すいません、目新しい話はないです。単に自分の経験不足と忘却力過多です。

結論

• 大半の SQL DBMS には Boolean は存在せず、int の 0/1 で代用するケースが多い
• 文字列 t/f も同じように機能する場合が多い
• Boolean を持っているプログラミング言語と同じ感覚で true/false を書くとそのままの文字列が入って、どっちも true に見えたりする

以下ちょっと試したり調べた結果。

ということで自作の rails console 用 ModelDumper は boolean を 't'/'f' で返すようにしてみた。

A model dumper for rails console ( Rails 3 or later ) and .irbrc for rails env — Gist

感想

なんでこんなこと書いてるかというと、一つには

Rails でも fixture の部分は ActiveRecord などを通さない

という部分をなんとなくにしか理解していなかった、というのが理由。

1. rake db:seed で seed data を ActiveRecord から読み込むツールを用意して、確認用のデータは全部ここから突っ込んでいた
   • 当然 Ruby の boolean がそのまま使える
2. 同じ seed が使えるとは限らないのは分かっていたつもりだったので ModelDumper も書いたのだけど、まだ理解が浅かった

というコンボ。

けっこう時間を浪費してしまった…。

cf.

import seed data from .csv or .yml for Rails 2.3.4+ — Gist

Python-FIT 1回目。

会場

今回は

• 福井（自宅） x 2
• 石川（KIT） x 1

の変則的な形に。

目的

Python 初心者も少なくないということで Python チュートリアルの読み合わせを進める感じで、かつオンライン勉強会の方法を模索する。

結果

よかった

• Skypeのグループチャットは Twitter と違って長いコードを貼ることができて、かつみんなが同じコードを見れる。

本当は全部 Twitter でまかなえた方が個人的には楽なんだけど、いきすぎた Twitter 脳は何も考えていないのと同じだね。

イマイチ

• KIT で 3G回線の確保は易しくない
  • 学外の人間は自由に学内のネットワークには参加できない。今どき当然。
• Skype のグループチャットはともかく、音声と特に Kogomi を使った画面共有はネットワーク品質に依存する
• オンライン勉強会の進行はネットワーク品質に引っ張られる
• 複数人参加する会場の音声もそれなりに気を使う
  • マイク、スピーカーがちゃんとしてないと意味が分からない

個人的には

• チュートリアルは買って読んだ方が楽

ということに気づいた。

内容

あんま進展がなかったとは言え、いきなり脱線して

RubyからScalaに乗り換えた15くらいの理由 - ヽ( ・∀・)ノくまくまー(2010-04-26)

に Python を入れようとしていた。面白かったけど、ちょっと時間掛けすぎたかも。

interactive shell

python の interactive shell で補完する方法がしばらく分からず難儀した。あちこちさまよって見つけた

import readline
import rlcompleter
readline.parse_and_bind("tab: complete")

を実行してなんとかなった。でも毎回こんなもん実行したくないから irb で言う ~/.irbrc に相当するファイルに書いて自動実行すればいいんだよね、と思ったらそういうファイルは存在しないことが分かってがっかり。どうも

PYTHONSTARTUP

という環境変数で明示的にファイル名を与えないとダメなようだ。いやいやいや。指定して実現できるのは正しいと思うけど、より便利なデフォルトを考えようとは思わない文化なのかな？

その後

デスクトップ丸ごと共有できる必要はないし、ぶっちゃけ Python の interactive shell だけ共有できればいいよね、という話をしていた。サイト上で interactive shell が動くサイトあるよね、きっと。あるある。そんなんでいいんだよね。でも Web だと同じセッションを共有することはできないね。

で、帰ってきてあれこれ探していてやっと思い出したのが以下。

ttyだけ共有できればいいんじゃ？

Partty!.org

これなら Terminal の様子だけ共有¹できる。

これで必要な会場分セッションを作って、それをブラウザのタブで開いておいて、必要に応じて各自が切り替えながら参照するという形でいいんじゃなかろうか。これなら HTTP さえ開いていればいいはずだし、十分軽いような気がする。

まだ次回これでいくと決まったわけじゃないけど、有力な候補とは言える気がする。Skype チャットでコードや結果は共有できてもやっぱ（ほぼ）リアルタイムで動く様子を共有したいじゃない。

音声はやっぱ Skype ?

あとは音声で、これは個人的に感じている問題が二つ。

1. 個人でカフェとかで勉強会に参加するのは周りに気を使う
2. ネットワーク的に P2P を制限している会場からは勉強会に参加できない

