最近読んだ VM の本 - steps to phantasien(2008-12-14)
少し前に "Virtual Machines: Versatile Platforms for Systems and Processes" という VM の教科書を読んだ. 今年は VM について知ったかぶりをする必要に迫られることが多く, 反省して付け焼刃をした次第. 言語処理系の VM の話を期待していたら XEN や VMWare 方面の VM の話が主で, 意表は突かれたものの面白かった. 速度を保ちながら仮想化という抽象を守るために コンパイラと OS の間の子が次々に曲芸を披露する健気さには心を打たれる. VM を使ってあげようという気になる一冊. 折良く Google から Native Client (NaCl) なんていう VM 技術の応用が公開されたことだし, これを肴に教科書の宣伝をするというのが今日の趣旨です. NaCl 自体の詳しい話は whitepaper や
Finagle - 都会育ちのメッセージングフレームワーク - Backnumbers: Steps to Phantasien
Scala でもやるかとぶつやく同僚を見て, たしかに Scala したいかも...などと意思の弱い私は気をそそられ, しかし特に書くものも思いつかずなんとなくウェブをぶらぶらしていた. そういえば Heroku が Scala をサポートしたニュースを読んだっけと検索すると, たしかにアナウンスがあった. このアナウンスにあるサンプルコードは面白い. Lift でも Play でもなく, Twitter の RPC フレームワークである Finagle が使われている. Finagle でサンプルを書いた理由の一つは画面におさまる簡潔さ, あとは流行り物の目新しさだろうけれど, Heroku の勧める Polyglot Platform の ありかたを示す意味もある気がしなくもない. Polyglot Polyglot という言葉を最初に目にしたのは プロダクティブプログラマ だったと思
最近もらった本: アジャイルサムライ - steps to phantasien(2011-09-13)
いただきました. ありがとうございます. そして読んでいるうちに, どうも自分はアジャイルへの興味が失せていると気付いた. さいわい "アジャイルサムライ" は良く書かれており 感想はもうウェブ上にたくさんあるようなのでここでは保留し, かわりになぜ自分の関心が失せたのかを説明してみたいと思う. 理由はだいたい二つある気がする. ひとつはしょうもない理由: 私の参加しているプロジェクトはとても大きく, 独自の開発スタイルをもっている. したっぱの自分はそのやり方に口を出す気がなかなかおきない. 時差があり英語も苦手(これはほんと情けなくて泣ける)だからなおさら乗り気でない. 変える気がないものへの関心は薄れる. 二つ目はもう少しマシな理由. 件のプロジェクトはそこそこアジャイル風になっている. おおよそ time-boxed にリリースがあるし, 開発者の自動テストもある. リファクタリン
地雷力 - steps to phantasien(2011-08-22)
地雷力のある人がいる. 簡単に直りそうなバグ, 一日で追加できそうな機能に手をつけたはずなのに, と当人はいう. バグがバグをよび, パッチがパッチをよび, 議論が議論をよんで, 目のまえに次々と刈るべき毛深いヤックが増えていく. そんな人がたまにいる. しかも話の流れでみつけてしまったバグをぜんぶ割り振られていたりする. 気の毒に...私が遠目にうかがうなかそのひとは毛を刈りだして, 刈るそばからバグや作業が次々と湧きだすけれど, しばらく経ってふと目をやるとあらかた片付いている. そして最後には歓声を耳にする: "おわった!" おめでとうと私は応じる. そのひとは次の仕事にとりかかかる, ああ, そのバグはやめておいた方が... けれどそのひとは動じない. いや一旦は動じるけれど, やれやれと仕事を再開する. そんな人には地雷力があるとおもう. 地雷体質, 羊毛フェチなど揶揄をこめるこ
心はさらわれるもの - steps to phantasien(2011-06-10)
購読しているブックマークからリンクされていた "一歩先行くJavaプログラマが読むべきオープンソースソフトウェア10選" という記事が面白かった. この人はだいぶ色々読んでいてすごい. Java には読むのに良いコードが色々あるものだと見直した. 私は推薦リストを作るには至れない. 本もコードも, 読んだ直後に気分が盛り上がって紹介することは時々あれど, お勧めするほどには自分の趣味や記憶を信じられていない. 私の読書/コード体験にはストックホルム症候群みたいなところがある; 苦労して何かを読んだあとはつい, こいつは必読/珠玉の一冊/ツリーだ! と思ってしまう. これを読んでないヤツは素人, なんて気分にすらなる. 友人も似たようなことを言っていたから, もしかしたらよくある気分なのかもしれない. そんな気分になったら, 私は架空の積読タワーに思いをめぐらせ, この山と積まれた本やツリー
近況 - "チームがよくなる" 感じについて - steps to phantasien(2009-12-31)
2009-12-31 近況 プログラマとしての成長が感じられない一年だった. 目先の仕事に気をとられ, 問題についてよく考える時間をとらなかった. 過労を言い訳に勉強もしなかった. 情けない. 一方で仕事のチームでは成長を感じることができた. せっかくだから, "チームがよくなる" 感じについて書いてみたいとおもう. 最近, 私のいるチームはコードレビューをするようになった. 私はこれまで仕事の中でコードレビューを実施しょうと試行錯誤してきたけれど, チームに定着することは少なかった. コードレビューはそれなりに面倒な作業なので, 特に組織的な外圧がないところではさぼられがちだと思う. けれど今のチームは外圧なしでやっている. およそ一年間のプロジェクトを通じ, このチームがコードレビューをするに至った道程を振り返ると, チームが成長する様子をうまく捉えることができるかもしれない. フェー
明日の空模様 - Backnumbers: Steps to Phantasien
ある Mac プログラマから "WebKit ってドキュメントがすくないよね" という話を聞いた. WebKit の挙動が気に入らないので直せないかと調べたところ, Mozilla と比較した文書の少なさに呆れたという. 私としては連載枠が貰えたのもひとえに文書がないおかげだから, そこに不満はない. (むしろめでたい.) けれどコードを直したい人が不便なのは困ったことだ. WebKit に比べ, Mozilla の内部は網羅的ではないにしろそれなりに文書化されている. この違いはどこから来るのだろう. 私の印象は, Mozilla が "書き直し" プロジェクトだからというものだった. Netscape は Netscape Natigator 4.x のコードベースを捨て, ほぼスクラッチから Gecko を書いたとされている. 私の仄暗い経験によれば, 書き直しのプロジェクトは最初に
Dehydra - Backnumbers: Steps to Phantasien
Mozilla を大書き換えする Mozilla2 プロジェクトの目標設定はえらく野心的で, 2004 年から話があるのに当分終わりそうにない. 傍目にそりゃ無理だろという目標も多い. XPCOMGC なんていかにも無謀だ. 参照カウントをやめて JavaScript と同じ GC を使おうぜという話. JS と C++ のオブジェクトが混ざっても平気だよ...と言われても困る. 数百万行ある Mozilla 相手にそんな書き換えを敢行するとは, ロケット科学を通りこして魔術的だと言っていい. それが無理だからこそ C++ は呪われた言語で, Microsoft も逃げだしたんじゃなかったの？ そんな外野の心配を他所に, Mozilla のプログラマ Benjamin Smedberg は Boehn GC と jemalloc くっつけたいんだけど良いアイデアない? なんて話をしている.
最近もらった本: インターフェイス指向設計 - steps to phantasien t(2008-07-21)
最近でもないですが頂きました. ありがとうございます > 関係者の方. 多忙にかまけて感想を書くのが遅れてしまいました. 遅れた理由はもう一つあって, 私はこの本の主張があまりピンとこなかった. でも貰った本のことを単にイマイチだったと書くのも社会人としてどうかなー, などとよたよたするうちに月日は流れ... 嘘や間違いはない. けれどアジャイルなオブジェクト指向設計という視点でみると, いまいち relevance を欠く気がする. この本を読んでまずい設計が良くなるのを期待できない自分がいる. 何でピンとこないのか, しばらく考えていた. どうも "インターフェイス" を中心に据えるのがまずいんじゃなかろうか. オブジェクト指向の設計を議論する上で, インターフェイスはツールの一つに過ぎない. "インターフェイス指向設計" という切り口は, 極端に言えば "クッキー指向ウェブアプリケー
ファクトリー ファクトリー ファクトリー API のユーザビリティテスト
前に 欲しいと書いた API のユーザビリティテスト. 実際にやってみたぜという話を読んだ. "The Factory Pattern in API Design: A Usability Evaluation (PDF)" という記事がそれ. 俎上に載ったのは factory パターン. 素のコンストラクタとどちらが使いやすいかを比べてみたという. そんなの, Factory が腐ってるだなんて Joel...じゃなくて Joel の読者も言っている. 実際この調査でも "factory は使いにくい" という思ったとおりの結論. 面白さはユーザビリティテストをした事実そのものにある. 調査では 12 人の被験者をあつめ, 5 つの課題をこなしてもらう. コードはぜんぶ Java. 課題1: メールを送信する. ライブラリを使ってこんな風に書けたらいいなと思うコードを notepad で
最近読んだ本: 市場を創る - バザールからネット取引まで - steps to phantasien t(2008-03-30)
表紙がすてきで買ったまま積読してたのを消化. とてもおもしろかった. 帯に "教科書が教えない<市場>の原理. 新しい時代の経済学入門" とあるとおりの 経済学読み物. イメージとしては経済学の教科書から ケーススタディのところだけを集めて一冊の本にしたかんじ. オランダの花市場から始まり, 製薬市場と途上国の対決, 電波オークション, 特許と著作権, ブラックマーケット, 排出権取引...と, 市場の設計を切り口に, 経済学の話がおなかいっぱい読める. 満腹満足. 色々面白かったのだけれど, 印象的だったところをひとつ抜粋してみよう: 企業は市場経済を眺望するときにもっとも目をひく存在である. ここにパラドックスがある. 企業はある種の集権的計画によって 運営されている存在だからである. 責任はすべて最終的にトップが引き受ける. 企業内の取引は, 市場ではなく, 階層的コントロールに従っ
steps to phantasien t(2008-03-16) C++ と Actor
頭が痛いだけでなく, 寝ている時に頭の傷を庇うせいか首がいたい. 鞭打ちかもしらんけど... そして頭とセットで打った臀部もいたい. 満身創痍で出かける気力もなく, 家でうだうだしているところ. こんなに良い天気なのになあ. うだうだついでに貰った本の紹介. 最近貰った本: プログラミング Erlang いただきました. ありがとうございます > 著者およびオーム社の中の方. Erlang の親玉が書いた入門書の翻訳です. Erlang は言語として特に斬新なところはなく, 処理系の提供するサービスの出来がいい, というのを伝聞で聞いていた. 読んでみるとたしかにそうだった. 本の内容も言語仕様(文法)の話は前半だけ. 後半は分散だとか並列の話をしている. 面白いのは後半. 私はお仕事の関係もあって分散メッセージングの仕組みには少し興味があったから, これはとても勉強になった. actor
コードと Communication - Backnumbers: Steps to Phantasien
Kent Beck の Implementation Patterns を読んだ. 薄いのがエライ. 内容は Java のイディオムをまとめたようなものだけれど, イディオムという言葉の印象ほどトリッキーなものは多くない. 凡庸なものだ. だからパターンなのだろう. 新鮮味のない, ある意味どうでもいい内容ではあったけれど, 逆にこりゃひどい, というものもあまり無い. 良いパターンと言えるのかもしれない. パターンといいつつパターン言語の様式に揃える様子がさらさら無いあたりは宗主の貫禄. そのせいでいまいち納得できない部分もあったけれど, 薄さとのトレードオフという気はする. 本編はさておき, 前書きと導入部はなかなか読ませる. Kent Beck は自身のプログラミング原則として, その一つ目に "Communication" を置いている. コードの可読性を高くしろ, と主張するのは
steps to phantasien t(2007-12-22) - 最近もらった本 : アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣
いただきました. ありがとうございます > 訳者のかたとオーム社の中のかた. 薄くまとまっているのは良いと思いました. あとはなにより訳が良いというのはアジャイル本では重要なのだと再認識しました. これは本を貰ったお世辞が二割くらいで八割本当. 私がこれまでに読んだアジャイルの本はなんというか lost in translation があり, アジャイル固有の良く言えば情熱的な, 悪くいえば宗教がかった迸りが失われていた. この本でも強調されているとおり, アジャイルの文脈では態度や感情の持ち方がそれなりの比率を占めている. それを伝える上で文体の果たす役割は大きい. 訳文はそうしたアジャイルのノリをうまくあらわしていると思う． 具体的な内容は, 私にとってはおおよそどこかで聞いた話だった. アジャイル関係の本はちょこちょこと読んでいるから当たり前かもしれない. 入門書として見た時の話題の
正規表現はお好き? - steps to phantasien
積んであった Beautiful Code を読んでみる. 第一章はカーニハンによる正規表現の話. 数十行のコードで簡単な正規表現を実装してみせる. パターン文字列を内部表現に変換せずマッチに使うぜ, コードも短い, ビューティホー! ...という主張なのだが, それはほんとにビューティホーなのか. UNIX 人の感覚にはついていけない. それにしても彼らは正規表現が好きだ. いつものその話ばかりしている. artu はいうまでもなく プログラミング作法 にも正規表現が出てきた. まったくこのマンネリめ. そう斜に構えつつ読み直してみると, 案外ラディカルな話も載っているのに気付く. 9.7 "オンザフライコンパイル" より: Ken Thompson はまさにこの方法によって 1967 年に IBM7094 上に正規表現を実装した. 彼のバージョンは, 正規表現に含まれる様々な処理を小さ
K のこと -- steps to phantasien t(2007-11-03)
友人の話をしよう. 先達に敬意を表し, 仮に彼を K と呼ぶ. (イニシャルは便宜的なものだ; 向上心云々と罵ったこともないし, 恋人を寝取ってもいない.) ある時期, 私は K と一緒に働いていた. 今は違う会社にいるけれど, 互いに暇なのか, このごろもよく二人で管を巻いている. 1 K は優秀なプログラマだ. いつも敵わないと思う. 一緒に仕事をしていたこともあり, プログラマとしての私は K から強い影響をうけている. たとえば私が自動テストを始めた発端には K がいる. コードレビューもそう. この日記に出てくる話も K の影響は色濃い. 私は K のあとを追いかけるようにプログラマを続けている. K と働いてはじめて, ああ, 物事とはこう改善していくものなのかと知った. 何か問題を感じると K は試行錯誤を始める. 問題は私が諦めていたものもあるし, そもそも気付かないものも
sparsetable - steps to phantasien t(2007-09-07)
Matz日記 で紹介されている google-sparsehash を眺めてみた. ひさびさに Google 気分. :~/src/sparsehash-0.8 omo$ wc `find src/google/ -type f` 253 1348 10336 src/google//dense_hash_map 237 1309 9884 src/google//dense_hash_set 238 1244 9616 src/google//sparse_hash_map 223 1214 9245 src/google//sparse_hash_set 919 4776 37957 src/google//sparsehash/densehashtable.h 42 189 1187 src/google//sparsehash/sparseconfig.h 884 4642 371
プロファイラのしくみ steps to phantasien t(2007-08-23)
UNIX 偏向文書 artu の中で "Measure Before Optimizing" と説く Raymond は, 同時にプロファイラの計測機構 (instrumentation) がもたらすノイズについて注意を促している. 私のプロファイラ信仰に不安が翳を落とす. gprof ノイズはさておき, そもそもプロファイラはどんな仕組みで速度を測っているんだろう. gprof のマニュアル によると, GNU 一族のプロファイラは次のように実装されている: まず "-pg" オプションつきの gcc でソースをコンパイルする. この指示を受けたコンパイラは各関数の冒頭に "mcount" という名前の関数呼出しを加える. リンクする C のランタイムも専用バージョン (gcrt0.o) に差し替わる. このランタイムは裏で profil() 関数を使いタイマを仕掛ける. そのタイマは発
C++ と DI - steps to phantasien t(2007-08-17)
Java と DI (Dependency Injection) の世界から C++ に戻ってくると気が滅入る. すべてがくっついている. ああ... "Working Effectively With Legacy Code" に従ってバリバリと依存を引き剥がすことになるんだけれど, もうウンザリ. せめて新たに書くコードはレガシー風味とさよならしたい. DI したい. C++ にも少しは DI コンテナの実装がある. Autumn Framework とか. ただリフレクションのない C++ では DI コンテナを使う有難味が薄い. Autumn Framework のチュートリアルを見ると無力感に襲われる. 閉じた型システムの再発明. C++ の限界もあるだろうから, あまり責める気は起きない. COM のような既存のオブジェクトシステムに DI を載せることはできるかもしれない.
最近読んだ本 - Backnumbers: Steps to Phantasien
だるい. 英辞郎によれば, 夏ばてを英語で "suffering from the summer heat" というらしい. 冷房負けは "suffering from the summer cool" かな ... 何もする気が起きない. 消去法で日記を書くことに. The Art Of Unix Programming を読んだ. (原書は オンライン版 もある.) 主題については良くかけており, 得るものも多かった. プログラミングというとクラスや関数がどうといったコードの話を想像するけれど, この本の重点はもう少し外側. プロセス同士の協調の仕方 (パイプとか) やファイルフォーマットの設計, コマインドライン・インターフェイスの流儀などについて詳しく説明している. Unix はプロセス同士の協調を好む. だからその繋ぎ方には気を使うんだろうね. Unix の歴史など文化的な話題に
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
