あーありがち

過去の日記 2012-12 2012-02 2012-01 2011-12 2011-11 2011-10 2011-09 2011-08 2011-07 2011-06 2011-05 2011-04 2011-03 2011-02 2011-01 2010-12 2010-11 2010-10 2010-09 2010-08 2010-07 2010-06 2010-05 2010-04 2010-03 2010-02 2010-01 2009-12 2009-11 2009-10 2009-09 2009-08 2009-07 2009-06 2009-05 2009-04 2009-03 2009-02 2009-01 2008-12 2008-11 2008-10 2008-09 2008-08 2008-07 2008-06 2008-05 2008-04 2008-03 2008-02 2008-01 2007-12 2007-11 2007-10 2007-09 2007-08 2007-07 2007-06 2007-05 2007-04 2007-03 2007-02 2007-01 2006-12 2006-11 2006-10 2006-09 2006-08 2006-07 2006-06 2006-05 2006-04 2006-03 2006-02 2006-01 2005-12 2005-11 2005-10 2005-09 2005-08 2005-07 2005-06 2005-05 2005-04 2005-03 2005-02 2005-01 2004-12 2004-11 2004-10 2004-09 2004-08 2004-07 2004-06 2004-05 2004-04 2004-03 2004-02 2004-01 2003-12 2003-11 2003-10 2003-09 2003-08 2003-07 2003-06 2003-05 2003-04 2003-03 2003-02 2003-01 2002-12 2002-11 2000-08

_ Rubyのプロジェクトの雛形 + gemの生成／公開にjewelerを使うようにしてみた

世界的にはマイナーでしたが、個人的には cutagem が大好きでした。

gemを作るとき、プロジェクトを作るときには結局何を使うと嬉しいのだろう

ですが cutagem は明らかに gemcutter.org というか rubygems.org 時代に対応する感じがなさそうです。そこでもう一度試してみました。

で、結果、jeweler にしてみました。

technicalpickles's jeweler at master - GitHub

試したもの

ruby-toolbox.com の上位3つ。

• jeweler
• bones
• newgem

だけ。

簡単な感想

jeweler

予想以上に多機能。テストツールやドキュメンテーションツールなどを雛形作成時に選べるので、rdoc + test/unit なプロジェクトも yard + rspec なプロジェクトも作れる。個人的には徐々に移行しようかと思っているのでこういうのは助かる。ただし、git + github + gemcutter.org に完全に依存していて、新しいプロジェクトを作るといきなり git init & commit までいってしまう。（rubyforge に上げることもできる。）

bones

Rakefile の中身がスカスカなのが気になる。きっと gem library の中にいろいろ記述されているんだろうけど、ちょっとここだけ修正したい、などには対応できなくなってしまう。また、テストは rspec しか考えてないっぽい。

newgem

Rails 寄りすぎて個人的にはあまり活用シーンがなさそう。

github-username をセットしておらず、jeweler でちょっとハマる

1年前の2009年10月には

InfoQ: RubyForgeは徐々に廃止され、RubyGems.orgがGemホスティングを引き継ぐ

ということで rubyforge.org は廃止の方向で話が進み始めています。他のコードホスティングサービス、github や google code の方が優れている機能を rubygems.org にわざわざ移植することはしないそうです。

その中で jeweler は git & github を標準としました。これを表すものとして

• github の username を要求し、
• いきなり git commit してしまう

という潔さに自分は感動しました。ただし一つハマったことがあって、それは

github の username が必要

な点。これには

1. jeweler --github-username USERNAME で指定する
2. ~/.gitconfig の github.user で指定する

の2つの方法があります。2 は

[github]
        username = USERNAME

という記述のことで、これは

git config --global github.user USERNAME

で指定することと一緒です。

もう2年以上 github を使っていながら github 用の設定を .gitconfig に用意していなかったので新しいプロジェクトを作ることができなくてしばらく悩んでしまいました。（というか、一回 jeweler に挫折しました。ちゃんとエラーメッセージ読んでなかった。）

でももう大丈夫。この間

crontabwrap | RubyGems.org | your community gem host

をリリースしてだいぶ感じをつかんだので、今後はこれでいこうかなと考えています。

