サクサク読めて、アプリ限定の機能も多数！
トップへ戻る
大そうじへの備え
bn.dodgson.org
過去の記事(2003 - 2011) 2012 - steps.dodgson.org 2011 2011/11/26 Moving to Octopress 2011/11/04 Finagle - 都会育ちのメッセージングフレームワーク 2011/10/31 MongoDB の BSON 2011/10/15 WEB+DB PRESS 総集編 / I told my code to sing 2011/09/13 最近もらった本: アジャイルサムライ 2011/08/22 地雷力 2011/07/18 呼び出しプラス記法の由来, そのほか瑣細なメール技法のこと 2011/07/16 最近もらった本: Being Geek 2011/06/10 心はさらわれるもの 2011/05/06 寄稿者の集い 2011/04/26 Clang のコード補完 2011/04/17 Reading R
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 (
いただきました. ありがとうございます. プログラマのキャリアに関する話題を中心に書かれた本で, Blog ををまとめて書き足したもの, らしい. そうした出自の性質上, 読み物として完結した感じはない. そのぶん気楽によめた. 他人の blog をまとめ読みする楽しみってあるよね. キャリア(仕事探し)の他にマネジメントやライフハックぽい話も扱っている. でもそういうのは話題を絞ってかかれた本を読めばいいと思う. この本の面白いところは仕事探し/仕事選びに関するところ. 同じ話題を扱った本はたしかに結構あるけれど, だいたい人事コンサルタントや転職斡旋業者, あるいは一山あたってリタイア済の老人や 独立して事業を営むアドレナリン的ヒーローによって書かれている. 営業, 説教, 黙示録に類する読み物を読むのは楽しい時もあるけど食傷しがち. 対する著者の Michael Loop は会社勤め
購読しているブックマークからリンクされていた "一歩先行くJavaプログラマが読むべきオープンソースソフトウェア10選" という記事が面白かった. この人はだいぶ色々読んでいてすごい. Java には読むのに良いコードが色々あるものだと見直した. 私は推薦リストを作るには至れない. 本もコードも, 読んだ直後に気分が盛り上がって紹介することは時々あれど, お勧めするほどには自分の趣味や記憶を信じられていない. 私の読書/コード体験にはストックホルム症候群みたいなところがある; 苦労して何かを読んだあとはつい, こいつは必読/珠玉の一冊/ツリーだ! と思ってしまう. これを読んでないヤツは素人, なんて気分にすらなる. 友人も似たようなことを言っていたから, もしかしたらよくある気分なのかもしれない. そんな気分になったら, 私は架空の積読タワーに思いをめぐらせ, この山と積まれた本やツリー
Apple の近所のホテルで WebKit Contributors Meeting (2011 春) というのがあった. 同僚ともども参加. 話の内容は地味なのでおいておくとして, unconference としての開催が割とうまく回っていたのがおもしろかった. たぶん unconference にも色々な流儀があると思うので, 具体例として今回どんな感じだったかを書いてみたい. (去年もあったんだけれどよく憶えてない...) 開催まで 開催の一ヶ月少し前にメーリングリストで開催がアナウンスされた. Wiki のページ に話したいトピックを書いてねという. ページにはリストがあり, トピックの横にホストする人と聞きたい人を書く書式. 前々日までは 10 個くらいしか候補がなく, 二日もやる必要ないんじゃね? などと思っていたが前夜にわらわらと追記されていた. きみたち... 初日朝 会場
Clang のツリーを眺めていたら, "clang-completion-mode.el" というファイルがあった. clang のプログラムを呼び出してコード補完ができるらしい. (使いかたを説明してくれている人もいた.) 以前読んだ時 は気付かなかったけど, 二年前からあったようだ. こんなものがプラグインで書けてしまうなんてさすがモダンなコンパイラは違うなーインデクスはどうするのかなーと 感心しつつコードを見ていたらインデクスのような前処理はないようす. それに全然プラグインじゃない. Clang 組み込みの機能として実装されていた. 以前から Xcode(4) がどんな風に Clang を統合するのか気になっていた. コード補完はそうした取り組みの一環かもしれない. 高々 Emacs のため Clang 組込みの機能を増やすとも思えないからね. というわけでざっとコードを眺めてみよ
最近コードを読んでない. リハビリしようと軽めのものを探し, 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 の敷居を下げる. 体験談でありながら同時に後半の伝聞パート この手口で... を補強してい
2011-03-12 近況 無事です. はいいとして, 先週 Shibuya.js で話してきました (スライド). 空気をよまず JS と無関係の話をしてしまいやや申しわけなかったけれども, WebKit の様々な幻想をぶちこわす開発の様子を知ってもらうことには個人的な使命感を感じておりつまりこれはちょっとした十字軍なのです. JS のテストってなんでむずかしいの? 地震さわぎで自宅警備中の人も多いだろうから, お互いの気晴らしをかねてだらだら書きたい. JavaScript のテストについてぐぐったりついったを読んだりしていると, JavaScript でテストを書くのは大変だとか難しくてやってないという話が多くて不思議におもった. 私は JavaScript を使ってウェブアプリを作る仕事をしたことがなく, いまいち難しさがピンとこない. 趣味でさわっている範囲だと普通に書ける. な
はじめてまじめに ...といってもたぶん 500 行くらい... WebKit ではなく Chromium 側のコードを書いている. まだレビューをとおってないため現在形. でかすぎてビルドの遅い Chromium より Mac WebKit をいじる方が快適という同僚もいたけれど, コード自体は Chromium の方がだいぶモダンだよなあ. 普通に unit test が書けるありがたさといったらない. Developer testing まず gtest が良くできていて感心する. static initializer を使ってケースの登録を分散化したり, コマンドラインフラグでテストケースを一覧選別できたり, プロセスを分離してクラッシュに強くしたり, クラッシュしたテストケースの backtrace をだしたり. でかい C++ のコードベース相手にテストをスケールするための工夫
このページはもともと近況や日記だったはずがいつの間にか日記でなくなる ウェブ日記にありがちな落日に向かいつつあり気に入らない。 もっとどうでもいいことも書こう。というわけで日記のようなもの。 このごろチーム編成のなりゆきで英語な人々と昼飯をたべることが多い。 タダメシがあるというのに彼らはビルの外の食事が好きで、 おかげで少しは近所のピザ屋などに詳しくなった。 八割がた聞きとれない会話をにこにこ聞き流しながらピザ(など)をかじる日々がつづく。 パレートの法則に助けられ二割の範囲でわかることもある。 彼ら日本人と働く愉快な仲間たちにはいくつかお約束のジョークがあり、 呼称に関する話題もレパートリーのようだ。 いわく: 日本人の呼称は名字のあとに san をつけるものだけれど、ルールにあてはまらない人がいて困る。 たしかにちょっと検索しただけで英語圏な人々がなやむ様子を窺える。 たとえば私の上
ウェブをみていたらこんな風に書いているページがあった. WebKitは、現在も改良が加えられ、日々「現在開発中のWebKit」が開発者や先端ユーザー向けに提供されています。 ある程度、安定した機能を次のリリース用として仕様を固めたバージョンが、開発中バージョンとは別に作られ、一般ユーザーにも使えるよう、バグが少ない安定したコードになるまでデバッグが繰り返されます。 そして安定したバージョンを、各ソフトウェア提供企業が採用して、製品に使われるようになるのです。 この説明に間違いは無いと思うけれど, たぶん読んだ人の印象と実体は少し違うと思う. このズレに実害は無いと知りつつ, いい機会なので WebKit のリリースについて私の理解を説明してみたいとおもう. 最近 webkit-dev メーリングリストに "Best way to track feature evolution from r
「プログラマが知るべき 97 のこと」 日本語版のエクストラとしてちょこっと書かせてもらいました. エッセイ集のような本で, 読切 Blog 記事一気読み, みたいなノリで読めます. ソフトウェアアーキテクトが知るべき(同上) の続編というかんじですが, アーキテクトもプログラマも大差ないので片方読んで面白かったらもう一方も楽しめると思います. (両方に書いてる人もいます...) 一編 2 ページくらいの長さに揃っているので割と読み易い一方, 私のようにぐだぐだ長々と書く傾向の人間が書くと ややあっさりしてしまう気がした. ここで続きをちょっと書きたい. パッチのなやみ 私が書いたのは, "良いコード" と "良いパッチ" はときどき相反することがあるからどうしましょうね, という話だった. 良いコードはさておき良いパッチとはどんなものだろう. という話は本を買っていただきたくおもいますが
アジャイル開発の本質とスケールアップ を読んだ. 本書は前半がアジャイルの復習, 後半が大きなプロジェクトへのアジャイルの適用を扱っている. 前半は網羅的なぶん記述が bullet listive になりがちで面白くない. 後半が本題を扱っている. 著者のレフィングウェルは様々な大規模プロジェクト, 特に IBM/Rational での 開発を通じて得た大規模開発の知見をアジャイルの言葉で説明しようとする. まずチームの分割, 役割分担の話. それからイテレーション, リリースの話に続く. そのほか分散開発やアーキテクチャ, 組織のありかたについても章を割いている. 私はなりゆきから大き目のプロジェクトに参加しており, おかげでこの本は興味深く読めた. ただ不満な部分もあった. 扱っている話題は他人事じゃない. 大きなプロジェクトでの頻繁なリリース. 国をまたいだ分散開発. 機能別チームの
2010-07-27 近況 iPad も iPhone4 も新 mac mini も買わない私の信仰心に疑念の目を向ける心無い言葉を何度か耳にした. i5 が載ったら買うっていってるじゃん, といっても聞きやしない. ここは宣教プログラマとして信徒の鏡たれねば. 決意の末に LLDB のスライドを作り 説教に望んだ. I visited the mothership! LLDB 所感 宣教の一環としてこの日記でもコードをウォークスルーしようと 1/3 くらい書いたんだけれど, 途中でやる気がなくなってしまった. デバッガの面白さを大きく二手にわけると, 一つは他所のプロセスに横槍を入れる OS 密着部分のスリルがある. もう一つはプログラミングツールとしての強力さや柔軟性に挑むデザインへの興味. LLDB は, スリルの部分を "プラグイン" と呼ばれる サブクラスとしてうまく切り出してい
2010-03-12 近況 2 月末でこれまでの勤め先を退職し, 3 月から渋谷のグーグルで働いています. 前職のみなさまお世話になりました. もうちょっとコードにコメントを書いておくんだったと後悔しつつ後の祭りです. ごめん. 新しい職場のみなさまよろしくおねがいします. というか既にだいぶよろしくされてます. ありがとうございます. 4 月から入ってくると思われる新卒社員の方, は読んでないと思いますが, ときどき研修に混じってくるおっさんがいても適当にスルーしてくださいませ. カルマを高めてきたグーグルウォッチャー業は廃業です. 機会を頂いたのにすみません. でもさすがにウォッチャー社員はよくない. ドントビーイービル. 新しいウォッチ対象を探したい気もするけれど, その前にもうちょっと(というかだいぶ) コードを書いたり英語を話したりできるようにならないとまずそうで手いっぱい. 両
2010-02-23 近況 WEB+DB PRESS の連載が最終回です. 今回は毛色をかえ, 外野として WebKit にパッチを投稿する様子を 書いてみました. 宗教上の理由など C++ を避けておられる方にも楽しめるかもしれない内容になっております. パッチが原稿目的だったのは内緒です. (バグはちゃんと直したよ...) 連載のポストモーテムとしては, もっとレイアウトまわりを集中して扱えばよかったかなと反省. 自分もそのへんをよく読みたかった. CSS はさておき parser とか loader とか割とこう, しんどいゾーンから入ってしまったせいで 興味深いであろう箇所が手薄になってしまった. あと HTML5 なんかの流行りっぽい話をいれた方が人目を引けたかもしれない. ただ HTML5 ってブラウザが本来より守備範囲を広げる話なので, ブラウザらしさを見るには面白くない気も
このページのロードが遅い. たぶん前回 Amazon 画像を貼りつけすぎたせいだとおもう. 前回および前々回のページをさっさと追い出すべく何か書きたい. 金曜日は同僚に仕事をおしつけ デブサミ2010 を観にいった. パワハラの恩はとんかつで返すからね...などと思いつつ聴講していたらパワハリーから "バグがでた" とメールが届き 直しに戻ったため 3 コマしか観られず. こんにゃろうとんかつはナシだと思ったら私のバグだった. はいはいとんかつとんかつ... OpenSocial ケータイ Game 戦国時代 mixi と DeNA による各社プラットホームの紹介. OpenSocial 自体の話はさておき両社の対比が面白かった. Facebook のノリで汎用のソーシャルアプリ環境を目指す mixi と, ケータイ向けウェブゲームにフォーカスしている DeNA. 狙いの明確さは DeNA
裁断とスキャンが停滞している間にまた部屋の蔵書が幅をきかせ始めた. "最近読んだ本" で自分のページを検索したら, 最後は 2008-01-11. 二年分か. そりゃかさばるわ. さっさとメモして処分したい. 順不同. (もうすぐ処分します. めぼしいのがあって物理的に無事なら差し上げますのでご連絡を.) RESFful Web サービス わかった気になっていたけれどわかっていなかった話が多く, 面白かった. 私が REST だと思っていたのは REST-RPC ハイブリッドだったのかとか, connectedness がないと REST としてはいまいちだとか. 特に 8 章のベストプラクティスについては, トランザクションや一括取得のように素人が考えたらうまく設計できなそうな 話題に定型を与えているのがよかった. 実際のデータは階層化されていなかったり unified interfac
年始は食べものの調達が億劫で, 大鍋にカレーを作り三日三晩食べ続けた. 量が多過ぎたので最後の夜は友人 M に助けを求めた. 鍋を空にすべくたらふく食べたあと土産にもらったチャイをすすりふと見ると, やはり腹ごなしに本棚を物色していた M が CACM の山に目をとめていた. CACM: Communications of ACM は, 米国のコンピュータ学会(ACM)が発行する月刊の会誌. 昔々はこれに論文を載せるのが計算機科学者のステータスだった, らしい. たとえば "Goto statement considered harmful" に 続く一連の論争は CACM の投稿欄で行なわれた. ダイクストラがジャンプ放送局に出てくる雑誌を想像してほしい. もうちょっとマシな例だと Quicksort なんかも CACM が初出のよう. 最近は分野の細分化が進み, CACM で最先端の研
2009-12-31 近況 プログラマとしての成長が感じられない一年だった. 目先の仕事に気をとられ, 問題についてよく考える時間をとらなかった. 過労を言い訳に勉強もしなかった. 情けない. 一方で仕事のチームでは成長を感じることができた. せっかくだから, "チームがよくなる" 感じについて書いてみたいとおもう. 最近, 私のいるチームはコードレビューをするようになった. 私はこれまで仕事の中でコードレビューを実施しょうと試行錯誤してきたけれど, チームに定着することは少なかった. コードレビューはそれなりに面倒な作業なので, 特に組織的な外圧がないところではさぼられがちだと思う. けれど今のチームは外圧なしでやっている. およそ一年間のプロジェクトを通じ, このチームがコードレビューをするに至った道程を振り返ると, チームが成長する様子をうまく捉えることができるかもしれない. フェー
(最近はうそです. もらってから半年くらいたってます....) プロジェクト管理の本だった. 見積りの話も丁寧に書かれている. プロジェクト管理の二本柱(PMBOK による) "計画" と "監視制御" のうち, "計画" に占めるソフトウェア開発固有な部分は見積りくらいだから, 当然といえば当然かも. 前半 2/3 が計画(=見積り), 後半 1/3 が監視制御の話. 顧客に見積りや計画を求められる管理職には読んでおいて欲しい気がしたけれど, 管理職が読むのを期待するよりは自分で読んで見積りができるようにしておく方が たぶん現実的だし, 本書の趣旨にもあっていると思う. 本書の前半で説明されている見積りについて言えば, 規律にうるさい マコネルの見積り と比べ 実施の敷居は低い気がするので, まずはこのコーン式見積りをやってみるのが良さそう. 私のいるチームも planning poke
次のページ
このページを最初にブックマークしてみませんか？
『bn.dodgson.org』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
