Boxenの導入(の準備)

新年、明けましておめでとうございます。

今年一年を良い年にすべく、Boxenを使ってみることにしました。

準備

boxenと干渉する可能性があるものをアンインストールする。
僕の環境ではrbenv, homebrew, nvm。なんとなく影響が小さそうなものから消していく。

nvmのアンインストール

公式にアンインストール方法が書いてなかった。

とりあえず.nvm/を消す。

% rm -rf ~/.nvm

あとは.zshrcにも数行書いてあったのでそれも消した。

rbenvのアンインストール

rbenvはbrewでインストールしたので、homebrewごと消せばいいのかもしれないけど、一応ちゃんと消す。

rbenv管理のrubyを消すには、~/.rbenv/versions/ の中にあるディレクトリを消すか、ruby-buildを使っているならrbenv uninstallで消せる。
これもわざわざやらなくていいような気はしたけど、パッチレベルも低かったのでついでに消した。

で、rbenvとruby-buildをアンインストール。

% brew uninstall ruby-build
% brew uninstall rbenv
% rm -rf ~/.rbenv

なんかよくわからないけど一回やっただけだとちゃんと消えず、何回か実行したら消えた。

homebrewのアンインストール

https://github.com/Homebrew/homebrew/wiki/FAQに書いてあった、このスクリプトを使った。

実行したら何故かiTermのタブが閉じたりしてちゃんと消えたのかよくわからない。
which brewとかしてcommand not found: brewとか出るようになったので消えたと信じる。

これでようやく準備が整った。

capistranoでmiddleman buildするまで

前回、bundle installするところまで出来たけど、その後middleman buildもして欲しかった。

capistranoでやる以前に、そもそもUbuntuでmiddleman buildしようとすると、execjsがjavascriptのruntimeが見つからないと言って泣いていた。
幾つかの依存ライブラリが足りないらしいので、Gemfileに以下を追加

gem "rb-inotify"
gem "therubyracer"

これでmiddleman build自体は出来るようになったので、今度はcapistranoでやるように、deploy.rbを編集。
capistrano-bundlerのソースとか見よう見まねで、こんな風になった。


withinとか要らなそうだったり、executeが2行に分かれてたりとか、若干気に入らないところはあるけども、ともあれこれでbundle installの直後にbundle exec middleman buildされるようになった。

Chefからufwを有効にする

execute resouceを使った。

ufw enable と ufw allow sshしている。

sshでufw enableしようとすると、sshのコネクションが切れるかもしれないけどいい?(y|n) みたいな確認をしてくるので、パイプでyesを渡してやっている。
手元でvagrant使って試したらこれでいけたけど、allow sshが先に実行されるようにしたほうがいいのかもしれない。

chefはknifeとかcookbookとかの用語とDSLで、学習コストを飛躍的に高めてしまっていると思う。

[Mac]Vagrantのインストール

Vagrantの前に、VirtualBoxをインストールする。
https://www.virtualbox.org/ からインストーラーを落としてきてインストール。

続いてVagrantのインストール。
http://docs.vagrantup.com/v2/installation/ 曰く、バージョン1.0.xの時にあったRubyGemsを使ってのインストールはもう無いらしい。もしgemでインストールされてたら先にアンインストールしておいてね、とのこと。
というわけでこちらもインストーラーを落としてきてインストール。

インストールできたら以下のコマンドを実行するとUbuntu 12.04 LTS 32-bitのイメージがダウンロードされて、立ち上がる。

$ vagrant init precise32 http://files.vagrantup.com/precise32.box
$ vagrant up

立ち上がる……はずが立ち上がらない。
VBoxManageのimportコマンドでエラーがどうこう言っている。これで貴重な日曜日の午後が失われた。

そして昨日、月曜日。VitrualBoxのバージョンを一つ下げて4.2.10で試してみたらすんなりいけた。

で、今日。このようなものを見つける。
https://github.com/mitchellh/vagrant/issues/1847
https://www.virtualbox.org/ticket/11895

というわけで近いうちに直ると思われるが、それまでは4.2.10を使っておくのが吉。

JavaScriptのテスト環境を整える その3

その1 その2

モジュール単位でファイル分割する。RequireJS使う。

前々回からのbower.jsonを編集。dependenciesにrequirejsを追加する。

{
    "name": "zakuni-js-template",
    "version": "0.0.3",
    "main": "main.js",
    "ignore": [
        "**/.*",
        "node_modules",
        "components"
    ],
    "dependencies": {
        "requirejs": "latest"
    },
    "devDependencies": {
        "mocha": "latest",
        "chai": "latest"
    }
}

色々と試行錯誤した結果、こうなった。

.
├── bower.json
├── camera.coffee
├── camera.js
├── components
│   ├── chai
│   ├── jquery
│   ├── mocha
│   └── requirejs
├── index.html
├── main.coffee
├── main.js
└── test
    ├── test.camera.coffee
    ├── test.camera.js
    ├── test.coffee
    ├── test.html
    └── test.js

