午前中、長女の中学校の参観日だということで参加する。
普通の授業ではなく、ホームルームのような感じ。 人権とか同和とか書いてあったので、どんな授業をするのか、 と思ったが、その実態は一言で言うと「欠点も見ようで長所になる」というようなものか。
こういう活動をリフレーミングというらしい。 このフレームは「フレーム問題」のフレームだな、きっと。
で、資料としてリフレーミング辞書なる紙が配られた。 「頑固」が「自分の意見をしっかり持っている」などと ポジティブに言い換えられた単語が並んでいる。 これに基づいて生徒たちが自分と同じ班の人たちの「良い点」を探していた。 なかなか興味深い活動ではある。私が中学生のころはこんな活動絶対にしなかったよなあ。
このリフレーミング辞書を逆方向に写像すると「悪口製造機」になるのは、 思っていてもやってはいけないことなのだろう。
で、途中通りかかった中学校の図書コーナーには、 さまざまな職業に対して『〜になるには』という書籍が並んでいた。 若いうちからいろいろな職業になることを考えるのは良いことだ。 私でも事情がわかる業界について何冊か眺めてみる。
『コンピュータ技術者になるには』という書籍では、 結局は「コンピュータを好きなこと」くらいしか書いてないのだが、 いろいろな会社の技術者にインタビューをしていて、 コンピュータ技術者の生活実態がわかるのは良いことかもしれない。
ただ、取り上げられている会社が「コンパック」(HPに買収された)、 「ロータス」(IBMに...)など、今は無き会社ばかりなのが、 時代の移り変わりの速さを感じさせる。
『ウェブデザイナーになるには』という本では、 (株)オン・ザ・エッヂ社長の堀江貴文さんの写真が長髪で微笑んでいた。 これも時代の移り変わりを感じさせる。
安来苑で開かれたRuby温泉ミーティング2006春に参加してきた。
４時からチェックインということで、４時すぎに会場に到着。 さっそく温泉に入る。この旅館には何度も来ているのだが、 そのたびにハックしてたり、話し込んだりしていて、入浴したことがないのだ。 今回こそは。
堪能した。
末娘が生まれてからはなかなか温泉に行く機会もなくて(歩いていけるのに)、 久しぶりな気がする。
その後、食事と宴会。それぞれの料理には小さな鍋がついていた。 私はカモ鍋だったのだが、苦手な食材(特に名を秘す)が入っていたため、 イノシシ鍋と交代してもらう。
あとはあちこちで話し合いを進めたり、 雑談したり。剣神ドラゴンクエストのプレイが行われたり。
その後、サイボウズラボの竹迫さんが(主に)リクルーティングのプレゼン。 いや、気前のいい親会社があると違うなあ。 負けじと(株)ネットワーク応用通信研究所の発表も行われたが、 施設や資本で見劣りがするのは否めない。 温泉や豊かな環境やRuby三昧な仕事は提供できるけど。
あと、私や前田くんやかずひこくんと仕事ができます、とか。 うれしい人はかなり限定されそうだけど。
それから、松江だけでなく東京でも募集しているので、 生越さんや、ゆうぞうさんとも仕事ができます。 これも、うれしい人は限定されそうだけど。
さて、その他、目についたことを箇条書きに
I18Nは早々に入れる。
でも、まだこなれてないところがたくさんあるからなあ。 一番気になるのはMarshalのフォーマットだがすっきり「非互換で構わない」という結論が。 その他、正規表現の連携、文字コード変換・推測などもあるのだが、 その辺も含めて1.9に取り込んで試すことに。
gcは入れない。
いろいろやってみたが、 今よりも劇的に性能を改善できるものは無いため。
2/14にはCVSリポジトリにYARVブランチを取り込む。
でも、ささだくんが酔った上での発言だったらしいぞ。
個人的には非常に楽しかった。 他の皆さんも参加を後悔しないくらい楽しんでいただけただろうか。
メソッド定義の対象となるクラスを指すruby_classと、 定数参照の対象となるクラスを指すruby_cbase(その実態はruby_cref)は、 非常に似通っている。 というか、このふたつって本来は統一した方がわかりやすいんじゃないだろうか。 きっとユーザーもそれを期待してると思うし。
ということで、統一する。今回はruby_classを全削除して、 ruby_cbaseに置き換えることにする。
で、思い立ったら３０分で作業が終了してしまった。 今まで１０年以上これらスタックと格闘してきたのは一体なんだったんだろう。
というわけで、1.9ではスタックを３本削減。 残るは以下の５本。
これらも手を入れる余地はありそうな気がする。 たとえばprot_tagを一つ一つジャンプしながらチェーンするのではなく、 目的の場所までいっきにジャンプするとか。 ruby_dyna_varsをリンクではなく各レベルごとの配列にするとか。
昨日の高速化パッチは高速なんだけど、 どうやらN-GramのインデックスになっているBDBの更新に問題があるようで、 検索結果に大きな漏れがある。morqのようなタイプのメールリーダーでは 検索以外にメールに到達する方法が無いので、漏れは致命的だ。
しばらくソースを眺めてみたが、かなり大規模な修正で、 どこに問題があるのか発見することはできなかった。
しかたがない。このパッチは当面断念しよう。
で、パッチを当てる前のRastのソースを眺めてみる。 とりあえず遅いのはsyncする部分のようなので、そのへんを重点的に。
まず、明示的なfflush(3)とBDBのsyncはおそらく不要なので外すことにする。 stdioの方はfseek(3)を呼んでいるのでそのタイミングでflushされているはずだし、 BDBの方も明示的にsyncする理由はなさそうだ。BDB自身に任せた方が 賢いsyncをしてくれるだろう。
これでちょっとだけ速くなった。本当にちょっとだけど。
次にソースをよく読むと、データファイルの書き出しで、 各N-Gramごとにfseek+fread+fwriteを繰り返している。
デバッガで実行してみると、 syncの遅さはどうやらここに由来しているようだ。 プロファイラまで動かせると確実なんだが、 Rubyで書いてあるmorqからRast部分だけのプロファイルを取る良い方法を知らないのだ。
というわけで、 できればここをページ単位での書き出しにしたいところ。
だが、なかなか良いアイディアが思いつかない。
いっそ、現在の「BDBによるインデックス＋データファイル」という構成から 「全部QDBM」にしてしまうってのはどうだろうか(QDBMS好き)。
Curiaを使えば、データ容量の問題もさほどではなさそうに思うし、
素朴に要素ごとにfeek+read+writeするよりは、
(ページングしてるから)速度的にも、(圧縮してるから)容量的にも有利だと思うんだけど。
でも、確かRast設計段階でこのアイディアはボツにされたんだよな。 ま、単なる「上司の思いつき」だったので、その時は強くは出なかったんだけど。 自分が作業するわけじゃないから、当事者の意見の方が重要だしね。
でも、担当者が忙しい今のうちに、こっそり試してみるか*1。
はっ、...もう２月か。原稿の〆切が近づいているぞ。 もうちょっと先まで我慢したほうがよいか。
追記:
後でQDBMのソースを読んだら、DepotやCuriaはデータ圧縮してなかった。 容量的な利点は無いようだ。
教会の宣教師による英会話を手伝ってくる。
今日は「英語によるスキット」。我々の班(６名)は、 即興で「三匹の子豚」を演じたのだった。急だったわりには 全員ノリノリだったという。
確かに結構楽しかった。
降ってきたよ。7時前に帰宅したときには降ってなかったのに、 7時10分に英会話に出発しようとしたら、わずか２０分ほどで地面が真っ白になっていた。
明日の温泉は大丈夫かな。寒い方が風情が出るけど。
そして、明日こそは安来苑の温泉に入ろう。 古くからインターネット接続完備の温泉旅館として(知る人には)知られている 安来苑では過去数回宴会を行っているのだが、 私はいずれもハックに熱中していて、温泉に入りそこねているのだ。
明日こそは。明日の「Ruby温泉ミーティング」こそは。
今日になってからFirefoxを始めとするいろいろなプログラムが起動に失敗して core dumpするようになる。どうもフォントに問題があるらしい、と気がつくまで ずいぶんかかった。
strace付きでFirefoxを起動して、フォントファイルの読み込みあたりで落ちていることで ようやくわかった。その後、fc-cacheも落ちるので、これもstrace付きで実行させ、 原因がttf-arabeyesというTrueTypeフォントであることを突き止めた。
そういえば何日か前にdselectでチェックを入れたような気がする。
もともと不要だったので、さくっと削除。やっと通常通りに動作するようになった。 しかし、こんな問題が起きるようでは、まだまだ「コンピュータは難しすぎて使えない」ものだよなあ。普通の人がこんな問題に直面したら、対処しようがないじゃん。
答え: 「普通の人」はDebianを使いません。
ま、それは冗談としても。うちの妻のマシン(OSS貢献者賞でもらった日立のPrius)は、 ネットワークが接続しているのに、「サーバーが見当たりません」というエラーをしばしば出す。 どうやら、DNSがおかしいように思うのだが、ネットワークの仕組みはわかっていても、 Windows XPの仕組みがわからないので直しようがない。 ネットワークの「修復」を行うと再接続をして、一時的には状況は改善するのだが、 すぐに再発してしまう。
Debianでそんな問題起きたことがない(あるいは問題と意識する前に復旧できる)んだけどなあ。
*1 ここに書いたら全然「こっそり」じゃないなあ
_ ささだ [えーと、結局文法変わっちゃったんでしょうか。]
_ まつもと [「文法」は変わってませんね。parse.yには手を入れてないから。 あ、ruby_blockを消したときにNODE..]
_ mikio [DepotもCuriaもページ管理はせずに、個々のレコードの読み書きでlseek+read/readする方式です。 ..]
_ 通りすがり [似たような事が以前あり、最近もありました。 ~/.fonts.cache-1/ を消してログインし直したら戻りま..]
_ Ono [Priusのネットワーク関係のエラーは、単純にハードウェアの 故障じゃないでしょうか。 PriusのLANアダプ..]
Thinkpad入院中に全文検索データベースを壊してしまった(FAT32ファイルシステムだったのがいけなかったのかなぁ)ので、再構築しようと思ったが、 morqにたまった15万通のメールにインデックスを張ろうとすると、 いつまでたっても処理が終わらない。
業を煮やしてRastメーリングリストに流れていた高速化パッチを当てた。すると、今まで１通の処理に１秒くらいかかる上に、 syncのタイミングで数分から十数分も待たされていたのが、 １通あたりの処理は数十倍、sync待ち時間を数秒で済むようになった。
すばらしい。
これくらいスケールしないと大量データは扱えないだろう。
あーあ、出ちゃったよ。X41より軽くてX32よりパワフルなのが。
Intel Core Duoだってさ。バッテリーが公称で4.5時間はちょっと短いかも。 まあ、実際にはそんなにバッテリーが必要なことは滅多に無いんだけど。 でも、長いと飛行機の中とかで安心して作業ができるよね。
しかし、今のX31で不満があるわけではないので、 後1,2年はこれを愛用しようと思う。それからその時点での最新あたりを購入すればよいよね。 もう、日常生活に必要なCPUパワーは余ってるんだよね、きっと。
たぶん、それより前にディスク容量が足りなくなると思うが(今、40Gが80%)、 Thinkpadは簡単にディスク交換できるし。
ここまでCPUが高速になると、 これからはCPUパワーを消費するために 新しいアプリケーションが必要になるのではないだろうか。 たとえば、全文検索やインデクシング、自然言語処理などが考えられるけど、 本命はそんなに簡単に思いつかないものかもしれない。
現代の言語屋はもともとCPUをあまり消費しないタイプの人間だしね。
２巻まで読んだ時点であまりポジティブでない評価を書いた 『よくわかる現代魔法』だが、 気になったので既刊5巻まで読んでみた。
まあ、予想外の現れ方をする業界用語を楽しむという点では、 「にやり」くらいしかできないのだが、 最後まで読んでみたらストーリーが予想外に面白かった。うーむ。
いや、最初は「私が書いた方が面白いのでは」などという不遜な考えが頭をよぎった のだが、やはりプロの仕事を甘く見てはいけない。
ちなみに面白かった用語。
全部、ちょっと(あるいは全然)違った意味に使われているのがミソ。 あ、「TIMTOWTDI」だけは本来の意味のままか。 タイトルにしか使われなかったけど。
なお、Rubyは登場しません、残念ながら。JavaやCやPerlは出るのに。
Spam分類技術のためにSophosに買収されたActiveStateが、 本来の領域であるスクリプト言語の技術をベンチャーファンドに買われて、 Sophosから独立した、という話。
いや、暗澹たる言語ビジネスに一条の光明って感じですな。 Sophosの傘下にいたときもKomodoを開発したりと頑張りつづけたのが評価されたに違いない。
うんうん、よかった、よかった。
小飼さんも「オブジェクト指向プログラミングは構造がプログラミングの次」という点に 納得して下さったようだ。伝わってよかった。
「サブジェクト指向」なるどこかで聞いたタームが登場するのはまあご愛敬として。
しばしば耳にする「サブジェクト指向」は(「自己中すぎる」という小飼さんの指摘以外にも)、 メッセージセンドのフォーマットにこだわりすぎているような気がする。
たとえば、CLOSのマルチメソッドだったら「サブジェクト」は存在しないわけだが、 これが「オブジェクト指向ではない」というのはちょっと極端すぎるだろう。 あるいは、通常のメッセージセンド(or メソッド呼び出し)についても、 たしかにレシーバは特別な位置にあるが、それ以外の引数もやはりオブジェクトである点は 見逃してはいけないと思う。