2005-05-01 [長年日記]
_ 散髪とお買い物
初めての床屋*1へ。なんというか、店は古くないんだけど、ちょっと懐かしいというか、今まで行ったことのある店より確実に男くさい店だ。漫画用に背の高い本棚が入っていてそのラインナップがエロ系はないにしても確実に男くさい。うちは予約取らないから、という店主の言葉が妙に男気に溢れている。
おばちゃんが担当してくれたんだけど、シャンプーのとき痛かったのも、きっと男気と力が溢れていたからだろう。そこさえ除けば、それなりにいい店だと思う。
次いで初めての「青山」へ。Yシャツがかなり古くなってきていたので3枚、ネクタイはちょっと今までと違う色がほしくて2本。「これはほしい」と思うやつはどこで買ってもそんなに安くないのはなぜだろう。
ついでに会員にならんかと薦められる。近いので入っておこうと思ったらこれがすごく面倒で細かい情報を取られた挙げ句、拇印で捺印。うげーと思ったらクレジットカードにもなるのか。うーん、ちょっと機能がありすぎるぞ。ただの会員カードじゃないじゃん。
あと、個人情報の取り扱いについて、申し込んだあとに書面を渡されたけど、これは事前に提示した方がよいですよ > 青山さん（知っててそのまま書いちゃったオレもオレだけど）
ついで UNIQLO でキースへリングTシャツ。MATSUYA で靴下。そんな感じ。
まだ紐解いていなかった荷物を少し出す。
録画しておいた「まる得マガジン『収納のコツ』」を見て、あちこちのサイズを測り始める。OmniGraffle でメモを書き、PNG に吐き出して携帯にメールして、買い物のときに参考にするぞ作戦。結構きれいに見える。しかし手間なのでこれはちまちま行こう。
*1 美容院には行かねーよ
2005-05-02 [長年日記]
_ 冷房器具調べ
思うところあって冷房器具を調べる。
冷風機なるものがあるらしいことを知るが、最終的には湿度が上がるか気温が上がるかのどちらからしい。そりゃまぁそうだよなぁ。電気もガスもそのままでは冷却能力はないんだから、どうにかしてある空間の熱や湿度を奪ってそれを別な場所に逃がさなきゃならない。じゃーどこへ逃がすって話に行き着く。部屋の中に逃がしたら元の木阿弥以下の可能性は十分にある。
体感温度を下げることは十分に可能だろうけど、それは直接風を受けることが可能な場合に限られると考えて間違いはなさそう。では風を受けることがそもそも身体に触る場合はどうだろう？ 暖房は温風を出さないタイプがあるけど、冷房はそういうのはさすがに無理なのかな。
なんて、別に大げさな話じゃなくて単にフェレット向けの冷房を考えてただけなんだけど。うーむ。経済的で健康的な冷房ってのは案外難しいな。
_ 大人も勉強しろとは思うが、
うーん。正答率91%(8/11)。 悔しいなぁ。
まだやってない人のためにどれが何とかは書かないけど、日本の入試とか免許の試験とかを受け慣れてると裏読みしてハマる可能性アリとだけ書いておきます。スパッといきましょう。
しかしこの手の基準を文部科学省が言うのはどうかなぁ。旧文部省じゃなくて旧科学技術庁が言ってるのかな。あ、これも裏読みか。
_ HHK Lite2 げと
なんかキーボードを買ってばかりのような気がするが、うち用に HHK Lite2 JP PS/2 黒を入手。予想通りちょっと音がでかい*1が、それ以外はそれほど不満はない。さすがにこの値段で細かいタッチに注文をつけるのは酷ってもの。サイズと値段とまともな配列を考えると十分にお値打ち品である。*2
しかし金沢はこれ1本手に入れるだけなのにちょっと苦労しますぞ。いいのか、こんなことで。置いてるキーボードのほとんどは Microsoft, Logicool を除くと Elecom はじめ安めのラインナップばかり。そもそもまともな配列のコンパクトキーボードがほぼ皆無。（変則配列*3の USB のものは割とよく見る。）いかんなぁ。まーまともなコンパクトキーボードってみんな高めだから、売れにくいってのはあるだろうけど、こうして店頭にモノがないという状況は完全に悪循環にハマッてるよね。以前は 100満ボルトにも置いてあったのになくなってしまった。パーツの品揃えは増えたのにキーボードが減るとは何事か。
_ FreeStyle Wiki こんな感じかな
accesskey だけでなくついでに title もつけてみた。
lib/Wiki.pm
319a320,321
> my $title = shift;
> my $access = shift;
330c332,344
< push(@{$self->{"menu"}},{name=>$name,href=>$href,weight=>$weight});
---
> if ( $title !~ /^$/ ) {
> $title = ' title="'.$title.'"';
> }
> if ( $access =~ /^[0-9a-zA-Z\/.,]$/ ) {
> $access = ' accesskey="'.$access.'"';
> } else {
> undef( $access );
> }
> push(@{$self->{"menu"}},{name=>$name,
> href=>$href,
> weight=>$weight,
> title=>$title,
> accesskey=>$access});
accesskey に使える文字は正規表現にあるように制限したけど、これは手元の Firefox で適当に確認しただけなので、間違ってる可能性あり。まーでも普通は英数字以外使わないでしょ。
tmpl/header.tmpl
7c7
< <a href="<!--TMPL_VAR NAME="href"-->"><!--TMPL_VAR ESCAPE="HTML" NAME="name"--></a>
---
> <a href="<!--TMPL_VAR NAME="href"-->"<!--TMPL_VAR NAME="title"-->
<!--TMPL_VAR NAME="accesskey"-->><!--TMPL_VAR ESCAPE="HTML" NAME="name"--></a>
途中で改行入れましたが。
あとは plugin/*/Install.pm とかにある
$wiki->add_menu("編集" ,"",997);
を
$wiki->add_menu("編集" ,"",997,"このページを編集[e]","e");
こんな風に直す。使い方は
add_menu( リンクテキスト, href, weight, title, accesskey)
で、title も accesskey も任意。設定しない場合は当然 HTML 上には現れない。（これは HTML::Template の機能。）
title はともかく、accesskey は管理画面で有効にするかどうか選べた方がいいんだろうなぁ。
2005-05-09 [長年日記]
_ 説得スキル
多国語で書けるブログはどこ？ブログ124サービス【文字コード】全チェック
たださんは（内心は知らないけど）煽り*1に対して真正面から論理的に反論していて、さすがだなぁと思うわけだけど、この記事については
煽りで問題が解決するとでも思っていたのだろうか？
というのがものすごく疑問。あり得ないと思うんだけど。問題点と傾向を明確にするという意味では今回の調査はそんなに悪くないと思うんだけど、なぜ全体の体裁は煽りなのかな。中には感情的に反応しちゃう人が当然出てきて、余計に話を進めにくくなると思うんだけどなぁ。
まぁ多言語対応で煽りを入れることができるくらいには、「多言語対応していないが完成度の高いアプリ」が多くなったという風に解釈することもできるんだけど、逆に多言語対応してても機能的に有用でなければ使われることはないんだしね。そういう意味では「ずいぶんと乱暴な話をするな」という印象はやっぱり拭えない。開発者は閉鎖的な us-ascii オンリーなアプリをあれこれ苦心しながら使っていたりするんだから。
では今回はどういう話に持っていくのがいいんだろう？ それはずばり、
私が自分を含め多言語対応のテスターを募って協力します
ではなかろうか。細かい理由はいろいろあると思うけど、多言語対応は明らかに開発のコストを上げるのだし、いくらかでも協力してくれる人の意見はかなりツールに反映されやすいと思う。
*1 まぁこの煽りもどこまで本気なのか分からないけど。
2005-05-10 [長年日記]
_ FAT32 で外付け HDD を確保
iMovie で遊んでいたら HDD の容量が厳しくなってきたので USB2/IEEE1394 両対応のケースを買って外付け HDD を用意した。NAS にしなかったのは電気をケチるため。NAS だとどうしてもつけっぱなしにしたくなるので。
クロスプラットフォームで使えるように FAT32 でフォーマット、、、しようと思ったら Windows 2000 以降の標準フォーマッタでは 32GB 以上のサイズを FAT32 でフォーマットできないとな。MacOSX の DiskUtility でも HDD に対しては FAT32 でのフォーマットは行えない。まぁこの辺は Windows98 でフォーマットするなりツールを探すなり Linux でするなりすれば済むので割愛。OS X の fdisk でフォーマットできるかどうかは試していないので悪しからず。
ただしフォーマット済みの FAT32 の1パーティションの BigDrive を、やはりノーマルの Windows 2000 SP4 で認識できない。これはレジストリの書き換えで回避可能であった。XP は SP2 以降なら安全に何も考えずに利用できるらしい。
参考
HDD買い替え大作戦テンプレの「(・∀・)突き破れ！！ 137GB(128GB)の壁(・∀・)」以降
2005-05-12 [長年日記]
_ Wiki と tDiary テーマは合わないんじゃないか
tDiary テーマに対する不満
tDiary テーマはたくさんあって便利だけど、扱いにくいなぁと思うことがよくある。いちばん感じるのは短いページの場合、やたらと下に空白ができてかっこ悪いということだけど、それに次ぐのは「tDiary ではユーザーに対するナビゲーションと管理者向けのアクションに区別がない」という点である。これらはすべて adminmenu という HTML class の中に入ってしまう。しかし横一列*1にすべてのメニューが並んでいて、果たして使いやすいだろうか？
Wiki で tDiary テーマを採用するとメニューが窮屈では？
まぁ tDiary の場合は編集系のメニューはほとんどなく、全部 adminmenu 扱いでも別にいいかなと思う程度なのだけれど、これが Wiki になると話は別である。圧倒的多数の ROM に対して編集系のメニューを絶えず表示し続けるのはいかがなものか？ もちろんフラットに表示することで Wiki のオープンさを表明することはできると思う。メニューを分けないことで誰もがこのコンテンツを編集できるということを明示する効果はひょっとしたらあるかもしれない。しかし使いやすいとは言えないと思う。
例えば閲覧の利便性から言えば検索窓は常に分かりやすい場所にあってほしい。sidebar に plugin などで表示するのもアリっちゃアリだけど、そういうよく使いそうな機能こそ上にきててほしくない？ というか tDiary テーマ互換でないサイトの場合は右上の方に検索窓があるのは割とフツーなので、やっぱりその辺に配置したくなる。しかし Wiki の多彩なメニューをひとまとめに表示している場合は、検索窓はでかすぎて扱いにくい。だからかどうかは知らないけど、多くの Wiki では検索するために
- 検索のメニューをたどる
- 検索窓だけのページを表示してキーワードを入力する
という2アクションを要求する。個人的にはこれはとてもいやだ。
もちろん使い勝手はその Wiki の性格（コンテンツ）にもよるので一概には言えないかもしれない。ならばどれだけカスタマイズしやすいかということもまた重要なのではないだろうか。
tDiary テーマ互換とデザインのカスタマイズ
具体的なカスタマイズの話をすると、PukiWiki はあまり凝った作りをしていなので skin に該当する PHP のファイルを力任せにいじっていけばどんなデザインや機能もまず実現可能である。例えば標準状態では一直線に並んでいるメニューを Firefox まとめサイトのように分離してしまうことも、作業そのものはホネだが、技術的にはそう難しくない話である。（むしろデザインの力と HTML と PHP が複雑な if 文を挟んで混在する skin ファイルをきちんと調整する根性が必要。）
しかし tDiary テーマ互換の場合はそうはいかない。あまり HTML の構造に手を加えてしまうと、200もあるテーマから選べるというメリットが消えてしまう。それに新しい HTML の class を追加して adminmenu と navigation を分離することはできるかもしれないが、アプリの方で adminmenu が一つしかないことを前提に作り込まれていれば、その修正作業量はかなりのものになってしまうだろう。
今まさに FreeStyle Wiki に accesskey を付ける、という作業でメニューのカスタマイズについて考えている。PukiWiki の場合はメニューは全部 skin に集約されているので、skin をどれだけカスタマイズしても本体には影響せず、アップデートへの追従もしやすい。しかし FreeStyle Wiki ではメニューの構成は本体の方に入っているのでカスタマイズしてしまうとアップデートしにくくなる。そこでうまい具合に本家に取り込んでもらおうとしているんだけど、そもそも tDiary テーマ互換の場合はメニューのカスタマイズの自由度ってそんなに高くないんだよなということを改めて思っている次第。
便利なんだけどね、tDiary テーマって。でも Wiki に向いているとは思えないんだよな。HTML 的にも class="day" とか入っておかしなことになっちゃうし。tDiary テーマ互換を謳わずに、ある程度有名で、なおかつ今のうちなら skin のカスタマイズが容易な PukiWiki 当たりで Wiki 向けの共通テンプレートが作れたら面白くなるんじゃないかなぁ。
PukiWiki はなぜ table レイアウトなのか
ただ PukiWiki は標準の skin が table レイアウトだから、その辺で CSS によるデザインがやりにくいと思われているのかもしれない。これは歴史的な経緯によるもので、CSS によるマルチカラムデザインに対応していない Netscape 4 などのブラウザでも MenuBar（tDiary で言う sidebar）がちゃんと表示されるようにという配慮からくるものである。当時 Reimy 氏は苦渋の決断と言っていたように記憶している。なぜ MenuBar にこだわったのかは記憶にないが、Wiki の場合は、特にページ数が増え、内容が多岐に渡った Wiki の場合は MenuBar があった方が確かに便利だなとは思う。そこでマルチカラムデザインを守るために table を採用したというわけだ。これなら w3m でも使い勝手が大きく変わらないし、実際使ってみて便利だなと思う。
しかしそれも含めて再検討してもよいんじゃないかと個人的には思っている。PukiWiki 1.4 以降は UA ごとに skin を細かく切り替えられるので、tty 用ブラウザは table レイアウトで、グラフィカルなブラウザの場合は CSS レイアウト、という具合に分けるのもアリだし、今さら Netscape 4 のことを考える必要は、少なくとも非商用プロダクトの場合はないと思う。*2
まぁいちばんの問題は、例によって「じゃあお前が叩き台作れよ」と言われてもちゃんと作り上げる気力が自分にはないってことか。作るだけじゃなくて結構な量の議論をこなさないと標準的なテンプレートに育てることはできないしねぇ。
2005-05-16 [長年日記]
_ ちょっと体調回復
先週、どうにもだるくて、なんか血が足りないような気がしたので週末もおとなしく過ごしていたんだけど、そう言えば春から初夏に掛けて貧血っぽい症状が出てくることが多いような気がしないでもないなぁ。*1実際は血圧計ったり比重計ったりしてないので貧血かどうかも分かっていないんだけど、こういうときは「とりあえず無理せずとっとと寝る」方針で過ごすことにしている。もともと無理の効く方じゃないし。
貧血っぽいのはひょっとして姿勢が悪かったのが原因かとも思い、今日、机の足回りを少し片付けた。（一時的なつもりで荷物が置いてあったので絶えず身体をひねる体勢になっていた。）
別に吐き気があったりするわけじゃないけど、身体が重いと気持ちも重くなる。防げるもんなら防ぎたい。しかし！
によると、食後のコーヒーは鉄分の吸収を妨げるとな。うぐぐ…。
*1 と思い、この日記を検索してみたけどそれっぽい記述は見当たらず。
2005-05-17 [長年日記]
_ scp って帯域制限できるようになってたんだ
によると 3.6 から -l オプションで指定することができるようになったと。実際使うときは単位が kbits/s なので注意すること。
2005-05-18 [長年日記]
_ Apple RemoteDesktop Client で VNC
Mac OS XにVNCサーバーを入れたいときはARD2.1 Clientをインストールすれば良い
を見て「うぉっ」と思って試してみたんだけど、Ultr@VNC とは相性があまりよろしくないような。Ultr@VNC Viewer の方で AUTO で繋いじゃうと画面の初期化ができない。接続スピードとか設定とかいじれば見れる状態にはなるんだけど、マウスカーソルが出てこない。
いずれも制御はできるんだけど。
まぁあんまり真面目に検証してないし、そもそも組み合わせ的に
Ultr@VNC Viewer → Apple Remotedesktop Client
という接続はほぼあり得ないので、自分とこでは全然困らないんだけど。
2005-05-20 [長年日記]
_ Wiki のファイル添付機能に XSS 脆弱性
- 複数のWikiクローンのファイル添付機能にXSSな脆弱性 (/.-j)
- Wiki クローンにおけるクロスサイトスクリプティングの脆弱性 (JVN#465742E4)
なんかどうも分かりにくいんだけど、要するに「ブラウザ上でスクリプトが実行可能なファイルをそのまま開けてしまう形でファイルを添付できること」が問題なわけですな。*1
例えば HTML が添付してあって、その添付ファイルへのリンクをクリックしたときに、ダウンロードではなくそのまま表示できるようになっている。もちろんいちいちダウンロードして開き直すよりその方が便利なんだけど、じゃあその HTML に悪意のコードが埋め込んであったらどないすんねん、ちゅーこと。対策としては
- ブラウザにファイルのダウンロードを強要する
ということになる*2んだけど、これが
- まともな実装のブラウザに対しては Content-Type で plain/text（これもやばいと思う）とか application/octet-stream を返すことで対処
- IE に対しては拡張子のつけかえ（Content-Type なんか見てないから）、と思ったら拡張子も見ていない場合があったので本当に根本的な解決策はあるんだかないんだか？
ということになるわけだ。副作用としては
- 画像をインラインで展開してくれないと添付機能のうまみが半減しないか？
- PDF とかもインラインで展開してほしいなぁ
なーんてことを思うと、
- ファイル添付機能の利用ユーザーを制限する
という、「運用で回避」な方法がいちばん現実的なのかなぁという気もする。でも今度は Wiki の良さを spoil しちゃうのね。
spoil ついでに、これが本格的な CMS なら添付そのものは誰でも ok にして、添付されたファイルはとりあえず保留にする。（公開しない。）で、特権ユーザーの手で安全性が確認されたら有効にする、なんて方法もありか。高機能な Wiki はますます CMS としての機能が増えていくってことかなぁ。
あるいは Wiki にそのファイルが安全かどうかをチェックする機能を埋め込むって手もなくはないのかな。添付したときにファイルをチェックする。重たそうだし、どこまでチェックできるのかはよく分かってないけど。
ところで IE 7 は Content-Type 周りの挙動は修正されるんですかね？
ちなみに PukiWiki では
とりあえずファイル添付を管理者だけに制限するのがよさげか。LAN 内のものは放置でいいとして、インターネット上で公開しててみんなで使っているところではかなり不便そうだ。
_ KB の RSS と複数の RSS の一本化
を見て「おぉこれはスバラシイ」と思ったんだけど、ぶっちゃけほしいものだけピックアップしてもかなりの数のフィードになるので、これを一つ一つ確認なんかしてらんない。
ということで、ほしい RSS を登録してったら全部フラットに1本のフィードとしてチェックできるものがほしいなと思ったんだけど、Bloglines ってそういう目的に使えるんですか？（> 誰）
とりあえず Bloglines デビューしてみるか。実はまだ使ったことがないのだな。
2005-05-22 [長年日記]
_ Web ベースのアルバムソフトがほしくなった
写真は好きだがデジカメはそんなに好きじゃないので、手元にデジタルの画像はあまりない。*1だから画像の整理も日付（と場所）の入ったディレクトリを掘ってそこに突っ込むだけ。とりあえず ViX とか Graphic Converter とか xnView とか使って縦横を揃える、簡単な補正を GIMP や Photoshop などで加える*2と言ったことはするけど、いわゆるアルバムソフトの類いは使ったことがなかった。ただこの方法に不満がないわけじゃなかった。
画像にコメントを加えてそれで検索できたら便利なのに
ということだけ。ま、それだけじゃアルバムソフトの選択のポイントにならないので、以下に自分の条件を洗い出してみた。
背景
- 自分の撮った写真を整理できればそれでいい
- 例えば誰だか知らない人の写真を自分が管理するようなことはまったく想定していない。例えばネットで画像を集めるようなこともまったく考えてない。
- これまでの画像の整理は日付と場所を名前にしたディレクトリを掘るだけ
- 作品としてのアルバムを作るソフトがほしいわけじゃなくて、単にフォルダ単位で画像が放り込めて、それが一覧できれば ok
ほしい機能
- Web で閲覧できる
- 家族や組織内で情報を共有しようと思ったら重要だし、サーバに置く方がバックアップとか考えるのが楽
- 画像の詰まったディレクトリを所定の場所に置くだけでよい
- DB にインポートとか余計な作業が必要ないもの。従前の自分の写真の管理方法とのギャップがいちばん少ないものが嬉しい。
- 画像にコメントを加えることができる
- これをキーに検索できればなおよし。
ほしくない機能
- コメントの付加やアルバムの追加などの作業が Web インターフェイスでしか行えない
- Web インターフェイスはたるいので細かい作業はやりたくない。クライアント PC で作業して、できあがったディレクトリをサーバに転送するだけ、という感じがよい。
- rating とか閲覧者からのコメント付加
- photolog やりたいわけじゃないし、やるとしてもその前段階としてまず自分の写真の整理が必要でしょ。そのためのツールなので対ユーザを意識した機能は不要。
- DB を要求する
- すべての画像に対して詳細にデータをセットしてあって、そこからズバッと検索するという用途には DB は向いていると思うけど、普通、ほしい情報って「いつどこで何を撮った」くらいでしょ？ DB なんか要らないって。スペックマニアが「このレンズで撮った写真はどれだっけ」なんて検索をする可能性を考慮してくれる必要はまったくない。*3
_ singapore に決まった
というわけで 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
いちばん簡単で確実に動き、なおかつきれいかも。
_ singapore を使う
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*4
- template ごとに template.ini で細かい調整が可能。サムネイルのサイズや一覧するときの画像の数など
- メタデータは画像ディレクトリ内の `metadata.言語コード.csv' ファイルで行うか、ファイル名に埋め込む。
- csv でメタデータを記述するときのフォーマットはドキュメントの Development 参照。
singapore の足りないところ
singapore には当初の目的のはずだったコメントで検索するという機能がない。でもまぁ、csv にメタデータを書けることが分かったので、とりあえず自分の用途では grep すれば ok という状態に。Web のインターフェイスを付けるのもそんなに面倒じゃないと思う（検索結果が template にハマる調整するのが面倒か）ので、その辺はおいおい考えることにする。
もう一つ、画像を縮小して表示する設定にしておくと、元画像をダウンロードすることができないのは惜しい。今どきの元画像の大きさじゃページのバランスを崩すだけだし縮小表示は当然だと思うけど、そこから元画像へのリンクがほしかった。まぁ初期設定では galleries/ は Web に公開されてる場所にあるのでそのまま直打ちして取り出すことはできるし、自分用ならサーバから直接取り出せばいいって話ではあるいんだけど。
_ 余談その1
実はファイルシステムがメタデータを抱え込むだけでコメント検索はできる。
MacOS にはファイルにコメントを埋め込む機能があるので実は昔からこれは可能だった。似たようなことは WinFS でも可能になるだろうから、ますます Windows か Mac 使ってるなら何も用意しなくていいよ、という状況になってきている。
しかしそうなるとサーバに画像放り込んでおきたい、となったときには Windows か MacOS をサーバにしなくちゃならなくなる。特定の OS に縛られるのは好きじゃないのでこれは避けたい。Web ベースにしたいのに特定の OS に縛られるなんてばかばかしいじゃん*5。
_ 余談その2
ついでに昔話をすると、JPEG や PNG の画像に直接コメントを埋め込むタイプのアルバムソフトってないかなーと思っていた。自分の必要な機能からいくと、その方法にしてくれれば余計なメタデータは一切ないので、画像データを自由に移動できるうえに検索性を損なわない、と思っていたけどそんなことしたら個人的なメモが外にバラまかれる可能性があるじゃん、ということにずいぶん経ってから気がついた。
当時そんなソフトがあったら喜んでプライバシーを漏らしまくっていたに違いない。ま、他人に渡せる写真に関してだけだけど。
2005-05-23 [長年日記]
_ XP vs ソフトウェア工学的な構図になっちゃってる話。
自分の中では「説得スキル再び」な話。
えーと。naoya さんはどこでソフトウェア工学を否定したんでしょうか？ 否定したのはウォーターフォールモデルではないのですか？ naoya さん自身の言葉でソフトウェア工学について書いているのはこれだけでしょ。
もうひとつ僕が引け目を感じていた原因として、ソフトウェア工学というものを学んだことがないというのもありました。僕は大学で物理を専攻していたこともあって、いわゆるソフトウェア開発の方法論やアルゴリズムといったものをまともに勉強したことがありません。
ソフトウェア工学を学んだことがないことを引け目に感じているだけ。否定的なことを書いているのはここか。
しかし、独創的なソフトウェアを"創りながら創る"という方法においては静的型付けの言語よりも動的型付けの言語の方が有利だと思うし、スーツを着て設計書を書いてからものを作るなんて作業は、今の僕には耐え難い作業です。もう後戻りはできなそうです。
言語の話が一つ、開発体制の話が一つ。ソフトウェア工学そのものはやっぱり出てこない。
ソフトウェア工学そのものは分からなくてもボトムアップ（あえてことの言葉を使いましょう）で XP にたどり着いた、ということですな。
これに対して orionae さんがいやいやソフトウェア工学は大事なんだよと言うのは別に問題ないと思うし、まぁ実際 naoya さんはソフトウェア工学そのものを大事にしているわけじゃーないでしょうな。ないがしろにしているのではないかという指摘は正しいと思います。でも反論のための例の出し方がまるで「XP では欠陥住宅ができますよ」みたいに読めちゃうんだな。この辺とか。
もしある人が「自分は薬品を混ぜていろんな物質を作るのを愛してるんです。
いろんなアイデアがわいてきて、そうやって作ったこの薬はこの症状にはすごく効くんですよ。」って言って提供する薬を、それを作った人が一切薬学や分子工学の知識が無いとわかっていて、あなたは人に薦められますか？？
また、ある人が「自分は日曜大工が好きで、どんな家でも作れるんだ。いろいろアイデアが浮かんでさ。こんど10階建てのホテルを自分で作ったんだけど、泊まりに来る？建築工学？構造力学？そんなの好きじゃないからぜんぜん知らないや。」
あなたはそのホテルを責任を持って沢山の人に紹介できますか？
極端なようですが、上記ブログでnaoyaさんが述べられているのは、まさに同じことです。
そして
なぜ設計が必要か。なぜドキュメントが必要か。なぜ静的型付けが必要か。
あれ。ソフトウェア工学の必要性の話が設計、ドキュメント、静的型付け言語の必要性の話にすり替わろうとしている。
ところで。
ソフトウェア工学を押さえておかないとなぜ XP の手法が有効なのかは説明できない。そりゃそうだ。でも現場で生き残るのは理論じゃなくて手法だっていうのも自明じゃないですかね。*1理論ではソフトウェアは生まれないのだから、ソフトウェア工学の必要性を解くためには論破ではなく、アジャイルの手法を選択した経緯をソフトウェア工学の豊富な知識を以て補完して説明してあげる方が有効なんじゃなかろうか。つまり、あなたが否定したつもりのソフトウェア工学で以てあなたの選択を説明することができる、という釈迦の掌論法だ。（くどいようだけど、naoya さんは明確にソフトウェア工学の否定はしてないはず。）
もう一つの方法は、あなた方の知見をみんなで共有するためにソフトウェア工学が役に立つ、というアプローチかな。つまり、「はてなメソッドの確立」のために工学的手法が使えますよ、という話。これはソフトウェア工学の人（って誰）にも Web アプリを開発している他の人たちにも嬉しい話になると思う。はてな内部の人がどれだけ嬉しいかはちょっと分からないけど。
ところで今回あちこち見て気に入ったのはこれ。
まぁ要するにソフトウェア工学について、古くて、今ではそんなに重視されていない話の方が有名になっちゃってるんじゃないかなーと勝手に解釈したんだけど、考えてみたらいわゆる「学」のつくものって多かれ少なかれこの手の問題を抱えているんだよな。みんな学校で習った段階でその分野の情報が固定されて、自分の中で常識化してしまうから。
えーと。
オチがねーな。まいっか。
_ ポスドク話。
ドクター取得後の就職にはどんな支援が必要？ (/.-j)
結局、どの組織、どの分野でもダメな人がいて、出来る人がいて、ダメな上司、ダメな部下に悩む人が居て、隣の芝生が青くしか見えない人も居る一方で、どうしても自分より下の人間を見つけてこき下ろしたい人が居ると。
まぁいつものスラドのパターンだなと思った次第。ポスト不足なんてどこにでもある話さ。*2
勝手な妄想を並べておくと、年齢、学歴、実績を「順番に積み上げて行く」っていう以外のルートがもっと認知されるべきじゃないかなと思う。キャリアを活かして新天地ってことじゃなくて、いつでも学び直せるしやり直せる世界。まぁ寝言と思われるかもしれないけど、そんなにとんでもない話じゃあないと思うんだよな。
学問の世界は企業に就職したら遠のくのか？ 逆に学問を究めようとしている人間は企業社会で通用しないのか？ どちらも極端な話だと思う。（それっぽい傾向があることまで否定はしないけどさ。）キャリアパスって言葉があるけど、学問の世界にも企業社会にも、つーかもっと広い意味においても、パスは本来何本も描けるはず。それを狭めているのはスキルや制度だけじゃなくて、自分と周囲の世間体や常識でもある。*3
と、具体的な支援策を書かずに逃げるのであった。だってさぁ、今日やって明日効果が出るような対症療法で解決するとは思えないし。だったら価値観とか、そんなすぐにはどうにもならない話を持ち出してもいいかなーなんて。
2005-05-24 [長年日記]
_ はげどう。の話。
RD のリモコンはでかくていやだから小さいの売ってほしいって意見
いやまったくほんとにその通り。わたしゃ最初マジで「このリモコンは分割できるようにすべきだ」と思いましたよ。うちは H1 じゃなくて XS ですけどね。
東芝ちゃん、藤原紀香に魔法掛けられてる場合じゃない。気づくの遅すぎ。あとブラウザからサクッとタイトル削除もできるようにしてください。でもファームウェア上げて変なフリーズに悩むのはいやですので、その辺もしっかりやってください。
2005-05-25 [長年日記]
_ mod_perl2 リリースと Apache2 への移行
mod_perl2 が出たらしい。（リンク先は /. なんだけど、オリジナルのリリース文書はないのかな？）
tdiary.net の稼働環境を見ると mod_ruby も Apache2 との間で深刻な問題はないだろうと判断できるので、あとは PHP かな？ PHP5 への移行を伴わずに Apache2 で安定動作するようならそろそろ Apache2 にいっちゃってもいいかなぁ。（文字コードとか PHP の動作で悩んだのは2年も前の話か。）
_ for あれこれ
JavaScript の for ( i in array ) は i が添字だと。うーん、ちょっと書き出してみよう。
| 言語 | 書き方 | i にくる値 |
| JavaScript | for ( i in array ) | 添字 |
| awk | for ( i in array ) | 添字 |
| sh | for i in array っちゅーか list? | 要素 |
| Ruby | for i in array | 要素 |
| Perl | foreach $i ( @array ) | 要素 |
| PHP | foreach( $array as $key => $value ) | 添字も要素もどっちも |
Ruby は for も each も書き方が違うだけっぽいですが、for は awk 方式、each が shell 方式でもよかったかなとか勝手なことを思ったりした。
PHP 4 以降の foreach は要素を取り出すのと添字と要素の組み合わせを取り出すのと、両方の書き方
foreach(array_expression as $value) 文 foreach(array_expression as $key => $value) 文
が可能なんだけど、これ結構邪魔くさい。foreach ってのが長いくせに as とか => とか妙にタイプ量を上げるトラップが仕組まれてる。まぁ PHP 3 で使っていた
while ( list( $key, $value ) = each( $array ) )
よりはマシなんだけど。
2005-05-26 [長年日記]
_ one liner, one linerer, one linerist
one liner という言葉がある。日本語で一行野郎などと訳されたりするけど、要は一行スクリプトのことで、プロンプトにカタカタと打ち込んでいき、一度エンターを押すだけで結果が返ってくるように書かれたものだ。
さて。
では「one liner 使い」はどう呼ぶのがいいのだろうか。one linerer? one linerist? 達人レベルなら one liner wizard っていうのもアリかもしれないけど、下手の横好きの場合は one liner lover? うーん。
ほんとは one line script 使いが one liner なんじゃないのかなぁ。
2005-05-27 [長年日記]
_ for でぶん回して clamscan
恥ずかしながらファイルサーバ内にマクロウィルスを発見。メールはプロバイダがスキャンしているので、これは基本的にリムーバブルメディアを介して入ってきたんだろうなぁ。
さて、ここから先が問題。ファイルサーバは Mac で動いているので Windows では認識できないファイル名などが散在している。運良く手元の機械は OS X だが、とりあえず今回のマクロウィルスに感染する可能性のある Excel のファイルのリストを作成するにはどうしたらよいか？
とりあえず Information List という Classic アプリに頼ったが、今なら Unix 系のアプリと AppleScript でなんとかなるかもしんない。AppleScript はまったく経験がないので今回は Information List でタイプ、クリエータ情報まで含めてリストを生成し、改行コードを lf に変換して awk でそれらに対して検索を掛け、Excel ファイルだけのフルパスのリストを作成する。*1Classic Mac の世界では拡張子は文化として存在しないのでタイプ、クリエータに対して検索を掛ける必要があるのと、リストがタブ区切りで生成されるのが分かっているので、こういう場合は awk がすごい便利。
そうしてできあがったリストに対して今度はスキャンを掛けるのだが、Information List の吐くリストは Classic 流で、フォルダの区切りに : が使われているので
sed -e 'y/\/:/:\//'
で / と : を入れ替えて clam に食わす。しかしここでリストを
for i in `cat list`; do clamscan $i; done
ってやると「半角スペースを含んだ名前が分割されちゃって正しくスキャンできない」。慌てた私はファイルのリストに対してエスケープを書き加えてみたが、これは間違い。正解は
IFS=$'\n'
とシェル変数を設定し、「改行だけを for 文のパラメータの区切りにする」ことで対処するのが簡単。
ログは -l でログファイル名を指定して吐くよりリダイレクトした方がなんだか望みの形になったのでそうした。
で、問題のファイルを特定したら対処開始だ。ここから先は今回のテーマじゃないので割愛。フルスキャン掛けないと意味ないんじゃねーのってゆー正論も今回は無視。*2
★ OS X で作業するときはファイル名は Unicode なので普段の作業の都合上 EUC に設定している人は注意。
2005-05-28 [長年日記]
_ AppleScript で遊びを勉強し始める
先日書いたファイルのカタログを作成するもの が AppleScript で作れないかなと思い、ちまちまと調べながら Script Editor と格闘。やることは
- 対象となるフォルダを指定して
- カタログ情報の出力先を指定して
- find TARGET
- 結果を受け取ってリストにして
- リストに上がってるファイルに対して順番に情報を取得して、それを付加して
- ファイルに書き出す
という流れになるんだけど、2 と 5 の、要するにファイルの書き出しがよく分からないというか今のところうまく行かない（すでに開かれているだの、開かれていないだの、目的に合致した状態にならない。）。そこを無視すると一応できたんだけど、結果が今のところダイアログにしか出せなくて、まったく使いものにならない（画面に収まらない）。
初めての AppleScript の感想は、
- 基本の構文が英文ライク（な end 構文）でタイプ量が多い
- フリーフォーマットでないというか、複数行に気楽に分けて記述できない
- 暗黙の変数 Result に頼りまくりなのは Perl や Ruby のようでもあるけど、あんまり気持ちよくない（Result を壊さないようにするためにスクリプトの記述順序に気を使う）
- OS X での AppleScript は do shell script 命令のおかげでものすごく楽ができそうだ
- AppleScript 内ではパスは Classic 風に扱うが、POSIX パスと簡単に相互変換できるので助かる
- 他の言語でポピュラーな文字列処理の関数（命令？）がない*1ので、その辺も全部外部のコマンドに頼ってしまいそうだ（ファイルの出力も do shell script でリダイレクトしたら？と言われたが、さすがにちょっと躊躇している。）
- しかしいかにも UI をかぶせただけって感じになってしまうといささかかっこ悪いので、AppleScript Studio が使いこなせると気持ちよさげ
- とりあえず Inerface Builder も動かしてみたけど、いやぁ Aqua な UI やメタルな UI ができてるよー。かっこいいよー。見た目がいいとモノがよさげに見えるから不思議だよー。
- 逆にコマンドラインで AppleScript を使うのも便利そう。それも可能らしいけどまだよく分からない。
なんだか可能性はずいぶん広がった気がする。
*1 まったくないわけじゃないけど、自然言語のような書き方を目指しているのですごくまどろっこしい。
2005-05-29 [長年日記]
_ 最近、以前よりテレビを見る
あるある2 肩こりネタ
またあるあるかと。いやねぇ、この時間帯ってなんかどうもまったりしててねぇ。テレビを見ちゃうんだな。でも法律相談所はなんかイメージ挽回のための小ネタ披露番組になってて、前より明らかに間延びしてるのですよ。とまぁそれは置いといても、長いおつきあいの肩こりネタだったので見たわけですが。
肩こりの原因を
- 首
- 背中
- 腕
の3つに分け、これらの原因に対して効果の高い運動を提示するというスタイル。最終的に全部志村けんのネタに統合されているのは作りとしてはうまいなぁとは思うんだけど、それやるといかにもうさんくさくなっちゃうような。つまり、ネタ先攻で番組作ったような感じがしちゃう。
まーあるあるにマジツッコミしても始まらないのかもしれないけど、自分は上のどれについてもそれほどひどい症状ではなかったのに、肩こりの自覚症状はひどいぞ。まぁ骨格のゆがみとかそういうレベルだと短時間の運動では解消されませんよということなのかもしんない。
どうでしょうクラシック
2ヶ月ほど前から「水曜どうでしょうクラシック」を見ている。金沢では今放送されているのですよ。水曜の深夜に。深夜なので録画で見てるんだけど。
最初薦められたときは DVD が発売になったり話題になっているのは知っていたけど、だから何？という感じだった。しかし MPEG2 素材の取得とムービーのエンコードなどの練習のためと称して見始めたらおもしれーじゃねーか、この野郎。なんだよ、もっと早く教えてくれよ。というか途中で気づいたけど、確かマレーシアに連行されたスペシャル番組か何かを昔見たことがあった。やることもなく食って飲んで移動してをくり返して、ホテルで企画発表。大泉また騙されるってやつ。これかぁ、と。そうかあれがどうでしょうかと。なんだよ知ってたら最初から見たぞ、この野郎。*1
大泉洋は何が面白いって、ネタそのものじゃなくて、あの浮き沈みの激しさ。同じ B型として彼のノリの変化にとても親近感が湧く。あのヘコミっぷり。さいこー。あと、地方の番組にしては CG部隊とか編集が頑張ってる気がする。正直、タレントの差をさっぴいてもあのレベルのローカル番組は金沢にはないんじゃないかな？ さすが大都市札幌。中核都市とは違います。やっぱこう、商売的にも生活的にも文化的にも、100万〜200万くらいのレベルの都市ってのは面白いのかもなぁ。
というか番組予算がローカル番組にしてはでかい気がするんだけど、それはギャラが安いからなのかな。全国レベルのタレント連れてきちゃうとギャラが予算圧迫するから、タレントありきの番組じゃあんな企画は絶対できないよな。
*1 これが藤村Dの口調でしょうか？
2005-05-30 [長年日記]
_ プロパティ別 CSS
労作だなぁ。
alternative stylesheet を考えるときや、media 別に CSS を分けるなんて場合はこういう書き方せにゃならんのですよね、実際のところ。つまり、幅広いプラットフォームを考慮して CSS を書くときは「表現でセレクタを串刺しにする」ような書き方ができなきゃならんのです。逆に言うとグラフィカルな最新ブラウザしか考えないなら分ける必要はないんじゃないかと。
最近は blog ツールなどの方で HTML ごと表現をごっそり入れ替えるのが楽になったから、あえてそういう書き方をする必要もなくなってきましたけどね。簡単なところでは「印刷向けページ」を別に生成することなく、CSS だけで自分のページを印刷向けに仕上げてみると、このプロパティ別整理の有効性が分かると思います。少なくともテキストブラウザや音声ブラウザを動かしてみるよりははるかに簡単に確認できます。
※ 実際には私はプロパティ別には整理してないですけど、考え方は比較的近いです。
_ テクニカルエンジニア（情報セキュリティ）創設予定とな
新試験「テクニカルエンジニア(情報セキュリティ)」とは? （MYCOM PCWEB IPAX 2005 - 今語られるスーパークリエータの開発のきっかけ(2) ）
ほほう。
来年創設予定。ほほう。
情報セキュリティアドミニストレータは受けてから気づいたけど、基本的にシステムがいじれなくても勉強すれば通る。少なくともサーバ管理のスキルは必要ない。もちろんいじれた方が理解は早いし正確な理解にたどりつきやすいのは間違いないけど、概念と法律の知識の比重が高いので、これはいかんなぁと思っていた。*1今度はこれを技術寄りに振ると。データベースの話が多くなるのは昨今の事情を反映してってことなんでしょうな。アクセスコントロールって意味ではこれは基本中の基本なので別に不思議じゃないんだけど、データベースだけクローズアップされるとちょっと違和感を覚えるな。
記事中にもあるけど、確かにベンダー非依存を目指すのは難しそう。陳腐化させずに全部 Linux Box で作ってくださいって話になったらそれはかなり邪魔くさいというか、現実的じゃない。もちろん全部 Linux Box で自前で組むという選択もあるだろうけど、現実的には組み込み機器を適切に配置してシステムを構築する。それはコストと実現されるもののバランスのうえで判断されるものであり、この過程で機器、ベンダーに対して得手不得手が出てくるのも半ば当然の話だ。（全部ソフトでいく場合もそう。）
取るなら試行錯誤のスタート直後の方が楽か？ :-)
*1 いやいや、ユーザー側にこういう知識を持った人間が必要という意味では十分機能する可能性は高いし、「上」を説得するためには法律などの枠組みはとても重要ですよ。
2005-05-31 [長年日記]
_ 絶対パスとファイルタイプとクリエータ情報をリストアップする AppleScript
初めての AppleScript 動きましたバージョン。（昨日の夜の段階では日本語テキストの出力に失敗してましたが、それも成功します。）
| 制作・動作確認環境 | OS X 10.3.9 + ScriptEdtor 2.0 |
(*
指定したフォルダ以下のファイルの絶対パス、タイプ、クリエータ情報をテキ
ストファイルに書き出す
target リスト作成対象フォルダ
output リスト出力先
*)
-- パスを指定
choose folder with prompt "リストを作成するフォルダを選んでください"
set target to getPath(result as string)
choose file name with prompt "リストの出力先を指定してください"
set output to result
-- 出力先を開く
try
set fp to open for access output with write permission
set eof fp to 0
on error
close access fp
end try
-- ファイルのリストを取得してくり返し
do shell script "find " & target
repeat with filename in line2list(result)
-- ラスト5文字が /Icon なら除外（なんか怒られるので）
set last5 to text -5 thru last item of filename
if (last5 is not "/Icon") then
set fileinfo to (info for (POSIX file filename))
-- フォルダか否かを明示
set foldertext to ""
if (folder of fileinfo is true) then
set foldertext to "Folder"
end if
try
write filename & tab & foldertext & tab & file creator of fileinfo
& tab & file type of fileinfo & return to fp
end try
end if
end repeat
close access fp
--
-- Classic パス形式から POSIX パスの最後の / のない形式を取得
--
on getPath(str)
set len to (length of POSIX path of str) - 1
return text 1 thru len of (POSIX path of str)
end getPath
--
-- 文字列を改行でリストに分ける
--
on line2list(str)
set text item delimiters to return
return every text item of (str as text)
end line2list
以下、ハマったところ。
- ファイルを開いたときのエラー処理がへたくそなのか、ファイルを開きっぱなしになったりして変なエラーが起きることがある
- ScriptEditor を再起動しないとずっと同じエラーが出たりするので注意。
- 文字列処理が、、、ものすごくつらいorz なんかリストに分割したり、ファイルに書き出したり、クリップボードに吐き出したりするのがポピュラーなテクニックらしいけど、面倒くさすぎてやっとれん。
- さらに日本語を含むテキストを扱う際、text, unicode text, string とか気を使わないといけない。
難しいよ。
_ Sage 1.3.3
自動アップデートでまったく補足できていなかったので気づかなかったけど、pre の改行の問題が直ってる！
やった！
1.3.2 で直ったのか、1.3.3 で直ったのかは分かりませんが。