index.html用のメインと、テスト用のmainは別のファイルにする(main.jsとtest.js)。
あと、テストもモジュール単位で分ける(camera.jsのテストはtest.camera.jsを作るようにする)。
mocha.setupとかmocha.runはtest.jsで行う。

中身はこういう感じになっている。


https://github.com/zakuni/js-template/tree/v0.0.3
RequireJS使おうとしたら時間かかってしまって最終的にちゃんと整理しきれなかった感があるので、そのうちまたまとめ直すかもしれない(しないかもしれない)。

JavaScriptのテスト環境を整える その2

前回の続き。

あとやりたいことは、CoffeeScriptを使ってる時でも同じようにテストを書けるようにするのと、ファイル分割。
どちらを先にやるかだけど、後でわざわざ書き直すめんどくささもさることながら、それで動かなくなって悩むのは嫌なので、Coffee化を先にやることにした。
前回のmain.jsは

var a = 1;

だけだった。
これをCoffeeScriptで書くと

a = 1

となるわけだが、これをコンパイルしたmain.jsを使うようにするだけで、前回書いたテストは通らなくなる。

なぜかというと、CoffeeScriptから生成されるJavaScriptは、無名関数で囲われていて、グローバル汚染を防いでくれている。
つまり、先ほどのmain.coffeeをjsにコンパイルすると

こうなるので、変数aには外部からアクセスできず、ReferenceErrorになってしまう。

尚、コマンドラインからmochaを使ってテストする分には

% mocha --compilers coffee:main.coffee

みたいにすると中でうまいことやってくれてcoffeeでもテストを通すことができる。
(今回書いてるやつそのままでは通らない。-uオプションでtddを指定したり、chaiをrequireする必要がある)

前回は素のJavaScriptの話だったのでブラウザで実行することを重視したけど、CoffeeScript書いてるならnpmも使ってることが多いだろうし、それなら素直にコンソールでmochaを使えばいいような気がする。

そして気づいたけど、前回使ったbowerはインストールするのにnpm使ってるだろうから、ブラウザにこだわる必要はないような気もしてきた。
ただ、mochaとかchaiをファイルでダウンロードしてきて使う人とかもいるだろうと思えば、意味はあるので一応続ける。

無名関数の中で宣言されているのでアクセスできないことについては色んな解決方法があると思う。
簡単な方法の一つは、windowオブジェクトのプロパティにしてしまうこと。

window.a = 1

テストコードは変えないままグリーンになる。

というわけでこういう風に書ける

ここではやってないけど、テストもcoffeeで書けばいいと思う。

そしてひと区切り。あとはファイル分割する。

ここまでまとめたやつ。
https://github.com/zakuni/js-template/tree/v0.0.2

JavaScriptのテスト環境を整える

クライアントサイドJavaScriptでBackbone.jsとかのフレームワーク使いつつrequire.jsでファイル分割しつつ、更にそれらをCoffeeScriptで書いていた場合にテストを書こうと思ったら軽く発狂しそうになったので、一つずつ解決していくことにした。

個人的な趣味等を鑑みて前提条件は以下のような感じになった。
・CoffeeScriptでも同じような構成で使える
・ファイル分割できる
・テストがブラウザ上でも動作する

自動化は今回の範疇にはない。

後からテストが書きづらかったということに端を発するので、テスト駆動で開発する。

% bower install mocha

mochaを選んだ理由は、expect.jsとかQUnitとかと組み合わせやすそうなことと、ブラウザとコンソール両方で動かせるのと、Nodeでも使えるから。
npmじゃなくbowerでインストールしているのは、クライアントサイドのことはなるべくクライアントサイドで完結させたいので、なるべくNodeと切り離したいのがあるから。

mochaのサンプルを見ながらテスト用ページのひな形を作る。mocha.setupをbddでなくtddにしたのは趣味の問題。

これをブラウザを開いてみると、passes: 0 failures: 0 duration: 0s とか出てるはず。

assertionのために別のライブラリを使う。色んな書き方に対応してるChaiを使ってみることにした。
あと、ここでbower.jsonを作った。

% bower init

ちょっと編集する。
mochaもchaiもテストで使うものなのでdevDependenciesに入れた。

{
  "name": "zakuni-js-template",
  "version": "0.0.1",
  "main": "main.js",
  "ignore": [
    "**/.*",
    "node_modules",
    "components"
  ],
  "dependencies": {
  },
  "devDependencies": {
    "mocha": "latest",
    "chai": "latest"
  }
}

HTMLを編集して、テストを書く。

これでブラウザリロードして、グリーンになってればOK。

namespace的なこととか考えないならたぶんこれで充分テストを書いていける。
ひとまずここで一区切り。

ここまでをまとめたのが以下のもの。
https://github.com/zakuni/js-template/tree/v0.0.1