私の住んでいるところは玉造といって、松江市の郊外にある温泉地だ。
ここは松江市ではない(玉湯町)ので、いろいろサービスが届かないことがある。 私にとって切実なのはいわゆるブロードバンドアクセスが提供されていない、という点だ。 だいたいコンピュータをろくに使いもしない実家が8M ADSLなのに、 どうしてまがりなりにも「コンピュータの専門家」ということになっている私が32kでアクセスせねばならんのか (それはもちろん引っ越しのときに玉造を選んだからです、自業自得)。
ある程度以上都市部から離れると、アクセスのための補助金が県から出るので、 かえってCATVやADSLのサービスが提供されている。ここは中途半端なのだ。 県は2003年度中に全市町村でブロードバンドアクセスが提供されるという目標を立てているのだが、 実際には今年度NTT西日本は島根県内で1箇所もADSLを新規開局していない。 こんなことで目標は実現できるのか。
ところが、先週ふとNTT西日本のページを眺めていると、 なんと「7月から玉湯町でADSLが提供」と書いてあるではないか、やった。 これで人並みな生活になる。うふふ。
単純な私は急に機嫌がよくなっていたのだが、今日になってNTT(マーケティングアクト)から電話があった。
NTT: 実はこの度、玉造でもADSLが提供されることになって... 私: それはそれは待ってました。 NTT: 2,3日中にプレス発表になる予定なので、その時にまた案内します。 私: でも、NTT西日本のページではもうとっくに発表してますよね。 NTT: え？ ....そうですか？
どうやら関連会社の間での情報連携に不備があるらしい。
で、あいかわらずGmailを試してみるのだが、不満もある。
文句ばかりだが、耐えられないというわけではない。というか、こういうツールが 手元にぜひ欲しいものだ。
昨日のメッセージは総計30Mを越えた。サーバ側でもフィルタリングすることにした。
希望者をつのったところ、実に14名の参加希望者が。
ということでメーリングリストを作ろうと思うのだが、どこが良いだろうか。
いまやrubyist.netやruby-lang.orgは私が勝手なことをするのははばかられるし。 とはいえ、ログを残したいのでquickmlとかはよくないような気がするし、 freemlは広告がうっとうしいし。
というわけで、作りました、langsmith。参加希望者は私<matz@ruby-lang.org>にCCして、
<URL:mailto:langsmith@quickml.atdot.net>
にメールしてください。で、自分の気持ちや野望を紹介してくださるとよいのでは、と思います。
以下のような人々を前に並べた上で勝手に喋らせるセッション。
ひとりだけ名前の表示幅や肩書が長いぞ、というのは置いといて。
で、ITmediaに寄せられた質問に対して、それぞれが勝手なことを言うスタイルだったのだが、 まあ、予想通りぐだぐだと話して終わり。盛り上がったんだか盛り上がらなかったんだか。 あと、聴衆の役に立ったんだか、役に立たなかったんだか。
その場で話されたことの概要はBravoさんがまとめている。
やや、補足するなら、私の主張のうち
ってのが書いてなかったかな。後者は私が「ここだけの話ね」って言ったからかもしれないけど、 ああ言ったのはその場のノリで、別に秘密にする程のことじゃないよね。
で、島根は遠いので、セッションが終わったら講師控え室で支給されたお弁当をいただいて帰路につく。
追記 (2005-06-29)
MYCOM PCで取り上げられている。
「確かにRubyにも(自分の勤務先の)お客さんの要望で入れた機能はある」なんて言ったかなあ。 Rubyじゃなくて「うちが開発しているOSS」というつもりだったんだが。
ITmediaでは20の質問それぞれで20本の記事を書くと西尾さんが息巻いていたが、 本当にできるだろうか。
先日の冗談パッチ(「;;」をendの代わりにするもの)に手を入れて、 「;;」を「end;」の代わりにしてみた。やっぱ「;」を含むんだから、文の区切りでないとな。
ary.collect do |x| x*2;;.each do |x| p x;;
とか気持ち悪すぎ。
あとは、anthyのkyuriバインディングにバグがあったので修正。
帰って家族と夕食を食べてから教会でミーティング。 出張があるから出席できないというつもりだったけど、 間に合うように帰れてしまったので。でも、ちょっとくたびれた。
今日のお客さんの中にはエンジニアの人も来ていたのだが、 この方、奥様もプログラマで、
とのこと。なんか、すっごく微笑ましいというか、 うらやましいというか。
うちはコンピュータ(特にプログラミング)に理解がないからねえ。 敵だと思ってるし。まあ、そう思わせているのは結局私の態度なんだけど。
David Alan Blackから、
プレゼンテーションの申し込みが少ないようなので、 「Matzにっき」で宣伝してもらえないか
との依頼。なんでだろう。めぼしい人はみんなRailsConfに取られちゃったのかな。
日本からの発表申し込みも歓迎だそうなので、 「こんなことしゃべってみたい」というものがある人は <URL:http://proposals.rubygarden.org/>まで。
言葉の問題には(ある程度)相談に乗ります。
〆切は6月30日。
広尾の神殿に参る。
六本木の方から向かって広尾の裏通りを抜ける。 この辺の道を通るのは２０年ぶりのような気がする。 寝坊したのでセッションはひとつしか受けなかった。
浜松の人に出会う。 その他にも知人の息子さんや、弟さんらしい人を見かけたのだが、 声をかけるチャンスがなくて確認できなかった。
２時の飛行機で松江に帰る。
先日の結城浩さんとの対談がWebで公開された。 同じものが今月発売の日経ソフトウェアにも掲載される。 同じタイミングで公開すると言うのは大胆なことではある。 ま、それだけ特集全体に自信があるということなのだと思う。
結構好きかってなことを話している。 ま、面白がって読んでいただければ幸いである。
SQLiteの開発者、Richard Hippのインタビュー。
数ある「オープンソース」ソフトウェアの中でもSQLiteはちょっと特異で、 完全にパブリックドメインを維持している。 また、SQLの解析のために独自のコンパイラ・コンパイラ(lemon)を実装してたりする。
ある意味すごく徹底してかっこいい。
また、会社を経営しているうえに、 SQLiteのためにアシスタント(Dan Kennedy)を雇っているというのも 尊敬する。
うちの取引先でもあるオープンソースジャパンがPCIホールディングスの子会社になった、という話。
なんの事情も聞いていないので、背景やらなんやらはさっぱりわからないのだが、 少なくとも当面事業方針に変更はないようだ。 このことから「オープンソースでビジネスするのは難しい」という結論が 引き出されるというわけではない、と思う。
4873113245 弾さんは「失格。」と断じたRuby Cookbookではあるが、 単独の書籍としては欠点があっても、 まわり(既存書籍)の状況や、費用対効果を考慮すると、 妥当だったかもしれない、という意見。
実はまだ私自身はRuby Cookbookを読んでいない(入手していない)ので、 どちらかに味方するつもりはないのだが、 複数の書籍に名前が乗る身としては、 書籍を企画する・執筆する・翻訳する・執筆する・出版する ことはたくさんの要素がからみあう大変難しい課題であって、 だれもが満足するものができることは滅多にないことについては よーく知っている。
RubyKaigi 2日目は参加できなかったので、 あちこちのレポートをチェック。
akrさんの「Matzを説得する方法」は普通にオープンソースで自分の要望を通す方法として 有効だと思った。「Perlを出すと通る」というような枝葉は除いて。
authorNariの「RubyのGCを(ry」は誤解を招くと思った。
JRuby, Rubinius, CRubyのGCをそれぞれ
として、CRubyのGCは(形容詞が少ないから)劣っていると思わせるような表現があるが、 それはあまり適切ではない。GCの実装というのはいつもトレードオフだからだ。
前にも書いたがスループットはGC全体の処理時間、 レスポンス(or ポーズタイム)はGC1回によって本来の処理が停止する時間である。
これらは多くの場合トレードオフの関係にある。
incrementalとかgenerationalなGCを実装するためには write barrierという仕組みを入れる必要があるが、 それはほとんどの場合スループットを低下させる。 要するにwrite barrierを入れると遅くなるのだ。
普通の方法ではwrite barrierを入れることによって増大したコストを 穴埋めするほどGC処理効率を改善することはできないし、 card markingなどの手法を使うとこんどはメモリを馬鹿食いする。
CRubyはconservative(保守的な)GCを採用しており、 残りはexact(正確な)GCを採用している。
exactなGCの方が性能的にやや有利だが、 一方、拡張ライブラリの書きやすさは 保守的GCの方がずっと楽である。
たとえば、Rubiniusはexact GCを採用しているため
など、Cでのメソッド定義にかなり制約がある。 まあ、ほとんどのメソッドをRubyで実装しようというRubiniusでなら 受け入れられる制約なのかもしれない。
CRubyは開発効率を重視しているので、 今後も保守的GCを使い続けると思う。
Ruby Enterprise Edition*1でも 指摘されていることだが、サブプロセス間でメモリページが共有されている場合には オブジェクトにできるだけ触らない方がよい。ページのコピーが発生しちゃうから。
ところが、JRubyやRubiniusのcompactを行うGCは、そういう観点からは壊滅的である。 まあ、JavaにはforkはないからJRubyは気にする必要はないのかもしれないけど。
現在のCRubyのGCもcopy-on-writeについて問題はあるけれども、 compactingを行わないので、(REEが使っている)bitmarkingなどの手法で 対応する可能性は残されている。
というわけで、「どんげんかせんといかん」だろうとは思うが、 今のRuby GCが今のようになっているのはそれなりに理由がある、という話。
世代別GCだって、copy-on-write friendlyだって、実際に試してみた上で、 普通のケースで性能低下が発生するので採用していないわけで。
*1 Ruby Enterprise Editionについてはあとで書くつもり
Charlesが来るからオフィスに来て、と言われる。
でかけると、某社社長が松江市の業務システム(Ruby製、一部JRuby入り)について 一生懸命(英語で)説明している。すばらしい。
あと、Charles相手にNaCl対抗将棋戦、囲碁戦が行われる。 将棋はshugoの勝ち、囲碁は時間切れ。
島大で講義。Charlesの講義が聴ける島大生はラッキーだと思うけど、 本人たちがどれだけ自覚しているんだろうか。
懇親会(その前にCharlesたちは千鳥城を見学したらしい)。
NaClの若い衆がCharlesを取り囲んで一生懸命英語で話をしていた。 authorNariはJRubyのGCについて食い下がっていたけど(うーむ)、 「そんなにはJVMに任せているからシラネ」とあしらわれていた(らしい、本人談)。
ケータリングは大変おいしかった。食べ過ぎ。
これからCharlesは福岡→東京と移動するらしい。 うーむ、なんて体力勝負。