朝6時の飛行機に乗るために4時にホテルを出る。
行きにも使ったプロペラ機でまずバンクーバーへ。
そこでなぜか外に出されてしまう。普通トランジットは空港内にとどめておくものじゃないのか。 カナダの入国手続きはしてないんだけどなあ。このまま逃げちゃったらどうするつもりなんだろう。 しかも、国際線のゲートは空いてないし。いいのか、こんなおおらかなことで。
10時になってやっとゲートをくぐって出発待ち合いへ。そろそろおなかが空いてくるが、 気ままに食べていると後で体重に響くのが目に見えているのでぐっとがまん。 どうせ機内で食事は出るはずだし。 それにカナダドルを持っていないので、両替が面倒だし、食事みたいな小額でカード使いたくないし。
で、出発まで2時間以上あるのでPCを開く。ためしに無線LANカードを入れるとなんと接続するではないか。 嬉しい。インターネット接続がないと何もできないワタシ。
逆に接続さえあれば世界のどこででも同じように仕事ができるっていうのも、 ある意味ちょっとどうかしてるかも。
帰りの機種も行きと同じボーイング767。こんな小さい機体で太平洋を横断するってのもある意味すごいことだ。 空いていたので2席を占有して眠る。ぐー。
岡山で会議。途中、ひどい雷が鳴り、どしゃぶりになった。 金曜は松江がひどい天気だったが、山陰と山陽では時差があるのか。 松江と同様、すぐにやんだので被害を受けなかったけど。
いずれにしても今日で中国地方は梅雨明けだったらしい。
今日の収穫はミニトマトが９個。
しかし、気長に対応する必要があるものだな。 これだけのものを得るために何ヶ月もかけるなんて。 いや、あんまり手はかけてないけど、普段相手にしている ソフトウェアやらインターネットやらとは時間の流れ方が違うようだ。
ちょっと新鮮。
テーマは「ブロックと高階関数」。いや、「ブロックとクロージャ」の方がよいかな。 いずれにしてもRubyのブロックの力を紹介しようという試み。
ここまで「オブジェクト指向」、「継承」、「動的型」とやってきて、 急に対象のレベルが変化したような気がするが気にしない。
しかし、集中講義の準備に時間がとられて(いや、正確には気がとられて)、 なかなか進まない。だからといって講義の準備が進むかというとそうはならないのが不思議だ。 いや、逃避しているんだけど。
一昨日完成したRast対応morqのメールボックスに入っているメールに Rastのインデックスを付ける作業を行う。 現在900MBほどのメールを持っているのだが、 インデックスを付けるのが遅い遅い。このペースだと24時間くらいかかりそうだ。
一度全部インデックスを付けてしまえば、 あとはインクリメンタルだから気にならないんはずだけどね。
テーマは「ネットワークプロトコル」。 取り扱うのは主にアプリケーション層だが、 一応OSI7階層モデル(古いっ)から、 各レイヤーのプロトコルについても簡単に触れる。
が、いかんせん時間と余裕がなく、 なかなか進まないのだ。
余裕がないのは、今週の木曜と金曜に筑波大で集中講義をするから。
言語設計論に終始した昨年と比べ、 今年は実装よりの話をしようと考えていたのだが、 スライドを準備するうち、力尽きてしまった。
結局、2日あるうちの初日は昨年の使いまわしとなった。 いや、別に倫理上なんの問題もないのだが(元々昨年と全く同じ講義でも問題ないわけだし)、 当初の意気込みを実現できなかったのが残念だ。
学生さんたちゴメンよ。でも、今改めて考えると 実装オンリーだと難しすぎだったかも。
募集中である。〆切が近づいているな。
オープンソース啓蒙的にはわかりやすい記事かもしれないけど、 歴史認識に誤認があるような気がする。
ソフトウェアが独立したビジネスとしたのを 「Bill Gatesの公開書簡」からだと位置づけると AT&TがUNIXを公開した時期はそれよりも古いのでは。 それを
一昔前までのコンピュータ業界では、ソフトウェアを作成した会社が、そのソフトウェア製品を販売することにより利益を上げるという形態が一般的でした。
...
その後アメリカのAT&T（日本の電話会社に先駆けて分割された結果、今はソフトウェアを扱っていません）のベル研究所で「UNIX」というOS が開発され、教育機関などに対して非常に安価に、一般企業に対してもかなり安価にソースコードを公開しました。この結果、ソースコードに触れることができる開発者がソースコードを修正することによりUNIXがいろいろなコンピュータ上で動くようになり、世界中広く行き渡りました。
とまとめるのは、かなり事実と違う。 初期のUNIXのテープ配布は、むしろ当時の、開発したソフトウェアは 同じコンピュータのユーザ同士で共有するという、より古い慣習に従っていると思う。 それこそがRichard Stallmanが回帰を望んでやまない「幸せな世界」である。
あと、AT&Tは元々ソフトウェアをビジネスにすることを禁じられていたので、 分割によってソフトウェアを扱わなくなったわけではない、とか。
若い人が歴史を知らない、興味がないのは仕方がないけど、 「ソフトウェアビジネスありき」という姿勢では オープンソースの(というかフリーソフトウェアの)歴史を見誤りそう。
「ラボ」、はやってますねえ。
「ビジネスの閉塞感を打ち砕くため」や、 「将来に対する保険」、 「事業継続のために必要なイノベーション」などのために 「次の一手」を打ちたい事情はわかる。
が、過去に二度も名ばかりの「研究所」勤務だった経験からいうと、 ラボってかじ取り難しいよねえ。
技術者の言いなりだとビジネス的成果があげられないし、 経営者の言いなりだと技術的成果があげられないし。
本当は技術者にいろいろやらせて、その中からビジネス的価値のあるものを 拾い出して来るのが正統なんだろうけど、 技術者の評価という観点からも、事業的余裕って観点からも それが許される企業は少数のような。
ということは、零細企業では勝手連的な開発を黙認して そこから成果を吸い上げるって形になっちゃうのかな。
それなんてオープンソース？
後で読む。できるものなら英語読みたくない。
CでRails互換フレームワークを、という話ではなく、 本当にパフォーマンスが必要ならRubyInlineを使って、 Cコードを埋め込むことでパフォーマンス改善できるよ、という話。
このエントリの場合には2 reqs/secが21 reqs/secと10倍の改善が可能であったそうな。 もちろん、彼のアプリケーションがどのようなものであったのか分からないし、 おそらくはほとんどの場合にはRubyInlineまでは必要になることはないと思うのだけど、 もし本当に必要ならそういう手もあると知ってることは悪いことではないだろう。
なお、彼(Jared)は、この経験をもとにOSCONでUse C to Tune Your Rails Applicationというプレゼンを行うそうだ。
もうひとつ、Railsパフォーマンス改善テクニック。
Rails(というかActiveRecord)は、SQLを隠蔽しちゃうんで、 SQLのSELECT DISTINCTを実現するのに、たとえば
@distinctlist = Item.find(:all).map{ |i| i.fieldname }.uniq
なんてことをやっちゃうことがあるんだけど(あるの？ ありそう)、 実は、
Item.find(:all, :select => 'DISTINCT fieldname')
とやる方がずっと効率がいい。当たり前といえば当たり前だけど。 データベースのことはデータベースにやらせた方が(効率が)よい。
もっとも、それで生SQLばかり使うようになるのでは本末転倒だけど。
ならいっそActiveRecordなんて使わないでSQLをそのまま(でもRuby風に)使いたい、 というのがSequelである。
私はDBプログラミングの経験がないんで使い勝手とか想像してもよくわからないんだけど、 SQLの雰囲気がそのまま感じられるような気がする。 でも、せっかくだからfilterとかでなんでも文字列で渡すんじゃなくて もうちょっとメソッドに隠蔽(で、内部的にSQLを生成)するアプローチをとってくれた方が Ruby風味が高くて「おいしかった」かも。
PythonのSQLArchemyとかそんな感じなの？
Rubyでは31bitまでの整数は即値といってタグをつけてポインタ値に埋め込んでいる。 これはインタプリタ実装の基本的な最適化テクニックで、これによって 普段よく使う整数値の効率が非常に高くなっている。
一方、浮動小数点数はこのテクニックの対象外になるので、 小数ひとつひとつのためにオブジェクトが割り当てられ、 効率が非常に悪くなっている(大きな数Bignumも同様)。
で、リンク先はタグをつけて埋め込む技術を浮動小数点数に適用する方法について。
「値」が最低64ビットになってしまうというのは、ある意味デメリットであるが、 最近ではポインタ64ビットなアーキテクチャも増えてるし、 そろそろ現実的な選択肢になってきてるのかも。