Fish Shellでコマンドの実行結果を変数に代入する方法

fish 2.0がでたので、fish(friendly interactive shell)色々と試していますが文法等が違う所も多いです。

よく使いそうな、ある実行結果を変数に入れて使うような場合に必要な機能、一般にはCommand Substitutionという名前みたいで、Bashやzshでの

$(command)
# や
`command`

などの機能のことです。

fish shellでは

help expand-command-substitution

と叩くと解説が見られます。

fish shellでは単純に

(command)

とすれば実行されるようです。

set wd (pwd)
echo $wd

なので、上記のようにやると $wd には pwd の実行結果が入るようになります。

挙動の動画

参考

追悼 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の未来の予感

セキュリティバグ

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

  • <XMLTagContent XMLWhitespace /> という感じにワカれてる
  • 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

おわりに

メモ

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回「ブラウザー勉強会」 アウトラインメモ

第4回ブラウザー勉強会

第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

テンプレートエンジンとは何か

テンプレートエンジンとはデータとテンプレートをあわせて表示する

mustache.js

テンプレートエンジンを作る

簡単な言語実装ができる

  • テンプレートエンジンはロジックが入るならある種のプログラムになる。

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ライブラリ


お前は今まで入力したselfの数を覚えているのか – hokaccha

var self = this;

thisが代入されてる変数名を調査するツールをesprimaを使って書いた

私の愛するfor文たち – 川田寛

私の愛するFor文たち

  • モテるfor文

  • 線形探索

  • iterator
  • ポインター

おわり

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.jsonsrc_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にアクセスしていけばテストが動作します。

1 testem

この辺、シンプルな仕組みながらもちゃんと拡張できるようになっていて、testemよく出来てるなーと思いました。

カスタムHTMLについて調べ始めた理由は何かテストページが文字化けしてたので試してみましたが、文字化けの原因はべつの所だった…

WebStormのJavaScriptデバッガー連携

上記の仕組みを見てピンと来る人は来ると思いますが、 WebStormのJavaScriptデバッガーとの連携がものすごく簡単にできます。

設定はものすごく単純で、

Type: JavaScript Debug
Name: Chrome
URL to open: http://localhost:7357/
// ポートは設定ファイルのportに合わせます
Remote URL : http://localhost:7357/
// ルートとなる所

RunDebug Configurations 2013 04 04 23 58 18

たったこれだけで、 $ testem にてCapture待ちの状態にしておいて、 WebStormからDebug実行で先程のJavaScript Debugを起動させるとJavaScriptデバッガー連携ができます。

Hello test js  testem custom test page   ~DropboxworkspaceJavaScriptprojecttestem custom test page 2013 04 04 23 57 21

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 を除いては、テスト実行の流れ自体は同じなので先に解説します。

  1. Capture用のローカルサーバを立てる
  2. テストしたいブラウザで capture URL へアクセスする
  3. コマンドラインからテストを実行する
  4. Captureされてるブラウザでテストを実行した結果が得られる

これはJsTestDriverの流れを組んでいるTest Runnerには大体共通してると思います。

この一連の流れをCIサービス上で実行して、Githubにpushするたびに自動でテストを行うようにするのが今回の目的です。

どのCIサービスも裏側ではUbuntu上で動いていて、apt-getやnpmを使ってテスト環境を事前に準備する必要があります。 また、Travis CIdrone.ioには最初からNode.js環境なども用意されているので、BuildHiveに比べると事前の準備は簡潔に済みます。

travis-ci.org 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.jsondevDependenciesBuster.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

ここでやっていることを簡単にまとめると、以下のとおりです。

  1. GUIテスト用にxvfbをstartする(before_script:)
  2. Capture用のローカルサーバ(buster server)を立てる(setup_busterjs.sh)
  3. 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  Free Hosted Continuous Integration Platform for the Open Source Community 2013 03 20 17 31 36

Travis CI側で有効にすると、Github側のService Hooksが自動で有効になるので、後はGithubへPushすれば自動でCIが走るようになります。

Travis CIではTravis CI ClientというCLIクライアントがあり、CLIから特定のレポジトリのCIの実行状態や手動での再実行などTravis CIで行う操作をCLI上から行うことができます。

Travis CI Clientは実行結果の取得や過去の履歴などもちゃんと見られるので結構便利です。

より詳しい設定方法等は以下を参照して下さい

drone.io drone.io

次は、 drone.io でのテスト環境を揃える方法についてです。

drone.ioではGithub/Bitbucket/Google Codeと連携できますが、今回は先ほどと同様のレポジトリを使うのでGithubの場合です。

また、drone.ioもNode.js環境が用意されていますが、PhantomJSとGoogle Chromeを追加でインストールして、 Firefox/PhantomJS/Google Chromeの3つでテストを動かしたいと思います。

