2011-09-03 [長年日記]
_ node replと生jshint
生のjshintの使い方
commit 3c77ac で確認。
- JSHINTという名前空間の中に処理が収まっている
- JSHINT( src, opts ) の形で lint を実行
- src は当然文字列、opts は JSON ?
- error がなければ JSHINT() の戻りは true で、あれば false
- JSHINT.data() で実行時の細かいデータが取れる
- JSHINT.report() はこれを HTML 化してくれる
- error は JSHINT.errors というプロパティに収まっている Hash の Array を見れば分かる
- ただ残念なことに JSON のように見えて valid な JSON ではないので、この情報を JS 以外の環境でそのまま扱うのは難しい。
以上のことをnode replで確認する
- node >
- var JSHINT = require( /PATH/TO/jshint.js ).JSHINT
- var fs = require('fs')
- JSHINT( fs.readFileSync( /PATH/TO/jshint.js, encoding ) )
- // => true
- jshint.js 自身を一部書き換えて保存（例えば末尾に , を足すとか）
- JSHINT( fs.readFileSync( /PATH/TO/jshint.js, encoding ) )
- // => false
- JSHINT.errors
結果、
[ { id: '(error)',
raw: 'Extra comma.',
evidence: ' wsh : true, // if the Windows Scripting Host environment globals',
line: 320,
character: 29,
a: undefined,
b: undefined,
c: undefined,
d: undefined,
reason: 'Extra comma.' } ]
当たり前だけどチェック対象は文字列なので、どのファイルのエラーなのかという情報はない。ここは呼び出し側で対応を取ってやる必要がある。
なるほど。
fs.readFileSyncにはencodingを忘れずに
fs.readFileSync( path, encoding )
なんだけど、encoding を与えないと文字として解釈できないっぽい？ ASCII のファイルでもダメだった。数字の羅列になってたので codepoint 的な何かになってるのかなぁ。
とりあえず utf-8 にしたら動いたけど、たぶん ascii でもいいんじゃないかな。試してないけど。
2011-09-04 [長年日記]
_ Rubyのexecjsがすごい件
できることと起動方法とエンジンの違い
- RubyスクリプトからJavaScriptコードを実行できる
- V8, node, spidermonkey, rhino などの中からそのとき利用できるエンジンを autodetect して実行してくれる
- 環境変数からエンジンを指定できる
- ExecJS::Runtimes の中で定義されている RubyRacer や Node の名前で export EXECJS_RUNTIME=Node などと指定する
- 例えば Rhino は therubyrhino gem に依存する。こうした依存 gem は自動では入らないので注意が必要
- 何の gem も準備していなければ execjs 1.2.4 の段階では node.js, JavaScriptCore, SpiderMonkey, JScript の順で利用可能かどうか探してくれる。
- 当然上に挙げた ExternalRuntime は外部プロセスの起動が入るので重い。Node よりも TheRubyRacer で V8 を直接叩いた方が速い。
※ 手元でいくつかのファイルを jshint に掛けるツールを動かしたら TheRubyRacer で 0.14s 掛かる処理が Node だと 2.28s 掛かった。だいたいこの数値で安定しているので、16倍くらい違う。数が多くなればなるほど差は開く。
Windows の人も node.exe に PATH が通ってれば node.js で動かせる。残念ながら今のところ Windows では npm は動かないので node.js の旨味がだいぶ減ってしまっているんだけど、execjs を使えば node.exe を使うスクリプトを自由に実行することができる。
というわけで手始めに jshint4rというものを作りました。使ってみてね。
簡単な使い方
- exec
- eval
- compile & call
の3つの使い方がある。
副作用だけで希望の処理が実現できるならそのまま exec にコードを与えれば ok. 戻り値が欲しい場合は eval で呼ぶ。
ExecJS.exec('1 + 1') # => nil
ExecJS.eval('1 + 1') # => 2
中で
execは(function( ... ){})()
の中に source を入れて実行するだけなのが exec. この前に return を置いて値を返すのが eval.
call は eval の応用みたいな感じで、compile 済みの JS ファイルの中のある function を call する格好になる。例えば
context = ExecJS.compile('function add() { return 1 + 1 }')
context.call('add') # => 2
呼び出し方は
context.call( FUNCTION, ARG1, ARG2, ... )
みたいになる。たぶんちょっとやってみればすぐに分かると思う。
気をつけなきゃいけないのは compile に文字列を与えるところかな。だから例えば jshint に JavaScript のコードを与えたい場合は
context = ExecJS.compile( File.read( /PATH/TO/jshint.js ) ) context.call( 'JSHINT', File.read( /PATH/TO/SRC ), opts )
みたいな形になる。（ただし、JSHINT 関数は true か false しか返さないため、このままでは使いものにならない。）
JavaScript 側に特別手を入れずに Ruby でその実行結果を活かそうと思ったら eval か call を使う形になるのではなかろうか。
まとめ
compile とかうまく隠蔽すればかなり自然に Ruby コードの中から JavaScript を実行してその結果を利用することができると思う。TheRubyRacer を使えばオーバーヘッドもまったく気にならない。
いやこれはすごいな。JavaScript は今後もどんどん応用範囲が広がって行くと思うんだけど、その成果を丸ごと（対応していないオブジェクトはダメだけど）いただくことができる。なんて贅沢。
おまけ
Rails 3.1 から execjs を利用しているため、何らかの JavaScript Runtime がインストールされていないと Rails 環境を起こすことができない。
Windows の場合は WSH が、Mac の場合は JavaScriptCore が最初から入っているので問題ない。Linux の場合はなんらかの JavaScript 実行環境が必要になる。node.js をやっている人はこれを利用するので問題ないけど、普段そこまで JavaScript に入れ込んでない人は TheRubyRacer でも TheRubyRhino でも入れるとよい。いちばん簡単に入るのはたぶん SpiderMonkey じゃないかな。結構いろんな環境でサクっとインストールできるはず。
2011-09-05 [長年日記]
_ jshint4rというものを作りました
なんてことはない、単に jshint を Ruby を通して実行するだけのツール。
なんで作ったか
- npm の jshint ではファイルの除外ができない（たぶん）
- npm の jshint の出力がイマイチ
- jshint_on_rails gem は同梱の Rhino に依存しててスクリプト内の日本語を問答無用で unsafe character 言いまくってうざい
- 外から文字コードを教える方法が分からない
そのうえで、JavaScript の lint 系ツールは手軽に実行できるやつがいい。
jshint の情報をそのまま Ruby で扱えるようにして自分でいろいろカスタマイズできたら便利じゃね？と思い立つ。
特徴
- execjs を通しているので幅広い JS 環境で動く
- custom reporter を書けば様々な出力形式に対応できる（標準で npm の jshint っぽい出力の他に emacs の compilation-mode 対応形式を用意）
- custom reporter 自体は npm の jshint にもあるんだけど Ruby の方が慣れてるし
- 実行バイナリも用意してあるのですぐ試せる
動作環境
- Ruby 1.8.7 と 1.9.2 で確認
たぶんWindows でも動く
Unicode 以外でできたスクリプトがどうなるかは知らない。
使い方
gem install jshint4r
しておいて、
jshint4r [options] path1 path2 ...
か、あるいは自前のアプリやライブラリの中から
require 'jshint4r'
していい具合にオプションを与えて自由に利用することができる。はず。
ツール
以下のようなものが使えるはず。
苦労したところ
- jshint そのものの使い方がよく分かってなかった
- execjs のドキュメントが全然足りてない
- jshint の返す情報が valid な JSON でなく、どう解釈したらいいのか迷った
- file の exclude が面倒で、結局 Rake::FileList を使った
まとめ
意外にというか予想通りというか、とにかく便利。compilation-mode からジャンプできるし、何回実行してもダルいとか言わない。
でもなんか node 力も Ruby 力も足りてない気がした。
2011-09-10 [長年日記]
_ rackアプリのサーバサイドでHTMLをチェック
まとめ
- tidy を文法チェッカとして使う rack middleware は rack-htmltidy だが、1.8 専用
- しかも HTML 5 には対応していないのでスマホ版などイマドキの HTML に対応できない
ということで、HTML 5 対応を考えなければ rack-htmltidy を使えばなんとかなるのですが、ちょっと寂しい状況ですね、これは。
背景
しばらく前からWebのフロントエンドの作業をする際にはこのFirefox add-onを使っていました。
しかし Firefox が 5.0 になり、release サイクルが変わって以降、Windows 版以外は source が配布されるのみになってしまいました。さすがに Firefox add-on のために自前 build とかやりたくないし、そこまでの死活問題でもないし、まぁいいかと見送っていたのですが、先日 HTML の構造を壊して手痛い時間の浪費をしてしまったので、一度真面目に考えないとなーと思っていたところでふと気づきました。
サーバサイドでチェックできればいんじゃね？
Bingo でした。rack tidy で検索するといくつか見つかります。というわけで現状を整理してみたいと思います。
Html Tidy
まず今回の話で出てくるいちばん大切なソフトはこれです。
HTML Tidy とはとても古いソフトウェアで、
- HTML の cleaning
- HTML の構文エラーの警告
の2つの機能を持っています。先の HTML Validator も中で tidy を実行するモードを備えています。
tidy gem ( 1.8 )
メンテされていないので fork バージョンが多数存在しますが、今でもこれを参照しているプロジェクトが多いです。以下の 1.8 用の gem は基本的にこれを参照しています。
rack-tidy ( 1.8 )
チェックではなく HTML の書き換えを目的にしているので、自分の意図とは合いません。また文字コードの扱いもあるので自動書き換えものはけっこう危険。
rack-htmltidy ( 1.8 )
こちらも tidy gem を使ったものでチェックだけで使えます。エラーは Log に落ちるので、それを見ながら作業していけばよいようです。
html5-rack-tidy ( 1.8 )
customink/html5-rack-tidy - GitHub
rack-tidy から fork して HTML 5 対応したもの。ということでこれも書き換え目的になっています。
tidy_ffi ( 1.9 )
1.8 用の tidy gem は libtidy を利用するライブラリで、要するに native extension です。これはそのままでは 1.9 では動きません。1.9 では ffi を通す tidy_ffi を使うとよいようです。
tack-tidy-ffi ( 1.9 )
その tidy_ffi を利用するバージョンがこれ。
makevoid/rack-tidy-ffi - GitHub
ただしやはり HTML の書き換えを目的にしており、また 1.9 の encoding の絡みもあって日本語の HTML を通すととても残念な結果になることもあり、ちょっとさすがに使えない感じです。
tidy_rack
これは libtidy を使わずに実行バイナリを使うバージョン。
HTML の書き換えもするけど HTML 上に error や warning を出力してくれるらしい。
まとめ
- tidy を文法チェッカとして使う rack middleware は rack-htmltidy だが、1.8 専用
- しかも HTML 5 には対応していないのでスマホ版などイマドキの HTML に対応できない
ということで、HTML 5 対応を考えなければ rack-htmltidy を使えばなんとかなるのですが、ちょっと寂しい状況ですね、これは。
※ HTML 5 対応を考えると Validator.nu が今のところイチオシみたいですね。試してないですけど。
蛇足
middleman で動かす
middleman で動かすには config.ru ではなく config.rb の方を書き換えないとダメなようです。config.ru で説明してある部分を読み替える必要があります。
w3c validator
もしかしたら HTML のチェッカとしては w3c validator の方が有名かもしれません。w3c validator はチェッカサービスであり、そのエンジンの名前です。手元の環境に自由にインストールして動かすことができます。
この w3c validator を利用する rack middleware がないか探してみたところ、やはりありました。
ただし、せっかくこのツールを利用しているのに rack-validate は w3c_validators にまったく option を渡せず、ローカルの環境に閉じることができずに
The W3C Markup Validation Service
にアクセスしに行ってしまいます。なんてこった。
2011-09-18 [長年日記]
_ 日記ネタを掘り起こしている
本当はコードを書きたいんだけど、うまくアイディアが出てこないとか考えるのに使えるまとまった時間が足りないとか、なんか寝坊しちゃうとか昼寝しちゃうとか。
なんかそんな感じでダラダラしてる。まー休みなんだし、ダラダラすればいいのよ。勉強会に出たり git push しないといけないような強迫観念など不用なのよ。
疲れが取れてない気もするし、ちょっとよろしくない感じ。もっとダラダラ。ずっとダラダラ。
そう言えばものすごく久しぶりにSUBWAY食べた。店舗には石川県初進出って書いてあって、それはちょっと嘘書いちゃいかんよと思った。金沢は初めてだが松任にはあったぞ。
久しぶりすぎて思い出せないんだけど、バジルソースってなかったっけ。バジルマヨネーズだった。マヨネーズは好きじゃないのよね。
パンが柔らかくておいしかった。最近ああいうパンを出す店はあまりないのでとても好印象。金沢の人の新しもの好きが落ち着いたら贔屓にしようと思う。落ち着いたらなくなるかもしれんけど。
もう2, 3店舗くらい出してくれないかな。ちょっと不便。
2011-09-23 [長年日記]
_ ブラウザのリロード自動化2011秋
※ 2011秋っていうのは自分用に書いてあるだけで、決して 2011 年の本当の最新情報ではないです*1。
何年も前からいろんな形でくり返し出てきてる話だけど、みんなもっと楽しようぜ。いったいオレたちは何回リロードすればいいんだい？
まとめ
ということで今回はブラウザのリロード自動化の話。どういう形でこれを実現しているのか調べてみた。
Rubyist 的には LiveReload がイチオシなんだけど、まだ開発途上な部分がアレコレあって Windows 環境にはややつらい。*2それでも Windows で動かしようのない npm 依存のものよりはマシだし、使い勝手はいいと思う。
以下の記事もあわせて読みたい。
背景
- View や CSS、効果系の JavaScript の編集は細かい変更を目視で確認しながらくり返すことになりがち
- 広範囲に渡る変更の場合、多くのページを開きまくる必要がある
- 思いがけない影響が出ていないとも限らない
ダルい
ダルいのは機械に任せてしまおう。
自動化の実現方法
大きく以下の2通りに分かれる。
- やみくもに reload する ( 数秒おきとか )
- どちらかというとオークション監視向け
- ファイルの変更を監視して reload させる
reload方法
- HTML の中に JavaScript を仕込んで location.reload
- OS、ブラウザを選ばないが HTML を書き換える必要がある（手で？ 自動で？）
- OS の機能などでアプリの操作を自動化 ( AppleScript or WSH or AutoHotKey ... )
- ブラウザの拡張で
- MozRepl, Firebug, LiveReload, ...
ファイルの変更監視方法
できるだけ OS レベルでサポートされている方法が軽いし速いが、力ずくでも監視できる。説明がこみいってしまうので詳細は割愛。
監視と通知が分離していない形態もある。
ファイルの変更通知方法
- 直接エディタやブラウザからファイルの status を取得
- XMLHTTPRequest で status を渡す
- WebSocket <- New !
ブラウザのautoreload拡張
では具体的なツールの話。
やみくもにreloadする
- Easy Auto Refresh, Auto-Reload, Auto Refresh Plus, Page Refresh (以上 Chrome)
- ReloadEvery, Tab Mix Plus :: Add-ons for Firefox (以上 Firefox)
ファイル監視系
- Auto Reload :: Add-ons for Firefox
- file scheme only だけどお手軽でイチバン効果を実感しやすいかも。
- XRefresh provides browser refresh automation for web developers
- XRefresh for Chrome ― Gist
- -> livereload
監視ツールと組み合わせる系
多少手間は増えるけど速い。リソース的にも多少有利？
vogue
- node.js + npm 依存
- 各ページに reload 用の js を噛ませる必要がある
- user script で噛ませる方法もあるらしい
- ブラウザを選ばない
試してない。
livereload系
LiveReloadが超気持ちいい2011 へ。個人的にはいちばんのオススメ。
nodejuice
nodejuiceがヤバい2011へ。ヒトバシラーが増えるといいな。
自分で組み合わせてなんとかする方法
頑張るのが好きな人向け。あるいは頑張った人たちの歴史。
- watchr - ファイルに変更があったら何かする / もしくはオサーンについて - coリ・ー・ン＜2nd life
- MozRepl + ruby + watchr + net/telnet
- System.Exit – autotest と MozRepl でブラウザ自動リロード
- Eclipse/保存と同時にブラウザを自動リロードする方法 - TOBY SOFT wiki
- 橋本商会 � エディタ保存したらブラウザリロードするsinatra/auto-reloadを作った
- Dreamweaverで上書き保存した瞬間に、Firefoxを自動でリロードさせる、強力なコーディング高速化スクリプト | 5am! Web Illusions
- ファイル保存時にブラウザを自動的にリロードする JavaScript ライブラリを書きました | Tanablog
- 最速インターフェース研究会 :: Firefoxでの開発を高速化する自動リロードスクリプト
ほか
もう一度まとめ
ブラウザの自動リロードについては何年も前から様々な工夫がなされてきている。どれを使っても自分の目的が達成できればそれでよいとも言えるが、最近は LiveReload など完成度の高いツールが出てきていて、もう少し導入が楽になれば一気にブレイクするんじゃないかと感じている。
こうしたツールは1ページしか書かないうちは、あるいはあまり HTML, CSS, JavaScript を多く書かないうちはメリットを感じないかもしれないけれど、CSS や JavaScript は予想外に影響範囲が広くなりがちなので、あるところだけをいじっているつもりがうっかり別な場所を壊していたということも十分あり得る。
最近はそういう事故を防ぐためにも上に挙げたツールで押さえておきたいページを全部自動でリロードさせるという使い方をしているが、これはなかなかよい。マシンの負荷は当然上がるが、リロードという作業は完成するまでやり続ける単純作業なので、導入に多少コストを掛けても十分お釣りがくるし、安心感がまるで違う。もちろんチェック自体を目視ではなくシステムによるテストに置き換えていくなどの工夫もできるだろうが、目視でなくては確認できない効果は目視せざるを得ない。そういう意味では完全に CI に置き換えが効くわけでもなく、エンジニアにもデザイナにも嬉しいツールだと思う。
ぜひ多くの人に使ってほしいなぁと思う。
2011-09-24 [長年日記]
_ nodejuiceがヤバい2011
※ nodejuice は決して 2011年製のアプリではありません。Vimeo 上のデモムービーは 2009年に上がっています。同時に、開発は止まっていません。
ブラウザのリロード自動化2011秋 から読んでもらえると嬉しいです。
ブラウザの自動リロードの話が長くなりそうだったので特に紹介したいものは別エントリにした。まずは nodejuice から。
三行紹介
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 での検証の手間も減らせる
準備のハードルは若干高い*1が、より多くの環境での検証の自動化を助けるという意味ではエンジニア好みな感じ。またどの言語、どのフレームワークでの開発にも使えるのが大きい。
※ node.exe で nodejuice を動かせるかどうかは試していないので分からない。
まとめ
nodejuice はアイディアは良いんだけど、使い始めをもう少し簡単にしてくれるとドキュメントや実際に試す人が増えてくるのかなぁという感じ。両方ともあまりに少ないのが難点。やってることのイメージがつけばそれほど難しいものではないと思うが、あまりに声が少ないと不安になってしまう。
それとも気づいてない問題があるのか。WebSocket を使わずに status check しまくり script を挿入しておくのはブラウザによっては壊れやすいような気がしないでもない。デモムービーもよく見ると一部リロードできていないウィンドウがあるように見える。
ちなみに macports からは install できた。他の環境では恐らく手で入れないとダメ。
*1 と言っても node.js の環境がすでにあれば落としてきて広げるだけ
2011-09-25 [長年日記]
_ LiveReloadが超気持ちいい2011
※ もはや2011言いたいだけ。
ブラウザのリロード自動化2011秋の流れで LiveReload のご紹介。動作イメージとしては本家の screencast が分かりやすい。
LiveReload Screencast « Envy Labs
エディタで編集した HTML(View) や CSS などがほぼ即座にブラウザの方に反映されている。待ち時間がなさすぎて何が起きたか一瞬分からないこともあるくらい。もちろんアプリの切り替えなどの手作業は一切なし。少々の編集ならまだしも、細かい調整のフェーズや多くの画面を一度に確認したい場合などに絶大な効果を発揮する。
まとめ
Web の開発、制作者は少なくとも Safari, Chrome, Firefox のいずれかは使っていると思う。これらのブラウザを使っているならぜひオススメ。毎回の reload から完全に解放されるのはちょっと想像以上にインパクトが大きい。
ただ、個人的にはイチオシの LiveReload だけど Windows 環境ではちょっと制限が厳しい。ちゃんと手順に従えば間違いなく動く（1.6については）ので、コスト計算がちゃんとできる人にはぜひ試してもらいたい。
またワークスペースが Windows 以外のマシンなら特に難しいことはない。仮に Linux Box 上に「共有」スペースを用意しているようならそこで動かしておくだけでだいぶ効率は上がるし、多くの人に同時に効果を体験してもらえるのでより良い。
一人で小規模だとあまり効果は実感できないかもしれないけど、慣れると手放せなくなりそう。というか自分はもうなった。
仕組み
- ファイルの変更を監視をする Ruby 製のツール
- WebSocket を通じて上のツールとやりとりしてブラウザのリロードを実行する拡張
の組み合わせで動く。
拡張の方は簡単だけど、Ruby 製のツールは Ruby に不慣れだったり、まして Windows 環境だったりすると気を使うかも。
分かんない人は分かる人にメシおごってやってもらおう！
注意
空白の入ったパス上では動かないと思う。すべての環境で試したわけではないけど、少なくとも Windows + LiveReload 1.6 では動かなかった。自分は普段パスに空白は絶対に入れないので気づかなくてハマった。
あと試した限りでは file scheme には対応していないような？ 対応してると書いてあるんだけど、自分の環境ではうまく動かせなかった。
Webサーバやアプリケーションサーバが特別存在しない場合は Ruby を使って DocumentRoot に当たるパス…えーと絶対パスの / に当たるところに cd して（もちろん KUROIGAMEN で）
ruby -r webrick -e 'WEBrick::HTTPServer.new(:DocumentRoot => ".").start'
と打てば ok. Windows だと
ruby -r webrick -e "WEBrick::HTTPServer.new(:DocumentRoot => \".\").start"
こうなる。
※ Ruby 1.9.2 以降なら
ruby -run -e httpd -- --port=3000 .
でもイケる。
ブラウザ拡張の準備
ブラウザの拡張はどちらも同じものを使う。
- chrome 拡張の方は port 番号が入っていない可能性あり。
- 35729
- firefox は
- 0.6.3 以降でないとないと Firefox 6.x 以降は動かない
- about:config で以下の設定を
- network.websocket.enabled true
- network.websocket.override-security-block true
- 再起動しないとダメかも
拡張の準備については以下のエントリが参考になる。
Railsアプリを変更したら自動でブラウザをリロードしてすぐ確認できる guard-livereload｜WEBデザイン Tips
もしかすると Firewall が 35729 を block するかもしれないので、ruby による通信を丸ごと許可とか、そんな設定にしておくといいかも。
Rubyの準備
OS のパッケージでも rvm でもいいがまず Ruby を用意する。Windows の場合は rubyinstaller で 1.8*1 を入れて、devkit もインストールしておく。devkit があれば native extension も怖くない。
当然のようにインストールには gem を使うので gem も入れておくこと。rvm や rubyinstaller では gem は標準のはずなので特にやることはない。
guard-livereload
※ 2011-09-25 現在で Windows では動かないと思います。
Ruby の Guard というファイルの変更を監視して何かするツールの plugin 的なものと、上のブラウザの拡張を組み合わせて実現する。WebSocket でブラウザに reload させるので WebSocket 対応ブラウザでないと使えない。
以下、特徴。
- HTML には手を加える必要がない
- ブラウザを選ぶ
- サーバ側は Rails アプリだと何かと嬉しい（便利な gem が豊富だから）が、別に Rails や Ruby アプリである必要はない。
- static なサイトでも PHP アプリでもなんでもよい
- CSS は CSS だけ reload して適用し直してくれる
最近 Rails や Middleman でこれを使ってるんだけど、git co や stash などするだけで対応してるブラウザが片っ端から reload するサマはなかなか壮観。ただし CSS の変更は裏で行われて黙って適用されるので気づかないことがあって手動 reload したりする（ダメじゃん）。
インストール
gem insall guard-livereload
でオシマイ。たぶん。
使い方
まず監視したいディレクトリで
guard init livereload
たぶん Rails 用のテンプレートの Guardfile ができるので、これを目的に合わせて編集。生 HTML ならこんなんでもいい。
guard 'livereload' do watch(/\.html?/) watch(/\.css/) watch(/\.js/) end
で、監視したいディレクトリで
guard [start]
これでブラウザ側で [ LR ] ボタンを押してくれるのを待つはず。無事 connect できたらボタンは緑になり、KUROIGAMEN 上では Browser connected. と表示されるはず。
こうなればあとは適当なファイルを編集するだけ。
LiveReload
LiveReload は guard-livereload と同じく Ruby で書かれているが cross platform を意識しつつ Guard 依存を取り除いてある。*2 Guard 依存を取り除いているのでついでに guard にいろいろやらせる*3ことはできない。あくまで純粋に LiveReload しかしない。ただしその際便利そうな Sass や CoffeeScript の対応は自前でやってくれるらしい。
2011-09 時点で GUI も備えたアプリケーションとして書き換えようとしている最中で、もっとも高機能な reloader になりそうな気配。
- HTML には手を加える必要がない
- ブラウザを選ぶ
- 今のところ platform も選ぶ
- Ruby 1.8 + LiveReload 1.6 が今のところ Windows では唯一の選択肢
- パスに空白があるとアウト。もしかするとこの制限は他の環境でも同じかも。
インストール
Windows でも動かせる方法ということで Mac 用の GUI の方は無視してやはり KUROIGAMEN で github のインストール方法に書いてある通りに打つ。
- Windows
- gem install eventmachine-win32 win32-changenotify win32-event livereload --platform=ruby
- Mac
- sudo gem install livereload
- Linux
- sudo gem install rb-inotify livereload
たぶん他の方法でもインストールできると思うけど、少なくとも 2011-09-25 時点では Windows についてはこの通り以外にやってもうまくいかないと思う。
使い方
監視したいディレクトリで
livereload
guard と違って特に用意するファイルはないので、これだけ。(ファイルを用意してカスタマイズすることもできるけど。）
まとめ
Ruby に不慣れだとやや分かりにくいかもしれないが、基本的には用意されたドキュメントの手順通りに作業すれば動くと思う。逆に Ruby に慣れていると Windows で油断してハマる可能性があるので注意が必要。（自分はハマった。）
LiveReload の最大の特徴は速さじゃないかと思う。実は恥ずかしながらこれまで自動リロードの仕組みは用意したことがないので比較はできないんだけど、少なくとも中で使っている EventMachine も WebSocket も特に処理が重なった場合の速さに定評があるはずなのでそこからの類推。あ、Firefox の AutoReload 拡張は試したな。あれは遅かった。あれに比べると待ち時間がほんとに少ない。Atom マシンでも十分快適に作業できる。
というわけでこれはオススメだと思うなー。Windows でもモロモロの制限がなくなってくれると嬉しい。
