金曜の忘年会のあと、 週末スキーに行って体調を崩した人、 ゴルフに行って風邪をひいた人、 とにかくなんだか具合の悪い人が続出。遊び過ぎです、みなさん。
先日のスライドでの インスタンス変数の変更に対して、ruby-talkで異論がある人が結構多い。
複雑になるのを嫌ってのことのようで、理解できないでもないのだが、
のそれぞれが整理されずに噴出しているようだ。
しかし、複数のモジュールが使うインスタンス変数が、重なっちゃった時には悲劇なわけで、 それを確実に避ける手段はなんとかして提供したいんだが。
あるいは「:=」を、初期化されていないことを検証する代入として導入すると、 重複の検出だけはできるようになるなあ。自分の管理下にないもの同士が重複しちゃうと 検出しただけでは駄目なんだが。
オープンソースに関する記事みっつ。後ふたつはk3cの日記から。
オープンであることを強みに換えようという鼎談の記事。 この記事には当たり障りのない内容しかないけど、現場にいれば面白い話があったかも。
日本随一の(唯一の？)オープンソースジャーナリストとして名高くなった風穴さんの記事。 OSDを満たすことよりも、その結果成立するバザールモデルが重要との内容。
Web Publisherの作者である成島さんによるオープンソースビジネス論。
作者がオープンソース関連ビジネスをやらないようなら、その作者が行うオープンソースプロジェクトの価値自体を見直したほうがいいのではないかと思います。なぜなら、作者がそれをやらないということは、そのオープンソースの価値もそこまでだということだからです。
オープンソースを書くことによって自分にどういう利益があるのか、これを意識しないオープンソースはダメだと思います。惰性でオープンソースを書いていては、長続きしません。
というのは残念ながら自分の立場の押しつけの印象がある。 オープンソース開発者の意識やスタンスはそれこそ多種多様である。
しかし、気持ちはわかる。私自身もいわば「オープンソース作者を抱え込むメリットがある組織に属」する方法を実践しているわけだし。オープンソース開発で飯を食う人はもっともっと増えるべきだ、というのは私の持論なので、 ぜひ実践していただきたい。期待している。
「オープンソースビジネスは成立するか？」が、 たださんのところでも話題になっている。
その中でも
開発者として、オープンソースだけでメシが食っていけるならそれに越したことはない。おれもつい先日、某誌から受けたインタビューで「できることならそうしたい」と言ったし。Linux KernelやRuby、それからWeb Publisherのようなインフラに近いプロダクトは寿命が長いので、うまくすれば継続して収入をもたらしてくれる可能性は高い。逆にアプリケーションは寿命が短いので、そのプロダクトだけで食っていくのは難しいだろう。
しかし新陳代謝の激しい業界である。いくら寿命の長いソフトを作っても、いずれは使われなくなる時が来る。その時のことまで考えたライフプランニングはあるのか。例えば単一のソフトウェアプロダクトを元に興されたベンチャー企業が、製品寿命を越えて生き延びるために買収や合併を繰り返すのと同様、オープンソースの作者だって(それで食っていくなら)より長く生き延びる方法を考えなくては。
という部分は私にない視点であった。私は自分の得意分野が変化がゆっくりで寿命が長い プログラミング言語なので、上記のことはあんまり意識していなかった。確かにそうだな。
ただ、「きちんとしたプロジェクト」の寿命はそれなりに長い(10年スパン？)と思うのだ。 もちろん立派なプロジェクトでもっとずっと早く使われなくなるものは多いけど、 それは寿命がきたというよりは、むしろ「継続できなかった」という問題ではないかと。
となると、「最初の難関」を乗り越えたオープンソース開発者の次の目標は、 十分長い期間継続することでプロジェクトのプレゼンスを増すことで、 最終的な目標は、その「ある程度長い期間」の間に今度は自分の プレゼンスとか地位とかいうようなものを確立すること、ではないだろうか。
そんなあやふやなのはライフプランニングとは呼べないかもしれないが、なに、 ほとんどのベンチャー企業の将来に対する目論見もその程度だ(暴言)。
オープンソース開発者は、オープンソース開発(特にバザール体制による開発)が楽しいのでやっているのだが、 プロジェクトが成長するにつれだんだん片手間では手に負えなくなる。ここで、選択肢がやってくる
前二者は継続性について不安がある。これらに成功せず衰退したプロジェクトは多い。 後者は結局「プレゼンスの向上」こそが鍵である。これをいかに実現するか。
(結論のないまま終わる)。
について質問された。きっと、このメリットは「企業にとって」という意味だろう。
普通に考えると
というのが一番大きい。オープンソースプロジェクトを使う時に一番不安なのは継続性だ。 途中で消え去ってしまうものがいかに多いことか。 もちろん、ソースが公開されているのだから、たとえ主開発者が引退しても 原理的には継承できるのだが、そんなに簡単というわけではない。 ならば、いっそ主開発者を抱えることで すくなくとも自分が必要な間の継続性を保証しようというのは論理的な企業戦略だ。
その他に重要そうなものを考えてみると
などがある。要するに「Rubyの作者」を一人飼うのは、 雑誌に広告を出したり、リクルートに募集依頼をしたりするよりずっと安くて効果的ってこと。
発端は「TinyP2P」。 Pythonで書かれたわずか15行でのP2Pアプリケーションである。 もちろん実用的ではなく「基本はこんなに簡単」ということを示すためのもの。
これに対してMoleSterなる Perlによる9行の実装が登場。 こちらは、さらに以下のような制約を加えているところがすごい。
実装は以下のようになる。
$/=$_;$,=shift;$w=$a=shift;sub g{open(F,'<',$4)&&t($2,$a,"e$4",<F>);close
F}$k{+shift}=1;socket S,2,1,6;bind S,&a;sub e{open F,'>',$4;print F
$';close F}sub h{t($2,$_,id)for keys%k}sub i{$k{$2}=1}sub f{t($_,$2,$4)for
keys%k}sub a{$w=~/:/;pack'CxnC4x8',2,$',split'\.',$`}for(listen
S,5;$SIG{ALRM}=sub{};m!^(.*?) (.*?) ([e-i])([^/]*)/!s&&$,eq$1&&&$3){alarm
9;(accept(C,S),alarm 0)?read C,$_,1e6:($_="$, $a f".shift);close
C}sub t{socket X,2,1,6;$w=shift;$k{$w}=(connect X,&a)?print
X"$, $_[0] $_[1]/".pop:$/;close X}
目がつぶれそうだ。
Rubyも負けていない。以下はFlorian Grossによる実装([ruby-talk:123789])。
#!/usr/bin/ruby
# Server: ruby p2p.rb password server server-uri merge-servers
# Sample: ruby p2p.rb foobar server druby://localhost:1337 druby://foo.bar:1337
# Client: ruby p2p.rb password client server-uri download-pattern
# Sample: ruby p2p.rb foobar client druby://localhost:1337 *.rb
require'drb';F,D,P,M,U,*O=File,Dir,*ARGV;def s(p)F.basename p[/\w.*/]end;def c u
DRbObject.new((),u)end;def x(u);[P,u].hash;end;M["c"]?c(U).f(x(U)).map{|n|p=x(n)
c=c(n);(c.f(p,O[0],0).map{|f|s f}-D["*"]).map{|f|open(f,"w")<<c.f(p,f,1)}}:(DRb.
start_service U,Class.new{def p(z=O)O.push(*z).uniq!;O;end;new.methods.map{|m|m[
/_[_t]/]||private(m)};def f(c,a=[],t=2)c==x(U)&&(t==0?D[s(a)]:t==1?F.read(s(a)):
p(a))end;def y;(p(U)+p).map{|u|c(u).f(x(u),p(U))rescue()};self;end}.new.y;sleep)
コメントを除けば6行。密度でも負けていない。
ただし、dRubyを使っているから「TCP以上のプロトコル抽象化ライブラリを使わない」というMoleSterの制約は満たしていない。
スライドを仕上げてから仮眠。 その後、ホテルをチェックアウトして、オブジェクト倶楽部クリスマスイベントの会場へ。 と、その前に乗り換えの新宿で軽く朝ご飯。 たこ焼き(それで朝ご飯か)を食べながら、PCで会場の位置を確認。
小田急線で参宮橋へ。
で、会場に着いたらマシンがレジュームしない。 あらら、と思って電源を切り、再度スイッチを入れると なんとBIOSから起動しない。 昨日のとみたさんに引き続きIBMマシンは厄日なのか。 どうして私がプレゼンしようとするとマシンに嫌われるのか。
「Access IBM」ボタンを押しながら電源ボタンを押すと ４回に１回くらいの割合でBIOSが起動する。 BIOSの設定に問題はないように思うが...。
で、BIOS設定画面から改めて起動すると ４回に３回くらいの割合でgrubの画面に到達する。 で、そこまでいくとxdmの起動までうまくいく。
しかし、しばらく使っていると原因不明のハングアップに。
とりあえず、うまく起動できたところまで持っていって 恐る恐るプレゼンを始める。
が、やっぱり途中で固まってしまう。 リブートもしない。あらら。
今までも、プレゼンしようとするとプロジェクターに出力されないことは数知れず。 うまくいくはずの新しいマシンでも今年のRubyConfで出力できなかったし、 今度はマシンそのものがブートしないとは。やっぱり呪われているのか。
そこで記憶を頼りにしゃべりでカバーしようとしたが かなり無理がある。でも英語でなくてよかった。
途中休憩を入れさせてもらって再挑戦したらブートした。 だましだましプレゼン再開。 今度は最後までハングせずに終了。
なんともかともひどいことであった。 期待して私の発表を聞きに来た人はごめんなさい。 まあ、おかげでテンションの高いプレゼンにはなったような気もする。
とりあえずこちらにスライドを置く。 ちょっと高橋メソッド風味。誤字だけは直してある。が、実際の発表はこのスライドだけではとても表現できない。いや、良くも悪くも(主に「悪くも」かな)。
私は、いわゆる「アジャイル」な人ではないので、 ここで話しているアジャイルは、XPとかのことではなく、 「変化を許容するやり方」全般のことだと思ってほしい。 途中むりやりXPのプラクティスにつなげてるけど、これは愛敬。
最後に質疑応答。
「Rubyはテストに向かないのでは？」という質問。
「確かにテストを書いてると頭の中の「これから作ろうとしているもの」のイメージが逃げて行ってしまうように感じることもある。でも、それはRubyに限った話ではなく、イメージとコードが近いRubyで目立つだけ」が答え。しかし、あとで考えると「ドライブ感」を重視したテスト方式って開拓の余地があるかも。
「豊富なリテラルを追加する予定がありますか、時刻リテラルとか」という質問。
「とりあえず予定はない」が答え。しかし、しっかりruby-listを読んでいるのね。
「Rabbit使ってください」が要望(須藤さん)。
「はい、...たぶん」が答え。８年以上使っているMagicPointに愛着があるのと、 スライドの準備をするときには時間的余裕がなくて新しいツールを試してみる暇がないことが多いんだよね。あと、Debianパッケージがあると試しやすいなあ。
「本日中に帰宅せよ」との指令があったので、懇親会には出席できず。 ちょっと残念。
帰ったら、島根は東京より寒かった。
帰宅中、空港でBIOSの自己診断プログラムを動かすと、 どうもメモリーがおかしいらしい。
帰宅して、ドライバで裏蓋を開け、 DIMMを差し直すと、とりあえず通常のBIOS画面が表示され、ブートした。
その後、一度ハングしたがもう一度DIMMカードを差し直したら 通常に戻ったようだ。なんだったんだ。やっぱり呪われていたのか。
そういえば、とみたさんのマシンも復活したようだ。
姉二人は部活。 残る家族とクリスマス前の買い物。
ユーザインタフェース、特にユーザがそのツールを使ってどのように感じるかを デザインの根本原理にするという話。
Webアプリケーションに特化した話ではあるが、 そのデザイン原則はあらゆるUIデザインにつながる。
言語デザインにも有効そうだ。