2016年03月24日

ソフトウェアの世界は螺旋を周りながら進歩している

npm周りでごたごたがありました。その前にはCocoaPodの問題もありました。その前にはGemの話も話題になりましたよね。

上記のツイートはgemに絡んでのツイートであって、コンテキストはnpmではなかったのだけど、なんか予言めいたツイートに見えちゃったのかもしれないけど偶然です。ここまで、いくつかの文化の変化がありました。

  • SourceForgeやCodeplex、Google Codeのような、プロジェクトが唯一の名前空間という世界があったが(今もないわけではない)、GitHubやBitbucketのような、個人や組織が名前空間としてあって、その中で自由に作り放題の世界ができた。
  • 地道にパッチを送って、信用貯金を得てコミット権を得るという文化から、どんどんプロジェクトを作って、フォークしてPull Requestで開発を行っていく文化になった。
  • かつてライブラリは、システムにインストールするものだったが、node.jsがプロジェクトごとにローカルにライブラリ庫を持てるようにした。Pythonはvirtualenvなどの後付の仕組みでそれを実現していたが、それが標準になった。プロジェクト間のコンフリクトを恐れずに気軽にダウンロードできるようになった。

3/25追記:
最後の項目について、はてブでJavaについての指摘がありました。CLASSPATHについては確かに指摘された通りですが、それを言ってしまうとconfigure --prefix=(ここ)でもできちゃうことではあるし、rpm/deb/CPAN/PyPIなどの依存関係解決機能付きの中央パッケージリポジトリを使ったケースで考えていました。Javaは1.2のホットスポットコンパイラすげぇ!って時に触ったっきりですが、調べてみたらMavenは共通の場所(${HOME}/.m2)に入れているようですね。最近のJava事情はよく分かってません。すみません。昔の、1回ダウンロードしたものをありがたく使い回してたのはダイアルアップ等を考慮してのような気がします。

新しいことを始めたり、コードを改善する上での敷居がどんどん低くなって、コードを書く自由が飛躍的に高まりました。今回起きたnpm、CocoaPod、Gemの話はこれらの流れとは逆行する話です。作る自由というのは壊す自由と表裏一体です。変更やアップロードが取り消したりすることができなければ、作るのにみんな慎重になります。無茶できるのは、セーフティネットがあるからです。そういう意味で、「unpublishを禁止しよう」というのはちょっと違うかなぁと思います。それでは防ぐことはできません。

壊れたアップロードもできないように制約をかけるべきか?マイナーバージョンアップでは、使われているすべてのパッケージで壊れないかを自動テストすべきか?というのを考えていっても、どんどん不自由になるだけです。

ちなみに、npmの対応を問題視している人もいますが、たぶん運営側になったらこのような対応をせざるを得ないかなって思います。全世界から使われるサービスで、「この国のこの法律に反しているんだけど」って言われた時にどこまで対応すべきか、無視すべきか、そこをきっちりガイドライン化できる人はたぶんいない。自分の国の著作権の扱いだけでもみんな頭を抱えている状態ですし、法的アクションを起こした人優先にせざるを得ないかなぁと思います。そうでなければnpm社が潰される可能性もゼロではないし、npm全体のエコシステムがまるごと潰されるよりは、指摘があったトカゲの尻尾を切り離す方が全体の保持になると思いますし。

3/25追記:
npm社も一応ガイドラインがあってそれに基づいた紛争解決はこれまでも行われてきたとのこと

The npm Blog − kik, left-pad, and npm

なるほど。そもそも名前に関する紛争解決ガイドラインがあって、semverを使ってユーザーに負担にならないように名前を移管することが推奨されてるのか

2016/03/24 14:15

Github社だって、指摘があったらリポジトリをクローズします。知人がこれをされたことがあるのですが、反論の余地は与えられなかったとのこと。ここに消えていったリポジトリの墓標があります。他の知人で、Bitbucketでリポジトリをクローズされた人もいます。まあこれはプライベートリポジトリが無制限になった時にエロ動画をたくさんアップしたという事案なのでアレですが・・・

使う側での防衛方法としては、リスクを恐れてgithubやnpmの使用をやめる、というのはご自由にどうぞ、と思いますが、現実的な落とし所は、きちんと信頼できる開発元のライブラリを使いましょう、以上のものはないかな、と思います。

ソフトウェアの世界はこれまで何度も螺旋を描いてきた

続きを読む
posted by @shibukawa at 03:09 | TrackBack(0) | 日記 はてなブックマーク - ソフトウェアの世界は螺旋を周りながら進歩している

2016年03月21日

Gopher Night #1で発表してきました

適当に作ったライブラリの紹介をしました。スライドの流れは、10数年前の、牛尾さん(当時NEC)のアジャイル原理主義のスライドのオマージュです。Goの人気ぶりを表すエピソードとして、アドベントカレンダー(3本埋まった&Goを関してない企業アドベントカレンダーでもたくさんGoの話が出てきてた)みたいなのを言おうと思ってたけどいい忘れました。あと、Goのキャラクターあざとい話で、ウルトラマンXのツインテール前髪パッツンメガネっ娘ホットパンツニーハイソックス白衣理系女子のルイルイ並にレベル高いあざとい、みたいに言おうかなとか一瞬思ったけど自粛しました。気になる人は映画館へGo!

