そういえばモバイル端末からのアクセスってどんなもんだろう。ログはほとんど見ていなかった……で、ちょっと見てみたら大半のアクセスがロボットとクローラで少し凹む。まあ、世の中というのはそういうものだ、きっと。
WordPressのスマートフォン対応についてはWPtouchというのを使えばいいらしい。スマートフォンというが、設定にはスマートフォンではない携帯端末(ガラケー?)にもなんかできるようなことが書いてある。ただ、試していない。設定項目はいろいろあるが、細かいカスタマイズは若干面倒臭く、ひとまずお試し、動けば良いということで、テーマを変えたぐらい。でまあ動いているっぽい。
ところでモバイル端末からのアクセスは割と残念な状況な気がした(1%ぐらい)。まあ今後は増えるかもしれないが……。あとHonycombタブレットとかでもスマートフォンUIになっちゃうっぽいんだよね。どうしたものかなあ。というかそれはどっちがいいのかなあ。
Made by Hand ―ポンコツDIYで自分を取り戻す (Make: Japan Books)
Makeの編集長、マーク・フラウエンフェルダーによるDIY体験記エッセイ。芝生を家庭菜園にしてみたり、エスプレッソマシンを改造してみたり、にわとり小屋を作ってみたり、発酵食品にチャレンジしてみたり、楽器を作ってみたり、９章からなるエッセイ集。DIYの読み物ってーと、絵図面がバンバンあるようなガイドが多いけど、この本は完全にエッセイ集だ。読んでも何かの参考になりはしないけど、こういう生き方もいいかもな、というのも気分にさせてくれる。
著者は実に様々なことに挑戦しているけれど、なにより語り口が常に楽しげなのがいい。何か自分もこういうことをやってみたい、そんな気分にすらさせられる。にわとりを買ったりなんて、東京の都市部ではありえないわけだけど、それすら楽しそうだ。
だが、同時に強調されるのは、常に失敗と隣り合わせだということだ。著者は楽しげに語るが、失敗は必ずある。やばい瞬間はいつもある。DIYはコストと成果物の質を考えれば見合わない。むしろDIYは、したいからしているという意味合いが強いようにも読める。例えば、
私がアマチュアの冒険に踏み出したとき、DIY仲間からこう忠告された。失敗は必ずするが、それに負けてはいけないと。私はよくわかっていたつもりだったが、自分がやらかす失敗の数については見積もりが甘すぎた。実際、失敗をしないことがない。どんなに簡単で小さなプロジェクトでも、失敗はキノコのように次々と顔を出す。
とか、
ワゴンの製作に午後いっぱいの時間がかかった。その時間を使って原稿を書けば、工場で生産されたピカピカのワゴンか二台や三台は買えただろうが、私はなにも、時間やお金を節約するためにワゴンを自作したわけではない。大切なのはスローダウンすることだ。DIYは、二〇年前にイタリアで始まったスローフードのムーブメントに似ている。計画、道具と材料の選択、作業場所の確保、作り方、資材、そして最終的なDIY作品、これら全てによって味が出る。労力は出費は二の次だ。
とか。
読んでいて、Makeのバックボーンにはこういう文化があったのだと思った。日本のMakeには、こういう文化的背景がかけているのかもしれない。去年、たまたまいい時期にベイエリアに行って本場のMaker Faireを眺めて、雰囲気が違うなと思ったのだ。もちろん根本的に違うというのではなく、スペクトラムの差でしかないのだが、その違いをうまく言語化できなかった。その違いというのが、アメリカのDIY文化なのかも……と思ったりする。ずぶの素人がこういうことに手を染めるというのは、日本では嫌われる気がするし。そういう意味で極めてアメリカンな本だ。
面白いのは、著者があくまでも素人芸の域を出ないでいることだ。というと悪い言い方みたいだが、著者はわざとこの位置にとどまっているのがいい。各エピソードでは、いろんな専門家が顔と口を出す。エスプレッソの専門家は、家庭にあるようなしょぼいマシンではいいエスプレッソは作れないという。著者はちゃんと稿を割いて専門家の言い分を説明する。なぜそうなのか。何が問題なのか。すべてが明らかになったところで、でも著者はその先には行かない。その道の人の目的は完璧なエスプレッソを作ることであって、そのためにはまず例えば高い機械を買うのが必須だ。それはわかった。でも、と著者は一歩引く。やりたいのは、家庭用のエスプレッソを改造して、そこそこいいエスプレッソを作ることだ。専門家の話を聞くことで、なぜ高い機械が家庭用のしょぼい奴よりいいものができるのかがわかったから、そのエッセンスを汲めば家庭用のをうまく改造できるかもしれないし、できたら嬉しい。そういうスタンスが本書では貫かれている。
そういう思想に共感できる人なら、この本はとても楽しく読めると思う。
半年ほど前に少し書いたSKY配列だが、あの時にはしばらくして使うのをやめてしまっていた。が、この5月にSKY++配列の作者とあって話したことで、また少し気分が舞い上がり、SKY配列に再挑戦することにした。で、それから2ヶ月たち、かなりSKY配列に慣れてしまった。今は使っているマシンは基本的にすべてSKY配列を少し改造した独自配列で書いている。
SKY配列とは何か。詳しくは「SKY配列について」のページを参考にして欲しいが、ルールはかなり単純で、左手のキーに子音、右手のキーに母音を割り振る変則ローマ字配列だ。こうした配列の利点はいくつかあるが、基本的に日本語の一文字というのは子音ひとつと母音ひとつで成り立っているわけで、こういう配列にすることで自然と両手の指を交互に打鍵することになり、効率的な入力が可能になるという次第だ。
また、よくある母音の並びである、あい、うう、えい、おう、あん、いん、うん、えん、おん、などが1打鍵で入れられるため、打鍵数を減らせるという利点もある。また、SKY配列はとても単純な配列なので習得が容易であるということもあると思う。
そもそも、日本語を入力するにあたって、別に既存の英語のキーときちんと対応している必然性はないと思う。台湾の注音記号や韓国のハングルなどは、音素の部品が各キーに割り当てられているけれど、同じように左右で母音と子音を切り分けていて交互に打鍵しやすくなっている。それでもいいんじゃないか、と思うんだよね。
—
前回のチャレンジでは、須藤玲司氏のSKY++配列を試してみた。SKY++配列のポイントはシフトキーを使うということにある。jが「あ」を意味するが、Jは「や」のようになる。dがさ行なので、djが「さ」だが、dJなら「しゃ」というわけ。子音の方は「っ」が前置される。Sjが「った」なわけ。
幸いにして(?)、Google日本語入力ではローマ字変換テーブルでこうした大文字に対応できる。設定から「入力補助」タブの「シフトキーでの入力切替」をオフにしておけば、あとはローマ字変換テーブルに大文字を書いておくとちゃんと動作する。ということなので、実地試験も含めてやってみたのだが、どうも違和感がある。やっぱりそれなりに文中に英単語を書くことがあり、そういう時にシフトキーの動作がこれだとやっぱりどうも不自然だと思って、そこで一旦使うのをやめてしまった。
今回、再挑戦するにあたって、このシフト方式に代わる手段はないかと考えた。GOTO方式は中指プレフィクスだが、これには違和感がある(Sの代わりにks、Jのかわりにdjとする方式)。中指はそれなりに利用頻度の高いキーだという気がするので、そこをプレフィクスにしてしまうのはもったいない。どうしたものかなと思っていたのだが、同じようにプレフィクス方式にするにせよ、中指のような便利でよく使うところではなく、小指のキーを割り当てればいいと気づいた。具体的には、右小指の右隣のキー(“、英語配列の場合は’)をプレフィクスにする。’sがSの扱いになる。’jのように母音パターンは右手の連続になるので打ちづらいということで割り当てず、代わりにや行のキーであるgを混ぜてつかう(dgjが「しゃ」になる)。二回打鍵で「っ」が入り、シフトで「ん」になる(このキーはシフトを押しても大文字小文字の変化じゃなく、違う記号になるだけなので、シフトキーでの入力切替の問題とかち合わない)。そうすると、もともとこのキーに割り当てられていたオンビキ(ー)が打てないのだが、これは普通のローマ字テーブルと同様のハイフンを使うことで妥協した。
言葉で書くとややこしいが、小指プレフィクスということなのでそれなりに単純だし、シフトキーだって小指プレフィクスみたいなものだ、と自分を説得して使ってみたところ、案外良い塩梅なので満足した。なかなか使い心地がいいと思う(自分で考えたからというバイアスがかかってそうだけど)。Google日本語入力のローマ字変換テーブルの設定をGoogle Docsにアップロードしておいたので、興味のある人はどうぞ(英語配列用ですが)。
会社の人数名と一緒に先週に見に行ってきたけど、そうして正解だったかも(笑)。
なんか、既視感で構成されている映画だとか、そういう方面の悪評があることは知ってたのだけど、いやいーじゃんこれ。私は楽しめましたよ。
確かに既視感のあるシーンも多いし、話はご都合主義的なツッコミどころも多く、話の筋は読めます。わかります。だが、これはそれでいいのだ。こういう映画なのだ、と思う。なんともB級な怪獣映画を撮りたかったのねえ、という気持ちはよく伝わってくる。第一、みんなでゾンビ映画を作ってて、特殊メイク役で鉄道模型とかに夢中な主人公が、ヒロイン役で出てきた女の子と仲良くなる話が話しの軸ですからね。彼女にゾンビメイクを施して、演技指導をしながらじゃれあうシーンの微笑ましくもボンクラの妄想としか言い用のないところがイイ、そういう映画ではないかと思います。
ときは1979年、スリーマイル島事故がニュースで流れる頃、秘密を隠蔽する軍部、といった設定は今の日本と重なる部分もあり、見ながら「もしやそういう深い展開が……」と一瞬だけ期待しましたがただの気のせいでしたーという感じ。これも「よくある映画の設定」というぐらいの背景情報に過ぎず、1979年という時代が選ばれたのはむしろ監督(J.J.エイブラムス、1966年生まれ)がこの主人公たちと同じ年頃の頃ってだけじゃね、という気がします。
そういうボンクラ映画ですから、友達とみんなで見に行って、ポップコーンでもかじりながら「キター」とか言いつつ見るのが正しい映画であり、その目的には完璧に沿った映画であろうと。なんか大作だと思って見に行くからがっかりするのですね。そういうのではない、全然。
あとエンドクレジットが最高(笑)。この映画を見に行ってエンドクレジットを見ずに帰るのは全く損をしてますよ! マスト見るべし。むしろそこが本編。
ふとなんとなく足してみた。だんだん派手めになっていく……。
この手のサービスは、まあいいんだけど、どのみちここのような辺境の地ではたいした影響はないだろうと思う。ほぼすべてのページはどうせゼロだし、こういうボタンに強い影響があるとも思えない。が、あろうがなかろうが影響がないなら、置いといてもさしたる問題はないのかもしれない。まあ、気が向いたら押してやってください。
そういえば、2ヶ月ほど前にほぼ単純な好奇心でアドセンスも導入してみたのだが、その後、月あたりの収入は、まあいいとこ数百円といったところのようだ(それでも事前に思っていたよりは収入がある)。もう少し色々頑張れば効率化はできるだろうと思うが、そこはあまりがんばらないでいこう、と今のところは考えている。ちなみに、amazonのアフィリエイトも収入源としては似たような感じ。
だからどうだというのではないけれど、特に有名でもない普通の人のブログというのは、まあその程度なわけだ。
ただまあ、アドセンスやアフィリエイトというのは、半分はそれ自体が娯楽なのではないかと思うことがある。クリックのデータなんかを眺めると、なんとなく傾向がわかるようでわからない(データがスパース過ぎて人間にもよくわからない)。その絶妙な所をあれこれ眺めるのは、なんとなく楽しいものだ。+1ボタンとかにも、そういう面白さがあるだろうか。
うちの近所の本屋では、どうも好きな書店員がいるようでずーっと本屋のどこかしらに置かれていて、それなりにじわじわ売れていたというポップがあったりする、一部に大人気の『がらくたストリート』が2年半ぶりぐらいに続刊が出た。待ちぼうけるというより、どこかで作者が書くのをやめちゃって打ち切りとかだったんじゃないかと思ってた。
この漫画は抜群に面白いと思うけど、その面白さをどう伝えたらいいか……。とある山間の田舎の、子供たちと少年少女と、宇宙人と時々神様の日常。そんな感じ。淡々とした日常、時に非日常みたいな、ダラっとした生活を描くという意味では、昨今よくある日常系な漫画という括りになるかもしれないけれど、そんな括りからは逸脱するような不思議さがある。日常と非日常の境目がひどく曖昧で、区別されないファンタスティックな面もあって、そんで時にオタクネタやうんちくが混ざってたりして(今回だと「1話に金田いるらしいぞ」ってのに「かなだ」というルビがふられるとかそういうね……)、話が進んでいるんだかそうでないんだか、進めるような話がそもそもないようであるようで、いかにも不思議でワンアンドオンリーなのかもしれない。
そんななんだかよくわからないような漫画が面白いのかというと、これが面白い。
この漫画の面白さは「語り口」だと思う。この漫画は語り口が抜群だ。語り口というのは、話の持って行き方とか、掛け合いの面白さといったもので、ヒトコマをバーンと貼ってわかるような面白さとは違う。だから説明はしづらいけれど、読めばわかる。2巻冒頭の、海に行くのに駐車場に集合してうだうだしている所がすでにいい、と私なんかは思ってしまう。
おすすめです。
git commitにある–amendというフラグをご存知だろうか。
gitでは、commitは手元のレポジトリに保存される。多人数で開発するときの中央レポジトリに反映させるには、commitしたものをpushする必要がある。……で、大抵の多人数で開発するプロジェクトの場合、commitした変更を(gerritとかの手段によって)レビューしたりしつつ、すべてが整ってから、pushするというのが一般的な流れかと思う。
だけど人間というのはうかつなことをするものだから、commitした直後に下らない間違いを犯しがちなわけだ。例えば、編集したのにChangeLogを追加してないとか。ファイル足したのにビルドファイルの変更を加え忘れたとか。そういうやつ。そういうしょうもない変更でコミットを汚したくない時のために–amendがある。–amendすると、新しいコミットを作る代わりに最新版のコミットを更新する。
実は、Darcsにもamend-recordというそのための専用コマンドがある(普通のcommitに当たるコマンドはrecordという名前になっている)。これはつまり、こういううかつなコミットはよくあって避けづらいということだ。だが、Mercurialには、この種の操作のための便利なコマンドがない。
もちろん、同じ事もできるといえばできる。hg rollbackというコマンドを実行すると最新のコミットを消してしまう。で、その後にhg commitし直せばいい(Gitユーザ向けのMercurialガイドにもそのまんま載っている)。そういうextensionを書くという手も残されていて、もちろんmqを使うという手もなくはない。
だが、なんで–amendがないんだろうね、というのを、ここではうだうだ考えたい。
すぐ思いつくのは、「非推奨の操作は面倒くさくする」の原理だ。普段良く使ってほしいオペレーションは簡単にできるようにし、あんまり使って欲しくないやつはよくわからない複雑なオペレーションにする。ちゃんとわかってない人には使わせないようにするというわけだ(この観点からすると、git reset –hardとかは最低ではないかとおもう……)。Mercurialはわりとこの原則を採用していて、hg helpでは出てこないような特殊なコマンドが実は山ほどあり、詳しい人だけが内部的なデータをうかがい知ることができるようになっている。つまり、–amendは「やればできるけど積極的にはサポートしたくない」という開発者の意思が介在していると見るべきだ。
そもそもバージョン管理システムにおいて、変更履歴というのは不変であり、勝手に消したりするべきではない。バージョンの管理というのはそういうことだ。また、amendで書き換える前のコミットを誰かがpullしてしまっていたら厄介なことになる。そういう危険はもちろんgitだろうがなんだろうがありうるので、gitのマニュアルにもYou should understand the implications of rewriting history if you amend a commit that has already been published.と注意書きが書かれている。だが、本質的に危険な処理なら、やるべきではないという主張なのではないだろうか。
ここに、理想主義的な視点を感じることができる。gitの–amendは便利さの追求でもあり、実用主義的な視点を感じる。あと私は気づかなかったが、git bisectなどのためには各コミットをクリーンに保っておく必要があり、そういうワークフローを追求した結果として–amendは必要だというわけだ。Mercurialの考え方は理想的だが、現実に立脚していない気がする。
Mercurialの側にも言い訳はある。Mercurialのextensionフレームワークは協力かつ柔軟なので、commitコマンドに–amendフラグを足すことぐらいはやればできる。作者はやりたくないが欲しいというユーザに対しては「それextensionで」と返事しておける。mqを使えば問題ないわけだし(そういえばMacHgにはamendがあるらしい。なんじゃそりゃ……)。
しかし、ここにextensionの不幸もある気もする。「それextensionで」の行き着く先は、謎の野良extensionが溢れ、統一したものが存在しない世界であり、extension同士の相性が取り沙汰される世界だ。Mercurialはそんなひどい事になっていないけど、柔軟すぎるextensionは得てして不幸ももたらす気がする……。
という以上は全く私の妄想なわけだけど、実際のところはどうなんでしょ。メーリングリストを追っても、–amendはどうもFAQっぽい気がするけどなあ。
同僚に教えてもらって読んだのだが、とても良かった。プログラマは必読だが、それ以外の人にもおすすめしたい。
Chandlerという鳴り物入りで始まったオープンソースプロジェクトについて、およそ3年にわたって追いかけた失敗の記録。といって「ああ、デスマの本ですか」と一括りにしてしまうともったいない。確かにソフトウェアプロジェクトの失敗の話なんてありふれているし、デスマーチの本なんて他にいくらでもある。この本が面白いのはたぶん、そういうありがちな問題がまるでないプロジェクトだったにもかかわらず失敗する、ということを報告しているからだ。
デスマーチはない。納期に追われて徹夜するやつはいない。勤務時間は自由であり、オフィスには愛犬を連れてきてもいいし、在宅勤務もオーケー。資金的にも問題ない。スポンサーが変なことを言い出して仕様変更になったりしない。リーダーはロックスター級の人物で、他にも超大物で有能な人物がどんどん参加する。しかも、リーダーは壮大で理想的な目標を掲げ、みんなその理想に共鳴して参加する。ビジョンは共有されている。
にもかかわらず、プロジェクトは進まず、失速する。なぜか?
その問いには簡単には答えられないが、ひとくちで言うなら、目的が壮大過ぎ、かつはじめから高い完成度を追い求め過ぎたことかと思う。Chandlerは凡百のツールとは違う。メールのやり取りができ、予定の管理ができ、メモを書き留めることができ、ドキュメントやTODO管理ができ、しかもそれらのデータは相互に変化させることができる(受け取ったメールからカレンダーの予定やTODOを作ったりできる)。さらにデータの同期までできるが、データの同期はP2Pで中央のサーバを必要としない。
壮大すぎるし柔軟すぎる。案の定、開発者たちは議論だけの無為な時間を過ごす。メールはアイテムなのか、スレッドはどうなるか。くり返しの予定はどういう風に保存されるべきか。ドキュメントの集合はドキュメントとして管理されるのか、違うのか。議論は長引き、会議は踊る。どうでもいい技術が導入される。
けっきょく、機能を限った小さなプロトタイプから始めてドッグフードしつつ完成度を高めていくのが一番だと思うけど、チームはなかなかその結論に至らない。データは、ユーザからはどれも等価に扱えるべきだけど、内部的には階層的な意味論で管理されるべきだ、という提案を受け入れづらい。P2Pは将来の目標ということで棚上げしてしまえば楽だけど、なかなかそういう道に進めない。エンジニアは斧を研ぎたがるという話がこの本に出てくる。その時点では必要ないかもしれないけど、将来必要となった時のために考えておくべき拡張性や新機能を斧になぞらえているわけだ。ゲームを作るのにまずメモリマネージャを作り始めるというネタも近いものがありそうな気がする――何故かそこから始めてしまい、それ自体は高機能だが、いつまでたっても所望のものが出てこない。
開発プロセスもなかった。オープンソースというと、いろんな人達がよって集って作り上げていくから開発プロセスも無きに等しいと思いがちだけど、それは違う。個人プロジェクトならそうだけど、これほどの大規模プロジェクトではそれじゃ無理が出てくる。普通の会社とは違うかもしれないけれど、何らかのプロセスなしには進めなくなる。どういうスケジュールで、どの段階までに何が必要で、それにはどれだけ時間がかかるか。次のバージョンではどのバグを直し、どの機能を入れるのか。やり方はなんでもいいのだけど、そういうことをなにもしないとプロジェクトは迷走する。
……ここであげるれた問題は、よくあるデスマの愚痴とは違う。違うがゆえにソフトウェア開発でおこる問題が浮き彫りになる。プロジェクトが失敗するのは、技術のことをわかっていない客が余計な口出しをするからではないし、無茶なスケジュールが組まれるからでもない。プログラマが無能だからでもない。そういうことではない。なのに、いつまでたっても具体的な問題に落とし込まれず、動くものも出来ず、プロジェクト自体が泥沼にはまってしまう。
ただ、こういう問題は、あげつらうと大したことのない話に見えるので、あとから振り返ってみたり傍から見れば「それはこうしたらいいに決まっているじゃん」と思いがちなんだけど、読むと結構ぐさぐさくる。人間、そう簡単に地雷を避けることはできない。
—
テクニカルに面白いのは、採用する技術のことごとくで地雷を踏んでいることかも。当初からマルチプラットフォームを考えていたので、Python。これはいいけど、GUIにはwxPython。ウェブは使わない。何故ならUIがイケテナイから。データの意味論にはRDFを採用。というか全面的にXMLっぽい。RDF「トリプル」とか、久々に目にしましたよ……。ストレージはP2Pでの同期を想定し、ローカルにはZopeのオブジェクト指向DB、ZODBを採用(のちにBerkeley-DBを直に叩くように書きなおし)。迷走の数年を経て最終的にはP2Pは諦め、webDAVを使った同期を採用。
いちおう弁護しておくと、プロジェクトの構想は2001年頃、実際に始動したのは2002年ぐらい。プロジェクトが迷走している間の2004年にgmailが登場し、ajaxがバズワードとして急速に広まっていくが、まともなウェブアプリをデスクトップアプリと比較するのはありえないという時代だった。
そういえば、本も終盤になったところで、とあるPythonハッカーがこのプロジェクトに参加することになって、そのコードを読んだのをもとにして「PythonはJavaじゃない」という記事を書いて揶揄したというくだりがある。著者はその中身までは紹介してなかったが、好奇心から読んでみたらおもしろかった。技術的に詳細すぎるとして著者が省いた論旨の中には、たとえばXMLの多用がある。JavaではXMLはいいものだとされている。柔軟さにかけるコードに動的な機能を与えるツールとしては便利だ。だけどPythonならコードははじめから柔軟なんだから、XMLを使う意味はない。XMLを手書きするより、Pythonのコードの書いたほうがシンプルでわかりやすい。まあ、ある程度の経験がある人なら「そりゃそうだ」と思うような話だよね。それで思い出したんだけど、本の半ばぐらいに「レイアウト情報もデータの形でストレージに入っているから、コードは何も変えなくてもデータを変えるだけでレイアウトを変更できる」技術が成果の扱いで紹介されてたんだよね。そうか、XMLか……とちと感慨にふける。
全般的に「そういう時代だった」としか言いようのないテクノロジーの組み合わせなのかもしれない。XMLとセマンティックウェブの夢。ああいう壮大で理想主義的で、確かに実現したらすごいかもしれないけど現実的の細々とした問題に目がいかない。そういう時代だったし、そういうビジョンだったのかも。
今は、壮大で巨大なプロジェクトというのが成り立ちづらくなっている時代なのかもしれない。これは野望そのものの壮大さとは関係ない。「世界を変える」のが野望だとして、そこに至るのは「なんでもできるすごいヤツ」ではなくて、むしろ「メールサービス」「TODO管理」「メモの記録」そういった小粋でニッチを埋めるようなツールなのかもしれない。小さなツールから出発し、それをうまくやりながら広がっていくパターンこそが成功の道。そういう、時代の境目に咲いた徒花のような視点で本書を読むこともできる。かも。
—
翻訳は微妙な気分になる。訳者の伊豆原弓さんは『イノベーションのジレンマ』の人でキャリアもあり、訳自体はこなれている。だけど、エンジニア以外の人が読んで楽しめる本という原書の目的に追随するために(たぶん)、中の用語は可能な限りカタカナに訳すというポリシーが採用されている。その結果、ゾープとかルシーンとか、ウェブDAVとかwxウィジェッツとかJavaスクリプトとか、思わずのけぞるような訳語が結構ある。この辺は頑張って読んでくださいとしか言いようがない感じ。
—
本書の終わりは、一応の希望を感じさせる終わり方になっている。時間はかかったし、機能もまだ素晴らしいとは言いがたいが、開発プロセスは手に入れた。ドックフードもしている。最新版のリリースにひどい遅れはなかった。プロジェクトリーダーは、色々あったけどプロジェクトには関わり続ける。資金もある。オープンソースプロジェクトには明確な完成がないことも多い。著者の取材は終わるが、プロジェクトは続いていく。
……んだけど、オリジナル版の2年後に出たペーパーバック版にたされたあとがきと、訳者あとがきで語られるプロジェクトのその後で何もかも台なしな感じ。プロジェクトは続いていくことに変わりはないけれど、戦いは終わった。勝ち負けで言えば、Chandlerは負けた。そういう時代なのかもねえ。
……というタイトルの文章を誰か書くべきだと思う。
Gitに初めて触れる人は、(分散)バージョン管理というのはこういうものだ、という認識ができているのではないか、と思った。でもGitはそれなりに特殊なスタイルのバージョン管理システムである。
バージョン管理システムというのは一義にはソフトウェア管理ツールだから(文章の版を管理するのにも使えると思うけど)、あるシステムは何らかの典型的なワークフローを前提としている。GitはLinusがLinuxの開発のために開発されたツールなので、Linuxの開発で採用されているポリシー、考え方、ワークフローが暗黙のうちに組み込まれている。そのまま他のツールに移行しようとしてもなかなかうまく行きはしないものだ。他のツールはたいてい、他の考え方を持っているものだからだ。
Gitに特有なのがブランチの使い方だ。Gitではかなり気軽にブランチを作る。ちょっとした、一日分の作業にもブランチを作り、コミットしていって、それをまとめたものをメインに組み込んだらひと通りの作業が完了という感じ。手元の作業ブランチはそのまま手元にだけ残り、そのうち消える。だが、ここまでブランチが多用されるのはGitぐらいのものだ。Mercurialではそうでもない。Darcsも違う。その違いを意識せずに同じようにブランチを作りまくると破綻する。それはツールが悪いのではなく、使い方が悪いのだ。
じゃあ、Mercurialで大規模開発をするにはどういうふうなワークフローになるのか。どうやって作業するのか。細々した問題はどうやって解決するのか。……というのに答えるには私の経験が足りないのだけど(Mercurial Queuesを使うんですかね)。
Mercurialで大規模な開発をしているプロジェクトというと何があるだろう、などとProject Using Mercurialを眺める。Goかな。Goかも。あとPython? OpenJDKだとかOpenOfficeだとかもあるね。ちょっとこのへんは調査したほうがいいのかもしれない。
githubでは、たとえばファイルリストからファイルをクリックすると、なめらかに横にスライドしてファイルリストのビューからファイルの中身のビューに遷移するような、今時のwebappとしては当たり前のようなオシャレなことをしているのだが、よく見るとURL自体も書き換わっていて、ファイルリストのURLからファイルを示すURLに変わっている。これはいいな、と思っていたのだが、こういうことをpjaxと言うのだと教えてもらった。
よくあるのはURLのfragment (#のあとの部分)を書き換えておく方法。ここはwindow.location.hashでJavaScriptから参照できるから、ページがロードされたらそこを読み取って描画を変える。難点はJavaScriptが動かないとダメだということで、そういうブラウザやwget/curlのようなツールとの相性が悪い。というよりそれ以上に深刻なのは、ソーシャルブックマークやFacebookやGoogle Buzzでページの紹介をするのとも相性が悪いところかも。こういうツールでは、サーバ側でそのページを取りに行って、ページのタイトルだとか、本文の一部だとか、画像だとかを提示してくれるわけだが、JavaScriptを実行して頑張るようなのはなかなか難しい。
だがfragmentではなくてパスそのものが変わっているなら、こういう問題は引き起こされないはずってわけだ。かっこいい! しかし、どうやってURLを変えつつページの一部だけ書き換えるようなことができるのか。window.location.href=”new URL”みたいなやり方だと、ブラウザが勝手に新しいページのロードを始めてしまう。
全く知らなかったが、HTML5では、window.historyにいくつかの拡張がされていて、pjaxはそれを使ってみたこういうのを実現する。キーはpushStateというメソッド。 window.history.pushState(data, title, url) は、ブラウザ履歴にそのURLを追加する。titleはタイトル、それと後で使う用のdataも指定できる。追加するんじゃなくて最新のを書き換えるようにreplaceStateというのもある。ちなみに、セキュリティ上の問題から、pushStateなどで足せるURLはもとのページと同じoriginでなければならない。
pjaxというのは、第一義にはjQueryのプラグインの名前だが、つまるところ、pushStateをうまく使ってajaxなwebappっぽい動作を実現するためのやり方だ。基本的な概略としてはこういう感じ:
こうして書きだしてみると、pushState以外は割と普通ですね……。URLをコピペなどした場合にはX-PJAXフィールドはないから、普通にページがロードされ、所定の役割は果たせるというわけだ。
なお、githubなどではブラウザの戻るボタンなどの場合でも逆方向スライドしたりオシャレにページ遷移している。pushStateした状態に履歴が移動するときはpopstateイベントが発生するので、こいつをとらえて同じようにハンドルすればそういうこともできるわけだ。もちろん実際には、失敗したらwindow.location.hrefを書き換えることで新しいページにちゃんと遷移させるなど、ちゃんとやるのがそれなりにめんどい部分も結構ありそうだ(なお、pushStateで渡したdataはpopstateのときに取り戻せる)。
pjaxのpがなんなのかはよくわからないが、pushStateのpなのかなあ。もはやjaxの部分はなんだかよくわからない……。ネーミングセンスに疑問はあるが(人のことは言えないが)、いずれにせよ「githubのオシャレなアレ」のことをpjaxと呼ぶのだ、といったん決めてしまえば、これは意思疎通に便利だなとは思った。
