modern.IE×VMWareFusion 試してみた

modern.ie

最初に言ってしまえば、以下の記事をまず読もう。導入手順が詳しく書いてあります。ありがとうございます。 http://design-spice.com/2013/04/03/mac-ie-test/

http://www.modern.ie/ja にアクセスし、
仮想環境 > Download a Virtual Machine. For Mac, Linux, or Windows. > Get the VM > 目的のOS→Mac > プラットフォーム→VMWareFusion で目的のOSのファイルをダウンロード。ダウンロードした.sfxファイルをターミナルから

$ chmod +x DOWNLOADED_FIKE.sfx
$ ./DOWNLOADED_FIKE.sfx

と実行すると、解凍されてディスクイメージファイルができる。
で、そのファイルをVMWare Fusionで開いたら実行できた。詳細はこちらにて

以下、気づいたこととか。

js-test-driverの使い方メモ

js-test-driverはGoogleが作った、JavaScriptをコンソールでテストするプログラム。試したのでメモを。環境はMountain Lion搭載のMacBookAir。

ダウンロード:
http://code.google.com/p/js-test-driver/downloads/list

使い方:
http://code.google.com/p/js-test-driver/wiki/GettingStarted

参考になる日本語記事:
http://0-9.tumblr.com/post/15614207218/js-jstestdriver
http://everyday-eachday.blogspot.jp/2011/12/jstestdriver.html

ダウンロードページで JsTestDriver-x.x.x.jar ってやつを落とす。ダウンロードしたファイルを ~/bin/JsTestDriver.jar みたいなパスに置く。コンソールから以下のコマンドでサーバーを起動。

$ java -jar ~/bin/JsTestDriver.jar --port 4224

ポート番号は適当でいいらしい。コマンド成功したら、適当なブラウザで http://localhost:4224/ を開く。そうすると

  • Capture This Browser
  • Capture This Browser in strict mode

ってテキストリンクが並んでる画面になるので好きな方をクリック。(普通は Capture This Browser でいいと思われ)そうするとそのブラウザをウォッチしているような状態になる。で、そのブラウザのエンジンでテストが実行される。

実際にテストしたいプロジェクトのディレクトリを作る。例えば以下のような構造にする。

|- jsTestDriver.conf
|- src
|--- hoge.js
|- test
|--- hoge_test.js

hoge.js が書きたいJavaScript。hoge_test.js がhoge.jsに対するテストを書くファイル。jsTestDriver.conf がjs-test-driverのためのファイル。テキストエディタで開き、以下のように記述。

