先日からの続きで Node6 でコードを書いてるわけだけど、どうしてもテストの際には同期的に処理されてほしい before, after な辺りがあるわけですよ。
追加したもの
yortus/asyncawait: Callback heaven for Node.js with async/await
他にもいくつか似たようなライブラリはあるが、これを選んだ理由は
async () => {}
を
const {async} = require('asyncawait')
async(() => {})
と書けて、字面的に構文としての async/await に対していちばん違和感が少ないため。
これで
desribe('..', () => {
beforeEach(async(() => {
..
}))
it('..', async(() => {
..
}))
})
のように書ける。
除外したもの
eslint では test/ 以下を対象としないようにしておく。
eslint-plugin-node を使って async/await がコードに混入しないようにしている場合、ライブラリで追加した async/await も弾かれてしまうため。
テストコードに lint … 要らないよね? ダメすか。
cf. eslint-plugin-nodeでNode8を使いつつNode6で問題の起きないコードを書く - あーありがち(2018-05-23)
しかしこれ
同期的に処理されてほしいから async/await が欲しいと考えてるわけで、async とは?
※ もはや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.81 を入れて、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 でもモロモロの制限がなくなってくれると嬉しい。
Linux と FreeBSD の cron の動作の違いとして気になるところに、FreeBSD では
/etc/cron.d/*
を読まないというのがある1が、periodic を使って month, weekly, daily なんかと同じように読み込ませることはできそう。つかまぁもっとこれらの periodic なディレクトリを活用すればいいんですけど、タイミングを自由に記述しつつ crontab ファイルの肥大化を防ぎたいわけですよ。
ついでに Linux の run-parts も調べてみたのでちょいとまとめてみる。
periodic
基本的な使い方
periodic DIRECTORY
- 指定ディレクトリ内の実行ビットの立っているファイルについて順次実行を試みる
- FreeBSD/MacOSX の /etc/periodic 内の monthly, weekly, daily はここから実行される
- cron 関係のディレクトリでない場合は基本的にフルパスを指定する
- run-parts と違い、実行した日時を出力する
- 細々した設定を
periodic.conf
に書ける。細かい設定をしたい場合はディレクトリに名前を付けて置いて、その名前に応じて設定を記述していくとよい感じ。
これをうまく使えば Linux と同じように
/etc/cron.d/
内のファイルを読み取って実行させることもできなくはない。
ただし、Linux の /etc/cron.d/ 内に置くファイルは crontab そのものであり、実行ビットが必要ないが、periodic を使う場合は実行するファイルを置くので実行ビットが必要、という点が大きく違う。
run-parts
基本的な使い方
run-parts DIRECTORY
- 指定ディレクトリ内で実行ビットの立っているファイルについて順次実行を試みる
- Linux の monthly, weekly, daily, hourly はこの run-parts を利用して実現している
run-parts の解釈するファイル名には制限があるので注意が必要。まぁ man 嫁。
If the –lsbsysinit option is not given then the names must consist entirely of upper and lower case letters, digits, underscores, and hyphens.
/etc/cron.d/
Linux の cron はこの中のファイルについても crontab と同様にチェックを行う。この中のファイルは実際に実行するものではなく crontab フォーマットのファイルなので、当然実行ビットは必要ない。
ずっと気になってるんです、ワタシ ↩
まぁ OmniGraffle はそもそも 2 から 3 のアップグレードは有償なのですが、GraphicConverter もバンドル版から配布最新版へのアップグレードは別料金が必要なのですな。なんじゃそら。
iLife とかはさすがにそういうことないんだろうけど、なんだかなぁ。
ベースラインの関係か、必ず文字の下に余白ができてしまい、自動で文字をオブジェクトの中央に配置することができなかったが、IPA フォントにしたらうまく納まった。
意外なところで扱いやすさを発揮。