Scala でもやるかとぶつやく同僚を見て, たしかに Scala したいかも...などと意思の弱い私は気をそそられ, しかし特に書くものも思いつかずなんとなくウェブをぶらぶらしていた. そういえば Heroku が Scala をサポートしたニュースを読んだっけと検索すると, たしかにアナウンスがあった. このアナウンスにあるサンプルコードは面白い. Lift でも Play でもなく, Twitter の RPC フレームワークである Finagle が使われている. Finagle でサンプルを書いた理由の一つは画面におさまる簡潔さ, あとは流行り物の目新しさだろうけれど, Heroku の勧める Polyglot Platform の ありかたを示す意味もある気がしなくもない. Polyglot Polyglot という言葉を最初に目にしたのは プロダクティブプログラマ だったと思

ペーパードライバーにはヒマなエリアへ出張中. 各種中毒メディア群も数周して飽きたため, 前から読みたかった MongoDB でも調べよう...としたけれど, 思ったよりコードサイズがあるなあ. ちょっとだけ眺めて気を済まそう... ウェブっ子でない同士諸兄に説明しておくと, MongoDB は JSON のようなオブジェクトに 適当な ID を割り振り, その ID をキーに JSON (のようなもの)を検索できるようにした データベースのこと. ID 以外の JSON のフィールドにもインデクスをつけて 検索できるぶん便利な子だとされている. (教科書情報.) 今日は手始めに MongoDB 内の JSON 表現たる "BSON" を眺めた. MongoDB は, 自身が内部で使っている JSON 相当のデータ表現を BSON (Binary JSON) と呼び, あわよくば広く使っても

"わたしはじぶんのコードにうたえと命じた" と題して WEB+DB PRESS 総集編 に小話を 書かせていただきました. レビューしてくれたひとありがとう. 表題は モンキービジネス 14 号 に載っていた 柴田元幸訳 ディキンスン の "わたしはじぶんの魂にうたえと命じた" から. 小話はさておき, 私にとって一番面白かったのは...目次だった. 時代の移りかわりを感じられていい. 記事本体は古い方から読んでいくと楽しい. 私はふだんテクノロジの世代交代が進まないもどかしさを感じているけれど, JSP と ASP (ASP.NET ではなく) を説明した記事のおかげで 無事に滅びたテクノロジもそれなりにあったことを思いだした. そういえば SOAP もだいたい滅びたよね. 時代はちゃんと前にすすんでいる. めでたい. いま必要な新しいテクノロジーを調べるだけでなく 消えてしまったテクノ

いただきました. ありがとうございます. そして読んでいるうちに, どうも自分はアジャイルへの興味が失せていると気付いた. さいわい "アジャイルサムライ" は良く書かれており 感想はもうウェブ上にたくさんあるようなのでここでは保留し, かわりになぜ自分の関心が失せたのかを説明してみたいと思う. 理由はだいたい二つある気がする. ひとつはしょうもない理由: 私の参加しているプロジェクトはとても大きく, 独自の開発スタイルをもっている. したっぱの自分はそのやり方に口を出す気がなかなかおきない. 時差があり英語も苦手(これはほんと情けなくて泣ける)だからなおさら乗り気でない. 変える気がないものへの関心は薄れる. 二つ目はもう少しマシな理由. 件のプロジェクトはそこそこアジャイル風になっている. おおよそ time-boxed にリリースがあるし, 開発者の自動テストもある. リファクタリン

地雷力のある人がいる. 簡単に直りそうなバグ, 一日で追加できそうな機能に手をつけたはずなのに, と当人はいう. バグがバグをよび, パッチがパッチをよび, 議論が議論をよんで, 目のまえに次々と刈るべき毛深いヤックが増えていく. そんな人がたまにいる. しかも話の流れでみつけてしまったバグをぜんぶ割り振られていたりする. 気の毒に...私が遠目にうかがうなかそのひとは毛を刈りだして, 刈るそばからバグや作業が次々と湧きだすけれど, しばらく経ってふと目をやるとあらかた片付いている. そして最後には歓声を耳にする: "おわった!" おめでとうと私は応じる. そのひとは次の仕事にとりかかかる, ああ, そのバグはやめておいた方が... けれどそのひとは動じない. いや一旦は動じるけれど, やれやれと仕事を再開する. そんな人には地雷力があるとおもう. 地雷体質, 羊毛フェチなど揶揄をこめるこ

