Ars longa, vita brevis

鯖江市のオープンガバメント

2012-02-21T21:52:00.000+09:00

とりあえずこちらのリリース。

Dataシティさばえ（XML化の推進） - city.sabae.fukui.jp

ライセンスは、Creative Commonsの「表示」（CC BY）としています。

「Dataシティさばえ」のデータを使用していることをアプリケーション内に表示し、このページ（http://www.city.sabae.fukui.jp/pageview.html?id=11552）や、各データを公開しているページへリンクを張っていただければ、データは無料で自由にご利用いただけます。

ということで「鯖江百景の位置情報等（XML）」を手元の Google Earth に表示してみました。公開している XML を KML に変換したものです。初めから KML で公開してくれても... とかは次のステップだと思いますので、データフォーマットがどうとか、その中身がどうとかはこれから議論されていくべきことです。「行政が管理しているデータがオープンになった」という事実がまずは大切ですね。

ちょっと思ったこと

都道府県の数は47だけど、市区町村は？という問いにサッと答えられる人がどのくらいいるかは分かりませんが、ゼンリンの方がインタビューで次のように回答しています。

地図調査スタッフ (21世紀の「仕事！」論。)

全国1750市区町村のうち1740市区町村の地図を発行しています。

市区町村は合併することもありますので、この数字は不変ではありませんが、だいたい 1700〜1800 で考えておくと良さそうでしょうか。

さて、これらの市区町村が個別に Creative Commons の何らかのレベルでデータを公開してくれたとして、それぞれの市区町村のページにリンクを張るとなると大変だなぁ、というのが最初に思ったこと。もちろん、そんなアプリケーションを作るの？と聞かれれば No ですが、以前に住んでいたところの情報を見たいな〜と思うことはありますので、複数の市区町村のデータを参照したくなることもあるでしょう。

鯖江市の今回の取り組みは実証実験の意味合いが強いでしょうから、そこまで真に受ける話でもありませんが、行政組織は何かと大変なんだなぁ、と思った次第です。昨年の 3.11 から考えてみると、

そういうデータがあるなら早く公開してよ！
実験とかじゃなくて全部やってよ！

という声につながるのは容易に想像できますが、実際の現場には API エキスパートやデータサイエンティストみたいな人は少ない気がします。どういう人が取りまとめているのか分かりませんが、全国を統一的に扱えると嬉しいなぁと感じます。北海道と沖縄県で XML のタグが違う！とかにはなりませんように。

終わりに

アメリカでは Gov 2.0 というムーブメント (?) が盛り上がってきているようで、政府系のデータを一般市民が使えるようになりつつあるようです。

DATA.GOV

また、公務員同士の SNS (GovLoop - Social Network for Government) もあるらしく、情報交換も進んでいるとのこと。 (それが「うまく」機能しているかどうかは別の課題)

オーストラリアでも "government 2.0 taskforce" という取り組みがあり、 NTTデータが「オーストラリア政府による“Government 2.0”の動向」としてまとめてくれています。 2010年11月のレポートなので現在はもう少し進展しているでしょうが、オープンガバメントに関する技術面での課題で、特に次の２点はどこの政府も直面する問題だと考えられます。

複数の政府機関の間でデータが個別に作成されているため、重複が多数存在し、一般市民にとっての利便性が低くなっている
各政府機関の間で使用されているデータフォーマットや規格が統一されていないため、一般市民にとっての利便性が低くなっている

話が戻って鯖江市。 XML はマイクロソフト社のソフトウェア (Excel か Access か SQL Server 辺り？) を使って出力しているようで、名前空間にその名残が見えます。ベンダーロックオンされないようにどうこうとかは望みませんが、なんとか RDF などの形式に沿って出力して頂けると嬉しいところです。ともあれ、緯度経度があって英語表記 (name) と日本語表記 (localname) がありますので使いどころは多そうですね。まずは「透明性」ということで。難しいのは継続性。

オープンガバメントの推進！地元鯖江から世界へ #html5 #sabae #opengov

デブサミ2012に行ってきた

2012-02-21T08:15:00.000+09:00

デブサミ2012 (Developers Summit 2012) に行ってきました。概要ページには次の記述があります。

厳しい経営環境の中で、企業が教育や研修の機会を維持していくのも、非常に困難な状況となっているようです。

みんなが活き活きとして研修に参加する状況も見たことがありませんので、研修の機会が減るのは当然の流れなんだろうな、と感じています。

当日にはたくさんのトラックがありましたが、個人的には角谷さんの話が最も印象的でした。どうやってソフトウェアを開発していくか？という手法というか心構えのような話です。こうしたことを常に問い直し続けられると、特別に研修とかしなくても良いのかなと思いました。

なんとなく動くプログラムを書くには本を読むなりインターネットで調べれば良い話ですが、製品やサービスを作る、運用して改善を続ける、という話になると、人や組織に特有の事情も関係してきます。「こうすれば良い！」という回答を求めたがる人もいますが、基本的には変化に適応していくしかないわけで、後から振り返れば無駄だったとしても、色々とやってみるしかないわけですね。要するに適者生存。

以下、自分が参加したセッションのメモや感想などです。

１日目 - 2/16

node.jsテクノロジースタック for ソーシャルアプリケーション

「ソーシャルアプリケーション」ならではという感じはなく、 Node.js を使ったアプリケーション構築方法の紹介といった感じ。比較対象として PHP が繰り返し登場していたのが GREE っぽい。

クライアントサイド、サーバーサイド API、ストレージ (Redis) とのデータ交換を統一的なコーディングスタイルで扱いたい、という感じの説明が最後にあった。 Node.js を使うと言語は統一できるので、以前にニュースサイトで読んだ Facebook における Node.js への取り組みと似たような雰囲気。

Node.js のコア部分まで読んでいるらしく、PHP に疲れたんだろうなぁ、というのが個人的な感想。

講演中のメモ:

会場 (100人以上いる) の８割くらいの人は Node.js を書いたことがあるみたい。
Node は処理が高速でノンブロッキングですよ、という流れ。 Webアプリならクライアントとサーバで同じ言語で書けるよね、という部分は入ってない。
GREEでは、自分たちでソースコードまで追いかけて管理してるらしい。低レイヤーまで読む必要があるのは変わらないので、開発者のモチベーションが一番の要因か。
アプリケーションでデータ制約を課せるように実装。 SQL を文字列で書くとタイプミスが混入してしまうので、DSL でラップしてあげている。

参考: Facebok における Node.js

Node.js at Facebook - Why it's Needed and What's Holding it Back - readwriteweb.com

Cloud Foundryで変わるこれからのクラウドアプリケーション開発

クラウドのホスティング環境としては比較的後発の Cloud Foundry の話。特定ベンダーにロックインされないようにしてくださいね (ふたつ目の選択肢としてウチを)、という感じ。 AWS 一択だと AWS に障害があるとサービス全断なので、クラウド環境を複数所有しておけば可用性の高いシステムを構成できるかも!?

講演中のメモ:

Cloud Foundry の人の話が交互通訳なので、進行スピードが半分くらいのイメージ。
会場アンケートだと .NET 開発者が意外と多い気がする。
クラウドスタックを多角的に眺め直してみる。アナリストだったら？導入数別だと？開発者から見ると？中立的に考えるとインフラもプラットフォームもサービスも同じようなウェイト。なお、クラウドスタックは SaaS - Service, PaaS - Platform, IaaS - Infrastructure の３つ。
ソフトウェアもファッションのようにサイクルが目まぐるしくなってきており、ソフトウェア開発のサイクルが短くなってきている。以前はビルドマスター、リリース担当者がいたかもしれないが、アプリケーション開発者がビルドを意識せずに自分でリリースできると工程を削減できる。結果として、開発サイクルの高速化を期待できる。
最後にアンケートに答えて T シャツと USB メモリをもらった。

プレゼン中に登場した参考リンク:

Welcome to the Jungle
Software G-Forces - slideshare.net (KentBeck)

3・11から見えた社会基盤としてのIT

昨年の震災のクライシスレスポンスの話。情報を次のようにレイヤー分けしてディスカッションが進んだ。

情報処理
情報流通
情報基盤

「人間×情報×社会＝価値」と考え、社会資本における情報という切り口はこのセッションならでは。ソフトウェア開発が建築から学ぶことはいつまでも多いと思う。また、情報を伝える (Communication) ことと、情報を処理する (Computing) ことの両方の話題が絡み合っていることが刺激的。

どうやって開発するか？というセッションが多い中、そもそも何を作るべきか？という根本的な話題のディスカッション。震災から１年が経過しようとしているが、復興への取り組みは始まったばかり。何が必要とされるか？という問題は現地に行ってみないと分からない。しかも、課題は非常にローカルな問題に落とし込んで対処しないと意味がない。

10年前のデブサミでは考えられなかったようなセッションだが、「10年後も世界で通じるエンジニアであるために」というタイトルの通りだと思った。今は予想もできないことが10年後には起こるかもしれない。

講演中のメモ:

「地震があったらNTTの局社に逃げ込め」という通説があるらしい。去年の3.11では地震には耐えられたけど津波には耐えられなかった。結果、ケータイでも連絡とれず。
アメリカの公務員向け SNS として GovLoop - Social Network for Government - を紹介。
「全ての災害は防げるのだろうか。それとも、災害とともに生きるのだろうか。」建築でのアプローチにおける文脈で登場。特に分野を限定しない考え方である。
all or nothing ではなく、グレードを区切って意思決定を支援する。なんでもかんでも防波堤を作れば良いってもんじゃない。現実的な問題としては、うまくグレードを定義できる人が不足しているかもしれない。
避難用に作った模型を共有するときに、行政に持って行くと市長室に飾られてしまって誰も見ない。むしろ神社とかに置いた方がみんなで情報を共有できる。情報共有を支援するために IT を使えると嬉しい。
ルールがあって設計するのではなく、シミュレーションしながら設計する。パラメータのチューニングで試行錯誤していく。ソフトウェア開発の文脈で言うならアジャイルな感じ。

２日目 - 2/17

言語の世界

Ruby のまつもとさんの話。立ち見がたくさんいるくらいの大盛況。 Ruby がどうこうという話ではなく、歴史を紐解いてこれからを予測する流れ。 1960年くらいの時代から10年区切りくらいで2000年過ぎまでをタイムスケープ。これから重要になりそうな考え方としては、並列処理、分散処理、統計処理、宣言的記述を取り上げていました。

講演中のメモ:

AWSに計算リソースが「集中」するけど、その中では「分散」してるよね、という話が分かりやすい。
今のままで実現できることはそのまま続ければいい。でも、新しいパラダイムが登場したときは「未来の言語」みたいなものが欲しくなる。まつもとさんの予想では Erlang, Node.js, R, SQL などが発展したようなイメージ。

プログラミング言語の歴史に関してはたくさんの読み物があります。自分が使用している処理系が何に由来しているかを学ぶことで、得意なこと、不得意なことが分かるかもしれません。少なくとも、多くのプログラミング言語を習得している方が要所要所の選択肢は増えますので、知らないよりは知っている方が断然良いでしょう。

プログラミング言語年表 - wikipedia.org
第1回　サルでも分かるプログラミング言語の新潮流【前篇】 (1/2) - itmedia.co.jp
The History of Programming Languages - oreilly.com

アジャイルマニフェストディケイド

アジャイルマニフェストから11年。これまでの振り返りだけでなく、「どうやって」チームを構成していくか？という話も。オープンソースの世界からプロジェクトの進め方を学ぶ、という姿勢が鮮明に打ち出されており、講演内容が非常に具体的で分かりやすかった。

講演中のメモ:

Christopher Alexander のプロセスに関してはこの本 - The Process of Creating Life
ウォーターフォールからアジャイルへの流れは、プロジェクトの進め方が違うというだけでなく、個々人が自立しないといけないよね、という話。やるべきことを自分で考えて漂流しないようにしないと、という言い方に納得。
「コードがドキュメントだ」のオリジナル記事 - CodeAsDocumentation
朝会での報告は単なる問題の羅列でなく、ストーリー性を持たせると各人が考える力を鍛えられる。「昨日は世界をどう変えたか？」「そのための阻害要因は何か？」
Q.「ユニットテストは何を書けば良いですか？」A.「変更に適応できるようにしといてね。」

「変更に強いソフトウェア」を作るためには、あれこれと考える必要がありますね、という話でした。自分にとっては何となくモヤモヤっとしていた部分をうまく言葉で表現してもらえた感じで、とても印象的なセッションでした。去年５月の「アジャイルスタートアップ」というイベントで Pivotal Labs の CTO の話を聞いたときよりはイメージが具体化しました。後は周囲の人とどうやって進めていくか、という部分なのかなぁと思います。

アジャイルスタートアップの後で思ったこと

Building scalable web apps

デモを交えて Heroku の紹介。デモのコードネームは bushido (武士道)。スピーカーは外国人で英語での発表でしたが、日本でのイベントのために作った、という点が非常に優しいなぁと思いました。

講演中のメモ:

Heroku だと logging as a service があるらしい。
アプリケーションのエラーを適切にレポートしてくれると確かに良い。ついでに自動的に BTS に登録してくれると嬉しい。
デモアプリ - http://devsumi2012-demo.herokuapp.com/ - ハッシュタグ (#devsumi) を拾う。

クラウドを使った開発については、こちらの記事を紹介。

The Twelve-Factor App

終わりに

２日間とも半日ずつの参加でしたが、いろいろと刺激になったイベントでした。「クラウド」と「アジャイル」は言葉としてもう少しフワフワしているでしょうが、何年かすれば当たり前のことになっていくと思います。サイクルを回す、要するにフィードバックを受け入れながら継続して開発する、というスタイルを無意識に実践できるチームを形成できると良いんだろうなぁと感じました。

waf を使って Sphinx で生成した HTML を ZIP にまとめる

2012-02-16T20:33:00.001+09:00

ビルドツールである waf を使って、 Sphinx で生成した HTML ファイルを ZIP 形式にまとめるメモです。

コマンドラインで次のように実行すると、Sphinx でビルドして ZIP が作成されます。

$ waf configure build dist

(出力省略)

New archive created: sphinx-project-1.0.0.zip
'dist' finished successfully (7.701s)

Sphinx に関してはこちらの記事でも紹介されています。

Sphinx を活用し、適切に構成されたドキュメントを容易に作成する (IBM developerWorks)

Sphinx は Python で作成されており、元々は Python 言語のドキュメント作成用に作られたものですが、必ずしもドキュメント作成の対象言語を Python のみに限定しているわけではありません。場合によってはプログラマーの作成するドキュメントのみが対象というわけですらありません。 Sphinx の利用者は数多くおり、本をまるごと Sphinx で執筆する人もいます。

環境の準備

まずは Sphinx と waf を使えるようにします。 virtualenv で独立した環境を作成し、ツールをインストールします。

$ virtualenv --distribute waf-sphinx
$ cd $_
$ cat <<EOF >requirements.txt
Sphinx
EOF
$ . bin/activate
$ pip install -r requirements.txt
$ curl http://waf.googlecode.com/files/waf-1.6.11 >bin/waf
$ chmod +x bin/waf

Sphinx でプロジェクトを作成したり、何らかのドキュメントを構成する方法は冒頭の IBM developerWorks の記事を参照してください。

wscript を書く

wscript は make における Makefile のようなものです。関数がアクションになります。デフォルトで定義されているアクション名の関数を定義するのが基本的な記述になります。ここでは次の３つの関数を定義します。

configure: ツールが存在することを確認する
build: 処理を実行する
dist: パッケージにまとめる

wscript

APPNAME = 'sphinx-project'
VERSION = '1.0.0'

def configure(ctx):
    ctx.find_program('sphinx-build')

def build(bld):
    # Sphinx 用のテキストは doc/ ディレクトリにあると仮定。
    bld.exec_command(['make', 'html'], cwd='doc')

def dist(ctx):
    ctx.algo = 'zip'
    ctx.files = ctx.path.ant_glob(['doc/build/_html/**/*'])
    ctx.base_path = ctx.path.find_dir('doc/_build/html')

順番に実行していきます。

$ waf configure
$ waf build
$ waf dist
New archive created: sphinx-project-1.0.0.zip
'dist' finished successfully (7.701s)

APPNAME と VERSION で指定した ZIP アーカイブができました。 ctx.algo のデフォルトは bz2 なので、圧縮効率を高めたい場合には何も指定しなければ自動的に処理してくれます。 base_path を指定することで、特定のディレクトリ以下のファイルに絞ってアーカイブを作成できます。何も指定しない場合は、カレントディレクトリ以下のファイルが対象になります。バックアップファイルやオブジェクトファイルなど、除外するものとして有名な拡張子は対象外となります。 excl で明示することも可能です。たとえば、Sphinx で生成した場合はソースを含めない、といったカスタマイズも可能です。

終わりに

探してみると英語のフォーラムにも似たような投稿がありました。だいたいの人が考えることは一緒、と。

dist: having trouble creating zip files without the folder

wscript を記述するときは API ドキュメントを読みながら、というのがちょっと大変かもしれませんね。

Scripting (Waf v1.6.8 documentation)

サクッと ZIP にまとめられると嬉しいなぁ、と思っていたので、自分としては結構嬉しい発見でした。

Buildbot を使ってみる

2012-02-07T00:56:00.000+09:00

Buildbot はソフトウェア開発におけるチェックアウト、ビルド、テストというサイクルの自動化を支援してくれます。 Python 自体の継続ビルドや、Chronium のビルドツールとして利用されています。

Buildbot の概要についてはこちらの記事にまとめられています。 (実際のコードはちょっと古くなってしまっています)

Buildbot による継続的インテグレーション - IBM developerWorks

Note

この記事は、Python の学習資料の中に盛り込もうとしたけど難しそうだからやっぱりやめた、というもので、結論や発展性はありません。要するに書きかけの没ネタです。 (何かのメモになれば)

これまでのまとめ :

Buildbot をインストールする

まずはソフトウェアをインストールします。 pip を使ってインストールできます。

$ virtualenv --distribute buildbot-sample
$ cd buildbot-sample
$ source bin/activate
(buildbot-sample) $ pip install buildbot

bin ディレクトリ (Windows の場合は Scripts フォルダ) に buildbot コマンドがインストールされます。

virtualenv って何？という場合は環境構築の資料を見直してください。

マスターノードを作成する

次に、マスターノードを作成します。

(buildbot-sample) $ buildbot create-master master
mkdir /Users/shigeru/projects/buildbot-sample/master
chdir /Users/shigeru/projects/buildbot-sample/master
creating master.cfg.sample
populating public_html/
creating Makefile.sample
creating database
buildmaster configured in /Users/shigeru/projects/buildbot-sample/master

設定ファイルや起動スクリプトなどが生成されます。 master の中を見てみましょう。

(buildbot-sample) $ ls master/
Makefile.sample  buildbot.tac     master.cfg.sample       public_html/     state.sqlite

設定ファイルはサンプルになっていますので、 .sample を取り除いたものに変更します。

(buildbot-sample) $ mv master/master.cfg.sample master/master.cfg

このサンプル設定で起動させてみます。 (Pyflakes というツールのレポジトリを監視する設定になっています)

(buildbot-sample) $ buildbot start $VIRTUAL_ENV/master
Following twistd.log until startup finished..
2012-02-02 23:56:01+0900 [-] Log opened.
2012-02-02 23:56:01+0900 [-] twistd 11.0.0 (/Users/shigeru/projects/buildbot-sample/bin/python 2.7.1) starting up.
2012-02-02 23:56:01+0900 [-] reactor class: twisted.internet.selectreactor.SelectReactor.
2012-02-02 23:56:01+0900 [-] Applying patch for http://twistedmatrix.com/trac/ticket/5079
2012-02-02 23:56:01+0900 [-] Creating BuildMaster -- buildbot.version: 0.8.5
2012-02-02 23:56:01+0900 [-] loading configuration from /Users/shigeru/projects/buildbot-sample/master/master.cfg
2012-02-02 23:56:01+0900 [-] configuration update started
2012-02-02 23:56:02+0900 [-] setting database journal mode to 'wal'
2012-02-02 23:56:02+0900 [-] Using SQLite Version (3, 7, 5)
2012-02-02 23:56:02+0900 [-] twisted.spread.pb.PBServerFactory starting on 9989
2012-02-02 23:56:02+0900 [-] Starting factory <twisted.spread.pb.PBServerFactory instance at 0x107f08488>
2012-02-02 23:56:02+0900 [-] adding new builder runtests for category None
2012-02-02 23:56:02+0900 [-] trying to load status pickle from /Users/shigeru/projects/buildbot-sample/master/runtests/builder
2012-02-02 23:56:02+0900 [-] no saved status pickle, creating a new one
2012-02-02 23:56:02+0900 [-] added builder runtests in category None
2012-02-02 23:56:02+0900 [-] setBuilders._add: [<buildbot.process.botmaster.BuildRequestDistributor instance at 0x107cf6950>, <BuildSlave 'example-slave', current builders: >] ['runtests']
2012-02-02 23:56:02+0900 [-] adding IStatusReceiver <WebStatus on port tcp:8010 at 0x107d43128>
2012-02-02 23:56:02+0900 [-] buildbot.status.web.baseweb.RotateLogSite starting on 8010
2012-02-02 23:56:02+0900 [-] Starting factory <buildbot.status.web.baseweb.RotateLogSite instance at 0x107f590e0>
2012-02-02 23:56:02+0900 [-] Setting up http.log rotating 10 files of 10000000 bytes each
2012-02-02 23:56:02+0900 [-] WebStatus using (/Users/shigeru/projects/buildbot-sample/master/public_html)
2012-02-02 23:56:02+0900 [-] removing 0 old schedulers, updating 0, and adding 1
2012-02-02 23:56:02+0900 [-] adding 1 new changesources, removing 0
2012-02-02 23:56:02+0900 [-] gitpoller: using workdir '/Users/shigeru/projects/buildbot-sample/master/gitpoller-workdir'
2012-02-02 23:56:02+0900 [-] gitpoller: initializing working dir from git://github.com/buildbot/pyflakes.git
2012-02-02 23:56:02+0900 [-] configuration update complete
The buildmaster appears to have (re)started correctly.

マスターが起動すると、プロセスIDが書かれたファイルとログファイル、レポジトリをポーリングする作業用ディレクトリ、それからテストディレクトリが生成されます。

(buildbot-sample) $ ls master/
Makefile.sample    gitpoller-workdir/ master.cfg         runtests/          twistd.log
buildbot.tac       http.log           public_html/       state.sqlite       twistd.pid

マスターの情報は HTTP で閲覧できます。 master.cfg の buildbotURL というパラメータを確認します。

(buildbot-sample) $ grep buildbotURL master/master.cfg
# the 'buildbotURL' string should point to the location where the buildbot's
c['buildbotURL'] = "http://localhost:8010/"

Webブラウザで確認すると、以下のように表示できるはずです。

スレーブノードを作成する

次に、スレーブを設定します。まずはスレーブ用のソフトウェアをインストールします。 (buildslave というコマンドがインストールされます)

(buildbot-sample) $ pip install  buildbot-slave

スレーブからマスターに接続します。ユーザー名とパスワードは master.cfg に書かれているものに揃えます。まずは確認しましょう。

(buildbot-sample) $ grep "'slaves'" master/master.cfg
# The 'slaves' list defines the set of recognized buildslaves. Each element is
c['slaves'] = [BuildSlave("example-slave", "pass")]

続いて buildslave コマンドでディレクトリを作成し、接続します。

(buildbot-sample) $ buildslave create-slave slave localhost:9989 example-slave pass
mkdir /Users/shigeru/projects/buildbot-sample/slave
chdir /Users/shigeru/projects/buildbot-sample/slave
mkdir /Users/shigeru/projects/buildbot-sample/slave/info
Creating info/admin, you need to edit it appropriately
Creating info/host, you need to edit it appropriately
Not creating info/access_uri - add it if you wish
Please edit the files in /Users/shigeru/projects/buildbot-sample/slave/info appropriately.
buildslave configured in /Users/shigeru/projects/buildbot-sample/slave

(buildbot-sample) $ buildslave start $VIRTUAL_ENV/slave
Following twistd.log until startup finished..
2012-02-03 00:21:49+0900 [-] Log opened.
2012-02-03 00:21:49+0900 [-] twistd 11.0.0 (/Users/shigeru/projects/buildbot-sample/bin/python 2.7.1) starting up.
2012-02-03 00:21:49+0900 [-] reactor class: twisted.internet.selectreactor.SelectReactor.
2012-02-03 00:21:49+0900 [-] Starting BuildSlave -- version: 0.8.5
2012-02-03 00:21:49+0900 [-] recording hostname in twistd.hostname

The buildslave took more than 10 seconds to start, so we were unable to
confirm that it started correctly. Please 'tail twistd.log' and look for a
line that says 'configuration update complete' to verify correct startup.

マスターとスレーブのログを見ると、お互いを認識できていることが分かります。

(buildbot-sample) $ tail {master,slave}/twistd.log
==> master/twistd.log <==
2012-02-03 00:11:03+0900 [-] gitpoller: no changes, no catch_up
2012-02-03 00:16:02+0900 [-] gitpoller: polling git repo at git://github.com/buildbot/pyflakes.git
2012-02-03 00:16:04+0900 [-] gitpoller: no changes, no catch_up
2012-02-03 00:21:02+0900 [-] gitpoller: polling git repo at git://github.com/buildbot/pyflakes.git
2012-02-03 00:21:06+0900 [-] gitpoller: no changes, no catch_up
2012-02-03 00:22:19+0900 [Broker,0,127.0.0.1] slave 'example-slave' attaching from IPv4Address(TCP, '127.0.0.1', 58503)
2012-02-03 00:22:19+0900 [Broker,0,127.0.0.1] Starting buildslave keepalive timer for 'example-slave'
2012-02-03 00:22:19+0900 [Broker,0,127.0.0.1] Got slaveinfo from 'example-slave'
2012-02-03 00:22:19+0900 [Broker,0,127.0.0.1] bot attached
2012-02-03 00:22:19+0900 [Broker,0,127.0.0.1] Buildslave example-slave attached to runtests

==> slave/twistd.log <==
2012-02-03 00:21:49+0900 [-] twistd 11.0.0 (/Users/shigeru/projects/buildbot-sample/bin/python 2.7.1) starting up.
2012-02-03 00:21:49+0900 [-] reactor class: twisted.internet.selectreactor.SelectReactor.
2012-02-03 00:21:49+0900 [-] Starting BuildSlave -- version: 0.8.5
2012-02-03 00:21:49+0900 [-] recording hostname in twistd.hostname
2012-02-03 00:22:19+0900 [-] Starting factory <buildslave.bot.BotFactory instance at 0x105243878>
2012-02-03 00:22:19+0900 [-] Connecting to localhost:9989
2012-02-03 00:22:19+0900 [Broker,client] message from master: attached
2012-02-03 00:22:19+0900 [Broker,client] SlaveBuilder.remote_print(runtests): message from master: attached
2012-02-03 00:22:19+0900 [Broker,client] Connected to localhost:9989; slave is ready
2012-02-03 00:22:19+0900 [Broker,client] sending application-level keepalives every 600 seconds

Webブラウザでマスターを確認すると、スレーブノードが増えています。

ビルドを実行する

Webブラウザの方からスレーブノードを選択して辿って行くと、ビルドできるようになっています。実際にビルドしてみると、右のスクリーンショットのような結果を得られます。 (よく分からない場合は、リンクをぽちぽちとクリックしてみましょう)

それぞれのステップの標準出力などは記録されており、後からすべてを確認できます。

これでセットアップと動作確認は終わりました。プロジェクト個別の設定は、プロジェクトサイトにあるドキュメントを参照してください。

終わりに

ソフトウェアを開発する上で、CI (Continuous Integration) をサポートするツールも使えた方が良いことは間違いないでしょう。しかし、ソフトウェアの依存性が複雑だったり、対象とするツールの範囲が広いことなどもあり、導入するにはそれなりに知識が必要なだったりもします。

それでは専任のビルドスレーブな人を育成しましょう、という流れもあるかもしれませんが、チーム開発における CI は個々のチームメンバーの理解があってこそです。知識は勉強すれば何とかなりますが、ツールを導入することによってどのような効果が見込めるのか？という部分を共有できるか否かが一番の肝だったりします。

このため、トップダウンで開発手法を改善しても早晩に形骸化してしまうのかな、と。

Buildbot はマルチプラットフォームに対応するソフトウェアの CI には良い選択肢だと思いますが、そもそもそんなソフトウェアが多くはないかもなぁ〜というのが、没ネタにした理由です。とりあえずは Jenkins を導入した方が管理やメンタルモデルの適応は簡単そうです。

あと蛇足になりますが、Buildbot は低レイヤーで Twisted を使っています。 Twisted に関してはこの辺を参考にしてください。

Twisted 入門

Python の学習資料 - 3

2012-01-30T22:17:00.000+09:00

Python の学習資料を追記しました。

Python School 1.2.1 documentation

社内で勉強会をやってみるとたまに質問がきますので、一般的なレベルに落とし込んでまとめた内容になります。特に連続性はありませんが、知っていると便利なときがあるかもしれない、というものたちです。基本的にリンク紹介とも言えます。

個人的には json.dump() の ensure_ascii 引数を知りませんでしたが、日本語を含んだ JSON を整形するときには重宝すると思います。

追加内容

デコレータ

組み込みデコレータ
デコレータのいろいろ

モジュールのインポート方法いろいろ

標準モジュールのインポート
サードパーティモジュールのインポート
自作ライブラリのインポート
Python のバージョン違いを考慮したインポート

ネットワークプログラミング

HTTP でダウンロード
HTTP のレスポンス処理

Web API

Twitter API

Tips

モジュールの実行
日本語を扱うときに便利なこと

終わりに

「デコレータのいろいろ」に記載したリンク先の記事を読み直してみると、デコレータの経緯はややこしいんだなぁ、と思いました。入門レベルからは一気にジャンプアップしてしまいますが、時間ができたら読んでみると良いのではないでしょうか。

あと、既存のページもディレクトリレイアウトを変更しました。これに伴い、各ページの URL は変更になっています。 (個別のページにリンクを張ってることもないだろうけど)

Solr に Wikipedia のデータをインポートする

2012-01-23T08:23:00.002+09:00

テスト用によくあるパターンですので、Solr に Wikipedia のデータをインポートする手順をメモしておきます。

方法は大きく３つあります。

DIH (Data Import Handler) を使う。
自前で XML を解析して /update ハンドラに投げる。
MySQL などに一旦インポートして、そこから DIH を使う。