[2010-10-09 追記]

https://rubygems.org/ にパッケージを上げると http://rubydoc.info/ に自動的にドキュメントが生成されるみたい。これはすごいなぁ。

_ ふと思い立ってPHPのmicro frameworkをちらっと見てみた（結論ナシ）

最近 Sinatra をベースに、みたいなのが増えてるっぽいのでこういうのは PHP ではどんな感じなんじゃろなぁというのが気になって調べてみた。

有名なのは

• Limonade - PHP micro-framework
• GluePHP - about
• zeroflux.org
• Tekuna.org – MVC Microframework for PHP

辺りなのかな？

で、ざっとコードを見てみたけど、

• Glue, phatso はさすがにシンプルすぎ
• Tekuna は XML の定義とかあったりどこが micro なのか理解できない
• バランス的には Limonade っぽいけどこいつはグローバルな関数と定数でゴリゴリ
  • プロダクトコードの見た目は確かに micro な感じなんだけど、ツクリ的にはまったく Sinatra inspired でもなんでもない

って感じで、例によってガッカリした感じ。

Limonade は中身に踏み込まずにプロダクト書くだけなら確かに手軽な感じだけど、ある程度拡張したくなったときにすごく邪魔くさいことにならないかなぁ。まぁなんか書いてみればいいんだろうけど。

これとは別に micro という謳い方ではなく Sinatra 風のものもあるので見てみると

• jim's fitzgerald at master - GitHub
  • これが比較的有名っぽい
• brucespang's Frank.php at master - GitHub
  • なぜか YAPC::Asia 会場辺りから流れて来た情報を追加

この辺？

でも Sinatra と違って Rack ( WSGI ) に載らないし、testability はやっぱあんまり高くなさそうな。結局 PHP のスーパーグローバル変数を直接参照したりしてるので、ブラウザでアクセスしてテスト、って形になりそう。

うーん。

うーん。

プロダクトコードが短くなるのは大事なんだけどさ。もう、それだけじゃないよね。

creationix's rack-php at master - GitHub

rack-php っていうプロジェクトはあるけど、Sinatra inspired な人たちは Rack にはあまり興味ないっぽいしなぁ。どうしたもんすかねぇ。

そういうの期待したかったら PHP なんか選んじゃダメってことなのかなぁ。

※ Limonade はなんか curl で request 飛ばす処理があるな。もしかすっとこれでテストできるのかも。

cf. Sinatra風PHP用フレームワークLimonadeによるWebアプリケーション作成 - なんとなくな Developer のメモ

_ むしろ最近 svn list を使う

最近、以前より svn list を使う。というのも

• git （自分用） + svn （共通）の二重管理
• git-svn を使ってない

git-svn を使わないのは

• svn のファイル全部を相手にしたくない

から。（あと、なんか妙に面倒そうだから。）

svn up しないと古いまま

ということで git ls-files と svn list とか、細々チェックしながら作業してるんだけど、add や remove を commit したあとの svn list が古いことに気づいた。

どうも svn commit するだけではなく、svn update して .svn/ の中身を新しくしないといけないらしい。なるほどな。

ディレクトリを除外

svn list を使って一部のファイルを操作する際、ディレクトリ名がそのまま出てきて具合悪い場合がある。そんなときは

svn list | awk '!/\/[^.]+$/'

みたいなことをやってパスの最後に拡張子が含まれていない場合はディレクトリと看做して除外、みたいなことをしている。

ただし、ドットなしファイル（README とか）を対象にしている場合はうまくいかない。

参考

以下を参考に git-svn を使ってみたけど、git の commit を svn の commit と同期しないという使い方は難しいっぽい。

• git-svnの使い方を覚えた - idesaku blog

_ fixdapで全部の通知が欲しい人は管理者にすべし

先日fixdapを使い始めたのだが、一部で期待していない動きがあったのでそのまとめ。

結論から言うと

fixdapのQ&A：タスクの通知メールは、いつ、誰に届きますか - livedoor ヘルプ

をちゃんと読んでなくて通知メールがいかなくてあれぇ？ってなってたって話。これを読むと通知メールは

• タスク作成者
• 管理者

