ウェブっ子の間では Google Chrome の JS 処理系である V8 祭りが絶賛開催中らしい. いつもは出遅れる私もたまにはやんやしたいと思っていろいろ読んでみたものの, VM に食傷気味な自分に気付いた. けれど, そうは言っても祭りは別腹. 一通り騒いでみます. 販促マンガ や 資料 によれば, V8 は以下のような特徴を備えている. hidden class transition と fast property access generational accurate GC accurate だから incremental GC もできる オブジェクトの rellocation はするけど handle は使わず参照元書き換え 中間表現のインタプリタなしの native code 生成. instruction cache コードをみたところ, incremental GC

2008-08-31 近況 LL Future というイベントに呼んで頂き, 中野へ. 前日の激しい雷で眠りが浅く寝坊したら, 基調講演は Larry Wall だったらしい. 聞き逃した. なんてこったい... そしてサインを貰う準備もしていなかった. 昼飯を食べる暇があったら紀伊国屋に駆けこむんだったといまだに後悔している. おしいことをした. 宴会でゴルフ場経営者に見せてもらった サイン実物はとても気が利いたもので, まったくうらやましい. 彼の本は年季が入った版の上にかなり読みこまれた形跡があったので, Larry Wall も嬉しかったことだろうな. 私もいつか実現するであろう Stroustrup の来日に向け, 件の本を読み込んでおかねばなるまい. パネルの内容は shibuya.js 番外編というかんじで, JS や ActionScript の上で実装した処理系の紹介を中

"ECMAScript Harmony" を訳し, YukiWiki におきました. ES4 はやめるって Mozilla の親玉が ECMA で決めてきちゃったらしい. まじかよ, という話. 1-pass なので JS 詳しいひとはどうか添削をおねがいします. 関連リンクとかは気がむいたらあとで. Microsoft と Adobe は災難だなあ. 少し前に Web の進化は遅いが仕方ないんだぜ という話があって, 今回のはそれを象徴している気がする. 独走して独占というモデルを前提に技術資本を集めてプラットホームを作るのが割に合わなくなったのか, 戦いの舞台が別の層に移っただけなのか...両社のファンとしてはやや気の毒な気分. 追記: mal_blue@tumblr: /be の人一人で決めたわけでないし、 Adobe はともかく、MS はES4 の実装はじめてたわけじゃないので実害

いただきました. ありがとうございます. ネットワークの構成から冗長化, サーバのチューニング, デプロイの自動化まで, インフラや運用の話題を集めた本. 私は運用やインフラに素人なので, 内容の技術的正当性について特に意見はない. ただ動いてる実システムの解説という点で信憑性は担保してる気がする. ひたすらすげーなあ大変そうなだなあと読んだ. 特に TCP/IP より下, LAN カード (という表記が我ながら素人っぽい. 玄人ぶるには NIC と呼ぼうか...) より向こうは つい所与のものと考えてしまう. たまに仕事で必要になっても同僚に押しつけてるし. 実は色々やってるんだろうなと, なんとなく思っていた中身を垣間みた気分になる. NIC より手前の話もあるけれど, 個人的には ハブ(...というと素人っぽい. スイッチ.) や ルータやロードバランサの出てくる話が, 未知の世界で

Social Network Feedback in Real Time という記事があった. あるワークショップで参加者の social network (SN) を可視化してみせたところ, 参加者同士が anomaly に気付き自主的にそのネットワークを改善したという話. いろいろ面白い. 参加者の SN ってどうやったらわかるの？ それを改善するってどういうこと？ というわけで最初の疑問から. 参加者の SN を抽出するために, 著者らは "sociometric badge" というデバイスを使っている. これはマイクと赤外線センサ, 無線などを内蔵した小型計算機(センサ)で, 首から提げて持ち歩く. 大きさはケータイくらい. (関係者のページ に写真がある.) マイクや赤外線の情報は無線でホスト計算機に送られ, ホスト計算機がデータを分析する. 赤外線の記録から badge 同士

積んであった Beautiful Code を読んでみる. 第一章はカーニハンによる正規表現の話. 数十行のコードで簡単な正規表現を実装してみせる. パターン文字列を内部表現に変換せずマッチに使うぜ, コードも短い, ビューティホー! ...という主張なのだが, それはほんとにビューティホーなのか. UNIX 人の感覚にはついていけない. それにしても彼らは正規表現が好きだ. いつものその話ばかりしている. artu はいうまでもなく プログラミング作法 にも正規表現が出てきた. まったくこのマンネリめ. そう斜に構えつつ読み直してみると, 案外ラディカルな話も載っているのに気付く. 9.7 "オンザフライコンパイル" より: Ken Thompson はまさにこの方法によって 1967 年に IBM7094 上に正規表現を実装した. 彼のバージョンは, 正規表現に含まれる様々な処理を小さ