ただ、音声なしでチャットベースだとこれはこれで進行的にはちょっとしんどい。進行用に Ust で音声だけ流すってのもアリなのかもしれないけど、何か大げさな感じがするし、帯域的な問題もあるような気がする。

ネットワークの問題は上の Partty! の作者の音声チャット用のツールもあるんだけど、1 の方はいかんともしがたい。一人の場合は PC 使わないで iPod touch に新しいコード繋いだらいいかな？

ちょっと今度実験してみよう。bluetooth ヘッドセットも1年前の半額くらいだな。安くなったもんだ。

久しぶりに何か書いたか思ったら diff を貼り付けただけというテイタラク。

2005年にも一回やってる んだけど、git と gist を使って 1.4.7_notb バージョンを出してみる。相変わらず PukiWiki 関係は一つのブロックがものすごくでかくて追うのがつらい。

特に変わったところはないんだけど、なんか行番号が合わずにどこに何を入れたか考えるのが面倒になったのでロジックだけ頭に思い出してコピペしてしまった。

これで一応リリースされた PukiWiki の最新バージョンには追いついたので PHP を 5 に上げられる。

そのうち DokuWiki 辺りにするのがよいのかねぇ。最近 Wiki で熱い人を見かけなくなったので分からなくなってしまった。

もう 21 日に長いの書いちゃったから久しぶりに未来日記書いちゃうぞメソッド発動。

404 Blog Not Found:そろそろPHPに関して一言いっとくか

細かく言ってみよう。つかまぁ、自分も PHP マスターではないのでそこら辺のツッコミも希望しつつ。

全部 cofigure でビルド？

No. phpize がある 4.3.0 以降は個別にインストールできる。

ただし、できるだけ。

PHP には pear, pecl という便利なリポジトリ＆管理ツールがあるが、phpize はその範疇になく、どの拡張モジュールを入れたのかの管理はできない。はず。

Perl や Ruby では Pear と違って pure Perl, pure Ruby 以外のライブラリも多く、そこら辺で格安 or 無料レンサバ使いの人には不評だが、逆に言うと拡張モジュールもライブラリも一元的に管理できる便利さがある。PHP では Pear が pure PHP を守ってくれるというメリットはあるが、逆に拡張モジュールの管理はできない。（全部 pecl に入ってればいいのにね。）

php.ini で on/off できるのとはまた別な話ね。言うなれば Apache モジュールのようなものなんだよな、これ。ビルド済みのものでなければ .conf で on/off できない。結局全部まとめてビルドしてないと不便、ということになってしまう。このスクリプトのときだけこのモジュールが欲しい、てな要求にはもう対応不能。

最初に設定しちゃえば似たようなスクリプトを書く際にいちいち気を使わなくていいって意味では php.ini 方式は楽なんだけど、PHP のコードでそれを制御できないのはやっぱ面白くないと感じる場合もあるな。

<?php はウザイ ？

同感。

否定する気まったくなし。というか、いまどきはテンプレートを使って V とそれ以外を分離するので実は <?php なんて記法必要ないし。

すっげー簡単な確認用のスクリプト以外では最近では <?php は不要です。オプションかなんかで、書かなくていいようにできるとすごい嬉しい。

妙な約束事が多いのは Perl も一緒

prefix とか 1文字、2文字の特殊変数とか微妙な構文レベルの呪文になってしまってる分、見た目や理解しやすさは Perl の方がきつい。

ただし、細かい関数の違いという意味では PHP の方がきつい。似たような関数が大量にあり、バッドノウハウの塊と化しているのは間違いない¹。そして充実しているはずのマニュアルにそのノウハウは還元されていない。

例えば Perl や Ruby では obosolete なメソッドなどが必ず出てくるのだが、PHP はなぜか全部平等に扱われたままである。そんなわけないやろ、とツッコミたくなる。

余談だが、PHP はマニュアルが充実してしまっている分、動かして確認している人が少ない感じがする。動かして確認していればあり得ない嘘を再生産しているサイトが多いなぁという印象。

PHP 4 と 5 の違い < Perl 5 と 6 の違い

つかまぁ、Perl 6 は pugs であってもいじったことはないので知らないのが正直なところですが、ちらっと文法を眺めた限りでは Perl 6 を持ち出してまで叩くほどの違いはないと思う。

Perl 4 〜 5 の時代も経験しているのでそれと比較すれば、ドッコイドッコイか、少し PHP 4 から 5 の移行の方がヘビー。ってくらい。ただし Perl 4 から 5 への移行と同じく、メリットがかなり多い。

MVC の V しか書けない？

そんなわけないが、面倒くさい。バックエンドは Ruby で書きたくなる。

