Author Archives: ueda

Visualization のコンテキストでたまに紹介されているのを見かける D3 ですが、Google Chart で対応できない本格的な Visualization が必要になったときに、D３についてまとまった本を読みたくて。多分、まだ日本語になっていないと思います。 オライリーらしい良書で、ちゃんと動くサンプルコードを確認しているとすぐに D3 の全体像と、自分のコーディングに必要な詳細が１日で理解できました。もっとも、D3自体がそんなに複雑なものでもないというか、そんなに単純でもないのですが、まあ名前しかしらない状態から１日で必要なコードが書けてしまうあたりにオライリーのありがたさをいつも感じます。

最近読んだ本ではなく昔よんだ本を整理してて懐かしくて ^^;;; ちなみに Kindle 版がそんなに安くなってないこともちょっと嬉しく 某社の某組み込みシステムを Linux Kernel 2.4 から 2.6 に上げる（外部のライブラリやドライバをほとんど使わないシステムだったので、そんな必要がどこにあったのか ^^;;;）際に、それに関係するトラブルの消耗戦にはまり込んだ際に泥縄で読んだ本です。その時、私はミドルウェア製品をみていたので被害の根本原因はむしろ kernel の変更より gcc のバージョンが 3.x 系から 4.x 系にあがったことによる振る舞いの変化でした。私は gcc の manpage を30 回ぐらい読み直し、あと発注元の開発環境チームで作成された500ページ近くある（さすが大企業！）移行ガイドラインも何度も読み直しながら、目の前で起きている不思議な現象に関係あるかもしれない事項を探していて、その際 1000ページくらいの量の、gcc のオプションや関連ツールについて詳細に記載してある本が読みたくなり、これは 580ページしかないのですがまあいいかと… アマゾンの日本語での書評はちょっと辛口で、「gcc を改造したいような人には情報不足かも」とか書かれてましたが、そういう目的ではなくて当時の私のように gcc に起因する（と思われる）超難解トラブルの対策目的には大変ありがたい本でした。 ちなみに書評者御本人も理解されてらっしゃるようで、コンパイラをいじろうかという目的の人だと本読んでも仕方ない旨を書かれていますが、全くその通りというか、もう４半世紀以上前のまだ私が新人で、自社計算機のためにCコンパイラを作るプロジェクトに配属され、当時日本語で（英語でも？）ほぼ唯一の教科書だったカーニハン・リッチーを読んでいて「そんなバカ本読んでてどうすんのよ！（言語仕様書よみなさいよ！）」と課長にしかられたのも懐かしい思いでです。その影響でいまだにエンジニアが机の上にバカ本置いてると、ちょっと小言をいいたくなってしまいます ^^;;; プロがそんな本読んでていいのか！読むにせよ少しは恥ずかしいという後ろめたさを感じた上で読め！そしたら机の上になんか置けなくて引き出しに隠す筈だ！って感じで。 大体、gcc はなかなか触りにくいコンパイラで、私事が続いて恐縮ですが私も静的解析の目的でコードの複雑度解析を、gcc のフロー解析の結果を流用して作ろうと思い立って触り始めて「これは触ると障りがある」と気づいて挫折した過去があります。そういう目的だと今だとみなさん中田先生の coins か、あとは LLVM をつかわれているんじゃないでしょうか。 ちなみに C や C++ は型システムが働くおかげか、普通のプログラマが普通に書いたコードは普通に動くのでありがたいのですが、一旦、その型システムさえも信用できないような事態に（たとえば gcc のバージョンアップ時に構造体のパディングの方式が変わる等）が起きてしまうと、もちろんコードを追っかけているだけではなにもわからず、デバッグしてもこっちでは正しい値がはいっているのにあっちではへんな値で、あれ、誰が壊したの？と、まったく不可解な現象になってしまい大惨事です。 こういう時はもう、コンパイラの仕組み、特にコードを生成する仮定の理解とその変更が及ぼす原因を理解した上で、呼び出し元や呼び出し先（これらは得てして他社分担だったりします）まであわせてデバッグできる強力な協力関係がないと問題が解決しません。泥縄な部分もたしかにありましたが、でもその時はこの本が枝葉の大きい gcc 全体を短時間で俯瞰する目的に大変役に立ちました。 私見ですが、こういう問題は、型がコンパイル時に決まってしまう静的な言語の、普段の便利さを裏返したいざとなったときの怖さでもあるように思います。動的な言語で、型がポインタではなくハッシュで表現されている場合、その解釈も実行時にきまるので、前述のような「構造体のパディング」の解釈が、そのライブラリが何時翻訳されたかで変わってしまうような、つまり実行時に解釈がバラバラになってしまうような問題も発生しないので。もっとも、REST API が型チェックもしてくれないで単に「エラーです」とだけ言ってる現状は逆の意味で困った問題だとおもうのですが。 とにかく知識を一気に大量に脳にインプットして、あふれかけた脳みそを振り回さないと問題解決のアイデアはでてこないですね。空の頭でいくら考えても禅問答のように抽象的になってしまいます。そういう目的で、この 580 ページは大変有益でした。Apendix B にでてくる FR-V とか NM102 とかの懐かしい石の名前もいまではとてもノスタルジックで（もしかしてまだどこかで現役の石でしたらごめんなさい）。