これは VirtualDOM Advent Calendar 2014 に勝手に参加する記事です。 あたたかい春の昼下がりのこと、あるブラウザベンダの社内を不穏な噂が駆け巡った。 「React.js なるライブラリ、どうも仮想 DOM というやつのせいで速いらしいぞ」 もうリアルな DOM はお役御免、ブラウザも商売上がったりか・・・。雇用に不安を覚える人(私)がいる一方、 そのアイデアをとりこんでブラウザの DOM を速く出来ないかと考える人たちもいた。 仮想 DOM はなぜ速いのか。誰かのつてを辿って React.js チームにおいでいただき、速さの秘密をテックトークしてもらう。 イミュータブルなデータ構造による単純化、非同期適用による処理のバッチ化、差分アルゴリズムによる副作用の最小化… いくつかのアイデアはブラウザからはどうにもならないが、たとえば非同期化なんかは形は違えどブラウザ

たまには慣れない技術をさわろうと調べ物をはじめると、その技術の weekly や newsletter を名乗るメール配信サービスが目に付く。 たとえば Go には Golang Newsletter、Android には Android Weekly、 データサイエンスには Datascience Weekly がある。$要素技術名 {newsletter|weekly} で検索すると８割がた何か見つかる。 ずっと昔から続いているものもあるけれど、ここ数年で特に増えた様子。流行りの newsletter を紹介する記事も一年に一回くらい誰かが書いている。 よく知られた weekly のひとつ Ruby Weekly の発行者 Peter Cooper が ニュースレターの配信をはじめてみた感想を 2010 年に書いている。 2012 年にはメール配信サービス Mailchimp が彼をイ

あるとき Dark Matter Programmer という言葉をみかけた。ウェブやコミュニティに存在感のない、当人もそれを気にかけていない、プログラマをさす言葉。言い出しっぺの主張は、そういう人々の存在を忘れたり、見下したりすべきでないというものだった。 ダークマターはうまい比喩だと思う。正体がよくわかっていないらしいから適当さの粗が目立たず、その割にイメージは鮮烈。 他の比喩との相性もいい。たとえばスター。スタープログラマはダークマタープログラマの対極にいる印象だけれど、意図に立ち戻ればそれほど大げさでもない。何らかの可視性があればスターといえる。僕もあなたもスターなのがオンラインのコミュニティなのだろう。 さまざまな星 なんてきれいごとはさておき、乱暴に言ってダークマター以外がスターならスターにも色々ある。細かい隕石やガスなんかをさておくとしても、まず明るさ、等級が違う。あるいは自

先週はサンフランシスコで勤務先の年次博覧会が催され、中には自分と近いプロジェクトを紹介するセッションもあった。 いい機会なので便乗して宣伝してみたい。自主会社員活動につき勤務先の見解と違っても見逃してください。 さて件の年次博覧会、ウェブ開発者向けの講演の一つで Polymer という新しい JavaScript UI フレームワークが公開された。 Closure, GWT, Angular ときて また別のフレームワークかよ…とぼやく人の気持ちもわかる。でもそれほど被るものでもないから見逃してほしい。 なるべく多くのブラウザで動かそうとする既存のフレームワークと違い、 Polymer は新しいブラウザの機能を使い倒すことで強力なフレームワークを作ろうとしている。 別に特定ブラウザでしか動かないわけじゃない。ただ将来そうした新しい機能が各種ブラウザに備わる日を見越し、 そのときベストに動く

Gisted のドッグフードをかねて InfoQ のインタビューやプレゼンを見るようになった。 いくつか面白かったのを紹介したい・・・とおもってるうちにバックログを溜めすぎた。一度に紹介するのは諦めて何度かにわけよう。 今日はおっさん、具体的には ThoughtWorks 周辺の面々を追いかけてみます。InfoQ 中心だけどそれ以外も若干あり。 When Geek Leaks “プロダクティブ・プログラマ ” の著者 Neal Ford が あるキーノートにつけたタイトルは ”When Geek Leaks“。 ここでの Leak は前向きだ。Geek の情熱がその主たる関心の外にも影響を与えていくといいですね、という話。 ファインマンが物理学という専門以外で発揮した数々のいたずら心、 ”Now Every Company Is A Software Company” という Forbes

WIRED に ”Return of the Borg: How Twitter Rebuilt Google’s Secret Weapon” という記事があった。Twitter が Mesos というクラスタ管理のソフトウェアを開発しており、 それは検索会社のなんとかいうシステムみたいなもんらしいよ、という話。 不勉強につきそのなんとかいうシステムのことはよく知らないけれど、 去年の今頃開かれた Twitter の Open House (ASCII のレポート) をのぞかせてもらった際、 Twitter 社のエライ人 Rob Benson が 「これからインフラは Mesos でいく!!」 と熱心に話していたのを覚えている。 WIRED の記事によれば、Mesos ベースに移行したマシンは二割。もう全部移行する勢いなのかとおもってたけど、インフラを変えるのは大変なのだろう。 そういえ