訳したのを Yukiwiki に公開しました. 楽天テクノロジーカンファレンスの記事 で amazon の Dynamo というのが紹介されていた. そんなのがあるのかとぐぐってみつけた Dynamo の話を読む. その中で consistent hashing が使われており. シンプルでよくできたアルゴリズムだと感心, 紹介しようと思った次第. WWW8 に出たオリジナルの記事も読んでみたけれど, もともと単純なアイデアなので大した詳細はない. Chord や Dynamo の記事に含まれる紹介で十分ことたりている. でも Chord が consitent hashing だというのは件の記事を読むまで気付かなかったなあ. わっかの上をぐるぐる周るやつ, くらいの記憶しかなかった... Dynamo consistent hashing にはじまり, Dynamo は分散アルゴリズム

友人の話をしよう. 先達に敬意を表し, 仮に彼を K と呼ぶ. (イニシャルは便宜的なものだ; 向上心云々と罵ったこともないし, 恋人を寝取ってもいない.) ある時期, 私は K と一緒に働いていた. 今は違う会社にいるけれど, 互いに暇なのか, このごろもよく二人で管を巻いている. 1 K は優秀なプログラマだ. いつも敵わないと思う. 一緒に仕事をしていたこともあり, プログラマとしての私は K から強い影響をうけている. たとえば私が自動テストを始めた発端には K がいる. コードレビューもそう. この日記に出てくる話も K の影響は色濃い. 私は K のあとを追いかけるようにプログラマを続けている. K と働いてはじめて, ああ, 物事とはこう改善していくものなのかと知った. 何か問題を感じると K は試行錯誤を始める. 問題は私が諦めていたものもあるし, そもそも気付かないものも

訳して YukiWiki に置きました. 元は "How to Write an Effective Design Document". 友達が "最近, プロジェクトで設計仕様書を作ろうって話が..." と悩んでいた. そりゃ大変だねえと相槌をうち, 相槌ついでにぐぐっていたらみつけた記事. <design document> や <designdoc> と検索すれば ガイドラインだけでなく実物もじゃんじゃかみつかる. 玉石混交で面白い. 設計仕様書と聞くと, 設計する人と実装する人が異るような大規模開発をまず連想する. そっちの世界で文書が必要なのはわかるが, 一方で私は大規模開発をしたいと思わないし, 興味も湧かない. 元の記事も私の友達もそんな大規模開発を想定していない. 文書化した本人が実装も行う. それでもこの記事からは (訳しておいてなんだけれど) いまいち違和感が拭えない.

昨日の RTR 読書会はパイプライン最適化の話だった. 改めて読むと面白い. 各種高速化チップスはさておき, パイプラインの遅い部分, ボトルネックを特定する方法が興味深かった. (ゲーム屋さんには当たり前の話だと思います.) グラフィクス・アプリケーションのパイプラインはおおよそ以下のようなものだ: CPU でデータを作り, それを GPU に送る. GPU ではまず geometry ステージ (vertex shader とか) が頂点情報を計算し, それを rasterize ステージ (pixel shader とか) がピクセルに変換, frame buffer に書き込む. データは図の左から右に流れる. この流れっぷりがパイプラインと呼ばれる所以. パイプラインの各ステージは基本的に並列して動く. だから全体の実行時間は最も遅いステージの所要時間になる. 各ステージの合計で

最近みた TechTalks の中で STM (Software Transactional Memory) の話が面白かった. 紹介しようと思ったものの, まず STM の認知度はどれほどなのだろうか. 日本語でぐぐると CPU 会社の宣伝くらいしか見当たらない. 友達にたずねたら "そんなので騒いでいるのは君と Haskell ユーザくらいだよ" とのたまう. 私の脳内では STM 派とメッセージ通信派が激烈な争いを繰り広げていることになっているけれど, 気のせいなのかもしれない... 念のため TechTalks を眺める前に少し STM の話を書いてみる. そのあと話の肴に作ってみた STM のトイ実装 (500行くらい) を紹介したい. Software Transactional Memory の話 ではさっそく STM のことを簡単に説明してみよう. 専門家による一次資料を読

SCM の Mercurial には CGI スクリプトがついてくる. これを使うと簡単に共有レポジトリを作ることができる. Web ブラウザからコードを閲覧できるし, 標準の hg コマンドからもさわれる. ためしにこのサーバ(さくらインターネットの賃貸)にインストールしてみたら, ちゃんと動いた. せっかくなのでインストール手順を簡単に紹介しておく. さて, SCM が CGI として動くのは一部の人にとってキラーな機能かもしれない. ちょっと友達と一緒にコードをいじりたい. 家と学校で設定ファイルやメモを共用したい. そんな時に重宝する. 今時の先鋭的な Web の若者は自分の公開サーバがあるだろうけれど, 怠惰な中年にそういうものはない. 共有サーバの賃貸がせいぜい. なので CVS や Subversion はあてにできない. 有償の Subversion ホスティングに金を払う

