よそに訪問している時には割とお話の責任が割り当たるので、 松江ではそういう機会はあまりないのだが、今回は松江でも。 テーマは「悔い改め」、というか、そこから発展して「忘却」について。
忘れてしまうことは恐ろしいことだ。 感謝を忘れると恩知らずだし、罪を忘れると悔い改めることができない。
引用した聖句:
私は自分が忘れっぽい人間であることを自覚しているが、 本当に大切なものは忘れないようにしたいものだ。
とうとう登場した。いつかはやる人が出てくると思ってたんだ。大歓迎。
大会ルール。 〆切は3月末日(2005-03-31 23:59:59 UTC)。
可読性が高いといわれるRubyだが、読めないことに関しても他の言語に決して負けないことを示していただきたい。
Ruby用IDE。
Chizzle is a ruby ide. Frustrated by the lack of a good ide for ruby, CharlesLowell and I decided to try our hand at one.
Our vision is to eventually build an IntelliJ style IDE with tons of refactoring support on top of Parrot AST's. This means that it in theory, with a few tweaks, it should support any language which can run on top of the Parrot VM. This includes ruby, python, perl6 and a ton of others. Pretty cool concept, yeah?
っていうか、これParrot用IDEなのね。あれ、「目指してる」だけなのか? いずれにしても面白い。
ところでこのIDEは日本では「千鶴」と呼ばれちゃうんだろうか。
「約束」を引用しておく。
非常によろしい。 佐渡さんのインタビューも参考になる。
うちの会社もこれくらいしないと、 OSS界におけるプレゼンスの今以上の向上は望めないんじゃないだろうか。 今、同じ「約束」を出しても二番煎じで目立たないのが欠点だが。
社内では、うちで開発しているオープンソースソフトウェア(あまり知られていないが結構ある)を、 一箇所にまとめてファームして、sourceforge.jpのような形で知らしめてはどうか、 というアイディアが出ている。実現すればVAとは違う形でアピールできるかも。
追記:
佐渡さんのインタビューには、
しかし、われわれとしては勤務時間内は100%与えられたタスクをこなしてほしいと思っています。企業に属する以上、勤務時間中にはやはり業務に専念しなければいけません。ただ、業務に関連してプロジェクトに関わることもあるでしょうから、それは認めなければいけません。
とある。ああ、VA Linuxはまだ「普通の会社」なんだなあ。
うちは小さいせいか、
なんて感じだ。
佐渡さんの日記で、上のエントリに反応があった。直接コメントがつけられないので、こちらで書いてトラックバック。
で、Matzさんからは「VA Linuxはまだ「普通の会社」なんだなあ。」と突っこまれているが、これについては(世間の普通ではないかもしれないが)普通の会社でいいと思ってるのでいいとして、それ以降に書かれていることはちょっと首をひねるかな。
あぁ、「普通の会社」と書いたことから私の意図以上にネガティブなものを読み取られたようですね。 言いたかったのは「うちは(まだ)普通じゃないなぁ」であって、実はVAに含むところはないです。 まだまだ小さいからこうなってる部分もあるわけで一概に比較はできないでしょう。
そもそも業務でOSSを開発するのは、VAリナックスではごく普通のことであるので、OSSの開発も業務に入ることになる。ただ、業務と全く関係のないOSSプロジェクトに勤務時間中ずっとかかりきりになるのは当然ダメなわけで、ある程度の線をひくことになる。
やってることは同じですよね。ただ、うちには勤務時間という明確な縛りがないから、 「タスクを期限までに完了する」というのが「線」になっているということで。
Paul Grahamからメールが来た。 Summer Foundersプログラムの卒業生が作った reddit.comの日本語版が出来たから、見てくれないかと。
どうも、ブックマークに近いのだが、「好き」「嫌い」を入力して訓練することでお薦めとか出してくれるようだ。こういうのはデータの数が重要なので、いろんな人が参加して、どんどんURLを登録してくれるといいと思う。
一番感動したのは登録が簡単なこと。AJAXを使っているせいもあるが、今までいろんなサイトで見た中で一番簡単だったんじゃないだろうか。
見たらshiroさんがさっそく登録していた。
たださんからトラックバックをもらった。
並みの自意識は持っているので、名刺を出すときにちょっとドキドキするわけなんだが、一度も気づかれたことはない。今日行ったところなんてブログ屋さんなのに、ビタイチ反応なしである。
いや、ブログ屋で、たださんに気がつかないっていうのはどうかしてると思うけど。
弾さんのフォローにもあったけど、とにもかくにも有名になることに意味なんてない。的確な分野で認知されれば十分なのだと思う。で、そういう意味では、たださんは十分有名だと思いますよ。
で、
まつもとさんが、NaClの「広告塔」としてどれくらい機能しているのか、興味があるな。対費用効果とか。たとえばNaClはけっこうCOBOL仕事もやっていると聞いたことがあるけど、そっち方面には広告効果はないよね、たぶん。一方で、広告塔が有効に機能する仕事もあるとは思うけど、じゃあそれが NaClにとってどれくらいメリットをもたらしているんだろう?
とのこと。実は、恐いので数値化はしないでいるのですが、首になってないところをみると、
ということではないかと勝手に想像してます。
メリットは
などなどですが、これをどうとらえるか、ですよね。幸い、経営陣はポジティブに評価してくれているようです。
昨日あたりから調子が悪い。一昨日の晩、マレーシアのスライド仕上げるのに夜更かししたからか。今日は早く休もう。未踏のスライド準備できてないんだけど...。
(関係者を不安にさせるようなことを言う)
で、風邪でぼーっとしてる頭でつらつらと考える。
モジュールを気軽にincludeした時に、そのモジュールが定義しているpublicなメソッドが取り込まれることは問題ない。その機能(メソッドの集合)が欲しいからincludeするわけだから。
しかし、内部的に使われるだけのprivateなメソッドが重複してしまうことは避けたい。重複を避けるために妙なprefixを付けるのもイヤだし、とはいえ、気軽にprivateが使えないのもイヤだ。
これを改善するにはRubyの挙動を以下の二点について変更すればよい。問題はその変更による影響がメリットを上回るか、だ。
まず、privateメソッドがpublicメソッドを(意図せず)上書きしてしまった場合に対応するために、 publicメソッドを探している時に、privateメソッドを見つけたら、そこで失敗せずにさらにスーパークラスを探索するようにする。
これはメソッド探索ルーチンに、今publicメソッドを探しているか、 privateメソッドを探しているかの情報を与えてやれば良い。変更は簡単だろう。この点は今までエラーになっていたものがエラーでなくなるだけなので変更による影響は少ない。
しかし、privateメソッドが、publicメソッドまたは別のprivateメソッドで上書きされてしまう問題は上記の変更では対応できない。
で、どうするかというと、「関数形式(レシーバを省略した形式)で呼び出したメソッドの探索は、メソッドが定義されているクラスを始点とする」という変更を加える。すると、関数的に呼び出されているメソッドの定義はサブクラスにより上書きされないことになるので、オーバーライドの心配が無くなる。
この変更では「外から呼び出されたくはないが、サブクラスで上書きしたい」要望が (もしあったとしたら)難しくなることが欠点である。そのような要望はあまりないような気がするが、言語はどのように使われるか分からないから、「ない」と断言するのも難しい。
「明示的にselfをレシーバとして指定した場合には、privateも呼び出せる(しかし、探索はオブジェクトのクラスからはじめる)」のような回避策が必要になるかもしれない。
あるいは、積極的な対応はせず「そういう使い方にはprotectedを使ってほしい」というのも手だろうな。
もうひとつの欠点は、メソッドの呼び出しセマンティクスが複雑になることだ。今の「メソッドを呼び出す、しかしpublic/protected/privateという可視性がある」というモデルも十分複雑なのに、それ以上複雑にする意味があるのか。
個人的にはあるような気がしているのだが。
「Delphi for PHP」なんて名前は形容矛盾じゃないかと一瞬思ったのだが、 よく考えてみたらかつてのDelphiに組み込まれていた言語はDelphi言語ではなく、 Object Pascal(の方言)だったということなのかもしれない。
しかし、Pascalの代わりにJavaを採用したものはJBuilderだったしなあ。
Delphi for PHPのコア部分はスペイン製らしい。
角谷さんのデブサミ講演を社内で再演したもの。 熱く語っている。
ところどころ「まつもとさんが〜」という言及があって恥ずかしい。
あと、武者修行メソッド重要。永和さんにはずいぶん助けてもらっている。 というか、NaClは万年人材不足なので、 我と思わん人の応募を待っている。
Kahuaもこんな感じのようだが、 普通に手続きっぽくロジックを組むと、 非同期のイベントドリブンに動作してくれるというモデルにはあこがれを感じる。 あとはどこまで隠蔽できるかという点だ。
でも、Railsの隆盛を見ていると、 実はそんなことは問題じゃなかったりして。
HpricotとWWW::Mechanizeを統合した scRUBYt!の紹介。
機能もString#scrapeもそうだけど、 だんだん面白いツールが出てきた。
なんとなく「知らなかっただけ」という気がしないでもないけど。
夕方からRuby開発合宿。本来は明日からのような気がするのだが、 せっかく集まったので(中田さんはまだ)。
今日の時点の参加者は
で、今日は今後の方針について議論。重要な点は以下の通り。
さほど重要でない点。M17Nの細かな仕様など
日曜日に用事があるためまわりの人たちよりも1日早く出発。
ヒルトンからシャトルで空港まで。14ドル。 MAX(2ドル)に乗った方がよかったかなあ。
ポートランド空港では無線LANが無料で使える。ありがたい。 ポートランドからサンフランシスコ。 サンフランシスコから成田。 空港でゲートを間違えてちょっと焦った。
成田について4時。 メールチェックしてから羽田へ。
羽田は大混雑。 なんでも雪のため北方向の便がそうとう欠航しているらしい。 で、そうこうしているうちに私が乗るはずだった米子便も欠航。 がびーん。
朝イチの便を予約し、ホテルに泊まる。 青物横丁の東横イン。
明日には帰れるか。
また表彰していただいたらしい。 ありたがいことである。
期待されているということだと思うので、 期待に応えられるようにしたいものである。
というわけで対談することになった。
対談というのはプレゼンと違って事前の準備はさほど要らないので 気は楽なのだが、聴衆にとって価値が出るかどうかはかなり運次第である。 まあ、弾さんとならばそんなにハズれることはないんじゃないかなあ。
以前にもCodeGearのデベロッパーキャンプの時にも会ったし、 今月のデブサミでもかなり長い間、話をする機会があったが、 ほんとうにいい人である。
また、Rubyに対するコミット加減もこっちの方が当惑するぐらいである。 たいへんにありがたい。
ところで、デブサミで彼がマイクロソフトの波村さんをつかまえて、 「Andersと働いてるのか。奴は俺の長年の友人だ。昔一緒に働いててな」などと 話しかけていたのが印象的である。