先々週土曜から先週土曜までラスベガスへ出張だった。 帰ってきて、最後の力で荷物ほどいて寝て、 起きたときはもう日曜が終わりかけていた。 どんだけ疲れてんだ俺……。
木金は休むかなあ。
(06:51)
さて、3ヶ月近く放置したことで この日記を見る人も激減していると思うので、 ここぞとばかりに適当なことを書き散らすことにする。
ふつぱいらのコンパイラがJavaなので、 最近家ではJavaばっかり書いている。 さんざんJavaで書きまくってると、 Javaも意外と悪くないなあと思うようになってきた。 先入観イクナイ。
でも Java 1.4 は本当にイクナイ。 generics のない静的型付きオブジェクト指向言語なんてありえん。 キャストの嵐がめどすぎる。 コンパイラも実は 1.4 対応なんだけど、Java 5 にすればよかった。 まさか 2 年以上かかるとは思ってなかったからなあ。
それとは対照的に C# は俺内評価が下がりぎみ。 Java ばっかりいじってたからかもしらんけど、どうも気に食わない。 もっとも、言語がというより IDE が気に食わない可能性も大。 メソッドが全部大文字で始まってるあたりが地味に嫌だ。 あと言語的には virtual を書かせるあたりが嫌だ。
一方、昼間は相変わらずシェルスクリプトばかり書いている。 シェルスクリプトもそれほど悪くないのだが、 500行を越えるとウンザリしてくる。 特に素の sh にはローカル変数がないので地獄を見る (見た)。 ksh であっても local があったりなかったりして嫌だ。 しかたないので防衛的に、 常に alias local=typeset を入れておかなければいけない。
それと、UNIX の常識的なルールに従う限りは問題ないのだが、 スペースの入ってるパスもちゃんと扱おうとか、 マルチバイト文字の入ってるパスもちゃんと扱おうとか、 そういう余計なことを考えるととたんにウザくなる。 local basedir="$(dirname "$(dirname "$0")")" とか書くのはもう疲れた。 何回クオートすればいいんだよ！
スペースやマルチバイト文字の入ってるパスなんて 実際にはないだろうと考えて無視したいところだが、 SUA (SFU) だとフツーにありうるから困る。 あの環境には心底ウンザリだよ。
そんなわけで結論としてはやっぱり Ruby がいいなあー、 ということになったのであった。 最近はちょっとしたツールくらいしか書いてないけど、実に楽だ。 each と map がサクッと書けるだけで感動できる。
もっとも、そのへんはシェルスクリプトでも意外と 同じようなことができるわけだが、 行より細かい単位の文字列処理がからむと Ruby が圧倒的に楽でいい。 awk とか sed とか cut とか expr とか駆使して チマチマ処理していると発狂しそうになる。
そもそも echo に移植性がない時点で泣ける。 こないだ発見したバグなんてひどかった。 "C:\WINDOWS\SUA\home\bwuser" っていうパスを echo すると "\b" がバックスペースになってしまうというバグ。 こんな感じのコードで発覚した。
echo ".export report file = `NativePath "$path"` > "$tmp"
この時は cat + ヒアドキュメントで回避できたのだが、 いつか回避できないときが来るような気がしてならない。 恐ろしい。
Ruby が楽だという話をするはずなのに、 気付くとシェルスクリプトに対する不満に変わっているのはなぜだろう。
やっぱねー、Ruby はいいよねー。 例外あるからエラー処理が楽だし、配列もハッシュテーブルもあるし。
ちなみにシェルスクリプトの嫌なところをもう一つ。 以下のコードで $stat が絶対に変化しない理由を述べよ。
#!/bin/ksh
main() {
stat=0
cat $file | procfile
exit $stat
}
procfile() {
if ! sed .....
then
echo "$0: error: sed failed" 1>&2
stat=1
return 1
fi
}
main "#@"
ヒント： 次のコードなら $stat は変化する
#!/bin/ksh
main() {
stat=0
procfile < $file
exit $stat
}
procfile() {
if ! sed .....
then
echo "$0: error: sed failed" 1>&2
stat=1
return 1
fi
}
main "#@"
そのてん Ruby ならこんな変な罠はないし、 オブジェクトを返せるから情報の受け渡しには苦労しない。
あと、仮引数だよな。 関数の仮引数を明示的に書けないのは非常に、非常に、非常によくない！ ソースコードのわかりやすさが極端に下がる。
もちろん、もっと単純な、 スカッとパイプライン一本で解決するような話なら シェルスクリプトはめっちゃ楽なんだけどさ。 やっぱ根本的にシェルスクリプトに向いてない処理を やろうとしてる気がするな。 真剣に Java 化を考えよう。
(01:19)
AMD64 はいいよねー。何がいいって、 汎用レジスタの本数が増えたことが一番だが、 RIP（プログラムカウンタ）相対アドレッシングが地味によい。 おかげで PIC でもグローバル変数アクセスが超簡単。 グローバル変数からのロードもこんなコードで一発ですよ。
movq gv@GOTPCREL(%rip), %rax
x86だとサンクをcallしてスタックから 戻りアドレスを取って……と激しくめどい。
(02:31)
笹田さんとメールで連絡した結果、 少なくともRuby会議の実行委員会でるりま枠をなくせとか、 そういう意見はなかった、ということがわかりました。 また冷静に考えてみるとわたしが聞いたのは 「〜〜という話を聞いた」程度のあやふやな情報にすぎず、 それだけを根拠に他人を非難したことは軽率に過ぎました。 深く反省しています。
時間枠についても、追記で書いたとおり、 最終的にはちゃんと 20 分もらえているわけですから、 感謝こそすれ非難する筋合いではありませんでした。 時間帯もだいぶいい枠を回してもらえたということで、 むしろ優遇してもらったと考えるべきかもしれません。
よいカンファレンスを作るために様々な場面で尽力してくださった Ruby会議運営スタッフの方々にいわれのない非難を浴びせてしまったことに対し、 深くお詫びいたします。本当に申し訳ありませんでした。
(01:42)
■ 通りすがり [疲れてる時って、やたら攻撃的になっちゃう瞬間ありますよねｗ]
■
maru [僕が青木さんだったとして、うわさ程度の情報だとしても、憤慨してると思いますよ。
なんて言うか、あり得ないような情報ですもんね。
Rubyに人一倍愛情を持っているからこその、憤りを感じる感情は人間として大事なものだと思います。
誰も青木さんを悪く思う人はいませんよっ。そんなに謝ることでもないと僕は思います。]
■
sat [話題がそれますけど、私は発表を聞いて、こういう風に頑張ってくれている人がいるってことを再認識できて良かったと思います。
色々大変なこともあると思いますが、これからも頑張って下さい。]
■ hiroshi [普通の本書いてるのですか？涼しくなった＝：＝峰郎の屋根に雪降り積む＝：＝季節へ続く。]
Ruby会議2008のリファレンスマニュアル枠について、 去年と同じ話題じゃん (だからいらない) という意見をもらった。 具体的に誰が言ってんだか知らないが、 企画側と観客側の両方から出ていることはわかっている。
そういう意見に対する俺の答えは以下のとおり。
一昨年からずっと同じプロジェクトやってんだからあたりまえだろ。 あれはプロジェクトステータスの報告なんだから、 タイトルも同じにしてんだよ。
まあ、観客の立場ならそういう意見が出てくるのはある意味しょうがない。 ちょっと Ruby に興味があるだけで、 日本 Ruby の会で積極的に活動しようなんて全然思ってない人もたくさんいるだろうし。 リファレンスマニュアルはブツだけあればいいという人もいるだろう…… っていうか、ほとんどそうかもしれないな。
でも、なんでそれと同じ意見が企画側から出てくんだよ。 そもそもリファレンスマニュアル刷新計画は 日本 Ruby の会としてとりくんでるプロジェクトだろうが。 俺はそうだと思ってたから http://doc.loveruby.net/wiki/HowToJoin.html にも 「なお、リファレンスマニュアル刷新計画は 日本Rubyの会の活動の一貫として実施されています」 と書いてあるわけんだけど (あ、typoが……)。
な、の、に、自組織の活動の一環である プロジェクトのためにたかだか20分を割けないって何なのさ。 あのセッションは青木峰郎のセッションではなく リファレンスマニュアル刷新計画のセッションだってわかってないの？
観客から文句を言われるならともかく、 Ruby の会にまで嫌がられるとは思ってなかったよ。 本気で萎えた。デスマ明けに徹夜してまでプレゼンした俺がバカだった。 そんなに嫌がられてまでプレゼンやる気もないし、 リファレンスマニュアルの発表はもう二度とやらない。
(20:31)
いやいややはりこういう感情的な書きかたはよくなかった。 論理的に要点だけまとめることにしたい。
ようするに、まがりなりにも「日本 Ruby の会として」 プロジェクトをやってるんなら 20 分くらい喋らせてくれと。 そのていどもできないなら最初から放置してくれということだ。
まあ、そういうことは開催前に言うべきだし、 最終的には 20 分出してくれてるわけだから、 全然配慮してくれてないとは思ってない。 ただ、このまま黙ってんのもなんか腹が立つんで一言言っておきたかった。
(02:46)
週末はRuby会議2008。 スタッフの人が「まさかLTの途中に来るやつなんていねえよな〜」 と油断している隙を狙って到着してやりました。KY。
んで、わたしの発表は凝りずに 「日本Rubyのリファレンスマニュアル2008・初夏」です。 リファレンスマニュアルも 1 年でずいぶん進みました。 資料とか↓
http://i.loveruby.net/rubykaigi2008/
今年もよいRuby会議でした。 みなさま本当にお疲れさまでした。
あーRubyのコードが書きてぇ〜
(02:02)
Ruby会議のゴルフで「ふつう賞」なる賞があったらしい。 その賞品が「ふつう」3点セット。 内訳は、 『ふつうのLinuxプログラミング』 『ふつうのHaskellプログラミング』 『ふつうのコンパイラ』(出版されしだい送付)
ちょ……待っ
(02:45)
ReVIEW の反応が意外とあったので tar.gz にかためてみた。
自分が使うことしか考えてなかったのでドキュメントはない。 ReVIEW フォーマットの説明だけは以前必要にかられたので書いてある。 doc/format.txt を参照。
使いかたをチョー簡単に書く。
◆インストール
Ruby 1.8 があればオケ。 ちょっと古い 1.9 (M17N 導入のしばらくあと) でも動いてた。今は知らん。 setup.rb でインストールしてもよいけど、 tar.gz を展開してそのまま bin にパスを通せば使えるのでそっちがおすすめ。
◆使いかた / 最初にすること
まずディレクトリを作って章ごとにテキストファイルを作る。 拡張子は「.re」。 でもって CHAPS というファイルを作り、その中には章の順にファイル名を書く。 例えば 1 章が intro.re で 2 章が lexer.re、3 章が parser.re なら、 CHAPS ファイルは次のようにする。
intro.re lexer.re parser.re
また、章を「部」に分けるときは空行を入れる。 例えば以下は「ふつりな」の CHAPS。
intro.re abstract1.re abstract2.re abstract3.re stream_sys.re stream_stdio.re practice1.re practice2.re hier.re fs.re memory.re process.re signal.re etc.re network.re httpd.re httpd2.re advanced.re
また preface.re, postscript.re, appendix.re というファイルを作ると、 それぞれ前書き・後書き・付録と自動認識されて、なんとなくそれっぽく処理される (CHAPS に入れてはいけない)。
あと、原稿は EUC-JP でしか書いたことがない。 Shift JIS だったりすると何か起こるかも。
◆使いかた / 目次出力
review-vol コマンドは章目次と章ごとの分量を表示する。 引数なしで review-vol と打てばよい。その他の使いかたは --help 参照。 「review-vol」は名前が長いので、ローカルでは「list」に alias している。
review-index コマンドは詳細な目次と、章・節・項ごとの推測行数を表示する。 デフォルトの組版メトリックは A5 (ふつうシリーズの大きさ)。 ちなみに A5 だと 1 ページ ≒ 1KB で近似できる。 B5 変形なら 1 ページ ≒ 2KB。 当然ながら、節の分量はあんまりバラつかないほうがよい。 本の分量と内容にもよるが、 ふつうシリーズでは 1 節を 200 行前後にまとめることを目標にしている。 コマンドの詳細は --help オプションを参照のこと。 あと、「review-index」も名前が長いので 「ind」を alias にしている。
◆使いかた / フォーマット変換
review-compile コマンドはフォーマットを変換する。 review-compile --html で HTML を生成、 review-compile --latex で LaTeX を生成、 という感じ。 ln -s review-compile review2html してもよい。 あとは review-compile --help を見よ
◆使いかた / プリプロセッサ
review-preproc コマンドはプリプロセスをかける。 プリプロセスの主な目的はソースコード引用を更新すること。
他人に話すときはフォーマット変換のほうが目立つので そっちを話すが、ReVIEW を最初に作った動機はソースコード引用を自動化することであった。 プログラミング関連書籍における執筆支援システムの役割は、 ソースコード引用に始まりソースコード引用に終わると言うとやや過言である。
◆使いかた / その他
あと、「記述・参照関係のチェック」 (もうこの専門用語は説明したかどうか、みたいなことをチェックする機能) とか「NG ワードのチェック」とかあるんだけど、 説明が面倒なのと、もしかすると今動かないかもしれないので説明しない。 まあ NG ワードなんて grep すりゃ済むから、専用コマンドなんていらんか。
◆ライセンスとか
LGPL。例によって無保証。 あと、いまバグレポートとか機能追加要望とかもらっても絶対に反応できません。 ふつぱいらが書き終わったら反応するかも。
(03:04)
■ seo [GOOD!]
■ ホストクラブ [メ侃ニ、陦」]
■ ケ��HスYサ [メ侃ニ、陦」]
■ ホストクラブ [メ侃ニ、陦」]
■ ライブチャット [メ侃ニ、陦」]
■ ライブチャット [メ侃ニ、陦」]
■ ケ��HスYサ [、隍ッセ圖鬢�Ε宗�」]
■ ケ��HスYサ [量モ側ヒｎ、ケ、��」]
■ ケ��HスYサ [量モ側ヒｎ、ケ、��」]
■ ケ��HスYサ [、隍ッセ圖鬢�Ε宗�」]
■ ケ��HスYサ [量モ側ヒｎ、ケ、��」]
■ ケ��HスYサ [量モ側ヒｎ、ケ、��」]
■ seo拳イ゜ [よかった。]
■ ホストクラブ [だと房わない��]
■ ホストクラブ [メ侃ニ、陦」]
■ ライブチャット [メ侃ニ、陦」]
■ SEO [だと房わない��]
■ SEO拳イ゜ [、隍ッセ圖鬢�Ε宗�」]
■ アレテ諷ァシ{ [チ「、チシト、熙゛、ケ。」、゛、ソ。「゜[、モ、ヒ、ュ、゛、ケ。」]
■ ・ロゥ`・爭ィ・�Д襯�`・ソゥ` [すんなりと樹できると房います。また、゜[、モ、ヒ、ュ、゛、ケ」。]
Copyright (c) 2002-2007 青木峰郎 / Minero Aoki. All rights reserved.
■ hiroshi [青木さま、おつかれさま。お仕事で行かれたんですか？こちらは、規模が小さく北陸（黒部アルペンルート）（１３日〜１６日）行ってきました。疲れは無く、ますます快調になりました。]
■ hiroshi [青木さまは、お仕事！！僕は、温泉つかってました。忙しくならないかなぁ〜。もっと仕事をぉーー。]
■ ささだ [勝った？]
■ 青木 [150負けた]
■ ５分半 [900負けた。
と思ったら、レッドソックスが7点差まくったので500戻しました。]