Admin  azu 2013 03 20 18 43 45

drone.ioもTravis CIと同様にオープンなコードなら無料で殆ど利用できるようになっています。
(前月ぐらいまでは soft limitsな50回/monthの制限が書いてありましたがUnlimitedになってました)

テスト環境のセットアップ

drone.ioはTravis CIのように設定ファイル(.travis.yml)は用意する必要なく、直接ウェブでテスト環境を準備するスクリプトを書くようになっています。

なので、最初にGithubのレポジトリからdrone.ioにプロジェクトを作成します。

まず、 New Project から Githubを選択します。

Add Repo  drone io 2013 03 20 19 08 02

レポジトリの一覧から、CIをしたいレポジトリを選択して、言語の選択ではNode.jsを選択します。
(言語とかは後から変更できるので適当でも大丈夫です)

そうするとビルドスクリプトを書く画面になるので、テスト環境を準備していきます。

Build Setup  Browser CI as a Service 2013 03 20 19 42 58

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.cloudbees.com BuildHive

基本的にJenkinsの画面なので、人によっては馴染みやすいかもしれません。
BuildHiveもdrone.ioと同じく、ウェブ上でビルドスクリプトを書いてテスト環境を揃えます。

デフォルトでNode.js環境がないため、そこから環境を揃えていく必要があります。
ただし、Travis CIやdrone.ioと違って、一回ごとに仮想環境がリセットされないで継続する感じなので、少しセットアップ方法が変わります。

Add Git Repository からGithubのプロジェクトを選んで有効化します。

BuildHive Cloud Continuous Integration 2013 03 20 20 32 57

設定 を 選ぶとシェルスクリプトを書く欄が出てくるので、この部分にビルドスクリプトを書いていきます。

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.com Jepso CI

最後は Jepso CI についてです。
他のCIサービスが特にJavaScriptに限定されないのに対して、Jepso CIはHTMLとJavaScriptというものに限定される作りになっているので全く別の仕組みです。

Saucetestling-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.testsPassedtrue ならテストが通った事になります。 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を動作させることができます。

具体的には以下のようなことが必要になります。

  1. /dev/shm のパーミッションを修正する
sudo chmod 1777 /dev/shm 
  1. Chromeの起動引数に --no-sandboxつける

こうすることで、Travis CIの仮想マシン上でもGoogleChromeを動かすことができるようになるので、 Chromeでテストを実行させることが可能です。(--no-sandbox の副作用が何かあるかもしれませんが)


BuildHive では sudo が使えなかったので、上手くインストール出来ませんでしたが、上手くやればインストールできるかもしれません

もっといろんなブラウザのバージョンで試したいんだけど?

今回紹介した Travis CIdrone.ioBuildHive はブラウザに特化した作りでは無いので、自前でバージョンごとのブラウザを用意すればできますが、負荷が大きそうなのでそういう用途は避けましょう。(また全体として成功か失敗かなのであんまりそういう用途ではない気がする)

BrowserStacktestling-ciSauce 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

jsFiddleを使ってJavaScriptのテストを簡単に動かせるテンプレートサイトを作りました

JavaScript Test Fiddle Template

JavaScript Test Fiddle Template というJSFiddleで使えるQUnit/Jasmine/Mocha/Buster.JSなどを動かすテンプレートを作りました。

使い方は単純で、

  1. JavaScript Test Fiddleで好きなテスティングフレームワークを選ぶ(なかったらPull Requst)
  2. JSFiddleがテストのセットアップが入った状態で開かれるので、テストを書く
    Edit this Fiddle  jsFiddle 2013 03 03 02 53 02
  3. “Save” ボタンを押して保存
    Edit this Fiddle  jsFiddle 2013 03 03 02 53 56

後は、自由にShareするなどして使えます。

jsFiddleのショートカットや使い方については jsFiddleをとことん楽しむために知っておくと良い15の事 | ゆっくりと… が詳しいです。
画面左隅にもショートカットのチートシートがあります。

jsFiddleのPOST APIを使った単純なHTMLだけのGithub pagesで動いてる静的なサイトです。
jsPerfのテスト版みたいな他の人が実行した結果も残るようなサイトがあるともっとよさそうですね。

Enjoy testing!

追記: 他に書いてるところがなかったので、スマートフォンなど実行させてremote debuggingする方法について.

jsFiddleにログインしておくと、実験的な機能としてDebugging remote resourcesというものが利用できます。
weinreのサービスを使ったものなので、デバッガーを開く側はWebkit系のブラウザなどが必要です。

jsFiddleにログインする、Runの隣にdebug on mobileというボタンが表示されるので実行すると、
短いURLが表示されるので、デバッグ対象(モバイル端末など)でそのURLにアクセスします。

Edit this Fiddle  jsFiddle 2013 03 03 13 48 06