あとは、このネタに至る道程としては、Unreal Wayの「それぞれの人が自分だけで高速にイテレーションを回せる」「プログラマーが間に挟まると、その分だけイテレーションが減る」「計画・実行までのサイクルが速いScrumであっても、1週間は要求の変更をブロックするから、それだと遅いよね」みたいなのがあったんですが、それを説明しだすと動くものを紹介するまで長くなっちゃうので辞めました。

普段サーバっぽいコードは書かないので、その点はいろいろ話を聞いて参考になりそうでした。MQとかね。そのうちちょっとやりたいなぁと思っていたので。あと、HashiCorp製のプラグインの仕組み(別プロセスでRPCでやりとりする)というのは、同じような奴をやろうとしていました。僕の方で考えていたのは、Go/Qtの通信用で、QtにあるQLocalSocket/QLocalServer互換のソケット(Windowsは名前付きパイプ、それ以外ではUnixドメインソケット)をバックエンドに使い、その上にdRubyっぽいレイヤーの簡易版(参照渡しはサポートしない)を用意して、HTTPのウェブアプリのようなパス上にオブジェクトを配置してメソッドと引数を渡すという感じでやろうとしています。Goはreflectを使って、QtはQMetaObjectのリフレクションを使ってメソッド呼び出しができるので、言語が違っても相互にやりとりできる(部分の検証はすでに済み)。Go側の実装は一通りできていて、Qt側は現在実装中です。これもそのうち公開できるかと思います。それ以外だと、SensorBeeのコードのASTをいじくるコードはなんかそのうち書いてみたいですね。

イベント主催かつ会場提供のエウレカさん、どうもありがとうございます。また次回以降のイベントも楽しみにしていると同時に、金銭的余裕があれば(キッチン内蔵の食器洗い乾燥機と、Nexus 5が壊れたり)しなければ懇親会も参加したかったです。

posted by @shibukawa at 14:30 | TrackBack(0) | 日記 はてなブックマーク - Gopher Night #1で発表してきました

2016年03月01日

ハッカソンのゲームデザイン

ハッカソン界隈が非常に盛り上がっています。ハッカソンという言葉が一人歩きした結果だから「まあそういうことも起きますよね」としか思えないのですが、いいタイミングなので、4-5年ぐらい前から考えていたことをまとめてみます。

ハッカソンという名の対人リアルタイムシミュレーションゲーム

ハッカソンという名前がバズワードとして広まり、いろいろなイベントのタイトルとして使われています。ただ、本来使われてきたハッカソンとは意味が違ってきています。こちらにオフラインの勉強会のスタイルの分類をまとめているのですが、ハッカソンはどちらかというと開発合宿スタイル。集中的に何か動くものを作ってみよう、という形のイベントです。

@technohippyさんが良いリンクをTweetしていたのでこれも参考に貼っておきます。

一方、企業協賛のものは商品や賞金が出るということもあって、優劣を決めるイベントです。これを明確に表している分類は「コンテスト」の方が適切かと思います(数年前の感覚では)。ただ、言葉の定義というのは、神から与えられた正しい意味みたいなのはなくて、人々が使っている中で、誤用とかも含めて定着していった結果です。オリジナルの由来のみを正しいと信奉して「送り狼」を褒め言葉で使ったらたぶん友達がいなくなります。送り狼にも諸説あるみたいですが。コンテスト相当のものを「ハッカソン」と呼ぶというのはこのまま定着しそうな気はします。

「コンテスト」であれば勝敗をつけるイベントというのが明確なので当然「レギュレーション」をどう定めるのか、その中でどうパフォーマンスを出すのか、というところに参加者や審査員の意識はフォーカスします。「ハッカソン」と呼んでしまうと、「クリエイティビティを発揮しよう」みたいな印象を与えがちで、あまりルールや縛りにフォーカスしようとはしなくなるんじゃないかと思います。そういうポジティブな印象を与えたい、という主催者側の意図が「ハッカソン」という言葉を使わせている気はしますが、それが逆にハッカー気質な人がハッカソンという言葉に対してネガティブな印象を持ったり、今回の関連記事等にかかれていたように、一部の参加者「技術を発揮しないのに違和感を感じる」という悲劇につながっているのかなと思います。

ハッカソンをゲームと例えるなら、準備フェーズでスキルを成長させて相手を殴りに行くMOBAとか、RTSに近いかもしれません。この手のゲームで「この設備を最初に作っちゃえば勝ちが確定」みたいなのがあると対戦は面白くないですよね。

対戦ゲームはバランス調整が肝

続きを読む
posted by @shibukawa at 18:28 | TrackBack(0) | 日記 はてなブックマーク - ハッカソンのゲームデザイン
検索ボックス

Twitter

www.flickr.com
This is a Flickr badge showing public photos and videos from shibukawa.yoshiki. Make your own badge here.
<< 2016年03月 >>
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    
最近の記事
カテゴリ
過去ログ
Powered by さくらのブログ