ただのにっき

■ 「パラボラアンテナ」を移設する(またはGitHubのPost-Receive Hooksを使って自動更新)

spc.gr.jpのWikiFarm閉鎖に伴い、パラボラアンテナの行き場を探さなければいけなくなったわけだが(自業自得)、まぁ、tdtds.jpの下でよかろう、と。ただ、Wikiとしてはほとんど機能していなかったので*1、もっと静的なサイトでいいやと思っている。

というわけで、とりあえず閉鎖前に移転しておこうと思い、ダウンロードしてきた静的HTMLをちょっと整形して、移転だけでもやっておく。

1. コンテンツをGitHubで管理する

いずれ軽量CMSを作るか探すかしようと考えてはいるが、まずは静的ファイルだけにして、GitHubで管理しちゃう。プロジェクトを作って、必要なファイルをcommit & push。これをWebサーバ上でcloneすると新しいサイトのできあがり。

2. Post-Receive Hooksを使って自動的に更新する

手元の環境でいじったファイルをpushするだけで、サイトの方が自動的にpullしてくれると嬉しい。これを実現するのがGitHubのPost-Receive Hooks。Github上のリポジトリにpushがあると、指定したURLを叩いて、POSTメソッドを使ってそのpushの内容をJSON形式で教えてくれる。

ヘルプを読むと、「url」にはリポジトリのURLが含まれていそうなので、こんな感じのCGIを書いておく(JSONパーサとかいらんわ):

#!/usr/bin/ruby
require 'cgi'
cgi = CGI::new
payload, = cgi.params['payload']
puts "Content-Type: text/plain\n\n"
if payload =~ %r|"url": "http://github.com/tdtds/(.*?)[/"]| then
   open( "/home/hoge/github-hook/#{$1}", 'w' ) do |f|
      f.write( payload )
   end
end

リクエストのうち「payload」パラメタの内容を見て、urlの中のプロジェクト名のファイル名を作ってpayloadの内容を保存している。内容は別になんでもいいというか、空でもいいけどデバッグのために入れておく。

ここで直接git pullさせてもよかったんだけど、rubyバインディングであるGritにpull操作用のメソッドがない(?)みたいだったし、かといって子プロセスを起動するのも癪に障るので、トリガー用のファイルを作るだけにした。だって、何かの間違いで1秒間に100件とかpushがあったら怖いじゃん。

実際のpullは、都合よく5分に1回起きるcronタスクが設定してあったので(以前作ったJリーグ速報用)、それを使う。上で作ったトリガー用ファイルがあったらgit pullしてから、トリガーを削除する。

準備ができたら、GitHubの設定。プロジェクトのページから、Admin → Service Hooksと選ぶと、Post-Receive URLsという欄が出てくるので、そこに上で作成したCGIのURLを入力する。「Test Hook」というリンクがあるのでクリックすると、試しにリクエストを発行してくれる。「parabola」というファイルができていれば成功である。あとはcronタスクの起動を待って、pull操作が行われたことを確認すればよい。

3. 旧サイトからのリダイレクト

Wiki版の「パラボラアンテナ」は、さすがにライバルが少ないこともあり、そこそこ検索順位も高かったので、そのPageRankを引き継がない手はない。検索エンジンは301リダイレクトをすればPageRankともども引っ越してくれるはずなので、その設定をしておく。

今回、WikiNameだったページ名をすべて小文字化して末尾に「.html」を付加したので、Hikiのindex.cgiの代わりに以下のようなCGIをかましておく。

#!/usr/bin/ruby
q = ENV['QUERY_STRING']
case q
when /^[a-zA-Z0-9]+$/
   q = q.downcase + '.html'
else
   q = ''
end
puts "Status: 301 Moved Permanently"
puts "Location: http://tdtds.jp/parabola/#{q}\n\n"

これで(いちおう)引越し完了。

■ 川崎 3-1 大宮@等々力競技場

オレンジ色のチームが苦手で苦手で苦手で苦手で、前節もアウェイで清水に負けてきた川崎だが、今節もまたオレンジである。先制されたときは「あぁ、やっぱりダメか……」と思ったが、テセが同点に追いついたあとは、残り5分で2点追加の大勝利。ふー、心臓に悪い勝ち方だぜ。

ところでタイミングの悪いことに、トイレに入ってる間に谷口に決勝点を入れられて、苦笑いしながら握手を交わした見知らぬお父さん、その後、手を洗いましたか。私はちゃんと洗いました。

■ アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~(Mike Cohn)

翻訳者の角谷さんから送っていただいた。いつもありがとうございます。読むのに丸々一ヶ月かかるとか、どうかしてる。

ちょっと日記を遡ってみると、約5年前のXP祭り2004で、咳さんが「XPで一番面白いのは計画ゲーム」という発言をしていて、当時XP聞きかじり組だったおれは「ほうほう、そういうものか」と感心したものだった。なにしろXPといえばペアプログラミングやTDDばかりが取りざたされていて、計画ゲームやメタファーなんてプラクティスは、なんとなく「手の届かないもの」っぽい感じがあったものだ。

その後もしばらくは、計画ゲームはマジシャンの扱う道具で、その種明かしはベールの向こうという状況が続いていたと思う。で、計画ゲーム抜きで導入された「なんちゃってXP」が、失敗の山を築いていたわけだ。

本書は、そんなベールの向こう側をあますところなく見せてくれる。手品の種明かしがつぎつぎとなされるわけで、これは面白くないわけがない。

何がいいって、「例え話」が豊富なところがいい。まったく未知の概念を説明するのに、例え話は効果的だ。計画を頻繁に見直すことを水平線の向こうへの航海で例えてみたり、見積りの手法を家のペンキ塗りでたとえてみたりという具合。本書最後にあるケーススタディも、広い意味で例え話だと思うが、これがめっぽう面白くて、まさにクライマックス。

読んでいて、本当に隠されていたアジャイルの種明かしは「正直になること」なんじゃないかと思った。未経験者だけで集まってアジャイル開発なんてできないことを「正直に」認める。正確な見積りなんてできないことを「正直に」認める。チームメンバに、顧客に、いまわかっていることを「正直に」伝える。5年前のアジャイル本が、きれいごとを並べてばかりだったのに比べると、本書は呆れるほど正直だ。

そうしてみると従来の手法は、実に欺瞞に満ちているなぁ。できっこないとわかっているのに、最初から正確なスケジュールを求める。チームメンバの出してきた見積りをしれっと2倍にしてから上司に見せる。嘘で塗り固めた計画が、うまく運ぶわけがない。バレたら困るから、手遅れになるまで見直ししないしね。

結局、お互いに正直になれる土壌作りが、正しいアジャイルの第一歩ですよ(これが一番難しかったりして)。