Fish Shellでコマンドの実行結果を変数に代入する方法
2013年5月20日 | 
fish 2.0がでたので、fish(friendly interactive shell)色々と試していますが文法等が違う所も多いです。
よく使いそうな、ある実行結果を変数に入れて使うような場合に必要な機能、一般にはCommand Substitutionという名前みたいで、Bashやzshでの
$(command)
# や
`command`
などの機能のことです。
fish shellでは
help expand-command-substitution
と叩くと解説が見られます。
- fish user documentation の
Command substitution
fish shellでは単純に
(command)
とすれば実行されるようです。
set wd (pwd)
echo $wd
なので、上記のようにやると $wd には pwd の実行結果が入るようになります。
挙動の動画
参考
Tags:
追悼 E4X (仮) アウトラインメモ
追悼 E4X (仮) : ATND に参加してきたメモです。
(bug/バグはチケット的な意味で使われてます)
E4X って何？ – @makoto_kato
- SpiderMonkeyからは削除済み
JDK 6
- 対応しないよ的なコメントあり
ActionScript 3
- Flash 9+
- AIR 1.0+
JavaScript Core
- 2005年にbugが上げられてたけど放置
V8
- 2009年にbugがあげられて、not standard!!との返答
実装しなかったエンジン
- V8
- Webkit
- IE
- Opera
実装したエンジン
- Firefox
- ActionScript
時代背景
なんでE4X実装されたのか?
- SOAP
- サーバのやり取りはXMLでやろう!
- XHTML 1.0
時代的に
- XMLはウェブサービスで使われる重要なフォーマットだった
- HTMLもXMLへ移行しようとしてた
XHTML仕様書のcontirbutedにある企業の残存率とE4Xの未来の予感
セキュリティバグ
- セキュリティバグの色々
- hasegawayosuke’s fotolife – 20101116112317
E4Xの使い方
- XMLオブジェクトを作成
new XML()- ここまでは良かった気がするね
- XMLリテラル < – ここから何かおかしいね
a.*for each
フィルタ
a.($id == "abc")
idがhogehogeのものを取り出す
Node.js
- V8が実装しないなら使えない
E4X とパフォーマンス
- E4Xは遅い
- 今の正規表現はJITになってる
- E4Xにパフォーマンス求めるならJITが必要な気がする
Vimperator での E4X @teramako
- ヒアドキュメント
- XMLテンプレート
として利用されてた
ヒアドキュメント的に
- スタイルシートのテキスト生成
スタイルシートなどに使ってた
XMLテンプレートとして
- XMLオブジェクト — DOM変換 -> DOM
- コマンドライン出力
- 補完リスト生成
- Hit-a-Hintの要素生成
- XMLオブジェクト – - XSLT -> DOM
便利メソッド
template.map()
E4X 廃止
ES.nextのTemplateLiteralへ
- ES.next として提案されていた構文
- Template literal(Quasi-literals)へ
- パーサーを書いて、動的に生成する
- E4Xからの変更が小さくて済む
コンバート要件
- プラグインファイルの様に動的に読み込まれるスクリプトもある
- 独自プロトコルを使用
liberator://templateを使ってコンバートして詠み込む- 一種のリダイレクト的な感じで動的に変換
まとめ
- Vimperator はE4Xをディープに使ってた
E4X昔話
- @ を属性値に入れたりすると勘違いする
- 勝手にできる謎の名前空間
- function:: というMozilla独自実装
__defineGetter__なおかしな挙動- E4Xのパフォーマンスについて
- DOM APIとE4Xのパフォーマンスの比較
- 正しいXMLとして大体保証されるもの(制御文字などはあれかも)を吐き出してくれるE4X
Esprima 上での E4X parsing と ECMA 357 spec bugs – @Constellation
スライド : E4X parser implementaion & ECMA 357 spec issues // Speaker Deck
ECMA357 パース問題
- Final draft 2nd edition of ECMA-357 – Ecma-357.pdf
- パースがとてもむずかしい
- XMLWhitespaceがトークンになってる(whitespaceがトークンだ!!)
- laxerのモードを変更してE4Xに対応するしかないようなレベルの仕様
- 特定の
<がきたらこれE4Xだ
WhiteSpace
<XMLTagContentXMLWhitespace/>という感じにワカれてる- whitespaceの扱いが独特
Special Nodes
- コメントをXMLComment というオブジェクトとして保持する必要がある
- CDATA section
< ?xml ...>- 特殊な並びをしてるので1つのトークンとして持っていける
new tokens
var encodingStyle = message.@soap::encodingStyle;
order.@*;
:: 、 @ 、 . 、 * などの新しいtoken
syntax extention
- Ordinary mode “`::“
statements
default xml namespace = "";
for each (var p in e.employee){}
ステートメントが増えた
XML
- スキャナモードを変更する必要が出てくる場面
< がきたら、スキャナモードを変更する
スペースをtokenとして必要になるので、
var xml = <customer>
;
< がきたら、E4Xモードになってspaceのために1つ戻ってスキャンする。
XMLEscape
<customer>{var}
{}がきたら、ECMAScriptモードに戻してスキャン
function::
function:: だけは特別
// NG
default::test;
// OK
function::test;
Esprima with E4x
- 仕様に書いてあるsyntaxを全てサポートしたEsprima
- Esprima: E4X
- 仕様書自体にbugあり
私とE4X – @nanto_vi
- Mozilla Relase Note @ 新聞
E4X と autovivification – @nanto_vi
XMLオブジェクトのプロパティ代入
- 存在しないプロパティへ文字列を代入すると、自動で新たな要素が作られる
[[Put]]によるもの入れ子になった要素が一度に作成される
XMLListオブジェクトの
[[ResolveList]]によるもの[[ResolveValue]]内部メソッドは、再帰的に呼ばれることもある
Perl
Perl も存在しないハッシュ値などに代入すると入れ子のハッシュを作れたりする
autovivification という機能という名前になってる
E4X
::get 名前空間を使ったautovivification の応用
他LT
- はてなのE4X
- VimperatorのDescriptionパーサ
おわりに
E4Xフォーエバー #RIPE4X twitter.com/saneyuki_s/sta…
— さねゆき (@saneyuki_s) May 19, 2013
メモ
Objective-C勉強会＠東京 で iOSのユニットテストについて話してきた
Objective-C勉強会＠東京 – PARTAKE に参加して、iOSのユニットテストについて話をして来ました。
スライドは上記に置いてあります。
そこまで、それぞれに詳しく扱ってない感じで、ロジックテストとアプリケーションテストの違いや、 どういうツールがあるのかやデータベースを使った時にテストの仕方等の紹介な感じです。
xctool はiOSのテストをCLIで実行するのにとても便利でよい感じなのでお勧めです。
スライド内にひっそり(note)とCocoaPodsと xctool の相性がまだ良くないことが書かれていますが、 一度ビルドしないと、 xctool からテストを動かすとエラーになる現象があります。
ld: library not found for -lPods
これは、”Find Implicit Dependencies”の挙動が上手く動いていないのが原因みたいで、手動でビルドの設定にCococPodsの静的ライブラリをビルドするTargetを追加すれば動作するようになります。
BuildのTargetを CocoaPods -> Main -> Test に並べてあげると解決します。 (そのうちxctool側で対応しそうな気がする)
一度でもビルドしてあれば、上記のエラーはでなくなるので気づきにくいですが、Travis CIのように毎回クリーンな環境で実行される場合はエラーが出ます。 以下のプロジェクトではCocoaPods + xctool + Travis CIでテストを動かしています。
以下メモ
Objective-Cの概要 – @akuraru
Objective-Cとは
- Cの完全上位互換
- 動的型付きオブジェクト指向
- メッセージ式
他の言語との関わり
- C言語
- Smalltack のようにかけるC言語
特徴
- メッセージ式
- ARC
- C言語と同等の速度
- カテゴリ
メッセージ式
あるClassにxxというmethodがある- xxというmethodがあるClass
同じメッセージ
ARC
- C言語と同様にメモリ管理は手動で行わないといけなくなった
- コンパイラが自動でメモリ管理に関するコードを追加する
- ガーベッジコレクションじゃない
C言語と同等の速度
- ClassはC言語の機能のラップ
- メソッドは過疎数の名前空間が分かれている(名前空間を分けている)
- 本来に速度が必要ならばC言語で実装すると高速
カテゴリ
- 実装を複数のファイルに分割する機能
- NSObjectにも機能が追加できる
- 強力な分リスクがある機能
GDBでObjective-Cの中身を見る
- GDBでObjective-Cのアセンブラ
- メッセージ式はobjc_msgを呼び出してる
- Objective-C ではメソッドを呼ぶときに self, _cmd, パラメータ1,2…と渡される
- NSStringはCFConstStringReference になってる
LLVMでアセンブラ
- clang -emit-llvm -S でllvmアセンブリな形式で見られる
- 直接アセンブラを見るより楽
- どういう引数を渡しているかがわかりやすい
おわり
- 来月ぐらいにもう一度やるそうです。
第４回「ブラウザー勉強会」 アウトラインメモ
第4回ブラウザー勉強会
第４回「ブラウザー勉強会」 on Zusaar に参加してきたので、その時のメモです。
午前の部 : コミュニティ セッション
オフラインキャッシュについて – hebikuzure
Content.IE5
- IEのキャシュデータ構造はIE5から変わってなかった
- Window2000 の頃と同じ
IE10のキャシュのシステム変更
- IE10ではキャッシュのシステムを変更されてる
Content.IE5の中身
- index.dat
- インデックスファイル
- 英数8文字のキャッシュフォルダ
- 実際のファイルが並んでる
- 4個つづキャッシュフォルダを作ってキャッシュを書き込む
キャッシュの情報はどこ?
- 最終更新日時とかのメタデータはどこ?
- index.datに含まれている
- バイナリファイル
- データ構造は非公開
index.dat
- キャッシュフォルダ名はそのままアスキーコードで入ってたり
- HTTPのレスポンスヘッダも大体そのまま入ってる
- index.dat フォーマット(非公式)公開されてる
IE10のキャッシュシステム
- index.datはなくなった
- container.datという0バイトになってある
- キャシュされた実ファイルはそのまま
プロセスモニター
- WebChaceV01.data
- Jet BlueというMSの内蔵データベース
- IE10のキャッシュはJet Blueのデータベースで管理してる
- WebCache01.datというファイルがある
ログ
- V01.log
- バイナリとレスポンスヘッダーとかがアスキーコードでそのまま入ってる
まとめ
- IE10で一時ファイルの管理方法が変更される
- IE自体もタブとかでマルチプロセスなので、古い方法はキャッシュが壊れる原因になってあ
- インデックス管理はindex.datのバイナリファイルからExtensible Storage EngineのISAMデータベースに変更
- インデックスが堅牢になった
Office365 – もくだい
午後の部
アンケート結果
- Chrome > Firefox > IE > Safari > Opera
- 重複解答有り
- 1ブラウザ主義はChromeだけ突出
- マルチブラウザ主義の場合はFirefoxとChromeが均衡
JavaScript
領域の拡大
- サーバーサイド
- ローカルアプリケーション
JavaScriptのトランスコンパイル
JavaScriptへ変換する変換言語
- シンタックスシュガー
- 静的型付き言語
- Haxe
- JSX
- TypeScript
「モテる、JavaScript-」- 物江修さん
目的
- 他人に見られて恥ずかしくないコードを書く
- カコイイJavaScriptコードを書いてモテる
知っておきたい慣例的な命名規則
- 変数名はキャメルケース
- コンストラクタ関数は大文字から始める CalendarCtrl
- this
- > vat that = this;
- 定数は大文字
- プライベート
_private
変数/関数
- 関数: 動詞を先頭に入れる
- 変数をあえて_で区切ることでわかりやすくする
変数を宣言する場所
varで変数を宣言する- 変数宣言を関数の先頭にまとめる
- JavaScriptの変数スコープは関数単位でhositingが起きるので先頭に書く
中括弧の書き方
暗黙的セミコロンの挿入による意図と反する動作を避けるため
function main (){
return {
// returnの後に暗黙的にセミコロン挿入があるので気をつける
}
}
中括弧の省略は避ける
- 他の人が書き換えるときに間違える元となったりする
DOMアクセスについて
- 複数回同じにDOMにアクセスするときは変数に入れておきましょう
- jQueryとかはDOMにアクセスする周りで色々やるので効果的
かっこいい書き方
- 曖昧評価の利用
if(hoge){}
- 短絡評価の利用
hoge || "default
- 厳密等価演算子
===!===
- 即時実行関数
クロージャー
- 部分適応を使った例
メソッドチェーン
- thisを返す関数を書いてメソッドチェーン
最近の書き方
- オブジェクトで分けていく
initで初期化処理を行う
JavaScriptはページ表示時かイベントから呼ばれることが殆どなので、 初期化処理をまとめておくのが重要
JavaScriptがもっと好きになる。JavaScriptを知るために – kyo_ago
「JavaScriptを知るために」
=> 「作ってみる」
=> 「静的解析しましょうか」
静的解析とは
コードを文字列として分割してどういった内容が書かれてるかを解釈すること
を 正規表現 で
エスケープのエンコード
文字列の中に " のようなエスケープ文字列があると、
対応をちゃんと見ないと行けないので、最初に 別の 記号的なものに変換しておく
使い道
- 簡易プリプロセッサ
- console.logの除去等
- 言語の仕様の理解
- 文字列処理のノウハウ
難しい所
/**/var hoge = 5 / 1; /* comment *//[/]]/
結論
Esprima を使ったほうがいい
いつソースを読むのか – kyo_ago
ブラウザの特性で公開されてるプロダクトのソースを読むことができる
- 新規プロダクトごとに少しずつコードがよくなってる
- ライセンスを圧縮時に消してしまってること等
コードを読む文化
- 動いてるプロダクトコードを直接読める世界は今まで殆どなかっtあ
- フレームワークなどが標準で圧縮されてるようになって読みにくくなってる
- 圧縮する前に1ファイル化 + gzipで十分な場合もある。
- 圧縮前のソースをコメントに入れておく
- SourceMapを使う
テンプレートエンジンを作ろう – kyo_ago
テンプレートエンジンとは何か
テンプレートエンジンとはデータとテンプレートをあわせて表示する
テンプレートエンジンを作る
簡単な言語実装ができる
- テンプレートエンジンはロジックが入るならある種のプログラムになる。
TDDと相性がいい
- ロジックのみに集中しやすい
- 処理が基本的に同期処理なのでテストしやすい
- どういう機能が必要なのか、input / outputがわかりやすい
文字列処理の練習
- 文字列処理の練習に鳴る
テンプレートの仕様
仕様によってテンプレートエンジン作成の難易度が変わる
テンプレートエンジンとテスト
- テンプレートエンジンはテストがそのままドキュメントになりやすい
- input -> outputがわかりやすいため
白石の異常な愛情 または私は如何にして心配するのを止めてNodeを愛するようになったか – 白石 俊平
- 敵役がいたほうがプレゼンが盛り上がる
- Node vs Java
Node
- JavaScriptコードはツギハギだらけになる
- 逆に考えるんだ
- ラピッドスタートをそのままにコードに持ってこれてぐちゃぐちゃだけど動くコードを書ける
ラピッドスタート
- npmで便利なモジュールを取ってこれる
変更容易性
- クライアント/サーバで言語脳の切り替えが不要
- JSONで直接データベースに格納できる
- インビーダンスミスマッチが起こらない
その他の良いところ
- 日本語のリソースが豊富
- 対応してるクラウドサービスが豊富
- Windows Azure/Node Ninja…
- 決定を遅延できる
JavaScriptでもWindowsアプリ作りたい! – mayuki
JavaScriptでアプリを作りたい
- JavaScriptが色々な所で動かせる
- パッケージで配布、ウェブではなくてネイティブでしか出来ないことをしたい
- 他のものと共通したコードが使えるかもしれない
アプリケーションの種類
- コンソールアプリケーション
- Windowsアプリケーション
- GUIアプリケーション
- その他(ガジェット、ウィジェット)
コンソールアプリケーション
GUIが必要なCLIのアプリ
- Node.js
- JScript/JScript.NET
Node.js
- 特徴と利点
- npmで豊富なライブラリ
- エンジンがV8なので高速、新しい文法が使える
- *nix系っぽい色がある
JScript
- Windowsには必ず入ってる
- COMとの親和性がよい
欠点
- JScript 5.7相当なので色々ショボイ
- ネイティブに干渉にはCOM経由になる
JScript.NET
- NETFrameworkのパワーがある程度利用できる
- JScript 5.7より文法が強化されてる
欠点
- MSのやる気がない
HTMLアプリケーション (HTA)
IEのエンジンを使った枠を提供するもの
- Windowsなら必ず入ってる
- htmlがそのまま動く
欠点
- 環境のIEのバージョンに依存
- exeにはならない
- IE10だと機能制限がある
Windowsストアアプリ
- Windows8向けの配布・販売できる
- 枠となるアプリが不要
- Windows Runtime(WinRT)でネイティブで動かせる
欠点
- 要 Windows8
Chromium Embedded Framework
- アプリにChromiumを組み込むライブラリ
- Chrome相当でリッチなUIが作れる
欠点
- 枠のアプリケーションを自分で用意する必要
利用点
- ネイティブの機能を使いたい
- ロード機能を使いたい
AppJS
- Chromium Embedded Framework + Node
- マルチプラットフォーム
- アプリケーションの枠をJavaScriptで作れる
欠点
- 動作が不安定
XULRunner
- マルチプラットフォーム
- HTMLとXULで作れる
- アプリケーションの枠は用意されてる
欠点
- 使うまでのハードルが若干ある
- XPCOMと仲良くなる必要がある
Adobe AIR
- マルチプラットフォーム
- Webkitを持ってるのHTMLとJSで作れる
- ランタイムを含む実行ファイルを含めたファイルを作れる
- アプリケーションの枠は用意されている
欠点
- Adobe AIR
LT
新しいOfficeはJavaScriptで動くんです！ – 野呂清二
- Officeストア
- Office 内でHTML+JavaScriptで動くアプリが動いて
Office + JavaScript
- JavaScriptでExcel内で動くアプリ
- Eventを使って色々連動
Offfice JSライブラリ
office.jsというライブラリが用意されてる- JavaScript API for Office
お前は今まで入力したselfの数を覚えているのか – hokaccha
var self = this;
thisが代入されてる変数名を調査するツールをesprimaを使って書いた
私の愛するfor文たち – 川田寛
モテるfor文
線形探索
- iterator
- ポインター
おわり
- メモ : Markdown Life
testemで任意のHTMLでテストを動かす方法とJavaScriptデバッガ連携
testem
Test Runnerのtestemを使ったテストについてメモ
testem自体については以下などを見るといい気がします。
testem の仕組み的には、テストを実行するためのHTMLページを用意して、 testem のローカルサーバ上でそれを表示してテストを実行しています。
testem自体は特にmatcher等は持ってなくて、adapter を書いて、jasmineやBuster.JS、QUnit等の構文を使ったテストを走らせた結果を得られるようにしてます。
Example Projects で紹介されてますが、この辺が充実してるのがtestemのいいところでもあります。
カスタムHTML
testem/views at master · airportyh/testem · GitHub に内蔵されてるjasmineやBuster.JS等のテストを実行するページとなるHTMLがありますが、 今回はこれを自作してみます。
サンプルプロジェクトは以下にあります。
正直デフォルトのBuster.JSと殆ど同じですが、ユーザーが用意したHTMLでも同様のことができることを示すだけのサンプルです。
testem.json の設定ファイルでテストページの ベース となるHTMLとソースファイルを指定しています。
{
"src_files": [
"*.js"
],
"test_page": "tests.html"
}
そしてベースとなるHTMLを見ていきます。
testem-custom-test-page / tests.html
< !doctype html>
<html>
<head>
<meta charset="UTF-8"/>
<title>Test'em</title>
<link rel="stylesheet" href="/testem/buster-test.css"/>
<script src="/testem/buster-test.js"></script>
<script src="/testem.js"></script>
{{#serve_files}}<script src="{{src}}" charset="UTF-8"></script>{{/serve_files}}
</head>
<body></body>
</html>
直接HTMLにテストしたいファイルを並べても問題はありませんが、せっかくなので testem.json と連動した動きにしたいと思います
HTMLを見ると気付きますが、 testem.json の src_files に対応する部分を展開するテンプレートが使えます。
$ testem を実行すると、テストページは以下のように展開されます。
< !doctype html>
<html>
<head>
<meta charset="UTF-8"/>
<title>Test'em</title>
<link rel="stylesheet" href="/testem/buster-test.css"/>
<script src="/testem/buster-test.js"></script>
<script src="/testem.js"></script>
<script src="hello-test.js" charset="UTF-8"></script><script src="hello.js" charset="UTF-8"></script></head>
<body></body>
</html>
後は、普通に http://localhost:7357 なCapture URLにアクセスしていけばテストが動作します。
この辺、シンプルな仕組みながらもちゃんと拡張できるようになっていて、testemよく出来てるなーと思いました。
カスタムHTMLについて調べ始めた理由は何かテストページが文字化けしてたので試してみましたが、文字化けの原因はべつの所だった…
WebStormのJavaScriptデバッガー連携
上記の仕組みを見てピンと来る人は来ると思いますが、 WebStormのJavaScriptデバッガーとの連携がものすごく簡単にできます。
- WebStormからtestacularでテストとデバッグをする方法 | Web scratch
- WebStormのデバッガでBuster.JSのテストをデバッグをする方法 | Web scratch
設定はものすごく単純で、
Type: JavaScript Debug
Name: Chrome
URL to open: http://localhost:7357/
// ポートは設定ファイルのportに合わせます
Remote URL : http://localhost:7357/
// ルートとなる所
たったこれだけで、 $ testem にてCapture待ちの状態にしておいて、
WebStormからDebug実行で先程のJavaScript Debugを起動させるとJavaScriptデバッガー連携ができます。
testemはTest Runnerに徹しているため、複雑な設定なしにすぐにテストを書き始められる所が魅力的で、またシンプルな仕組みなため意外と他との連携がやりやすい作りになっています。
testem ci のコマンドを使えば、
CI as a Service – ブラウザを使ったJavaScriptのテストをCIサービスで動かす方法のまとめ | Web scratch で書いてた、Capture URLにアクセスしてテストを実行してという手順を、testem ciという一つのコマンドでできるのでお手軽です。
利用したサンプル
CI as a Service – ブラウザを使ったJavaScriptのテストをCIサービスで動かす方法のまとめ
CI as a Service
Travis CIを始めとするウェブサービスとして使えるCIを使って、 JavaScriptのブラウザテスト(ブラウザ上でJavaScriptを走らせて行うユニットテスト)をやる方法をサービスごとにまとめてみました。
テストフレームワークとして Buster.JS を使用して行います。
Karma (旧Testacular) では公式サイトにも Karma – Travis CI でCI Serviceとの連携方法が記載されているのでそちらも参考にして下さい。
今回紹介するCI Servicesは以下のものです。
テスト実行の流れ
Jepso CI を除いては、テスト実行の流れ自体は同じなので先に解説します。
- Capture用のローカルサーバを立てる
- テストしたいブラウザで
capture URLへアクセスする - コマンドラインからテストを実行する
- Captureされてるブラウザでテストを実行した結果が得られる
これはJsTestDriverの流れを組んでいるTest Runnerには大体共通してると思います。
この一連の流れをCIサービス上で実行して、Githubにpushするたびに自動でテストを行うようにするのが今回の目的です。
どのCIサービスも裏側ではUbuntu上で動いていて、apt-getやnpmを使ってテスト環境を事前に準備する必要があります。 また、Travis CIやdrone.ioには最初からNode.js環境なども用意されているので、BuildHiveに比べると事前の準備は簡潔に済みます。
Travis CI
Travis CIでは.travis.ymlという設定ファイルを書くことで、テスト環境を揃えることができます。
サンプルプロジェクトは以下においてあります。
テスト環境のセットアップ
サンプルの Browser_CI_as_a_Service / .travis.yml を見ていきます。
env:
- DISPLAY=:99.0
before_script:
- sh -e /etc/init.d/xvfb start
- sh .travis/scripts/setup_busterjs.sh
script:
- npm test
language: node_js
node_js:
- 0.8
Travis CIではデフォルトでNode.js(npm)、PhantomJS、Firefoxの環境が入っているため、before_scriptでインストールするものは、Buster.JSのみとなります。
Travis CIにデフォルトで入っているものは以下で見られます
.travis.yml内に language: node_js を記述しておくと、自動で npm install を実行してくれるので、
レポジトリの Browser_CI_as_a_Service / package.json の devDependencies に Buster.JS を追加しておきます。
{
"author" : "azu",
"name" : "Browser_CI_as_a_Service",
"description" : "Buster.JS with CI Service example",
"version" : "0.0.1",
"scripts" : {
"test" : "node_modules/.bin/buster-test -r specification"
},
"devDependencies" : {
"buster" : "~0.6"
},
"engines" : {
"node" : "~0.8"
}
}
これで、自動で npm install が実行されれば、テスト環境が揃います。
テストの実行を設定
.travis.yml の事前準備の部分を見ていきます
env:
- DISPLAY=:99.0
before_script:
- sh -e /etc/init.d/xvfb start
- sh -e .travis/scripts/setup_busterjs.sh
before_script: で実行しているsetup_busterjs.sh は以下のような内容になってます。
#!/bin/sh
node_modules/.bin/buster-server &
sleep 5
firefox http://localhost:1111/capture &
sleep 5
phantomjs node_modules/buster/script/phantom.js http://localhost:1111/capture &
sleep 5
if [ -x "google-chrome" ]; then
google-chrome --no-default-browser-check --no-first-run --disable-default-apps http://localhost:1111/capture &
sleep 5
fi
ここでやっていることを簡単にまとめると、以下のとおりです。
- GUIテスト用にxvfbをstartする(before_script:)
- Capture用のローカルサーバ(buster server)を立てる(setup_busterjs.sh)
- Firefox/PhantomJSでCature URLにアクセスする(setup_busterjs.sh)
詳しくはTravis CI: GUI & Headless browser testing on travis-ci.orgを参照してください。
後は、テストを実行するだけです。
.travis.ymlの script: で npm test を実行するようにしているので、npm testでBuster.JSのテストが実行されるように package.json に設定します。
(language: node_jsが設定されるなら省略可能です)
script:
- npm test
package.json に以下のように書いて、npm test でBuster.JSのテスト実行されるようにしました。
"scripts" : {
"test" : "node_modules/.bin/buster-test -r specification"
}
Travis CIの有効化
最後に、Travis CIとGithubのレポジトリを連携させます。
Repositories から テストを走らせたいレポジトリを選んでONにします。
Travis CI側で有効にすると、Github側のService Hooksが自動で有効になるので、後はGithubへPushすれば自動でCIが走るようになります。
Travis CIではTravis CI ClientというCLIクライアントがあり、CLIから特定のレポジトリのCIの実行状態や手動での再実行などTravis CIで行う操作をCLI上から行うことができます。
Travis CI Clientは実行結果の取得や過去の履歴などもちゃんと見られるので結構便利です。
より詳しい設定方法等は以下を参照して下さい
- Travis CI: Documentation
- Travis CIでブラウザテスト — The little book of Buster.JS 1.0 documentation
- Karma – Travis CI
drone.io
次は、 drone.io でのテスト環境を揃える方法についてです。
drone.ioではGithub/Bitbucket/Google Codeと連携できますが、今回は先ほどと同様のレポジトリを使うのでGithubの場合です。
また、drone.ioもNode.js環境が用意されていますが、PhantomJSとGoogle Chromeを追加でインストールして、 Firefox/PhantomJS/Google Chromeの3つでテストを動かしたいと思います。
drone.ioもTravis CIと同様にオープンなコードなら無料で殆ど利用できるようになっています。
(前月ぐらいまでは soft limitsな50回/monthの制限が書いてありましたがUnlimitedになってました)
テスト環境のセットアップ
drone.ioはTravis CIのように設定ファイル(.travis.yml)は用意する必要なく、直接ウェブでテスト環境を準備するスクリプトを書くようになっています。
なので、最初にGithubのレポジトリからdrone.ioにプロジェクトを作成します。
まず、 New Project から Githubを選択します。
レポジトリの一覧から、CIをしたいレポジトリを選択して、言語の選択ではNode.jsを選択します。
(言語とかは後から変更できるので適当でも大丈夫です)
そうするとビルドスクリプトを書く画面になるので、テスト環境を準備していきます。
Commandsの部分にビルドスクリプトを書いていきます。
sudo start xvfb
npm -d install
sh -e .travis/scripts/install_phantomjs.sh
sh -e .travis/scripts/install_chrome.sh
# start buster server
node_modules/.bin/buster-server &
sleep 5
# start browsers
firefox http://localhost:1111/capture &
sleep 5
phantomjs node_modules/buster/script/phantom.js http://localhost:1111/capture &
sleep 5
google-chrome --no-default-browser-check --no-first-run --disable-default-apps http://localhost:1111/capture &
npm test
npm install でBuster.JSをインストールして、
PhantomJS(バイナリでインストールしたかったのでnpm経由)とGoogle Chrome(apt-getで取得してインストール)しています。
scriptはazu/Browser_CI_as_a_Service · GitHubにまとめてあります。
(jubianchi/travisci-helper · GitHub
こちらのスクリプトも参考になります)
後は、Travis CIと同じでbuster serverを起動して、ブラウザでCapture URLにアクセスして、
npm test でテストを動かすという感じです。
Travis CIの setup_busterjs.sh を実行させようと思ったのですが、なぜかテストが成功しても終了しないという感じになったので直接書いています。
今回紹介したビルドスクリプトは Build Setup | Browser_CI_as_a_Service から参照できます。
drone.io はTravisCIよりスマートな感じなので、初めてCIサービスを試す場合はこちらのほうが試行錯誤しやすいかもしれません。
BuildHive
基本的にJenkinsの画面なので、人によっては馴染みやすいかもしれません。
BuildHiveもdrone.ioと同じく、ウェブ上でビルドスクリプトを書いてテスト環境を揃えます。
デフォルトでNode.js環境がないため、そこから環境を揃えていく必要があります。
ただし、Travis CIやdrone.ioと違って、一回ごとに仮想環境がリセットされないで継続する感じなので、少しセットアップ方法が変わります。
Add Git Repository からGithubのプロジェクトを選んで有効化します。
設定 を 選ぶとシェルスクリプトを書く欄が出てくるので、この部分にビルドスクリプトを書いていきます。
export PATH=$HOME/.nodebrew/current/bin:$PATH
if [ ! -x "$HOME/.nodebrew/current/bin/nodebrew" ]; then
curl https://raw.github.com/hokaccha/nodebrew/master/nodebrew | perl - setup
nodebrew install-binary stable
nodebrew use stable
fi
if [ -e /tmp/.X1-lock ]; then
rm /tmp/.X1-lock # たまにロックがかかって死ぬので
fi
if [ -z "$DISPLAY" ]; then
export DISPLAY=:1
Xvfb :1 &
fi
npm -d install
node_modules/.bin/buster-server &
sleep 5
firefox http://localhost:1111/capture &
sleep 5
node_modules/phantomjs/bin/phantomjs node_modules/buster/script/phantom.js http://localhost:1111/capture &
sleep 5
npm test
Node.jsはnodebrewを使ってバイナリからインストールしています。
後は、他のものと同じでXvfbをstartして、Capture用のローカルサーバを起動して、Capture URLにアクセスさせて、
npm test するという感じです。
正直、ちゃんとした書き方がよくわからなかったので、適当な部分が多いです。
(Node.jsのアップデートとかも対応したい… buildhive for node)
毎回リセットされない前提で書く必要があるので、どなたかがもう少し良いものを書いてくれるはず。
Jepso CI
最後は Jepso CI についてです。
他のCIサービスが特にJavaScriptに限定されないのに対して、Jepso CIはHTMLとJavaScriptというものに限定される作りになっているので全く別の仕組みです。
Sauce や testling-ci の方に近いジャンルのCIサービスです。
また、まだ安定してるとは言えないので、実験的でテスト結果も安定しないのもあるため実用で使うのは諦めて下さい。
(2013-03-20)
サンプルプロジェクトはazu/BusterJS_JepsoCI · GitHubに置いてあります。
仕組み
他のCIサービスとは異なる仕組みで、基本的にローカルサーバなどは使わないで、
QUnitのようなテストを走らせるための静的なHTMLファイルと、そのファイルへのパスを書いた .jepso-ci.json という設定ファイルだけです。
今回のプロジェクト(azu/BusterJS_JepsoCI · GitHub)ではルートに、テストを走らせるための test.html をおいてるので、
.jepso-ci.jsonは以下のような内容が入ります。
{
"url": "/test.html"
}
次に、BusterJS_JepsoCI / test.html を見ていきます。
Jepso CIのテストの成否判定は、test.html内の2つのプロパティによって判定されます。
window.testsPassed;// bool
window.completedTests;// number
Buster.JSのtest runnerとなる test.html は以下のような感じです。
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
<title>Buster.JS</title>
<link rel="stylesheet" href="http://cdn.busterjs.org/releases/latest/buster-test.css">
<script type="text/javascript" src="http://cdn.busterjs.org/releases/latest/buster-test.js"></script>
<!-- jepso-ci -->
<script type="text/javascript">
// start test
buster.testRunner.on("suite:start", function (results) {
window.completedTests = 0;
window.testsPassed = null;
});
// each passed test
buster.assertions.on("pass", function () {
window.completedTests += 1;
});
// each failure test
buster.assertions.on("failure", function (err) {
window.testsPassed = false;
});
// finish all test
buster.testRunner.on("suite:end", function (results) {
window.testsPassed = results.ok;// result boolean
});
</script>
<!--test source-->
<script src="./src/hello.js" type="text/javascript"></script>
<script src="./tests/async-test.js" type="text/javascript"></script>
<script src="./tests/hello-test.js" type="text/javascript"></script>
</head>
<body>
</body>
</html>
結論をいうと、test.htmlを実行した結果 window.testsPassed が true ならテストが通った事になります。
window.completedTests は非同期のテストがある場合に、++していくとtimeoutを伸ばしてくれるためにあるようです。
実際の処理内容を見ていくと、Buster.JSは .on でテスト実行時のイベントを設定できるので、以下のような処理をイベントに仕込んでいます。
buster.testRunner.on("suite:start", function… はテスト開始時に初期化
buster.assertions.on("pass", function... でテストが通るたびにインクリメント
buster.assertions.on("failure", function... で一つでも失敗したらテスト失敗
buster.testRunner.on("suite:end", function... でテスト終了時にテスト結果を代入
後は、テストファイルを読み込ん実行するだけです。 (単純に*.jsファイルをscriptタグで読み込んでる)
Jepso CIとGithub連携
Githubとの連携はPost-Receive Hooksの”WebHook URLs”に https://jepso-ci.com/api/hook と設定するだけです。
後は、GithubにpushすればJepso CIが動作するようになります。
Jepso CIのページは https://jepso-ci.com/<user>/<repogitory> にアクセスすると表示されます。
HTMLを使ったとてもシンプルな仕組みとなっていて、ビルドステータスもSVGで書かれていたりして面白いサービスだと思います。
公式にも幾つかサンプルが用意されています。
Jepso CIは静的なHTMLでテストを動かしてるので、以下のテンプレートも参考になるかもしれません。
また、testling-ciもHTMLをベースとしたテストができるようになったようです。(2013-03-21)
FAQ
Travis CIやBuildHiveではChromeは使えないの?
Travis CI がUbuntu-64bitに移行した際にChromeが動かなくなっています。(インストールはできます)
Chromium/Chrome does not work in an OpenVZ container · Issue #938 · travis-ci/travis-ci のIssueが解決するまでは使えないです。
追記 : Travis CIとChromeについて
記事ではChromeはインストールしていませんでしたが、以下のような変更を入れることで、 Travis CI上でもChromeを動作させることができます。
- fix Google-Chrome for Travis CI · d736273 · azu/Browser_CI_as_a_Service
- 修正したコミット
- Travis CI – Free Hosted Continuous Integration Platform for the Open Source Community
- 実際に動いてる様子
- Chromium/Chrome does not work in an OpenVZ container · Issue #938 · travis-ci/travis-ci
具体的には以下のようなことが必要になります。
/dev/shmのパーミッションを修正する
sudo chmod 1777 /dev/shm
- Chromeの起動引数に
--no-sandboxをつける
こうすることで、Travis CIの仮想マシン上でもGoogleChromeを動かすことができるようになるので、
Chromeでテストを実行させることが可能です。(--no-sandbox の副作用が何かあるかもしれませんが)
BuildHive では sudo が使えなかったので、上手くインストール出来ませんでしたが、上手くやればインストールできるかもしれません
もっといろんなブラウザのバージョンで試したいんだけど?
今回紹介した Travis CI、drone.io、BuildHive はブラウザに特化した作りでは無いので、自前でバージョンごとのブラウザを用意すればできますが、負荷が大きそうなのでそういう用途は避けましょう。(また全体として成功か失敗かなのであんまりそういう用途ではない気がする)
BrowserStack や testling-ci 、Sauce Labs などブラウザに特化したサービスを利用するか自前のサーバ等でやりましょう。
CI Servicesの環境に何が入ってるかもっとしりたい
公式サイトにサーバのスペックは書いてあると思います。
デフォルトに入ってるものについてはTravis CIはtravis-ci/travis-cookbooks · GitHubを見ると大体わかります。
gildegoma/travis-ci-inspector · GitHubのように走査して何が入ってるか調べる地道な方法も利用できます。
(対話側のコンソールみたいなのが欲しいですね…)
Example Project
今回使用したサンプルプロジェクトは以下のURLで公開しています。
Test Tools
今回は Buster.JS を使用しましたが、Test Toolとしては他に以下のようなものもあります。
Special Thanks
- ようせいさん(@kyo_ago)
jsFiddleを使ってJavaScriptのテストを簡単に動かせるテンプレートサイトを作りました
JavaScript Test Fiddle Template というJSFiddleで使えるQUnit/Jasmine/Mocha/Buster.JSなどを動かすテンプレートを作りました。
使い方は単純で、
- JavaScript Test Fiddleで好きなテスティングフレームワークを選ぶ(なかったらPull Requst)
- JSFiddleがテストのセットアップが入った状態で開かれるので、テストを書く
- “Save” ボタンを押して保存
後は、自由にShareするなどして使えます。
jsFiddleのショートカットや使い方については jsFiddleをとことん楽しむために知っておくと良い15の事 | ゆっくりと… が詳しいです。
画面左隅にもショートカットのチートシートがあります。
jsFiddleのPOST APIを使った単純なHTMLだけのGithub pagesで動いてる静的なサイトです。
jsPerfのテスト版みたいな他の人が実行した結果も残るようなサイトがあるともっとよさそうですね。
- azu/js-test-fiddle · GitHub Githubにソース置いてあります。
- JavaScript Test Fiddle Template
Enjoy testing!
追記: 他に書いてるところがなかったので、スマートフォンなど実行させてremote debuggingする方法について.
jsFiddleにログインしておくと、実験的な機能としてDebugging remote resourcesというものが利用できます。
weinreのサービスを使ったものなので、デバッガーを開く側はWebkit系のブラウザなどが必要です。
jsFiddleにログインする、Runの隣にdebug on mobileというボタンが表示されるので実行すると、
短いURLが表示されるので、デバッグ対象(モバイル端末など)でそのURLにアクセスします。
Chrome等のブラウザ でdebuggerとなってるリンクを開くと、
デバッグ対象が開いてるページをデバッグできるコンソールが開かれます。
Sourceパネルが無いのでJavaScriptのデバッグでできることは限られてますが、簡単にremote debugできるので便利です。
WebStormのデバッガでBuster.JSのテストをデバッグをする方法
WebStormのデバッガをBuster.JSのテスト実行時に使う方法についてです。
最初に要約を書いておくと
- buster static で静的なURLのテストページを用意する
- WebStormのデバッガ(ブラウザ)でそのURLを開く
です。
WebStormのデバッガは、デバッガ連携できるブラウザ(ChromeとFirefox)で指定したURLを開いてデバッガを使う感じ
以前、Testacularを使った場合を紹介しましたが、TestacularはちょっとWebStorm向けに小細工が用意されてる感じなので、
今回のほうがもう少し一般的な感じの内容になると思います。
やっていること自体は下記の記事で解説されているのと同じで、ちょっとパスが違ったり使うコマンドが違う感じなだけだと思います。
- WebStormからtestacularでテストとデバッグをする方法 | Web scratch
- WebStormでtestacularを動かしてデバッグもする #WebStorm #testacular #JavaScript – Qiita
下準備
先にデバッグに使うブラウザの下準備ですが、設定のBrowserからFirefoxとChromeにはSettingsがあり、
ここから使うプロファイルなどを指定出来ます。
Chromeの場合は`Use custom profile directory`にチェックを入れるだけでも、普段と違うプロファイルになるので、
デバッグに使うプロファイルは別のものにしておいたほうがいいと思います。
(特にChromeの場合はデバッガに拡張のjsも含まれたりするのでうざったい)
また、デバッガを使うにはChrome web storeからJetBrains IDE Supportをインストールする必要があります。
Firefoxもアドオンをインストールしておく必要があります。
本編
今回使ったサンプルのプロジェクトです。
まずはWebStormのRun Configurationで buster static のコマンドを叩く設定を作成します。
Type: Node.js Name: buster static Path to Node App JS file: /path/to/buster-static buster-staticバイナリへのパス Application parameters: -p ポート番号 # Application parameters でのポート番号指定は任意
今回は、-p 引数を使ってポート番号を 8989 に指定しています。
このConfigurationを実行してみると、下記のようにbuster-staticのローカルサーバが起動していて、 http://localhost:8989/ にアクセスすると、QUnitなどのようなウェブページとしてテストを実行出来ます。
/Users/azu/.nodebrew/current/bin/node /Users/azu/.nodebrew/current/bin/buster-static -p 8989 Starting server on http://localhost:8989/
次に、デバッガのRun Configurationを作成します。
Type: JavaScript Debug Name: Chrome URL to open: http://localhost:8989/ // ポートはbuster staticの-pで指定したポートに合わせます Remote URL : http://localhost:8989/ // テストのルートディレクトリのRemote URLに指定
このようなデバッガの設定を作成します。 見てみるとわかりますが、 URL to open で指定しているのは、先ほどのテストページのURLです。
Remote URL はプロジェクトのファイルならどれにでも設定出来ますが、これはURLとファイルパスのmapを指定する設定になっています。
buster staticではローカルのディレクトリ構成がそのまま使われるため、
http://localhost:8989/ に該当するディレクトリに対して http://localhost:8989/ を設定すれば良いことになります。(この場合はプロジェクトのルート)
テストページのネットワークを見ると、テストファイルがプロジェクトの構造そのままに配置されてることがわかる。
実行方法
実際にWebStormのデバッガを使ってみます。
buster static を実行(run)してローカルサーバを起動しておきます。
そして、WebStormから適当なファイルにブレークポイントを貼っておいて、先ほど作成したChromeの設定をDebugで実行します。
すると、上記のようにブレークポイントで止まってステップ実行などができるようになります。(この辺は普通のデバッガと同じです)
ユースケースとして、テスト実行中にJavaScriptのどこかで例外が発生してしまっていてテストが失敗してしまうケースがあると思います。
Chrome Dev ToolsなどにExceptionがあった時にbreakする設定がありますが、WebStormにも同様の機能があり、
Ctrl + Shift + Aのコマンド検索で `View Breakpoints` を開くとブレークポイントの一覧が表示されます。
この中のAll exceptionsにチェックを入れておけば、例外が発生した場所でbreakされるので、原因となる場所が発見しやすいです。
エディタ上からテストケースにブレークポイントを貼って、ステップ実行して実装の内部を見ながらできるとブラウザとの切り替えが少なくなってデバッグがしやすくなると思います。
まだ、デバッグ実行するとテストの成否のフィードバックが薄かったりする部分がちょっと中途半端ではあります。
以上で、WebStormからtestacularでテストとデバッグをする方法よりやや一般よりのWebStormのデバッガを使う方法についての紹介は終わりです。
サンプルのプロジェクトは以下に置いてあります。
.ideaディレクトリも入ってるのでRun Configurationもそのまま入っています。(nodebrewじゃない場合はパスとか変更が必要ですが)
調査メモ
buster static の場合はQUnitなどでおなじみの静的なテスト実行ページが用意されるため、
remote URLでそのURLを指定すれば、問題なくWebStormからJavaScriptデバッガを使うことができた。
(これはテストファイルなどのパスも静的であるため)
buster server の場合は、テスト実行ページのURLにランダムなセッションIDが含まれるため、
WebStormでremote URLを指定することが困難となる。
http://localhost:1111/slaves/b8b98e2a-d00d-4ba9-a1b6-0d7c2a9339ae/browser
そのため、このセッションIDが入ったURLを固定するオプションが必要になるが、
それは buster test コマンドのオプションに存在する。
-p, --static-paths
buster test –static-paths のようにテストを実行すると、
buster serverを使った場合でも静的なパスを吐くようになる。
http://localhost:1111/sessions/static/<テストディレクトリ>
これで、buster serverの場合でも静的なパスを吐くため、
WebStormのデバッガが使えるような状態にはなるのだけど、 buster testを行った時点で既にテストを実行してるわけなので、
(WebStormのデバッガはURLを開くことでしか開始できないため)デバッガを上手く混ぜることができなかった。
(何かいい方法があったら教えて下さい)
内部的な話としては、サーバモジュールのrampのcreateSession()のオプションにstaticResourcesPath : trueを渡すことで、
静的なパスになるようになっている。
このオプションが、buster.jsの設定ファイルやbuster serverのオプションで設定できると、buster serverでもデバッガが機能しそうな感じではあるのだけど…
Frontrend Vol.4 アウトラインメモ
Frontrend Vol.4 に参加してきたのでその時のメモです。
CA Frontrend v04
- Frontrend Vol.4 powered by CyberAgent, Inc. : ATND
- 場所: サイバーエージェント本社 13F セミナールーム （東京都渋谷区道玄坂一丁目12番1号渋谷マークシティ ウエスト13階）
Frontrend Vol.4 powered by CyberAgent, Inc. に回答するとスライドがある
JavaScript Development Tools – JavaScript開発の効率アップ – Layzie
- JavaScript開発に役立つGUI
- JavaScript開発に役立つCUI
Chrome Developer Tools
- ショートカット
- ブレークポイント
- DOMの属性が変更
- Throw Error
- XHRでURLに通信した時にbreak
- etc…
- Timeline
- Profile
chorme://net-internals
- SPDYなどの通信を見られる
Charles
- デバッグ用Proxy
- Fiddler
- MapLocal
- URL先のファイルとローカルファイルをすり替えられる
- AutoResponder的な機能
- Throttle
- 回線のエミューレート
- 3G相当の通信の遅さをサイト
Dochub
http://dochub.io/#css/
- JS/CSS APIの検索サイト
- MDNのコンテンツの検索
jsFiddle
- jsbin/jsdot.it 系のサイト
- Debug on Mobile
- モバイル用のデバッグURLがある
jsPref
- JavaScriptのベンチマークを見るサイト
browsering
- substack
- ブラウザのテスト
- $20/month
- ci.testing.com
JSHint
- JavaScriptのLintをかけるツール
jq
- jsonのsed
- jsonをqueryでいじれる
- jsonを整形表示される
Doctor JS
- ctag的なJavaScriptのタグファイルを作成するツール
- 静的解析したファイルを作ってエディタ
Yeoman
- パッケージ管理
- 土台作るCLI
- scaffold
- grunt server
Nodefront という類似なCLIもある
jQuery Performance Tips – jQueryにおける高速化 – @pocotan001
マシンの仕事を少なくすることが、高速なプログラムになる
jQueryライクを保ってパフォーマンスチューニング
- ファイルサイズ
- セレクタ
- リフロー影響
ファイルサイズ
- jQuery 1.9と 2.0をIEの条件コメントで読み込むものを分ける
- スタート時には最小構成で始めるほうがいい
jquery migrate plugin
- jQuery 1.9で削除されたAPIを補完するプラグイン
- 非推奨のことについても警告してくれる
- 警告の詳しい内容はGithubに
jQuery セレクタ
$("#target p");
$("#target").find("p")
$('#tareget).find('p:first');
- QuerySelectorAll -> 失敗
- getElementTagName
- jQueryパース
次のように分けるか、:first-child を使う
$('#tareget).find('p').first();
リフロー
HTML – DOM – レンダーツリー – CSSOM – CSS
描画のフローは一度ではなく、段階的に描画していってる
- CSS Reflow
- Chrome Devloper Tools – Timelimeで可視化できる
DOMツリーとレンダーツリー
- DOMツリーにはあって、レンダーツリーにはないものも
- display : noneなどされてる要素はレンダーツリーには出てこない
- display : blockにして見えるようになった時、レンダーツリーに出現する
- これがリフローに関係する
同じリフローが起きる処理を2回呼んだ場合は、ブラウザがクッションを挟んで1度に済ませたりする
$('p').css('margin' , '5px');
リフローのトリガー
- ユーザー入力
- positionの変更
リフローを減らす
- hideにしてから変更すればリペイントはまとまる
- $.cssはオブジェクトで指定したほうがいい。
- offset()等の計算は変数に入れて使いまわす
の中にscriptがある場合
表示 -> JS -> 変更
でdocument.readyで動かす
JS -> 表示 ->
ボトルネックを解消をする
- 描画コストの高いCSS
- アニメーション
- ループ
Chrome Cannaryを使う
- cannaryにしかない機能もある
- Timelimeで表示する内容のしきい値を指定できる(ALl , 15ms)
- 10ms以内でするのがモバイルだとちょうどいい
- Timelineの山がコストの大きさ
- 設定 -> Rendering
- レンダリングの可視化
- FPSの表示
- 連続的なレンダリングの可視化
jQueryアニメーションとCSS3
- CSSのほうがネイティブに近いので基本的には早い
- requestAnimationFrame
まびく
処理を間引いて行う
- throttle
- debounce
その他
- スタイルの変更を末端要素で影響範囲を抑える
- アニメーションはfixedにしておく
- Tableレイアウトをしない
- テーブルは特別的な感じなので
Javascript – テストしやすいJavaScriptとテストについて – CSSRADAR
- テストしやすいJavaScriptとは
- ユニットテストツールとは
テストしやすいJavaScriptとは
ベストプラクティス
- オブジェクト指向JavaScript
- デザインパターン
- MV*構造
- ユニットテスト
リファクタリングを前提に考える
- リファクタリングをする前提で書く
- テストはリファクタリングを補助する
- ロジックにもデザインがある
テストしずらいコードを見ていく
- テストしにくいコードからテストしやすいコードを学ぶ
- QOF
untestable code
- 50行の中に5つの役割がある
- jQueryのready
- clickイベント
- フォームのインプット内容を取得
- appendでDOM捜査
- appendするHTML生成
- // XHR
- コードの役割分担が複雑だとテストしにくいコードなる
- コード間で密接な関係を持つとテストしにくくなる
- これをリファクタリングしていく
テスト駆動リファクタリング
- テストはデザイン
- パターンはよくある問題の解決する
リファクタリング
- まずは、テストコードからアプリケーションコードへアクセスできるようにする
- init にとりあえず、以前のreadyの中身を突っ込む
QUnitを使ってテストコードを書いていく
- 名前空間があるか
- getDataでユーザーが入力したデータを取得できてかをテストを書く
- 単一責任の原則 -> それぞれのユニットが正しいかを確認していく
- setupで、ユーザーの入力を入れて、teardownでユーザーの入力を消す
テストツール
Jasmine
- BDD
- descript 何が it どうなる
Qunit
- jQueryが元々
- 安定している
- test 振る舞い
Mocha
- Node.jsが元々
- assertion libraryを持ってない
- chai , expect.js
PahntomJS
- ヘッドレスブラウザ – test runnerとして使う
Grunt.js
- ビルドツールで自動化
Koans
- テストで学ぶJavaScript
Q&A
- チームの他の人がテストしたがらない場合に何から始めるか?
- テストは何を行うものが体験してもらう
- Koansみたいな動かしてみるところからやってみる
jQuery to Backbone – アーキテクチャを意識したJavaScript入門 – ahomu
- jQueryについて
- Backbone.jsについて
- jQuery to Backbone.js
jQuery replace backboneではなく、フォーカスを移すイメージ
Backbone.js
- 軽量で短く
- jQuery/Unserscore.jsに依存してる
jQuery
- DOM APIを隠蔽して簡潔に記述する
- クロスブラウザ対応の諸問題を対処
- プラグインが豊富
jQueryが解決しない問題
- アプリケーションコードの肥大化
- スパゲティコード
- テストしにくいコード
これをBackboneを使いつつ上手く解決していく
MV*
- TodoMVC
- JavaScriptのMV*ライブラリを作ってサンプルのTodoアプリを作ってサイト
- 30個以上ある
Backbone.js
- やさしい構造をサポート
- Model/View/Router
デザインパターン
- デザインパターンから一般的なパターンを学ぶ
facade
Singleton
- オブジェクトが1個にあって欲しい
FlyWeight
- 動的にインスタンスを生成し、同一のものは使いまわすパターン
Observer
- イベントをつけて監視して発火する
- 1 vs 1
Mediator
- イベントの仲介をするパターン
- Pub/Sub – 3者
jQuery to Backbone.js
View
- 見た目入力
- DOM要素の管理
- イベント制御
Backbone.View.extend
Model
- 取り扱うデータの単位
- ストレージとの通信・動機
- APIや情報のレコードを表現
Backbone.Model.extend
Collection
- Modelが集合したリスト
- リスト操作など
- Modelとの通信、同期
Backbone.Collection.extend
Router
- URLによるルーティング
- hisotyr.pushState
DEMO
- Backbone.Viewを作成
- renderメソッドを中執
- テンプレートの分離
モジューラーJavaScript
- 依存性の低さによる変更のひしゃすさ
- 継続的なメンテナンス性がアップする
ModelとCollection
- CollectionはModelsを束ねるもの
- new Model()
Collectionのソート
- collectionのcomparatorにソート条件を書く
sortにイベントをつけておいて、sortされたらrenderメソッドを呼ぶようにする
アーキテクチャを考えるためのBackbone.js
- アーキテクチャを実際の実装から学べる
その他
- Marionette
- Backboneをラップしてlistなどを追加してるフレームワーク
- Chaplin
- Thorax
Q&A
- Backbone.js 使ってよかったどうか?
- Viewが多いけどRequire.jsで分けて読んでる
- Backbone.jsでjQuery/Zepto.jsの選択肢、スマートフォンだとどっちを使う?
- プロジェクトでバラバラ
- Zepto.js のほうがファイルサイズは小さい
- jQueryはベンチマークテストだと有利
- モバイルでCanvas使い物になる?
- Androidとかに苦しめられる
WebStorm(JetBrains製IDE全て)が75%オフのセールをしていました[終了済]
マヤ暦の終わりのセールということでIntelliJ IDEAを始めWebStormやAppCode等JetBrains製のIDEが全て75%オフになっています。
- OS:Windows Vista, 7、Max OS X
- ブラウザ:Firefox
- Twitterのアカウントはこちら
- メールアドレス(Twitterの方が確実)
