ぶじに開催されました。「10年後も通用するソフトウェア技術者になるには」とかいうような テーマでしたが、自分自身が10年後も通用するかどうかもわからないのに、えらそうなことは言えないなあ、 と思いつつ臨んだのですが、なんか思いっきりえらそうなこといってたような。
会場にいた、咳さん、たださん、きたさんをはじめとする皆さんはどのように感じられたのでしょうか。
<URL:http://capsctrl.que.jp/kdmsnr/diary/?date=20030530#p09>に良いまとめがあります。
そうそう、私と斎藤さんって180度方向性が違いますよね。 片方はエンドユーザとサービスだけに関心があり、 片方は技術の深いところにどんどん潜っていっちゃう。
言えることは、
ってことですかね。お金が要らないわけじゃないんだけどなあ。
APSLがありましたね。 私は客観的に判断できるオープンソースの方向性も好きなのですが、 APSLのようなものを許容するのは「OSDのバグ」のように感じているせいで、 無意識に無視していたのかもしれません。
あんまり良いことではありませんね。どう考えるべきなんだろう。
オープンソースはフリーソフトウェアと同じものを違うアプローチで表現しようとしてるが、 まだ、完全には表現しきれてないと考えるか。 いや、本当にPerensやRaymondがそう思ってるかどうかは未確認だけど。
暫定的な状態だが、やっと復旧した。これを書いているのは6/5である。
「There Ain't No Such Thing As Plain Text」に関連して、 Paul Prescodからメールをもらう。要するに「Prothonはバイナリも格納できる文字列を採用しようとしているようだが、これは間違いだ。それに関してマイクロソフトが日本でどのように(Unicodeを使って)日本語を扱うソフトウェアを作っているのかいくつか質問がある」ということだそうな。
が、この質問に私はこたえられなかった。私も知りたいので、どなたか知恵を貸していただけないだろうか。
Microsoft is a huge promoter of Unicode, and not even full Unicode, but mostly the BMP subset. So I would like to understand how they make Japanese software that is popular.
Do they use Unicode?
マイクロソフトは(日本で)Unicodeを使っているか。
Do they layer on encoding tags or something on top?
エンコーディングを示すタグのようなものを使っているのか。
Does Japanese Word support a) just the BMP, b) all of Unicode or c) much more?
日本語版マイクロソフトワードは a) BMPだけを使っているか b) Unicode全部か c)それ以上か？
Can Japanese Word show un-unified Chinese and Japanese characters side by side?
日本語版マイクロソフトワードは中国の文字と日本の文字を(ユニファイせずにそれぞれの字体で)並べて表示できるか。
Can Word import from Ichitaro? If so, how do they manage the extra characters?
ワードは一太郎から文書をインポートできるか。できるなら、外字をどう扱っているか？
ご存じの方はいらっしゃるだろうか。最初のふたつの質問の答えが「Yes」、「No」であることは容易に想像ができるのだが。
リンク
ここ数日、Emacs上での日本語入力はAnthyを使って行っている。 「きゅうり改」を使って入力できるので、それなりに快適である。
もっと早く移行すればよかったな。anthy-kyuri.elを作ったら、 将来のリリースに取り込んでいただけるとの連絡をいただく。 ありがたいことだ。
ただ、使っているうちにいろいろ不具合を見付けたので、 しばらくハック。やっぱりEmacs Lispはプログラムしていて心地よい。
まあ、言語が優れているというよりも、 プラットフォームとしての機能の充実によるところが大きいのだろうけど。
ついでに元のanthy.elにもバグを見付けてしまった。
いろいろいじっているうちに、それなりに満足するものができたようだ。 変換効率もさほど悪くない。まだ「最高」とまでは言えないけど。
後は、「きゅうり改」で使っているとanthy-agentが30M以上メモリを使ってしまう現象がちょっと気になる。 rkmapを書き換えるとそういうものなのか、それともどこかにリークがあるのか。
ひさしぶりにオフィスに行ったら、うちの部署宛の仕事がいくつか来ていた。 まあ、確定ではないとはいえ、仕事があることはありがたいことだ。 普段あまり金にならないことをしているので、 たまには稼がないと「お荷物部署」とか思われると嫌だし*1。
とはいえ、全部〆切が7月1日というのはいかがなものか。 どういう営業でこうなるんだか。
*1 実際には大変に尊重してもらっている
子供、特に赤ん坊っていうのはだいたい親の期待に応えてくれない。 寝てほしいときに限っていつまでも寝ないし、 やっと寝たと思って布団に置いた途端に泣きだしたり。
「この子を寝かせて、仕事を片付けてしまいたい」なんて思っているときにはなおさらだ。 ストレスが溜るったらありゃしない。
が、冷静になって考えてみると、この種の「親の期待」なんてのは、 結局、親の都合の押しつけであるわけだ。 自分でない他者が自分の都合に合わせてくれないと嘆くのは、 どっちかっていうと「わがまま」とか「甘え」とかの領域で、 あまり褒められたもんじゃない。
「こうでなくちゃいけない」とかいうような思い込みを捨てて、 「ま、そういうこともあるわな」とのんびり構えることが必要だったようだ。 おかげでストレスからちょっと脱出できた。
仕事が進んでないのは変わらないんだけど、な。
左側の一番奥の歯(親知らずは抜いているので、その手前)が ときどき痛むので歯医者に。本当は医者や歯医者のたぐいは好きではないのだが、 歯は自然に直らないので(いや、厳密には再石灰化とかあるけど)、あきらめて。
レントゲンを取ってもらった結果
のだそうだ。うーん、歯磨きはそれなりに頑張ってたつもりなんだが。
で、金属をはがすのにえらい苦労した。 また、はがした後は簡単な詰め物があるだけなので、 食事の際にしくしく痛む。今まではときどき痛むだけだったのになあ。 薮をつついちゃったなあ。
プレゼンテーション。11時から最終練習という話だったが 少々遅刻した。ごめんね。
練習後、昼食。ビッグサイトはどこも満席。 かろうじてカレーを食べる。
1時からのSeasarのひがさんのセッションは大混雑。 すごい人気である。
と、思ったら、2時からの私のところも馬鹿にならない人数が集まる。 30分以上前から席を陣取ってる人までいるし。 最初30分弱は私がRubyをとりまく現状について話して、 残り15分くらいを山崎さんにデモしてもらう。
いつも、スライドばかりでおもしろくもないプレゼンだが 今回は趣向を変えて、と思ったのだが、担当になった山崎さんには いい迷惑だったかもしれない。せめて成長の糧にしてね。
デモのある発表は初めてであったが聴衆はどう感じたろうか。 数人に話を聞く限りでは、 おおむね好評だったのではないかと思う。
ただし、難点もあって、
くらいは残念だった。まあ、こんなに人間が来ることを想定した会場設計ではなかったものな。
ほか、風呂グラマー、増井(masuidrive)さんに会ったり、あちこちブースをめぐったり。 増井さんはおととしのOSC札幌で私が英語で質疑応答したのに影響されて アメリカに引っ越すのだそうだ。すげーっ。
思わぬところで他人の人生に影響を与えてしまっている。 なんだか恐いような気がする。
昨日公開された、私・平鍋さん・角谷さんの鼎談。 Linux World会場でもうちのブースで上映されていた。
今回はAgile・オブジェクト系言語の歴史概観。 ホワイトボードに書いていたものをタイムライン化したものも用意した。
うだうだとした話だが、これはこの後もずっと続きます。 ぜんぶで6話くらいになるとか聞いたような気がする。
「Rubyの鍵は信頼である」という話。
信頼については昨年末の福岡での発表で強調した覚えがあるが、 この人はそれを(Google Translateかなにかで)翻訳して読んだのだろうか(スライド公開してないような)、それともRubyを見ていて独自にその見解に到達したのだろうか。
どうも後者のようだが、だとすると、その感覚は非常に鋭い。 まるで言語仕様(とわずかな私の言葉)だけから「Ruby Way」を切り出してきた Hal Fultonのように鋭い。
Enumerableを操作するのに
@stooges.select {|s| s.name == 'Mo'}
と書く代わりに
@stooges.that.have.name == 'Mo'
と書くためのライブラリ、ho_enumerable.rbについて。
非常にRailsというか、ActiveSupportと同じ臭いがするが、 それはそれでアリなんじゃないかと思う。 でも、こういうのをHigher Orderっていうのかなあ。
というわけで、昨日U-20プロコン実行委員会でポロシャツをいただいたわけだが、
なんて書かれた(しかも出かける前にこのエントリを読んでしまった)からには、 着ていかないわけには行くまい。というわけで、Linux Worldでは 関係者でもないのもAsianuxポロシャツを来ている「自称ハッカー」が目撃されました、とさ。
あと、オライリーからも何枚もTシャツをいただいてしまった。 ありがとうございます。
夏時間(Daylight Saving Time - DST)のせいで計算が狂って2004年10月には30日しかないことになってしまったプログラムの話。
もう何年も前の話になるが、RubyのTimeクラスにも面倒なバグがあって 半年に一回1時間ずれるというレポートに対処するのに大変苦労したことがある。 何年かに一回政治家たちが省エネとか訳のわからない理由を言い訳に サマータイム導入を口にするが、冗談じゃない。
夏時間がないのは日本の美徳だと断言したい。 そんなものは要らない。
「今まではハードがどんどん高速化してきたので、ソフトウェアの皆さんは(マシンのアップグレードで)自動的に性能向上を享受できていましたが、これからは諸般の事情でそういうことはできなくなります。ソフトウェアの皆さんもご協力を」という話。
っていうか、最初からそういう風に言ってほしいものだ。
LinuxWorldでゼンドジャパンのブースに行って質問してきた。 あまり嫌みにならないよう、身分は隠して。
で、関心があったのはPHPのスクリプトキャッシング。 これにより実行速度が1.3から3倍になるのだそうだ。 どうにも納得が行かないのでいろいろ食い下がったが 対応してくださったのが内部までご存じの技術者ではなかったので 「理屈はともかく体感では確かに速くなります」とのことであった。 実体験を疑う理由はない。が、技術屋としては「なぜそうなるのか」がとても気になる。
私の理解が正しければ、スクリプトキャッシングは、 プログラムのロード時に構文解析を行い、内部的に用いる中間表現に変換したものを 保存しておくことにより、構文解析のコストを削減し、 高速化を実現する技術である。PHP以外にもたとえばPythonが同様のことを実現している (でも、Pythonは1.3倍とか言ってない)。
しかし、これにより実行速度が1.3から3倍になるということは、 単純に計算してアプリケーションの実行時間の23%から67%が 構文解析で消費されている必要があるのではないか。 Rubyではよっぽど特殊なケース以外では構文解析時間が 実行時間に対して大きな比率を占めたことはない。 各種プロファイルを行っても構文解析関係が上位に来たことは 私の経験では一度もない(ので、通常の感覚ではチューニングの対象にならない)。
にもかかわらず、PHPではこの結果というのはどういうことなのだろうか。 ソースも見てないので、断言はできないのだけど、いくつか考察してみる。 間違いがあれば(きっとある)、遠慮なく指摘してほしい。
構文解析が予想以上にコスト高
普通に考えたら、構文解析はそんなに重い処理ではないのだが、 実はそれは思いこみで、なんらかの事情でPHPでは構文解析のコストが非常に高い。
構文解析が予想以上に頻繁に実行される
普通に考えたら、mod_phpやfastcgiを使えば、構文解析はほとんど行われないと 思ってしまうが、実はそれは思いこみで、なんらかの事情でPHPでは構文解析の頻度が 非常に高い。あるいは実行速度が改善されたというのはCGIモードであった。
実は単なるキャッシングではない
スクリプトキャッシングは単なるキャッシングではなく、 同時になんらかの最適化も行っている。 キャッシングされて何度も実行されることが期待されるので、 かなり頑張って最適化しても、時間消費に見合う。 とはいえ、PHPのような言語でそんなに最適化が効くような気はしないけど。
謎は深まる。