ここでは Solr Wiki にも記載されている DIH を使ってインポートします。

Data Import Request Handler > Example: Indexing wikipedia (Solr Wiki)

Wikipedia のデータをダウンロードして解凍する

Wikipedia はダンプデータを公開してくれていますので、 jawiki-latest-pages-articles.xml.bz2 をダウンロードします。ページの概要だけが欲しい場合には jawiki-latest-abstract.xml をダウンロードします。

Index of /jawiki/latest/ - dumps.wikimedia.org

$ curl -O http://dumps.wikimedia.org/jawiki/latest/jawiki-latest-pages-articles.xml.bz2
$ bunzip2 jawiki-latest-pages-articles.xml.bz2
$ ls -lh jawiki-*
-rw-r--r--  1 shigeru  staff   1.2G Jan 18 01:32 jawiki-latest-abstract.xml
-rw-r--r--  1 shigeru  staff   5.7G Jan 18 01:55 jawiki-latest-pages-articles.xml

Solr の設定ファイルを変更する

Wikipedia のデータを保存するスキーマを定義します。 Solr Wiki を参考にして、次の３つのファイルを編集します。 DIH の設定ファイルは wikipedia-data-import.xml とします。

solrconfig.xml: DIH のハンドラを追加する。
schema.xml: スキーマを定義する。
wikipedia-data-import.xml: Wikipedia のダンプデータを Solr のスキーマにマッピングする。

solrconfig.xml で /dataimport へのアクセスを DataImportHandler に処理させます。

  <!-- Data Import Handler for Wikipedia dump data.
  -->
  <requestHandler name="/dataimport" class="org.apache.solr.handler.dataimport.DataImportHandler">
    <lst name="defaults">
      <str name="config">wikipedia-data-config.xml</str>
    </lst>
  </requestHandler>

schema.xml で次のフィールドを定義します。

id: ページの ID
title: ページのタイトル
revision: ページのリビジョン
user: ページの作成者名
userId: ページの作成者の ID
text: ページの本文
timestamp: ページの最終更新時刻

   <field name="id"        type="int"      indexed="true"  stored="true" required="true" /> 
   <field name="title"     type="string"   indexed="true"  stored="true" required="true" />
   <field name="revision"  type="int"      indexed="false" stored="true" />
   <field name="user"      type="string"   indexed="true"  stored="true" />
   <field name="userId"    type="int"      indexed="false" stored="true" />
   <field name="text"      type="text_cjk" indexed="true"  stored="true" required="true" />
   <field name="timestamp" type="date"     indexed="true"  stored="true" default="NOW" multiValued="false"/>
   <field name="titleText" type="text_cjk" indexed="true"  stored="true"/>

wikipedia-data-import.xml で XML と Solr のフィールドへのマッピングを定義します。 <entity> 要素の url 要素で XML ファイルのパスを指定します。ここでは自分のホームディレクトリ直下を指定しています。

<dataConfig>
        <dataSource type="FileDataSource" encoding="UTF-8" />
        <document>
        <entity name="page"
                processor="XPathEntityProcessor"
                stream="true"
                forEach="/mediawiki/page/"
                url="/Users/shigeru/jawiki-latest-pages-articles.xml"
                transformer="RegexTransformer,DateFormatTransformer"
                >
            <field column="id"        xpath="/mediawiki/page/id" />
            <field column="title"     xpath="/mediawiki/page/title" />
            <field column="revision"  xpath="/mediawiki/page/revision/id" />
            <field column="user"      xpath="/mediawiki/page/revision/contributor/username" />
            <field column="userId"    xpath="/mediawiki/page/revision/contributor/id" />
            <field column="text"      xpath="/mediawiki/page/revision/text" />
            <field column="timestamp" xpath="/mediawiki/page/revision/timestamp" dateTimeFormat="yyyy-MM-dd'T'hh:mm:ss'Z'" />
            <field column="$skipDoc"  regex="^#REDIRECT .*" replaceWith="true" sourceColName="text"/>
       </entity>
        </document>
</dataConfig>

余計な記述も多いですが、ファイルは次のリンクにあります。 (github)

インポートする

Solr を起動したら管理画面を表示させます。 4系からは管理画面が刷新されて、マルチコアにした場合の視認性が向上します。

DataImport の部分を確認し、entity をしてインポートを実行します。インポート中はステータスを確認するようになっており、進捗状況が分かります。

すべてのインポートが終わると処理件数が表示されます。実際に検索してみて、確かにヒットすることを確認しておきます。

$ curl "http://localhost:8983/solr/wikipedia/select?q=東京都&wt=json&indent=true&rows=2"
{
  "responseHeader":{
    "status":0,
    "QTime":0,
    "params":{
      "indent":"true",
      "wt":"json",
      "q":"東京都",
      "rows":"2"}},
  "response":{"numFound":92823,"start":0,"docs":[
      {
        "id":23340,
        "timestamp":"2003-11-02T01:45:21Z",
        "revision":2191172,
        "title":"東京市と都",
        "titleText":"東京市と都",
        "text":"#redirect [[東京都]]",
        "userId":490,
        "user":"秀の介"},
      {
        "id":321811,
        "timestamp":"2005-09-05T23:11:51Z",
        "revision":2899301,
        "title":"東京都の市区町村",
        "titleText":"東京都の市区町村",
        "text":"#REDIRECT[[東京都]]"}]
  }}

マルチコアの設定

久しぶりに Solr のマルチコア設定をしたら JAR のパス解決に手こずりました。個別の solrconfig.xml に <lib> タグを記述しても良いとは思いますが、 solr.xml の <solr> タグの sharedLib 属性でパスを指定することで解決しました。

Quick Review: What are Multiple Cores? (Solr Wiki)

今回は example ディレクトリの隣にある multicore ディレクトリに wikipedia という場所を作り、 solr.xml を編集しました。

ディレクトリ構成は次のようになります。

$ tree -L 1 multicore
multicore
├── README.txt   <-- 配布パッケージに含まれる
├── core0        <-- 配布パッケージに含まれる
├── core1        <-- 配布パッケージに含まれる
├── exampledocs  <-- 配布パッケージに含まれる
├── lib          <-- コアで共有する JAR を置く
├── solr.xml     <-- コアの設定ファイル
└── wikipedia    <-- 自分で追加

他のインデクスデータと混ぜたくない場合 (テスト用など)、そもそもスキーマが異なる場合には、コアを変えて管理すると便利です。

終わりに

Solr に Wikipedia のデータをインポートしました。データのダウンロードとインポートで、それぞれ数時間くらいはかかると考えた方が良いでしょう。部屋の掃除などをしながら、気長に作業する感じでしょうか。

実際にどのような検索軸で遊んでみるかは、こちらの記事が参考になると思います。

SolrにWikipediaのデータを入れて遊ぶ

また、別の話題になってしまいますが、ベンチマークなどではそれなりにたくさんのデータが必要になります。英語のデータばかりではありますが、こうした記事でまとめてくれるのは嬉しいですね。

10 sites to get the large data set or data corpus for free

Solr の trunk を使ってみる

2012-01-15T08:49:00.004+09:00

調べ物をするときにソースコードがあった方が便利な場合もありますので、 Lucene/Solr の trunk のソースコードを取得して動かしてみます。

Apache Solr

Java と Ant と Subversion はインストール済とします。

ソースコードをチェックアウトする

ASF のプロジェクトのお作法に従ってチェックアウトします。詳しくはこちらのページを参照。

Source Code Repository - apache.org

$ svn co http://svn.apache.org/repos/asf/lucene/dev/trunk lucene-solr

(出力省略)

中身を確認しておきます。

$ cd lucene-solr/
$ ls
README.txt  build.xml   dev-tools/  lucene/     modules/    solr/

ソースコードをビルドする

build.xml のターゲットを確認しておきます。

$ grep "<target" build.xml
  <target name="test" description="Test both Lucene and Solr" depends="validate">
  <target name="javadocs" description="Generate Lucene and Solr javadocs">
  <target name="validate" description="Validate dependencies, licenses, etc.">
  <target name="compile" description="Compile Lucene and Solr">
  <target name="get-maven-poms"
  <target name="generate-maven-artifacts" description="Generate Maven Artifacts for Lucene and Solr">
  <target name="eclipse" description="Setup Eclipse configuration">
  <target name="idea" description="Setup IntelliJ IDEA configuration">
  <target name="clean-idea"
  <target name="clean" description="Clean Lucene and Solr">

compile でコンパイルしてくれますので、これを実行してしばらく待ちます。一応、時間も計測しておきましょう。(Ant 自体が時間を出力するので、 time コマンドはなくても良い。)

$ time ant compile

(出力省略)

BUILD SUCCESSFUL
Total time: 58 seconds

real    0m58.528s
user    1m16.734s
sys     0m7.490s

次に、Solr の example 用に必要なファイルをコピーします。

$ cd solr
$ time ant example

(出力省略)

example:
     [copy] Copying 1 file to /Users/shigeru/workspace/lucene-solr/solr/example/webapps
      [jar] Building jar: /Users/shigeru/workspace/lucene-solr/solr/example/exampledocs/post.jar
     [echo] See /Users/shigeru/workspace/lucene-solr/solr/example/README.txt for how to run the Solr example configuration.

BUILD SUCCESSFUL
Total time: 25 seconds

real    0m26.300s
user    0m36.986s
sys     0m4.495s

最後の echo 部分で「README.txt を見てね」と出力されていますので、読んでおきましょう。

サンプルを動かしてみる

example ディレクトリにサンプルがありますので、これを使って簡単なテストを実施します。 README.txt に書かれていることでもあります。

Jetty を使って起動する

example ディレクトリに移動して起動させます。

$ cd example
$ java -jar start.jar

(出力省略)

2012-01-14 22:42:16.215:INFO::Started SocketConnector@0.0.0.0:8983

最後に、8983番ポートで待ち受けているログが出力されていますね。

管理画面を表示する

ブラウザで "http://localhost:8983/solr/admin/" にアクセスすると管理画面を表示できます。設定ファイルの表示や、クエリの確認などができます。

インデクスを追加する

example/exampledocs に post.jar と post.sh というファイルがあります。これが XML を投げるプログラムになっており、引数でインデクスに追加するファイルを指定します。

サーバを起動しているのとは異なるターミナルを起動し、 exampledocs ディレクトリまで移動します。このディレクトリにはサンプルの XML がありますので、それらのすべてをインデクスに追加します。

$ cd {your-lucene-solr-trunk}
$ cd solr/example/exampledocs

$ java -jar post.jar *.xml
SimplePostTool: version 1.4
SimplePostTool: POSTing files to http://localhost:8983/solr/update..
SimplePostTool: POSTing file gb18030-example.xml
SimplePostTool: POSTing file hd.xml
SimplePostTool: POSTing file ipod_other.xml
SimplePostTool: POSTing file ipod_video.xml
SimplePostTool: POSTing file manufacturers.xml
SimplePostTool: POSTing file mem.xml
SimplePostTool: POSTing file monitor.xml
SimplePostTool: POSTing file monitor2.xml
SimplePostTool: POSTing file mp500.xml
SimplePostTool: POSTing file sd500.xml
SimplePostTool: POSTing file solr.xml
SimplePostTool: POSTing file utf8-example.xml
SimplePostTool: POSTing file vidcard.xml
SimplePostTool: COMMITting Solr index changes..

最後にコミットも発行されています。サーバ側のログにもコミットされたとのメッセージが出力されています。

インデクスに追加する XML の書式は、Wiki に記載されています。

XML Messages for Updating a Solr Index

フィールド名などは schema.xml と統一しておく必要がありますので、自分でカスタマイズする場合にはこのファイルも確認しておきましょう。

なお、インデクスを更新するには、XML 以外にも CSV や DIH (Data Import Handler) も使えます。 DIH のサンプルは example/example-DIH にあります。

検索してみる

"q" パラメータに検索式を記載して検索してみます。 "q" パラメータの記法は Lucene 由来で、次のページに記述されています。 AND, OR, NOT といった条件も確認できます。

Query Parser Syntax

実際に、id フィールドが "apple" のドキュメントを検索します。ヒューマンリーダブルにするため、"indent=true" も追加しておきます。

$ curl "http://localhost:8983/solr/select?q=id:apple&indent=true"
<?xml version="1.0" encoding="UTF-8"?>
<response>

<lst name="responseHeader">
  <int name="status">0</int>
  <int name="QTime">4</int>
  <lst name="params">
    <str name="indent">true</str>
    <str name="q">id:apple</str>
  </lst>
</lst>
<result name="response" numFound="1" start="0">
  <doc>
    <str name="id">apple</str>
    <str name="compName_s">Apple</str>
    <str name="address_s">1 Infinite Way, Cupertino CA</str></doc>
</result>
</response>

デフォルトでは XML で出力されますが、 "wt" パラメータを指定すると JSON でもレスポンスを取得できます。

$ curl "http://localhost:8983/solr/select?q=id:apple&indent=true&wt=json"
{
  "responseHeader":{
    "status":0,
    "QTime":1,
    "params":{
      "indent":"true",
      "wt":"json",
      "q":"id:apple"}},
  "response":{"numFound":1,"start":0,"docs":[
      {
        "id":"apple",
        "compName_s":"Apple",
        "address_s":"1 Infinite Way, Cupertino CA"}]
  }}

おわりに

Solr の trunk のソースコードを取得し、自分でビルドしてサンプルを動かしました。 trunk 特有のことは何もしていませんが、とりあえず環境を作っておくと便利かな、と。

あと、こんなイベントもあったんですね。行けばよかった。。

2012/01/14 Lucene ソースコードリーディング会を開催

Haskell 環境の確認

2012-01-14T18:29:00.002+09:00

昨年末に安定版がリリースされていましたので、 Haskell Platform を更新しておきます。主に自分用のメモ書きです。

手元のマシンは Mac OSX Lion です。下記のリンクから適当なインストーラーパッケージをダウンロードしてインストールしておきます。

The Haskell Platform - hackage.haskell.org
- Current stable release: 2011.4.0.0 (December 2011)
- Next release: May 2012

Haskell Platform に関してはこちらの記事が参考になります。

第39回　一般向けの「Haskell Platform」とインストール・ツールの「cabalコマンド」 - itpro.nikkeibp.co.jp

現在のバージョンを確認する

uninstall-hs コマンドでシステムにインストールされているバージョンを確認できます。

$ uninstall-hs
-- Versions found on this system
7.0.3
7.0.4
-- To remove a version and all earlier: uninstall-hs thru VERSION
-- To remove only a single version:     uninstall-hs only VERSION

ふたつのバージョンがインストールされています。古い方はいらないので、 only でバージョンを指定します。

$ uninstall-hs only 7.0.3
-- Would remove just version 7.0.3
/Library/Frameworks/GHC.framework/Versions/7.0.3-i386
/Library/Haskell/ghc-7.0.3
/usr/bin/ghc-7.0.3@ -> /Library/Frameworks/GHC.framework/Versions/7.0.3-i386/usr/bin/ghc-7.0.3
/usr/bin/ghc-pkg-7.0.3@ -> /Library/Frameworks/GHC.framework/Versions/7.0.3-i386/usr/bin/ghc-pkg-7.0.3
/usr/bin/ghci-7.0.3@ -> /Library/Frameworks/GHC.framework/Versions/7.0.3-i386/usr/bin/ghci-7.0.3
/usr/bin/haddock-ghc-7.0.3@ -> /Library/Frameworks/GHC.framework/Versions/7.0.3-i386/usr/bin/haddock-ghc-7.0.3
-- To actually remove these files, sudo run the command again with --remove
-- To generate a script to remove these files, run the command again with --script

何が削除されるかを確認してくれました。

実際に削除する

実際に削除するには sudo を使って --remove オプションを付けます。

$ sudo uninstall-hs --remove only 7.0.3
Password:
-- Removing just version 7.0.3

もう一度 uninstall-hs コマンドを使うと、削除されたことを確認できます。

$ uninstall-hs
-- Versions found on this system
7.0.4
-- To remove a version and all earlier: uninstall-hs thru VERSION
-- To remove only a single version:     uninstall-hs only VERSION

実際、ファイルシステムからも削除されています。

$ ls -l /Library/Frameworks/GHC.framework/Versions/
total 8
drwxr-xr-x  5 root     admin  170 Dec  6 12:01 7.0.4-x86_64/
lrwxr-xr-x  1 shigeru  wheel   12 Jan  6 07:51 Current@ -> 7.0.4-x86_64

パッケージの一覧を表示する

ghc-pkg コマンドでパッケージの一覧を確認します。

$ ghc-pkg list
/Library/Frameworks/GHC.framework/Versions/7.0.4-x86_64/usr/lib/ghc-7.0.4/package.conf.d
   Cabal-1.10.2.0
   GLUT-2.1.2.1
   HTTP-4000.1.2
   HUnit-1.2.4.2
   OpenGL-2.2.3.0
   QuickCheck-2.4.1.1
   array-0.3.0.2
   base-4.3.1.0
   bin-package-db-0.0.0.0
   bytestring-0.9.1.10
   cgi-3001.1.7.4
   containers-0.4.0.0
   deepseq-1.1.0.2
   directory-1.1.0.0
   extensible-exceptions-0.1.1.2
   ffi-1.0
   fgl-5.4.2.4
   filepath-1.2.0.0
   ghc-7.0.4
   ghc-binary-0.5.0.2
   ghc-prim-0.2.0.0
   haskell-platform-2011.3.0.0
   haskell-src-1.0.1.4
   haskell2010-1.0.0.0
   haskell98-1.1.0.1
   hpc-0.5.0.6
   html-1.0.1.2
   integer-gmp-0.2.0.3
   mtl-2.0.1.0
   network-2.3.0.5
   old-locale-1.0.0.2
   old-time-1.0.0.6
   parallel-3.1.0.1
   parsec-3.1.1
   pretty-1.0.1.2
   process-1.0.1.5
   random-1.0.0.3
   regex-base-0.93.2
   regex-compat-0.95.1
   regex-posix-0.95.1
   rts-1.0
   stm-2.2.0.1
   syb-0.3.3
   template-haskell-2.5.0.0
   text-0.11.1.5
   time-1.2.0.3
   transformers-0.2.2.0
   unix-2.4.2.0
   xhtml-3000.2.0.4
   zlib-0.5.3.1

utf8-string がありません。以前のマシンでは macport で用意しましたが、新しいバージョンでは必要ないそうです。

追加パッケージをインストールする

Haskell のパッケージは HackageDB で管理されています。

HackageDB - hackage.haskell.org

パッケージの管理には Cabal を使います。

Cabal - haskell.org

とりあえず cabal コマンドを実行してみます。

$ cabal

**********************************************************************


=== Configuration for cabal has been written to
    /Users/shigeru/.cabal/config

=== Executables will be installed in:
    /Users/shigeru/Library/Haskell/bin

    You may wish to place this on your PATH by adding the following
    line to your ~/.bash_profile:

    export PATH="$HOME/Library/Haskell/bin:$PATH"

=== When documentation is built, a master index to all documentation
    will be placed in:

    /Users/shigeru/Library/Haskell/doc/index.html

    You may wish to bookmark that file once it gets built (after the
    first cabal install).

**********************************************************************

Downloading the latest package list from hackage.haskell.org
cabal: no command given (try --help)

設定ファイルが生成され、パッケージの一覧が更新されました。

インストールしてみる

CSV を処理するモジュールを探します。

$ cabal list csv
* bytestring-csv
    Synopsis: Parse CSV formatted data efficiently
    Default available version: 0.1.2
    Installed versions: [ Not installed ]
    Homepage: http://code.haskell.org/~dons/code/bytestring-csv
    License:  BSD3

* csv
    Synopsis: CSV loader and dumper
    Default available version: 0.1.2
    Installed versions: [ Not installed ]
    License:  MIT

* csv-enumerator
    Synopsis: A flexible, fast, enumerator-based CSV parser library for Haskell.
    Default available version: 0.10.1.0
    Installed versions: [ Not installed ]
    Homepage: http://github.com/ozataman/csv-enumerator
    License:  BSD3

* cursedcsv
    Synopsis: Terminal tool for viewing tabular data
    Default available version: 0.1
    Installed versions: [ Unknown ]
    License:  BSD3

csv-enumerator をインストールします。まずは --dry-run オプションで確認。

$ cabal install csv-enumerator --dry-run
Resolving dependencies...
In order, the following would be installed (use -v for more details):
attoparsec-0.10.1.0
enumerator-0.4.17
attoparsec-enumerator-0.3
safe-0.3.3
unix-compat-0.3.0.1
csv-enumerator-0.10.1.0

依存ライブラリがいくつかあるようです。

実際にインストールします。ログは長いので省略します。

$ cabal install csv-enumerator

(ログ省略)

ドキュメントも更新されていますので確認しましょう。

$ open /Users/shigeru/Library/Haskell/doc/index.html

終わりに

去年は Haskell を書こうと思いつつも全然書いていませんでしたので、とりあえず環境を更新して、今年は何とか継続したいなぁ、と。

FC東京 - ACL2012 のカレンダー

2012-01-13T22:54:00.001+09:00

今年は元旦にFC東京が天皇杯で優勝しました。天皇杯優勝チームは ACL (=アジア・チャンピオンズ・リーグ) に出場できます。ということで、ACL2012 におけるFC東京のカレンダーを作りました。常に３月から５月までの予定を表示させる方法が分かりませんでしたので、手動で読み込む必要がありますが、自分の Google Calendar に取り込んでおくと便利だと思います。なお、タイムゾーンの扱いが微妙だったので試合の時間は入れていません。

公式スケジュールの Group F の部分から作成しました。

AFC Champions League Schedule & Results - the-afc.com

Python の学習資料 - 2

2012-01-04T16:19:00.003+09:00

Python の学習資料を追記しました。

Python School 1.1.0 documentation

ファイルシステムとのやり取りに関することがメインとなります。ローカルのマシンに対しては os と subprocess モジュールを使うと多くの作業をスクリプトで記述できるようになります。リモートのマシンに対しては SSH を使って操作することが多くなりますが、 Python の paramiko モジュールや fabric を使うことで、ローカルのマシンと似たような雰囲気で作業を自動化できるようになります。

追加内容

コマンドライン操作 - 1

ファイル一覧を取得する
ファイルの最終更新時刻を取得する
ファイル一覧をソートする

コマンドライン操作 - 2

パスを連結する
ファイル操作いろいろ
ファイルシステムの階層を辿る

コマンドライン操作 - 3

環境変数の扱い
設定ファイルの扱い
HTTP でダウンロード (記述場所を移動する予定)

コマンドライン操作 - 4

シェルコマンドの実行
コマンドの実行を待つ

コマンドライン操作 - 5

リモートサーバの操作
paramiko を使う

コマンドライン操作 - 6

fabric のインストール
fabfile.py
fab コマンドの実行

終わりに

何となく雑多だなぁ、と思っていたことを集約しました。改めて自分で資料を書いてみると、やっぱりまとまらないなぁ、と再認識。しかし、ちょっとしたスクリプトやモジュールは単に知っているかどうかの問題でしかありませんので、折に触れて使ってみる / 読んでみることも大切だと思います。

せっかくの新年ですから、スクリプトの勉強がてらファイルシステムを整理するのも良いかもしれませんね。

Python の学習資料

2011年の振り返り

2011-12-31T09:54:00.002+09:00

年末なので2011年を振り返っておきます。今年は東日本大震災があって色々なことを考えさせられた一年でした。個人的にも転職イベントがあり、なんか色々と考えた気がする一年です。

月々の出来事

毎月のトピックを二つずつ挙げておきます。プライベートも駄々漏れですが、来年以降に見直してみると自分で「へぇ～」と思うはずなので書き残しておきます。

１月:	高校サッカー選手権大会を観に行く。 Japan Innovation Leaders Summit で MIT Media Labs の石井先生の話を聞く。
２月:	アジアカップで日本が優勝したのでカップを掲げてきた。 XMPP の洋書を読み切る。
３月:	東日本大震災！なんか色々と調査しないとな〜と思い始める。
４月:	Twisted に関する英文記事のシリーズを翻訳した。 Haskell を触ってみる。
５月:	新卒で入社した会社を退職。アジャイルスタートアップで Pivotal Labs の人の話を聞く。
６月:	新しい会社に入社。検索システム Solr をちょこちょこ触る。
７月:	女子ワールドカップで日本が優勝。寝不足。。 DotCloud を触ってみる。
８月:	自分で夏休みの宿題みたいことをやってみる。(Waf / JavaScript MVC) HTML5 のことをキャッチアップし始める。
９月:	ドラッカーの本を読んでみる。 Solr の勉強会に行ってみる。
10月:	Node と Nginx を調べてみる。 Python の学習資料を書き始める。
11月:	FC東京の J1 昇格が決まる。 Google Buzz が終了する。
12月:	FC東京が天皇杯の決勝に進出する。去年のリベンジ！ Python の学習資料をひとまず公開する。

世界の出来事

世界のニュースは The Big Picture (Bostom.com) の132枚の写真が良い感じですね。

個人的な印象として、今年は災害や訃報が多かったような気がします。来年はもう少し良いことがありますように、と思います。

過去の記事

第７回 Solr 勉強会に行ってきた

2011-12-20T23:35:00.003+09:00

Solr の勉強会 (2011/12/19 19:00 to 21:30) に行ってきました。

第７回Solr勉強会 - atnd.org
#SolrJP - twitter.com
2011/12/19_第7回 Solr＆検索エンジン勉強会( #SolrJP ) - togetter.com
Solr勉強会第７回に参加しました。（発表もしました） - johtani.jugem.jp

ので、そのメモ。

会場を提供してくださった VOYAGE GROUP さん、運営者の方々、ありがとうございました。

Solr に特化した内容ではなく、ちょっと間口を広げて検索一般の話もあって勉強になりました。というか、ちゃんと統計とか数学とかを勉強し直さないと先がないなぁ、と思ったり。。。

発表とか

Solrベースの全文検索サーバFess

株式会社エヌツーエスエム　菅谷信介さん

オープンソース全文検索サーバー Fess (フェス)

ステータス:

Full tExt Search System から FESS。
第２回の勉強会で紹介。その後も開発を継続。
最新バージョンは 5.0 で、Solr は 3.5。
当初は独立した設計だったが、次第に Solr に依存するようになってきた。
商用サポートもあるし、個人でも簡単に導入できる。

機能:

インデクスを作成するときにロール情報を付加している。ログイン状態によって検索結果が違う。
カテゴリ絞り込みも可能。デスクトップ検索といった機能も追加。クリックログの統計情報もあり。
クローリングには S2Robot を利用。下位レイヤで Tike, POI などを利用。
Solr Server Manager -> Solr Group -> Solr Server で段階的に管理。グループAは更新用、グループBは検索用、などのように使い分け可能。

lucene-gosenの話

@johtani さん

lucene-gosen のコミッターのひとり。

lucene-gosen - code.google.com

org.apache.lucene.analysis.ja パッケージに日本語処理のソースあり。

JapanesePartOfSleechKeepFilter ・・設定値の文字のみ残す
JapaniseBasicFormFilter ・・基本形に変換例）悲しき＝＞悲しいと変換
JapaniseKatakanaStemFilter 「ー」変換
JapaneseBasicFormFilter 悲しき→悲しいなど基本形に変換して揃えるフィルタ
JapaniseWidthFilter ・・半角＜＝＞全角に変換するフィルタ
JapanisePunctuationFilter ・・区切り文字・記号を除く
JapanisePartOfSpeechStopFilter ・・記載ワード除く

lucene-gosen は合成ルールを適用できる。合成ルールは外部ファイルで定義しておく。(compositePOS)

Q&A:

Q)フィルタをかけると字が詰まるのですが？
A)enablePotionIncrements="false" を指定すると字が詰まりません

その他:

転置インデクスを作る話。英語は空白区切りなので割と簡単に処理できる。日本語だと切り方が難しいので形態素解析を使う。ってことで Gosen へ。
Lucene / Solr のデフォルトは N-グラム。辞書は不要だが、ノイズも多くなる。意味のある最小単位の文字列に区切るのが形態素解析。
Kuromoji はソースごと Lucene に contribute されたらしい。 ("Kuromoji is a Japanese morphological analyzer.")
compositePOS の話。NAIST の辞書だと数字を一文字で登録。「100」が三つの文字になってしまう。
Kuromoji - atilika.org

ApacheCon参加レポート

@Ijokarumawak さん

ApacheCon NA 2011 Report - slideshare.net
ApacheCon NA 2011 - apachecon.com

Solr に限らず、全般的な話。

Hadoop のコミュニティがとても大きくなってきた。
IBM の Watson の紹介など。Watson は ASF のソフトウェアを活用している。

Solr の UI に関するライブラリの話。

Velocity を使った実装も同梱。
JRuby -> TwigKit, Rails -> Blacklight, PHP -> VUFind
JavaScript のライブラリもある。

Solr 4.0 に関すること。

