2005-09-01 [長年日記]
_ 打って響くことの気持ちよさ
以前早口の話に触れたことがあったが、やはり自分は頭はぶんぶん回す方が気持ちよいし、自分のためによさそうである。頭が疲れるくらいに高速で本題と本題じゃない話題を展開し、トレースし反芻してまぜ返すのはとても面白い。様々な刺激が頭の中を駆け抜け、気持ちが新たになったり、ふとした思いつきが出てきたりする。しかしこれは会話の相手が同じスピードでついてこれないとできない。
いつもいつも疲れるほど回すこたぁないけど、回した結果として気持ちよさが残る相手は貴重だ。
…ということは説明が徒労に終わったときに痛いほど感じる。めんどくさい思いをしてだるさだけが残るなんてあほくさい。
_ Wiki とメールがうまく共存できると嬉しいな
エキサイト創業者に聞く、Wikiブームの実情 (CNET Japan)
メールの話が出ていたので、触発されて以前から思っていたことを。断片的にはすでに何度か書いているような気がするけど、復習ってことで。
個人的に、既存の多くの Wiki がメールと相性が悪いのは問題だなと感じている。それは編集の通知をメールで出せるとかそういう技術的な話ではなくて、Wiki のソースをメールで送ろうとしても読みにくいってこと。ときどき Wiki のソースは人間にも機械にも読みやすいと思っている人がいるけど、これは結構な割合で嘘だと思う。試しに Wiki 文化になじみのない人にソースをそのまま送りつけたら怪訝な顔をされるだろう。
そりゃそうだ Wiki は WikiWikiWeb であり、Web サイト上に文書があるのが前提なのだというのは正論なんだけど、自分の手元にない情報と自分の手元にある情報をうまく整理つけて取り回しできる人は、実はそれほど多くない。つまりそもそも Wiki の情報は手元にないものだから、Wiki 文化の外にいる人には扱いにくいという問題を抱えているし、例えばこれ読んでおいてくださいと言われてメールに URL が書いてある場合と、実際の文章が書いてある場合でどちらがちゃんと読まれるかを考えると、そりゃー文章が書いてある方だろうと思う。
で、何が言いたいかというと、
- Wiki 文化はまだ根付いていない
- Wiki に書くことが根付いていないと、多くの場合読むことも根付いていないだろう
- Wiki 文化の圏外に居る人に何か文書を読ませたい場合はメールで送りつけた方が効果的
- Wiki 文化内の人間としては Wiki ソースを貼付けてメールで送れると楽
- Wiki ソースがそのままメールに貼付けて違和感のない形になっていると両方の文化の人にとって嬉しい
ということが言えるんじゃないかなぁと。*1
で、そのために個人的には reStructuredtext に期待しているというのは前にも何度か書いた気がするんだけど、setext を知らない人にはこの話は単なる飛躍なのよね。では書きましょう。setext は、プレインテキストであるメールの中で文章の構造を記述するために考案されたのです。確か。*2だからその拡張版である reStructuredText に期待するのは当然なの。
ただし、現状で安心して日本語で書けて reStructuredText をサポートしている Wiki は選択肢があまりない*3と。こういうことです。
2005-09-03 [長年日記]
_ スピードワゴンの「あまーい」
TVチャンピオンの芸人通選手権。
これかっ。これかぁー。
前からこんなネタやってたかな？
いやー。だったらね、だったらね。場を止めなきゃダメ。流れの中に埋没させるトークで甘い言葉は言っちゃダメ。気づいている人のほとんどいない甘い言葉は反則。
スピードワゴンはこの甘い言葉を喋る方が好きじゃなかったんだけど、そうかこれはピンで喋ってたからだめだったんだな。つーか相方すごい。
2005-09-04 [長年日記]
_ ユニットテスト始めました
今までもテストコードは書いていたんだけど、使い捨てだったのでこれはいかんなぁと思っていたのと、確認は人間の目で行っていて、成否をいちいち人間が判断するという効率の悪さが気になっていたので、テストツールを使うことにした。
とりあえず Ruby の Test::Unit から始めた。うーん最初はやはりかなり邪魔くさい。あと、assert にはテストしたいメソッドの結果が直接返ってこないとダメなのかと思いこんでいたけど、たぶんそうじゃないんだな。確認用のメソッドを作ってそっちを呼んでも、とりあえず問題はないと判断。*1
ユニットテストの自動化のメリットとして
テストしやすい書き方をするから書き方のバラつきが少なくなる
てな記述を見かけるんだけど、これはほんとかもしれないと思った。こういう自動化ツールは中途半端に使っても嬉しくなく、徹底的に依存しちゃう方が効果は大きい。そうすると、確かにテストしやすいコードに自然と直ってくる。ような気がする。まだコードそのものが変わっちゃうほど使い込んでいないけど、このなんかこう、居心地の悪さは、慣れないことをやっているとき特有のもので、慣れると気持ちよくなりそうなそんな期待を感じることのできる気持ち悪さだ。cvs なんかを使い始めるときもこんな感じかな。最初のうちは面倒なだけで必要性を感じられないんだけど、慣れると使ってないと気持ち悪くなるところが。
ただ、テストコードを書きにくいものはどうしても残りそうだし、とりあえず Web 上を見て回ってもそれに対する有効な回答は見つけられなかった。なんか、そのうちうまく書けるようになる、みたいなちょっと騙されたような感じ。（まぁよほど経験を積んだうえでないと具体的にテストしにくいものはこうする、なんてことは書けないもんな。）
テストコードはどこに置いておくのがいいんだろう？ 別ディレクトリに分けてリポジトリにつっこんでおくのがいいのかな？ コンパイラ言語なら中に書いちゃって ifdef で切り分け、なんてのも ok なんだろうけど、LL の場合はそうはいかないもんな。
これしかし、自分で書いたものを自分でチェックしてるだけなんだけど、プログラムが自動で成否を判断してオッケーって言ってくれてるような感じが嬉しくて面白い。錯覚なんだけども、面白いと感じることができる要素があれば続けられそう。
*1 この辺、assert の書き方のパターンがどこかにいっぱいあると嬉しいかな。
2005-09-06 [長年日記]
_ いまさら 1.6 ですが何か
つーかアンケート対象の日本 Ruby の会の人らの使用歴長すぎ。
- なぜ 1.6 か
- 本番環境が古いから。（セキュリティ fix は有償で当たってますが。）
- 1.6 で書くときの参考資料
- 本家リファレンスと tDiary のコード。正直、今後公開されてるアプリが 1.8 対応ばかりになるとパk(ry …にくくなって困る。
まぁ Ruby は基本的に more better perl というか、伝統的に Perl がよく使われていたシーンで書きやすい Perl としてしか使ってない（今のところそういう方針なの）ので、そんなに困るところはないんだけど。
※ 本番環境を上げなきゃなぁとは思ってますが、具体的なスケジュールはありません。
_ alog いじりたい
Lightweight Language Day and Night レポート
alog についてはとても軽く触れられているんだけど、
- プロキシ動作して
- Web サイトに付箋をはれる
って、wema2 への要望に書いたことそのまんまじゃん！ 動いてるならいじりたいよー。これはね、公開サイトに使うんじゃなくて、内部で使うのにいいんですよ。制作中の Web サイトへの修正項目をメモするとか、参考にしているサイトのここに注目！ みたいなポイントを書くとか。サイトじゃなくて Web アプリでもいいし、例えば ruby-lang.org のここをこう直せ、とかいう要望を書くために使ってもいいと思うけど。
こういう目的のためには Wiki である必要はないというか、Wiki じゃない方がいいんです。まさにほしかったものそのまま！ だと思っているけど、落ち着いて資料読むか。まず。
試したい試したい試したーい。
2005-09-07 [長年日記]
_ PukiWiki fork 向け試案
※ まずはじめに、この日記はおれが fork したる！という意思表示ではありません。お間違えのないよう。
pukiwiki.org ドメインが for sale になりましたな。
確認できるのは
- 増井氏が pukiwiki.jp を取得し、死んでた users-ML に報告
- heno氏は dev の開発日記に書き込み
やりとりする気なさそうに見えるなぁ。というか pukiwiki.org のサイトは通常の状態では閲覧不可能なのに、なんでいつまでもここにどんどん書いていくのかな、heno 氏は。hosts 書き換えれば見ることができるっていうのと、そのまま使い続けていくのとは別な話だと思うんだけど。
というか、開発以外の話なんだし、自分で blog 用意してそこに書いてくれるのがいちばんありがたい。
- fork しようかという動きもあるが、愚痴を言う場所になりつつある感じ？ つまり 2ch の PukiWiki スレがもう一つできたようなもんか？
ただ、個人的には fork は悪いアイディアじゃないと思う。サーバ管理やサイトの運営ポリシーの問題を除いてもおおざっぱに
- PukiWiki 内部に非常に手を入れにくい作り
- アップデートしにくい作り
- 設定ファイルやコード中のコメントが日本語じゃなくて敷居が高いなどの問題
があるわけで、これをどうにかしようと思ったら、
- Wiki 記法のパーサ以外全とっかえ
でいいんじゃないかと思う。*1というわけで以降は fork する人向けメモ。（あくまで自分で fork するぞ宣言でないことに注意。）
まず、PukiWiki 全体で global 宣言しまくりで、名前空間がフラットで、それを避けるために関数名とかやたら長くなったりして、超やな感じなので、これはもう全部クラスに分けちゃう*2。あとアップデートしにくいのと設定ファイルの問題は
- 設定ファイルの役割を最小限に絞って、あとは全部 Web インターフェイスで設定するように変更する
で、その設定情報がデータ領域に入るようにすれば、設定ファイルの中のコメントが英語だとかアップデートしにくいだとかの問題を一挙に解決できる、はず。特にコメントの問題は単に設定ファイルがでかすぎるのが問題なんだと思っている。あんだけでかけりゃそらコメント要るし、コメントがすぐ読めなきゃそら面倒くさくてやっとれんて話ですよ。
- そのためには認証周りをもっと扱いやすくしないとダメ
なんだけど、これは前からそうなんだから、この際だからガンバレと。
もひとつ、コード中のコメントが英語でカスタマイズしにくいって問題も、そもそもコメント見ないと何やってるのか分からないような長大なブロックなどが問題なのであって、もっと読みやすいコードにすることが前提にくるべき。あと phpdoc をフル活用する方向にして、それと簡単な図*3をサイト上に載せておけば、ずいぶん楽に全体の構造が把握でき、かつそれぞれのパーツの役割も確認しやすくなると思う。
果たしてそれは PukiWiki をベースにする意味あるのか？という疑問は残るけど、自分にとって PukiWiki が PukiWiki であるいちばんの理由は Wiki 記法なので、自分にとっては意味がある。ま、極端な例だと思うけど、しっかりした何かがベースにないと fork できないままで終わると思うし、fork しない方がいいんじゃないかと思う。
_ Ruby で YAML はすごい楽じゃん
プログラマーのための YAML 入門 (初級編) とか Yaml.rb -- Yaml for Ruby とか参考に、適当に YAML で書いたファイルを用意して
require 'yaml' require 'pp' fh = File.open( FUGAHOGE ) yaml = YAML.load( fh ) pp yaml puts yaml.to_yaml
こんなんでテスト。すっげ。Hash の配列とか配列の Hash とか Hash の Hash とか、正直 Ruby で書くのはだるいんだけど、YAML だとばかみたいに簡単。なんだこれわ。もっと早く試すんだった。Ruby では標準添付っつーのがサイコーに楽。
しかしこうなると yaml-mode.el がほしくてたまらない。
2005-09-08 [長年日記]
_ SSL 2.0 を切ってみた
Firefox は SSL 2.0 を切る方向らしいので、どういうことになるのか確認するために 1.0.6 で SSL 2.0 を off にしてみた。
Web メールで広告が出なくなった。素晴らしい :-)
_ Ruby 率高すぎ
Lightweight Language Day 2005アンケート集計(1)
他の言語の人があまりよその言語の人と交流を持とうとしていないのか？ あるいは他の言語のコミュニティではあまり話題にならないのか。実際現場で使われている率で言うと Perl と PHP の方が断然高そうだもんな。（自分勝手に Ruby や Python を使っている人は多そうだけど。）
それとも、関東では実は Perl, PHP よりも Ruby がキテるのか？ まさかね。
意外と awk が健闘しているのがなんか嬉しかったり。（XML をいじろうとは思わないけど。）
2005-09-09 [長年日記]
_ JavaScript 2.0 はまずいでしょ。
めもぱっどの『伊藤直也の「アルファギークのブックマーク」』のコメント。
JavaScript2.0は本当に言語として作成中なので新語を造っちゃうとまずいと思います。
まったくその通り。
このうっかり具合がはてなクオリティなんだなと納得させられた。というか JavaScript をいちばん誤解していたのが単にハテナオヤだっただけなんじゃないかと邪推。JavaScript がどれだけ時間を掛けてまともな作りになってきたかとか、全部ぶっ飛ばしちゃってるもの。
2005-09-12 [長年日記]
_ bruteforceblocker @FreeBSD ports
security/bruteforceblockerはPF限定じゃなくて簡単にipfwにも対応できる
なるへそなるへそ。
そろそろ 4.x 系の引き際も考えないとなぁ。
_ フィクション殺人について
- なぜ、現実では「人を殺してはいけない」とされ、フィクションでもそのルールは概ね準用されるのに、現実世界の人間がフィクション世界の人間を死なせることはよいのでしょうか？ ※その回答は自己評価で何ポイント相当か、併記してください。
- Critique of games - 死の表現
なるほど面白い。
けど。
なんか最近、殺人に問題が単純化されたり、安易に比較対象にしたりすることがちょっと多いような？ タブー視すべきではないけど、「概念」として安易に扱いすぎることも現実感の喪失を生まないだろうか。もうちょっと生命体としての感覚を磨くのも大事じゃないかと思う。なんつーか、死ぬのも殺すのも恐ろしいものでしょ、ほんとは。そういう感覚はなくしちゃダメだと思うんだよな。概念の方をトレーニングするのと同時に、皮膚感覚というか、そういうのも磨いておかないとちょっと危うい感じがする。
まぁ、本来個人でトレーニングを意識する必要なんかなかった話なんだけどね、死っつーのは。
2005-09-13 [長年日記]
_ 中選挙区に戻すんじゃだめなのか？
そんなに差がつくかぁ？と思っていたけど、やっぱ選挙区制度の改悪が原因だったのか。小選挙区・比例代表並立制になるとき、かなりすったもんだしたけど、結果が出たってことですな。自民党がやりたかったのはこれだと。これが「民意を反映した」ことになるんだから、めちゃくちゃでごじゃりますがな。
票を殺し、民意を殺し、政治を殺してるのは誰だ。
2005-09-18 [長年日記]
_ Perlプログラミング救命病棟確保
ぱらぱらーっと眺めた限りでは perldoc で提供されていたり、あちこちですでに見聞きしたものが多いかな。まとまっているので Perl newbie を卒業したくらいのレベルの人に読ませるにはいいかもしれない。少なくともこれ読んだうえですすんで他人には解読不能なコードを書くことはあるまい。
最近 Perl 書かないようにしてたこともあり、これで復習しよう。
一週間ほどサボります。
2005-09-26 [長年日記]
_ オフってました。
もう完全に。キーボードにまったく触らず、観光旅行。撮った写真は600枚（コンパクトデジカメ + ブローニーの銀塩）程度ですか。
今回はデジタルのデータは全部 iPod に吸い上げたので荷物はずいぶん楽でした。なぜか iPod 本体が充電されたりされなかったりするのでちょっと悩みましたが、実に手軽でよい感じ。あとはこの整理がなげーんだな。まぁコンパクトデジカメだし、そんなにこだわってもしょうがないのは分かっているので、スパスパ判断して削除＆補正をやっていきませう。
しかしもう長時間のバス移動が連続するのはやだな。今度はもうちょっと考えよう。
2005-09-27 [長年日記]
_ Hundertwasser Haus はこんな感じ。
見た目に面白い写真を最優先で取り出すとこんなところ。ちなみにこの建物、普通に人が住んでいるそうですが、周りには観光客がうろうろ、ショップもあるという状態。住んでみたいがよく住めるなぁというのが正直な感想。
2005-09-30 [長年日記]
_ Apache 1.3 で転送できる最大サイズ
Apache 1.3 on OSX(not Xserve) では 2GB を越えるファイルの転送はできないらしい。
LimitRequestBody 0
にしてもダメだった。ファイルシステムは 2GB の制限を受けないので、Apache そのものの制限か、OSX 用の何かのモジュールか、コンパイルオプション（そんなのあったかな）か何かの影響かもしれないけど、考えるの面倒になったので
split -b 2000m
して対象ファイルを分割して対処。
以下はその他も含めてテスト結果。Apache は apt-get か ports で素直ぉーに入れたもの。
| Webサーバ | OS | ファイルシステム | 結果 |
| Apache 1.3.33 | OSX 10.3.9 | HFS+ | ×*1 |
| Apache 1.3.33 | FreeBSD 4.11R | UFS | ○ |
| Apache 1.3.26 | Debian 3.0 | Reiser3 | △*2 |
| Apache 2.0.54 | Debian 3.1 | ext3 | ×*3 |
よぐ分かんねぇ。ports で入れたものは普通に動いているので Apple バイナリ、Debian バイナリが何か手を加えられているんじゃないかと疑っているんだけど。気分が乗った人は追試してみてください。
なんでそんなでかいファイルを転送したかったかというと、DVD-R ドライブを積んでいない Mac で DVD の iso イメージを作って、それを DVD の焼ける Windows マシンで焼こうと思ったからなんですが。普通にその Windows マシンで焼くとイメージの作り方が Windows 前提で、ちょっと嬉しくないことが起きたりするので。SMB/CIFS でええやんという指摘はごもっとも。でもなんとなく「HTTP の方が軽いかもしんない」と思ったので。
外付けのドライブ買うのがいちばん簡単なんだよなぁ。
※ 結局、Mac で作ったイメージ（「CD/DVDマスター」に変換したもの）を Windows や Linux でマウントできないことが判明。いったいなんだったんだorz CD は iso9660 で焼けるのに DVD はできないのか？ （とりあえず 10.3 では mkisofs -udf するしかないっぽい。）
_ ran [どこ行ってきたん？ うちは子供いるせいでどこにも行けんかった orz]