結局のところ、関数一発で書けない処理は書きにくいのだ、PHP は。Pear があるって言っても、あまり感嘆するようなライブラリはなかったりする。いやテメーで書けと言われたらシンドイからヤダって言うけど、なんつーかこう、他の言語では「なんて超絶すげーライブラリなんだ！」と思うようなものがあるのに、PHP ではそういう感動を覚えることがほとんどないのね。

自分でライブラリを書き始めると、Perl って自由だなぁ、とうらやまくしくなることもあります。マジな話。

まとめというか

フレームワーク全盛の今、PHP のメリットはけっこう薄れてきていると言える。以前 違いは作業環境的な面だと思うんだな で書いたときに比べると

• フロントコントローラ方式なら実行ビットの必要なファイルは 1つだけなので、そこら辺がルーズでもよいと言う PHP のメリットはなくなる
• ブラウザ上で back trace できるのは素の PHP の何倍も便利

てな感じ。

ただ。

フレームワークを日曜大工スクリプトに応用しちゃうと基本的に重たくなる一方だし、アクセラレータがない環境ではそんなに嬉しくないだろうことを思うと、手軽に使ってサクサクと動的なページを高級 SSI 程度の感覚で作って行く分にはやはり PHP 最強だなと思う²。

プロが仕事の道具として使うには微妙なところがいくつもあるんだろうけど、そこら辺も Debian のようにバージョンを fix したうえでパッチを提供してくれるディストリビューションを使う、あるいはそういうサービスを使うという選択肢も当然あるわけで、プラスして IDE でコード品質の統一をはかりやすいという部分もやはり大きいかなと。Zend もeclipse も頑張っているわけだから、その成果を使えばよいのではないかと。

ただそういうプロダクト頼みっていうところがなんとなくオープンソース万歳、フリーソフト万歳な他の LL と違うっていう感じはする。なんというか言語そのものというよりは文化の違いと言うか。例えば PHP が好きになれない人はたぶん VB も好きになれない人だと思う（自分はそう）んだけど、それって結局「お仕着せのツールを使ってる分には楽」っていう、制限された堕落さにあるんじゃないかという気がしている。工夫の余地がないというか、ハッカー的においしくないというか。

Perl で Perl を、Ruby で Ruby を、JavaScript で JavaScript を拡張できる、書きやすくできるってのはやはりものすごく「オレってばスゲー感」が前面に出てるわけ。その快感をあまり PHP から得ることはできない、という感じはする。

ただ。

同じ「使わなきゃいけない状況」になるのであれば、絶対に Perl より PHP の方がいいな。自分が書き手の場合は。力量を図るためにあえて求人のメインストリームから外れた言語を使わせる場合は「Perl + CPAN モジュール + コーディングスタイル」よりは Ruby か Python にすると思う。コーディングスタイルまで含めるなら Python がいいのかねぇ。書いたことないけど。

しかし元記事のコメント欄、釣れてるなぁ。

複数の辞書を一つのツールでいっぺんに検索できるのは便利なので Jamming を買ってみた。（Win/Mac 両方。）これで EPWING も英辞郎もみんな扱える。 ¹で、英辞郎 94 のデータを Jamming 形式に変換してみた。

結果、

• インデックスがないと遅くて使いものにならない
• 専用とは言え、英辞郎ビューア²はテキストデータの検索なのにかなり速くてステキ

てなことが分かった。

しかしこの変換が曲者で、

• OSX版では変換、インデックス作成とも正常に完了する。
• しかしこのインデックスは Mac 専用なので Windows では使えない。
• それではと Windows版の JammingDicTools を使うが、変換はできてもインデックスの生成ではメモリを食いつぶして終了してしまう。

つまり現時点では Windows では Jamming で英辞郎データは使いものにならない。

開発ツールがタコなのか OS がタコなのかツクリがアレなのか分からないけど、とりあえず報告しとこう。

ついでに昔話をすると、JPEG や PNG の画像に直接コメントを埋め込むタイプのアルバムソフトってないかなーと思っていた。自分の必要な機能からいくと、その方法にしてくれれば余計なメタデータは一切ないので、画像データを自由に移動できるうえに検索性を損なわない、と思っていたけどそんなことしたら個人的なメモが外にバラまかれる可能性があるじゃん、ということにずいぶん経ってから気がついた。

当時そんなソフトがあったら喜んでプライバシーを漏らしまくっていたに違いない。ま、他人に渡せる写真に関してだけだけど。

実はファイルシステムがメタデータを抱え込むだけでコメント検索はできる。

