体験って何だ・・・ というのは置いておいて、Excel2007 Betaをインストールしてみました。(正確にはOffice2007 Pro Betaだが)
メニューがなくなってリボンと言う奴になりました。最初は手惑いそうだけど操作自身は本質ではないし、まあ慣れれば気にはならないかも。マウスでオペレーションする方向になったような気はする。ちょっとしたことをするにもいちいち探索することが多いが、右クリックでうまく乗り切れそうではある。もうプルダウンメニューに飽きたし、IE7もそんな感じなので、Vistaではだいぶんかわるのだろう。とりあえずいろいろつっこみどころ満載のExcelで遊んでみよう。ざっくり使えるように設定の変更。
今年もLightweight Languageの年に一度のお祭りであるLightweight Language Day (and Night)に参加してきました。チケットの発売に気がつかなかったので、何とか買えた昼間の部のみ参加。
今年の僕が感じた目玉のひとつ目は、GNU awk(gawk)のXML拡張であるxmlgawkであろうか。僕がgawkやnawkを使っていたのは学部の4年目のころで、あのころは日本語化パッチを当てたjgawkをメインに使っていた。(今にして思うとperlのプログラムも結構書いたけどawkほど使ってないな。) 気がつけば国際化されて、キーワードが増えてXML文書をSAXっぽく扱えるようだ。この拡張はgawkの先端開発版という位置づけで、コンパイルオプションで無効にできるそうだ。awkは行指向ツールとしてはperlやrubyより使いやすいところはあるので、まだ開発が行われていて進化が続いているのかと言う驚きとともに、昔師匠のawkの技でうんざりしてしまいやめてしまったawkであるが、再び遊んでみたいなあと思ったのである。(僕の師匠(指導教官ともいう)はawkとかPostScriptのプログラムをサクサクと・・・)
二つ目は全然追いかけてもいなかったけどPerl6周辺の話。昨年のLLでは北京オリンピック頃と言っていたPerl6であるが、この1年でPerl6のHaskellによる実装(Pugs)を行ったという天才が登場して、突如として開発が加速しているようだ。それにしても1ヶ月でHaskellを覚えて、Perl6の仕様を具現化してしまうとは。若い天才的な人物の登場というのはなかなかエキサイティングなことだったのだと思う。小飼さんのPerl6のデモを見ていたのだけれど、Perl5との互換性を捨てているせいか、言語自身がリファインされて、どことなくrubyに近づいているような・・・ 似たような機能を影響しながら追加していくと、結局PerlとRubyとPythonを足して3で割ったような言語ができるのだろうか？ もうちょっとPerlの良いところであり悪いところでもある毒々しさを残して置いて欲しいのだけれど。
他の言語に関しては特に進展があったわけではないのでここで述べる必要もないと思う。ざっと10個の言語プレゼンを聞いたのであるが、聞いた結論としてLightweight Languageとは何だろうかと思ってしまう。個人的なLightweightであることの定義付けであるが、まず最初に軽い記述で高度な処理ができること、次にたいていの人にとって理解しやすい概念のみでプログラム可能であることかなと思う。そういう点でエヴァンジェリストの方々には大変申し訳ないが、monadsとか、Curry化とか、継続とかが一般に理解されるようになるとはとうてい思えない。(一応分かりやすいと思う解説へのリンクは貼った。) むろん関数型プログラミングの威力は理解できるのだが、果たしてLightweightなのか？ 誰しも知っていて当たり前なのか？ と言うあたりが僕は知りたい。(Scheme的にはSICPを読めと言う話だと思うのだが、みんなしなければならないもんでも無かろう。) ちなみに僕自身はLightweightに関係なく関数型な言語の1つはプログラマを志す人は教養レベルでも良いからやっておくべきだと思ってはいる。第一、面白いし。
フレームワーク対決については、Kahuaは昨年のLLで面白いツールだと思っていろいろ調べていたので、面白くデモを拝見したのだが、もう少しうまく説明できればなという場面が多かったかも。Ruby on Railsについては、一度デモを見ておきたいと思っていたので、今回のプレゼンは参考になった。みんなが凄いというだけあるな。うちのサーバにインストールというのはバックエンドDBをインストールしたくないので保留としても、試験動作環境のDebianマシンには入れてみてもいいかも。ちょっと検討してみよう。Sledgeについては今更Perl Baseなシステムを持ちたくない(我が家の環境でPerl依存なものはもうほとんどない)ので、意見は保留。
「君ならどう書く」というセッションは、漢数字を扱う電卓ということで、面白く眺めさせてもらった。今回の漢数字の定義自身が、一般的ではない(世間的には無量大数まで万進のはず。今回はどの桁か忘れたけど万万進に切り替わる)こともあり、パースをどうするかというところが面白かった。(万万進の場合は人間が聞いてもよくわからなくなるので、少なくとも国内では廃れている。) 桁数が多くなれば誰しもがやるように、下の桁から勘定すればいいのよね。今回は個人的にはプログラム可能な電卓を作りこんでいたPythonのチームが秀逸であったと思う。
あと自由演技のsfの小林さんなのだが、科学技術計算という論点では特に行列計算ができる計算機という位置づけだったかと思う。この手の計算は特に実験系の人は常に悩ましいと思うのだが、測定器が吐き出すテキストデータをなんとかパースして、どう配列に取り込むかという点でいつも悩むところがあるが、このプログラムの場合データを表のようなものに落としこんでテキストファイルとして、テキストファイル自身が行列やベクトルをあらわして、ファイル名を記号として使えるような計算に特化したシェルのようなものという風に読めたのであるが、あの場で量子力学の固有値計算をするのはどうかと思う。説明によっては面白いと思うのだけど。ちなみに僕はあの規模の計算は普通にCで書くべきだと思う。いろいろ悩ましいけど。
毎年こんな見出しで大晦日の日記を書いているわけだが、ついこないだ2003年もおしまいどころか2002年もおしまいなんて言う記事を書いた気がするのは気のせいではない。今年は転職・引越しと人生の転機となる大きな変化のあった1年で、住環境や人間関係もがらっと変化して、めまぐるしい変化があった1年だった。気が付くともう今年もおしまい。今年お世話になった方々はいっぱいいて名前を挙げきれないが、今年1年本当にありがとうございました。来年もよろしくお願いします。
大晦日と言うことで、行く年に思いをはせ、今年はどういう戦いの1年だったか、今年の戦術・戦略とその戦いの成果を主要な分野別にまとめておこう。(と、ほぼ毎年と同じ文章にしてみた。こういうのは毎年そろえておいたほうがよいもので、断じて_手抜きではない_。)
2004年の戦況がどのようなものであったか述べていくことにする。前の会社の上司の年賀状には_今年は攻めと成果_と書かれていたのだが、個人的には攻めに攻めた1年だったかと思う。アクティブに変化を求めて行動したが、いまいち成果があったとはいえない。まぁ来年あたりから取り返していきたい。今年から技術系よりは研究系に寄った立場になったので、より注意して形になるように成果を残さねばと思うのである。(これは特に本業について言える話。)
経済的な状況は現段階でほぼ解決した状況(今年はでかい収入と出費があって、これまでのごたごたはほぼ解決したといってよい) 今後は多少余裕はできると思うので今年あたりからちゃんと貯蓄に励もうと思う。なかなか自力で解決できないのだが、残りは車のローンくらいだし…
今日も関東で揺れを感じました。会社から家まで遠いとどうやって帰ろうかと悩んでしまいます。(今地震になって交通が寸断されたならば、まず荒川を越えるのが厳しそう。)
なんだか身の回りのインストール熱が上がっているので、いろいろサーバに仕込んでしまおうかと。いったん考えている大きなものは、
Ruby1.6系からRuby1.8系への入れ替え
もうデファクトなライブラリの追加インストールがめんどくさいので。
Gauche のインストール
やっぱSchemeを使ってみようと言うことで。cosmosには導入済みですが、展開をする。
と言うところ。さらにこまごましたところでは、何個か必要なアプリケーションにぶら下がっているライブラリの入れ替えかな。
zphoto
2日目の前半は最近はやりのblogな話題。僕は基本的に興味がないのだが一応お勉強のため… 大きなblogサイト(Livedoor Blog)やはてなダイアリーなど)の方が来ていたので、個人的には「(政府や各種圧力団体などから圧力がかかりそうな)非常にまずい記事の削除要請があった場合にどのように考えるかの立ち位置」を効きたかったのだが、LLには関係ないし、契約で乗り切れる話かもしれないし、あまりにダークなんで聞けなかった。聞いておけば良かったかな？ LLの最も巨大な応用先であることは認めるが、blogだけでこんなに時間を取るんだったら他の話が聞きたかった。
Lightning Talkは詳細はあまり覚えてない。(なんせ半分くらいBitKeeperと話をしていたので。) 平内さんの「木のマッチ」では、Schemeを使用した木構造のデータに対して正規表現みたいなパターンマッチをする話。さくっとXML VallidatorがかけるあたりがSchemeのマクロらしい。久井さんの「Gauche-glによる、3次元図形言語」では、Gauche-GLとストリーム(SICP Chap3の後半)を使ったアニメーションによるプレゼンでGaucheではこんなこともできるのかと言うこともあってこれまた面白かった。
高橋さんの「日本Rubyの会設立」の話は要点とをついたインパクトのあるプレゼンで、こうあるべきかと思ったり… 早川さんの「LL侍」は最初は照れが見えたが、吹っ切れたあとはかなり面白かった。(もう一段切れが欲しかったかな。)
行ってきました。ざっくりとした的確な要約は、まつもとゆきひろさんのMatzにっきを参照。(こんな手抜きで良いのかな。)
あまりに手抜き過ぎなので、印象深いところをかいつまんで。今回はPerlにしてもRubyにしてもPythonにしても大きな変化がなかった1年なので、逆にマイナーな言語の存在が目立つカンファレンスでした。特に、SchemeやHaskellと言った関数型言語の人が目立ったなぁ。
今回特に面白かったなと思ったのはSchemeの1実装であるGaucheですかね。ここ数年Schemeは忘れ去られていた感がある(入門的な書籍類が全て無くなっていたので)のだけども、国内的にはGaucheのおかげで復権したと考えて良かろう。またどの言語でもキラーアプリがあれば動き出すのであるが、Gaucheは継続ベースのWebアプリケーション・フレームワークであるKahuaが最近広まってきていて、その紹介などがあった。HTMLをさくっとS式で書けるのは良いかもしれない。あとSchemeを勉強していてサッパリ分からないものの一つが継続で、これはいったいなんじゃろ？と言うあたりが今回少し解決した。今日あたりから「何でも継続」を読んで、真面目にSchemeで遊んでみようと思います。SICPでは凄く後のほうに載っていますが、LISPとは根本的に違うScheme特有の概念だと思います。
あとGroovyの話も面白かった。(「Javaの奇妙な冒険」と題した後半は爆笑物だったが。絵は補完すること。) JavaVMの上でJavaのSyntaxに似た言語で、Ruby-Likeなクロージャー(一昔前までイテレータと呼んでいたもの)を書ける言語で、出かける前にこれはなんじゃろねと言う話をしていたが、なるほどなと思いました。(出かける前までは_またよく分からない俺言語誕生かと揶揄していたので_)まぁよく考えれば、JavaVMのパフォーマンスがあがれば、何の変更もなくパフォーマンスが良くなるわけだし、もっとも多くのVM開発者がいるのはJava周辺ですから、こういうアプローチはアリかもしれない。(JavaのAPIをそのまま使えるというのはおまけだろう。)
「LLでお仕事」のBOFではいろいろと悲しい話を聞く。まぁ今回のカンファレンスではJavaは明らかにアウェーであるのは確かなのだが、LL全体としてはCやC++、VB、Javaに比べると立場が弱い。あとLLの中でもPerlは割と認知されているが、「Rubyで書いた検証プログラムを顧客の無理解から泣く泣く書き換えた」というかなりショッキングな話もあって、三浦さんとPerlで書き直したソースを解読するよりrubyを勉強する方が時間かからんだろうなどと言っていたのだが、何とも切ない話だ。クライアント側で考えると選択できる言語の幅は狭いので泣く泣く環境を選ぶことはあるのだが、サーバーサイドなら何とか選べるんじゃないと言う意見もあった。あと印象的だったのは、まつもとさんの_「秘密兵器」としてサクセスストーリーを積み重ねるしかない_というもっともな意見で、僕もそう思う。まぁこういう便利なものは便利と悟った人が効果的に使えばいいのかなと思う。
「君ならどう書く」のセッションでは前半は「ls-lRシェル」、後半は「n-Queen」ゲームと言うことだったが、前者は各種言語の考え方は分かるのだが、デザパタに当てはめるのは結構無理があるような… 後者はプロトコルは格好いいんだけども、ゲームバランスが… HTTPでなくて独自プロトコルの方がまだ良いかもしれない。あとルール的には誰かが負けるとおしまいでなくて、最後まで残ったものが勝ちとすべきだったかもしれない。まぁ来年以降の課題ですな。
今日は久しぶりに早く帰ってきた(とは言え21時)ので、violaからcosmosへメールフォルダ(~/maildir)の移動とSPAMフィルタの導入を行った。今回はIMAPサーバをたてないのと、procmailを使いたくないのでメールの読み書きなどの全て処理はcosmosで行うことにした。
昨日Wanderlustを入れておいたので、WanderlustからSPAM Filterを直接扱えることとせっかくだからRubyベースのSPAM Filterにしてしまえと言うことで、Spamassassinからbsfilterに変更してみた。なかなか軽快に動作するようなので、しばらく試してみよう。
ここを読んでくれているみなさん、僕の写真を楽しんでくださるみなさん、昨年は本当にお世話になりました。ありがとうございました。今年も変わることなくよろしくお願いします。昨年と同じですが、「一年の計は元旦にあり」と言うことなので、今年はどのような戦いを展開するか、「戦いの軌跡」と言う題にしているので、戦術や戦略について分野別に纏めておこう。
2004年の野望(何の?)を達成するための、戦術や戦略を述べていくことにする。上司の年賀状にも_今年は攻めと成果_と書かれていたので、アクティブに課題に当たり、しっかりとした成果を残さねばならないと思う。今まで攻めてはいたけど、成果を形にすることに拘っていなかったので、なるべく形になるように残さねばと思うのである。(これは特に本業について言える話であるが。)
経済的な状況はまぁ怪しい上に_新年早々車を買い換えることにした_ので、これを糧に仕事をするモチベーションを創出することとしよう。いやぁがんばらねば。あと多少余裕はできると思うので今年あたりからちゃんと貯蓄に励もうと思う。2月までを乗り切った後は何とかできると思う。
年末もそうだったが、やっぱり体調を壊しがちであることは否定できない。食生活はなるべく改善する方向で何とかしているので、あとは機会を見つけて運動をせねばなと思うけど。時間を作って対応するしかないか。
今日は某社まで日帰り出張です。(アンカー打って良いのか?) つ、疲れた。
先日某MLで話題になった「計算機プログラムの構造と解釈」を仙台の書店で探索したのだが、ここ最近の仙台の書店で欲しいと思った本はすべて在庫として持っていないことが分かった。この本も見つけられなかったので、八重洲ブックセンタにて購入。(ここでも危うく見逃すところだった。) この本は巷で「Wizard Book」と呼ばれている有名な本である。
原書は「Structure and Interpretation of Computer Programs」で、本文はWebで読むことが出来る。非常にありがたい本なのである。原書のWebを読めば分かると思うが、僕の貧しい英語力でも文章の良さを理解できる非常に素晴らしい文章なので、出来れば原書を読むのが正しいと思う。この本を日本語で読めるという_気軽さ_も必要だと思うので訳書を購入。おそらく原書も買うことになると思う。
僕の経験では、国内の著者が書いた自然科学・工学の分野の日本語の教科書で_文章の良さを感じる_本を_読んだことがない_。僕の貧しい英語力で英文の素晴らしさを感じることが出来る教科書を見てしまって、思わず日米の教育水準の違いに愕然とせざる得ない。(ちなみに前回愕然としたのは「Feynman：Lectures on Physics」で、ちらちら読んだのはもう10年以上前の話だ。) こういうあたりに国語教育の問題点(物を書く教育をしないことや、読むことに関しては小説の偏重していることや、論理的な討論をする演習をしないことなど、他にもいっぱい)を見いだしてしまうのだが、そんなことを言っても僕の国語力もかなり怪しいので、こういうComfortableな文章を読みあさって日本語にフィードバックするしかないのですな。精進が必要ですな。
話がそれてしまったが、一言で言えば_この本は凄い本_である。(おおざっぱな意見すぎて失礼すぎるか。) 内容は難しいと思うが、こんなに面白いと思って読める本はなかなかない。SchemeなどのLISP系な言語は実際の仕事に直接役立つかと問われれば、おそらくすぐには役立たないと思う。ただ_役立つ/役立たないという思考軸だけが世の中の本質ではない_と思うのである。_読んで・手を動かしてソースを書いて楽しい・面白い_ということの方が遙かに重要だと思うのである。
ということで、しばらくこの「魔法使いの本」を読みつつ、魔法使いの弟子になってSchemeの呪文で遊ぶことになりそうである。もしCやC++やJavaやVBでしかプログラムを書いたことがないと寂しい経験しか持っていないと言う人には、_全く異なる物の考え方_をかいま見るためにもこの本を読んで、LISP系の言語をさわるべきなのかなとLISP万年初心者の僕も思うのだから、必読の書といえるのだろう。
帰りの新幹線でひたすら読む。1.1.4 Compound Proceduresあたりからだんだん深みに誘われてくる。とりあえず、帰りの新幹線で読んだ範囲で目から鱗だったのは、1.2.2 Tree RecursionのFibonacci数列の計算で、再帰を使った計算はFibonacci数列の漸化式から理解できるのだがこれは非常に効率が悪い。Fibonacci数列の計算を反復的なステップで計算するあたりでなるほどと思い、1.3 Formulating Abstractions with Higher-Order Proceduresで、Schemeの教科書を読んでいまいち想像が沸かなかった高階手続きといままでLISP系の本を読んでlambda記法のありがたみがいまいち分からなかったが、何となく見えてきたこと。理解するためにちゃんと手を動かさないと駄目だと思ったところ。とりあえず第1章だけでも読んで手を動かすところ満載なのである。