Automaton Query ・・あいまい検索が速くなる
- 性能測定には Wikipedia を使用。
- 今）0.1-0.2QPS ＝＞ 50QPS になるらしい。
- あいまい検索 (FuzzyQuery) が100倍高速化。
lucene4からファイルに(フラッシュするところまでマルチスレッドでいけるらしい。
ニュース
- Lucene's FuzzyQuery is 100 times faster in 4.0 - java.dzone.com
- Lucene 3.5 と Solr 3.5 - 大幅な RAM 削減，SearchManager，ディープページングのサポート - infoq.com

サフィックスアレイの話

@nobu_k さん

Solr ではなく、検索一般のこと。 PFI で Sedue の開発をしている人なので、研究開発の側面が強い。

一般論として、速度的には転置インデクス > Suffix Array > n-gram らしい。
Suffix Array の使いどころは遺伝子やバイナリデータの検索。HPC との組み合わせになりそう。
ストップワードは二分探索なので、甚大なボトルネックにはならない。

P2P分散検索エンジン ORBISについて

@ceeflyer さん

ORBIS - code.google.com

開発の動機:

リアルタイム性の高い検索。
サーバ増設を簡単に行いたい。
スモールスタート / 分散型 => P2P な自律分散ネットワーク

機能的なこと:

1000台未満の小規模ネットワークでフルメッシュを構成する。
P2P のノード間の通信には Message Pack を使っているらしい。
結果はXMLで返し、どのノードで追加したかも分かる。
インデクスはハッシュ値を元にして、一定数のレプリカを分散して保存する。

終わりに

Fess や ORBIS のように Solr をベースにしたシステムも増えてきている印象です。一方で、Lucene / Solr を中心とした話は lucene-gosen の発表だけ。 Solr はデフォルトでもそれなりに使えるという部分と、 MySQL などの RDBMS ほどにはユーザー数が増えにくいという部分がありそうです。

形態素解析、Suffix Array、n-gram は文字列検索の基礎的なことですが、改めてまとめてもらえると勉強になります。

あと、そろそろ Solr4 (trunk) を使ってみないとなぁ、と思いました。

前の勉強会の記録:

第６回 Solr 勉強会に行ってきた

Python の学習資料

2011-12-10T15:24:00.001+09:00

Python の学習資料を公開しました。

Python School 1.0.0 documentation

対象は次のイメージです。

何となく動くソフトウェアを書ける。
自分の環境では動くけど、別のマシンで動かすときは苦労している。
デグレードに悩まされて仕事から帰れない。

資料のアウトライン

全体的な内容としては次のものを予定しています。

環境構築と基本的なスクリプト
- Virtualenv + pip (Windows)
- Fizzbuzz
- コマンドラインスクリプトのテンプレート
CSV ファイルの読み込み
- zip / dict 関数、クラス定義
- 文字コードの扱い
- O/R マッパー - SQLAlchemy
コマンドライン操作
- ファイルシステムとのやり取り
- 設定ファイルの持ち方、環境変数
- Fabric によるリモートサーバ操作
テストの方法
- unittest / doctest
- Nose による実行
Web アプリケーションの作成
- Django チュートリアル
- URL のルール
- テンプレートエンジン
ドキュメントの構成方法
- Sphinx と CI
- テーマの作成
プロジェクトの構成方法
- パッケージング
- ビルドツールいろいろ

実際に書き終わっているのは CSV ファイルの読み込み部分までです (もう少し更新はあるだろうけど)。 Web アプリに関しては微妙なとこです。やっぱり書かない (or 書けない) かもしれません。３月くらいまでには書き終えたいなぁ、と。

そもそもの動機

ソフトウェア系の会社で働いていると、ちょっとしたスクリプトを書けば業務改善が図れることは多いと思います。

標準的なスクリプティング方法が統一されている会社もあるでしょうし、個人がまちまちに管理していることもあるでしょう。個人的には、それなりの規模の会社で働く場合は、周りの人と協力して作業できるように環境を整備しておくことが大事だと思っています。

当たり前といえば当たり前のことですが、意外とそこは重視されにくいようで、「XXX というプログラミング言語を使ったことはありますか？」と聞かれたことはあっても、「XXX で NN 人が効率的に仕事をするためにどうするべきですか？」といった類の話題は少ない気がします。

がむしゃらにソフトウェアを書いてみても良いとは思いますが、せっかく会社で仕事をするなら、協調できる方法を模索するのも悪くないと思います。自分の手元で動くから完成、膨大な手順書があるから機械的に運用できる、そうした幻想を抱くのではなく、どこでも気軽に動かせるソフトウェアが増えて欲しいな、と。

そんなこんなをもう少し現実的な地点に落とし込むと、基本的なコマンドラインスクリプトを書ける人が増えて欲しいなぁ、ということで、冒頭の資料を作成することにしました。

Python を使う

管理ツールなどの補助スクリプトとして Python を使う方法を学びます。テキストファイルに対する処理、シェルスクリプトに代わるものを Python で記述することにより、チーム開発の生産性を向上させます。

なぜ Python か？という部分にはいくつかの理由がありますが、なぞのコーディングルールを定めなくともそれっぽく記述がそろいますし、記号を多用する必要がなく、多くの Linux にデフォルトでインストールされている、という点が挙げられます。あと、Windows でも簡単に始められます。

ともあれ、ひとつの言語でスクリプトを記述できるようになれば、それを他の言語に適用することは簡単になるはずです。「この言語を使うんだ！」と明確な指針が定まっていない限り、とりあえず Python を勉強してから他のことをやっても、さほど遠回りにはならないでしょう。むしろ、あれやこれやと考える前に取り組める人の方が好ましかったりします。

Python だと実行速度が不安... という話もあるみたいですが、そもそも性能要求が厳しい部分で使うことは想定していません。実行速度よりも実装速度が求められる部分で力を発揮すると思います。乗り物で例えるなら、一方通行の狭い道を移動するときは大型車より自転車の方が速かったりします。何事も適材適所ですね。

終わりに

公開した資料をベースに、社内で勉強会を開催しています。ちょっとした糊付けプログラムはサラッと Python で実装できる人が増えてくれれば嬉しいなぁ、と思います。

効率化のためにソフトウェアを開発しているわけですから、効率的に仕事を進められるようになりたいですね。

中竹竜二氏が語る「世界で勝つために」必要なこと（２／２） (スポーツナビ)

ユース世代がスコットランドに勝ちましたが、当然だと思っています。ユース世代で世界で一番練習しているのは日本です。毎日練習して週末も練習している。こんな国はほかにありません。それでも世界で一番強くなれてないのは練習効率が悪いからです。忙しいと言うなら練習を減らして準備して振り返って考える、考えさせる時間をつくってくださいと言っています。

HTML5 の File API を使ってみる

2011-12-06T22:50:00.001+09:00

CSV を読み込んで JSON で出力できるようにします。 CSV の仕様は意外と難しいので、単純にカンマで区切られているテキストファイルだけを想定します。

File API Sample (デモ)
simple-usage-fileapi.html (ソース)

File API の仕様などはこちら。基本的にこれらのサンプルスクリプトをまとめたものが、上記のデモになります。

File API - w3.org
Reading local files in JavaScript - html5rocks
HTML5 File API を使ってファイル読み込み - tmlife.net

なお、イベント管理には jQuery を使います。

form を作る

まずは <form> 要素を作成します。複数のファイルを選択できるよう、 multiple を有効にします。

        <form>
        Select CSV files: <input type="file" id="files" name="files[]" multiple="multiple" />
        </form>

この要素に change イベントを割り当てます。コールバックに渡されるイベントオブジェクトの target には files があり、これは FILE オブジェクトの配列になっています。イベント自体と FILE の扱いは分離したいので、別に定義する関数に処理を投げます。

                $(selector).bind("change", function(e) {
                    var files = e.target.files;
                    handleFiles(files);
                });

ファイルを処理する

先ほどの handleFiles は簡単にループを回すとして、個別のファイルは次のように処理してみます。

メタ情報を表示する
CSV ファイルの場合は読み込み処理を実行する

スクリプトにまとめると次のような感じ。関数の戻り値が真の場合のみ読み込み処理を継続します。

        function parseFile(f) {
            var dt = [];
            dt.push({Name: f.name,
                     Type: f.type || 'n/a',
                     Size: f.size,
                     LastModified: f.lastModifiedDate ? f.lastModifiedDate.toLocaleDateString() : 'n/a'});
            $("#file-list-template").tmpl(dt).appendTo('#file-list');
            return f.type && f.type.match("text/csv");
        }

ファイルの読み込みは次のようになります。コールバックを設定してから、読み込む文字列を与えます。 opts という変数に適当なコールバックが設定されている場合には、適切なタイミングでそのコールバックが呼ばれるでしょう。

        function readFile(readFile) {
            var reader = new FileReader();
            // Handle progress, success, and errors
            reader.onprogress = opts.progress || function(e) {};
            reader.onerror = opts.error || function(e) {};
            reader.onload = opts.load || function(e) {};
            reader.readAsText(readFile, "UTF-8");
        }

readAsText で読み込んだ場合はイベントオブジェクトの target を通じて、普通の文字列を取得できます。後は自由にその文字列を処理すれば良いだけです。

                var fileString = evt.target.result,

ドラッグに対応する

ついでにドラッグ&ドロップにも対応させます。

まずは適当な HTML 要素を準備します。

        <div id="drop-zone">Drop CSV files here</div>

そこにイベントハンドラを割り当てますが、ここのイベント処理がちょっと曲者です。

stopPropagation() を呼んでブラウザにネイティヴの挙動をさせない。
jQuery のイベントに未登録のものは originalEvent を参照する必要がある。

詳しくはこちらのスライドで説明されています。

Understanding jQuery Events & working with new HTML5 APIs

スクリプトにまとめると次のような感じ。 originalEvent を介さないと、 dataTransfer が見つからない、という理由でエラーになります。 (jQuery のバージョンによって異なるので、新しいバージョンだけを使う場合は気にしなくて良いかも)

                    .bind("drop", function(e) {
                        e.stopPropagation();
                        e.preventDefault();
                        var files = e.originalEvent.dataTransfer.files;
                        handleFiles(files);
                    });

終わりに

HTML5 の File API を使って、CSV ファイルの中身を JSON で出力してみました。 CSV と言っても非常に簡易なものしか扱えませんが、取っ掛かりとしては十分かな、と思います。

File API はテキストデータだけでなくバイナリデータも扱えますので、様々なリーダーを試してみるとおもしろそうです。

KML ファイルを作成する

2011-11-26T00:46:00.001+09:00

ちょっと、CSV のデータから KML ファイルを作成してみます。

KML チュートリアル - code.google.com
KML Interactive Sampler - kml-samples.googlecode.com

CSV ファイルから KML に変換するスクリプト

Python でスクリプトを書いておきます。

KML ファイルのテンプレートを用意する

Jinja2 を使ったテンプレートだと次のように記述できます。名前と緯度経度が必須で、説明文がある場合はそれも出力します。

TEMPLATE = u"""<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">

{% for point in points %}
  <Placemark>
    <name>{{ point.name }}</name>
    {% if point.description %}
    <description>{{ point.description }}</description>
    {% endif %}
    <Point>
      <coordinates>{{ point.longitude }},{{ point.latitude }}</coordinates>
    </Point>
  </Placemark>
{% endfor %}

</kml>"""

CSV ファイルを読み込む

次のフォーマットの CSV ファイルについて考えます。１行目はヘッダー行で固定とし、２行目以降に同じ並びでデータが続きます。

name,longitude,latitude,description
国立霞ヶ丘競技場,139.714941,35.678160,naash.go.jp

... 同じ形式でデータが続く ...

簡単のために、区切り文字以外にカンマは存在しない、と仮定しておくと、次のようなコードで処理できます。

    def process(self, reader):
        header = reader.next().strip().split(',')
        points = []
        for line in reader:
            r = line.strip()
            if not r:
                continue
            row = r.split(',')
            data = dict(zip(header, row))
            points.append(data)
        self.rederer.render(points)

エクセルの CSV と互換性がないとか、ダブルクォートの処理がどうのという話もありますが、 CSV ファイルを真面目に扱うと奥が深いのでやめておきます。

ファイルにまとめる

引数処理や入出力のエンコーディング処理を追加して、ファイルにまとめておきます。

csv2kml.py - github.com

入力ファイル

$ cat sample.csv
name,longitude,latitude,description
国立霞ヶ丘競技場,139.714941,35.678160,naash.go.jp

実行結果

$ python csv2kml.py sample.csv
INFO:root:Start processing: sample.csv
<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">

  <Placemark>
    <name>国立霞ヶ丘競技場</name>

    <description>naash.go.jp</description>

    <Point>
      <coordinates>139.714941,35.678160</coordinates>
    </Point>
  </Placemark>

</kml>
INFO:root:End processing: sample.csv

ヘルプ表示

$ python csv2kml.py -h
Usage: python csv2kml.py [options] file1 [file2 [ ... ]]

Convert CSV file into KML format.
See KML Tutorial
<http://code.google.com/intl/ja/apis/kml/documentation/kml_tut.html>

Input file must contain following header line:

    name,longitude,latitude,description


Options:
  -h, --help            show this help message and exit
  -f FILE, --file=FILE  setting file
  -o FILE, --out=FILE   output file
  --basedir=BASEDIR     base directory
  --input-encoding=ENC_IN
                        encoding of input source
  --output-encoding=ENC_OUT
                        encoding of output destination
  -v, --verbose         verbose mode
  -q, --quiet           quiet mode

Google Maps で読み込む

Google Maps には、ローカルファイルシステムから KML をアップロードする方法と、任意の URL のファイルを読み込む方法が用意されています。 Dropbox のパブリックフォルダなどに KML を置くことで、URL から読み取れるようになります。

終わりに

CSV のデータから KML ファイルを作成しました。 Google Maps と Google Earth は KML を読み取って地点情報などを表示できます。何となく地球の地点情報を火星にマッピングしてみると楽しいかもしれません。まぁ、誰得な話でもでもありませんが。。

KML には Google の拡張もあり、Google Earth ではツアー機能もありますので、気が向いたら使ってみようかなぁ、と思いました。

あと、Google Earth で緯度経度表示の単位を変更するには、設定画面から選択できるようです。度分秒からの表示を変更したい場合に便利です。

追記：KML で複数の地点を含めるために Document 要素を追加。

さよなら Google Buzz

2011-11-20T16:18:00.001+09:00

Google Buzz に終了宣言が出されましたので、データをエクスポートしておきます。 API 設計がキレイだなぁとは思っていましたが、サービス自体の立ち位置が定まらなかった点が大きかったのでしょうか。メールシステムとの統合は根深い問題もありそうです。

A fall sweep - googleblog.blogspot.com
Google Buzz - wikipedia.org

データのエクスポート

Google Takeout (データエクスポート) を使ってデータをエクスポートします。サービスを選択してダウンロードできます。データ量によっては時間がかかるかもしれません。

Buzz のデータをエクスポートしてみるとこんな感じになります。

ファイル名の変換

Takeout では日本語のファイル名がパーセントエンコードされていて個人的に好きでありませんので、もう少し機械的な文字列として日付日時に変換します。日付はファイルの変更日時にしますが、同じ時間の場合には連番となる数字を付与して重複を防ぐことにします。複数人のデータだと重複管理にはもっと気を遣った方が良いでしょうが、一人分のデータで時間が重なることは少ないでしょうから、それなりに妥当なとこかなぁと思います。

Python のスニペット:

def determine_new_file_name(timestamp, suffix):
    mtime = datetime.fromtimestamp(timestamp)
    base = mtime.strftime('%Y-%m-%d-%H-%M-%S')
    c = 0
    while True:
        if c:
            cand = "%s.%d%s" % (base, c, suffix)
        else:
            cand = base + suffix
        if not os.path.exists(cand):
            return cand
        c += 1


def fnameconv(basedir, outputdir=None):
    outputdir = outputdir or basedir
    if not os.path.exists(outputdir):
        raise SystemExit("\"%s\" is not found." % (outputdir,))
    for f in os.listdir(basedir):
        # XXX: ignore list should be optional argument
        if f == __file__:
            continue
        fname = os.path.join(basedir, f)
        _, suffix = os.path.splitext(fname)
        cand = determine_new_file_name(os.stat(fname).st_mtime, suffix)
        dst = os.path.join(outputdir, cand)
        shutil.move(fname, dst)

あとは main() 関数で引数をそれっぽく解析すれば良いと思います。

スライドショー風に表示

まずはファイル一覧をリスト (JSON のリスト形式) にして files.json という名前で保存します。

次に HTML ファイルを作成して files.json を読み込めるようにし、適当なタイマー設定でランダムにファイルの中身を読み込みます。 (jQuery の load() を使うとお手軽。HTML が静的なものであると想定)

たまには自分で選択したいこともあるでしょうから、ランダムに６つのファイル名をタブ表示させておきます。タブ表示のデザインは Twitter Bootstrap を使うととても簡単に実現できますね。 HTML を組み立てる部分は jQuery Templates にお任せです。

    $(function() {
      $.getJSON("files.json", function(data) {
        var slides = [];
        $(data).each(function() {
          // XXX: parse date and time.
          var t = this.substring(0, 19).split("-");
          slides.push({"file": this.toString(),
                       "name": t[0] + "/" + t[1] + "/" + t[2] + " " + t[3] + ":" + t[4],
                       "date": this.substring(0, 10)});
        });
        function pickup() {
          var len = slides.length;
          return slides[Math.floor(Math.random() * len)];
        }
        $("#screen").load(pickup()["file"]);
        setInterval(function() {
          $("#screen").load(pickup()["file"]);
        }, 6000);
        function update() {
          var dt = [];
          for (var j = 0; j < 6; j++) {
              dt.push(pickup());
          }
          $("#slide-list").empty();
          $("#slide-list-template").tmpl(dt).appendTo("#slide-list");
        }
        update();
        setInterval(function() {
          update();
        }, 20000);
      });
      $("#slide-list a").live("click", function(e) {
        e.preventDefault();
        $("#screen").load($(this).attr("href"));
        // XXX: freshen auto update timer.
      });
    });

NOTE:

jQuery Templates は JsViews に置き換えられる予定 (?) なので、もう少しちゃんと作る場合はテンプレートライブラリを差し替えるのがベター。

jQuery Templates and JsViews: The Roadmap - borismoore.com

出来上がったものを Web サーバのディレクトリに置けば表示されるようになります。

Buzz Slide

終わりに

Google Buzz のデータをエクスポートして自前のサーバー環境でスライドショー風に表示しました。有料か無料かを問わず Web サービスは継続されない可能性がありますが、エクスポートできる仕組みを提供してくれているかどうかは大きな違いだと思います。画面デザインが刷新されて好き嫌いもあるでしょうが、Google はその辺をうまくやってるなぁ、と思いました。

OData のための効率的なフォーマット

2011-11-15T20:50:00.001+09:00

OData のブログに気になるエントリがありましたので、ちょっと日本語に訳しておきます。

An efficient format for OData

"dense" にしっくりくる日本語を思いつかなかったので、そこはそのまま英語表記。

日本語訳

そろそろ OData におけるもっと効率的なフォーマットが必要になってきており、このスレッド (Why XML) で直近はやり取りされている。このトピックについてもっと突っ込んで調査し、問題を文章として表現することで、考えられる可能性への足場づくりにしたいと考えた。

OData 用の新しいフォーマットの導入を議論すると、非常に多くのことを考えさせられる。過去にもこのフォーラムで議論してきたように、閉じたシステムに特化したフォーマットは良かった。しかし、たくさんのエコシステムにサポートを望むフォーマットについて話すときは別だ。エコシステムを分断化 (fragment) しないことを保証する必要があり、特定のクライアントやサーバーを蚊帳の外に追い出してはならない。

OData は今や膨大なサーバファームでも携帯電話でも使われている。前者はデータシリアライズにおける CPU サイクルに厳しく、後者はデータサイズや CPU 効率化、それからバッテリー消費を注意深く管理する必要がある。よって、どこそこの部分に注力する、と言うのがフェアだろう。

解決すべき問題とは？

フォーマットとパフォーマンスについて議論すると、お決まりの質問がやってくる。「サイズとスピードのどちらを最適化するの？」おもしろいことに、本当に多くの場合に、サーバ側はスループットを最適化したがり、そうしたサーバとやり取りするクライアントはバッテリーの寿命を最大化することなら何でも最適化したがる。そして誰もがサイズのために帯域幅を最適化する。

ここから分かるのは、バランスのとれた選択肢を模索しなくてはならない、という点であり、相互運用を認めながら、さらなる改善の機会は常に開かれている。このもとに、OData のための「効率的」なフォーマットを作成するというゴールを緩く定義し、更なる効率さが更なるコンパクトさや生成の早さを意味するかどうかを問題定義に埋め込まないようにする。

何を変更できる？

シリアライゼーションの準備ができていれば、データの獲得とそれを運搬するプロセスを一定だと考えると、シリアライゼーションのコストは CPU 時間に支配される傾向にある。文字列でないデータを文字列に変換する (テキストベースのフォーマットを使う場合) すべての文字列を正しい文字エンコーディングにエンコードし、すべてのレスポンスを一緒に縫い合わせる。サイズだけに注目するなら出力を圧縮するだろうが、それでは CPU を二倍も使ってしまう。一度目は最初のドキュメントを生成するときで、二度目はそれを圧縮するときだ。

そこで、始めるときから記述量を減らし、何を書き出すかを決めるのに大量の時間を費やさないようにしよう。このことは比較的明らかな候補を見つけられるし、余分なものを排除することにつながる。

その一方で、変えたくないこともたくさんある。帯域外の知識なしに通信できるようになるので、OData のリクエストとレスポンスを自己内法的にすることは大事である。 OData はサーバがなんでもエンコードできるように URL を非常によく使う。たとえば、エンティティの分散や異なるホストにまたがった関係性、継続的なエンコーディング、 CDN におけるメディアの場所といったものが挙げられる。

読み書きすべきこと、すべきでないこと

OData のペイロードを見てみると、すぐに冗長な部分を勘ぐるだろう。しかし何回か試行するために、多くのデータを持たせるようにしておく (正確な科学的調査ではなく、大雑把なものだと考えてほしい)。参考として Northwind データベースを OData サービスとして見せるサンプルサービスから、３つの場合を扱った。

1 Customer: http://services.odata.org/Northwind/Northwind.svc/Customers?$top=1
100 CustomersAndOrders: http://services.odata.org/Northwind/Northwind.svc/Customers?$top=100&$expand=Orders
100 NarrowCustomers: http://services.odata.org/Northwind/Northwind.svc/Customers?$top=100&$select=CustomerID,CompanyName

これらは、本当に小さなデータセット、やや大きく広範なデータセット、それから大きいが狭い範囲のデータセットである。

Atom と JSON のサイズを比較すると、JSON は Atom の半分から３分の１になる。このことの大部分は、JSON の方が冗長もしくは不要なコンテント (閉じタグ、空の必須要素、など) が少ないからだ。値の型アノテーションの欠如のような、このうちのいくつかは実際に忠実さを損なうけれでも。

JSON のペイロードをもう少し見ていくと、メタデータとプロパティ名がコンテンツの40%近くになっていて、システムが生成した URL も40%弱ある。純粋なデータはコンテンツの20%前後でしかない。データを視覚的に見たい人も多いだろうから図にしよう。

これについてはかなりの変動性がある。 URLが20-25%近くになるフィードや、メタデータとプロパティ名が65%にもなるようなものも見てきた。どちらにせよ、これらの両方に言及する確固たる言い分がある。

アプローチ

実際の接続フォーマットと、冗長さを減らして記述量を少なくする ("write less") 戦略を分離しておこうと思う。まずは後者に着目していこう。

上述のデータから、構造 (プロパティ名、エントリのメタデータ) と URL の両方をエンコーディングするのが大変な作業なのは明らかだ。シンプルな戦略は二つの構造をドキュメントに導入することだろう。

構造化テンプレート ("structural templates"): 含まれるものの構成を記述する。レコードや入れ子になったレコード、それからメタデータのレコードなどである。テンプレートは一度記述されれば良く、実際のデータをそれらを参照するだけとなるので、行レコードにおけるプロパティ名の繰り返しを回避できる。
テキストテンプレート ("textual templates"): ドキュメント全体を通して何度も繰り返すテキストパターンを記録しておく。 URL などは真っ先に思いつく好例といえる。 (例えば、このようなテンプレートを想像できるだろう "http://services.odata.org/Northwind/Northwind.svc/Customers('{0}')"。それぞれの行の値は "{0}" を置換するだけでよい。)

必要とされるときにデータと一緒にインライン化できるので、本当に必要とされるテンプレートだけが特定のドキュメントに入ることになる。

実際にやり取りするフォーマット

接続フォーマットを実際に選択するときはたくさんの観点から検討する。

テキストかバイナリか？
どのようなクライアントが処理できるようにすべきか？
低レベルの転送フォーマットを選び、テンプレートスキームに適用すべきか、もしくは、冗長性を取り除くメカニズムを持っている既存のフォーマットを使うべきか？

私が検討したいくつかのことを挙げよう。

EXI: W3C が推奨するコンパクトなバイナリ XML フォーマットだ。これの良い点は、単なる XML であり、Atom のシリアライザーを使えることだ。圧縮効率も満足のいくレベルである。それでも、すべてのことを高レベルのレイヤーで実現した方が良いのではないかと心配になる (CPU 使用率に関してきっちり調べていない) し、すべてのクライアントがダイレクトに使用できるわけでもない。実装するのも一仕事だ。
「低レベル」のバイナリフォーマット: BSON、Avro、それから Protocol Buffers について調べてみた。様々な OData のイディオムを受け渡す部分の上にフォーマットを定義する必要があるため、「低レベル」と呼ぶことにする。多くの場合に冗長性を減らしたいなら、これを取り扱わなければならないだろう。 (公平を期すなら Avro は構造の面でも自己言及の側面を既に扱っているが)
JSON: いつだったか WCF チームの人も言及していたように、これは直感的な考えだ。構造的でテキストのテンプレートを使って "dense JSON" エンコーディングを定義できる。ドキュメントは一貫して JSON ドキュメントであり、どのような環境でも通常の JSON パーサーを使って処理できる。よくできたパーサーなら dense フォーマットから最終的な出力までをダイレクトに生成できるだろうし、普通のパーサーであってもシンプルな JSON から JSON への変換を適用できる。これは実際のシナリオで期待する類で、プロパティ名が繰り返し出現するオブジェクトとして JSON を返す。このアプローチはサイズに対してはそこまで最適化された結果ではない。しかし、ほどほどな効率性を持っており、極めて優れた相互接続性を持つ。

バイナリフォーマットと JSON については、圧縮することを脇に置いておいたことに注意してほしい。 OData は HTTP 上に構築されるので、クライアントとサーバはコンテンツのエンコーディングを介していつでも圧縮について協議できる。これにより、サーバはスループットとサイズに関して選択できるし、クライアントはサイズと CPU 使用率でどちらの最適化が好ましいかを提案できる。 (ポータブル機器の場合はバッテリーの寿命に反映されるかもしれない)

OData 用の dense JSON エンコーディング

これらの中では、私は JSON に興味を持っている。テンプレートに詰め込むのがとても暗号的になるかもしれないが、フォーマットをテキストにしておく考え方が好きだ。その他すべてのクライアントに加えて、ブラウザーの中で動作するという事実も本当に好ましい。

ここまでで十分に長文になってしまった。これが興味深い方向性だと考える人たちがいれば、JSON エンコーディングの実際の定義は他の議論に移したい。ということで、その動機付けのために一例を示させて欲しい。

上述の Netflix の例では「タイトル (Title)」型の行データがたくさんある。典型的には、個別の行データに対して完全な JSON オブジェクトを使うだろう。すべてが array 型でまとめられ、__metadata オブジェクトを伴ってそれぞれが「自分へのリンク (self links)」などを持っている。 dense バージョンでは、 "control" と "metadata" それから "data" に対して、それぞれ "c" や "m" あるいは "d" オブジェクトなどを持つ。それぞれのオブジェクトはトップレベルの array 型でオブジェクトを表現し、その値はテンプレートが定義される順番に一致しており、新しいテンプレートを導入するメタデータオブジェクトか、テンプレートのある部分の特定の値を表現するデータ値のどちらか。制御オブジェクトはたいてい最初か最後にあり、件数や array または singleton などを示す。次のような感じである。

(そこまで正確さを意識しておらず、単なる手描きの図だと考えて欲しい)

ふたつの構造化されたテンプレート (JSON スキーマっぽいもの) とテキストテンプレートに注意して欲しい。単一行データにとってはいささか大きくなってしまうが、大きすぎるほどでもないと思う。行データが増大するにつれて、圧縮密度が高いオブジェクトになっていくだろう。属性名がなく、解凍するときに順番が固定されている。このようなフォーマットだと、"100NarrowCustomers" の例では元の JSON に対して３分の１くらいのサイズになる。クライアントとサーバーをつなぐデータとして小さいだけでなく、テキストの３分の１はまったく処理する必要がないのである。

次のステップ？

複数のフォーマットについてもっと良く評価する必要がある。個人的には dense JSON フォーマットの考え方が良いと思うが、トレードオフの作業として検証が必要になる。もう少しよく考えてみてから、また連絡するよ。 dense JSON でもう一段階踏み込んだことを挑戦してみて、どんな感じになるかを見ていこうと思う。

ここまで読んでくれたなら、新しいフォーマットを作ることに本当に興味があるに違いない。フィードバックを歓迎する。

ありがとう。 -pablo

終わりに

"An efficient format for OData" というエントリを日本語にしました。 OData 自体がどうなっていくかは未知数ですが、データ構造の設計についてまとまった記事は少ないと思いますので、クライアント/サーバ間の通信に関して議論する取っ掛かりにはなるでしょう。

JSON のキー名を個別のデータに含めない、という考え方は JavaScript の本 (High Perfomance JavaScript) でも述べられていますので、知っているに超したことはないのかな、と。

Nodefest.jp warm-up event に行ってきた

2011-10-29T00:34:00.004+09:00

Node に関するイベントに行ってきました。翌日の「東京 Node 学園祭 2011」の前夜祭みたいなものです。本編には出られませんが、雰囲気だけでも感じておこうかな、と。まぁ、飲み会みたいな感じだったという。。。

Q&A は QLive というサイトでホストされました。

QLive Nodefest.jp warm-up event

トーク

スピーカーは３人。

QLive のこと
Cookpad でアイコンのテストスクリプトを作ったこと
myGengo の中の人が Wii-js について

自分がメモしたこと:

QLive のアーキテクチャの話。Node.js と Rails で構成されてる。
- 初期データは Rails から配信し、POST データもこちらで。
- 投稿されたデータは Redis をキューにして Node + socket.io で配信。
- Node と Rails は分離されているのが嬉しいところ。
- Redis が SPOF (単一障害点) にならないか心配だが、daemontools がプロセスを再起動してくれる。
- Ubuntu 11.10 の node は 0.2.6 だから自分でコンパイルしているらしい。
クックパッドでアイコンの違いのテスト方法について。
- アイデアからプロトタイプまで２時間くらい。
- Node, Express, EJS, CoffeeScript, SASS 辺りを使っているみたい。
- StackOverflow でたくさん聞けるから、何かあっても苦にならない。
Wii-js を作ったきっかけは、子供にプログラミングを教えることに適している、という理由もある。
- Wii のブラウザは Opera 9.26 ベースだから古い。
- 英語で話しているが、スライドは日本語で読みやすい。

残念に思ったこと:

自分の英語力が足りない。
- Redis と Rails を間違って聞いていることがあった。
- V8 を vi かと思った。

Q&A

QLive の質問に Ryan と Guillermo が答えてくれる流れ。メモしてないから、断片的に覚えていること。

try/catch のサポートは、今のところ考えていない。
スタックトレースが取りづらいけど、関数呼び出しの仕組みを考えると色々と難しい。
V8 に影響を受ける部分もある。ヒープサイズとか。
Microsoft からサポートで入ってきてくれた人がいて、とても助かる。
コマンドラインもサポートしたいね。需要があれば。
BOXCAR は良いと思う。 (聞き間違いでなければ)

終わりに

クックパッドでの開催でしたが、きれいなオフィスで立派なキッチンでした。料理もおいしく、本当にシェフの人がいるんだなぁ、と再認識。ありがたい限りです。

外国人が多いとニギヤカな感じがして、シリコンバレーや TechCity (ロンドンの IT 系の人を誘致しているエリア) だと人の交流が盛ん、っていうのは納得。知らない人ともすんなり話せるようにならないとなぁ、と思いました。自分の偏見だと、日本人のソフトウェア系の人はこれが苦手な感じ、と自省。。。言語なのか文化なのか、性格なのか。難しい。

CentOS に Node.js をインストールして forever でデーモン化

2011-10-13T23:55:00.000+09:00

ちょっと作業するときに忘れてしまうのでメモ。さくらインターネットの VPS で適当なユーザーを作成して sudo 権限を与えてから作業。

ちょうど去年くらいの Realtime Web hack-a-thon で Windows でのビルドとかやってたんだなぁ、と振り返ると、本体だけでなく周辺ライブラリが充実してきたスピードも目を見張るものがある。

Porting Node to Windows With Microsoft’s Help (node blog)
Installing Node.js On Windows (MOZILLA WEBDEV)

Node.js のインストール

基本的な環境の準備

$ cd /usr/local
$ sudo mkdir src/archive
$ sudo chgrp -R wheel src
$ sudo chmod 775 src src/archive/
$ sudo yum -y install openssl-devel

パッケージをダウンロードして展開

$ cd /usr/local/src/archive
$ wget http://nodejs.org/dist/node-v0.4.12.tar.gz
$ cd ..
$ tar -xzvf archive/node-v0.4.12.tar.gz

コンパイルしてインストール

$ cd /usr/local/src/node-v0.4.12
$ ./configure --prefix=/usr/local/nodejs/node-v0.4.12
$ make
$ sudo make install

シンボリックリンクを作成してバージョンを確認

$ cd /usr/local/nodejs
$ sudo ln -s node-v0.4.12 latest
$ /usr/local/nodejs/latest/bin/node -v

npm のインストール

Node のパッケージマネージャーをインストールする。 Python における pip みたいなもの。

パスの調整をすれば、後はドキュメント通り。

$ curl http://npmjs.org/install.sh | sudo PATH=$PATH:/usr/local/nodejs/latest/bin sh

/usr/local/nodejs/latest/bin に npm コマンドがインストールされる。

npm は本体に付属してくれても良いんじゃないかな、とは思うけど、双方の開発がかなり安定するまでは難しいのかも。とはいえ、curl コマンドが無い Windows 環境用には同梱されて欲しい。

express のインストール

express は Web アプリケーション・フレームワークのこと。ロガーとか、ミドルウェアが色々と実装されているので便利。

マシンの利用用途にもよるが、モジュールをシステムグローバルにインストールする場合は "-g" オプションを付ける。 /usr/local/nodejs/latest/bin に express コマンドがインストールされる。

$ export PATH=$PATH:/usr/local/nodejs/latest/bin
$ sudo PATH=$PATH:/usr/local/nodejs/latest/bin /usr/local/nodejs/latest/bin/npm install -g express

たとえば、 "http-proxy" というアプリケーションの作成

$ [ -d projects ] || mkdir projects
$ cd projects
$ express http-proxy
$ cd http-proxy
$ npm install -d

開発用サーバーを起動

$ node app.js

環境を切り替えるには NODE_ENV を指定

$ NODE_ENV=production node app.js

forever でデーモン化

プロダクション環境で最適な方法は分かりませんが、この辺の記事が参考になりそう。

node.js+express-mvc-bootstrapをdaemontoolsでデーモン化
forever - github.com
daemon.js - github.com
setting NODE_ENV for node.js + expressjs application as a daemon under ubuntu - stackoverflow.com

forever を使う場合は次のような手順。

npm でシステムグローバルにインストール。

$ sudo PATH=$PATH:/usr/local/nodejs/latest/bin /usr/local/nodejs/latest/bin/npm install -g forever

forever コマンドの start アクションにスクリプトを指定。

$ export PATH=$PATH:/usr/local/nodejs/latest/bin
$ forever start app.js

自前で init.d 用スクリプトなどを書くよりは断然簡単で、 list アクションで稼働アプリケーションを一覧表示できるのも嬉しい。 (ターミナルによっては色付きで表示)

$ forever list
info:   Running action: list
info:   Forever processes running
data:       uid  command script forever pid   logfile                         uptime
data:   [0] XnU4 node    app.js 32290   32291 /home/shigeru/.forever/XnU4.log 0:0:0:17.44

止めるときは stop を使う。

$ forever stop app.js

終わりに

たまには JavaScript を書かないとー、というときに、さくらのVPSは便利。 Amazon の EC2 でも変わらないけど、なんとなく SSH のレスポンスが早い気もする。

「なぜ Node.js を使うのか？」という点では Facebook の中の人の意見に賛成だけど、そもそも JavaScript をバリバリ書ける人は多いのか、という点が大きな疑問だったり。。。

Node.js at Facebook - Why it's Needed and What's Holding it Back - readwriteweb.com

じゃ、Dart を使えば解決？かというと、今は微妙だと感じる。移行できる資産が存在しないのもネック。

Dart (STRUCTURED WEB PROGRAMMING) - dartlang.org

どんなプログラミング言語を使うにしても、プロジェクトのライフサイクルを意識して開発できないと厳しい感じ。それを支援するツールも必要で、パッケージ管理やテスト、ドキュメンテーションは必須。誰かが開発するとは思うけど、どれだけ熱意のある人が集まるかでスタートダッシュが変わるので、単純に構文がイケテル、とかはそこまで重要でもない気がする。 (Google にはソフトウェアエンジニアが多いので問題にはならないかもしれないが)

ちょっと関係ないけど、「コンピュータの名著・古典100冊」の一節が簡潔で分かりやすい。

日本語の場合でも、文法を知ることと文章を書くこととの間には大きなギャップがある。プログラミングも同じである。文法を知ることとよいプログラムを書くことの間には大きなギャップがある。

名著や古典を紹介する本だけど、これはこれで良い本。面接で何を聞くか？というトピックは紛糾しやすいけど、この中の10冊以上をきちんと読んでいる人ならハズレない気がする。もちろん Node.js にはノータッチだけども。

Nginx でレスポンスヘッダーを追加する

2011-10-02T22:33:00.000+09:00

Nginx の HttpHeadersMoreModule を使うと、HTTP レスポンスにヘッダーを付け足せるようなので導入してみます。特定の条件の場合にヘッダーを追加できるとクロスドメイン通信を実現できますので、 JSON か XML でレスポンスを返せるサーバーソフトウェアのクライアントサイドを実装する敷居が下がるはずです。要するに、JavaScript で Solr のカスタムクライアントを実装できるかもしれませんね、という話です。

HttpHeadersMoreModule は追加モジュールであるため、ソースコードを取得して、 Nginx のビルドオプションで明示する必要があります。自前でソースコードをコンパイルするところから始めますので、すんなりいかない場合もあるかもしれません。実行環境には Amazon の EC2 を使います。

この辺の続きです。

Nginx のコンパイル

nginx-1.0.8 を使います。 headers-more-nginx-module のバージョン 0.15 は 1.0.5 で動作確認しているようですが、たぶん 1.0.8 でも大丈夫でしょう。

Nginx 自体をコンパイルするためには PCRE (Perl Compatible Regular Expressions) も必要になりますので、合計で次の３つのソースアーカイブを用意します。

nginx-1.0.8
headers-more-nginx-module-0.15
pcre-8.13

$ [ -d src ] || mkdir src
$ cd src
$ wget http://nginx.org/download/nginx-1.0.8.tar.gz
$ wget ftp://ftp.csx.cam.ac.uk/pub/software/programming/pcre/pcre-8.13.tar.gz
$ wget -O headers-more-nginx-module-0.15.tar.gz https://github.com/agentzh/headers-more-nginx-module/tarball/v0.15
$ for f in `ls -1 *.tar.gz`; do tar -xzvf $f; done

コンパイラなどをインストールしておきます。

$ sudo yum -y install gcc zlib-devel

configure スクリプトにいくつかのオプションを渡してビルドします。

$ cd nginx-1.0.8
$ ./configure \
        --prefix=/usr/local/nginx/nginx-1.0.8 \
        --with-pcre=../pcre-8.13 \
        --add-module=../agentzh-headers-more-nginx-module-137855d
$ make

コンパイルが通ったらインストールします。バージョンの違いで嵌まるとイヤなのでバージョン番号も残しておきます。

$ sudo make install
$ cd /usr/local/nginx
$ sudo ln -s nginx-1.0.8 latest

インストールできたら起動してみます。

$ cd /usr/local/nginx/latest
$ sudo ./sbin/nginx

wget などでアクセスして、Server が nginx であることを確認します。

$ wget -Sq "http://localhost"
  HTTP/1.1 200 OK
  Server: nginx/1.0.8
  Date: Sun, 02 Oct 2011 11:56:12 GMT
  Content-Type: text/html
  Content-Length: 151
  Last-Modified: Sun, 02 Oct 2011 11:52:43 GMT
  Connection: keep-alive
  Accept-Ranges: bytes

アクセスログも確認しておきます。

$ tail logs/access.log

Nginx の設定

more_set_headers を使ってみます。 /usr/local/nginx/latest/conf/nginx.conf に次の記述を追加します。

location /search {
    more_set_headers 'X-MyHeader: blah' 'X-MyHeader2: foo';
}

Nginx を再起動します。

$ sudo pkill nginx
$ sudo ./sbin/nginx

/search にアクセスするとヘッダーが追加されていますね。

$ wget -Sq "http://localhost/search"
  HTTP/1.1 404 Not Found
  Server: nginx/1.0.8
  Date: Sun, 02 Oct 2011 12:01:47 GMT
  Content-Type: text/html
  Content-Length: 168
  Connection: keep-alive
  X-MyHeader: blah
  X-MyHeader2: foo

クロスドメインの設定

サーバー側で Solr を動かして Nginx でプロキシさせるために、 stackoverflow の回答を参考に設定します。

Apache/Nginx: proxy POST requests to remote server, handle OPTIONS requests locally - stackoverflow.com

nginx.conf はこんな感じ。

location /solr {
    if ($request_method = 'OPTIONS') {
        more_set_headers 'Access-Control-Allow-Origin: *';
        more_set_headers 'Access-Control-Allow-Methods: GET, OPTIONS';
        more_set_headers 'Access-Control-Max-Age: 1728000';
        more_set_headers 'Content-Type: text/plain; charset=UTF-8';

        return 200;
    }

    more_set_headers 'Access-Control-Allow-Origin: *';
    proxy_pass       http://127.0.0.1:8983/solr;
}

HTTP の OPTIONS を処理する必要性はこの辺で。

HTTP access control - developer.mozilla.org
jQuery $.ajax(), $.post sending “OPTIONS” as REQUEST_METHOD in Firefox

JavaScript で Solr のレスポンスを表示

ローカルマシンで適当な HTML と JavaScript (solr-search.html, solr-search.js) を用意します。 jQuery と jQuery Template、それから Twitter Bootstrap を読み込んでおきます。

solr-search.html - github
solr-search.js - github

HTML のあるディレクトリで HTTP サーバーを立ち上げます。

$ python -m SimpleHTTPServer

ブラウザーで http://localhost:8000/solr-search.html にアクセスし、検索キーワードを入力して実行すると、検索結果が表示されます。(冒頭のスクリーンショット)

Firebug などでレスポンスヘッダーを確認すると、 Access-Control-Allow-Origin が設定されています。

あとは好みに応じて実装すればカスタムクライアントを実装できます。特定のフィールドだけを一覧形式で表示したい場合には便利かもしれません。

終わりに

Nginx でレスポンスヘッダーを追加してみました。追加モジュールを使う場合は、ソースアーカイブを取得してコンパイルオプションを調整する必要があります。独自環境を使っている場合にはコンパイルが大変かもしれませんが、たいがいのアーキテクチャではサクッと使えると思います。

ヘッダーにも多様な役割のものがありますが、ここではクロスドメイン通信に焦点を当てました。 JavaScript によるクロスドメイン通信には色々と難しい問題がありますが、サーバーサイドにプロキシを追加して実現する方法はとてもお手軽だと思いました。

なお、Solr の場合は json.wrf パラメータを使うことで JSONP を実現できます。このため、Solr で JSON だけを使う場合にはこの記事の内容は不要です。たとえば、次のリンクのようにして実現できます。

Solr の JavaScript クライアントとしては ajax-solr があります。リクエスト URL とプロキシ URL を設定できるようになっていますので、きちんとした自前のクライアントページを構築するならこちらを使うべきでしょう。

ajax-solr
SolrJS (以前に実装されたもの)

用途に合わせて様々な組み合わせや制約がありますが、何かのときに役立つと良いのかな、と。

Nginx を Solr のフロントに使ってみる

2011-10-02T10:26:00.000+09:00

Solr のフロントに Nginx を使ってみます。外部からも select はできるけど update はできないようにして、 admin には BASIC 認証をかけます。

クリーンな環境の方が分かりやすいので、Amazon の EC2 を使います。

EC2 のインスタンスを用意

基本的な構成でインスタンスを作成します。 SSH のための 22 番ポートと、HTTP のための 80 番ポートを開放しておきます。細かい手順はこの辺で。

Amazon EC2 を使ってみる (１月の記事)
ec2-api-tools - blog.withsin.net

ローカルマシンから EC2 のインスタンスには SSH で接続しますが、このときにローカルマシンにポートを転送させます。 Solr は Jetty を使って 8983 番ポートで起動し、Nginx はデフォルトの 80 番ポートで起動させ、ローカルマシンでは、それぞれを 8080 番ポートと 8000 番ポートに対応付けます。

$ ssh -L8080:localhost:8983 -L8000:localhost:80 -l ec2-user -i {PRIVATE_KEY} {IP_ADDRESS}

もちろん {PRIVATE_KEY} と {IP_ADDRESS} は環境に合わせて適当な文字列を使います。

以降の作業はこのインスタンス上で進めます。

Solr を準備

Solr の 3.4 をダウンロードして展開します。

$ wget http://ftp.riken.jp/net/apache/lucene/solr/3.4.0/apache-solr-3.4.0.tgz
$ tar -xzvf apache-solr-3.4.0.tgz

example ディレクトリに移動して、付属の Jetty を使って起動します。

$ cd apache-solr-3.4.0/example
$ java -jar start.jar &

EC2 インスタンスの 8983 番ポートはローカルマシンの 8080 番ポートにフォワードされていますから、ブラウザーで http://localhost:8080/solr/admin にアクセスすると、管理画面が表示されます。

Nginx を準備

パッケージ管理ソフトを使って Nginx をインストールし、起動スクリプトから起動させます。自動起動を有効にする場合にはその設定もしておきます。

$ sudo yum -y install nginx
$ sudo /etc/init.d/nginx start

(この記事を書いている時点では nginx-0.7.67 のパッケージを使いますので、最新版を使いたい場合にはソースコードを自分でビルドします。)

EC2 インスタンスの 80 番ポートはローカルマシンの 8000 番ポートにフォワードされていますから、ブラウザーで localhost:8000/ にアクセスすると、ウェルカムページが表示されます。

設定ファイル置き場も確認しておきます。

$ tree /etc/nginx/
/etc/nginx/
├── conf.d
│   ├── ssl.conf
│   └── virtual.conf
├── fastcgi.conf
├── fastcgi.conf.default
├── fastcgi_params
├── fastcgi_params.default
├── koi-utf
├── koi-win
├── mime.types
├── mime.types.default
├── nginx.conf
├── nginx.conf.default
└── win-utf

Nginx の設定

プロキシの設定をします。 Nginx に /search でアクセスされたら Solr の /solr/select にフォワードします。 /etc/nginx/nginx.conf に次の記述を追加します。

location /search {
    proxy_pass   http://127.0.0.1:8983/solr/select;
}

Nginx を再起動します。

$ sudo /etc/init.d/nginx restart

ブラウザーで http://localhost:8000/search?q=*:* にアクセスすると空の結果を意味する XML が返されます。

次に管理画面に BASIC 認証をかけます。 wiki の設定をほぼそのまま適用します。

HttpAuthBasicModule - wiki.nginx.org

/etc/nginx/nginx.conf に設定を追加します。

location /admin {
    proxy_pass            http://127.0.0.1:8983/solr/admin;
    auth_basic            "Restricted";
    auth_basic_user_file  htpasswd;
}

パスワードファイルを作成します。パスは、 nginx.conf ディレクトリからの相対パスで決定します。 nginx のプリフィクスディレクトリからではありませんので、インストール方法によっては注意が必要です。

$ sudo htpasswd -c /etc/nginx/htpasswd admin

htpasswd コマンドが存在しない場合には crypt(3) 関数を使って手動でパスワードファイルを作成します。何らかのツールを使った方が良いでしょうね。

Nginx を再起動します。

$ sudo /etc/init.d/nginx restart

ブラウザーで http://localhost:8000/admin にアクセスすると、 BASIC 認証のダイアログが表示されます。なお、パスを大きく変更していますので管理画面からは検索を実行できません。

Solr のテストデータ

Solr の配布パッケージに付属するサンプルデータを登録します。 Solr の example ディレクトリに exampledocs があり、ここにテストデータが保存されています。 post.sh に引数で与えた XML ファイルを登録できます。

$ cd apache-solr-3.4.0/example/exampledocs
$ ./post.sh *.xml

続けて、件数カウントのリクエストを投げます。

$ wget -qO - "http://localhost:8983/solr/select?q=*:*&rows=0&indent=on"
<?xml version="1.0" encoding="UTF-8"?>
<response>
<lst name="responseHeader">
  <int name="status">0</int>
  <int name="QTime">0</int>
  <lst name="params">
    <str name="indent">on</str>
    <str name="q">*:*</str>
    <str name="rows">0</str>
  </lst>
</lst>
<result name="response" numFound="17" start="0"/>
</response>

ローカルマシンの 8000 番ポートで確認します。ブラウザーで http://localhost:8000/search?q=*:* にアクセスすると XML で結果が返ってきます。

きちんと 80 番ポートが開放されていると、そのアドレスにアクセスすれば同じ結果が得られますね。

開放しているポートからプロキシするのは検索用のハンドラだけですから、ドキュメントインデクスの更新は閉じたネットワーク内で完結します。間違ってドキュメントを削除することは防止できますから、 URL を公開しても問題ありません。

終わりに

Nginx を Solr のフロントに使ってみました。「それ、Apache でいいじゃん」というのはその通りで、単純に Nginx を使ってみたかったのでやってみた、という感じです。実際に手を動かすととても簡単なことが実感できますので、 Nginx ってなんだか難しそう... とは杞憂に終わりました。

Nginx は Web サーバーというよりプロキシサーバーですから、複数の Solr サーバーに対してロードバランシングもできます。アクティブ / スタンバイ構成ではなく、複数台のサーバーを並べて使えると、マシンが遊んでしまうこともなさそうです。

EC2 に関しては、ちょっとした動作確認にマイクロインスタンスを使うのは便利だな、と思います。管理用のコマンドラインツールもありますし、パッケージも不便なく利用できます。サービスとして動かし続ける場合はそれなりのお金がかかるでしょうが、学習用にスポットとして使う分には書籍代より安いですし、そもそもダラダラと作業しないようになり、可能なものは事前に調べるようになる気がします。なにより、自分のマシンがミドルウェアでいっぱいにならないのは嬉しいですね。

使い終わったインスタンスは ec2-stop-instances で停止させておきましょう。インスタンスの ID は ec2-describe-instances で確認できます。

ec2-stop-instances (ec2stop)

History API を使ってみる

2011-09-15T22:55:00.002+09:00

History API を使ってみます。正確には、History API をクロスブラウザ対応でラップしてある history.js を使ってみます。

history.js は jquery-history を再実装したもので、 jQuery のプラグインとしてしか使えなかったものを汎用的に再実装し、各種ライブラリへのアダプタを用意したものです。アダプタは YUI や Prototype などにも対応しているらしいので、 jQuery 以外の JavaScript ライブラリと組み合わせることもできます。

なお、ブラウザの履歴に関する操作は Mozilla のサイトで網羅的に解説されています。

Manipulating the browser history

ライブラリの読み込み

ブラウザの履歴 (window.history) には back() や go() などの API がありましたが、いわゆるモダンブラウザには pushState() や replaceState() という API が追加されています。このため、ターゲットとするブラウザによって読み込むべき JavaScript ファイルが異なります。ごちゃごちゃ考えるのが面倒な場合にはすべてを読み込めば動きますが、 HTML5 に関することを HTML4 までの世界に適用させるべきかは一考の価値がありそうです。

Intelligent State Handling

ともあれ、jQuery をベースにしてザクッと全てを読み込む場合は次のような感じでしょうか。 $STATIC_URL は適当に調整するか、何らかのビルドスクリプトで置換します。

  <script src="//ajax.googleapis.com/ajax/libs/jquery/1.6/jquery.js"></script>
  <script>window.jQuery || document.write('<script src="$STATIC_URL/js/jquery.min.js">\x3C/script>')</script>
  <script src="//ajax.microsoft.com/ajax/jquery.templates/beta1/jquery.tmpl.min.js"></script>
  <script>window.JSON || document.write('<script src="$STATIC_URL/js/json2.min.js">\x3C/script>')</script>
  <script src="$STATIC_URL/js/amplify.store.min.js"></script>
  <script src="$STATIC_URL/js/history.adapter.jquery.min.js"></script>
  <script src="$STATIC_URL/js/history.min.js"></script>
  <script src="$STATIC_URL/js/history.html4.min.js"></script>

なお、 jquery.tmpl.min.js は他の用途で使っているものなので、History API とは関係ありません。また、各種ファイルに .min を付けているのは個人的な管理を簡単化するためです。

履歴の変化を追いかける

ライブラリを読み込んだら、最初のコードを書きます。これは history.js の README の最初の方にあるものをコピペすれば動くはずです。とりあえずこんな感じ。

$(function() {

    var History = window.History; // 小文字ではなく大文字の H を使います。
    if (!History.enabled) {
         // History.js が無効になっています。
         // HTML4 のブラウザをサポートするかどうかによります。
        return false;
    }

    // StateChange イベントを紐付けます。
    History.Adapter.bind(window, 'statechange', function() { // popstate ではなく statechange を使います。
        var State = History.getState(); // event.state ではなく History.getState() を使います。
        History.log(State.data, State.title, State.url);
    });

    // 状態を遷移させます。
    // 引数は順番に「状態オブジェクト」「タイトル」「URL」です。
    History.pushState({state:1}, "State 1", "?state=1");
    History.pushState({state:2}, "State 2", "?state=2");
    History.replaceState({state:3}, "State 3", "?state=3");
    History.pushState(null, null, "?state=4");
    History.back();
    History.back();
    History.back();
    History.go(2);

});

「状態オブジェクト」って何？という感じですが、履歴のある時点に関連付く JavaScript オブジェクト (シリアライズ可能なもの) なら何でも良さそうです。とはいえデータサイズには上限があり、Firefox の場合は 640k だそうです。これを超過した場合は例外が投げられますので、大きなデータを保存しておくためには sessionStorage や sessionStorage を使いましょう、とのこと。

さて、HTML ファイルを開いて Firebug などの JavaScript コンソールを開いてみると次のようになります。ブラウザのアドレスバーも変わっているはずです。

終わりに

history.js を使ってブラウザの履歴を管理しました。サーバーサイドから JSON を送るだけにしてしまうと「ページ」という概念が希薄になりがちですので「戻る」「進む」が思い通りにいかないことが多々あります。その解決策として pushState() はとても良い方法だと思います。

サーバーサイドで HTML を生成する場合には HTTP の拡張ヘッダーを組み合わせて使う応用もあります。 jQuery Mobile でも使われるらしいので、ちょっと知っておくと良さそうです。

jquery-pjax - github.com
pjax - heroku.com

自分で Web アプリケーションを作る、という視点では PJAX の方が良いかもしれませんが、 Solr などの JSON ライターが存在するアプリケーションと組み合わせる場合には window.history を管理する方法は有用そうですね。

おまけ

history.js にはアダプタが登場しましたが、 JavaScript におけるデザインパターンや実装パターンは英語の記事だとよくまとまっています (日本語の記事は特に調べていませんが)。サーバーサイド JavaScript でも基本的なパターンは押さえておくべきなので、何らかのプログラムを書くなら一読しておくべきなのかな、と。

また、多様なパターンを覚えておくと非同期処理もすっきり記述できるかもしれませんね。

Asynchronous Programming in JavaScript with "Promises"

第６回 Solr 勉強会に行ってきた

2011-09-12T23:28:00.003+09:00

Solr の勉強会に行ってきました。

第6回Solr勉強会 - atnd.org
#SolrJP - twitter.com

ので、そのメモ。

会場を提供してくださった ECナビさん、運営者の方々、ありがとうございました。

思ったよりも利用事例って多いんだなぁ、というのが雑感です。とはいえ、解析関係の話はまだ目新しい様子なので、検索ログを Hadoop に突っ込んでデータマイニングしたらこんなことが改善された、という流れが増えてくると嬉しいのかなぁ、と。問題はマイニングの結果に何を求めるかが曖昧ってことだったりしますけど。

発表とか

ロンウイット関口宏司さん

Lucene/Solr 3.2 から 3.4 辺りの話題です。 3.4 では電源断によるデグレ改修が大きなトピックらしいので、 3.4 が出たら 3.3 以前のバージョンは使わないようにしましょう、とのことです。

IndexWriter.addDocuments という s が付いた複数形の API が追加されました。コレクションを追加できるようになったのは嬉しいかもしれませんね。

TieredMergePolicy で文書の親子関係を定義できるようになります。マージするアルゴリズムに変更があったそうなので、ドキュメントの登録順に依存しているアプリケーションがある場合は要注意だそうな。ドキュメントをマージする様子はこちらのブログに掲載されているビデオが分かりやすいと思います。

Visualizing Lucene's segment merges

検索対象はすべてをインデクスに保存しておかなくても良いようで、 ExternalFileField を使うと外部ファイルで管理された内容から関数クエリなどを実行できるそうです。インデクス更新いらずなので、負荷軽減に役立つかも。

ExternalFileField (javadoc)

PathHierarcyTokenize はファイルパスなどを分割するためのトークナイザーですが、分割したトークンを逆順に返すような ReversePathHierarcyTokenize が追加されたそうです。パスで分割するイメージはこちらのブログ記事が分かりやすい感じ。

Path Hierarchy Tokenizer

あと、クラスタリングするためのソフトウェアとして Carrot2 があります。検索システムが大規模かつ複雑になってくると役立ちそうですね。

＠PENGUINANA_ さん Solr＠cookpad

Cookpad での事例紹介でした。人気順の検索などだけでなく、社内ツールでも使ってるそうです。３ヶ月くらいで Tritonn からフルスクラッチで移行したとのこと。なんと Solr 4 nightly を使って。。。

Cookpad には Ruby 開発者が多いので、バッチ処理はすべて Ruby で記述するそうです。社内の共通言語だから他の人から意見をもらいやすいんだとか。 Analyzer を自作する場合は Java で実装する必要がありますが、分かち書き、正規化、同義語展開を事前に Ruby バッチで処理しているそうです。

運用面では、 munin でキャッシュのヒット率などをコア別に監視しています。グラフ化されているとパッと見でもなんとなく分かりやすいですね。

クエリ: QTime / QPS
キャッシュ: hit / eviction
インデクス: サイズ / ドキュメント数
レプリケーションの所用時間

Solr はインデクスだけを保存する、というポリシーのようです。それぞれのスキーマで indexed=true と stored=false を設定しているため、ファイルサイズが小さくなり、リプリケーションの高速化に寄与するそうです。本文情報は MySQL から取得すれば良いので、確かに合理的な感じです。

ある検索語句にヒットするドキュメントがインデクスに存在するかを確認するためには、 Bloom Filter のコンポーネント (BloomIndexComponent) があります。何かの機会に知っておくと良さそう。

その他にも、Cookpad では本番環境で複数のバージョンを持つ仕組みを用意してありますので、実際のデータを使って新しい手法をタイムリーに検証できるみたいです。

どんどん使う – Extension Frameworkの紹介

発表いろいろ

その他にも充実した内容の発表でした。詳しい内容は後日に資料が公開されることでしょう。

データセクション株式会社高井さん
@takahi-i さん - mixi での検索システムなど
@yutakashino さん – solrとRの連携について
阿部さん – Apache ManifoldCF

mixi では先月から検索システムに Solr を投入したそうですが、こうした複数台の Solr サーバと大量のインデクスデータを管理するために Anuenue が作られたようです。ナレッジの蓄積と人材の流動性を天秤にかけると、内製検索エンジンから OSS に移行する事例は増えるのかなぁとぼんやり思いました。

Solr にはファセット検索機能も組み込まれていますので、多様なシステムと結合していくことも可能だと思います。プラグインで拡張していく方法、解析用ツールにデータを流す手法、サーバーサイドで手数をかけずに何らかの表示をさせる方法など、応用事例はたくさん出てきそうですね。

Bobo Solr Plugin

Bobo, being a Lucene extension for structured data, can be exposed thru the Solr facet interface.
ManifoldCF

会社の中にある文書サーバからセキュリティ情報を維持してクローリングできる。ACL も考慮。
SolrCloud
ajax-solr (Solr の JavaScript ライブラリ)

Waf と YUI Compressor で静的ファイルを圧縮する

2011-09-06T21:51:00.000+09:00

Waf を使って JavaScript と CSS を探し、YUI Compressor の引数に渡すことで静的ファイルを圧縮します。

Apache Ant で YUI Compressor を使う方法は、次の英語の記事で網羅的に説明されています。

Building Web Applications With Apache Ant - Julien Lecomte's Blog
- Apache Ant
- Build types - 開発用、検証用、製品用に分けてビルドする
- Concatenate your JavaScript and CSS files - 順番を意識してファイル内容を結合する
- Preprocess your JavaScript files using CPP - C のプリプロセッサを使って条件付きビルドを実現する
- Minify your JavaScript and CSS files - yuicompressor.jar を使って JavaScript と CSS を圧縮する
- Work around caching issues - 変更のないファイルをキャッシュするためのテクニック
- Deploy your application - サーバーにファイルを転送し、サービスを再起動する
- Conclusion - みんながビルドプロセスを考慮すべき

この記事では yuicompressor.jar の使い方の部分だけを取り上げます。なお、Python 関連では buildout も使えます。

Minifying JavaScript and CSS with buildout (英語のブログ)

インストール

まずはいくつかのファイルをインストールします。 virtualenv を使って Waf を利用可能にし、JAR ファイルを配置します。 PyPI に yuicompressor 2.4.6.1 がありますので pip で JAR ファイルもインストールできます。

$ virtualenv --distribute yuicompress-test
$ cd $_
$ source bin/activate
$ curl http://waf.googlecode.com/files/waf-1.6.7 >bin/waf
$ chmod +x bin/waf
$ pip install yuicompressor
$ find . -name yuicompressor\* -type f
./bin/yuicompressor
./lib/python2.7/site-packages/yuicompressor/yuicompressor.jar

bin/yuicompressor というコマンドがインストールされます。これは yuicompressor.jar ファイルへのラッパースクリプトになっています。事前条件として、実行環境には Java がインストールされている必要があります。

入出力ファイルの確認

static というディレクトリにふたつのファイル - script.js, style.css - を置きます。これらのファイルを圧縮し、ビルドディレクトリに出力します。このとき、圧縮した結果は拡張子の前に "-min" を付けたファイルに出力します。

サンプルの準備

まずはサンプルファイルを準備します。

$ mkdir static
$ touch $_/script.js $_/style.css
$ ls static
script.js  style.css

ant_glob() と change_ext()

ant_glob() を使って、拡張子が .js か .css に一致するファイルを探します。結果はリストとして取得できますので、ループを回してファイルを処理します。このとき、 change_ext() を使ってファイル名を変更します。

wscript:

APPNAME = 'yuicompress-test'
VERSION = '1.0.0'

top = '.'
out = '_build'

def configure(ctx):
    ctx.find_program('yuicompressor')

def build(bld):
    assets = bld.path.ant_glob(['**/*.js', '**/*.css'])
    for src in assets:
        dst = src.change_ext('-min' + src.suffix())
        print "%s\n\t-> %s" % (src.abspath(), dst.abspath())

実行すると次のようになります。

$ waf configure build
Setting top to                           : /private/tmp/yuicompress-test
Setting out to                           : /private/tmp/yuicompress-test/_build
Checking for program yuicompressor       : /private/tmp/yuicompress-test/bin/yuicompressor
'configure' finished successfully (0.004s)
Waf: Entering directory `/private/tmp/yuicompress-test/_build'
/private/tmp/yuicompress-test/static/script.js
        -> /private/tmp/yuicompress-test/_build/static/script-min.js
/private/tmp/yuicompress-test/static/style.css
        -> /private/tmp/yuicompress-test/_build/static/style-min.css
Waf: Leaving directory `/private/tmp/yuicompress-test/_build'
'build' finished successfully (0.059s)

ループを回すのではなく、拡張子に対してルールを設定することもできます。この方が依存関係の解析が早くなるから、、、か確証はありませんが、きっと高速なはずです。

8.2. Name and extension-based file processing - Waf book

YUI Compressor の実行

yuicompressor コマンドを引数なしで実行すると、使い方が表示されます。

$ yuicompressor

Usage: java -jar yuicompressor-x.y.z.jar [options] [input file]

Global Options
  -h, --help                Displays this information
  --type <js|css>           Specifies the type of the input file
  --charset <charset>       Read the input file using <charset>
  --line-break <column>     Insert a line break after the specified column number
  -v, --verbose             Display informational messages and warnings
  -o <file>                 Place the output into <file>. Defaults to stdout.
                            Multiple files can be processed using the following syntax:
                            java -jar yuicompressor.jar -o '.css$:-min.css' *.css
                            java -jar yuicompressor.jar -o '.js$:-min.js' *.js

JavaScript Options
  --nomunge                 Minify only, do not obfuscate
  --preserve-semi           Preserve all semicolons
  --disable-optimizations   Disable all micro optimizations

If no input file is specified, it defaults to stdin. In this case, the 'type'
option is required. Otherwise, the 'type' option is required only if the input
file extension is neither 'js' nor 'css'.

最後の部分を日本語に訳してみると次のような感じでしょうか。

入力ファイルが指定されないと標準入力から読み取ります。この場合は、 'type' オプションは必須です。そうでなければ、入力ファイルの拡張子が 'js' でも 'css' でもない場合に限り、 'type' オプションは必須です。

ということで拡張子を気にする必要はありませんので、コマンドラインから次のように実行します。

$ yuicompressor static/script.js >_build/static/script-min.js
$ yuicompressor static/style.css >_build/static/style-min.css

もしくは、 -o オプションを使って出力先を指定します。

$ yuicompressor -o _build/static/script-min.js static/script.js
$ yuicompressor -o _build/static/style-min.css static/style.css

-o オプションにはマクロのような機能もありますので、複数ファイルを一括で指定することもできるそうです。

Waf で実行させる

wscript に独自のタスクを定義できますので、先ほどのルールを参考にしてタスククラスを書きます。

wscript にまとめると、次のようになります。

APPNAME = 'yuicompress-test'
VERSION = '1.0.0'

top = '.'
out = '_build'


def configure(ctx):
    ctx.find_program('yuicompressor')


from waflib.Task import Task

class yuicompressor(Task):
    def run(self):
        return self.exec_command('yuicompressor %s >%s' % (
                self.inputs[0].abspath(), self.outputs[0].abspath()
            ))


def build(bld):
    assets = bld.path.ant_glob(['**/*.js', '**/*.css'])
    for src in assets:
        dst = src.change_ext('-min' + src.suffix())
        t = yuicompressor(env=bld.env)
        t.set_inputs(src)
        t.set_outputs(dst)
        bld.add_to_group(t)

適当なスクリプトとスタイルシートを書いてから実行してみます。

$ waf distclean configure build
'distclean' finished successfully (0.002s)
Setting top to                           : /private/tmp/yuicompress-test
Setting out to                           : /private/tmp/yuicompress-test/_build
Checking for program yuicompressor       : /private/tmp/yuicompress-test/bin/yuicompressor
'configure' finished successfully (0.004s)
Waf: Entering directory `/private/tmp/yuicompress-test/_build'
[1/2] yuicompressor: static/script.js -> _build/static/script-min.js
[2/2] yuicompressor: static/style.css -> _build/static/style-min.css
Waf: Leaving directory `/private/tmp/yuicompress-test/_build'
'build' finished successfully (0.811s)

生成されたファイルを比較してみると、次のようになります。

$ ls -l static/ _build/static/ |
    awk 'NF == 9 { printf "%-20s -> %5d (bytes)\n", $9, $5; }' |
    sort -r
style.css            ->  1621 (bytes)
style-min.css        ->  1422 (bytes)
script.js            ->   357 (bytes)
script-min.js        ->   215 (bytes)

注意

YUI Compressor を実行すると、解読できない構文エラーが報告されることがあります。ソースコードのエラーかもしれませんが、YUI Compressor 側のバグかもしれませんので注意が必要です。

Reserved words are still valid property names - yuilibrary.com

簡単に空白などを取り除きたい場合は、 JSMin の方が分かりやすいかもしれませんね。

終わりに

Waf を使って JavaScript と CSS を圧縮しました。 Ant でいいんじゃないの？と思った場合は、Ant の方が良いでしょうね。 Waf を使うメリットは Python ですべてを記述できることです。 Ant だと XML でルールを書きますが、独自のタスクを定義する場合には Java のクラスを実装する必要があります。この辺の好きずきかな、と思いました。

文脈は異なっても、処理系のことはあまり気にせず文法などで選びましょう、という流れは今後も加速するはずですから、色々と知っておいた方が良いのかな、というのが基本となる動機です。

Heroku for Java :

"A common deployment infrastructure reduces language choice to just a question of syntax and libraries."

ソフトウェアを動かすためのインフラが汎化されると、プログラミング言語の選択は構文とライブラリを選ぶだけの問題になります。 (Java だから特定のベンダーサポートがあって ... という話は意味をなさない)

なお、 wscript のタスクに依存関係を持たせる方法はこちらにも書いています。

Waf を使って構文チェックしてからコピーする

プロフェッショナルの条件 - 転職

2011-09-04T16:50:00.002+09:00

ドラッカーの「プロフェッショナルの条件」という本を読んでいます。 2000年に出版された書籍ですが、「はじめに」の部分にこんな記述があります。

1950年代、1960年代のアメリカでは、パーティで会った人に何をしているかを聞けば、 ... (省略) ... 雇用主たる組織の名前が返ってきた。当時のアメリカは今日の日本と同じだった。 ... (省略) ... ところが今日、アメリカでは「冶金学者です」「税務をやっています」「ソフトウェアの設計です」と答えが返ってくる。少なくともアメリカでは、知識労働者は、もはや自らのアイデンティティを雇用主たる組織に求めなくなっており、専門領域への帰属意識をますます強めている。今日では日本においてさえ、若い人たちが同じ傾向にある。

出版から10年以上が経過していますので、この傾向はより顕著になっているように思います。なお、知識労働と言っても色々な種類がありますが、物理的な機器に依存しない人は特にこの傾向が強いのかな、と感じます。実験機材の購入に数億円が必要な研究領域では組織への依存度が高いでしょうし、手術の執刀のように属人性が高い領域では個人への依存が高くなるでしょう。

自分が中学生だったときの国語の教科書 (出版社は忘れた) に「転石苔を生じず」という諺に関する文章がありました。「苔」を捉える感覚が異なると諺のニュアンスも変わってしまう、という趣旨の内容だったと思います。確か、日本人とイギリス人の対比だったはずです。苔の美的価値を高く捉えれば石を転がさない方が良いでしょうし、その逆であれば石は転がし続けた方が良いでしょう。

転職

何の脈絡もありませんが、ソフトウェア開発者の場合は雇用主にアイデンティティを求める必然性もない、ということで、６月に転職して、数日前に無事に試用期間も終わりました。たまには神宮外苑を歩いて通勤するのも悪くないなぁ、と思います。

実際に転職してみると、定期的な自己評価の必要性を実感します。多くの会社では年に一度、あるいは半期や四半期に一度は社内の誰かと面談があるでしょうが、それ以外にも、自分自身が何ができて何ができていないかを考えてみる良い機会でした。これが整理されていないと、転職活動という側面では職務経歴書を作成できませんし、通常の業務においてもジリ貧になってしまうでしょう。 10年ひとむかし、と言われることも多いですから、昔取ったなんとやらでは立ち行かなくなっていきます。プログラマ35歳定年説？の一因もそこにあると考えています。

「プロ」という軸で考えると、サッカー選手だったら練習以外でもどこかの試合を観るでしょうし、食事などにも気をつけるでしょう。同じように、プロ意識に程度の違いこそあれ、知識労働者だったら業務時間以外でも知識を蓄積/活用する方法を模索すべきだと言えます。つまり、専門領域への帰属意識をますます強めていくことが、ひとつの競争戦略になります。

さて、ジョン・F・ケネディのことばに次のようなものがあります。会社においても個々人が自立しなければならない、とも言えますね。

Ask not what your country can do for you, but ask what you can do for your country.

自分の場合は転職の前も後もソフトウェア開発者ですが、新しい仕事ではバッチ処理や自然言語処理が必要になりそうです。ここ数年で実用例が多数紹介され始めた分野です。業務では使わなそうだけど周辺情報として知っておいた方が良いことはブログにメモしておこうかな、と思います。

(「業務で知り得た内容」は書きませんので、相変わらずニッチな話が多そうですが)

JavaScriptMVC +α

2011-08-30T21:05:00.001+09:00

JavaScriptMVC 以外に、いくつかのリンクをメモしておきます。

YUI App Framework

Yahoo の JavaScript ライブラリ - YUI - もバージョン 3.4.0 から MVC フレームワークを用意し始めました。

Announcing YUI 3.4.0 and the new YUILibrary.com - yuiblog.com
App Framework - API Document

YUI を使っている場合には、選択肢のひとつとして挙がってくるでしょう。

HTML5 Boilerplate

何事にもひな形があった方が便利です。 HTML5 Boilerplate は、基本的な HTML / JavaScript / CSS を提供してくれます。

HTML5 Boilerplate (本家)
HTML5 Boilerplate 日本語訳 (日本語訳)
HTML5 Boilerplate - CSS Radar (紹介記事)
HTML5 Boilerplate を使用して Web 開発を容易に始める (IBM developerWorks)

HTML / JavaScript / CSS

端末やブラウザーによって表現を揃えるか分離するかは難しいところです。 jQuery Conference の Nicholas Zakas の発表がひとつの指標となるかもしれません。

Progressive Enhancement 2.0 - slideshare.net

"An escalator can never break; it can only become stairs." - Mitch Hedberg

エスカレーターは決して壊れない。単なる階段になるだけだ。

また、Web ページのメタファーは印刷媒体ではなくテレビだとも主張しています。無理なく無駄なく最新技術を取り入れることができると嬉しいですね。

"Old browsers are like black & white TVs. New browsers are like HD TVs."

古いブラウザは白黒テレビのようなもので、新しいのは HD テレビのようなものだ。

このため:

"Your site SHOULD look different in different browsers."

サイトは異なるブラウザでは違って見えるべきだ。

コンテンツと視聴端末は別々に考えるべきことだからです。

なお、Nicholas Zakas さんは "High Performance JavaScript" の著者です。書籍は日本語にも翻訳されていますので、最近の JavaScript 事情 (と言っても発売は去年なので一昨年くらいの事情) を一通り眺めるにはとても良い本だと思います。 (自分が読んだときのメモ書き - Books - High Performance JavaScript)

その他に、CSS の使い方や各種のパフォーマンスについては下記の二点も良さそうです。

Presentational jQuery - slideshare.net : CSS の使い方
Building with HTML5 Tech Talk (Facebook Engineering のビデオ)

JavaScriptMVC でパッケージング

2011-08-29T21:41:00.001+09:00

JavaScriptMVC で作成したアプリケーションの配布パッケージを作成します。

一連の記事の最後になります。

ビルドする

StealJS の build.js を使ってソースコードを圧縮、結合します。依存性は StealJS が解決し、内部的には Closure Compiler を使います。

$ ./js cookbook/scripts/build.js
Building to cookbook/

BUILDING SCRIPTS ---------------
steal.compress - Using Google Closure app
   steal/steal.js
   ignoring ../steal/dev/dev.js
   cookbook/cookbook.js
   jquery/model/model.js
   jquery/class/class.js
   jquery/jquery.js
   jquery/lang/lang.js
   jquery/view/ejs/ejs.js
   jquery/view/view.js
   jquery/lang/rsplit/rsplit.js
   cookbook/models/recipe.js
   steal/less/less.js
   ignoring ../steal/less/less_engine.js

SCRIPT BUNDLE > cookbook/production.js

BUILDING STYLES ---------------
text/less
../cookbook/resources/example.less

STYLE BUNDLE > cookbook/production.css
Nice! Compressed: 27.1%  Before: 118.0 bytes  After: 86.0 bytes

JavaScript は production.js 、CSS は production.css にまとめられました。 cookbook.html から読み込む JavaScript を変更することで、開発版と製品版を切り替えられます。

ファイルをコピーする

適当な Web サーバーに JavaScriptMVC のフォルダを丸ごとコピーすれば動作しますが、製品版には不要なファイルが多いことも事実です。そこで、動作に必要なファイルだけをコピーします。

「必要なファイル」は次のものになります。

起動ファイル - steal.production.js
アプリケーション - cookbook.html, production.js, production.css
テンプレートファイル - 各種 .ejs

適当なディレクトリに次の構成でコピーします。

$ tree
.
├── cookbook
│   ├── cookbook.html
│   ├── production.css
│   ├── production.js
│   └── views
│       └── recipe
│           ├── edit.ejs
│           ├── init.ejs
│           ├── list.ejs
│           └── show.ejs
└── steal.production.js

3 directories, 8 files

パッケージにまとめる

HTML で JavaScript を読み込む部分を修正します。 steal.js ではなく、 steal.production.js を読み込ませます。ディレクトリ構成を変更していますので、 steal というディレクトリ名を取り除きます。

<script type='text/javascript'
        src='../steal.production.js?cookbook'>
</script>

あとは ZIP アーカイブなどにまとめます。

$ zip -r cookbook-0.0.1.zip steal.production.js cookbook

終わりに

開発した JavaScript ファイルなどをパッケージングしました。このフェーズで CoffeeScript と LESS はコンパイルされますので、実行時のオーバーヘッドは少なくなります。出来上がったファイル群を ZIP に固めることで、簡単に他のホストに配布できます。

JavaScriptMVC の紹介はこれでおしまいです。ベースにした英語のドキュメントはこちらです。

Get Started - javascriptmvc.com

"cookbook" という小さなアプリケーションを作る過程で、 JavaScriptMVC の主要な理念に触れてきました。コードの分離、テスト、圧縮、そしてドキュメンテーションです。何もないところから、圧縮されてテストされ、そしてドキュメントも備わったアプリケーションにたどり着いたのです。この道のりがどんなにシンプルだったか振り返ってみると本当に素晴らしいですね。

クライアントサイドのカウボーイコーディングから脱却して、サーバーサイドに引きずられることなく実装を進められそうなのは嬉しいですね。

JavaScriptMVC でドキュメントを生成

2011-08-28T17:16:00.003+09:00

JavaScriptMVC で作成したアプリケーションの API ドキュメンテーションを生成します。

この記事の続きです。

JavaScriptMVC - 概要 (2011年8月25日)
JavaScriptMVC を使ってみる (2011年8月26日)
JavaScriptMVC でテストを実行 (2011年8月27日)

API ドキュメントの生成

JavaScriptMVC でドキュメントを生成するには documentjs を使います。

cookbook アプリケーションのドキュメントを生成します。

$ ./documentjs/doc cookbook
PROCESSING SCRIPTS

  cookbook/controllers/recipe_controller.js
  cookbook/cookbook.js
  cookbook/models/recipe.js
  cookbook/resources/example.js
  cookbook/scripts/build.js
  cookbook/scripts/clean.js
  cookbook/test/funcunit/recipe_controller_test.js
  cookbook/test/qunit/recipe_test.js

GENERATING DOCS -> cookbook/docs

Using default page layout.  Overwrite by creating: cookbook/summary.ejs

生成されたものは cookbook/docs.html で確認できます。 Javadoc みたいな感じです。

@Static と @Prototype は明示的に記述しておくと良さそうです。また、 index.json を生成できるようにすると、トップページコンテンツを配置できるようです。

終わりに

サンプルアプリケーションの API ドキュメントを生成しました。メソッドの一覧を確認して、冗長なインターフェイスを作ってしまっていないか確認できます。

また、引数と戻り値を記述しておくと、しばらくしてからコードを見直すときにもキャッチアップしやすいでしょう。オブジェクトを渡すのかコールバックを渡すのか、戻り値は undefined なのかメソッドチェーンでつなげるのか。確認すべきポイントは人それぞれにあるでしょうが、一貫性のある API だと間違いが少なくなりそうですね。

次は、ソースコードを連結して、プロダクション用のファイルを生成します。

JavaScriptMVC でテストを実行

2011-08-27T13:20:00.004+09:00

実装を進める前にテストを動かしておきます。あちこちと実装が散らかってくるとデグレードが多くなりますので、出来るだけ手戻りがないように用意できることが望ましいと思います。

この記事の続きです。

JavaScriptMVC - 概要 (2011年8月25日)
JavaScriptMVC を使ってみる (2011年8月26日)

２つのテスト方法

JavaScriptMVC で利用可能なテストには次の２種類があります。

QUnit - jQuery プロジェクトで使われているテストスイート
FuncUnit - QUnit 上に構築したテストフレームワーク

それぞれのテストはブラウザでも確認できますし、コマンドラインからも実行できます。コマンドラインではブラウザをシミュレートするために Envjs を使います。

モデルの取得や生成を確認するためには QUnit を使い、ユーザーとのインタラクション (e.g. マウス操作、キーボード入力) を確認するためには FuncUnit を使います。それぞれの方法を順番に見ていきましょう。

QUnit

テスト用の HTML ファイルを cookbook/qunit.html として用意します。

<html>
    <head>
        <link rel="stylesheet" type="text/css" href="../funcunit/qunit/qunit.css" />
    </head>
    <body>
    <h1 id="qunit-header">Cookbook Application Test Suite</h1>
    <h2 id="qunit-banner"></h2>
    <div id="qunit-testrunner-toolbar"></div>
    <h2 id="qunit-userAgent"></h2>
    <ol id="qunit-tests"></ol>
    <div id="qunit-test-area"></div>
    <script type='text/javascript'
            src='../steal/steal.js?cookbook/qunit.js'></script>
    </body>
</html>

テストケースを呼び出すためのスクリプトを cookbook/qunit.js として用意します。 steal.js に渡している部分のパスです。

steal
    .plugins('funcunit/qunit')
    .then('test/qunit/recipe_test')
    ;

test/qunit/recipe_test.js は scaffold で生成されたものです。

ブラウザーで cookbook/qunit.html を開くとテストが実行されます。まずはすべてのテストケースが失敗しています。

テストケースをクリックすると、以下のメッセージを確認できます。

Died on test #1: Cookbook is not defined

モデルモジュールのローディングミスなので、 cookbook/qunit.js を次のように変更します。

steal
    .plugins('funcunit/qunit', 'jquery/model')
    .then('models/recipe')
    .then('test/qunit/recipe_test')
    ;

再度テストを実行すると、モデルを取得 / 生成するために GET / POST リクエストが発生します。サーバーサイドは何も実装していませんので、すべてがエラーになります。

サーバーサイドの実装とクライアントサイドの実装は無関係に進めたいですから、 jQuery.fixture を使ってリクエストをエミュレートします。 cookbook/qunit.js で fixture プラグインも読み込むようにします。

steal
    .plugins('funcunit/qunit', 'jquery/model', 'jquery/dom/fixture')
    .then('models/recipe')
    .then('test/qunit/recipe_test')
;

これでテストがパスします。

コマンドラインからの実行

コマンドラインからもテストを実行できます。

$ ./funcunit/envjs cookbook/qunit.html
Using Default Settings
MODULE Model: Cookbook.Models.Recipe

--findAll--
steal.js INFO: looking for fixture in ../cookbook/fixtures/recipes.json.get
  PASS
  PASS
  PASS
  PASS
  done - fail 0, pass 4

--create--
steal.js INFO: using a dynamic fixture for /recipes
steal.js INFO: Model.js - publishing recipe.created
  PASS
  PASS
  PASS okay, expected: "dry cleaning" result: "dry cleaning"
steal.js INFO: using a dynamic fixture for /recipes/1867
  done - fail 0, pass 3

--update--
steal.js INFO: using a dynamic fixture for /recipes
steal.js INFO: Model.js - publishing recipe.destroyed
steal.js INFO: Model.js - publishing recipe.created
  PASS okay, expected: "chicken" result: "chicken"
steal.js INFO: using a dynamic fixture for /recipes/25832
steal.js INFO: Model.js - publishing recipe.updated
  PASS okay, expected: "steak" result: "steak"
steal.js INFO: using a dynamic fixture for /recipes/25832
  done - fail 0, pass 2

--destroy--
steal.js INFO: using a dynamic fixture for /recipes/undefined
steal.js INFO: Model.js - publishing recipe.destroyed
steal.js INFO: Model.js - publishing recipe.destroyed
  PASS Destroy called
  done - fail 0, pass 1


ALL DONEe - fail 0, pass 10

10個のテストがすべてパスしていることが分かります。

FuncUnit

続いて、ユーザー操作に関するテストを作成します。クリックすべき要素があるか、入力フィールドが存在するか、といったことをテストします。

テスト用の HTML ファイルを cookbook/funcunit.html として用意します。

<html>
    <head>
        <link rel="stylesheet" type="text/css" href="../funcunit/qunit/qunit.css" />
        <title>FuncUnit Test</title>
    </head>
    <body>

        <h1 id="qunit-header">funcunit Test Suite</h1>
        <h2 id="qunit-banner"></h2>
        <div id="qunit-testrunner-toolbar"></div>
        <h2 id="qunit-userAgent"></h2>
        <ol id="qunit-tests"></ol>
        <script type='text/javascript'
                src='../steal/steal.js?cookbook/funcunit.js'></script>
    </body>
</html>

テストケースを呼び出すためのスクリプトを cookbook/funcunit.js として用意します。 test/funcunit/recipe_controller_test.js は scaffold で生成されたものです。

steal
    .plugins('funcunit', 'jquery/model', 'jquery/controller')
    .then('controllers/recipe_controller')
    .then('test/funcunit/recipe_controller_test')
    ;

ブラウザで funcunit.html を開いてテストを実行します。ポップアップブロックは解除しておきましょう。

コマンドラインからの実行

コマンドラインからも確認しましょう。

$ ./funcunit/envjs cookbook/funcunit.html
Using Default Settings
Selenium is not running. Please use steal/js -selenium to start it.

FuncUnit をコマンドラインから実行すると、裏側で Selenium を動かす必要があります。

$ pushd funcunit/java
$ ln -s selenium-server-standalone-2.0b3.jar selenium-server.jar
$ popd
$ ./js -selenium
$ ./funcunit/envjs cookbook/funcunit.html

たぶんこれで動くはずなんですが、手元の環境では Firefox が何も進みませんでした。読み込むプラグインが足りないんだと思いますが、深追いしないことにします。

終わりに

JavaScriptMVC を使ってテストケースを動かしました。２種類のテストがありますので、着目する部分に応じてテストを使い分けられると良さそうです。ブラウザテストは同じ操作を再現することが煩雑だったりクロスブラウザでの確認を忘れがちですが、 Envjs を利用してコマンドラインからも実行できると、CI ツールに組み込んで使えます。

先にテストを書いておくと、とりあえず今日はここまで、という区切りを考えやすくなるかもしれません。また、サーバーサイドの API が未実装でも、わざわざモックを用意することなく、 JSON でなんとなくデータをエミュレートできます。最近は HTML5 を中心としたクライアントサイドのストレージも使えるようになりましたので、 HTTP をエミュレートしない場合には選択肢のひとつとして考慮すべきだと思います。

次は、モデルやコントローラーの API を HTML ドキュメントとして出力します。

JavaScriptMVC を使ってみる

2011-08-26T20:23:00.005+09:00

JavaScriptMVC を使ってプロジェクトを作成します。この記事の続きです。

JavaScriptMVC - 概要 (2011年8月25日)

ツールの準備

github から ZIP パッケージをダウンロードして適当なディレクトリに展開します。この記事を書いている時点での最新版は javascriptmvc-3.1.0.zip です。

中身を見ておくと次のようになります。

$ ls
MIT-LICENSE.txt  documentjs/      jquery/          js.bat*
changelog.txt    funcunit/        js*              steal/

$ ls steal/ jquery/ funcunit/ documentjs/
documentjs/:
README         distance.js    doc.bat        jmvcdoc/       scripts/       showdown.js    test/          update
build.js       doc*           documentjs.js  json.js        searchdata.js  tags/          types/

funcunit/:
README              drivers/            generate_docs.html  qunit/              summary.ejs
autosuggest/        envjs*              index.html          qunit.html          syn/
build.js            envjs.bat*          java/               resources/          template.html
dependencies.json   funcunit.html       loader.js           scripts/            test/
docs.html           funcunit.js         pages/              settings.js         update

jquery/:
README       buildAll.js  controller/  download/    generate/    lang/        qunit.html   tie/         view/
build.js     class/       dom/         event/       jquery.js    model/       test/        update

steal/:
README               coffee/              getjs                parse/               steal.production.js
build/               dev/                 js*                  patchfile            test/
buildjs              end.js               js.bat               pluginifyjs          update
clean/               generate/            less/                rhino/
cleanjs              get/                 make.js              steal.js

単純な JavaScript だけでなく、 QUnit, CoffeeScript, LESS なども同梱されていることが分かります。また、 steal の中には Rhino もありますね。ちょっと JavaScript を動かしてみるには良い環境だと思います。

アプリケーションの作成

js コマンドが Rhino へのラッパーになっており、 steal を使ってアプリケーションを管理します。

"cookbook" アプリケーションを作成してみます。

$ ./js steal/generate/app cookbook
      cookbook/cookbook.css
      cookbook/cookbook.html
      cookbook/cookbook.js
      cookbook/docs
      cookbook/resources
      cookbook/resources/example.coffee
      cookbook/resources/example.js
      cookbook/resources/example.less
      cookbook/scripts
      cookbook/scripts/build.html
      cookbook/scripts/build.js
      cookbook/scripts/clean.js
      cookbook/test

cookbook/cookbook.html を開いてエラーが出ないことを確認します。 StealJS がパス解決に失敗している部分があると後で大変なので、 FireBug や開発者コンソールなどで確認しておきましょう。

ファイルシステム上のファイルを直接開くと Cross origin リクエストのエラーになるブラウザもあります。 HTTP サーバを起動しておくと便利です。 js コマンドを実行したディレクトリで python -m SimpleHTTPServer を実行すると、 8000番ポートからアクセスできます。 Mac OS X の場合は Web 共有で Apache が起動しますので、 ~/Sites 以下に配置すれば HTTP 経由でアクセスできます。

次に、データモデルを定義します。 scaffold を使うことで、MVC で言うモデルとコントローラーを生成してくれます。

$ mkdir cookbook/models
$ ./js jquery/generate/scaffold Cookbook.Models.Recipe
      cookbook/controllers
      cookbook/controllers/recipe_controller.js
      cookbook/fixtures
      cookbook/fixtures/recipes.json.get
      cookbook/models
      cookbook/models/recipe.js
      cookbook/test
      cookbook/test/funcunit
      cookbook/test/funcunit/recipe_controller_test.js
      cookbook/test/qunit
      cookbook/test/qunit/recipe_test.js
      cookbook/views
      cookbook/views/recipe
      cookbook/views/recipe/edit.ejs
      cookbook/views/recipe/init.ejs
      cookbook/views/recipe/list.ejs
      cookbook/views/recipe/show.ejs

ここでサクッとモデルとコントローラーを使えると良いのですが、 JavaScriptMVC 2 系まであった .models() と .controllers() インターフェイスは廃止されました。

そこで、 cookbook.js を以下のように編集します。コードジェネレーターで生成されたファイルは LESS と CoffeeScript を読み込むようになっていますが、この部分は一旦コメントアウトか削除しておきます。

steal
    .plugins('jquery/model', 'jquery/view/ejs')
    .then('models/recipe')
    .then(function() {
        $('#content').append($.View('//cookbook/views/recipe/init.ejs', {recipes: []}));
    })
    ;

まず、モデルとビューのプラグインを読み込みます。ビューには EJS (EmbeddedJS), Micro, jQuery.Tmpl, JAML がありますが、コードジェネレーターのデフォルトが EJS なので、これをそのまま使います。

次に、 cookbook/models/recipe.js で定義されるモデルクラス (Cookbook.Models.Recipe) を読み込みます。 .then() で指定する場合には .js の拡張子を省略します。モデルクラスをここで読み込むのは、後から読み込むテンプレートファイルで参照しているためです。

最後の .then() にはコールバック関数を指定します。最初に生成した cookbook.html には ID が "content" の <div> タグがありますので、そこに HTML 要素を追加します。 $.View の最初の引数にテンプレートファイルへのパスを指定し、二つ目の引数でパラメータを渡します。パス表記はスラッシュふたつで始めています。 Web サーバ上での配置を考えるのが面倒な場合にはこのように書いておきます。

HTML ファイル (cookbook.html) をブラウザで開いてみると、レシピの一覧と新しいレシピを登録するフォームのひな形が表示されています。

これでアプリケーションを実装する準備ができました。

データの表示

一覧表示

サンプルデータを表示させます。 cookbook/fixtures/recipes.json.get の中身を cookbook.js にコピーし、テンプレートに渡します。先ほどのコールバック関数を次のように変更します。

.then(function() {
    var recipes = [
        {"name": "Take Out Trash", "description": "To the curb!", "id": 5}
    ];
    $('#content').append($.View('//cookbook/views/recipe/init.ejs', {recipes: recipes}));
})

続いてテンプレートを修正します。 init.ejs は list.ejs を呼び出し、その中で要素をループさせて show.ejs を呼び出します。自動生成された show.ejs ではエラーが発生しますので、以下のように書き換えます。

<%for(var attribute in this){%>
    <%if(attribute == 'id') continue;%>
    <td class='<%= attribute%>' style="border:solid 1px gray; padding: 5px;">
        <%=this[attribute]%>
    </td>
<%}%>
<td>
    <a href='javascript://' class='edit'>edit</a>
    <a href='javascript://' class='destroy'>destroy</a>
</td>

cookbook.html をリロードすると次のようになります。サンプルデータ (recipes 変数) を増やすと、一覧表示のデータに反映されます。

フォーム作成

モデルに属性を追加します。 Cookbook.Models.Recipe にはスタティックメソッドとプロトタイプメソッドが定義されています。 /* @Static */ のどこかに attributes を追加します。辞書のキーはデータのキーと合わます。バリューは適当に当てています。

attributes: {
    'id': 'integer',
    'name': 'string',
    'description': 'text'
}

ブラウザで確認してみると、"New recipe" の部分にふたつのテキストボックスが追加され、 "recipes" の一覧表にタイトルが追加されていますね。

スタイルシートの分離

先ほどはテンプレートファイルの中に style 属性を記述しました。これを外部ファイル化します。方法はふたつあり、通常の CSS で管理する方法と、LESS を使う方法です。

CSS を読み込む

CSS は steal の .css() メソッドで読み込めます。 cookbook.js の steal のメソッドチェーンに次の１行を追加します。

.css('cookbook')

<td> 要素に埋め込んだ style 属性を cookbook.css に移動してから cookbook.html を再度読み込みます。デフォルトのデザインもかかってきますので、フォントなどが変わります。

LESS を使う

LESS を使うためには、プラグインを読み込んでから .less ファイルを指定します。先ほどの .css() を次の４行で置き換えます。もちろん、CSS も LESS も両方使う場合には、置き換えではなく付け足しになります。

.plugins('steal/less')
.then(function() {
    steal.less('resources/example');
})

cookbook/resources/example.less に <td> の枠線を定義すると反映されます。

LESS を使うと変数を再利用できますので、素朴に CSS を記述していくよりは効率的にスタイルを管理できそうです。

終わりに

JavaScriptMVC を使ってアプリケーションのひな形と、簡単なデータを表示しました。表示方法は複数のテンプレートシステムから選択でき、デザインには CSS だけでなく LESS も使えます。

新しいテンプレートや LESS、それから CoffeeScript は、記法に慣れてしまえばサクサクと実装できるでしょうが、不慣れな場合には覚えることが多くなってしまうことも事実です。とはいえ、愚直に JavaScript や CSS を書いてブラウザごとの違いに泣かされるよりは、最近流行り始めているかもしれない手法を取り入れた方が手っ取り早いと思います。

次は、QUnit と funcunit を使ってテストを動かしてみます。

JavaScriptMVC - 概要

2011-08-25T22:47:00.004+09:00

JavaScriptMVC は Jupiter が開発/提供している JavaScript フレームワークです。 jQuery を中心に据えて、クライアントサイドの開発を助けてくれます。 JavaScriptMVC のメリットはこの辺でも触れています。

JavaScriptMVC と一覧表示の性能 - 2011年1月13日の記事

使い方をまとめて記事にしようとしたら大変だったので、５回に分けて書く予定にします。

Update: 一連の記事を書き終えたのでリンクにした。

github に書きかけの gist がありましたので、最初の方を少しだけ訳出します。

JavaScriptMVC Overview

github のレポジトリから javascriptmvc-3.1.0.zip をダウンロードしておくと、フォルダの中身を確認しながら動かせるようになるかもしれません。 (この記事では何も動かさないけど)

JavaScriptMVC の概要

イントロダクション

JavaScriptMVC は jQuery をベースとしたオープンソースの JavaScript フレームワークです。フロントエンドの開発フレームワークとしては (総体的に) 網羅されており、以下の有用性のあるものでパッケージングされています。

テスト
依存性管理
エラーレポーティング
パッケージ管理
コードクリーニング
独自イベント
jQuery 拡張
ドキュメンテーション

ライブラリは、ほぼ独立した４つのサブプロジェクトに分割され、 UI ウィジェットを除いたほとんどすべてがあります。 JMVC の MVC 部分は、GZIP 化されるとたったの 7kB しかありません。

プラグインとしての実装

JavaScriptMVC は独立した４つのサブプロジェクトに分割されます。

StealJS - 依存性管理、コードジェネレーター、プロダクションビルド、コードクリーニング
FuncUnit - Web テストフレームワーク
DocumentJS - JS ドキュメンテーションフレームワーク
jQueryMX - jQuery の MVC 拡張

ダウンロードパッケージは、以下のフォルダから構成されます。

funcunit
documentjs
jquery
steal

それぞれのフォルダ内には、たくさんのサブプラグインがあります。たとえば、 JavaScriptMVC のコントローラーは jquery/controller/controller.js にあります。

JavaScriptMVC を使うときは似たようなフォルダ構造にすると良いでしょう。この文章の最後で作成する (訳注:元の記事が終わってないので未完) ToDo アプリケーションは以下のように構成しました。

funcunit
documentjs
jquery
steal
todo/
  todo.js
  todo.html

終わりに

JavaScriptMVC の概要を日本語に訳しました。 JavaScriptMVC 3 系からは、かなり大きく API が変更されたようで、いくつかの (多くの？) ドキュメントが陳腐化しています。 API を見ていくときには注意が必要です。特に、非同期に処理する方法を導入したことによって、いくつかの API は互換ではありませんし、モデルとコントローラーを使うメソッドも変更されています。

New Steal API checked into master branch

次は、Steal を使ってアプリケーションを作成してみます。

Waf を使って構文チェックしてからコピーする

2011-08-23T00:54:00.001+09:00

インタープリタ型のプログラミング言語では、ソースコードを記述したファイルをそのまま実行できます。小さめのファイルなら簡単に動作を確認できて非常に便利です。しかし、モジュールを区切って管理するようになると複数のファイルに依存関係が発生し、こまめにテストしながら開発する必要があります。

ひとくちにテストと言っても様々なレベルが考えられますが、ここでは、構文だけをテストします。原理は同じですから、同様にして単体テストやドキュメントテストも実行できるようになります。設定方法を工夫すれば結合テストもできるようになるはずですね。

Python で pep8

Python には PEP 8 - Style Guide for Python Code - という約束があり、これに沿っているかを確認するために pep8 というツールがあります。インデントは空白4文字になっているか、1行が80文字以上になっていないか、クラス定義の前に2行の空行があるか、エンコーディングは何かといったことを確認してくれます。

PyPI にモジュールがアップされていますので、簡単にインストールできます。

$ pip install pep8

Python スクリプトを引数に渡してあげると次のようになります。

$ cat <<EOF >pep8-test.py
if True is False:
  print "Bad world."

class True(object):
  pass

False = True
print type(False), True is False
EOF

$ python pep8-test.py
<type 'type'> True

$ pep8 pep8-test.py
pep8-test.py:2:3: E111 indentation is not a multiple of four
pep8-test.py:4:1: E302 expected 2 blank lines, found 1

インデントが４で揃っていないこと、空行が２行あるべき部分に１行しか見つからないことが報告されます。

コマンドライン引数を渡すことで、 doctest を実行したり、無視するエラーレベルを調整できます。 --show-source や --show-pep8 オプションを使うと詳細な説明も表示されますので、コードスタイルに慣れておらずソースコードが小さいうちは、これらを付けた方が良いかもしれません。 (記述量が多くなってくるとエラーが埋もれてしまうのと、エラー内容を見ればだいたい分かるので、しばらく使うといらなくなる感じ。)

Waf で pep8

wscript を用意して Waf で実行できるようにします。先ほどの pep8-test.py をそのまま使い、構文エラーがなくなったら _build ディレクトリにコピーできるようにします。

ツールとパスの確認

まずは wscript の大枠を整えます。

APPNAME = 'pep8-test'
VERSION = '1.0.0'

top = '.'
out = '_build'


def configure(ctx):
    ctx.find_program('pep8')


def build(bld):
    f = bld.path.find_resource('pep8-test.py')
    print "f                     : %s" % f
    print "f.abspath()           : %s" % f.abspath()
    print "f.get_src().abspath() : %s" % f.get_src().abspath()
    print "f.get_bld().abspath() : %s" % f.get_bld().abspath()

configure で pep8 コマンドが存在しているかを確認します。コマンドが見つからない場合は次のようなエラーになります。

$ waf configure
Setting top to                           : /private/tmp/pep8-test
Setting out to                           : /private/tmp/pep8-test/_build
Checking for program pep8                : not found
Could not find the program pep8
(complete log in /private/tmp/pep8-test/_build/config.log)

探索しているパスの一覧はログファイル (_build/config.log) に記載されています。環境変数が思い通りに設定できていない場合はこのファイルを確認します。

pep8 をインストールすると次のようにチェックされます。

$ waf configure
Setting top to                           : /private/tmp/pep8-test
Setting out to                           : /private/tmp/pep8-test/_build
Checking for program pep8                : /private/tmp/pep8-test/bin/pep8
'configure' finished successfully (0.004s)

次に build ターゲットを実行します。ターゲットとするファイルを find_resource で取得し、いくつかのパス表記を確認しています。

$ waf build
Waf: Entering directory `/private/tmp/pep8-test/_build'
f                     : pep8-test.py
f.abspath()           : /private/tmp/pep8-test/pep8-test.py
f.get_src().abspath() : /private/tmp/pep8-test/pep8-test.py
f.get_bld().abspath() : /private/tmp/pep8-test/_build/pep8-test.py
Waf: Leaving directory `/private/tmp/pep8-test/_build'
'build' finished successfully (0.002s)

get_src() と get_bld() でノードが異なることが分かりますね。

pep8 と cp

pep8 で構文をチェックして cp でビルドディレクトリにコピーするには、 build ターゲットを次のように書き換えます。

def build(bld):
    f = bld.path.find_resource('pep8-test.py')
    bld(rule='pep8 ${SRC}', source=f)
    bld(rule='cp ${SRC} ${TGT}', source=f.get_src(), target=f.get_bld())

cp コマンドを実行するタスクの target 引数を間違えると依存関係がループしてしまいます。 get_bld() を使うことで、明示的にビルドディレクトリのパスを指定します。 source 引数は f でも良いのですが、対称性のために get_src() を明示的に呼び出しています。

実行してからビルドディレクトリの中身を表示させます。

$ waf distclean configure build
'distclean' finished successfully (0.002s)
Setting top to                           : /private/tmp/pep8-test
Setting out to                           : /private/tmp/pep8-test/_build
Checking for program pep8                : /private/tmp/pep8-test/bin/pep8
'configure' finished successfully (0.004s)
Waf: Entering directory `/private/tmp/pep8-test/_build'
[1/2] pep8 ${SRC}: pep8-test.py
[2/2] pep8-test.py: pep8-test.py -> _build/pep8-test.py
../pep8-test.py:2:3: E111 indentation is not a multiple of four
../pep8-test.py:4:1: E302 expected 2 blank lines, found 1
Waf: Leaving directory `/private/tmp/pep8-test/_build'
Build failed
 -> task failed (exit status 1):
        {task 4556299536: pep8 ${SRC} pep8-test.py -> }
' pep8 ../pep8-test.py '

$ ls _build
c4che/        config.log    pep8-test.py

どちらのタスクも実行されており、ビルドディレクトリに pep8-test.py がコピーされました。しかし、 pep8 では構文エラーが報告されているのにコピーされてしまうのも困りものです。それぞれのタスクが独立していると並列化させやすいですが、ここではそうではなく、グループ化されていて欲しいところです。

タスクの順番を制御

Wafbook の 7.2. Build order constraints で３つの方法が説明されています。タスクの set_run_after() メソッドを呼び出す方法、タスク定義に before もしくは after 属性を持たせる方法、そして、タスクの順番を自前で管理する方法です。最後の方法はジョブショップ・スケジューリング問題 (JSP) とも言われる問題領域ですから、クリティカルパスがよほど単純な場合を除いては使わない方が良いと思います。

さて、タスク定義は waflib.Task.Task クラスを継承すれば良いので、一番最初の方法 - set_run_after() - が簡単そうです。

スクリプト

cp 用のタスクと pep8 用のタスクを定義します。それぞれのタスクに入出力パスを設定したら、順序関係を設定します。

from waflib.Task import Task

class cp(Task): 
    def run(self): 
        return self.exec_command('cp %s %s' % (
                self.inputs[0].abspath(), self.outputs[0].abspath()
            ))

class pep8(Task):
    def run(self):
        return self.exec_command('pep8 %s' % (self.inputs[0].abspath(),))

def build(bld):
    f = bld.path.find_resource('pep8-test.py')
    t1 = pep8(env=bld.env)
    t1.set_inputs(f)
    t2 = cp(env=bld.env)
    t2.set_inputs(f.get_src())
    t2.set_outputs(f.get_bld())
    t2.set_run_after(t1)
    bld.add_to_group(t1)
    bld.add_to_group(t2)

実行結果

実行してみると (pep8 でエラーの場合は) ビルドディレクトリに pep8-test.py がコピーされないことが分かります。

$ waf distclean configure build
'distclean' finished successfully (0.002s)
Setting top to                           : /private/tmp/pep8-test
Setting out to                           : /private/tmp/pep8-test/_build
Checking for program pep8                : /private/tmp/pep8-test/bin/pep8
'configure' finished successfully (0.004s)
Waf: Entering directory `/private/tmp/pep8-test/_build'
[1/2] pep8: pep8-test.py
/private/tmp/pep8-test/pep8-test.py:2:3: E111 indentation is not a multiple of four
/private/tmp/pep8-test/pep8-test.py:4:1: E302 expected 2 blank lines, found 1
Waf: Leaving directory `/private/tmp/pep8-test/_build'
Build failed
 -> task failed (exit status 1):
        {task 4367677712: pep8 pep8-test.py -> }
''

$ ls _build
c4che/      config.log

ソースコードを修正してから改めて実行してみると次のようになります。

$ waf distclean configure build
'distclean' finished successfully (0.002s)
Setting top to                           : /private/tmp/pep8-test
Setting out to                           : /private/tmp/pep8-test/_build
Checking for program pep8                : /private/tmp/pep8-test/bin/pep8
'configure' finished successfully (0.005s)
Waf: Entering directory `/private/tmp/pep8-test/_build'
[1/2] pep8: pep8-test.py
[2/2] cp: pep8-test.py -> _build/pep8-test.py
Waf: Leaving directory `/private/tmp/pep8-test/_build'
'build' finished successfully (0.169s)

$ ls _build
c4che/        config.log    pep8-test.py

先ほどの失敗した場合と比べて、２つのタスクの内２つとも実行されていることが分かります。

終わりに

Waf を使って pep8 で Python の構文をチェックしてからコピーする処理を記述しました。同様にして nosetests などもフックに入れておくと、ソースコードを編集する度にテストを実行できます。なお、まだ確認していませんが、テストはテスト用の枠組みでも実行できるはずです。

Waf 自体は Python で記述されていますが、そのターゲットの言語は選びません。同じ方法は PHP にも適用可能で、 pep8 の代わりに php -l を使うことになるでしょう。フロントエンドのリソース - JavaScript, CSS - に対しては YUI Compressor や Closure Tools でミニフィケーションできますね。

また、ここでは find_resource() を使ってノードを探し出しましたが、 ant_glob() を使うと Ant の探索パターンを活用できます。プロジェクトのソースコードが増えてきた場合にはこちらを使ってループ処理を回した方が自然だと思います。

Makefile でも良いんだけど違う方法も覚えておきたい、という場合には Waf も良さそうです。

蛇足ながら、ここではテキスト表記ですが、実際にコンソールで動かすと色が付きます。意外とこれで導入障壁が下がったりするかもしれませんね。

Waf から Solr を起動させる

2011-08-16T22:51:00.004+09:00

Waf を使うと、Python で色々な処理を記述できます。 Waf は普通は C 言語などのコンパイルに使いますが、ある条件に従って何らかの処理を実行できると便利ですので、他のことにも流用してみます。以前に、Solr をダウンロードして解凍できることを確認しましたので、今回は、そこから Solr を起動させます。

Waf を使う (2011年8月の記事)
The Waf Book (Google Code)

実行環境の準備

まずは virtualenv で実行環境を作成し、 waf コマンドを実行できるようにします。

$ virtualenv --distribute solr-test
$ cd solr-test
$ source bin/activate
$ curl http://waf.googlecode.com/files/waf-1.6.7 >bin/waf
$ chmod +x bin/waf
$ waf
Waf: Run from a directory containing a file named 'wscript'

wscript が見つかりません、というエラーが表示されれば正常に設定できています。

Solr を起動させる

Solr をダウンロードして解凍する処理は、以前の内容と似たような感じです。 Python の urllib と tarfile モジュールを使います。

Solr の配布アーカイブには start.jar というブートストラップが含まれています。これは example ディレクトリにありますので、そこへ移動し、JAR を実行します。 (その他の基本的な内容物に関してはこちらの記事で触れています - DotCloud で Solr を使ってみる)

$ cd {apache-solr-dir}/example/
$ java -jar start.jar

毎回これを実行しても構わないのですが、Solr の設定を変更したい場合にはちょっと不便です。デフォルトでは実行したディレクトリ直下の solr ディレクトリを見に行きますが、たとえば、 /tmp/solr から設定ファイルを読み込みたい場合には次のように引数を与えます。

$ java -Dsolr.solr.home=/tmp/solr -jar start.jar

"solr.home" ではなく、"solr.solr.home" なので、分かっていても間違えてしまいます。ということで、スクリプトにまとめておきたいわけです。

スクリプト

wscript にまとめると、次のようになります。

APPNAME = 'solr-test'
VERSION = '1.0.0'

top = '.'
out = '_build'

import urllib
import tarfile

from waflib.Task import Task

SOLR_VERSION = '3.3.0'
SOLR_PACKAGE = 'apache-solr-%s.tgz' % (SOLR_VERSION,)
SOLR_MIRROR = 'http://ftp.riken.jp/net/apache/lucene/solr/%s/%s' % (SOLR_VERSION, SOLR_PACKAGE)


def configure(ctx):
    p = ctx.path.find_resource(SOLR_PACKAGE)
    if p is None:
        urllib.urlretrieve(SOLR_MIRROR, SOLR_PACKAGE)
    jar = ctx.path.ant_glob('apache-solr-*/example/start.jar')
    if not jar:
        with tarfile.open(SOLR_PACKAGE) as tar:
            tar.extractall()


def run_solr(ctx):
    jar_dir = ctx.path.find_dir('apache-solr-%s/example' % (SOLR_VERSION,))
    solr_dir = ctx.path.find_node('solr')
    ctx.exec_command(['java', '-Dsolf.solr.home=%s' % (solr_dir.abspath(),),
                      '-jar', 'start.jar'], cwd=jar_dir.abspath())

wscript においてファイルやディレクトリは「ノード」という単位で扱われます。ノードの取得方法には数種類あり、上記のスクリプトでは次の４つを使っています。 (使い分けている、というよりは、複数種類を例示している。)

find_resource : ビルドしたノードかソースファイルを探します。
find_dir : ファイルシステムからフォルダを探します。
find_node : ファイルシステムからファイルやフォルダを探します。
ant_glob : Ant のファイルマッチパターンに従ってファイルを探します。

「ファイルシステムから」という記述に意味があり、ビルドの依存関係を記述するためには、ファイルシステムには存在しないノードを定義することになります。とはいえ、ここでのスクリプトには関係ありませんので、無視しておきます。

その他のノードの扱いは、ソースコードを読むのが最も手っ取り早いかもしれません...

Source code for waflib.Node

実行方法

上記 wscript の configure ターゲットを実行して、アーカイブをダウンロードしてから展開します。

$ waf configure

次に、設定ファイルを編集できるように、トップレベルにコピーします。

$ cp -r apache-solr-3.3.0/example/solr .

最後に、 run_solr ターゲットを実行します。

$ waf run_solr

ブラウザで http://localhost:8983/solr/admin にアクセスすると、 Solr の管理画面が表示されるはずです。

あとは、 solr/conf にあるファイルを編集することで、Solr の中身をカスタマイズできます。

終わりに

Waf から Solr を起動させてみました。定型の処理ならシェルスクリプトにまとめてしまえば良いのですが、 Windows でも処理を自動化できると便利なこともあります。

Waf だと単一のファイルを配置すれば良いだけですので、簡単に手順を共有できそうですね。

Indexed Database API を使ってみる

2011-08-14T22:25:00.003+09:00

たまには Web 系技術もキャッチアップした方が良いかな、と思っていたら、 Indexed Database API のサンプルがありましたので模写しました。

IndexDB demo - original gist
IndexedDB demo - 模写版
ソースコード - github.com

HTML5 でクライアント側にデータを保存するための仕様ですが、この部分はバタバタしている印象があり、ブラウザベンダーによる実装差異も多そうですので、きちんと動くサンプルを書くのは難しいと思います。上記の模写版は Firefox 5 では動くはずですが、Webkit 系では動いたり動かなかったり。 (どこかで実装を間違えているっぽい...)

なお、API の正式名称は "Indexed Database API" ですが、省略形は "IndexDB" と "IndexedDB" が混在しているのかな、といった状況です。関係する仕様としては "Web Storage" と "Web SQL Database" がありますが、前者は Key / Value を保存するもの、後者は SQL を使う仕様を策定してみたもののボツになったものです。 "Indexed Database API" と "Web Storage" はどちらも NoSQL ですが、データを一覧表示するかしないかの違いとも考えられます。 IndexedDB を使って Key / Value も実現できますが、本当に Key に対する Value が欲しいだけなら localStorage (Web Storage の一部) を使う方が簡単です。どれも名前と使いどころくらいは知っておいた方が良さそうです。

"Indexed Database API" は基本的に非同期処理でコールバックを多用する必要がありますので、抽象化ライブラリを作ってメソッドチェーンでつなげるようにするべきなんだろうな、と思います。 jQuery における jqXHR のようなオブジェクトが出てくるかもしれませんね。 (同期処理でデータを操作するのは、ユーザーへの応答性という点でイマイチなはず)

API の細かい使い方は Mozilla の記事 (英語、下記リンク) に書かれています。カーソルの受け渡しに慣れてくればサクサク記述できると思いますが、コールバックのつなげ方は実装の試行錯誤が必要になりそうです。あと、開発者コンソールかなんかでデータを確認できるようになると嬉しいですね。

リンク

Indexed Database API - w3.org
Web Storage (sessionStorage, localStorage) - w3.org
Web SQL Database (no longer inactive) - w3.org
Using IndexedDB - MDN
Indexed Database API W3C Draft Implementation - indexeddb
Indexed Database API について - へっぽこプログラマーの日記
indexedDB を触ってみた - こてさきAjax
Googleは、Key-ValueデータストアであるLevelDBをオープンソース化した - InfoQ

docutils でブログ記事作成

2011-08-12T23:02:00.006+09:00

ブログの記事は reST (reStructuredText) で書いて HTML に変換していますが、パソコンを買い替えたので環境を移行しなければなりません。ということで、メモを書いておきます。

docutils のインストール

まずは Docutils モジュールをインストールします。 Sphinx をインストールすれば依存関係でインストールされていますが、そうでない場合は個別にインストールします。

$ site=blog-site
$ virtualenv --distribute $site
$ cd $site
$ . bin/activate
$ pip install docutils

docutils には rst から始まる Python スクリプトがいくつか付属しています。

$ ls bin/rst*.py
bin/rst2html.py
bin/rst2latex.py
bin/rst2man.py
bin/rst2odt.py
bin/rst2odt_prepstyles.py
bin/rst2pseudoxml.py
bin/rst2s5.py
bin/rst2xetex.py
bin/rst2xml.py
bin/rstpep2html.py

rst2html.py を使うと、 reST で記述されたファイルを HTML に変換できます。たとえば、 article.rst というファイルを HTML に変換する場合には次のように実行します。

$ rst2html.py article.rst >article.html

ブログ記事に使う

プレビュー用と投稿用の HTML を生成できるようにします。ブログ投稿用のアプリケーションを使えばそんなものは必要ないかもしれませんが、 HTML をベタ書きできた方が何かと都合が良いこともありそうなので、この方法にしています。

プレビュー用の HTML は先ほどのコマンドで生成できます。しかし、投稿用には HTML の <head> タグなどは不要ですので、これを取り除くことにします。

２種類のアプローチが考えられますが、ここでは後者を採用します。

生成された HTML をパースして、 <body> の中を抽出する。
そもそも HTML の <body> だけを生成させる。

rst2html.py のオプション

rst2html.py に --help オプションをつけて実行すると、たくさんのオプションが利用できることが分かります。なんとなくメモしておくものだけを抜粋して日本語にしておきます。

`--strip-comments`
	コメント要素を除去します。
`--leave-comments`
	コメント要素を残しておきます。 (default)
`--input-encoding=<name[:handler]>, -i <name[:handler]>`
	入力テキストのエンコーディングと、オプションでエラーハンドラーを設定します。 Default: <locale-dependent>:strict.
`--input-encoding-error-handler=INPUT_ENCODING_ERROR_HANDLER`
	デコードできない文字に対するエラーハンドラーを設定します。 Choices: "strict" (default), "ignore", and "replace".
`--output-encoding=<name[:handler]>, -o <name[:handler]>`
	出力テキストのエンコーディングと、オプションでエラーハンドラーを設定します。 Default: UTF-8:strict.
`--output-encoding-error-handler=OUTPUT_ENCODING_ERROR_HANDLER`
	デコードできない文字に対するエラーハンドラーを設定します。 "strict" (default), "ignore", "replace", "xmlcharrefreplace", "backslashreplace".
`--language=<name>, -l <name>`
	言語を設定します。 (BCP 47 言語表記). Default: en.
`--no-file-insertion`
	外部ファイルのコンテンツを挿入するディレクティブを無効にします。ディレクティブは "include" と "raw" です。
`--file-insertion-enabled`
	外部ファイルのコンテンツを挿入するディレクティブを有効にします。ディレクティブは "include" と "raw" です。 Enabled by default.
`--no-raw`
	"raw" ディレクティブを無効にします。
`--raw-enabled`
	"raw" ディレクティブを有効にします。 Enabled by default.
`--template=<file>`
	テンプレートファイルを指定します。テンプレートファイルは UTF-8 でエンコードされていなければなりません。 Default is "lib/python2.7/site-packages/docutils/writers/html4css1/template.txt".
`--stylesheet=<URL>`
	スタイルシートの URL をカンマ区切りで指定します。 --stylesheet と --stylesheet-path の設定を上書きます。
`--stylesheet-path=<file>`
	スタイルシートのパスをカンマ区切りで指定します。 --link-stylesheet があると、出力する HTML の相対パスとしてパスは上書きされます。 Default: "lib/python2.7/site-packages/docutils/writers/html4css1/html4css1.css"
`--embed-stylesheet`
	出力する HTML にスタイルシートを埋め込みます。スタイルシートファイルは、処理中にアクセスできなければなりません。 This is the default.
`--link-stylesheet`
	出力する HTML にスタイルシートをリンクさせます。 Default: embed stylesheets.

この中に、 --template オプションがあります。ヘルプメッセージに表示されるデフォルトのテンプレートは次のようになっています。

%(head_prefix)s
%(head)s
%(stylesheet)s
%(body_prefix)s
%(body_pre_docinfo)s
%(docinfo)s
%(body)s
%(body_suffix)s

見た目のままですが、 $(body)s だけにすると、文章部分だけを出力できます。つまり、次のように実行できます。

$ rst2html.py --template=blog-template.txt article.rst >article-body.html

これでも目的は達成できますが、出力ファイル名をいちいち入力するのは面倒ですから、 Python スクリプトにまとめることにします。

Python スクリプトで使う

rst2html.py は単なるラッパースクリプトで、内部的には docutils.core.publish_cmdline() を呼び出しています。つまり、 subprocess.call() で rst2html.py を呼び出すこともできますし、 docutils.core.publish_cmdline() を使うこともできます。

docutils のモジュールを使う場合は、次のようなスクリプトにまとめられます。

スクリプト

__doc__ = """
python %prog {manuscript}

Parse a reST manuscript and write out it in two way HTML formats.
A file whose suffix is ".html" is for preview, and a file whose suffix
is ".txt" is for blogger's article.
"""

import optparse
import os
import tempfile

from docutils.core import publish_cmdline

# see: lib/python2.7/site-packages/docutils/writers/html4css1/template.txt
RST_TEMPLATE_SOURCE = '''
%(body)s
'''

def parse_args():
    parser = optparse.OptionParser(__doc__)

    opts, args = parser.parse_args()

    if not args:
        parser.error("no arguments found.")

    return args


def publish_restructured_text(manuscript):
    fname = tempfile.mktemp()
    with open(fname, 'w') as temp:
        temp.write(RST_TEMPLATE_SOURCE)
    basic_option = ['--strip-comments']
    basename, _ = os.path.splitext(os.path.basename(manuscript))
    source = '%s.txt' % (basename,)
    preview = '%s.html' % (basename,)
    argv = ['--template=%s' % (fname,), manuscript, source]
    publish_cmdline(writer_name='html', argv=basic_option+argv)
    argv = [manuscript, preview]
    publish_cmdline(writer_name='html', argv=basic_option+argv)
    os.unlink(fname)
    print "Write as single HTML page and only body element."
    print "  single page : %s (%dbytes)" % (preview, os.path.getsize(preview))
    print "  only body   : %s (%dbytes)" % (source, os.path.getsize(source))


def main():
    manuscripts = parse_args()

    for manuscript in manuscripts:
        if os.path.exists(manuscript):
            publish_restructured_text(manuscript)
        else:
            print "%s is not found." % (manuscript,)

終わりに

Mac を買い替えたので環境を移行する必要がありました。整理がてら記事にしましたが、必ずしも docutils で頑張る必要もなく、 Sphinx でラップした方が良いかもしれません。ともあれ、まずは愚直に移行することにしました。

その他、テキストファイルで原稿を書いてブログで公開するソフトウェアはいくつかあります。

Web サービスを使えない状況や、単一のドキュメントを整形する場合には、このような方法も便利かもしれませんね。

Waf を使う

2011-08-09T23:03:00.004+09:00

Waf を使ってみます。ここでの Waf とは、Web Application Framework や Web Application Firewall の略ではなく、 Python で記述されたビルドシステムのことです。

Waf - Google Code
The Waf Book - Google Code

ツールの導入部分に関してはこちらの記事で紹介されています。

waf チュートリアル (純粋関数型雑記帳)

この記事では、何かをビルドする、というわけではなく、アーキテクチャに依存せずに手続きを実行できるようにします。

例として、Solr をダウンロードして解凍する処理を記述します。 Linux では wget と tar を使うだけですが、 Windows だとコマンドラインでダウンロード処理を記述するのが難しく、 Mac OSX Lion には wget は付属していないため curl を使うことになるでしょう。もちろん、Windows に Cygwin をインストールしたり、Mac に wget をインストールすれば同じコマンド群を使えますが、その手間が面倒だと感じられることが Waf を使う動機です。

とはいっても Python をインストールしておく必要があります。そこはなんとか乗り越えてもらいたいですね。

実行環境の準備

Mac OSX Lion での設定例を示します。 Python は元から入っていますので、virtualenv を使えるようにしておきます。

$ curl -O http://python-distribute.org/distribute_setup.py
$ sudo python distribute_setup.py
$ sudo easy_install pip
$ sudo pip install virtualenv

次に、適当なディレクトリを作成し、独立した Python の実行環境を作成します。

$ virtualenv --distribute solr-test
$ cd solr-test
$ source bin/activate
$ curl http://waf.googlecode.com/files/waf-1.6.6 >bin/waf
$ chmod +x bin/waf
$ waf

これでおしまいです。 waf は単体のファイルとして配布されており、最初の実行時に展開されます。 virtualenv を使っておくと、パスの調整も必要ありませんので、便利だと思います。

Windows の場合はちょっとしたバッチファイルを用意しておくと便利かもしれません。 virtualenv で環境を作成しておくと Scripts フォルダもパスに追加されます。 Windows では拡張子が .bat のファイルは拡張子なしで実行できますので、 Scripts/waf.bat として以下のファイルを作成しておきます。

@echo off
python Scripts\waf-1.6.6 %*

Solr をダウンロードして解凍

Solr をダウンロードして解凍する処理を記述してみます。

Waf では waf コマンドを実行すると wscript ファイルを探しにいきます。これはデフォルトのビルドスクリプトで、 make における Makefile に相当します。いくつかのルールに注意する必要はありますが、普通の Python スクリプトも記述できます。

つまり、ファイルのダウンロードには urllib.urlretrieve 、 tar.gz の解凍には tarfile の extractall を使えます。

実際に書いてみると次のようになりました。 wscript として保存し、 waf コマンドを実行すると実行できます。 (Solr 3.1 を使うのは、dotcloud のバージョンに合わせるため - DotCloud で Solr を使ってみる)

APPNAME = 'solr-test'
VERSION = '1.0.0'

top = '.'
out = '_build'

from waflib.Task import Task
import urllib
import os
import tarfile

SOLR_VERSION = '3.1.0'
SOLR_PACKAGE = 'apache-solr-%s.tgz' % (SOLR_VERSION,)
SOLR_MIRROR = 'http://ftp.riken.jp/net/apache/lucene/solr/%s/%s' % (SOLR_VERSION, SOLR_PACKAGE)

class solr(Task):

    def run(self):
        p = self.inputs[0].abspath()
        if not os.path.exists(p):
            urllib.urlretrieve(SOLR_MIRROR, p)
        d, _ = os.path.splitext(p)
        if not os.path.exists(d):
            with tarfile.open(p) as tar:
                tar.extractall()

def configure(ctx):
    print('configure "%s".' % (APPNAME,))

def build(bld):
    solr_task = solr(env=bld.env)
    solr_task.set_inputs(bld.path.find_resource(SOLR_PACKAGE))
    bld.add_to_group(solr_task)

慣れないと不思議な記述も多いですが、次の４つの変数は予約語です。 (自分ルールとして、一番上に書いておく)

APPNAME : ソフトウェアの名前。
VERSION : ソフトウェアのバージョン。
top : 基準とするディレクトリ。普通はカレント。
out : コンパイルしたファイルなどの出力先ディレクトリ。

次の２つの関数は組み込みのものを上書きしています。

configure : コンパイル先ディレクトリの生成など。前処理。
build : デフォルトのビルドターゲット。

wscript の関数は「コンテキスト」を意識して記述しなければなりません。上記のいずれも引数オブジェクトが「コンテキスト」ですが、実際のクラス (型) が異なります。 The Waf Book の 2.1.2 の NOTE には次のように記載されています。

The context parameter is a new object for each command executed. The classes are also different: ConfigureContext for configure, BuildContext for build, OptionContext for option, and Context for any other command.

日本語混じりにすると次のような感じでしょうか。

コンテキストパラメータは、それぞれの実行コマンドごとの新しいオブジェクトです。クラスはコマンドごとに異なります。 configure には ConfigureContext、build には BuildContext、option には OptionContext、それ以外のコマンドに対しては Context になっています。

個人的にはここがちょっとした嵌まりドコロで、ドキュメントの最初の方には hello やら ping, pong などがありましたので、名前はなんでも良いのかな、と思いましたが、そうでもないようです。

関数名は waf コマンドの引数に対応しますが、自由に付けた関数名には BuildContext が渡ってこないために迷いました。とは言え、タスクは自作できますので、慣れれば自由に記述できそうな気がします。

終わりに

Python で記述されたビルドシステム - Waf - を使ってみました。 Python さえ利用可能ならば特別なインストールはいりません。ここでは、環境による影響範囲を限定するため、パスの設定を簡単にするため、この２点により virtualenv を使いました。

wscript では Python のモジュールを自由に利用できます。もちろん Makefile でもたくさんのコマンドを使えますので、表現力はあまり変わらないかもしれません。しかし、Windows 環境でも使えるのは大きなアドバンテージだと思います。

Python でのビルドシステムと言えば Scons もあります。これはこれで良いシステムだと思いますが、 virtualenv との相性がよくありません。設定ベースで考えるなら zc.buildout もあります。ケースバイケースで使い分けるのが良いのではないでしょうか。

この記事では取り上げていませんが、Waf も他のビルドシステムと同様に、依存関係を定義すること、ルールを階層化して適用することができます。ダラダラと記述して大変になってしまう可能性もありますが、 Windows でも処理の自動化を視野に入れると、知っていると便利だと思います。

蛇足ですが、モダンな Python ハッカーには Fabric が良いそうです。 Python のバージョンもモダンに限定できる場合には便利そうですね。

Tools of the Modern Python Hacker: Virtualenv, Fabric and Pip

九州旅行 in 2011

2011-08-01T00:12:00.002+09:00

サッカーを観戦して新幹線に乗りに九州まで行ってきました。

7月30日 (土)

飛行機で羽田空港から福岡空港へ
車で友達に拾ってもらって、レベルファイブスタジアムを見学してから小倉港へ
名物「焼きカレー」を食べてから巌流島へ
小倉駅付近でホテルを探してチェックイン
本城競技場へ行って J2 観戦
ホテル付近で晩ご飯

北九州市の高速道路が非常にややこしく、運転が大変そうでした。高速道路のインターチェンジで右から合流するパターンはやめて欲しいなぁ、と思います。都内の首都高でも怖いパターンです。

巌流島は宮本武蔵と佐々木小次郎の決闘の舞台として有名ですが、現在の島の面積は当時の6倍にもなるそうです。今はきれいな公園風になっており、関門橋を見るには絶好のロケーションです。なお、決闘のくだりに関しては Wikipedia の記事に詳述されています。

宮本武蔵 - 巌流島 (wikipedia)

J2 の試合ではFC東京が負けてしまいましたが、翌朝の地元のラジオでは「あのFC東京に勝った！」という扱いだったのが印象的です。これを機にサッカーの裾野が広がってくれると良いですね。とはいえ、東京にはそんなこと言ってる余裕が...ぁ

晩ご飯は現地の居酒屋に行きましたが、価格が良心的でした。九州と言えば焼酎のイメージしかなく、料理の味付けに関しては身構えずに行きましたが、関西よりは関東よりの味付けに近い感じでした。単なるお店による違いかもしれませんが、おいしいお店でした。

とんとん (食べログ)

7月31日 (日)

ホテルから博多駅へ
新幹線で博多駅から鹿児島中央駅へ
路面電車 (市鉄) で中央駅から水族館前へ
フェリー乗り場まで数分歩く
フェリーに乗って桜島へ
桜島でレンタサイクル
逆順に博多駅に戻る
地下鉄で博多駅から空港駅へ
飛行機で福岡空港から羽田空港へ

博多駅は数ヶ月前にリニューアルされたそうです。駅前ではミストシャワーが動いており、涼しげな雰囲気でした。新幹線乗り場には宣伝も多く、写真を撮っている人もまだまだいました。車内も快適で、座席がちょっと広々していました。なお、切符には２枚切符「博多〜鹿児島」というものがあり、当日購入でもちょっとお得なようです。

九州新幹線の終点である鹿児島中央駅には観光案内所があります。ここで桜島の観光マップをもらえます。また、観光案内所から出口方面にかけてコインロッカーが充実していますので、多少は大きな荷物があっても安心です。

市電 (トラム) に乗って鹿児島駅の少し手前で降ります。フェリー乗り場駅と水族館前のどちらでも構いませんが、水族館前の方が近いよ、と市電に乗るときに観光ガイドの人が教えてくれました。

桜島のフェリー乗り場を降りるとすぐにレンタカー屋さんがあります。ここで自転車も借りられます。借りる目安時間を伝えると、その時間に合わせたコースを教えてくれます。上り下りがありますが、車の少ない道を走るととても快適で、山と岩と海の景色がきれいでした。道には時折、灰が積もっており、別世界にやってきたなぁ、という気持ちになります。

そうこうしている内に帰る時間になりますので、新幹線で博多に戻ります。航空券を「羽田→福岡 + 鹿児島→羽田」で購入できれば良かったのですが、初動が遅くて売り切れでした。博多駅と福岡空港は地下鉄で数分ですが、接続を考えると意外と時間がかかります。複数の経路を扱ってくれる旅行代理店が増えると良いのになぁ、と思いました。

たまにはフラッと旅行に行くのも良いですね。

DotCloud で Solr を使ってみる

2011-07-27T21:10:00.004+09:00

DotCloud で Solr 3.1 を使えるようなので、簡単な検索 Web アプリを作ってみます。

DotCloud Solr

Solr の基本

Solr は検索用の Web アプリケーションで、Tomcat などのコンテナに WAR を置けば使えます。もっとも簡単な試用方法は Jetty を使うことで、これは Solr の配布用アーカイブに含まれているサンプルで確認できます。

Solr の最新バージョンは 3.3 ですが、DotCloud で利用可能なバージョンは 3.1 なので、まずはこれをダウンロードして展開してみます。

$ wget http://ftp.riken.jp/net/apache//lucene/solr/3.1.0/apache-solr-3.1.0.tgz
$ tar xzvf apache-solr-3.1.0.tgz
$ cd apache-solr-3.1.0/
$ ls . dist example
.:
CHANGES.txt  LICENSE.txt  NOTICE.txt   README.txt   client/      contrib/     dist/        docs/        example/

dist:
apache-solr-3.1.0.war                           apache-solr-core-3.1.0.jar                      apache-solr-uima-3.1.0.jar
apache-solr-analysis-extras-3.1.0.jar           apache-solr-dataimporthandler-3.1.0.jar         solrj-lib/
apache-solr-cell-3.1.0.jar                      apache-solr-dataimporthandler-extras-3.1.0.jar
apache-solr-clustering-3.1.0.jar                apache-solr-solrj-3.1.0.jar

example:
README.txt   etc/         example-DIH/ exampledocs/ lib/         logs/        multicore/   solr/        start.jar    webapps/     work/

dist ディレクトリには JAR ファイルと WAR ファイルがあり、これをそのままコピーすれば必要なコンポーネントを使えます。 Web コンテナには apache-solr-3.1.0.war を置くことになります。

example ディレクトリはサンプルを実行できる環境になっています。 solr ディレクトリに設定ファイルを置き、 start.jar を実行させると Jetty を使ってサーバが起動します。サーブレットに関するものは lib ディレクトリに置かれています。

$ cd example/
$ java -jar start.jar

Web ブラウザで http://localhost:8983/solr/admin/ にアクセスすると、Solr の管理画面になります。

どのフィールドでどのような値を管理するかは SCHEMA のリンクから確認できます。また、検索クエリに対してフィルタをかけたり、コンポーネントを実行させる設定は CONFIG のリンクから確認できます。これらはそれぞれ schema.xml と solrconfig.xml に対応しており、どちらも solr/conf ディレクトリにあります。

$ tree -L 2 solr
solr
|-- README.txt
|-- bin
|-- conf
|   |-- admin-extra.html
|   |-- elevate.xml
|   |-- mapping-FoldToASCII.txt
|   |-- mapping-ISOLatin1Accent.txt
|   |-- protwords.txt
|   |-- schema.xml
|   |-- scripts.conf
|   |-- solrconfig.xml
|   |-- spellings.txt
|   |-- stopwords.txt
|   |-- synonyms.txt
|   |-- velocity
|   `-- xslt
|-- data
|   |-- index
|   `-- spellchecker
`-- solr.xml

bin ディレクトリはユーティリティスクリプト置き場、 data ディレクトリは Lucene (実際の検索エンジン) のデータ置き場ですから、「設定ファイル」として必要なものは solr.xml と conf ディレクトリ以下のものになります。

つまり、ちょっと乱暴な表現をするならば、Solr の WAR ファイルと solr.xml と conf ディレクトリの中のファイルがあれば Solr を動かせる、と言えます。

Solr のバージョン

Solr は Lucene と密接に関係しています。初めは別々のレポジトリで開発されていましたが、ある時からレポジトリが統合されました。それからほどなくして、リリースも一緒のタイミングで実施されるようになりました。そして、バージョン番号も合わせることになりました。

統合後の最初のリリースが 3.1 です。以前の Solr のバージョンは 1.4 でしたが、一気に飛んだことになります。

バージョンは検索インデクスにも影響があり、Solr は Lucene のどのバージョンを使っているかを把握する必要があります。これは solrconfig.xml の luceneMatchVersion に記述されています。

$ grep luceneMatchVersion solr/conf/solrconfig.xml
  <luceneMatchVersion>LUCENE_31</luceneMatchVersion>

設定ファイルと実行環境でこの設定が異なっていると良ろしくありませんので、最初に Solr 3.1 をダウンロードしたのはこのためです。特に、Solr 1.4 と Solr 3.1 では Java オプジェクトをシリアライズした形式が異なるため、クライアント側で Java を使う場合には注意しなければなりません。

DotCloud への配置

DotCloud は WAR ファイルとコンテナ、そして、そのコンテナを監視する仕組みを提供してくれます。開発者は設定ファイルだけを管理し、 DotCloud 用の設定ファイル (dotcloud.yml) を用意してプッシュすれば Solr を使えるようになります。

一番最初は Solr のアーカイブから example/solr を丸ごとコピーするのが分かりやすいと思います。スキーマ定義を変更したい場合には schema.xml 、ハンドラなどを変更したい場合には solrconfig.xml を編集します。

手元のマシンで用意するもの:

$ tree .
.
|-- conf
|   |-- admin-extra.html
|   |-- elevate.xml
|   |-- mapping-FoldToASCII.txt
|   |-- mapping-ISOLatin1Accent.txt
|   |-- protwords.txt
|   |-- schema.xml
|   |-- scripts.conf
|   |-- solrconfig.xml
|   |-- spellings.txt
|   |-- stopwords.txt
|   `-- synonyms.txt
|-- dotcloud.yml
`-- solr.xml

DotCloud へのプッシュ:

$ cat dotcloud.yml
search:
  type: solr
$ dotcloud push solr .

これで http://{dotcloud-id}.dotcloud.com/solr/admin/ にアクセスすれば Solr の管理画面になります。

ドキュメントのインデクシング

適当なドキュメント群からインデクスデータを作成します。インデクスデータを作成するには、Solr の update ハンドラに XML を POST します。 Solr が XML を解釈して、Lucene が文字列を解析してくれます。

たとえば Sphinx で管理しているドキュメントの場合には、プレインテキストに変換したものを XML でラップして POST すれば良いだけです。

今回は、以前に書いた翻訳ドキュメントをインデクシングしてみました。

solr-document-indexer.py (github.com)

$ cd {SPHINX_DOCUMENT_DIR}
$ make text
$ python solr-document-indexer.py http://{dotcloud-id}.dotcloud.com/solr _build/text

スクリプトには色々とハードコードしていますが、とりあえず目的は達成できたので良しとします。

最後に、Solr 管理画面の "Query String" に "*:*" と入力してから "Search" ボタンをクリックして確認します。１件以上のドキュメントが検索結果として返ってくれば成功です。

プロキシの配置

Solr は XML で出力するだけでなく、いくつかのライタータイプを切り替えて使うこともできます。その一つに JSON ライターがあります。 JSON ならば、Web ブラウザまで渡せば色々と操作できます。

しかし、Web ブラウザがドメインを超えて通信するにはいくつかの制約がありますので、適当なプロキシを噛ませることにします。 DotCloud では PHP も使えますので、curl モジュールを使って通信を橋渡しさせます。

先ほどの Solr とは別のプロジェクトスペースを用意し、次のようなスクリプトを search.php としておきます。

<?php
header('Content-type: text/json');

const SOLR_SERVER = 'http://{dotcloud-id}.dotcloud.com';
$url = SOLR_SERVER . 'solr/select?';
$keyword = isset($_GET['q']) ? $_GET['q'] : '*';
$offset = isset($_GET['offset']) ? $_GET['offset'] : 0;
$query = "text:'" . $keyword . "'";
$param = array('q' => $query,
               'fl' => 'id,title,url',
               'hl' => 'on',
               'hl.fl' => 'content',
               'wt' => 'json',
               'start' => $offset,
               'rows' => 20);
$ch = curl_init($url . http_build_query($param));
// passthru output.
curl_exec($ch);
curl_close($ch);

次に、検索画面用の HTML ファイルを index.html とし、適当な JavaScript を書きます。ユーザーが検索ボックスに入力したものを search.php に "q" パラメータとして渡します。結果は JSON で返されますので、あとはそれを解釈すれば良いだけです。

なお、サーバ側でセットしている "hl"、"hl.fl" パラメータはハイライト用の設定です。検索スピードは低下しますが、必要に応じてこれらを使うのも良いと思います。ハイライトされたフィールドを JSON で扱う場合には ID の参照が必要になりますが、 JSON をその都度確認すれば解釈可能でしょう。

最後に DotCloud の設定ファイル (dotcloud.yml) を用意します。

www:
  type: php

あとはコマンドラインツールからプッシュすれば検索画面の出来上がりです。

In-house Documentation Search

DotCloud には複数のインスタンスを配置できますので、 Solr サーバと PHP アプリで同じ設定ファイルを使うこともできます。この場合、サーバ側の設定ファイル (/home/dotcloud/environment.json) に Solr サーバの URL が記載されていますので、次のようにして参照できます。

$envjson = json_decode(file_get_contents("/home/dotcloud/environment.json"), true);
const SOLR_SERVER = $envjson['DOTCLOUD_SEARCH_HTTP_URL']

この辺りは管理上の好みもあるでしょうから、どちらでも良いんじゃなかなと思います。

終わりに

DotCloud で Solr を使ってみました。課金について何も気にしていませんので、どれくらいのインデクス量ならどの程度の費用がかかるかは分かりません。とはいえ、プッシュすれば rsync で同期され、サーバ類が適切に再起動されるのは嬉しいですね。

検索に関しては、ちょっと Solr を使ってみる、あるいは、手頃な検索手段が無いドキュメント (*) をなんとかする、という点ではお手軽な方法ではないかな、と思いました。また、Solr にはファセット検索などもありますので、関連する検索キーワードを提示したり、惜しいキーワードを拾い上げることも出来るかもしれませんね。

(*) Sphinx 1.0 系に組み込まれた検索手法だと、日本語をきちんと検索できません。 1.1 がリリースされれば改善されるかもしれません。

マサチューセッツ工科大学

2011-07-22T00:23:00.002+09:00

新潮社から出版されていた「マサチューセッツ工科大学」を読んだメモ書きです。

Books - マサチューセッツ工科大学

書籍自体の初版は1995年9月で、2011年現在だと、おそらく絶版になっています。新潮文庫から出版された文庫版だと Amazon から中古版を購入できるようです。

読後感が訳者あとがきと一緒だったので抜粋します。

「ハイテク」関連の書籍というのは、ある友人の表現を借りると、おおむね「高血圧」の表現をとっている。騒々しいハイテク・グルーピーとは対照的に、きわめて冷静な、低血圧アプローチをとっていることが、個人的には本書の最大の美点と考えている。

時代を順々に追ってくると、エンジニアリングから出発してサイエンスに比重を移してきたことが分かります。一方で、最近の日本では、大学でも企業の即戦力となる人材を育成すべきだ、という論調も散見される点が興味深いところです。「歴史は繰り返す」という意味での揺り戻しなのか、もしくは歴史を共有できていないのか、はたまた、大学や大学院を研究機関として位置付けること自体が意味をなさないのか。社会的な構造や役割は変わり続けるため、唯一の正解もありませんが、大学の秋入学 (東大「秋入学」の前にやるべきこと - newsweekjapan.jp) が検討されている昨今、海外の有名な大学がどのような変遷を辿ってきたかを学んでおくのも良いですね。

もちろん、工学系の大学についての叙述ですから科学や工学に関する基礎知識があると読みやすいでしょうが、表現が固い以外は、数式などはありませんので気軽に読み進められます。願わくば、高校生のときに読んでおきたかったなぁ、と思いました。MIT への憧れというだけでなく、そもそも大学って何するところ？何を期待されているところ？という点が深堀りできるかもしれません。

目次は次のようになっています。

第１章エンジニアの欲望と動機
第２章バランス喪失のユーモア
第３章エンジニアの誕生
第４章思考をうながす校舎の誕生
第５章工学 (エンジニアリング) から科学 (サイエンス) へ
第６章鉄道模型クラブ
第７章 MIT製の義肢
第８章メディア研究所
第９章 10億分の1 (ナノ) メートルのテクノロジー
第10章技術のスポーツ
第11章脱コンピューターのシステム

「理系」と十把一絡げにされることも多いですが、多様な分野があるなぁ、と当たり前のことを再認識できました。

女子ワールドカップで日本が優勝

2011-07-18T17:00:00.001+09:00

ドイツで開催された女子のワールドカップで「なでしこジャパン」が優勝しました。 FIFA の公式サイトにもきちんと結果が残されているのを確認すると、本当に大きな一歩だな、と実感します。

得点王 + MVP の澤選手が最高スコアであることを始めとして、海外での評価も上々でした。

Japan Women vs United States Women Player Ratings (goal.com)

日常的にテレビで扱われないスポーツの選手たちは、日常生活を含めて見えないところで本当に苦労が絶えないと思いますが、来年のロンドンオリンピックでも、もちろんその前の予選でも、頑張って欲しいですね。

エキスパート Python プログラミングの読書会 - 13

2011-06-27T01:12:00.003+09:00

「エキスパート Python プログラミング」の読書会に行ってきました。 10章「プロジェクトのドキュメント作成」に関することで、この章は Web でも公開されています。

エキスパートPythonプログラミング読書会13
10章: プロジェクトのドキュメント作成 (sphinx-users.jp)

今回は、ざっくりと次の二点に関して話し合いました。

業務でどうやってドキュメント (主に IT 業における技術文書) を書いてますか？
"Sphinx" (日本語) というツールの使い方、Tips の共有。

自分のメモによる時系列は、おおよそ次のようになります。

参加者の自己紹介
6/21 19:49 "ドキュメント作成は、開発者、ときにはマネージャもさぼってしまいがちな作業です。"プロジェクトのドキュメント作成 - http://t.co/pf2y18e #expertpython
6/21 20:03 Q. 技術文章を書くためにどんな本を読んで勉強してる？ A. ワインバーグ先生の本、日本語の作文技術、理科系の作文技術、エキPy(笑 #expertpython
6/21 20:16 タイトルが明快になれば逸脱した話題はノイズに思えてくるので、情報のスコープが絞られる。後から振り返るときにどのような検索語句を使うだろうか？と問い直してみる。たいていの検索インデクスではタイトルの重みが強いことを利用する。 #expertpython
6/21 20:18 レビューするときは見た目を変えてみる。内容を書き出すフェーズと、表示をリッチにするフェーズを分ける。「２つのステップで書く」ということ。 #expertpython
6/21 20:30 Sphinx の autodoc を使うと docstring をドキュメントに反映しやすいので、doctest をやる気が上がるらしい。意図と実装が一緒になっているので、変更漏れが少なくなる。これもひとつの TDD。 #expertpython
6/21 20:36 Sphinx の便利メモ。 / 逆引き辞典 - http://t.co/nRuJInz #expertpython
6/21 20:45 ドキュメントの「ポートフォリオ」を作りましょう。再利用可能なテンプレートのことで、目的別に保管しておく。完成したドキュメントから作り直すと良さそう。先にポートフォリオを作り始めたら死亡フラグ。 #expertpython
休憩
6/21 21:24 "glossary" ディレクティブを使うと索引を生成できるけど、日本語だと Symbols にまとめられてしまう。日本語用パッチを作っている人もいるが、さらっとは取り込めない状態みたい。 #expertpython
6/21 21:28 Python も一緒に入るみたい。 / Windowsへのインストール(スタンドアロンインストール) - http://t.co/rAU10zw #expertpython
6/21 21:53 Sphinx の拡張レポジトリ。 / birkenfeld / sphinx-contrib - http://t.co/xatcvNQ #expertpython
6/21 22:10 linkcheck で外部へのリンクも確認しましょう、ということをみんなで学んで終了。 #expertpython

これ以降では、後からつらっと思ったことも含めて書いておきます。

ドキュメントを書く

まずは「技術文書を書くための７つのルール」を確認しました。誰に向けて何を書くか？という部分は文書一般に言えることだと思いますが、自分が特になるほど〜と思ったのは次の３点です。

アイデアにフォーカスして、まずはレビューする。
意味が分かり、動かせるサンプルを使う。
ドキュメント・ランドスケープを意識する。

作成とレビューのサイクル

PowerPoint や Word といった WYSIWYG (what you see is what you get: 作成中の文書と成果物が同じ見た目であること) ツールの場合、とかく表示の調整から始めがちです。ページ余白を調整してテーマや色遣いを決めて、フォントは何を使って装飾は... と、だいたい同じことに同じように時間をとられます。過去のテンプレートを使い回しても、なんとなくアニメーションを追加してしまうかもしれませんね。何かを書こう、と思ってツールを起動させても、その何かを書く前の準備が終わったら一休み、となりがちです。

一方で、メモ帳などのテキストエディタは文章に焦点を絞れるため、即座に何でも書き始められます。とはいえ、読み直したときの抑揚のなさ、図を思い通りに配置することの難しさなどにより、そのままレビューするわけにもいきません。また、無秩序に書き始めてしまうと、量が多くなったときにアウトラインを把握できなくなります。

これらの中間 (?) として、テキストエディタで書いて、何らかのツールを使って成果物を生成する方式があります。数十年前には、書籍を出版するための適したツールがないから作っちゃおう、という著名な先生もいますが、割と普遍的な課題ですから、現在までにたくさんの文法とツールが開発されています。

気軽に書き始められて、それなりの見た目 (目次が明快、強調部分が目立つ、図を取り込める、など) でレビューできて、その結果を反映できる、というサイクルを回すためには reST や markdown、textile は良い選択肢だと思います。少なくとも、独自フォーマットやローカルルールは控えた方が良さそうです。日本語の場合はついつい中黒 (・) を使って箇条書きを表現しがちですが、後からツールで処理する、つまり再利用性を高めるためには、"*" や "-" の方が良いかもしれませんね。

フィードバックのサイクルを繰り返す中では、変更履歴を追跡できるようにしておくことも重要です。 Word にも履歴管理機能はありますが、きちんと使えない人がいたり、使いすぎると動作がもっさりするなどの問題があります。特に複数人が編集に関わる場合には、文書自体と履歴管理は分離しておいた方が良いと思います。

履歴管理されているとレビュー範囲が明確になります。また、"文書ファイル名-日付文字列.拡張子" というルールでファイル名を変更する必要もありませんので、どれが最新版か分からなくなってしまう問題が低減します。ファイル名を変更するルールの場合、"最新版-課題XXXについて.docx"、"最新版2-課題XXXについて.docx" となりかねませんから。

何はともあれ、「１回書いたらそれでオシマイ！」ではなく、ある程度の期間に渡って継続的に更新し続けることがポイントです。主要な考えを書き出して、それを他の人に見てもらい、意見を反映させて、さらに考えを書き足していける状態を作ることが目標となります。要するにソースコード管理と一緒ですね。

実際に動作するサンプル

何かの手順書を作成する場合、「ここは手元の環境に合わせて XXX の部分を書き換えてください」と書くことも多々あります。それ自体は悪いことではないと思いますが、例示が悪いと誤解が生じやすくなってしまいます。

たとえば、Java のプロジェクトを Subversion からチェックアウトして Maven で Jetty を動かす場合、次のサンプルでは意図が伝わらないかもしれません。

$ svn co {Subversion の URL} hoge
$ cd hoge
$ cd example
$ vi {設定ファイル.xml}
--- サーバ情報を書き換える ---
$ mvn jetty:run

この場合は、Subversion の trunk から引っ張ってくるのか、 branch の場合はどれかが分かりません。また、設定ファイルがひとつなのか複数なのかも分かりませんし、何のサーバ情報をどのように変更するかも定かではありません。コピペして動かせませんし、何より hoge って何？となります。

コマンドサンプルの前後に説明を書き連ねることもできますが、それよりは、そのまま実行できるように工夫した方が良いでしょう。もしかしたら設定ファイルの見直しから始めなければならないかもしれません。しかし、それによって外部への依存性が明らかになりますので、中長期的な観点では、無駄な作業にはならないと思います。

サンプルはソフトウェアを客観的に見直すきっかけにもなります。必要だと思っていたパラメータが実は使われていなかった、もしくは、設定したつもりだったのに内部での読み取り間違いで反映されていない、というケースもあぶり出されます。

ドキュメント・ランドスケープ

「ドキュメント・ランドスケープ」という言葉を知りませんでしたが、この言葉は翻訳者の方々が原著者に問い合わせて NOTE に記載したとのことです。

「あるべきものがあるべき場所に存在する」というようなことで、家がビルの屋上にあったらオカシイよね、などを判別するために使います。

たとえば、手順書であれば事前条件や想定読者が実際の手順より前にあるべきです。先ほどの例であれば、コマンドを実行する前に svn コマンドと mvn コマンドをインストールする、あるいはインストールされているマシンを使う必要があります。そもそも Maven って何？という読者も想定されるなら、別途説明があった方が親切でしょう。

これまで読んできたドキュメントを参考にすると、こういうことはこの辺りに書いてありそうだ、と、読者側で違和感なく受け入れられる構成を考えていくことになります。何らかのテンプレートを踏襲したり、過去のドキュメントからコピーしてくるなど、いわゆるノウハウを活用する部分と言えます。「ポートフォリオ」の蓄積とも言い換えられます。

Sphinx あれこれ

Sphinx はそれ自体が文法を持っているわけではなく、 reST をまとめるツールと言えます。このため、reST と markdown は比較対象として妥当ですが、Sphinx と markdown の比較には違和感が発生します。レイヤーが違うわけです。 markdown をまとめるツールとしては jekyll (jekyll 日本語説明) がありますので、比較するならこちらが適当でしょう。 jekyll で構築されたサイトとしては gitready があります。

reST が拡張可能な仕様なので、Sphinx を作ることができたとも言えます。ディレクティブという命令体系を拡張できますので、 reST がそもそも持っているディレクティブに加えて、 Sphinx によるディレクティブ、あるいは自分独自のプラグインでディレクティブを記述できます。あるツールに対するラッパーという意味では、ラインエディタ ex におけるスクリーンエディタ vi と似た関係となります。

Sphinx を使って HTML を生成するときには、テンプレートエンジンとして jinja2 (jinja2 日本語) が使われます。 jinja2 にはテンプレート継承の仕組みがありますから、既存のテンプレートを再利用しながら、必要な部分だけを自前の HTML で上書きできます。たとえば、ヘッダーやフッターを書き換えたり、メニューバーをカスタマイズできます。

出力形式 (ドキュメントビルダー) は複数種類ありますので、表現は HTML だけに止まりません。 PDF や Windows ヘルプ、JSON や pickle にも出力できます。 JSON だけをサーバサイドに保存して Ajax を利用したドキュメントビューアや、 Python アプリケーションにドキュメントを組み込むといったアイデアも実現できそうです。

その他に、Sphinx でのドキュメント生成時に、ドキュメント内部から外部を参照しているハイパーリンクを確認できます。これには勉強会参加者一同が驚きましたが、 linkcheck ターゲットで実行できます。

$ make |grep linkcheck
  linkcheck  to check all external links for integrity

$ make linkcheck
sphinx-build -b linkcheck -d _build/doctrees   . _build/linkcheck
Making output directory...
Running Sphinx v1.0.7
loading pickled environment... done
building [linkcheck]: targets for 24 source files that are out of date
updating environment: 0 added, 0 changed, 0 removed
looking for now-outdated files... none found
preparing documents... done
writing output... [  4%] README
(line   5) http://krondo.com/blog/?page_id=1327 - working
(line   5) http://skitazaki.appspot.com/translation/twisted-intro-ja/ - broken: HTTP Error 404: Not Found
(line   5) http://twistedmatrix.com/documents/10.0.0/core/howto/index.html - working
(line  10) http://skitazaki.appspot.com/translation/twisted-intro-ja/ - broken: HTTP Error 404: Not Found
writing output... [  8%] index
(line  11) http://twistedmatrix.com/ - redirected to http://twistedmatrix.com/trac/
(line  43) https://github.com/skitazaki/twisted-intro-ja - working
writing output... [ 12%] p01
(line   8) http://twistedmatrix.com/ - redirected to http://twistedmatrix.com/trac/
(line   8) http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python - working
(line   8) http://twistedmatrix.com/pipermail/twisted-python/2009-May/019706.html - working
(line  16) http://twistedmatrix.com/trac/wiki/Documentation - working
(line  16) http://twistedmatrix.com/trac/browser - working
(line  61) http://en.wikipedia.org/wiki/Locality_of_reference - working

--- snip ---

build finished with problems.
make: *** [linkcheck] Error 1

$ ls _build/linkcheck/
output.txt

存在するものは working 、リダイレクトが発生するものは redirected 、リンク先が見つからないものは broken が表示されます。ターミナルの設定にも依りますが、それぞれのメッセージは色付けされているかもしれません。見やすくなっていると嬉しいですね。

最終的な結果は output.txt というファイルに書き出されます。ドキュメントのソースコードが階層化されている場合には、出力も階層化されます。

終わりに

エキPy の読書会に行ってきました。効率的なコードの書き方に関することはありませんでしたが、ドキュメントを書くことについて再考できました。

個人的には、多くの日本人ソフトウェアエンジニアに対して、得意なことに関しては次の順序関係が成り立つと思っています。

[日本語] >> [業務で使用しているプログラミング言語] > [英語]

ソフトウェアにはバグがつきもの、という開き直りもあるかもしれませんが、そもそもそういったソフトウェアの仕様を日本語で書き出してみると、きっと書けないと思います。馴染みのある日本語で正確に記述できないことを理解に乏しいプログラミング言語で記述しなさい、といっても、規模が大きくなればなるほど、多様な人たちが混ざれば混ざるほど、それは無理のような気がしてなりません。 (ひとりプロジェクトや、プログラミング言語への理解が日本語への理解と同程度の人たちの集まりは除く)

英語で書けば論旨が明快になるとの考えは一理ありそうですが、実際問題として、そんなに英語で読み書き (あるいは会話) できる人は多くありません。少ない語彙から捻り出した文章はあやふやな表現に終始しがちですので、まずは日本語で概要を共有してから、なんらかのプログラミング言語で実装するのが良いんだろうな、と思います。

とはいえ、日本語そのものに対する理解ですら怪しいのは如何ともしがたい、という部分が最大の難関なんでしょうけどね。。。

Google Tasks API を使ってみる

2011-06-21T08:19:00.003+09:00

先月、Google Tasks の API が公開されました。 API 公開のアナウンスが出されたときはサンプルがありませんでしたが、先週末に記事が公開されました。ライブラリコードのサンプルディレクトリに同様のコードが存在します。

Getting Started with the Tasks API on Google App Engine (Google Apps Developer Blog)
Getting Started with Tasks API on Google App Engine (Google Code - Google App Engine)

記事/サンプルを読む中では、 OAuth2Decorator クラスが導入されたこと、コールバック URL のハンドラスクリプトとして oauth2client/appengine.py を使えるようになったこと、この二点が大きな改善点だと思います。

しかし、それに気付かずに実装しちゃった... という寂しいお話。いちおう、スクリプトはこちら。。。

コマンドライン (bitbucket)
Google AppEngine (github) - 動作用

認証の始まり

最近の Google のたいていの API は OAuth 2.0 を使います。 Google が提供している Python のライブラリには oauth2client モジュールがあり、これを使うと簡単にトークンを管理できます。ちなみに oauth2 は OAuth 1.0a 用のライブラリ... というのは蛇足です。

認証には OAuth2WebServerFlow か OAuth2Decorator を使うことになりますが、どちらの場合でも次の４つの情報が必要になります。

client_id: アプリケーション ID のようなもの。
client_secret: アプリケーションのパスワードのようなもの。
scope: アプリケーションがユーザーに許可を求めるアクセス範囲。
user_agent: アプリケーションの名前。

client_id と client_secret は API Console から取得します。 API Console は画面表示が英語ですが、なんとなくの雰囲気でも使える気がします。 user_agent は適当な名前を付けた方が良いと思いますが、割と何でも動くはずです。で、おそらく選択肢が存在するのが scope です。

API を使ったアクセスはユーザーから見えない部分で何をするか分かりませんので、この範囲内で動作します/させます、と表明します。最近の話題だと、Twitter が scope の扱いを見直し、ダイレクトメッセージへのアクセス権限を変更しました。 Google の API では、そんな感じの仕組みが細分化されて実現されています。

Tasks API では、次のふたつの scope から選択できます。

https://www.googleapis.com/auth/tasks: 読み書き (read/write access to Tasks)
https://www.googleapis.com/auth/tasks.readonly: 読み込み専用 (read-only access to Tasks)

なんで https:// から始まるような長い文字列なのか？という疑問はさておき、 API ドキュメント - Developer's Guide (v1): Using the API - の Authorizing requests に記載されています。 Google のそれぞれの API には類似のドキュメントがあり、たとえばモデレータの場合には、 tasks の部分が moderator になったような感じで記載されています。モデレータについては Hack for Japan の Google モデレーターのデータを見る (過去記事) で同じような認証フローを書いています。

コールバック

先ほどまでの部分 (コードを掲載してないけど) で、OAuth 2.0 認証の準備が整いました。 OAuth は、認可するサービス (この場合は Google) と認可されるアプリケーション (この場合は自作アプリ) が別々に動いていますから、認可が終わったら何らかの方法でユーザーをアプリケーションに戻す必要があります。 Web アプリケーションでの常套手段として HTTP リダイレクトがありますので、アプリケーションはリダイレクト先のコールバック URL を準備しておきます。

API Console に登録する。
アプリケーションに特別な URL を用意し、GET パラメータを解析する。

コールバックは、たとえば flow という変数が OAuth2WebServerFlow のインスタンスであり、コールバック URL のリクエストハンドラを AppEngine の webapp フレームワークの RequestHandler で実装した場合、次のように記述できます。

credentials = flow.step2_exchange(self.request.params)

この戻り値がユーザーの認証トークンになります。

いちいちこのような仕組みを理解しながら記述するのは煩雑なので、 Google API Python Client では oauth2client/appengine.py というスクリプトを提供してくれています。冒頭に挙げた Google Code の記事では、 app.yaml に次のハンドラを追加しています。

handlers:
- url: /oauth2callback
  script: oauth2client/appengine.py

ライブラリの中に実行コードも一緒にして配布しているわけです。実際にコードを見てみると、最後に次の変数と関数が定義されています。

application = webapp.WSGIApplication([('/oauth2callback', OAuth2Handler)])

def main():
  run_wsgi_app(application)

URL が決め打ちになってしまいますが、簡単にコールバックを処理できるのは嬉しいと思います。

なお、API Console で登録していない URL をコールバックに指定すると認証エラーになります。 AppEngine の場合はローカル環境で開発してプロダクション環境にデプロイしますので、その両方 (ふつうは localhost と app-id.appspot.com) の URL を登録しておきます。ホスト名以降のパスも一致していなければなりませんので、最初の登録には注意が必要かもしれません。

タスクリストとタスク

認証トークンを使えるようになると、ようやく Tasks API を実行できます。 Tasks にはふたつのデータモデルがあります。

タスクリスト (task list): 複数のタスクをまとめるカテゴリのようなもの。
タスク (task): 個別の「やること」。期限や状態を設定できる。

ユーザーはデフォルト (@default) のタスクリストを含む複数のタスクリストを持つことができます。個々のタスクはいずれかのタスクリストに所属します。つまり、タスクを操作するためには次の二つのステップが必要になります。

タスクリストの一覧を取得する。
タスクリストを指定して、タスクの一覧を取得する。

実際に API 用のサービスを構築し、タスクリストを取得するコードは次のように記述できます。 credentials は OAuth 2.0 の認証トークンオブジェクトです。

http = httplib2.Http()
http = credentials.authorize(http)

service = build('tasks', 'v1', http=http)

tasklists = service.tasklists().list().execute()
for item in tasklists['items']:
    if item['title']:
        print '*', item['title']

build() は JSON のサービス定義ファイルからメソッドを構築するためのものです。 Discovery と呼ばれる仕組みで、要するに以下の JSON ファイルを読み込んでオブジェクトを生成します。

https://www.googleapis.com/discovery/v1/apis/tasks/v1/rest

人間が読むような代物でもありませんが、 resources というキーに対応する値がインスタンス化されます (表現が微妙な気もしますが)。いちおう読んでみると、メソッド名やそこで使われる HTTP メソッド、パラメータとして有効なもの、その順番などが記述されています。メソッドごとのスコープも制限されていることが分かります。 tasklists には methods が定義されており、その中に list があります。 path や description と API ドキュメントを照らし合わせてみると、何となく意味が分かってくるかもしれませんね。

(JSON を一部抜粋)

"list": {
 "id": "tasks.tasklists.list",
 "path": "users/@me/lists",
 "httpMethod": "GET",
 "description": "Returns all the authenticated user's task lists.",
 "parameters": {
  "maxResults": {
   "type": "integer",
   "description": "Maximum number of task lists returned on one page. Optional. The default is 100.",
   "minimum": "-9223372036854775808",
   "maximum": "9223372036854775807",
   "location": "query"
  },
  "pageToken": {
   "type": "string",
   "description": "Token specifying the result page to return. Optional.",
   "location": "query"
  }
 },
 "response": {
  "$ref": "TaskLists"
 },
 "scopes": [
  "https://www.googleapis.com/auth/tasks",
  "https://www.googleapis.com/auth/tasks.readonly"
 ]
},

タスクを取得する

次に、タスクの一覧を取得します。すべてのユーザーは @default というタスクリストを持つはず (意図的に削除しようとした場合などは未確認) ですので、決め打ちにしてしまって一覧を取得します。

tasks = service.tasks().list(tasklist='@default').execute()
for task in tasks['items']:
    if task['title']:
        print '*', task['title']

タスクにはタイトルがありますが、空文字でも構わないようなので、if 文で確認しています。個人的には必須で良いのにな、と思いますが、そこはそういう仕様のようです。

NOTE:

内部的に uritemplate モジュールを使いますが、バージョンによっては "@" の置換がうまくいかないかもしれません。 google-api-python-client に含まれる uritemplate と本家のものは safe が違うためです (将来的には統一される？)。

タスクを登録する

登録するときは insert() メソッドを実行 (execute()) します。 insert() の引数には tasklist と body を指定します。 'notes' と 'due' は指定しなくても構いません。

task = {
    'title': 'ファミマカードの支払い',
    'notes': 'そろそろ完済したい。',
    'due': '2011-07-08T12:00:00.000Z'
}
result = service.tasks().insert(tasklist='@default', body=task).execute()
print "Created a new task,", result['id']

終わりに

Google Tasks API を使ってみました。認証部分と Discovery あるいはドキュメントのどこを読むべきかが分かってくると、どの API も似たようなイメージで利用できます。ライブラリ自体も着々と改善されていますので、もうすぐ正式リリースとなるかもしれません。

タスク API は簡単に扱えますが、そもそも Google Tasks の位置付けが微妙... という考えもあります。とはいえ、AppEngine にメールを送ったら勝手に登録してくれるようにできると、ケータイメールで受け取ったことを転送するだけでタスク化できます。また、メールとカレンダーの両方に統合されているため、タスク自体に気付きやすいように思います。要は、どこまで Google Account に集約するか？という問題になるでしょう。

なお、最近は API ドキュメントのサンプルに PHP も追加されました。そこは Go じゃ... という気がしなくもありませんが、幅広くサンプルが揃うのは良いことだと思います。

おまけとして、過去には、モバイル画面をスクレイピングする、という記事もありました。もちろん、今となっては非推奨でしょうけど。

Google タスクの一覧を取得する (IBM dW)

アジャイルスタートアップの後で思ったこと

2011-05-29T01:23:00.005+09:00

MIT Media Lab新所長、伊藤穰一とPivotalのCTO,Ian McFarlandが語る「アジャイルスタートアップ」に行ってきました。

ATND のページ
ハッシュタグ #on_lab

自分の認識では Pivotal Labs は Pivotal Tracker を作っている会社でしたが、アジャイル開発に関するコンサルティングにも取り組んでいるようです (コンサルの方がメイン？)。クライアント企業を見てみると、Twitter、 Best Buy、Groupon、Linden Labs、Salesforce、Alexa などが名前を連ねています。 IDEO と協力してコンサルティングに関わることもあるようで、ソフトウェア業界のひとつの最先端、と呼べる立場だと思います。

今回はそんな会社の CTO と、 MIT Media Lab のディレクターのトークセッションでした。セッション内容に関しては Twitter を見るなり、もしかしたらネットメディアに取り上げられるかもしれませんので、そちらを参照、ということで。この記事では、自分がなんとなく思ったことをツラツラと。

自分のメモ:

18:55 - 「今日は通訳がいない」と今気づいたw 今さっき相談して進め方を決めるとは、アジリティ高い。
19:00 - アジャイルのストーリーボードとかスプリントの説明から。方向性だけ決めておく。Pivot で細かい部分はサクサク切り替える。Pivotal の由来はそれ。
19:03 - 「テストを書く方が実際のコードより多い」。RoR での TDD の実例と絡めた話。テストは自然言語で書くから、ビジネスオーナーとのコミュニケーションやリリースタイミングが分かりやすい。
19:08 - タスク群に対して velocity を管理し続けるから、開発者の健康には良いかも。締め切りを厳密にするのではなく、このままのペースで進めばいつまでに機能を充足できるかを見積りできそう。
19:11 - 8時45分に朝ごはんを用意。それに合わせて出社。Pivotal さんは朝早い！125人くらい。
19:14 - 「コードを書いてるときにイノベーションを生み出してはダメ！」新しいことはストーリーボードを作っているときに。
19:19 - プロトタイプ (テスト無し) をプロダクション (テスト有り) に書き換えるときはバグも含めてそのままに。ついでに機能追加とかダメ。
19:27 - 大きな機能や思い入れのある機能を捨て去るのは心情的に悩ましい。ストーリーが細かく分割されていれば、軌道修正 (Pivot) に取り組みやすい。
19:40 - 「Zynga なんかのプロダクトマネージャーはみんな SQL をたたいて、データドリブン」... えっ(-_-;)
20:18 - ペアプログラミングだとふたりで同じことやるから全体の生産性は落ちるのかも、とか思っていたけど、ペアプロ中はメールも YouTube も見ないから集中力が高い状態に追い込まれる、と。。普段がいかにぬるま湯かを思い知らされた感じ。とても勉強になりました。

朝会 (daily standup meeting) も良いですが、朝食を用意した方が色々と嬉しい人も多いかもしれませんね。

アジャイルって？

アジャイルソフトウェア開発を略して「アジャイル」で、英語だと "agile" です。 "agile" は日本語だと「機敏な」や「敏捷な」という意味で、 RPG (ロールプレイングゲーム) の「素早さ」を表すパラメータに "AGL" を使うものもありますが、これは "agile" からの３文字になります。要するに、高品質なソフトウェアを素早く提供するためにはどうすれば良いか？という課題に対するひとつのアプローチと言えます。

より詳しくは「アジャイルソフトウェア開発宣言」 (The Agile Manifesto) があります。今年の２月で10年を迎えていますので、この10年の変化を振り返りながらいろいろな記事が発表されました。個人的に印象に残ったのは次の記事です。

REFLECTIONS ON THE 10 YEARS SINCE THE AGILE MANIFESTO (Mike Cohn’s Blog - Succeeding with Agile)

ざっくりした内容は次のようになります。(引用や翻訳ではありません)

この10年で言葉と考え方が浸透してきたこと、実践すべきだ！との認識も増えてきており、部門長に提案するときには議題に上げるべきでしょう。また、- "We stop talking about agile." - つまり、それが何であるかを議論するフェーズから、それをどのように実践するか、ベストプラクティスは何か、といったことを議論するフェーズになりつつあります。例えば、オブジェクト指向プログラミングを語る際に、「オブジェクトとは何か？」を議論するフェーズは過ぎ去り、 OO (Object-Oriented) な考え方は当然ともみなされていますよね？アジャイルに関しても同様です。もはや実践して然るべき概念なのです。

ウォーターフォール開発

アジャイル開発と比較してウォーターフォール開発が挙げられます。 "waterfall" は滝のことで、水が溜まったら上から下へと一気に流れる様子から、要求獲得、仕様作成、システムの実装、検証を順番に実施する開発モデルを表現します。

滝が勢いよく流れ落ちるためにはたくさんの水を溜める必要があり、通り道に遮蔽物が存在しない方が望ましいですね。ウォーターフォール開発も同様で、要求が適切に検討されて、実装がスムーズに進むように準備しておく必要があります。要求 (実現したいこと) が曖昧で、製品開発と技術研修が混在している状態では、勢いよくシステムを開発することは難しいでしょう。水はいつしか地面に辿りつき、地面に浸み込んだり蒸発したり、あるいは海に流れ出ることもあります。しかし、コンピュータシステムはそうもいきません。時流に乗って多くのユーザーを獲得できる Web サービスや、いつまでも使われる社内システムは確かにあります。それは幸せなことですが、あくまで一握りの成功例。予算を割り当てて多くの人員を投入し、せっかく作ったものが負債になってしまっても、それを無に帰すことはできません。

無かったことにはできない、という点ではアジャイルも同じですが、ウォーターフォールに比べて、こまめにフィードバックを受け取って軌道修正を重ねる、という点が違います。どちらも一長一短ですし、要は方法論なのでどっちでもいいじゃん、と言えばそうかもしれません。しかし、いつフィードバックを受け取るか？という部分に心理的な違いがあります。

締め切り意識

たいていの受託開発は、契約で決めた納期に成果物を提出し、場合によってはその後の保守を請け負います。契約開始時点では、期日と何らかの要件を決めますね。機能の一覧だったり性能要件だったり内容は様々ですが、何らかのゴールが契約書という形で存在します。

一方で自社製品開発の場合は、社内の誰かしらが製品企画を取りまとめます。売り上げ予測だったり開発工数だったりを算出し、リリース期日を設定します。期日に合わせてプロモーションを進めているかもしれません。これがプロジェクトメンバーのゴールとなります。

どちらの場合も、締切日が存在します。

ちょっと話題を変えて、小学校の夏休みの宿題を振り返ってみます。多くの小学校 (地域により違いはある) は、9月1日が二学期の開始です。この日が夏休みの宿題の締切日とも言えます (最初の授業で提出する場合もあるが、そこは気にしない)。さて、宿題の進捗状況はどうだったでしょうか？

最初の数日で計画を立て、徐々に進めて、最後の数日で細かい部分を調整する。
とりあえず最初は何もせず、最後の数日で一気に片付ける。
時期とは無関係に自分のペースで進めて、夏休みの中盤には終わってる。
時期とは無関係に自分のペースで進めたものの、全ては終わらなかった。

「なぜもっと早く着手しなかったの？」と問われれば、「ギリギリの方が本気出せるから」と答える人も多いでしょう。それはそれで正しいことだと思います。この場合、締め切りが存在すればその日までに完成するでしょうが、その前には完成しません。フィードバックを受け取れる状態になるのは、締め切り直前でしかありません。

一方で、一定のペースで進めた場合には、終わるかもしれないし終わらないかもしれないし、常に不完全かもしれませんが、いつでもフィードバックを受け取れます。もしかしたら、スピードを上げるために友達に相談できるかもしれません。爆発的な推進力に欠けるかもしれませんが、次に何をすべきかの判断材料には事欠かないでしょう。

夏休みの宿題は個人の話なのでどちらでも構いませんが、関係者が増えてくると状況が異なってきます。最終成果物の前にレビューを実施するとなれば、その前に途中成果をまとめる必要があるかもしれません。わざわざまとめる時間がかかるのに、その効果が分かり難い、という理由で、レビューが敬遠されるチームもあるでしょう。レビュー結果を反映したものを再レビューになれば、もっと時間がかかります。たとえ実施したとしても、いわゆる「締め切りに追われる」状態に陥ってしまい、体力的にも精神的にも長くは続かないかもしれません。

マインドを変える

締切駆動に反して、Velocity (速度) という考え方があります。「いつまでにここまで進める」のではなく、「ここまで進むためにはこれだけ時間がかかった」ことを管理し続けていく手法です。チームのメンバーが変わらない場合、速度が分かれば将来の予測を立てやすくなります。

同じ難易度のタスクが10個存在 (実際には有り得ないが) したら、ひとつに1週間かかるなら全部終わるまでには10週間かかる、と言えます。同じペースで進める、それぞれのタスクが独立している、の二点が大事だと思います。つまり、全てを実現しなくとも、競合企業に対抗するためやユーザーの反応を見るためには途中でリリースできる状態です。 4週間でリリースして4週間は反応を見ながら開発を進めて、実は不要だったと分かれば、その後の2週間は軌道修正できます。締切駆動にパレードの法則が重なってしまうと、最後の2週間に全体の8割を実現する計画になるかもしれず、それを修正する術はありません。

「そうは言っても自分は計画的だ！」と主張する人もいるかもしれません。ただ、その人の周りにいる全ての人も計画的だとは限りません。人間がふたり以上集まれば意思疎通が必要です。目的地を設定して出掛けるのか、とりあえず出掛けてみてから目的地を見つけるのか、その意識合わせが大切になります。

目標意識を共有せずとも良い、あるいは無計画でも良い、とは違います。特定の部分 (時期の問題と人の問題) にしわ寄せがいかないようにしましょう、と言えるかもしれません。極端かもしれませんが、特定の人が特定の工程に責任を持つモデルがウォーターフォール、みんなが全体に責任を持つモデルがアジャイルとも考えられます。チームの構成メンバーや何を実現すべきかに合わせて、考え方を切り替えるべきでしょう。

なお、チームとしての Velocity を維持するためには、そのタスクに要した時間を管理しておかなくてはなりません。時間管理に関してはポモドーロテクニックなどが役立つかもしれませんね。

ポモドーロテクニックについて４ (R-style)

終わりに

興味のあったイベントに行ってきました。簡単に感想でも書こうかな、と思いましたが、ちょっと違う切り口で自分の考えを整理してみることも良いかな、と考え直し、アジャイルとウォーターフォールのひとつの側面を対比させてみました。

とにもかくにも、方法論を変えるためには、関係する人たちの考え方も変えなければなりません。現在実践していることと検討していることを対比させながら、何に似ていて何とは違うのか、メリットとデメリットは何かを明らかにしていく、という、普通のことを普通に実行する必要があるでしょう。

「ウォーターフォールは古臭いから、これからはアジャイルだ！」と主張したいのではなく、いくつかの方法論がありますが、それぞれを使い分けるためにはチームメンバー (もしくは外部の関係する人たち) の考え方を変える必要がありますね、という話です。どんな病気においても特効薬はありませんので、医師にすがりつくだけでなく、患者と医師が協力して健康を維持できるようになると良いですね。

まぁ「人月の神話」を読んで実践すれば良いんじゃ... という話なのかもしれません。出版から数十年が経過しても変わらない考え方が存在することは間違いありません。表現方法を少しずつ変えながら、多くの人に分かりやすくなっていくと良いのかな。

Ars longa, vita brevis

鯖江市のオープンガバメント

ちょっと思ったこと

終わりに

デブサミ2012に行ってきた

１日目 - 2/16

node.jsテクノロジースタック for ソーシャルアプリケーション

Cloud Foundryで変わるこれからのクラウドアプリケーション開発

3・11から見えた社会基盤としてのIT

２日目 - 2/17

言語の世界

アジャイルマニフェスト ディケイド

Building scalable web apps

終わりに

waf を使って Sphinx で生成した HTML を ZIP にまとめる

環境の準備

wscript を書く

終わりに

Buildbot を使ってみる

Buildbot をインストールする

マスターノードを作成する

スレーブノードを作成する

ビルドを実行する

終わりに

Python の学習資料 - 3

追加内容

終わりに

Solr に Wikipedia のデータをインポートする

Wikipedia のデータをダウンロードして解凍する

Solr の設定ファイルを変更する

インポートする

マルチコアの設定

終わりに

Solr の trunk を使ってみる

ソースコードをチェックアウトする

ソースコードをビルドする

サンプルを動かしてみる

Jetty を使って起動する

管理画面を表示する

インデクスを追加する

検索してみる

おわりに

Haskell 環境の確認

現在のバージョンを確認する

実際に削除する

パッケージの一覧を表示する

追加パッケージをインストールする

インストールしてみる

終わりに

FC東京 - ACL2012 のカレンダー

Python の学習資料 - 2

追加内容

終わりに

2011年の振り返り

月々の出来事

世界の出来事

過去の記事

第７回 Solr 勉強会に行ってきた

発表とか

Solrベースの全文検索サーバFess

lucene-gosenの話

ApacheCon参加レポート

サフィックスアレイの話

P2P分散検索エンジン ORBISについて

終わりに

Python の学習資料

資料のアウトライン

そもそもの動機

Python を使う

終わりに

HTML5 の File API を使ってみる

form を作る

ファイルを処理する

ドラッグに対応する

終わりに

KML ファイルを作成する

CSV ファイルから KML に変換するスクリプト

KML ファイルのテンプレートを用意する

CSV ファイルを読み込む

ファイルにまとめる

アジャイルマニフェストディケイド

ロンウイット関口宏司さん