MacOS にはファイルにコメントを埋め込む機能があるので実は昔からこれは可能だった。似たようなことは WinFS でも可能になるだろうから、ますます Windows か Mac 使ってるなら何も用意しなくていいよ、という状況になってきている。

しかしそうなるとサーバに画像放り込んでおきたい、となったときには Windows か MacOS をサーバにしなくちゃならなくなる。特定の OS に縛られるのは好きじゃないのでこれは避けたい。Web ベースにしたいのに特定の OS に縛られるなんてばかばかしいじゃん¹。

singapore 0.9.11 のディレクトリ構造の一部を抜粋するとこんな風になっている。

.
|-- data
|     ここに cache/ を作る
|-- docs
|   |-- Development.html
|-- galleries
|     ここに画像の入ったディレクトリを放り込む
|-- includes
|-- install
|-- locale
|-- singapore.ini
|-- templates
|   |-- admin_default
|   `-- default
`-- tools

最低限必要なことは、galleries/ の中に画像の入ったディレクトリを放り込むだけ。

各種設定

• data/ の中に cache/ を作っておかないとサムネイルがキャッシュされないので激しく重い
• singapore.ini で全体の設定
  • 0.9.11 では日本語リソースは最初から入っているので default_language = "ja" にするだけで日本語化完了