にしか届かない。担当者が決まっていれば担当者にも通知が行くけど、担当未定でタスクを切りたい場合はもうこの通知メールはだいぶ使いにくいものになってしまう。*1ということは基本的には

プロジェクト、タスクの情報をつぶさに知っておきたい「管理者」は実際のプロジェクトの管理者と fixdap 上のプロジェクトの管理者を兼ねないとダメ

ってことらしい。言い換えると

プロジェクトの管理者だけど機械には強くないので fixdap プロジェクト上では管理者にはなりたくないという運用は不可能

ってこと。

うーむ。しかも管理者を複数置くことができない。まぁ fixdap プロジェクトの管理はシステムの管理っていうほどなものではないから、プロジェクトの管理者を素直に fixdap プロジェクトの管理者に置けばいいってことなんだろう。ある程度パソコンとブラウザに慣れていれば、別に機械が得意でなくてもなんとかなるっちゃなんとかなるし。

でもちょっと不親切な設計だね。

鍵付きのプロジェクトだと feed も取得できないし、コレ以外には方法ないんだろうなぁ。あとは管理者権限でメールを受け取ってばらまく bot を作るとか、外部での工夫以外にはたぶん手がない。でもそこまで手を掛けるならもっと本格的なプロジェクト管理ツールを使えって話だよね。

_ Git リポジトリの起源を知りたい

以前 jarp で

最初のcommit hash - jarp,

こんなことやってて、変なことやってるなぁと思ってしまったんだけど、

その必要性が分かってしまった

ので自分もやってみた。

というのも git には svn info 相当の情報がないので、今自分の使っているリポジトリが何かよく分からなくなってしまう。もちろん

git remote -v

とかやると origin を表示できたりするんだけど、自分の場合は

origin の同じ複数の git リポジトリを作ってしまう

ので、これだけだと情報量が足りないのだ。というのも

むしろ最近 svn list を使う

で触れたように、svn の中に（今回の編集とは）無関係なファイルが多すぎるので、別個に git リポジトリを作って作業を始めるようにして、不要になった git リポジトリを削除するようにしているんだけど、念のためこの git リポジトリは bundle ファイルを作ってバックアップを作ったりもするので、

同じ svn tree を起源に持つが作った時期も作業内容も違う git tree が複数できる

という、ちょっとどうだろうという状態になってしまう*1。そこで、commit log を見てみるも、すでに混乱したあとでは終盤の commit がよく似ていたりする。

そうだ。最初の commit を見れば違いがはっきりするはず。なんだけど、うっかり

git log -1 --reverse

すると最新の commit だけが出てきてしまう。つまり、-1 だけが有効になっている。正解は

git rev-list --all --reverse | head -1 | xargs git log

--all は jarp の記事では不要っぽいけど、試したリポジトリでは必要だったのでこんな感じにしてみた。

ついでに

alias git-info='git rev-list --all --reverse | head -1 | xargs git log --name-only'

こんなものを用意しておくといざってときに助かるかも、と思った。残念ながら .gitconfig の中ではパイプを使う処理は alias 登録できないみたい。

たぶん、フツーはこんなもの必要ない。

cf.

優しいgitの育て方 : info - ヽ( ・∀・)ノくまくまー - s21g

_ Thunderbird + Nostalgy環境でフォルダペインが不意に消える

気づいてみれば話はごく単純で。

Nostalgy :: Add-ons for Thunderbird

Nostalgy で L がフォルダペインのトグルに割り当てられていた。

Nostalgy のデフォルトショートカットキー

Nostalgy は Thunderbird をキーボードで使いやすくしてくれる便利な拡張。ちなみにデフォルトで以下のようなショートカットが割り当てられている。

なぜ L を押すのか

あとで気づいたけど、アサイチで

• Trac をブラウザで開く
• Thunderbird を立ち上げる

んだけど、ここで

Trac に Login しようとしてブラウザに L を送ったつもりで Thunderbird に入力してしまう

ことがあるらしい。

なぜ L を押すのかというと、

キーボード機能: Find As You Type

この機能を使っているから。Login のリンクをたどるのに L を押して Login にフォーカスを合わせて Enter を押すのが楽なわけ。

