※ nodejuice は決して 2011年製のアプリではありません。Vimeo 上のデモムービーは 2009年に上がっています。同時に、開発は止まっていません。

ブラウザのリロード自動化2011秋 から読んでもらえると嬉しいです。

ブラウザの自動リロードの話が長くなりそうだったので特に紹介したいものは別エントリにした。まずは nodejuice から。

三行紹介

http://nodejuice.com/

node.js を使ったアプリなんだけど npm からインストールできずにやや面倒くさい。また、割と最近の Web アプリの考え方が分かっていないとそもそも WSGI などの用語が分からない。ということはつまりアプリの動作イメージがつかめない。

実際には

• 特定のフレームワークに依存しない
• ブラウザも選ばない
• HTML を自分で書き換える必要もない

と、かなり素晴らしいツールである。何しろ HTML の調整もせずにブラウザも選ばないとなればあの IE でもリロードを自動化できて、検証のコストを下げることができるのだから。

もう少し特徴を列挙

• ブラウザとサーバの間に入って動作
  • サーバがない場合は自身が Web サーバとして動作(WSGI)
• サーバ側のファイルの変更を検知して通知(seeker)
• アプリケーションの返す HTML に変更を加える proxy として動作
  • ここで seeker の js へアクセスさせる <script> を追加してくれる
  • サーバ側ですべて完結するので複数のブラウザを同時に reload させられるし、ブラウザを選ばない
• アプリケーションサーバ内で動作する必要はないのでアプリケーション環境も選ばない
• 難しいことを考えなくても static なサイトのためにもすぐに使える
• Mac + nodejs + nodejuice なら環境を作るのはそれほど難しくない。やってみた。
  • この Mac 上にサイトを起き、Windows からこの Mac へアクセスすれば Windows での検証の手間も減らせる

準備のハードルは若干高い¹が、より多くの環境での検証の自動化を助けるという意味ではエンジニア好みな感じ。またどの言語、どのフレームワークでの開発にも使えるのが大きい。

※ node.exe で nodejuice を動かせるかどうかは試していないので分からない。

まとめ

nodejuice はアイディアは良いんだけど、使い始めをもう少し簡単にしてくれるとドキュメントや実際に試す人が増えてくるのかなぁという感じ。両方ともあまりに少ないのが難点。やってることのイメージがつけばそれほど難しいものではないと思うが、あまりに声が少ないと不安になってしまう。

それとも気づいてない問題があるのか。WebSocket を使わずに status check しまくり script を挿入しておくのはブラウザによっては壊れやすいような気がしないでもない。デモムービーもよく見ると一部リロードできていないウィンドウがあるように見える。

ちなみに macports からは install できた。他の環境では恐らく手で入れないとダメ。