仕事用の inbox に “Happy Anniversary!” というメールが届いていた。 入社してから三年経ったらしい。我ながらよく頑張った。 今の仕事にはまあまあきついところもあり、きついといってもデスマ的なきつさとは違うんだけど、 たとえば自己主張の強い人々と議論するなんてのはきつい。 気の弱い私はなるべく成り行きに任せることでしんどさを小さくしようとしている。 けれど成り行きに任せすぎると意思決定の無力感が板についてしまう。バランスはあやうい。 今のところの私が完全な無力サイドにおちず踏みとどまれているのは、 チームの同僚やリードによるところが大きい。 苦手な仕事 私は日頃ブラウザのバグをとったり、 JavaScript から使える新機能の API を生やしたりといった仕事をしている。 嗜好に限った話をすると、API を生やすよりバグをとる方がすきだ。 バグをとると皆ハッピーに

TED の動画はまあまあ面白いのでときどき暇つぶしに見るのだけれど, 動画ではなく音だけ (mp3) で聴きたいことがある. 動画ばかりは疲れる. あとあんどろ機器や iPod に入れて持ち出すのも音声がいい. 動画だとサイズが大きい上にバッテリーの減りも速いからね. 幸い TED は多くの動画にダウンロード用の mp3 を用意してくれている. あとは transcript (原稿) があればいうことない. 実際, TED のサイトには transcript もある. ただサイトのつくりが持ち出し派につらい. 持ち出しビューがないし, サイトから手元に切り出そうもコピペがやりにくい. それに切り出したテキストを Instapaper なんかのテキスト表示機に取り込むのは, いずれにせよ面倒がある. 私は移動中に原稿つきでスピーチ聴きたいだけなんよ. 音声だけで足りるほど英語できない… とい

Chromium プロジェクトは crbug.com というドメインをもっている. このドメインは Chromium のバグトラッカー (BTS) 専用の URL shortener として使われている. たとえば crbug.com/125981 にアクセスすると https://code.google.com/p/chromium/issues/detail?id=125981 にリダイレクトされる. URL shortener といっても t.co や bit.ly みたいに大げさなものではない. Apache…じゃなくてなぜか IIS だった…の設定か何かでちょこっと URL を書き換え, そこにリダイレクトするだけ. データベースなし. オンラインでバグの話をするとき, 多くの Chromium 関係者は crbug.com の URL でバグを表記する. バグの URL が短い

WEB+DB の新しいやつがちょっと前にでてます. コードレビュー特集だそうな. 時が経つのは早い. まだ次の原稿書いてないのに… そういえば前にコードレビューの話を書いた気がして, 見なおしたところ かきかけ だった. せっかくなので続きを書いてみることにします. といっても何書くつもりだったか覚えてないのでだらだらと. WEB+DB PRESS の特集は, 主にこれからコードレビューを導入したい人に向けて書かれている. 幸か不幸か私はコードレビューを義務付けれたプロジェクトで働いているため, 導入には苦労していない. かわりにレビューをちょろまかせない面倒はある. ある意味でコードレビューを <やらされている>. もちろんこの言い分は大げさだ. 必要性に異議を唱える気はない. ただ異議はさておき自分の意向とは無関係にコードレビューに参加している気分を書いた話は あまり目にしないので,

有給を駆使し一足早くクリスマス休暇に突入、ヒャッホイ Ingress やるぜーと 意気込んでいた矢先ノロウイルスにやられダウンした。かなしい。鎮まれ俺の胃袋・・・ そんな腹痛日和の気晴らしとして今日は Garbage Collection Advent Calendar に参加してみることにしました。 Advent Calendar 初体験につきよくわかってないけど勝手に参加していいんですよね？ GC というとジェネレーショナルだのパラレルコンカレントだのといった話が目立ちがちだけれど、 現実の問題というかブラウザを相手にするとそれ以外の細々とした面倒が目につく。 GC つき言語 (JavaScript) のコードと C++ で書かれたコードとの連携は最たる面倒の１つ。 たとえば WebKit の DOM は C++ で実装されており、 C++ のオブジェクトは JavaScript 処理

コードレビューの話をいくつか見かけた. (1, 2, 3) 私もはやりにのってなにか書いてみたい. といってもリンク先についてどうこう言う気はない. ふだんからぼんやり感じていることをテキストにしてみたい. コードレビューの様式 コードレビューのやりかたは色々ある. 話の背景をあきらかにすべく, まずは私が参加したり見聞きしたりしてきた方法を紹介したい. ただとりとめなく列挙しても見通しが悪いから, 方法を評価する軸を見立てておこう. コードの粒度: 一回のレビューでレビュアが目を通すコードの量はどのくらいだろう. プロジェクト全体? モジュール単位, 機能単位, それともクラス単位? 古典的なレビュー様式はこれら <論理的な単位> でレビューをすることが多い. 最近はブランチやコミットのような <ひとまとまりの変更> を単位とする方法に人気がある. Github の Pull Reque