Nostalgy の L は殺すことにした

別にフォルダペインを消す必要がまったくないのでこの機能はなくてもいいや。

_ iPod touch 4thでボリュームの扱いが変わったのに気づいた

古い話ですが。

iPod touch を 2nd -> 4th に変えて地味に不便だなと思っていたのは

• 「通知音＆着信」と「本体ボリューム」が分離していること

だったんだけど、「設定」の「サウンド」にボタンでの変更を可能にするスイッチがあった…。デフォルトの動作が変わったのか。

_ 複数バージョンの LL を入れる話を集めてみた

理由はいろいろあると思いますが、ある言語の複数のバージョンを一つのシステム上で使い分けたい場合があります。そのためのツールと記事をただただ並べてみました。*1

※ ところで小規模、中規模案件で人気のありそうな PHP こそこういうツールが必要な気がするのですが、そういう話は聞かないですね。mod_php は PHP 単体で環境が完結しないので難しいのかもしれません。

PHP については phpfarm を使うと複数のバージョンを同一マシンに簡単にインストールできます。

cf. phpfarmを使って複数バージョンのPHPをインストール

ただし 2010-10-31 現在ではインストールできるだけで動的な切り替えなど気の利いた機能はありません。

比較表

意外なことに Perl, Python は複数バージョン入れるツール自身が元の言語で書かれています。Perl はシステム標準に入っているディストリビューションが多いからまだ分かるけど、Python でこの戦略を採用するのはちょっと大胆な気がします。

※ Python は virtualenv だけでも複数バージョンを切り替えて使うことができます。ただし、インストールや動的な切り替えまでは面倒みてくれません。そんなときに pythonbrew が便利なようです。

rvm

rvm の記事はもう書いてあります。

rvmを使ってREEへの移行を考える - あーありがち(2010-07-17)

Bundler

Bundler の記事ももう書いてあります。

Bundler 0.9.26 を触ってみた - あーありがち(2010-07-19)

perlbrew

• gugod's App-perlbrew at master - GitHub

• perlbrew + cpanminus + local::lib で環境構築 - Webtech Walker

perlbrew があれば perlbrew で切り替えて使う Perl のための lib はシステム標準のものとは分離しているので、local::lib はなくても大丈夫ということのようです。複数の lib 環境を使いたければたぶん local::lib はあった方が便利だと思います。その辺も rvm + Bundler 環境に似ているんじゃないでしょうか。

local::lib

root 権限が必要なく、アプリとライブラリをセットにして配布するといった用途にも使えるみたいです。

• local::lib - search.cpan.org

• local::libを使った非rootでのCPAN環境構築 - hide-k.net#blog
• Mac OS Xでもlocal::libをつかってCPANモジュールを入れよう - JPerl Advent Calendar 2009
• git + local::lib で CPAN モジュールを管理してみる - TokuLog 改メ tokuhirom’s blog
• local::lib を切り替える - unknownplace.org

cpanminus

これは完全に脱線です。2010年に開発の始まった新しいパッケージ管理ツールで、基本的には従来からある cpan, cpanplus の代わりになります。よりコンパクトに、つまり快適に動いて嬉しいらしいです。cpan-outdated と組み合わせたり、cpan に上がっていないパッケージをインストールしたりできるとか。*2

• cpanminus
• perlモジュールのinstallにcpanmを使う｜perl｜@OMAKASE
• cpanm - bayawiki

cpanminus は gihyo.jp のモダン Perl 連載で CPAN を取り上げた直後に開発が始まっていて、まだあまりまとまった日本語ドキュメントはないっぽいですね。

pythonbrew

perlbrew inspired.

• Pythonbrew | NINXIT-BLOG
• utahta's pythonbrew at master - GitHub

virtualenv

ずっと勘違いしていました。virtualenv は rvm と同じレイヤーの仕事はしていないんですね。

• rvm や perlbrew のようには処理系のインストールはしない
• インストール済みの処理系のうち、何をどこで使います、という環境構築ができる

ツール、と考えるとよいようです。rvm で特定のディレクトリに .rvmrc を置いたときのようなイメージでしょうか。

