Journal InTime

_ 引数なしのsuper

がHEADで使えなくなっててびびった。 一瞬自分が『引数なしのsuperはない方がsuper()と書かなくていいからうれしい』とか言ってたためかと思ったが、んなわけない。 define_methodで定義されたメソッドでsuperを呼ぶと落ちるバグの修正にミスがあったようだ。 何でも最近のRubyでは使われなくなっていたruby_frame->flagsを 使ったら0で初期化するのを忘れていたらしい。 テスト重要ですぞ。

_ machine readable commit mail

machine readableなcommit mailを用意しようと思うも、 形式に悩む。

候補は、今のところ、

• CIAの形式のXML
• svn log -v --xmlの形式のXML
• YAML

くらい。

最初は人間用もYAML一本にしようと思っていたが、to_yamlそのままの出力がいまいちなため分けることに。 つーか、svnなら楽なのに。

_ ゆうぞうさん歓迎会

のはずが、なぜか仕事の悩み相談大会に。

それはさておき、あんなまずいいくら丼初めて食べた。 ごはん食べていくら残すなんてありえないよね、普通。

_ COBOLとRails

あ、今、一瞬、21世紀のCOBOLerのRailerというのが脳裏をかすめたが気のせいだろう

[L'eclat des jours(2006-11-29)より引用]

ちょうどおとといに、宴席でCOBOLを引き合いに出してRailsの説明をしたりしてた。うーん、シンクロニシティ。

その時はある理由で話さなかったけど、COBOLとRailsの一番の違いは、COBOLにはアプリケーションプログラマに対する信頼をあまり感じないのだけど、Railsにはそれを感じるということ。 じゃなかったら、○○さん(適当に知っている人で置き換えてください)はRailsに手を出してないだろう。 Railsの規約は徹底的にプラグマティックなもので、プログラマを縛るためのものではない。

ひょっとしたら、みんなDHHに欺かれているのかもしれないけど("Constraints are liberating"なんていかにも洗脳用のフレーズっぽい)、今のところ自分はDHHの邪気のない笑顔を信用している。

追記:

何か読み返したらラブレターみたいで恥ずかしいな。 Rubyにも書いたことがないけど、もちろんRubyの方が好きですよ!

_ Joel SpolskyとPaul Graham

Joel SpolskyとPaul Grahamの文章にも同じようなことが言えるかもしれない。

_ Bruce Bouillet 復活

今頃気付いたわけですが、

伝説のRACER Xのギタリスト、ブルース・ブイエの参加も決定！

バンド解散以来初となる最強ギター・コンビが奇跡の復活！

[PAUL GILBERT -特別企画緊急大決定！-より引用]

ま、まじで?

_ Rails嫌い

昔からRubyに深くコミットしている人の中には、けっこうRailsに距離を置いているというか、はっきり嫌いって人もいる。

でもさー、やっぱり嫉妬というか妬みみたいなものもあるんじゃないかな。 「後から来てやりたい放題やりやがってー、みんな我慢してたのにー」みたいな。

で、自分が何でRailsを押しているかというと、嫉妬がないわけじゃなくて、むしろ他人より強いと思う。 だからこそ逆に、Symbol#to_procとかもあまり買ってないんだけど、「でもそれって純粋に論理的に判断してるんじゃなくて、嫉妬が判断を狂わせてるんじゃないか」と思ってしまって、はっきり嫌いとは書けないんだな。

でもそろそろ割り切って冷静に判断するようにしようと思う。自分だって結構やりたい放題やってたし。地味に。

とりあえず、returningはないと思う。 @content_for_layout→yieldも。 ってどっちもDHHじゃないか。

_ コンピュータアーキテクチャのエッセンス

以下の文章は翔泳社の「君のために選んだ1冊 ソフトウェア開発の名著」という企画のために書いたものだけど、ブログに公開してよいとのことだったので、たぶんWeb日記でもよいだろうと思って公開しておく。 今気付いたけど、これソフトウェア開発の本じゃないね。

コンピュータアーキテクチャのエッセンス (IT Architects Archiveシリーズ)

僕がはじめてコンピュータに触れたのは小学生の頃で、ファミコンが欲しいと言っていたら親父がHB-55というソニーのMSXマシンを買ってきたのがきっかけだった。ゲームをやりたい一心で、雑誌に付いていたBASICのプログラムを意味もわからずに打ち込んだものだ。その後、PC-9801を親父が買ったりもしたが、ゲーム機兼ワープロとしてしか使わず、プログラミングを再びはじめたのは大学に入って東芝のBREZZAというPCを買ってからだった。といっても、大学で計算機科学を勉強していたわけではなく、当時は理学部の数学科で、計算機センターのNeXTというかっこいいコンピュータを使ってMathematicaをいじっていたりはしたものの、授業でプログラミングをする機会はまったくなかった。せめてそのときに数学をもっとちゃんとやっていたら今ごろ役に立っていたかもしれないが、もともと物理学科を志望していたのに入試の点数が足りなくてあまり興味のなかった数学科に入ってしまったものだから、途中でついていけなくなって文学部哲学科に転部して、プログラミングに関係のあるようなことは大学では結局何一つ学ぶことがなかった。

というわけで、専ら趣味でRubyなどをいじっていたのだが、当時大変な不況で文学部哲学科の学生によい就職先などあるはずもなく（本当は就職活動もろくにしていなかったので、探せばあったのかもしれないが）、何となくプログラミングを仕事にすることになってしまった。

長々と説明してきたが、言いたかったのは、要は、僕は計算機科学の専門教育を受けずにプログラマになってしまったということである。このことはその後の僕の人生に大きく影を落としている…というのはちょっと大げさだが、計算機科学の常識を知らないために、しなくてもよい苦労をしたのは事実である。

最近では僕のようにちゃんとした勉強もせずに何となくプログラマになってしまう人も結構多いようで、「専門教育なんて受けなくてもプログラムはちゃんと書けるよ」というような声も聞く。たしかに書けることは書ける。でも本当に「ちゃんと」書けているだろうか。特に、Rubyのような高級言語によって独学でプログラミングを勉強すると、低レベルな（というのはもちろんハードウェア寄りのという意味だが）知識が不足しがちなように思われる。例えば、Rubyのメーリングリストでは、「浮動小数点数の演算結果が期待と違うがRubyのバグではないか」といった質問が跡を絶たない。

「コンピュータアーキテクチャのエッセンス」は、そんな計算機科学の専門教育を受けていないプログラマに薦めたい一冊である。本書は、元々大学のコンピュータシステム論の教科書として執筆された書籍だが、ハードウェア設計者を目指す学生向けではなく、プログラマ向けに、コンピュータアーキテクチャの基本概念を説明するために書かれている。そのためか、本書の「推薦の辞」にもあるように専門家からは色々と突っ込みどころもあるようだ。本書は、電圧と電流の話からはじまって、論理回路、データやプログラムの表現、プロセッサ、アセンブリ言語、メモリ、入出力、並列化といった概念をわずか400ページほどでまとめている。当然個々の内容は薄くなりがちで、本書だけ読んでもよくわからないところが多いかもしれないが、コンピュータの全体像を掴むためにはこれくらいコンパクトな方がよいのではないだろうか。

本書のテーマの一つは抽象化である。ソフトウェアから見ると、ハードウェアというのは具体的なものに見えるが、実際にはハードウェアもソフトウェア同様に抽象化の階層を成している。そのことは、本書でも繰り返し言及されている。本書の内容の多くはプログラミングに直接役に立つものものではないかもしれないが、それはこの抽象化の階層によって、上位レベルの議論では下位レベルの詳細を気にする必要がないからである。しかし、下位レベルの知識を知った上で、敢えて意識の外に一時的に追い出すのと、そもそも知らないのとでは大きく異なる。ぜひ、本書を手がかりとしてコンピュータアーキテクチャの基本概念を学んだ上で、必要に応じて抽象化の階層を自由に行き来できるようになっていただきたい。僕もあなたに負けないように、これからも勉強して行くつもりである。

後書き

ちゃんと翔泳社の本を選んだし、実は、訳者の一人の鈴木先生は数年前に島大に赴任された方で、笹田さんの知人である。 もちろん、そういった気遣いだけで選んだわけではなく、いい本だと思うので読んでみてください。

あと、浮動小数点数演算の誤差の話に触れたけど、本書ではあまり細かい記述はないので、予備知識なしでこの本だけ読んでも理解できないと思う。 そういうわけで、この本だけ読んで何かの役に立つことはあまりないかもしれないけど、まあそれが教養というものですよね。

_ 三瓶ツーリング

吉岡さん、山折さんと三瓶にツーリングに行ってきた。

ハンドルカバー装着のおかげで、途中まではそんなに寒くないなと思っていたけど、山の方の日陰は寒くてオーバーパンツを履いてなかったのを後悔した。

三瓶バーガーでベーコンバーガーを食べたけど、ずっと前に食べたのよりおいしかった気がする。空いてたせいかもしれない。