java-ja温泉に参加
先週の金曜日から日曜日にかけて、java-ja温泉に参加してきました。成果物：https://github.com/takano32/party-tracker
別に各人はJavaのプログラムを書くことを強要されているわけではなくて、java-jaコミュニティに近いひと、あるいは温泉でJava書きたいなっていう人たちが集まった感じです。
java-jaにとっては恒例のイベントとなっていて、すでにJavaを書く人は少ないですね。でも、かつてJavaのプロフェッショナルだった人たちが集まってボードゲームしたり、JVMで動作するわけわかんない言語をいじったりしているので、Javaの質問をしたりしてJavaパワーを底上げするにはいい機会かもしれません。
情報戦
java-jaの参加表明の期間には各人が何のプログラムを書くのかを記入する欄があります。これを押さえておいたり、参加者のブログを巡回して参加者がいつも書いている母国語を知っておくとものすごく後々作業がはかどります。なぜなら、その人の隣のポジションをキープすることで、先生を得ることができるからです。
最初、Clojureを書くつもりだったので、太一さんの隣をキープしていじくり回そうと考えていたのですが、温泉に行く前にClojureを予習していたらLISPのいいところがつぶれてる感じでいまいち積極的に使いたい言語にならなかったので、今回は保留してNodeをいじることにしました。
最初、Clojureを書くつもりだったので、太一さんの隣をキープしていじくり回そうと考えていたのですが、温泉に行く前にClojureを予習していたらLISPのいいところがつぶれてる感じでいまいち積極的に使いたい言語にならなかったので、今回は保留してNodeをいじることにしました。
詰まるところ、私はJavaScriptスペシャリストなはぎーさんの隣に座ることにしました。はぎーさんはC++などでOpenNIなどのプログラムをいじるようだったので、少しはぼくも助けになるかな、とか思ったからです。結局、ぼくからアドバイスできたのは最近の std::runtime_error は #include<exception> ではなくて #include<stdexcept> すると使えるようになるになったみたいですよ、という情報だけでしたが・・・
ぼくが今年のjava-ja温泉で書いたプログラム
CoffeeScript + Express + Socket.IO + nTwitter + eco / Node powered by JavaScript で指定したアカウントのタイムラインをTwitter Streaming API で監視するというプログラムを書きました。
Party Tracker という名前が示すとおり、後々は Twitter Streaming API の statuses/filter でキーワードやハッシュタグも監視して、イベントの状況を表示できるWebアプリケーションを作成したいと考えています。
以下、このプログラムを書いていたときに感じたことを紹介したいと思います。
CoffeeScriptの雑感
今年のjava-ja温泉で書いたCoffeeScriptについて簡単に感想というか感触などについてメモしておきます。
シンタックス
簡潔に記述できてすばらしいです。JavaScriptでの記述の冗長性に違和感を感じている方たちにはとてもおすすめです。さらに、JavaScriptの文法が頭に入っていると「おそらくこの記述であの形に変換されるはず」というのがわかるくらいではありますので、HTMLに対するWiki記法くらいの感覚で使うといいかもしれません。表現力についても同じようなことがいえます。Wiki記法が出力する成果物がHTMLを超越することがないように、CoffeeScriptで書いたプログラムがJavaScriptの表現力を超越することもありません。過度に期待するのは止めましょう。
あとは、好みの問題もあるかもしれませんが、オフサイドルールを持っている記述言語なのも個人的にはとてもよい言語だと感じました。今どきにありがちな "->" で関数を表現したり、オフサイドルールによってブロックを表現するなどの手法をもちいることで、とにかく簡潔で読みやすいプログラムが書けます。
私はシンタックスについてはとても気に入りました。JavaScriptに対してCoffeeScriptというものができたと考えるならば、Javaに対応したCoffeeという重めの記述言語があってもよいかもしれないと感じたほどですね。
エラーメッセージ
エラーメッセージはJavaScriptがわからないと言っていることの意味がわかりません。CoffeeScriptでJavaScriptの知識がなくても簡単にプログラミングできる！みたいな夢をもっていた方たちはすぐにJavaScriptの勉強をしましょう。
気になるポイントとしては、 "coffee" コマンドで hoge.coffee などを実行したときにエラーが起きているファイル名は hoge.coffee なんですが、エラー行が "coffee -c hoge.coffee" しないと作成されない "hoge.js" の行数ででてきているあたりが気になりました。どうせなら中間ファイルをはき出してエラーファイル名と位置を変更してほしい。これはおそらくエディタやIDEが発展してきたらどうやって開くのか謎、みたいなことになりそう。
Cakefile
CoffeeScriptの簡潔な記述でタスクを記述できるのがよい。Rakeの影響を大きく受けているようで、すんなりと記述することができた。DSL で定義されていると思われる exec の使い勝手もなかなかで標準出力と標準エラー出力などをうまく扱うことができてよい。
ただし、注意すぺきポイントとしてはデフォルトのタスクが登録できない、利用できないところだと思う。 "cake" とターゲットなしで実行したときには "rake -T" 相当の挙動となり、登録されているタスクの一覧が表示される。
なお、この事項についてはすでに検討済みのようなので、チケットなどを新しく作成してもおそらく方針が転換されることはないと思う。
ぶっちゃけ、今回の用途では Makefile でもよかったのですが、なんとなくプロジェクト全体の流儀をCoffeeScriptでまとめているときにCakefileを使わないのは気持ち悪いので使いました。
Socket.IOが便利すぎる
今回のプログラミングで充実感を得ることができたのはSocket.IOライブラリのおかげかもしれません。Socket.IOライブラリを使うことで簡単にクライアントとサーバの非同期通信のプログラミングを行うことができました。
WebSocketの仕様を追いかけていた人たちにはわかることだと思いますが、WebSocketの仕様がとにかく不安定で、こいつを生でいじる気にならない。いまでもブラウザごとに挙動が異なるはず。ところが、このSocket.IOというのは賢いやつで、それぞれのブラウザで利用可能なWebSocketの実装を選んで勝手に効率のよい通信方法で結んでくれる。場合によっては勧告されていた期間の短いドラフトの実装でも使ってくれるみたいだし、最悪の場合はXmlHttpRequestまでフォールバックして通信してくれる仕組みになっているので、とりあえずSocket.IOを使っておけばクロスブラウザプログラミングを意識しなくても動作するというのが大きい。今後も積極的に利用したいライブラリだと感じた。
ただし、こいつの中身は前述の理由からクロスブラウザプログラミングなどの汚い部分をギュウギュウに細密充填したようなものになっているため、中身は相当な覚悟がないとダイブして読み砕くことができないと思う。実際、自分くらいのレベルではすべてを追う気にはなれなかった。すでに歴史あるライブラリである。
Node の今後を予想
閑話休題。
と、思ったんですが、ここまでの話が長くなったので別の機会に「Node とそれを利用したプロダクトの未来を予想」というタイトルでエントリを書きます。