そんなわけで仕事の話を書いてみよう. どこかで誰かの名前を呼ぶとき, Twitter が @ で mention するように Google+ では "+名前" と書く. 人の名前の所は名字でもメールアドレスでも適当に補完してくれる. "+" の記法はきっとサービス名にちなんだのだろうけど, 以前からメールの中で使われてきた慣習でもある. 今の勤務先にやってきて, かつてよりだいぶ多くのメールを読むようになった. 以前は会社もチームも小さかったし分散開発でもなかったから, 一日の有効メール量は 10 通くらいだった気がする. 私は朝と晩の二回しかメールを読まなかったけれど, ほとんど支障はなかった. 今や私の Gmail は pin tab され, 一日 50 通くらい届くメールをさばいている. これは webkit-dev や chromium-dev, webkit-bugzilla (

購読しているブックマークからリンクされていた "一歩先行くJavaプログラマが読むべきオープンソースソフトウェア10選" という記事が面白かった. この人はだいぶ色々読んでいてすごい. Java には読むのに良いコードが色々あるものだと見直した. 私は推薦リストを作るには至れない. 本もコードも, 読んだ直後に気分が盛り上がって紹介することは時々あれど, お勧めするほどには自分の趣味や記憶を信じられていない. 私の読書/コード体験にはストックホルム症候群みたいなところがある; 苦労して何かを読んだあとはつい, こいつは必読/珠玉の一冊/ツリーだ! と思ってしまう. これを読んでないヤツは素人, なんて気分にすらなる. 友人も似たようなことを言っていたから, もしかしたらよくある気分なのかもしれない. そんな気分になったら, 私は架空の積読タワーに思いをめぐらせ, この山と積まれた本やツリー

最近コードを読んでない. リハビリしようと軽めのものを探し, Readability を眺めてみた. Readability はもともと Instapaper にヒントを得て 書かれたブックマークレットで, HTML ページの本文だけを抽出して見やすく表示する. Safari Reader の元ともなっており, 最近は 独立したサービス にもなった. Google Code でホストされているオープンソース版は実験ブックマークレット当時のもの. 2000 行くらい. 新しくはないけれど, 軽めのコードという趣旨にはあう. (私が Instapaper for Kindle ファンなのも Readability を読む気になった理由かもしれない. 本題と関係ないけど Instapaper はちいさい Kindle のキラーアプリだと思うんだよね.) 本文抽出 Readability の肝であ

そういえば先に紹介した本のサンプルコードは 前勤務先が開発していたライブラリを使っている. そんなのがあったなと思いだした. 開発元の会社は私が退職したあと解散してしまい, 製品としてのライブラリもなくなってしまったようだ. 少しはバグとりなどを手伝った身として一抹のさびしさがある. 今は亡きこのライブラリを偲んでみたい. それは C(v1.x)/C++(v2.x) で書かれたノンブロッキングスタイルの通信ライブラリで, libevent に類する イベントシステムと IO を抽象化するレイヤの上に バッファ管理, フレーミング, 多重化, 暗号化, 圧縮, UDP ベースのストリーム実装 と hole punching を実装し, 簡単な RPC もついていた. そのほかにも経路の heartbeat や素朴なリマッピング, 簡易チート対策, 高負荷な暗号化や圧縮だけを別プロセスに切り離

オンラインゲームを支える技術 をいただきました. ありがとうございます. どこかで聞いた割と当たり前の話ばかり...なのは当たり前で, 著者は私が前に勤めていた会社のボス. 仕事で相談した時のアドバイス, 各種レクチャー, 雑談/議論, 社内の blog や Wiki で見聞きした話がまとまっている. デジャブ感はないとおかしい. 目次は 出版社の書籍案内ページ に詳しい. 広いトピックを網羅して情報量はすごい. 逆にそれが祟って見通しが下がり, 説明も散漫になりがちのは残念だった. とはいえ 3 章の "オンラインゲームのアーキテクチャ" は割とよくまとまっている. あとは 4,5,6 章の疑似ケーススタディの中など各所で性能評価を扱っている部分が面白かった. 仕事のはじめに "こんな感じで作ろうと思う" とボスに話をすると, まず聞かれるのが性能, 特に帯域の見積りと遅延だった. ボス

ついに家にも来た！「輪番停電の作業のためおうかがいしました。」とピンポンする人たち。 インターホンの画面に映ったのは深々と帽子被った男数人。 でも耳たぶにたくさんのピアス見えた。作業があるなんて市役所から連絡ないし。 この手口で家に入られそうになる人多いらしい。みなさんも気をつけて！ 巷で噂になっているような Twitter デマ情報や怪談の類が届かず 寂しい思いをしている私を気遣ってか, following の一人が新しいのを一つ retweet してくれた. ありがとう. この怪談はいくつかの点でよく書けている. なんといってもつかみがいい. ついに家にも来た! 前例を仄めかし, 読み手に自分の知らない流行があったと焦らせる煽りがバズに初速を与える. 伝聞ではない当事者の語り口が retweet の敷居を下げる. 体験談でありながら同時に後半の伝聞パート この手口で... を補強してい

ウェブをみていたらこんな風に書いているページがあった. WebKitは、現在も改良が加えられ、日々「現在開発中のWebKit」が開発者や先端ユーザー向けに提供されています。 ある程度、安定した機能を次のリリース用として仕様を固めたバージョンが、開発中バージョンとは別に作られ、一般ユーザーにも使えるよう、バグが少ない安定したコードになるまでデバッグが繰り返されます。 そして安定したバージョンを、各ソフトウェア提供企業が採用して、製品に使われるようになるのです。 この説明に間違いは無いと思うけれど, たぶん読んだ人の印象と実体は少し違うと思う. このズレに実害は無いと知りつつ, いい機会なので WebKit のリリースについて私の理解を説明してみたいとおもう. 最近 webkit-dev メーリングリストに "Best way to track feature evolution from r

「プログラマが知るべき 97 のこと」 日本語版のエクストラとしてちょこっと書かせてもらいました. エッセイ集のような本で, 読切 Blog 記事一気読み, みたいなノリで読めます. ソフトウェアアーキテクトが知るべき(同上) の続編というかんじですが, アーキテクトもプログラマも大差ないので片方読んで面白かったらもう一方も楽しめると思います. (両方に書いてる人もいます...) 一編 2 ページくらいの長さに揃っているので割と読み易い一方, 私のようにぐだぐだ長々と書く傾向の人間が書くと ややあっさりしてしまう気がした. ここで続きをちょっと書きたい. パッチのなやみ 私が書いたのは, "良いコード" と "良いパッチ" はときどき相反することがあるからどうしましょうね, という話だった. 良いコードはさておき良いパッチとはどんなものだろう. という話は本を買っていただきたくおもいますが

(最近はうそです. もらってから半年くらいたってます....) プロジェクト管理の本だった. 見積りの話も丁寧に書かれている. プロジェクト管理の二本柱(PMBOK による) "計画" と "監視制御" のうち, "計画" に占めるソフトウェア開発固有な部分は見積りくらいだから, 当然といえば当然かも. 前半 2/3 が計画(=見積り), 後半 1/3 が監視制御の話. 顧客に見積りや計画を求められる管理職には読んでおいて欲しい気がしたけれど, 管理職が読むのを期待するよりは自分で読んで見積りができるようにしておく方が たぶん現実的だし, 本書の趣旨にもあっていると思う. 本書の前半で説明されている見積りについて言えば, 規律にうるさい マコネルの見積り と比べ 実施の敷居は低い気がするので, まずはこのコーン式見積りをやってみるのが良さそう. 私のいるチームも planning poke

同僚の生産性ツール愛好家が熱に浮かされて言った. "QuickSilver の検索がすごいんだよ!" どう凄いのかというと, たとえば "Skype を検索するのに <sp> でいい!" らしい. それは凄いのかも. 私もいちおう QuickSilver を使っているけれど, 素敵機能の類はまったく活用していない. だいたい私の使うアプリケーションはどれも一文字で特定できる. Firefox, Emacs, iTerm, Activity Monitor... そういえば iTunes は iTerm と被ってる. ためしに <iu> と打ってみたら iTunes にマッチする. なんとなく凄い気がしてきた. 同僚はこのアルゴリズムが気になるらしい. 編集距離の仲間かとも思ったけれど, 違う気がする. とりあえずぐぐってみたところ, QuickSilver は 2007 年に オープンソー

最近は過労気味でウェブにものを書くこともできない, という話で上司の同情を誘うべく 日本人の労働時間やストレスの実態をまとめた エンドレス・ワーカーズ を読んだら, 自分の労働時間は日本人労働者の上位 2 割から漏れていることを知り愕然とした. あんなに働いたってのに...残業エリートへの道は険しい. 道を進みたいわけじゃないけれど. (平均は越えてたぜ!) いずれにせよ流行からはすっかり脱落しているので, 時流を無視して仕事の話でもしよう. 以前, 会社の blog で RPC の結果をノンブロッキングスタイルで受け取るプリミティブ "弱関数" を提案した. でも試行錯誤の結果, いまは使っていない. C++ での弱参照は意図しないリークを作りやすい. 使いわすれることも多く, 忘れた頃にクラッシュする. 要求は明示的にキャンセルした方がいいことがわかった. (世間はみんなそうやってます

ある Mac プログラマから "WebKit ってドキュメントがすくないよね" という話を聞いた. WebKit の挙動が気に入らないので直せないかと調べたところ, Mozilla と比較した文書の少なさに呆れたという. 私としては連載枠が貰えたのもひとえに文書がないおかげだから, そこに不満はない. (むしろめでたい.) けれどコードを直したい人が不便なのは困ったことだ. WebKit に比べ, Mozilla の内部は網羅的ではないにしろそれなりに文書化されている. この違いはどこから来るのだろう. 私の印象は, Mozilla が "書き直し" プロジェクトだからというものだった. Netscape は Netscape Natigator 4.x のコードベースを捨て, ほぼスクラッチから Gecko を書いたとされている. 私の仄暗い経験によれば, 書き直しのプロジェクトは最初に

PC は忙しい時ほど壊れる. 先週は職場の PC にこの経験則が降りかかった. 頻繁にフリーズしはじめる VisualStudio 2008. VS 単体での修復では問題が直らず困り果て, 結局 OS から入れ直す羽目に. まあディスクが故障しなかっただけ幸いだと思おう... OS の入れ直しは生活習慣を見直し悪習を捨てる機会でもある. 私の Windows 生活で最大の悪習は cygwin だ. ホスト OS への敬意を欠く cygwin には以前から後ろめたさを感じていたが, 惰性でずるずると使い続けていた. 今回のトラブルは良き市民たれという神(シアトル在住)の思し召しかもしれない. 啓示に耳を傾け, しばらく cygwin なしでがんばってみたい. PowerShell cygwin を捨てるということはシェルを乗り換えるということだ. いま Windows 民の間でホットなシェル

"Above the Clouds: A Berkeley View of Cloud Computing" を読んだ. UC Berkley の RAD Lab が書いたクラウドのまとめ記事. RAD Lab は今時の分散システムを相手にした研究室で, スポンサーも Google, Sun, Microsoft といった分散システム持ちの大企業が名を連ねている. 研究員に David Patterson (パタヘネのパタ) が入っているあたりからも読み物への期待は高い. 実際よく書けていた. 私が読んだクラウド読み物の中ではいちばんくっきりしていたと思う. 記事ではクラウドを "公共設備としての計算機" という長年の夢の延長と位置付けた上で, その新規性や利点, 可能性を概観する. そして現存するクラウドサービスを計算モデルの抽象度に応じて分類し, 更にコストモデルの検討, クラウド普及

ThoughtWorks アンソロジー を読んでいたら Ruby を使った DSL の話が載っており, 仕事でうっかり Ruby DSL を作ってしまった私は興味深く読んだ. 特段目新しい話じゃないものの, (DSL と言えば聞こえはいいけれど要は設定ファイルですからね.) オレオレ DSL を作る際には "Martin Fowler もやっている" と言えば 説得力もあるってもんだろう. 説得力はさておき, Martin Fowler は私の DSL が抱える問題に答えてくれなかった. 最近の私は Ruby DSL の文書化に困っている. その DSL/設定ファイル はもともと余興にちまちま作っていたもので, 思ったより出来がよくなったため実プロジェクトで使いはじめたところだった. ちゃんと使ってみると案の定ぼろぼろと問題がでて, 後始末のために残業が続いている. まあドッグフードの自業