第2イテレーションの振り返り

はじめに

おはようございます。当ブログにアクセス頂き、ありがとうございます。
肩甲骨周辺の筋肉をほぐすと代謝が上がると聞き、日々肩を回している、たなけんです。
本エントリでは、第2イテレーションを振り返ります。

Clojurescriptおよび各種ライブラリを利用した所感

Clojurescriptの利点

Javascriptに馴染めない、という理由からWebクライアントの開発言語にClojureを採用しました。Google Closure Libraryで提供される関数やオブジェクトを利用する感覚が、通常のClojureからJavaのライブラリを利用する感覚に非常に近く、スムーズに開発を進めることができました。また、DOMやイベントの操作についての関数が十分に整備されていたことも、開発効率の向上につながりました。

Clojurescriptの欠点

多少違和感があった点としては、通常のClojureでは副作用を期待する処理にdoマクロを用いるのですが、Clojurescriptではdoマクロを用いずに次々と式を評価していく点があげられます。ライブラリの読み込みや表の描画など、戻り値を利用しない処理が多く、この点は若干の気持ち悪さがありました。

コンパイルとデバッグ

ClojurescriptからJavascriptへのコンパイルなど、導入前は手間が掛かることを想定していたのですが、lein-cljsbuildを用いることで、コンパイルを意識することなく開発を進めることができました。ただし、デバックについてはFirebugを用いてJavascriptのコードにブレイクポイントを設定し、エラーを解析する必要がありました。この点については、HTML 5で提供されるsource mapを利用することで、解決できるのではと考えています。

repl

Clojurescriptのreplは通常のClojureのreplほど洗練されておらず、若干使い勝手が悪かったです。そのため、Clojurescriptで提供されている関数の動作を確認する程度にしか利用しませんでした。この問題は、Emacsとの連携で解決できそうです。(本家サイトのEmacs連携のWikiページ)

Google jsapi (visualization API)

表や図などのオブジェクトが提供されており、自分でtableタグなど書く手間が省け、開発時間を短縮することができました。また、オブジェクトへのidの付与など、今回は利用しなかったものの、通常の利用では必須となるであろう機能も用意されており、また機を見てAPIを調査したいと思います。

Twitter Bootstrap

正直あまりUIに時間を掛けなかったので、なんとも言えません。
動的にCSSを生成するフレームワークとしてlessを採用しているようですので、こちらも機会を見て掘り下げてみたいと思います。

今後利用してみたいツール、フレームワーク

Clojurescriptについて調査を進める中で、気になるツール、フレームワークがあったので、この場を借りて紹介したいと思います。

lein-cljsbuild (複雑なソースのビルド、テストの自動実行)

今回はコンパイル機能のみを利用したのですが、その他にもClojure(.clj)ファイルとClojurescript(.cljs)ファイルを別ディレクトリに保存しておき、ビルド時に1つのJavascriptを生成する機能や、PhantomJSを起動してテストを自動的に実行する機能などをlein-cljsbuildは持っているようです。
特にビルドに関してですが、クライアント側で実行するコードであっても、純粋なClojureで記述できる部分がcljファイルに保存できると、単体テストの仕組みなどをサーバ側と統一できるため、非常に開発効率が上がると思います。
さらに、cljsソースとcljソースが粗結合となるため、Sinon.jsなども絡めることでcljs(ブラウザの操作などを含む不純なClojurescript)コードのテストもより単純化できるのではと感じました。

Clojure one

Clojure oneはサーバ、クライアントの双方をClojure(Clojurescript)で開発可能にした統合Webアプリケーションフレームワークです。単体テストの仕組みなども組み込まれているようで、非常に便利なのではないかという印象です。便利な反面、何かしら制約があるかもしれませんが、次回ClojureでWebアプリケーションを利用する際には、実際に使ってみようと考えています。

Bishop

BishopはClojureで書かれた、HTTPリクエスト処理ライブラリです。Webmachine互換のAPIを持ちRestfulなWebサービスを実現するために利用することができるようです。

クライアントサイドMVCフレームワークについては後述しますが、Webアプリケーションのあり方として、ロジックはサーバーサイド、描画と操作はクライアントサイドにまとめてしまった方が良いのではないかと個人的には考えています。Bishopは多様なリクエスト処理関数を実装しており、ロジックに特化したサーバサイドのライブラリとして、有用なのではと、密かに目をつけています。

クライアントサイドMVCフレームワーク

Bishopの項でも述べた通り、ブラウザでの描画および操作はクライアントサイドで完結させたいと個人的には考えています。そういった要望に応えるのがBackbone.jsやSpine.jsなどクライアントサイドMVCフレームワークです。

Coffeescriptの練習がてらSpine.jsを利用した感想としては、「何故、今までこれを使わなかったのだろう」と思ってしまったくらいに便利でした。(JavascriptではなくCoffeescriptでモデルなど定義できたからかもしれませんが。。。)

今後、クライアントサイドの処理が複雑なアプリケーションを作成する際には、ClojurescriptとこれらのクライアントサイドMVCフレームワークを組み合わせて実装出来ないか、検討したいと考えています。

今回の作業は以上。最後までお読み頂き、ありがとうございました。

たなけん(作業時間30分)