つづき。 Should の話は 前回 済ませた。 今日は was のはなし。私の時はこんな風だった、こんな会社があったという話をしてみたい。 読みやすさや角をたてないためなどの都合で一般化した書き方をするけれど、 ごく限られたインスタンスが相手である点はご了承ください。 グリッドと地層 最初のホッピングが終わって気づいたのは、新卒という立場の特別さだった。 新卒は給料が安く世間知らずとホッピング界ではバカにされがち。 けれど実際は良いこともある。 いまの私から見て一番うらやましい新卒特典は、 バッチ採用された同期入社の同僚たち。たくさん、しかも部門をまたいであちこちにいる。 中途採用で勤め始めると、知り合いは周りの人たちだけだ。 社交的で知り合いを増やすのが得意な人にしてみれば、 これは小さなことかもしれない。 でも人見知りな身からするとシステムとして顔見知りができる バッチ採用は大きな助

友人知人など、私のまわりには転職しようと考えている人がいつも少しずついる。 彼らに限らず、プログラマは割と頻繁に転職している気がする。よしよし、と思う。 世の中にとって良いことなのかはしらないけれど、 ジョブホッパーの身からすればそういう人が増えるほど私自身の角が立たなくてすむ。 類として呼ぶ友を求める心境。 私ほどのヘビーホッパー（ぜんぜん自慢になってない）ともなると、 たまにホッパー予備軍から「転職どうなんですかね」と水を向けられることがある。 そんなとき、酔った勢いなどで私はいつもでたらめを口走り後悔している。 そこでシラフのうちに自分用のテンプレを書いておくことにした。 正誤はともかくせめて主張を一貫させたい。 さいわい今の職場はもうしばらくいる気がするから、テンプレの陳腐化は心配しなくてよかろう。 私はおおむね行きがかりと衝動で職場をホップしており、そこに長期的な思惑はない。 た

Chromium と WebKit は二つの独立したプロジェクトだ。 ソースツリーはそれぞれ別で、そこにはインテグレーションの苦労がある。 WebKit 以外にも V8 や Skia など Chromium が依存している外部のプロジェクトは山ほどあるけれど, WebKit とは特にぴったりくっついている。 そのぶん二つの足並みをあわせる手間も際立つ。 以前、書籍 ”アジャイル開発の本質とスケールアップ” で リリーストレイン という大規模プロジェクトのインテグレーション手法を読んだ。 プロジェクトの内部で一段細かい時限リリースを設け、そのタイミングでインテグレーションする方法。 内部リリースにあわせてプロジェクト同士が依存している相手のバージョンを上げ、 壊れたところをなおすわけ。 Chromium と WebKit もこまめに相手のバージョンを新しくする。 主たる依存の向きは Chro

ある ニュース記事を同僚に教わった。 この記事によるとタッチデバイスの会社は WebKit2 に対応しているのに検索の会社は旧バージョンにとどまっており、HTML5 に課題は多いのだそうな。 そりゃ課題は常に山積みだよね…と思っていたら記事は誤解だと別の同僚が説明を書いている。 リンク先の記事はさておき、世間の関心をいまいち集められていない気がする WebKit2 についてざっと説明をしてみたいとおもう。 この記事を読み終われば WebKit2 と Chromium WebKit, Webkit1 の違いを知ったかぶれるようになる予定。 WebKit2 は 2010 年の 4 月にアナウンスされた WebKit の新しい API レイヤで、Mac 版 Safari などが使っている。 大きな特徴はレンダリングエンジンを別プロセスで動かせること。 Chromium でやっているのと同じような

いまいち気力がおこらず動画などを物色していたところ、 去年のおわりに開催された Strange Loopというソフトウェア開発者向けイベントのビデオが 公開されているのに気づいた。 題目を見る限り面白いのが多そう。 ホスト先が InfoQ なのはちょっと残念だけど・・・。 ぼちぼち眺めはじめた中では Product Engineering なる題目の Mike Lee による講演が面白かった。 Mike Lee は 蔵書管理ソフトの Delicious Libraryや iPhone 用音ゲーの Tap Tap Revenge といったアプリで一山あてたあとしばらく Apple で働き、その後またスタートアップに移った波乱あふれるヒットメーカー。 実際に役立つかはともかく、話の内容も iPhone のヒットアプリを作るひとの行動や思考様式が覗き見られ印象深い。 まず Technology

GitHub co-founder の Tom Preston-Werner (以下もじょ先生) が お仕事のコードも大半はオープンソースにしたほうがいい という話を書いている。 (@higepon の tweet で知った。) 同じような主張は、ビジネスとしてのオープンソースが隆盛を極めた 2000 年前後にもみられた。 時は流れ、今はソフトウェアそのものよりはアプリケーションやサービスをウェブ越しに売る時代。 ハイテク企業の前線もコード自身からデータやユーザの時間といったコード以外の部分に少しづつ軸足を移しつつある。 そうした企業は十年前とは異なる文脈でコードをオープンソースにしはじめた… というだいたいの背景を踏まえつつ読むと、もじょ先生の話は感慨深い。 もじょ先生はスタートアップの founder/CTO らしい立場でオープンソースの利点を説いている。 私はスタートアップ勤務でもな