WEB+DB PRESS 総集編 / I told my code to sing - steps to phantasien(2011-10-15)
"わたしはじぶんのコードにうたえと命じた" と題して WEB+DB PRESS 総集編 に小話を 書かせていただきました. レビューしてくれたひとありがとう. 表題は モンキービジネス 14 号 に載っていた 柴田元幸訳 ディキンスン の "わたしはじぶんの魂にうたえと命じた" から. 小話はさておき, 私にとって一番面白かったのは...目次だった. 時代の移りかわりを感じられていい. 記事本体は古い方から読んでいくと楽しい. 私はふだんテクノロジの世代交代が進まないもどかしさを感じているけれど, JSP と ASP (ASP.NET ではなく) を説明した記事のおかげで 無事に滅びたテクノロジもそれなりにあったことを思いだした. そういえば SOAP もだいたい滅びたよね. 時代はちゃんと前にすすんでいる. めでたい. いま必要な新しいテクノロジーを調べるだけでなく 消えてしまったテクノ
心はさらわれるもの - steps to phantasien(2011-06-10)
購読しているブックマークからリンクされていた "一歩先行くJavaプログラマが読むべきオープンソースソフトウェア10選" という記事が面白かった. この人はだいぶ色々読んでいてすごい. Java には読むのに良いコードが色々あるものだと見直した. 私は推薦リストを作るには至れない. 本もコードも, 読んだ直後に気分が盛り上がって紹介することは時々あれど, お勧めするほどには自分の趣味や記憶を信じられていない. 私の読書/コード体験にはストックホルム症候群みたいなところがある; 苦労して何かを読んだあとはつい, こいつは必読/珠玉の一冊/ツリーだ! と思ってしまう. これを読んでないヤツは素人, なんて気分にすらなる. 友人も似たようなことを言っていたから, もしかしたらよくある気分なのかもしれない. そんな気分になったら, 私は架空の積読タワーに思いをめぐらせ, この山と積まれた本やツリー
Clang のコード補完 - Backnumbers: Steps to Phantasien
Clang のツリーを眺めていたら, "clang-completion-mode.el" というファイルがあった. clang のプログラムを呼び出してコード補完ができるらしい. (使いかたを説明してくれている人もいた.) 以前読んだ時 は気付かなかったけど, 二年前からあったようだ. こんなものがプラグインで書けてしまうなんてさすがモダンなコンパイラは違うなーインデクスはどうするのかなーと 感心しつつコードを見ていたらインデクスのような前処理はないようす. それに全然プラグインじゃない. Clang 組み込みの機能として実装されていた. 以前から Xcode(4) がどんな風に Clang を統合するのか気になっていた. コード補完はそうした取り組みの一環かもしれない. 高々 Emacs のため Clang 組込みの機能を増やすとも思えないからね. というわけでざっとコードを眺めてみよ
ピンポン怪談と Conjunction fallacy : steps to phantasien(2011-03-14)
ついに家にも来た！「輪番停電の作業のためおうかがいしました。」とピンポンする人たち。 インターホンの画面に映ったのは深々と帽子被った男数人。 でも耳たぶにたくさんのピアス見えた。作業があるなんて市役所から連絡ないし。 この手口で家に入られそうになる人多いらしい。みなさんも気をつけて！ 巷で噂になっているような Twitter デマ情報や怪談の類が届かず 寂しい思いをしている私を気遣ってか, following の一人が新しいのを一つ retweet してくれた. ありがとう. この怪談はいくつかの点でよく書けている. なんといってもつかみがいい. ついに家にも来た! 前例を仄めかし, 読み手に自分の知らない流行があったと焦らせる煽りがバズに初速を与える. 伝聞ではない当事者の語り口が retweet の敷居を下げる. 体験談でありながら同時に後半の伝聞パート この手口で... を補強してい
はじめての Chromium Land - steps to phantasien(2011-02-19)
はじめてまじめに ...といってもたぶん 500 行くらい... WebKit ではなく Chromium 側のコードを書いている. まだレビューをとおってないため現在形. でかすぎてビルドの遅い Chromium より Mac WebKit をいじる方が快適という同僚もいたけれど, コード自体は Chromium の方がだいぶモダンだよなあ. 普通に unit test が書けるありがたさといったらない. Developer testing まず gtest が良くできていて感心する. static initializer を使ってケースの登録を分散化したり, コマンドラインフラグでテストケースを一覧選別できたり, プロセスを分離してクラッシュに強くしたり, クラッシュしたテストケースの backtrace をだしたり. でかい C++ のコードベース相手にテストをスケールするための工夫
プログラマが知るべき 97 のこと - Backnumbers: Steps to Phantasien
「プログラマが知るべき 97 のこと」 日本語版のエクストラとしてちょこっと書かせてもらいました. エッセイ集のような本で, 読切 Blog 記事一気読み, みたいなノリで読めます. ソフトウェアアーキテクトが知るべき(同上) の続編というかんじですが, アーキテクトもプログラマも大差ないので片方読んで面白かったらもう一方も楽しめると思います. (両方に書いてる人もいます...) 一編 2 ページくらいの長さに揃っているので割と読み易い一方, 私のようにぐだぐだ長々と書く傾向の人間が書くと ややあっさりしてしまう気がした. ここで続きをちょっと書きたい. パッチのなやみ 私が書いたのは, "良いコード" と "良いパッチ" はときどき相反することがあるからどうしましょうね, という話だった. 良いコードはさておき良いパッチとはどんなものだろう. という話は本を買っていただきたくおもいますが
Communications of ACM - steps to phantasien(2010-01-04)
年始は食べものの調達が億劫で, 大鍋にカレーを作り三日三晩食べ続けた. 量が多過ぎたので最後の夜は友人 M に助けを求めた. 鍋を空にすべくたらふく食べたあと土産にもらったチャイをすすりふと見ると, やはり腹ごなしに本棚を物色していた M が CACM の山に目をとめていた. CACM: Communications of ACM は, 米国のコンピュータ学会(ACM)が発行する月刊の会誌. 昔々はこれに論文を載せるのが計算機科学者のステータスだった, らしい. たとえば "Goto statement considered harmful" に 続く一連の論争は CACM の投稿欄で行なわれた. ダイクストラがジャンプ放送局に出てくる雑誌を想像してほしい. もうちょっとマシな例だと Quicksort なんかも CACM が初出のよう. 最近は分野の細分化が進み, CACM で最先端の研
近況 - "チームがよくなる" 感じについて - steps to phantasien(2009-12-31)
2009-12-31 近況 プログラマとしての成長が感じられない一年だった. 目先の仕事に気をとられ, 問題についてよく考える時間をとらなかった. 過労を言い訳に勉強もしなかった. 情けない. 一方で仕事のチームでは成長を感じることができた. せっかくだから, "チームがよくなる" 感じについて書いてみたいとおもう. 最近, 私のいるチームはコードレビューをするようになった. 私はこれまで仕事の中でコードレビューを実施しょうと試行錯誤してきたけれど, チームに定着することは少なかった. コードレビューはそれなりに面倒な作業なので, 特に組織的な外圧がないところではさぼられがちだと思う. けれど今のチームは外圧なしでやっている. およそ一年間のプロジェクトを通じ, このチームがコードレビューをするに至った道程を振り返ると, チームが成長する様子をうまく捉えることができるかもしれない. フェー
八割の動詞 - Backnumbers: Steps to Phantasien
PC は忙しい時ほど壊れる. 先週は職場の PC にこの経験則が降りかかった. 頻繁にフリーズしはじめる VisualStudio 2008. VS 単体での修復では問題が直らず困り果て, 結局 OS から入れ直す羽目に. まあディスクが故障しなかっただけ幸いだと思おう... OS の入れ直しは生活習慣を見直し悪習を捨てる機会でもある. 私の Windows 生活で最大の悪習は cygwin だ. ホスト OS への敬意を欠く cygwin には以前から後ろめたさを感じていたが, 惰性でずるずると使い続けていた. 今回のトラブルは良き市民たれという神(シアトル在住)の思し召しかもしれない. 啓示に耳を傾け, しばらく cygwin なしでがんばってみたい. PowerShell cygwin を捨てるということはシェルを乗り換えるということだ. いま Windows 民の間でホットなシェル
steps to phantasien(2009-02-14) - ハードディスクに耳をすませば
"Above the Clouds: A Berkeley View of Cloud Computing" を読んだ. UC Berkley の RAD Lab が書いたクラウドのまとめ記事. RAD Lab は今時の分散システムを相手にした研究室で, スポンサーも Google, Sun, Microsoft といった分散システム持ちの大企業が名を連ねている. 研究員に David Patterson (パタヘネのパタ) が入っているあたりからも読み物への期待は高い. 実際よく書けていた. 私が読んだクラウド読み物の中ではいちばんくっきりしていたと思う. 記事ではクラウドを "公共設備としての計算機" という長年の夢の延長と位置付けた上で, その新規性や利点, 可能性を概観する. そして現存するクラウドサービスを計算モデルの抽象度に応じて分類し, 更にコストモデルの検討, クラウド普及
steps to phantasien(2008-11-21)
The Decline and Fall of Agile を訳してみました. 例のごとく YukiWiki におかせてもらってます. 最近は短いのしか訳す根性がない... Agile 批判はよくあるけれど, これは割と良い指摘をしている気がした. 耳の痛い部分もある. たしかに日次のスプリントと月次の再計画は割と簡単に導入できて, チームも締まったかんじになる. けれどコードがよくなるわけじゃない. 一方で, この二つの trivial なプラクティスを取り込んだところで, 何かが悪化することはどのくらいあるんだろうか. 元記事の文脈を察するに, もともと重量プロセスがあったところに agile を持ちこみ, upfront の設計や計画がなくなって破綻したという話に思える. 数十人, 数百人のチームでソフトウェアを開発するプロジェクトには, おそらく何らかのプロセス, 秩序があるだろう
Dehydra - Backnumbers: Steps to Phantasien
Mozilla を大書き換えする Mozilla2 プロジェクトの目標設定はえらく野心的で, 2004 年から話があるのに当分終わりそうにない. 傍目にそりゃ無理だろという目標も多い. XPCOMGC なんていかにも無謀だ. 参照カウントをやめて JavaScript と同じ GC を使おうぜという話. JS と C++ のオブジェクトが混ざっても平気だよ...と言われても困る. 数百万行ある Mozilla 相手にそんな書き換えを敢行するとは, ロケット科学を通りこして魔術的だと言っていい. それが無理だからこそ C++ は呪われた言語で, Microsoft も逃げだしたんじゃなかったの？ そんな外野の心配を他所に, Mozilla のプログラマ Benjamin Smedberg は Boehn GC と jemalloc くっつけたいんだけど良いアイデアない? なんて話をしている.
Tamarin での文字列 - steps to phantasien(2008-08-31)
2008-08-31 近況 LL Future というイベントに呼んで頂き, 中野へ. 前日の激しい雷で眠りが浅く寝坊したら, 基調講演は Larry Wall だったらしい. 聞き逃した. なんてこったい... そしてサインを貰う準備もしていなかった. 昼飯を食べる暇があったら紀伊国屋に駆けこむんだったといまだに後悔している. おしいことをした. 宴会でゴルフ場経営者に見せてもらった サイン実物はとても気が利いたもので, まったくうらやましい. 彼の本は年季が入った版の上にかなり読みこまれた形跡があったので, Larry Wall も嬉しかったことだろうな. 私もいつか実現するであろう Stroustrup の来日に向け, 件の本を読み込んでおかねばなるまい. パネルの内容は shibuya.js 番外編というかんじで, JS や ActionScript の上で実装した処理系の紹介を中
Protocol Buffersのソースを読んでみる
2008-07-12 近況 新刊が多く慌しい. 谷川史子の "草の上星の下", 岩本ナオの "町でうわさの天狗の子", あとは Google の "Protocol Buffers". 谷川史子の洗練を綴るには余白が狭過ぎる. かわりに Protocol Buffers の話をすこし. Protocol Buffers (以下 protobuf) は Google 製のオブジェクトシリアライザ. 名前からは RPC を連想しそうだけれど, RPC そのものではない. もっともオブジェクトを直列化して送受信するのが RPC だから, あとは送受信だけあればいい. 実装は含まれないものの, protobuf にも RPC を前提としたインターフェイスがいくつか含まれている. ...といった細かい話は ドキュメント や インタビュー を見ればわかる. 今日はコードを見てみることに. なお, 例の
プロファイラのしくみ steps to phantasien t(2007-08-23)
UNIX 偏向文書 artu の中で "Measure Before Optimizing" と説く Raymond は, 同時にプロファイラの計測機構 (instrumentation) がもたらすノイズについて注意を促している. 私のプロファイラ信仰に不安が翳を落とす. gprof ノイズはさておき, そもそもプロファイラはどんな仕組みで速度を測っているんだろう. gprof のマニュアル によると, GNU 一族のプロファイラは次のように実装されている: まず "-pg" オプションつきの gcc でソースをコンパイルする. この指示を受けたコンパイラは各関数の冒頭に "mcount" という名前の関数呼出しを加える. リンクする C のランタイムも専用バージョン (gcrt0.o) に差し替わる. このランタイムは裏で profil() 関数を使いタイマを仕掛ける. そのタイマは発
ファクトリー ファクトリー ファクトリー 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-04-02)
社会人になって最初に配属されたチームのコードはひどいもので, 私は同期の新入社員仲間 Y に "ひどいコードなんだ. あの先輩はろくでもない." と愚痴た. すると Y はぽつりとこう答えた. "<コードを憎んで人を憎まず> だよ." Y の言葉は私の座右の銘となった. コードと人格を切り離す. あたりまえの事に思えるけれど, いまより輪をかけて狭量だった私はひどいコードの書き手を見下していた. もちろん自分は棚にあげて. たかがコードで友情や信頼を失うのは愚かなことだ. Y はそう言うのだった. 件の先輩社員は寛大だった. 私は勢いと趣味に任せて彼のコードを書き換えていたが, 彼は文句もいわず, 雑用を押し付けてくることもなく, 他所からのメールやバグを黙々と片付けていた. 私が同じ立場なら, 間違いなく戦いの火蓋を切っていただろう. (実際, 翌年の私は毎日のように後輩と口論していた.
K のこと -- steps to phantasien t(2007-11-03)
友人の話をしよう. 先達に敬意を表し, 仮に彼を K と呼ぶ. (イニシャルは便宜的なものだ; 向上心云々と罵ったこともないし, 恋人を寝取ってもいない.) ある時期, 私は K と一緒に働いていた. 今は違う会社にいるけれど, 互いに暇なのか, このごろもよく二人で管を巻いている. 1 K は優秀なプログラマだ. いつも敵わないと思う. 一緒に仕事をしていたこともあり, プログラマとしての私は K から強い影響をうけている. たとえば私が自動テストを始めた発端には K がいる. コードレビューもそう. この日記に出てくる話も K の影響は色濃い. 私は K のあとを追いかけるようにプログラマを続けている. K と働いてはじめて, ああ, 物事とはこう改善していくものなのかと知った. 何か問題を感じると K は試行錯誤を始める. 問題は私が諦めていたものもあるし, そもそも気付かないものも
設計文書のうまい書き方 steps to phantasien t(2007-09-24)
訳して YukiWiki に置きました. 元は "How to Write an Effective Design Document". 友達が "最近, プロジェクトで設計仕様書を作ろうって話が..." と悩んでいた. そりゃ大変だねえと相槌をうち, 相槌ついでにぐぐっていたらみつけた記事. <design document> や <designdoc> と検索すれば ガイドラインだけでなく実物もじゃんじゃかみつかる. 玉石混交で面白い. 設計仕様書と聞くと, 設計する人と実装する人が異るような大規模開発をまず連想する. そっちの世界で文書が必要なのはわかるが, 一方で私は大規模開発をしたいと思わないし, 興味も湧かない. 元の記事も私の友達もそんな大規模開発を想定していない. 文書化した本人が実装も行う. それでもこの記事からは (訳しておいてなんだけれど) いまいち違和感が拭えない.
テストで手を抜く:steps to phantasien t(2006-02-12)
海辺のカフカ もらいもの. すばらしく面白かった. (実はもう内容をほとんど覚えていないが, それは良い娯楽作品の条件だと思う...) 村上春樹はなんというか, 日本語が卓越しているね. こんなにストレスなく読めて, かつ下品でない日本語を書ける作家は他に見ない. アマゾン・ドット・コムの光と影 前から気になっていたのを近所の本屋で発見し読む. 資本主義的に良い会社で働くのが幸せとは限らないのは実感としては 当り前ではあるが, Amazon(JP) の配送センターで働くという極端なケースの体験記. Amazon は素晴しい企業だ. 流通やアルバイトの活用といった計算機的でない部分の出来が良いと 計算機は威力を発揮するのだなあ. Expert One-on-One J2EE Development without EJB Spring Framwork の思想に基いた J2EE のアプリケー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
