2007-02-05 [長年日記]
_ rsync は 2.5.6 以降 .svn を考慮する
rsync-2.5.6-NEWS(rsync.samba.org)
はずです。
2.5.6 以降であれば -C オプションをつければ Subversion の管理している .svn ディレクトリもスキップしてくれる。もしそれ以前のバージョンを使っているなら自前で除けてやらないといけない。つかイマドキ 2.5.6 以前が入ってるホストはちゃんと管理できてないか、やむを得ず古いバージョンのまま走らせているかどちらかなので、「ふつう」の人が当たる機会はあんまりないんじゃないかなぁ。
なんか以前 -C でイケるホストとイケないホストがあって、.cvsignore の違いかなーとか漠然と思っていたんだけど、いやーでもどっかで .svn に対応してるって読んだ気がするなーと思って調べてみた。
2007-02-06 [長年日記]
_ DOM で要素の絶対的な位置を計算してみる
※ 長さの割に内容はありません。先にあやまっておきますごめんなさい。
ことの発端はある部分のデータ量が多くてそこだけ縦に長くなっちゃってレイアウトが見苦しいので調整したいという要望だった。
んなもん紙じゃねーんだからバランス取ろうとする方がおかしいんだ
と思ったけれども、CSS（overflow: auto） + JavaScript（style.height をごにょごにょ）でなんとかなるかなーと思ってやってみた*1ら HTML の組み方によっては厳しいことが分かってきた。要は
旧石器時代に滅んだはずの table レイアウトってやつ
だ。あれは難しい。なぜなら table は内容全体に応じてセルの大きさが伸縮しちゃうからセルの大きさそのものは計算してもみんな同じなんだな、これが。中身がスカスカで見た目のバランスが崩れているかどうかは、セルの大きさを比較しても分からないわけ。
じゃあってんで内容の方に注目してその height を比較して調整すればいんじゃね？と思ったんだけど、デフォルトの margin なんかがあって意外とうまくいかない。マジックナンバーを投入するとなんとなくうまくいってるように見えるんだけど、ちょっと変更が入っただけで簡単に破綻してしまった。
じゃあ height じゃなくて注目している要素の bottom を比較できればいいんだなと思ったけれど、これをすんなり取得する方法は DOM にはないっぽい。offsetTop, offsetLeft てのはあるんだけどこれは親要素を原点としているので、ページレイアウト上の絶対位置は取得できない。
あれまーと思ったんだけどこういう方法で取得してみた。ある要素の上辺の、ページ内における絶対的な位置を取得する関数*2。
function top( obj ) {
var pos = 0;
if ( obj ) {
pos = obj.offsetTop;
if ( obj.offsetParent ) {
pos += top( obj.offsetParent );
}
}
return pos;
}
※ 横着してますが obj は DOM の HTMLElement オブジェクトが入ってきていると思ってください。
offsetTop が親要素に対する相対位置なのだから、てっぺんの要素まで再帰でさかのぼって行けばいいじゃんていう話。試したところ狙い通りの値が取れてるみたいなんだけど、なんかおかしいこと考えてるかもしれないんで、気づいた方はツッコんでください*3。一応 Opera 9, MacIE 5, WinIE 6/7, Safari 1.3, Firefox 1.5/2, iCab 3.0.2(build 382) で大丈夫みたい。つか今どきのフレームワークにはこういう機能すでにあるんかもしれんなぁ。
bottom の方は top + height を計算すればいいだけなので割愛。left, right も同じ要領なのでこれまた割愛。というかたぶん調整したいと言われるのは縦方向だけだと思う。
2007-02-07 [長年日記]
_ portupgrade を強引に pkg_delete して入れ直す
FreeBSDユーザは要注意!「ports-mgmt」設置、portupgradeはカテゴリ移動へ (MYCOMジャーナル)
ふーんと思いながら対処法も書かずに注意って言われたってねぇとぼやいていたんだけども、久しぶりに update をチェックしたらいっぱいあるなぁ。upgrade しようと思ったら /usr/ports/sysutils/portupgrade に cd できないと怒られる。えーなんでそんなことしようとしてんの？と思いながら make deinstall しようと思ったら /usr/ports/ports-mgmt/portupgrade なんてものはインストールしていないので削除できない。おうおう。そういうことか。
/var/db/pkg に降りて直接 portupgrade を pkg_delete して、改めて make install したら動いた。
まだなんか
missing key: categories
って怒られるんだが、これはどうやったら消せるんだろう？ あれ、一回動いたら出なくなった。んーじゃあまぁいいか。
だらだら書いたけど結局やったことは echo.dip.jp(2007-02-05) と同じ。
2007-02-09 [長年日記]
_ なんか Diigo がさらに使いにくくなったような
最近調子悪いなーと思っていたら v2 beta になった。機能が増えたりしたんだろうけど、ぱっと見で気づいたのは
- Social Annotation と名乗っているけど、これ前からだっけ？ なんかコンセプト変わった？
- 水色が増えた
- Google inspired か？
- 以前ボタンを CSS でリンクっぽく見せてるのは Mac のブラウザでひどいことになってるよと書いていたのは直った
- ブックマークした各記事の上にマウスカーソルがきたらアクションのメニューが表示されるという相変わらずワンクッション待たせる操作性*1。ただ、メニューを表示するために小さい more ボタンを一生懸命クリックする必要はなくなった。
- もともと低い一覧性がさらに低くなった
- 上で言う各記事に対するアクションメニューは mouseover で on/off するだけで「表示する場所は最初から確保されている」。つまりメニュー出っぱなしの状態となんら変わらない。で、そのメニューの分と、どのサイトをブックマークしたかの情報の分のスペースが邪魔。あとページタイトルがでかすぎて場所を取っている。
- 検索窓は右の方に行ってしまい、自分が普段使っているウィンドウサイズでは隠れてしまう。
なんだろうなぁ。この、印刷した時きれいに見えますよ的な余白の使い方をしてる感じ。
ということで例によって user css. 今回のポイントは
- 随所で px 指定されている font-size を全部いじるのは面倒なので、とりあえず各ブックマークアイテムについて、タイトルを 100%、それ以外を 80% にする
- 思い切って site filter（たぶん新機能）をカット
メニューボックスを一段下ではなくタグなどと同じ高さに。cache とか一部リンクが辿れないケースが出てくるがどうせ使わないので気にしない。これは思いとどまった。
こんな感じで。
@-moz-document domain("diigo.com") {
#logo {
z-index: 20 !important;
}
#siteNav {
position: relative !important;
margin-bottom: -20px !important;
}
.easySearchBox {
position: absolute !important;
top: 0 !important;
right: 0 !important;
float: none !important;
z-index: 10 !important;
background: none !important;
}
#mainNavOuter {
margin-right: auto !important;
}
#column {
position: relative !important;
margin-left: .25em !important;
margin-right: .25em !important;
}
#box {
width: auto !important;
}
h1 {
clear: both !important;
text-align: left !important;
margin-top: 0 !important;
margin-bottom: 0 !important;
line-height: 1em !important;
}
.bookmarkListHeader,
.bookmarkListFooter {
height: auto !important;
}
.bTabs {
float: none !important;
margin-top: -2px !important;
height: 24px;
}
.bTabs:after {
white-space: pre;
content: "\A";
visibility: hidden;
}
.sorter, .filter, .pagination, .bFooterOptions {
line-height: 1em !important;
}
.bFooterOptions {
height: auto !important;
}
h3.title {
font-size: medium !important;
width: auto !important;
margin-right: auto !important;
}
h4 {
font-size: 80% !important;
}
h4.tags a {
color: #5a9de1 !important;
}
h4.siteFilter {
display: none !important;
}
#leftColumn {
width: auto !important;
margin-right: 12em !important;
}
#rightColumn {
width: 12em !important;
position: absolute !important;
right: 0 !important;
top: 0 !important;
}
#user_tags_list,
#rel_tag_list {
width: auto !important;
}
#user_tags_list,
#friendList,
#groupList {
border: solid 1px #999999 !important;
margin-bottom: 1em !important;
}
div.DivInnerBox {
height: 30em !important;
}
.sideBarBox {
width: auto !important;
}
.sideBarBoxBorder {
background: none !important;
padding: .25em !important;
}
.sideBarBoxHeader {
background: none !important;
}
.sideBarBoxContent {
margin: 0 !important;
}
.sideBarBoxFooter {
background: none !important;
}
}
と思ったけど、
- 各所の width の px 指定を排除
- background の image も除去
- rightColumn と leftColumn のバランスも em で指定。leftColumn の width を auto に
- 先行する leftColumn の width が auto になった関係で float が効かなくなるので、 rightColumn を position: absolute によるレイアウトに変更
- 余白の分減ってしまう情報量がもったいないので全体に margin, padding をきつめに
- 検索窓も position: absolute にして z-index を上げることで、ウィンドウの幅を縮めてもナビ部分の高さが変わらず、かつ検索窓が隠れないように
- 検索窓の z-index を上げたらロゴに掛かったのでロゴの z-index をより高く
という具合にさらに変更を加えてちょっと大掛かりになってしまった。
全体に、自分が普段使わないものは隠れてしまっても構わない方針で作っているので普段使いには若干注意が必要かと思いますが、どうぞご自由に。
ちなみにユーザースタイルシートの作成には
- Firefox
- Firebug
- Stylish
を使っています。Firebug の Inspector で HTML 上の要素の特定を行い、その style を確認します。これを見ながら Stylish で書き換えを行っていきます。（Stylish は今回初めて使ったけどめっちゃ便利だわ。）
できあがったスタイルシートは常用ブラウザが Camino なので Stylish 上ではなく userContent.css にコピペして利用しています。
*1 こういうのは tiddlywiki とか、基本は読ませるけど編集もできますよ的なページなら有効な技だと思うけど、ブックマークはそういう使い方しないでしょ。
2007-02-12 [長年日記]
_ ports-mgmt/psearch なんてものがあるのか
Port description for ports-mgmt/psearch
Python を利用して ports の検索をしてくれるツール。カテゴリを限定したりできてなかなか便利かも。使い方は portsearch より簡単だと思う。出力フォーマットは apt 風というかそんな感じ。
ただなんかちょっと遅い気がする。元データを使ってるのかな？ オリジナルでインデックスを持つようにすると速くなるんだろうけど。
2007-02-13 [長年日記]
_ Pear のバージョンをおさらい
取り上げる人が少ないのかな。というか自分があまり真面目に追いかけていないだけか、肝心の情報を結構見落としてたりする。
- PEAR :: Innovating the future: Package.xml 1.0 and PEAR 1.3.6 are officially deprecated
- 2008年1月1日をもって 1.3.6 以前は廃止
- PEAR :: Package :: PEAR :: 1.5.0
- PHP 4.3.0 以降と（アップグレードの際には）PEAR インストーラ 1.4.3 以降が必要
- PEAR :: Package :: PEAR :: 1.4.11
- ここまでは PHP 4.2.0 で動く
- PEAR :: Package :: PEAR :: 1.4.0
- channel サポートはここから。
よく Pear の upgrade でエラーが出るんだけど、とりあえず 1.4.3 くらいに一度上げて、それから上げると。1.4.3 もエラーが出るならまたもうちょっと前のバージョンから上げると。そんな感じかな。
Pear コマンドはいっときミスで 4.2.0 で動かないときがあったけど、1.5.0 以降は公式に 4.3.0 以降を対象とする。個々のパッケージは現時点でも 4.3.0 以降に依存してるもの、4.2.0 でも動くものが混ざっている状態なんだけど、今度はタガが外れたのでどんどん 4.3.0 以降を対象とするようになるのかな。
2007-02-14 [長年日記]
_ PhpDocumentor の templatebase って効いてる？
プロジェクトの数がなんか知らない間に増えそうな予感がするので、phpdoc の生成を今までよりも高次元で自動化しようと思ったわけです*1が、この際、例によってこの子は iso-8859-1 しか喋る気のない大変困ったちゃんなわけです。
で、テンプレートの方に手を加えるんだよという話はあちこちで書かれているわけですが、
配布物に手を加えたらアップグレードのときに面倒くさそう
というのはある程度経験を積んだ方なら当然感じます。いやな予感がビンビンするところです。
幸い、phpdoc コマンドは -tb ( --templatebase ) というオプションで別な場所に置いてあるテンプレートを取り込むことができると書かれています。おぉこれは便利。早速これを使ってオリジナルのテンプレートを作っていこう…と思ったら効かねーよ！
当然階層違いとか間抜けなことは言いませんよ。Converters フォルダ、またその上のフォルダの phpDocumentor のフォルダから順にすべてのレベルのフォルダを templatebase で指定した場所に置いてみました。見事にすべて無視されます。
頭に来たのでソースを追いかけます。関係しそうなファイルは
- Converter.inc
- IntermediateParser.inc
- Io.inc
辺りですが、睨んだ場所に print を仕込んでもわざと間違った場所を指定して error_reporting を仕込んでも全然必要な情報が取れません。お前はいったいどこを通過してどのフォルダ、どのファイルを求めているの？
面倒くさくなったので*2他のテンプレートが置かれているのと同じフォルダ（今回は /usr/share/php/data/PhpDocumentor/phpDocumentor/Converters/HTML/frames/templates）に、そのまま *.i18n という名前で元のテンプレートフォルダをコピーして、そこでカスタマイズを始めました。やったことは iso-8859-1 を検索して削っていくだけ。
探すと同じような症状が
PEAR :: Bug #9250 :: --templatebase does not function as expected
にあるんだけど、再検証したっていう報告が結局上がっていない。あんまり使われてないのかなぁ。この辺の困った具合を除けばそれなりによくできたツールだと思うんだけども。
※ というわけで pdoc, jsdoc, rdoc, phpdoc 生成の自動化完成。phpdoc はテンプレートで、jsdoc は正規表現が再帰マッチするらしくメモリ不足で segmentation fault してハマりましたが、どうやら解決。ちくしょう意外と面倒だった。
2007-02-15 [長年日記]
_ 複数のプロジェクトのコードからドキュメントを自動生成する
昨日やっていたことを振り返りながら今日の日付で日記を書きます。
やってることは管理しているコード全体について、プロジェクトをまたいでドキュメントの生成を自動化する、というものです。
ドキュメント生成ツールの実行を自動化してこその自動生成
「ドキュメント 自動生成」などで検索すると phpdoc, rdoc などのツールについての紹介ページがたくさん引っかかります。しかしこれらのツールはコードからドキュメントとして使えるようにマークされた部分を引っこ抜いてきて HTML に整形する作業を自動化しているだけで、コード中にちゃんとドキュメントを書いておかないといけないという意味では別に自動生成でもなんでもないわけです*1。ただ、コードとドキュメントが物理的に分離していないため、それぞれのバージョンの食い違いが発生しにくいというとても大きなメリットがあることも事実で、だからこそこれらのツールを使うわけです*2。が、
どうせならツールの実行も全部自動化してこその自動生成じゃないのか？
と思いますわな。ということでやってる人は当然のようにやっているので表に出てきにくいんじゃないかなネタ第?弾。
前提条件
今回は以下の条件でドキュメントを生成します。しかし条件に合わなくても工夫すればなんとかなるかもしれません。
- WebDAV経由の Subversion リポジトリがあること
- Apache の設定をある程度自由に読み書きできること
- phpdoc, pdoc, jsdoc, rdoc など利用するドキュメント生成ツールのインストールや設定、起動を行えること
- cron, タスクスケジューラなどの設定方法が分かっていること
あと Apache 用語とか CVS 用語とか Subversion 用語とかが説明抜きにいきなり出てきますのでめげないでください。
目指す形
Web サーバ上のある位置に定期的に自動でドキュメントが生成される。
ドキュメントは Web ブラウザで読みます。
一応今回は Perl, Ruby, PHP, JavaScript に対応したツールを扱いますが、それ以外のツール（言語）でも同様に応用可能だと思います。
shスクリプトの例（Pdoc編）
ではいきなりですがスクリプトを晒します。これは pdoc の例です。
#! /bin/sh
umask 002
BASE=/dat/www/devel/apidoc/pdoc
SRC=$BASE/svn_co
SVN_LOG=$BASE/log/svn.log
cat /dev/null > $SVN_LOG
PDOC_LOG=$BASE/log/pdoc.log
cat /dev/null > $PDOC_LOG
cd $SRC
for proj in *
do
if [ -d $SRC/$proj ]; then
echo "= Project $proj ="
echo "= Project $proj =" >> $SVN_LOG 2>&1
cd $SRC/$proj
svn update >> $SVN_LOG
echo "= Project $proj =" >> $PDOC_LOG 2>&1
if [ ! -d $BASE/$proj ]; then
mkdir $BASE/$proj
fi
$BASE/perlmod2www.pl -skip .svn -source $SRC/$proj -target $BASE/$proj >> $PDOC_LOG 2>&1
fi
done
umask はあってもなくてもいいです。単に手元の作業の都合上の問題です。
何をやっているか？
- まず作業対象のディレクトリを指定します
- そこを基準に working copy を作成するディレクトリ
- およびログファイルを作成するディレクトリを決定します
- ログファイルをクリアします
- working copy を展開しているディレクトリに入って
- そこですべての中身をリストアップ
- ディレクトリだったらそれがプロジェクトだと判断してそこに入って svn update
- ドキュメント生成先がなかったらそれを作成して、
- HTML を生成する perlmod2www.pl に必要な引き数を与えて実行
- 7 に戻ってくり返す
ポイントは
- BASE の設定以外はすべて相対で設定してあるので、一カ所書き換えるだけでどこにでも置くことができる
- ディレクトリの中身を丸ごと対象にしているので、subversion で checkout するプロジェクト（CVS風に言えばモジュール）が増えたら生成されるドキュメントも自動で増える
- 処理対象はディレクトリのみなので、working copy を置くためのディレクトリにもメモ用のファイルなどは置いておける
- ドキュメント生成先のディレクトリが存在しない場合は勝手に作る
辺りでしょうか。できるだけメンテしなくても動くようにしたつもりですが、まだ甘いかもしれません。
ディレクトリ構成
ということで今回のサンプルのディレクトリ構成はこんな感じです。
DOCROOT |-- A_proj/ 生成された A_proj のドキュメント |-- log/ ログ（単なる動作確認用） |-- makepdoc* 呼び出すshスクリプト |-- perlmod2www.pl* pdoc スクリプト本体 |-- svn_co/ コードのチェックアウト先 | |-- A_proj/ A_proj の working copy | `-- W_proj/ W_proj の working copy `-- W_proj/ 生成された W_proj のドキュメント
※ 末尾の / はそれがディレクトリであることを、* は実行可能であることを表しています。
絶対に必要な作業として、svn_co/ ディレクトリの中に、ドキュメントを生成したいプロジェクトを svn co で作成しておくというものがあります。これが今回のキモというかほぼすべてです。
すぐに気づいたと思いますが、内部向けしか考えていないので割と大胆なことになっています。今回は
Web サーバで公開されている領域に working copy もログも生成されたドキュメントも全部置いちゃう
形にしてしまいました。これは、
- ログを落とす場所
- working copy を作成する場所
を
- ドキュメントを置く場所
と別に確保するのが面倒だったからに他なりません。考えるのが面倒でなければこのレイアウトにこだわる必要はまったくありません。
また、上の例を見るとプロジェクト名を proj_XXX という形に整えたくなるかもしれませんが、これはあくまで例示用の名前であって、proj が prefix になるか suffix になるかなんてことはまったく問題にならないのでお間違えなきよう。log とかチェックアウト先の場所と名前がかぶりさえしなければなんだっていいですし、たぶんその方がブラウザで見たときには自然でしょう。だってこの場合、
proj_XXX なんて名前でなくたって何らかのプロジェクトについてのドキュメントであることは自明
なんですから。
permission に注意
内部向けなのでなんだっていいっちゃなんだっていいんですが、
- ドキュメント生成のためのスクリプト
- （今回の例の場合は perlmod2www.pl）
に、Web サーバプロセスのユーザーでの実行権限があるとブラウザからドキュメントの自動生成ができます。便利なように見えなくもないですが、今回自分はそういうことが起きないように権限を分離しておきました。でないと誰かが閲覧中にいきなり裏でドキュメントの生成が走っちゃって、思いのほかサーバが重くなったりするかもしれないので。
ブラウザからいい感じに見えるようにWebサーバを設定する
すいません、問答無用で Apache でいきます。まず、ブラウザからドキュメントのリストが見えるように
+Options Indexes
します。
しかしこのままではブラウザで見たときにかっこ悪いなと思いませんか？ そこで
IndexIgnore log svn_co makepdoc perlmod2www.pl
と言った具合に見えてほしくないものを除外していきます。
ま、だいたいこんなもんでしょう。直アクセスすれば当然丸見えですが、細かいことは気にしちゃいけません。どうしても気になるならアクセス権限を制限すればいいんですけど、そういう人は素直に、見せたくないものは document root の外に置くようにした方がいいです。
他の言語の場合
RDoc編
RDoc の場合は以下を削除してください。
if [ ! -d $BASE/$proj ]; then
mkdir $BASE/$proj
fi
RDoc はドキュメント生成先に指定されたディレクトリが RDoc 自身の作成したディレクトリかどうかを判断できますので、勝手にディレクトリを作ってもその中にドキュメントは吐き出してくれません。
実際に rdoc コマンドを呼ぶところは
/usr/bin/rdoc -c eucj -o $BASE/$proj $SRC/$proj >> $RDOC_LOG 2>&1
こんな感じでしょうか。残念ながら charset を指定してやらないとできあがったドキュメントが文字化けしてしまうのですが、これは
- 判別用のファイルをリポジトリ内で決めておいて、それには明示的に svn:mime-type で charset を propset しておく（何語だ）
- rdoc を呼ぶ前に svn proplist -v からエンコーディングを取得して
- rdoc のオプションに与える
という処理を入れてやるのがよさげな気がします。1プロジェクト内でエンコーディングがぐちゃぐちゃに混ざってるなんてことはないでしょうから。
自分とこではまだそこまでやってないのでとりあえず決め打ちですけど。
rdoc のパスは環境に応じて適当に直してください。
PhpDocumentor編
phpdoc コマンドを呼ぶ部分が以下のような感じになるはずです。（バージョン 1.3 以降じゃないとこの書き方はできないかも。）
/usr/bin/phpdoc -pp on -o HTML:frames:DOM/default.i18n -ti $proj -d $SRC/$proj -t $BASE/$proj >> $PHPDOC_LOG 2>&1
これは自分が手を加えた（文字化けしないように iso-8859-1 を埋め込んである部分を片っ端から削った）テンプレートが default.i18n というディレクトリに置いてあるからこういう指定になっていますが、ここら辺は環境によって設定をいじってください。
phpdoc コマンドのオプションについては phpdoc -h とかマニュアルとか参照してください。phpdoc のパスは環境に応じて適当に直してください。
JSDoc編
これまでと同様、jsdoc コマンドの呼び出し部分を以下のような感じにします。
$BASE/JSDoc-1.10.1/jsdoc.pl -r -d $BASE/$proj $SRC/$proj >> $JSDOC_LOG 2>&1
これは BASE の中に JSDoc 一式を丸ごと放り込むという大胆な設定の場合なので、どこに置いたかに応じて書き換えて使ってください。
なぜ WebDAV経由の Subversion で update なのか
subversion を前提にしちゃってますが、これは以下の理由によります。
- 何らかのバージョン管理システムを使っている方がドキュメント生成用に最新のコードを準備する処理が楽ちんだから
- WebDAV 経由だと Apache の LimitExcept ディレクティブを使うことで、読み出しに関しては認証なしにする設定を簡単にできるから
- svn export の場合、.svn ディレクトリが作成されず、その working copy はどこのリポジトリと結びついているのかを sh スクリプト側で管理しないといけなくなるから
2 については別に認証なしにする必要はないのですが、認証ありの場合
- 認証情報をキャッシュしておかないと自動化できない
- 誰の認証情報をキャッシュさせる？
という問題が発生します。
誰でもええやんと思うかもしれないけど、仮に誰かのアカウントにした場合、この自動生成のシステムが、いなくなった人のアカウントで動き続けようとするケースが考えられます。今一生懸命やっている人がいつまでもいるとは限りませんので、できるだけアカウント情報は残したくありません。Subversion 管理用のアカウントにするという手もありますが、簡単に無認証にできるならそっちの方がいいかなと思いました。
また、WebDAV 経由にしておけばリポジトリの場所が移動しても rewrite や redirect などのサーバ側の設定だけで、クライアント側であるこのスクリプトを置く機械の方では何もしなくていいかもしれません。
3 については書いたまんまです。.svn ディレクトリが作成された方が楽なんです。どのディレクトリがどのリポジトリにアクセスしに行くのかがその中に保存されますので、あとは無造作に svn update するだけで最新の状態になりますし、プロジェクトが増えても svn co でディレクトリを増やしていくだけで sh スクリプトの方には修正を加える必要がなくなります。
Subversion などのリポジトリがない場合、例えばどこかから Windows の共有などを利用して丸ごとコード全体をコピーしてくる場合は、コピー元をスクリプト側、あるいは他のツールで管理する必要が出てきます。Subversion を利用する場合でも sh スクリプト以外のツールで管理していると言えば管理しているのですが、この情報はディレクトリを移動してもそのまま生きますし、何らかの設定ファイルなどを書く必要がないというところがポイントです。
逆に言えばこうした管理が苦でないなら、Subversion を利用していなくても自動化は可能です。（自分はやりたくないですが。）
個々のツールの注意点
PhpDocumentor
まずインストールの段階で結構メモリを食います。php-cli.ini で利用できるメモリを増やしておきましょう。
ドキュメント作成時にも実行時間、メモリの消費量とも大きいので、この設定はちょこちょこ見直す必要があるかもしれません。
Pdoc
インストールには make が必要です。どうにかして make を調達しましょう。Windows には入れたことないのでどうやるのかは分かりません。
JSDoc
HTML::Template が必要です。パッケージが用意されているならそれを、ないなら CPAN からインストールします。
メモリがちょっとでも厳しいと正規表現の再帰処理が深すぎるらしくて落ちることがあります。もしかすると最新の Perl にすればいいのかもしれませんが、多くの Linux ディストリビューションなどで Perl はベースシステムに食い込んでいておいそれとバージョンアップできなかったりします。
そこでスクリプトの設定の方を直します。具体的には
JSDoc.pm の
# Recursion limit for recursive regexes use constant RECURSION => 10;
ここです。これをとりあえず半分の 5 とかにすると割と動くと思います。
また、-extensions オプションがうまく動きません。これは jsdoc.pl の方を以下のように直します。
relname => $OPTIONS{NESTEDFILENAMING}
? substr($_, length($arg))
: (fileparse($_))[0]
- } if ((-f and -r and /.+\.$ext_re$/oi) &&
+ } if ((-f and -r and /.+\.($ext_re)$/oi) &&
(/^\Q$arg\E[^\/]+$/ || $OPTIONS{RECURSIVE}))
},
no_chdir => 1 }, $arg);
これで例えば
-extensions js,jsx
などのようにして InDesign 用の JavaScript を解析対象に入れることができるようになります。
あとは定期実行を設定するだけ
ここはお使いのシステムに応じて cron, タスクスケジューラなどの設定をしてください。
2007-02-17 [長年日記]
_ Exif って意外にメンドイ
※ そろそろこの「メンドイ」「面倒くさい」シリーズのタイトルも飽きてきたな。
singapore で Web アルバム作ってますよというか singapore 配下のディレクトリに写真のデータ放り込んでおく*1と楽でいいなという話は以前書いた通りなんだけども、メタデータ（metadata.ja.csv）の作成がやっぱり面倒くさい。
以前は写真を放り込んだディレクトリで emacs を開いて M-x shell から ls して写真の一覧を作成して、それでチマチマコピペしながら必要なフィールド数の分カンマを打ったり、適切なフィールドにデータを入力したりしてたんだけど、案の定激しく面倒くさい。
ということでコッソリと、指定ディレクトリ内の JPEG ファイルの Exif データを読み取って、設定ファイルに従って singapore 用の csv ファイルを作成するツールを作ってみていた。動くようになってからおぉ割と便利だこれは、と気づくまで時間は掛からなかったんだけど、今回は作る段階で以下の点にハマった。
exif を読み取る ruby 用のライブラリがあんまり充実してない
どうせなら露出補正の値がほしいと思った*2んだけど、なんかあんまりみんなそこまで踏み込んでくれない。個人的にはコマンドラインでも使いやすく、情報量の豊富な exiv2 が気に入ってるんだけど、libexiv2-ruby は FreeBSD 上でうまく gem install できなかった。
ぼくちんバインディングの作成なんてできないので諦めて今回は exiv2 の実行バイナリを叩くことにした。うーんかっこ悪いけどしゃあないか。サーバは速くなったことだし、いつも動かすものではないので負荷も気にしないこととする。
カメラによって入ってるタグが違う
なんか独自タグがあるぞ…。どこの業界もこういう標準フォーマットってある程度までしか守られないんだよな。まったくもう。
あと似たような意味の値が2つあることに気がついた。
| タグ | 意味 | タグ | 意味 |
| ExposureTime | 露光時間 | FNumber | F値 |
| ShutterSpeedValue | シャッタスピード | ApertureValue | 絞り値 |
どうもそれぞれ下の値の方が正確っぽい。上の値は代表的な値に丸められてしまっているらしい。
が。手元の Nikon のカメラの場合は ShutterSpeedValue は存在しない代わりに ExposureTime の方に中途半端な値が入っている。これはたぶん他の機種の ShutterSpeedValue に相当してるんじゃないかろうか？ うーむ、ということは下の値を優先的に取得するようにして、なかったら上の値を取る、っつー動きにしないといかんのか。対応した。
sort オプションの存在に気づく
なんつーか、今までお前は何をしていたんだという感じだけど、singapore.ini にギャラリー（フォルダに相当）のソート、写真のソートについての設定項目を発見！ そうか、なんか今までファイル名の順番でしか写真が一覧できなくて不便だなと思っていた（複数台のカメラがある場合にちゃんと時系列に並んでくれない）んだけど、ちゃんと設定項目あるんだね。
あ、そうかこれは date フィールドの値を読み取ってソートするオプションなのか。こんなの手で入力するなんて狂気の沙汰だからファイル名のソートに設定していたのかもしんない。ということはツールで自動作成するようにした今はちゃんと時系列表示にできるではないか！ 設定変更、リロード！ おぉ！ ちゃんと時系列に出てくるじゃん！
さて、metadata.ja.csv の方にもうちょっと詳細なデータを記入…しようと思ったらこっちはファイル名の順番のままだから singapore 上の順番と完全に食い違っちゃって編集しにくい。
うぇ。ということは metadata.ja.csv を作成する段階でも日時順とかでソートする機能があった方がいいんだな…。うーん。できなくはないんだが、ちょっと面倒くさくなってきたな。また今度考えよう。
できた。というか実はソートの機能は一度付けたけど singapore 上で効果がなかったので殺しておいたのだった。ちゃんと使えるように optparse とかあれこれ調整しておしまい。ついでに reverse sort もできるようにしておいた。
2007-02-24 [長年日記]
_ sh づいている日々
高級なスクリプトでも当然書けるんだけど、例えばあるパターンで行を処理してごにょごにょ、とかって処理は結構 awk と組み合わせて sh スクリプトで書いた方がやりやすかったりする。で、ちょっと最近凝った sh スクリプトを書くようになってハマったのが
- 引数のチェック
- エラーの意味がよく分からん
の辺り。
1 については getopt と case の組み合わせをマスターしないと面倒くさくなりそうなんで、これが今後の課題。*1
2 については xtrace を使ったり verbose にするとよいらしい。つまり起動時に -xv をつける。ただしこれはオリジナル sh のマニュアルがないと気づきにくい。
特に bash のマニュアルはあんまりよくない。bash のマニュアルしか手元にないようなら、set コマンドのところを見る。-o option-name のところに same as -x と書いてあれば、それはコマンドラインオプションの -x と同じだよという意味になっているんだけど、コマンドラインオプションの説明なんか端折りまくりじゃないか。
zsh の場合は man zshoptions の sh/ksh emulation set に書かれている。これはまだ分かりやすい。
というかオリジナルの sh のマニュアルくらい用意しておいてくれよ。
というわけで最近物色していた shell 関係の本は以下の通り。
プロフェショナルシェルプログラミング (Ascii software science―Programming paradigm)(砂原 秀樹)- ASCII の プロフェショナル・シェルプログラミング のページも参考まで。昔からものすごく気になっていたもの。今の自分なら csh についての説明は要らないし、基本的な部分の説明も要らないんだけど、安いしコンパクトだし、名前に反して入門向けとしていいと思う。もし後輩が買おうかどうしようか迷ってるんですと言ってきたら間違いなく薦める。昔のこういう ASCII の本は大好きだ。あ、自分の手元には たのしいUNIX―UNIXへの招待 (Ascii books)(坂本 文)、続・たのしいUNIX―シェルへの招待 (Ascii books)(坂本 文) があるんで、スクリプトだけじゃなくてシェル上の操作も含めて基本からっていう話ならこれ貸すかな。
入門UNIXシェルプログラミング―シェルの基礎から学ぶUNIXの世界(ブルース ブリン)- とても詳しいし、イチからきっちり勉強したいんですっていう人にはオススメ。上の -xv オプションも書かれている。というかこれ、前の版から絶賛されているらしいのでここに挙げるのは今さらか。
- 詳解 シェルスクリプト(Arnold Robbins/Nelson H. F. Beebe)
- 一冊置いてあると絶対安心できると思う。移植性の辺りは他にあまり扱ってる本がないので重宝するかと。
- Bash Quick Reference(Arnold Robbins)
- コンパクトにまとまっていてかつ素人が素人向けに書いた Web 上の情報よりはるかに使えると思う。日本で書き下ろされた小さい本よりさらに安い（はずだ）し。なんかいま日本の Amazon には在庫ないし思いっきり bash って書いてあるけど。
*1 例えば $2 が存在しているかどうかはいきなり [ $2 ] って書いてもうまく判別できないみたい。しかも標準状態ではエラーメッセージの意味がよく分からない。
2007-02-28 [長年日記]
_ ansi8 + M-x customize で emacs22 への準備
やっと M-x customize で色の設定の仕方が分かった。つかまぁ今まで例によって放置だったんだけど。
M-x customize で Faces → Font Lock → Font Lock Highlighting Faces にある。ちゃんとメニューを探して設定していけば .emacs に値が保存されるので安心。よしよし。ちょっと設定がいっぱいあるとめげるけど、まぁ見たままだし、基本的にすぐに反映されるし。
あと起動時のオプションで --color=ansi8 にすると ANSI の 8色だけで使える。つまり、
Emacs 22 を Terminal.app でも安心して使える
わけ。なんか 256 色にしたい人が世の中には意外といるみたいだけど、おらぁそんなものには興味ねーだ。Unicode と svn への対応がよくなって、起動が速いってだけで十分です。
※ ansi8 のビビッドな色で十分満足できるのは OSX + Terminal + 背景色白っていう組み合わせのせいなのかもしれないけど。putty + 背景色黒のときは見にくかったし。（結局 putty でも黒文字白背景にしてた。*1）
*1 Terminal も他のウィンドウと同じ設定の方が目が疲れなくていいと思う。まぁ、自分も SVGA とかの大昔の時代には暗めのブルーを背景にして白文字で使ってたけど、これはこの組み合わせの方が文字が大きく見えて視認性がよく、かつ真っ黒の背景より目が疲れなかったから。今はこんなノウハウ要らないよね。
_ の [古典ですが、こちらもおすすめです。 http://flex.ee.uec.ac.jp/texi/sh/sh.html..]
_ wtnabe [なるほどありがとうございます。オリジナルっていうのは bourne shell くらいの意味でして、手元では一応 F..]