• 見た目は template で行う。tDiary と同じように templates/ 内に使いたい template のディレクトリを放り込み、singapore.ini で default_template を変えれば ok¹
• template ごとに template.ini で細かい調整が可能。サムネイルのサイズや一覧するときの画像の数など
• メタデータは画像ディレクトリ内の `metadata.言語コード.csv' ファイルで行うか、ファイル名に埋め込む。
  • csv でメタデータを記述するときのフォーマットはドキュメントの Development 参照。

singapore の足りないところ

singapore には当初の目的のはずだったコメントで検索するという機能がない。でもまぁ、csv にメタデータを書けることが分かったので、とりあえず自分の用途では grep すれば ok という状態に。Web のインターフェイスを付けるのもそんなに面倒じゃないと思う（検索結果が template にハマる調整するのが面倒か）ので、その辺はおいおい考えることにする。

もう一つ、画像を縮小して表示する設定にしておくと、元画像をダウンロードすることができないのは惜しい。今どきの元画像の大きさじゃページのバランスを崩すだけだし縮小表示は当然だと思うけど、そこから元画像へのリンクがほしかった。まぁ初期設定では galleries/ は Web に公開されてる場所にあるのでそのまま直打ちして取り出すことはできるし、自分用ならサーバから直接取り出せばいいって話ではあるいんだけど。

というわけで sourceforge.net で web と photo をキーワードにして検索。いっぱい出てくるので気長にいく。試したソフトと簡単なメモを以下に順番通りに。テストは OS X と FreeBSD で行ったが、この手のツールはほとんどが PHP + GD で動いていて、OS X の PHP がどういう build になってるのか分かっていないのでほとんどは FreeBSD の ports で入れた PHP 4.3.11 でテスト。

slooze

• 画像のサムネイルは生成されているみたいなんだけど、うまくそれが表示されないんですが？
• なんか Roll とか Topic とか細かい言葉の意味がよく分からない

作者とセンスが合わないらしい。

mig

• short_open_tag が On じゃないと動かない
• albums/ ディレクトリ作成
  • 写真のディレクトリをその中に放り込む
• ImageMagick 必要
• mkGallery.pl も手作業。

PHP は確かに 3 以降で動くかもしれんけど、Perl も ImageMagick も必要だし、なんか手作業が多くてどうも。short_open_tag も微妙に気持ち悪いし。

yapig

とりあえず動いたけど、国際化の部分がよく分からないのと、ギャラリーの編集がよく分からないなぁ。

phpgraphy

まったく動く気配なし。検証する気も起きない。

yappa-ng

動かないなぁ？

spgm

動くんだけど、thumbnail 周りが動かない？ てか thumbnail 作成機能ないの？

gallery

ちょっと大げさな感じがするのでスルー。

singapore

いちばん簡単で確実に動き、なおかつきれいかも。

写真は好きだがデジカメはそんなに好きじゃないので、手元にデジタルの画像はあまりない。¹だから画像の整理も日付（と場所）の入ったディレクトリを掘ってそこに突っ込むだけ。とりあえず ViX とか Graphic Converter とか xnView とか使って縦横を揃える、簡単な補正を GIMP や Photoshop などで加える²と言ったことはするけど、いわゆるアルバムソフトの類いは使ったことがなかった。ただこの方法に不満がないわけじゃなかった。

画像にコメントを加えてそれで検索できたら便利なのに

ということだけ。ま、それだけじゃアルバムソフトの選択のポイントにならないので、以下に自分の条件を洗い出してみた。

背景

1. 自分の撮った写真を整理できればそれでいい
   • 例えば誰だか知らない人の写真を自分が管理するようなことはまったく想定していない。例えばネットで画像を集めるようなこともまったく考えてない。
2. これまでの画像の整理は日付と場所を名前にしたディレクトリを掘るだけ
   • 作品としてのアルバムを作るソフトがほしいわけじゃなくて、単にフォルダ単位で画像が放り込めて、それが一覧できれば ok

ほしい機能

1. Web で閲覧できる
   • 家族や組織内で情報を共有しようと思ったら重要だし、サーバに置く方がバックアップとか考えるのが楽
2. 画像の詰まったディレクトリを所定の場所に置くだけでよい
   • DB にインポートとか余計な作業が必要ないもの。従前の自分の写真の管理方法とのギャップがいちばん少ないものが嬉しい。
3. 画像にコメントを加えることができる
   • これをキーに検索できればなおよし。

ほしくない機能

1. コメントの付加やアルバムの追加などの作業が Web インターフェイスでしか行えない
   • Web インターフェイスはたるいので細かい作業はやりたくない。クライアント PC で作業して、できあがったディレクトリをサーバに転送するだけ、という感じがよい。
2. rating とか閲覧者からのコメント付加
   • photolog やりたいわけじゃないし、やるとしてもその前段階としてまず自分の写真の整理が必要でしょ。そのためのツールなので対ユーザを意識した機能は不要。
3. DB を要求する
   • すべての画像に対して詳細にデータをセットしてあって、そこからズバッと検索するという用途には DB は向いていると思うけど、普通、ほしい情報って「いつどこで何を撮った」くらいでしょ？ DB なんか要らないって。スペックマニアが「このレンズで撮った写真はどれだっけ」なんて検索をする可能性を考慮してくれる必要はまったくない。³

SVG を読み込む

• Dia でも SVG は読み込めるが、Sodipodi の作った SVG は満足な状態にはならなかった。（namespace があってもなくても）
• Inkscape は Sodipodi の SVG をきれいに読める。ただし日本語フォントが入っているとアウト。
• Illustrator で SVG が読めるのは 10 から。

E?PS 出力

• ImageMagick, GraphicsMagick は SVG, EPS の読み書きができるが、どう頑張ってもラスタライズしてしまう。ベクトルのまま出力することは不可能。
• Inkscape は日本語フォントさえなければ SVG ⇔ EPS 変換ツールとして使える。
• Sodipodi の直接印刷で PS を吐き出すことはできる。ただしこれは EPS ではないので Dia では読み込めない。また、フォントはアウトラインになる。したがって日本語が入っていても問題はないが、文字として編集することはできなくなる。
• つーか Dia の吐き出すファイルは SVG も EPS もめちゃくちゃです。（Kivio の方がいいのか？）

• PS → EPS 出力は GSview で楽勝。

SVG 出力

• GSView はライセンスキーが必要。
• pstoedit の Windows 版は GraphicsMagick の DLL を要求してきた。セットしたけどなんかうまくいかんかった。

つーことで SVG → PS → EPS はできたが、EPS → SVG がまだできてません。ま、素材の SVG 化が可能なことだけは確か。

SVG 作成

Sodipodi は完成度は高い方だが使い勝手がいいとはちょっと言えない。そこでやはり Dia との連携をもう少し考える。

Dia の吐いたファイルを直接開いた画面では大きさ、太さなどがおかしなことになるが、Sodipodi 上で別な書類にコピペするとなんとなく元の雰囲気を維持できそうな感じ。（今度は逆に小さすぎる感じはするが。）細かい調整は面倒だろうが、うまくすればフリーツールだけでインスピ

• Illustrator に近い環境にはなりそう。各オブジェクトのいつもの大きさなど、オレ定義をしっかりさせる必要があるな。（これもバッドノウハウと言えばバッドノウハウなのかな。）

2ch にスレがあった。

これによると ai, pdf の解釈に GSview を使っている模様。

確かに GSview も Adobe Reader も入ってない環境では PDF, AI は表示できず、EPS は表示できた。（PowerPoint が入っていなくても PowerPoint ファイル内の画像は表示できた。）

Adobe Reader が入っていてもそれを利用することはできなかった。単に関連付けで Adobe Reader が立ち上がっただけ。

そういうことか。。。

考えたら GSview って軽いし PDF 読むだけならかなりいいんだな。