Lineman.jsの立ち位置
1 comment | 0 points | by WazanovaNews 1日前 edited
Test Double社のJustin Searlsが、the changelogのpodcastで、Lineman.jsについてのインタビューに応えています。
Linemanは、JavaScriptのフロントエンドアプリ開発におけるコマンドラインツール。AngularJS / Ember.js / Backbone.js などがフレームワーク、Grunt / Gulp がビルドタスクの自動化ツールとすると、Linemanは慣習 & 設定（convention & configuration）ツールという位置づけのようです。各フレームワークにおいて、アセットの構築、サーバのmock、ファイル変更時のspec実行などの機能を提供します。Gruntのラッパーでもあるので、そのタスク自動化機能の抽象化レイヤとして、タスクをライフサイクルのフェーズにあわせて実行してくれます。
Railsが10年かけて築いてきたもので、自分が大きなメリットとして感じていたのが、気の利いたデフォルト設定と慣習駆動型のデザイン。JavaScriptのフロントエンドアプリのフレームワークはたくさんあるが、それらに横断でRailsの良い点である、慣習 & 設定ツールに絞ったソリューションを提供したいと考えた。
Railsでのプロトタイプづくりは本当に簡単だった。フロントエンドアプリにおいても、同じことを実現したい。自社のデフォルトのプロジェクトを、Linemanなら2行のコマンドラインで用意できる。
バックエンドがRailsアプリで、フロントにJavaScriptアプリを追加したい場合、独立したかたちですぐに起動できる。新規のプロジェクトだけでなく、既存のアプリでも実現できる。
また、周辺ツールとの関係がわかりづらいところがあったので、Justinの発言とサイトから類似ソリューションとの立ち位置の違いをまとめてみました。
- Gruntやtestemを理解していることを前提条件とせず、もっと幅広いユーザを対象としたかった。
- コマンドラインツールというトップレベルのプロセスをコントロールすることで、他の依存しているライブラリ（必ずしも設定だけで扱えるわけではない。）とのやり取りがスムーズになる。
- ラップをしていても、拡張性がある仕組みにしている。どのプロジェクトでもワークフローの変更が必要になるのは長年の経験でわかっているので、Linemanの設定は全て上書き可能。これが、Linemanが少ない追加コードで複数のフレームワークに対応できる理由の一つ。
Yeomanとの違い
- 機能比較表 -Linemanは、Yeomanみたいに後で切り分けづらい / アップデートしづらいものをデフォルトのプロジェクトにつくらない。
- Yeomanは、タスクの実行順 / タイミング / 繰り返し操作 / 一部だけの変更などを管理できることが中長期的には大切になるということに気づいていないのではないか。
- Yeomanには、タスクのジェネレータがたくさんあるが、コミュニティに任せすぎていて、重要度の整理やアップデートされるのかという点で心配。
- フレームワーク横断で利用できるツールにしているのと同じで、依存関係の管理 / ダウンローダー / パッケージマネジャも特定についてもエンジニアごとに意見が異なるので、特定のものには限定しない。テクノロジーの入れ替わりも激しい分野だし、既存のアプローチはどれも生き残らないのではないかとも思っている。
- BowerやBrowserifyを使いたい場合は、プラグインを用意している。
- 1. Gulpはファイルを中間のステートに書き出す必要がないから、マルチタスクのワークフローで利用すると、Gruntの方が遅い。しかし、全体をビルドをする頻度は低いし、単一のアセットタイプであれば開発において 2 or 3回の変換しか必要としない（例えば、CoffeeScript -> JavaScript -> 連結）ので、生死を分けるほどの問題ではない。大規模なプロジェクトにおいては懸念となるが、異論もあるようだ。
- 2. Gulp（とベースのGrunt）やBroccoli（程度は低いが）の問題点は、ソースがどこで、何のタスクを実行しなくてはいけないか、生成されるファイルはどこに置くかなどを決めて、アプリをエンコードする必要がある。最初のプロジェクトにおいては、取るに足らないな作業だと思うかもしれないが、プロジェクトを重ねるに従って、複雑さは増していく。Linemanをつくった理由は、それを一つにまとめたかったから。Brunch / Mimosa / ember-cli なども同じことを目指していると思う。
- Linemanはウェブアプリのフレームワークからアプリのフレームワークを切り離す試みだと考えてほしい。ウェブに静的なアセットを配信しているんだとわかっている限りは、様々なアプリのフレームワークに対応した、整合性のとれたしっかりしたワークフローを築くことができると信じている。
- これは、クライアントウェブアプリ開発のコンスタンツからうまく慣習やデフォルトの設定を選ぶことで、実現できる。この場合のコンスタンツは、概ね、必要なインプット（JavaScript/CSS言語、テンプレ）とアウトプット（HTML/CSS/JavaScript）である。各インプット型のアセットがどのディレクトリに置かれ、アウトプットをどこにまとめるか、というようなシンプルなことを決めることにより、アプリのフレームワークに関わらずほぼ動作するビルドを提供することができる。
- Linemanとember-cliの比較でいくと、中規模以上のアプリのフレームワークのほとんどは、ビルドのときに特別な対応が必要になるというのがポイントになる。Linemanでは、フレームワーク特有のものがあれば、linema-emberのように、そのビルド設定をLinemanのプラグインとして取り入れる。また、lineman-ember-templateのように、クローンできるテンプレのプロジェクトを用意する場合もある。
ember-cliを利用するケースとしては、
- Ember.jsの公式なアプローチに沿っているので、ビルドの問題を解決するのに、emberコミュニティから学びたい.。
- ember-cliのデフォルトの仕様（quintなど）を気に入っている。
- 全てのプロジェクトをEmber.jsで開発する予定なので、他のツールに乗り換える手間を掛けたくない。
- Emberの基本以外のカスタマイズをする可能性はない。
Linemanをお薦めする理由は、
- プロジェクトごとの設定から解放されて、全てのフロントエンドのプロジェクトで整合性のとれたワークフローがもてる。
- Emberプロジェクトのビルドを簡単につくれる。
- Test Double社が使ってるテストツール（Jasmine / testem / webdriver-sync) との親和性。
- プラグインを利用して、特有の設定が必要になれば簡単にシェアできる。
#linemanjs #javacsript #rails #angularjs #emberjs #backbonejs #grunt #gulp #yeoman