server: http://localhost:4224
load:
- src/*.js
- test/*.js

コンソールに戻る。さっきサーバーを起動したプロセスウィンドウはそのままにしといて、新しいプロセスを起動。そっちで

$ cd プロジェクトのディレクトリへ
$ java -jar ~/bin/JsTestDriver.jar --tests all

するとテストが走って hoge_test.js に書いたテスト結果が表示される…予定なんだけど、この時点で hoge_test.js には何も書いてないのでエラーになるはず。
というわけで簡単なコードを書いてみる。

### src/hoge.js function jsdriversample() { return true; }
### test/hoge_test.js TestCase(‘jsdriversampletest’, { ‘test should return true’: function () { var result = jsdriversample(); assertTrue(result); } });

で、コンソールでコマンドを叩いてテストする。

$ java -jar ~/bin/JsTestDriver.jar --tests all

ちなみにここで'test should return true'っていうのは各テスト単位の名前で、エラー時にコンソールに出力される。ちなみに文字列だからってマルチバイトは使えない。

assertなんちゃらって関数でテストを実行してるんだけど、使えるassertionの一覧は以下に載ってる。
http://code.google.com/p/js-test-driver/wiki/Assertions
例えば assertTrue だったら、引数の値が true だったらテスト合格になる。

まだちょっと使ってみただけなので、もうちょい勉強して実務に生かしたい。

### 2012-12-06 追記 テストケースのメソッド名(上記の例では 'test should return true' となっているところ)は必ず**test**で始まらないと、認識されないようです。

Mobile Safari、フルスクリーンモード、UIWebView、どれからのアクセスか判別する

apple-mobile-web-app-capableというめmetaタグの値をyesにするとiOS Safariでそのページを「ホーム画面に追加」し、ホーム画面からアクセスした際にページをフルスクリーンモードで開くことができる。

<meta name="apple-mobile-web-app-capable" content="yes" />

出典:Safari HTML Reference – Supported Meta Tags

フルスクリーンモードで開いた場合、navigator.userAgentの値に「Safari」の文字列が現れなくなる。

Moble SafariでのuserAgent(iOS 5.1.1):

userAgent: Mozilla/5.0 (iPhone; CPU iPhone OS 5_1_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9B206 Safari/7534.48.3 

フルスクリーンモードでのuserAgent(iOS 5.1.1):

userAgent: Mozilla/5.0 (iPhone; CPU iPhone OS 5_1_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Mobile/9B206 

ところで、FacebookアプリやTwitterアプリなど、投稿内容のURLを踏むと、そのアプリの中でWebページが展開されるものがある。UIWebViewというやつ。この場合のuserAgentにも、やはり「Safari」の文字列は現れない。

FacebookアプリのuserAgent(iOS 5.1.1):

userAgent: Mozilla/5.0 (iPhone; CPU iPhone OS 5_1_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Mobile/9B206 [FBAN/FBIOS;FBAV/5.1;FBBV/68414;FBDV/iPhone4,1;FBMD/iPhone;FBSN/iPhone OS;FBSV/5.1.1;FBSS/2; FBCR/KDDI;FBID/phone;FBLC/ja_JP] 

TwitterアプリのuserAgent(iOS 5.1.1):

userAgent: Mozilla/5.0 (iPhone; CPU iPhone OS 5_1_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Mobile/9B206 

というわけでSafariという文字列があるかないかを頼りに、フルスクリーンモード、ないしはUIWebViewからのアクセスを判別しようとすると失敗する。 しかし上記出典のSafari HTML Referenceによると、フルスクリーンモードではwindow.navigator.standaloneというプロパティがtrueになるらしいので試した。

デモ

iPhone/iPadのどちらでも、フルスクリーンモードのみでwindow.navigator.standalonetrueになるのを確認できた。

userAgent文字列からiPhone/iPadであることを判定した上で、

  • userAgentにSafariの文字列あり → Mobile Safari
  • userAgentにSafariの文字列なし、かつwindow.navigator.standalone === true → フルスクリーンモード
  • userAgentにSafariの文字列なし、かつwindow.navigator.standalone === false → UIWebView

という判定をすることができる。

GitHubを初めて使ってみた

ヘルプに書いてある通りにやったらできた。本当に、そのまんま。
Help.GitHub – Set Up Git
Help.GitHub – Create A Repo

Macでのやり方はこちら
Help.GitHub – Set Up Git

SSH keyを登録するところがキモだが、コマンドまで全てちゃんとヘルプに書いてあるのでつまずいたところはなかった。拍子抜け。

最初に作ってみたレポジトリがこれ。
seckie/jQuery.ui.vScroll – GitHub

今年の春に作ったものだけど、今また案件で使う必要があって引っ張り出したら無駄なところがあったりしてちょっといじることになった。案件の制作物は当然会社のレポジトリに置くんだけど、これは個人的に作ったものだったりしたので、せっかくなのでGitHubに挑戦してみた。

JavaScriptの変数についての考察

最近、Code Complete第2版という本を読んでいて、「変数の使用(第10章)」がとても為になる内容だったので、会社のチームメンバーに少しそのことについて話したら、JavaScriptについて興味深い話をすることができた。

第10章の内容について、議論の対象となった部分を引用する。

10.3 変数の初期化のガイドライン

変数は最初に使用する場所の近くで初期化する

リスト10-2: 悪い初期化(Visual Basic)
' すべての変数を宣言する
Dim accountIndex As Integer
Dim total As Double
Dim done As Boolean

' すべての変数を初期化する
acountIndex = 0;
total = 0.0
done = False
...

' accountIndexを使用するコード
...

' totalを使用するコード
...

' doneを使用するコード
While Not done
...
…中略

リスト10-2の例では、done変数を宣言した後、done変数を使用するコードが実行されるまでに、done変数が変更される可能性がある。

…中略

もう1つの問題は、すべての初期化を1か所にまとめると、done変数は最後の方でしか使用されないにもかかわらず、すべての変数がルーチン全体で使用されるという印象を与えることだ。

…中略

これは、「関連する作業を1つにまとめる」という近接の法則の一例である。

なるほどなるほど。しかし僕は普段の業務でプログラミング言語らしきものはJavaScriptしか使わないので、JavaScriptに置き換えて考えよう。

var accountIndex = 0,
    total = 0,
    done = false;
// accountIndexを使用するコード
...

// totalを使用するコード
...

// doneを使用するコード
while(!done) {
    
}
...

これが本書で「悪い例」とされているコードをJavaScriptに置き換えたコードだ。しかし関数の先頭で var hoge = 0, fuga = false; のようにして変数をまとめて宣言(&初期化)するのはJavaScriptではよく見られるコードだ。あのjQueryですらそのような記法を多用している。
JavaScript: The Good Partsによると

ほとんどの言語では、変数は一般的に最初に利用される場所で定義するのが最も良い方法だ。しかしこれは、ブロックスコープを持たないJavaScriptでは好ましくない。すべての変数は、それぞれの関数の先頭で定義したほうが良い。

とある。そう、JavaScriptはブロックスコープを持たない({}でくくられた部分限定の変数スコープ)といういわゆる変態言語であり、変数のスコープを生成するのは関数ブロックのみだ。それが理由で、変数はまとめて関数の先頭で宣言するという記法がベストプラクティスとされている。

さてしかし、Code Complete第2版による「変数は最初に使用する場所の近くで初期化する」ほうがよいという理屈の続きはこうだ。

10.4.1 変数の参照はまとめて

変数を参照してから次に参照するまでのコードは、「脆弱性の窓」(無防備な時間帯)である。その窓では、新しいコードが追加されたり、何気なく変数が変更されたり、変数に含まれていなければならない値が忘れられてしまったりする。変数の参照は、常に近いところにまとめて局所化するのが望ましい。

…中略

これを測定する方法は、変数の「持続間隔」を計算することである。

…中略
リスト10-6: 1と0の持続間隔(Java)
a = 0;
b = 0;
c = 0;
b = a + 1;
b = b / c;

この場合、bの1つ目の参照と2つ目の参照の間にコードが1行あるので、その持続間隔は1である。bの2つ目の参照と3つ目の参照の間にはコードがないので、その持続間隔は1である。bの2つ目の参照と3つ目の参照の間にはコードがないので、その持続間隔は0である。

…中略

リスト10-6では、bの平均持続間隔は (1 + 0) / 2 = 0.5 である。変数の参照を近くにまとめると、コードの読み手がコードをセクションごとに読んでいけるようになる。

…中略

10.4.2 変数の「寿命」はできるだけ短く

変数の持続間隔に関連して、変数の「寿命」という概念がある。変数の寿命とは、変数が存続する期間内に存在するステートメントの合計である。

…中略

変数の持続間隔とは異なり、変数の寿命は、最初に参照されてから最後に参照されるまでの変数の使用回数を計算に入れない。変数が最初に1行目で参照され、最後に25行目で参照された場合、変数の寿命は25(ステートメント)である。

…中略

変数の持続間隔と同様に、変数の寿命もできるだけ短くする、つまりステートメントの数を少なくすることが目標となる。持続間隔と同様に、ステートメントの数を少なくすると、脆弱性の窓が小さくなるという利点がある。

…中略

寿命を短くするもう1つの利点は、コードを正確に把握できることである。変数に10行目で値を代入し、45行目まで使用しない場合、2つの参照の間に空いている空間は、変数がその間に使用されていることを暗示する。

…中略

変数の寿命が短いと、コードが読みやすくなる。読み手が一度に頭に入れなければならないコードの行数が少なければ少ないほど、コードは理解しやすい。

変数には「平均持続間隔」と「寿命」という概念があるという。そしてそれらが短くなった方がコードの読み手にとって読みやすいコードになるという。

去年、僕がとある案件で数千行に及ぶJavaScriptを書いた際、最も頭を悩ませたのはコードを頭に入れることだった。機能を追加・修正するために一度に頭に入れなければならないコードが多すぎたため、開発が進めば進む程、コードの修正は困難を極めた。

プログラミング初心者が誰しも一度はぶつかる壁なのかもしれない。コードの分割をはじめとする、コードの設計の重要性を肌で感じた瞬間だった。
だからこそ、上記の「読み手が一度に頭に入れなければならないコードの行数が少なければ…」というくだりに深く納得したのだった。

さて、ではJavaScriptにおいて「変数の寿命を短くする」ことと「関数の先頭ですべての変数を宣言する」ことは両立するのだろうか?これについて隣席の@keiskeyの意見はこうだった。

関数1つの長さ自体を短くしてしまうのがいいのでは。Google Closure Libraryのコードを見ていると、中身が2行しかないメソッドに長々とした名前が付いていたりする。そんな長い名前を付けるんだったら直接コードを書いてしまえばいいやん、と思うけど、「変数の寿命」のポリシーをもって書かれていると考えると合点がいく。

なるほど…と再び納得するとともに、「この話、共有してよかった」と思った。

例えば上述(リスト10-2)のコードを一つの関数だと考えるとこうなる。

function Account() {
    var accountIndex = 0,
        total = 0,
        done = false;
    // accountIndexを使用するコード
    ...

    // totalを使用するコード
    ...

    // doneを使用するコード
    while(!done) {
        
    }
    ...
}

この関数をクラス風に書き直し、機能分割するとこういう感じになる。

function Account() {
    // コンストラクタ
    ...
}
Account.prototype = {
    getAccountIndex: function() {
        var accountIndex = 0;
        // accountIndexを使用するコード
        ...
        return accountIndex;
    },
    getTotal: function() {
        var total = 0;
        // totalを使用するコード
        ...
        return total;
    },
    checkStatus: function() {
        var done = false;
        // doneを使用するコード
        while(!done) {
            ...
        }
    }
}

prototypeにぶら下げたメソッド1つ1つを短くまとめて上手に機能分割することが、限りなく正解に近いのではないかと思った次第。

僕はプログラマと呼ばれる職種ではないのだけれど、プログラミングに関わる人間として、こういった考察はとてもおもしろいと感じる。また何か同じような話があったら書いていきたい。