2007-01-27 近況 このごろ Standard ML の入門を読んでいる. 新しいプログラミング環境, 言語やライブラリを試すと, 少し調べたあとは何か作りたくなる. さて, 何をつくろう. 悩ましい. あまり難しくないものがいい. なにしろ覚えたてのよちよち歩きだから. かといってあまり味気ないのも寂しい. fib, hanoi や tarai はもってのほか. データ構造も動きがなくつまらない. もっとアプリケーションぽいのがいい. オリジナリティはいらないけれど, 完成したものが動くヨロコビは捨て難い. 端的にいえば入門書の最終章に作るプログラム. 新人研修の締め括りにつくるプログラム. きみはもう一人で歩けると言ってほしい. わたしは一人で歩けると言いたい. イニシエーションとコングラチュレーション. そんな欲求を見たす "トイ・プログラム" のコレクションがないものか.

Mercurial という分散 SCM の紹介. Python 製で, シンプル軽量スケーラブルが売り. 開発を初めたきっかけは linux の BitKeeper 事件だという. (だから GIT がライバルらしい.) OpenSolaris や OLPC など, けっこう採用実績があるのに驚いた. 私は分散 SCM を触ったことがない. SVK をちょっとつついたくらい. 話を聞く限り Mercurial はけっこう良さそう. (スライドは Wiki に公開されている.) 分散はさておき軽量なのがいい. たとえばレポジトリのためにわざわざ svnrepos みたいな別ディレクトリを作る必要がない. 作業コピーの中に .hg ディレクトリができて, ここに履歴が収められる. つまり作業コピーのディレクトリでレポジトリが閉じている. svn だとレポジトリを作るのが面倒でバージョン管理を先

2006-11-23 近況 Java でアプリケーションを作っている. 足回りが動いたのでアプリっぽくしようとデータベースをつなぎだしたが ... かったるい. RDB の出てこないコードを書いていた昨日までは快調だったのに, 今日 SQL がでてきた途端に意欲がガタ落ち. このかったるさの原因はなんだろう. 思いあたる節はある. まず RDB はなんとなく仕事っぽい. 趣味らしさを損なう. あと, ここしばらく ORM considered harmful 仮説に与して Hibernate なんかを使っていない. (かわりに Spring JDBC Template を利用.) その結果お約束コピペコードが増えて萎える. アンチ ORM 派の主な主張は, 実世界のデータモデルが持つ複雑さを ORM では吸収しきれない (結局普通に RDB を使うのと大差がなくなる) というものだ. でも

Adobe が ActionScript3 の VM "AVM2" をオープンソース化し, Mozilla に寄贈した. 今後 Mozilla2 に向けて本体の JavaScript 実装 (SpiderMonkey) と統合していくという. 寄贈されたのは VM だけ. コンパイラはない. そこは SpiderMonkey のパーサを使ってがんばるらしい. SpiderMonkey の実装は bytecode 指向だから, 頑張ればなんとかなるのかな。 (すくなくとも構文木ベースの WebKit JavaScriptCore に繋ぐよりは楽そうだ.) この Opensourced AVM2 は名前が "Tamarin". 響きがかわいい. たまりん... Mozilla のエースが早速 コードをチェックインしている. せっかくなのでチェックアウトしてみた. cvs -d :pserver

2006-09-18 近況 第2回DHT勉強会 を見てきた. DHT は P2P 用語で Distributed Hath Table のこと. 去年も同じ主催者による P2P勉強会に 参加している. 我ながら野次馬だ. 以下メモ. 詳細は詳しいひとがどこかに書くと思うので主観駆動です. "オーバレイ構築ツールキット Overlay Weaver" と DHT 入門講義 shudo.net のひとによる. Overlay Weaver (OW) というオーバーレイ・ネットワーク構築キットを作ったので試してね, という話... を期待していったのだけれど, その前の入門講義に時間を食われて肝心なところは スキップ気味だった. ちょっと残念. (でも入門は勉強になった.) OW は 名前のとおり overlay network をつくるためのミドルウェアで, DHT 部分のアルゴリズムなど,

2006-09-01 近況 いまの余暇コードは Makefile のかわりに SCons を使っている. Scons は python 製の make alternative. (概要は Radium Software に記事があった.) "#include" によるヘッダファイルの依存関係を勝手に解決してくれるのがいい. 私は何度やっても Makefile の dep ターゲットをうまく書けない. 泣きたくなる. gcc -MD で作った .dep ファイルが どのタイミングで Makefile に incldue されるのか, 実のところ未だによくわかっていない. 少し前にやった仕事でも, 試行錯誤の末になんとなく動いた Makefile をおそるおそる使っていた. (マニュアルをぱくったんだっけ...でも sed なんて使わなかったような...) 一体何がどの順序で評価されるのかさっ