Chrome等のブラウザ でdebuggerとなってるリンクを開くと、
デバッグ対象が開いてるページをデバッグできるコンソールが開かれます。

Edit this Fiddle  jsFiddle 2013 03 03 13 53 15

Sourceパネルが無いのでJavaScriptのデバッグでできることは限られてますが、簡単にremote debugできるので便利です。

WebStormのデバッガでBuster.JSのテストをデバッグをする方法

WebStormのデバッガをBuster.JSのテスト実行時に使う方法についてです。

最初に要約を書いておくと

  1. buster static で静的なURLのテストページを用意する
  2. WebStormのデバッガ(ブラウザ)でそのURLを開く

です。
WebStormのデバッガは、デバッガ連携できるブラウザ(ChromeとFirefox)で指定したURLを開いてデバッガを使う感じ 

以前、Testacularを使った場合を紹介しましたが、TestacularはちょっとWebStorm向けに小細工が用意されてる感じなので、
今回のほうがもう少し一般的な感じの内容になると思います。

やっていること自体は下記の記事で解説されているのと同じで、ちょっとパスが違ったり使うコマンドが違う感じなだけだと思います。 

下準備

先にデバッグに使うブラウザの下準備ですが、設定のBrowserからFirefoxとChromeにはSettingsがあり、
ここから使うプロファイルなどを指定出来ます。 

Chrome Settings 2013 02 20 23 35 11

Chromeの場合は`Use custom profile directory`にチェックを入れるだけでも、普段と違うプロファイルになるので、
デバッグに使うプロファイルは別のものにしておいたほうがいいと思います。
(特にChromeの場合はデバッガに拡張のjsも含まれたりするのでうざったい)

また、デバッガを使うにはChrome web storeからJetBrains IDE Supportをインストールする必要があります。

Firefoxもアドオンをインストールしておく必要があります。 

本編

今回使ったサンプルのプロジェクトです。

まずはWebStormのRun Configurationで buster static のコマンドを叩く設定を作成します。

RunDebug Configurations 2013 02 20 23 36 05

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を作成します。

RunDebug Configurations 2013 02 20 23 36 36

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/ を設定すれば良いことになります。(この場合はプロジェクトのルート)

テストページのネットワークを見ると、テストファイルがプロジェクトの構造そのままに配置されてることがわかる。

 Buster JS 2013 02 20 23 37 02

実行方法

実際にWebStormのデバッガを使ってみます。

buster static を実行(run)してローカルサーバを起動しておきます。
そして、WebStormから適当なファイルにブレークポイントを貼っておいて、先ほど作成したChromeの設定をDebugで実行します。

 Test test js  WebStormBusterJS   ~DropboxworkspaceJavaScriptprojectWebStormBusterJS  JetBrains WebStorm  WebStorm WS 126 309 2013 02 20 23 37 44

すると、上記のようにブレークポイントで止まってステップ実行などができるようになります。(この辺は普通のデバッガと同じです)

ユースケースとして、テスト実行中にJavaScriptのどこかで例外が発生してしまっていてテストが失敗してしまうケースがあると思います。
Chrome Dev ToolsなどにExceptionがあった時にbreakする設定がありますが、WebStormにも同様の機能があり、
Ctrl + Shift + Aのコマンド検索で `View Breakpoints` を開くとブレークポイントの一覧が表示されます。

 2013 02 20 23 38 13

この中のAll exceptionsにチェックを入れておけば、例外が発生した場所でbreakされるので、原因となる場所が発見しやすいです。

エディタ上からテストケースにブレークポイントを貼って、ステップ実行して実装の内部を見ながらできるとブラウザとの切り替えが少なくなってデバッグがしやすくなると思います。
まだ、デバッグ実行するとテストの成否のフィードバックが薄かったりする部分がちょっと中途半端ではあります。

以上で、WebStormからtestacularでテストとデバッグをする方法よりやや一般よりのWebStormのデバッガを使う方法についての紹介は終わりです。

サンプルのプロジェクトは以下に置いてあります。
.ideaディレクトリも入ってるのでRun Configurationもそのまま入っています。(nodebrewじゃない場合はパスとか変更が必要ですが) 

 
おまけで、Buster.JSではbuster serverではなくbuster staticを使いましたが、理由としては以下の通り

調査メモ

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を始めWebStormAppCode等JetBrains製のIDEが全て75%オフになっています。

Read the rest of this entry »

1 2 3 4 5 6 33
プロフィール: azu(アズ)
JavaScriptやObjective-CやWeb系色々について。
  • OS:Windows Vista, 7、Max OS X
  • ブラウザ:Firefox
  • Twitterのアカウントはこちら
  • azu_re
  • メールアドレス(Twitterの方が確実)
  • info@ドメイン名
リンク