Python はもともと複数バージョンをシステムにインストールすることが特に面倒じゃないのかも。だとしたら virtualenv のアプローチだけで確かに十分かもしれません。

ただし easy_install は virtualenv を考慮してくれないので pip を使うとよい、という感じのようです。

• Python Package Index : virtualenv
• virtualenv ― virtualenv documentation
• virtualenv, virtualenvwrapper, pip を使う方法 - Ian Lewis

pip も試してみないといけないなぁ。

homebrew

これも完全に脱線。MacOSX の比較的コンパクトで最近評判のいいパッケージングシステム。Ruby製。ややこしい。

• Homebrew ― MacPorts driving you to drink? Try Homebrew!

_ PHPのAPI DOC生成にDoxygenも使うことにした

Doxygen

経緯

• 以前から一部のリポジトリで phpdoc がメモリ不足で落ちて困っていた
• Doxygen は何年か前にも試していたが、PHP の解釈がイマイチで採用を見送っていた
• 今回試してやはりイマイチだったが、いくつかの問題を我慢すれば使えそうだったので、メモリ不足で落ちるよりマシと判断して使い始めた

現在稼働しているバージョンは 1.5.6

動かせるようになるまで

最初は

• 落ちる
• 返ってこない

ファイルが後を絶たなかった。どうしたか。

EXCLUDE しまくる

まずはこれが基本。設定ファイルの中に EXCLUDE, EXCLUDE_PATTERNS の設定があるのでこれを利用してひたすら問題になるファイルを除外しまくる。話はそれから。

1. とりあえず EXCLUDE
2. 一つずつコメントやコードの構造を直して落ちないか試す

以上をくり返すことでほとんどのコードを扱えるようになる。

※ Warning はとりあえず無視しして徐々に対応していく。

やばげなパターン

if () {
  ...
}

でコード全体を囲んでいると doxygen が返ってこなくなりやすいみたい。

とは言え必ず返ってこないかというとそうではなく、コメントの書き方が正しくない場合に返ってこなくなる可能性が高い、という感じらしい。

コメントの書き方ミスにはとても厳しい

phpdoc と違ってかなり厳しい。少なくとも phpdoc 的には大きな問題でなくても Doxygen ではダメなケースは多い。ただし本当に問題になるのはやはり

正しくないコメント

なので、普段からちゃんと書けている場合はとりあえず移行そのものはそれほど大変ではないと思う。

対応してるタグは少ない

phpdoc に比べると対応するタグがだいぶ少ない。ただし、

• シンプルでよいと思うことにする
• ソースにリンクを張れるのである程度解釈が変でも直接読ませることでよしとする

で、乗り越えられる :-)

切り替えて使う

複数のプロジェクトのコードからドキュメントを自動生成する

で述べたように phpdoc の生成は自動化しているのだが、この中でドキュメント出力先は都度クリアしてから作業を始めている。このとき削除には

rm -r *

を使っているので、ドキュメント生成先に .doxyfile というファイルが用意されていたら doxygen で、そうでなければ従来通り phpdoc で処理することにした。*1

これで、全リポジトリで一気に Doxygen 対応をはかる必要がない。

よさげな設定

いろいろ試行錯誤した結果と default の diff を出してみた。たぶん Java っぽく振るのがいいんだと思ってるんだけど、どうなんだろう。

結果

• Doxygen の PHP 対応は今もやはりイマイチ
• メモリ不足で API DOC を生成できないリポジトリがなくなった
• API DOC 生成のスピードは10倍以上に跳ね上がった
  • API DOC 生成に使っているサーバの仕事を増やせる
• Windows 版もあるので、気軽に何回もドキュメント生成を試すことができる
  • ドキュメントの品質向上に繋がるかも

_ phpfarmを使って複数バージョンのPHPをインストール

先日 LL を複数入れる話をまとめて、なんで PHP にないんだよという話を書いたらツッコミをいただきました。その名も phpfarm なんと本家にありました^^;

• [svn] Index of /pear/ci/phpfarm/trunk
• Introducing phpfarm
• phpfarm - 複数のバージョンを同一マシンに簡単にインストールする - Do You PHP はてな

使い方

必要なものは

• フツーにコンパイルできる環境
• Subversion
• bash

です。以下のように使います。

$ svn co http://svn.php.net/repository/pear/ci/phpfarm/trunk/ phpfarm
$ cd phpfarm/src
$ ./compile.sh 入れたいバージョン

なんて簡単。

やってくれること

1. source の取得、展開、コンパイル
2. コンパイルオプションを設定する方法
   • 基本は options.sh で、バージョン毎に cutstom-options-{version}.sh を用意すればよい
3. 指定のディレクトリへの CLI SAPI バイナリへの link の集約
4. カスタム php.ini を準備する方法
   • 基本は custom-php.php で、同様に custom-php-{version}.ini を用意

やってくれないこと

rvm と違ってできないことがたくさんあります。

1. インストール可能なバージョンの確認
   • http://museum.php.net/php$vmajor/php-$version.tar.bz2 から取得してくるのでここで指定可能なバージョンがインストールできます。
2. インストール済みバイナリを切り替えて指定のバージョンを起動する
3. httpd.conf 周り

特に 3 が面倒になるかなぁという感じですね。

一応 CLI バイナリは一カ所に集まっているので SAPI によらず動かせるコードを書くようにしていれば、複数バージョンでのテストなどもなんとか動かせそうに思います。

Apache の mod_php については 複数の mod_php を LoadModule するのはできないような気がするので、仮想マシンを PHP の数だけ立てるような感じにするか、いちいち httpd.conf を書き換えて Apache を再起動する切り替えツールを自前で書くしかないんじゃないでしょうか。他の LL に比べるとだいぶ面倒な感じになりますね。

※ ちなみに自分が以前 PHP 4 から 5 への移行を行った際は複数のサーバを立てて NFS でコードを共有して*1 テストしました。その都度再起動しないのであれば OS 丸ごと増やすのが楽なのかなと思います。

入れ終わった様子

phpfarm ROOT
|-- inst
|   |-- bin
|   |   |-- php-4.4.9        -> ../inst/php-4.4.9/bin/php
|   |   |-- php-5.3.3        -> ../inst/php-5.3.3/bin/php
|   |   |-- php-cgi-5.3.3    -> ../inst/php-5.3.3/bin/php-cgi
|   |   |-- php-config-5.3.3 -> ../inst/php-5.3.3/bin/php-config
|   |   |-- phpize-5.3.3     -> ../inst/php-5.3.3/bin/phpize
|   |   `-- pyrus-5.3.3      -> ../inst/php-5.3.3/bin/pyrus
|   |-- php-4.4.9
|   |   |-- bin
|   |   |-- include
|   |   |-- lib
|   |   `-- man
|   `-- php-5.3.3
|       |-- bin
|       |-- include
|       |-- lib
|       |-- man
|       `-- pear
`-- src
    |-- bzips
    |-- php-4.4.9
    `-- php-5.3.3

これで、phpfarm の inst/bin に PATH が通っていれば一応複数バージョンを使い分けることができる道理です。

pear, pecl 周り

pear ついては make で入れる方法が提供されるような雰囲気のファイルが src/php-{version}/pear 以下にあるのですが、Makefile がないので機能しません。手で適当に go-pear で入れるのが正解のようです。

試しに上の状態で 4.4.9 用と 5.3.3 用に pear を入れてみましたが、4.4.9 は pear list を出すだけでなんかすごい量のエラーのような警告のようなメッセージが出て、5.3.3 は go-pear でのインストールの段階で大量の deprecated の警告が出ます。

なんというか、pear, pecl までこなれていないうえに、PHP の過渡期っぷりを感じてしまいます。5.1, 5.2 辺りでお茶を濁すならわざわざ自分でコンパイルしなくても各種ディストリビューションのバイナリパッケージ使った方が簡単ですしねぇ。うーん、どうしたものやら。

まとめ

クセがつかめれば、できることは制限されますが OS 丸ごと増やすよりはまだ楽かもしれません。とは言え今ある phpfarm の sh script だけだと不便なのは間違いないので、自分用のツールを書き足す工夫は必要かと思います。

自分の場合はやっぱり Ruby で phpfarm wrapper 作るべきなんでしょうかねぇ。