簡単にやり方を書くと、Node環境を用意した状態で

git clone https://github.com/rmurphey/js-assessment.gitなどで、リポジトリをダウンロードして、
ダウンロードしたディレクトリ内で、 nodeを使って以下のようコマンドを実行してテストが実行できるローカルサーバを立ち上げます。

npm install
node bin/serve

実行した状態で http://localhost:4444 というURLに行けば、Mochaで書かれたテストが走った結果が表示されます。

テストを通るコードの書き方は、node bin/serve を実行した時に表示されますが、

To work on the tests, open a browser and visit http://localhost:4444. Then,
edit the tests in the files in the tests/app directory, reloading your browser
to see whether the tests are passing.

Each test will look something like this:

    it("you should be able to return a truthy value", function() {
      // define a function for fn so that the following will pass
      expect(fn()).to.be.ok();
    });

In the case of the above test, you'd need to define a value for fn (by default,
fn is a function that does nothing):

    it("you should be able to return a truthy value", function() {
      // define a function for fn so that the following will pass
      fn = function() {
        return true;
      };
      expect(fn()).to.be.ok();
    });

For some tests, the instructions will be more involved; in those cases, the
inline comments should give you the details you need.

と書かれているように、tests/appにあるコードを編集して、それぞれのitの中にテストケースを通るような関数を定義したりして、
http://localhost:4444にアクセスして全てのテストが通るようにするのが目的です。

e.g) solve Arrays Test · c955516 · azu/js-assessment

テストコードはNodeで動くテストフレームワークのMochaを使って書かれています。
expectで期待してる動作は結構そのまま分かる感じなので、itのテスト文とあわせれば、大体期待してる挙動はわかるとは思いますが、
Mocha自体の挙動も少し知っておいたほうがいい場合もあります。

• ryu22eBlog : Node.jsのテスティングフレームワーク「Mocha」（前編）

用意されてるテストはArrayの機能のテストやBackboneを使ったViewのテスト、非同期のテスト等が入っています。

これで、A Test-Driven JS Assessmentの紹介は終わりですが、これ見た時に禅の公案（Koan）に何か似てるなとか思った。
JavaScriptでは

• liammclennan/JavaScript-Koans ( javascript-koans – Javascript learning tool. – Google Project Hosting )
• 禅の公安スタイルでCoffeeScriptを学ぶ「coffeescript-koans」 – にのせき日記

あたりが知られてそうな気がします。(他にも色々あるみたいだけど Search · Koans Javascript ) 
Koanとは以下のような穴埋め用のテストがかかれていて、そのテストを正しく書いてプログラミングを学べるものです。

test("not", function() {
    not(__, 'what is a false value?');
});

という穴埋め問題だったら

test("not", function() {
    not(false, 'what is a false value?');
});

のように、穴埋めするという感じのものです。

KoanとJS Assessmentを比較すると、Koanは穴埋めという要素が強くてロジックなどは用意されてる感じになっています。
一方 、A Test-Driven JS Assessmentはテストだけ書かれていて、ロジックなどを書いてそのテストを通るような関数を書くというものになっています。
似ているところもありますが、やりたいことは逆な感じなので、A Test-Driven JS Assessmentの場合は人によって答えが全然違うという事もありえて、
実際のテストファーストなものを書くのに近い感じになっていそうです。

これを書きながら、JavaScriptを学ぶ時に、最初からテストと絡めて学習したほうが良い感じになるのかなということについて考えていました。
実際に新人教育とかでそういう事をしている会社さん等の成果とかを聞いてみたいですね。

• A Baseline for Front-End Developers – Adventures in JavaScript Development
• TestFirst.org – The Home of Test-First Teaching

ECMAScript勉強会

ECMAScript概要 – rika_t

ECMAScript Study #1 Overview

途中参加

newがあるのはなぜ

プリミティブな型もメソッドやプロパティを持てるようにしたいため、ラッパーでラップしてた。

globalオブジェクト

globalオブジェクトは必ずしもwindowではない

オブジェクトとクラス

内部的には[[Class]]というクラスという文字列がでてきてた。

• ES6から内部的にClassというものがなくなってきてる。
• リテラル記法やコンストラクタを使って様々なオブジェクトを表現してる
• NativeBrandという名前になってる

prototype

• 仕様書にのってるprototypeの図はわかりにくい

変数宣言

• “var”キーワードの後にIdentifierを与える
• opt = option としてInitiliser = “str”みたいに初期化も同時にできる
• IdentifierName
  • IdentifierStart (変数名の最初に文字列) か初めて
  • IdentifierName IdentifierPart
• let から始まる内容はここで定義してる内容をかかれてる(他を見なくてもいい)

変数宣言の処理

• return (normal,empty,empty) normalは正常終了

ES.next 追っかけ – teramako

ES.next 追っかけ – ECMAScript 勉強会

メーリングリストの購読

• es-discussの購読
• ES.nextに追うため見るメーリングリスト
• 流量が多い

構文抽出

• wiki.ecmascript.org に最新版のドラフトがアップロードされる
• 更新内容は色分け表示されてる
• ドラフト仕様から構文部分のみ抽出したものを作成

Mozillaの実装追いかけ

＊SpiderMonkeyのHarmony実装をトラッキングするメタバグがある

構文解析

JavaScriptがどうやって構文解析していくか

• Reflect.parse()メソッド
• 結果をオブジェクトのツリーで返してくれる
• reflect.jsmを読み込んでReflect.parseが利用できる

iv/js

• ES.nextの実装をパースできるツール
• http://constellation.github.com/iv/js/es.next.html
• esprimaを使ったものも最近でてきた
• http://esprima.org/demo/parse.html

quasiリテラル

• ヒアドキュメント的に使えそう

ES.next the corner case – Constellation

ES.next the corner cases

• esprima
  • コミッターやってる

ConstDeclarationの話

• initializer必須
• Blockスコープ
• BNFだけでは判断できないで、semaniticsも見ないと行けないようになった *

block scope

• staticに解析可能
• ブロックスコープになったことで、ランタイムでないと判定できなかったのが、静的に解析が可能

• そのため速度がかなりよくなった

• 再代入はsyntax errorにする

• これもパース時に判断できるので、速度がよくなる

  const V = 20; V = 30;// syntax error

• early errorに分類(run timeより前)

egal operator

• is
• isnt
• より値の同一性に重きをおいたequal
• is/isnt はContextual Keyword
• Statement先頭にくるキーワードはcontextual Keywordになる
  • ofとか
• 文脈依存のキーワードのような扱い方をされるということ

<| operator トライアングル演算子

• 常にArrayを継承できる
• <|の右はリテラルしか置けない
• なぜリテラルのみ
  • JITとかに破壊的になってしまう
  • inline cacheが破壊されて、キャシュが機能しない
• 右側にfunctionリテラルときは挙動が変わる
  • 継承っぽくなる
  • Base.prototypeを[[Prototype]]にもつObjectが生成されて、インスタンスのprototypeに設定される
• ECMAScript と OOP パラダイム、それに ES.next の議論中 OOP 周りのシンタックス – oogattaの勉強日記

ES.next Library Extension

• String/Number/Function などに機能を増やす
  • repeat
  • startsWith
  • などの便利な関数
• GlobalなものをNumberにいける
  • isFinite
  • parseInt などをNumberにも追加する

duplicateな変数purge機構

• 関数スコープのレキシカルスコープ内で変数宣言が被った時にsyntax errorになる

new Date(NaN)

• ES.nextのnew Date(NaN).toString() Invalid Dateをかえすようになった

propertyの登場順

• for-in , Object.keysなどの登場順が規定される

LHS

• left hand side
• 今まで()でくくって中が式なら何でも入ってた
• それがleft hand side expressionという部類のみになった

(1,2,3) = 20;

というのがSyntaxErrorになる(ES5はReferrenceErrorなった) またパース時に判断できる

ES.nextのバグ

• draftにはバグある

({responseText }) = res;

そもそもオブジェクトリテラルの解釈

名前

• ES.next
  • バージョン番号がアレなので.nextという名前になってる
• strawman(ストローマン)
  • とりあえずな感じのバージョン
• Harmony
  • いずれかのバージョンにはいるかも的なもの

A brief history of ECMAScript versions (including Harmony and ES.next)

CoffeeScript

• is/isnt みたいにセマンティックが同じなのに、挙動が違うことで論争が起きるのが怖い
• => とかでも論争がおきてる

ECMAScript読書会

• 6章からが本番
• Annexに定義などが入ってる
• Annex C はStrict mode
• D, Eが変更点修正点

4.概要

• この仕様では外部データの入力や計算結果の出力に関する規定はありません

• 仕様外だが他にもオブジェクトがあるかもしれない事は考慮する(DOM)

4.2.2 Strict mode

• “ECMAScriptは、言語において使えるいくつかの機能の使い方を制限したいと考えているユーザがいる可能性があることを認識しています。”
• 標準のものに追加してエラー条件が定義される
• 実装中の注意
  • パース時にでるエラーと実行時エラー
  • パース時に出すエラーはパース時にstrict modeかどうかをみないといけない
  • 関数の先頭にstringリテラルが連続してる　== ディレクティブ プロローグ という
    • この範囲にuse strictが入っていればstrict modeになる
  • ディレクティブ プロローグの最後に”use strict”;を書かれた場合などは、最初のほうのパースにもstrictを適応してエラーにする
  • 関数の引数はどっち(中、外)のstrict modeなのか?
    • 中のstrict modeが適応されるので、関数内がstrict modeなら、関数名にevalとかしてる時もエラーにするようにする(disccuss)
    • body,param,functionName 全部strict modeに適応範囲とする
  • Does ‘use strict’ in a FunctionBody apply strict mode FutureReservedWord restrictions to function name or arguments?

メモ: Mou + github.css

JavaScript Testing FrameworkのBusterJSを使う via kwout

スライド : JavaScript Testing FrameworkのBusterJSを使う

今JavaScriptのテストフレームワークは色々ありますが、Buster.JSはJsTestDriverと似た仕組みを持ったテストフレームワークです。
Nodeで書かれてる所が大きく違いますが、細かい仕組み等はBuster.JS Architecture overviewという文章が公開されているのでそこを見るのがいいです。

中心となってる作者の一人はSinon.JS、Test-Driven JavaScript Developmentで有名なChristian Johansenですが、
テスト駆動JavaScriptで書かれてるようなノウハウが詰まった感じのテストフレームワークになっているので、触っていてとても楽しいツールになっている気がします。
またJsTestDriverはブラウザ向けという感じが強いですが、Buster.JSはNodeで書かれているのもあって、Nodeでテストを実行するという方法も行えるのでNodeのテストもできるようになっていると思います。

まだ、Beta 2なので実装されてない部分やWindows未対応(Windowsで試すならtry-busterjsとか)などの点もありますが、
それ以上に勢いを感じられるので今後のテストフレームワークの選択肢の一つになってくれるんじゃないかなーと思います。

WebStormでも使いやすくするために、WebStorm Integrateについてもスライドに少し書いてあります。

WebStorm指南書

発表してきた資料置いておきます。

後から資料として見やすいように画像をたくさん入れながらWebStormの機能紹介について書いたので、WebStormについて知りたい方は読むといいです。
また、最近出たばかりのWebStorm 4.0 Early Access Programについても書いてあるので興味がある人はどうぞ。

スライドの見方

スライドは上記のように機能の紹介がベースで、それの利用方法やこういう機能があって便利という感じのスライドになってます。

WebStormの楽しさ

Web開発等JavaScript周りの環境も変化してきているので、それにあわせてエディタやIDEももっと変化するといいなーと思う部分にいろいろ挑戦してる感じがしてるのがWebStormが好きな所でもあります。
とりあえず、WebStormは30-day trialなので、試してみるといいかもしれません。他のエディタ等もいろいろ競争して質が上がっていくといいなー。

横浜JSTDDハンズオンの方ではJsTestDriverを使ったハンズオンをしたのでその時のアウトラインメモ。
Twitterのまとめは 横浜JSTDDハンズオン #JSTDD つぶやきまとめ – Yukarin’Note に

TDDとは何か

• プログラマが行うホワイトボックステスト
• 開発的なアプローチ(TDD)
• ドキュメント的なアプローチ (サンプルコード

TDD

• 開発を行うためにテストを行う
• コードカバレッジは考慮しない
• 先に大きなインターフェイスを書いて設計を行う

BDD

• 振る舞いを先に定義する
• 開発を始めるときは重要だけど、開発を進めるといらない

ドキュメントアプローチ

• ドキュメントの代わりにテストを書く
• キッチンシンクと言われたりするような主要な機能についてテストを書く
• 開発当初は微妙だけど、公開するにつれて重要になる。

品質的なアプローチ

• コードカバレッジは管理していく段階で重要になる
• コードカバレッジを重視すると、ドキュメント的な役割がし難く。

結合テスト

Seleniumとかの話

JsTestDriverのアーキテクチャ

JsTestDriverの使い方

setUp

各テスト実行前に実行される

tearDown

各テストが終わる事に実行される

AsyncTestCase

引数で同期か非同期化を分けられるので、SyncTestCaseにもできる。

各テストにはqueueという引数がわたってくる 非同期テストはとても面倒

sinon.js

非同期テストを楽にするFakeテストができる

JSTestDriverのエラーになりやすい所

• serverオプションに/を付けるとエラー
• 複数人で同じサーバのJSTestDriverを使える(パブリックはやめとけ)
• ブラウザでアクティブでないタブのsetTimeoutがゆっくりになるので、それぞれウィンドウで実行するのがよい

Sinon.js

トロイの木馬の手引きをしたスパイの名前が由来

ツール

• Qute for PC/Mac
• WebStorm

書いたコードは azu/YokohamaJSTDD – GitHub に置いてあります。

• 海外のJavaScript情報を見つけよう
• 世界のJavaScript情報を読もう
• 今からRSS購読すべきタグと検索結果
• ブラウザの最新情報を知るために、Web開発者が読んでおくべきブログ
• HOW TO LEARN (これだけ記事じゃないですが)

世界のJavaScriptを読もう @ 2012を発表していた時、RSS購読フローの部分がなぜか受けが良かったようなので、簡単な補足を書いておきます。

自分はRSSリーダを多用しているので、何でもRSSにしてとりあえずRSSリーダーに流れてくるような状況を作っています。
Webサイトを見ていて、Read It Latorなどで後で読むことにしても結局読むのを忘れてしまうことがあるため、Read It Latorに登録したリストがRSSとしてRSSリーダーに流れてくるといった感じです。

Pinboardやはてなブックマークやソーシャルニュースサイト等もRSSで購読していると、同じ記事を扱ったものが何度もRSSに出てきます。
これは今からRSS購読すべきタグと検索結果でLDRの読み方にでも書いていましたが、SBMなどは量が多くなってしまうので、全て目を通そうとすると気疲れします。
そのため、SBMや検索結果等のRSSは高めのレートにして心理的に飛ばしやすい(LDRでいうSキーを押す)状態にしています。

なんで検索結果のRSSは★4にしてるかというと、検索結果RSSで出てくるサイトは★3のサイトと被ったりすることがあるので、
★4で飛ばしても★3で出てくるからまあいいっかと適当な感じで読める安心感が生まれます。

今からRSS購読すべきタグと検索結果 | Web scratch

ここから、発表してたときにウケてた部分ですが、RSSリーダで読んでいるときに少しでも気になった記事は
とりあえずTwitterへ投稿しています。(Post Now browsing to TwitterがLDRから直接投稿できるようにしているのもその辺の関係)
一応軽くは目を通してからTwitterへ投稿していますが、専門的な記事や英語の記事など一度みるだけじゃ理解が出来なかったり、判断が難しい記事も多いと思います。

そういう時にTwitterのフォロワーから反応があると理解しやすかったりします。
またFavやRTがあったものが流れてくるようにRSSを購読しておけば、重要な記事 (少なくてもフォロワーが興味を持った記事)が再度RSSとして流れてくるようになります。

こういう感じで、重要な記事は何度もRSSとして流れるようにして、読み忘れを減らしたり & 心理的に軽い気持ちでフィードを読み飛ばしても大丈夫なように意識しています。
他の人の力も借りて手を抜きつつ、人があまり見ないようなところもチェックするようにして、いろいろな情報を共有できればいいかなと思います。

どういう所などをみているかについてはオフライン勉強会でJSer.info一周年について発表してきた | JSer.infoのスライドの方にもまとめたのでそちらを見てください。

• オフライン勉強会でJSer.info一周年について発表してきた | JSer.info

「JavaScriptで大規模ゲーム開発」渋川

ソーシャルゲームの定義

• ユーザー間で非同期のやり取りが発生する

ngCore

• マルチプラットフォーム
  • 同一ソースでAndroidとiOSに対応
  • テスト環境はFlashにも対応

ゲームの構成

• ngCore上にゲームロジック/JavaScript
• サーバ/APach+FCGI上に認証とか結果の書き込みをMobageサーバに

役割分担

• ngCoreのクライアント
  • アクションシーン
  • サーバ側で作ったデータの再生
• ゲームサーバ
  • パラメーター保持、変化
  • アイテム管理
  • ミッションのスロットの目の決定など
  • ずる防止をするためサーバ側でロジックがある

ngCoreの開発サイクル

• node.jsで書かれたビルドサーバでビルドを行う。
  • ファイルの結合とか

コード

• CJSライクなモジュール
• クラスを作るsubclass関数
• ゲームはmain関数から始まる
• Core.UpdateEmitter でゲームループを回す

ゲームの基本構成

• シンプルなクラス群
  • Sceneクラスを継承してシームを作っていく
  • Sceneを遷移してゲームの遷移が行われる
• サーバ側からjsonのジョブスタックを受け取る
  • ミッション結果なども配列で返ってくる
  • 知らないジョブが来たら無視が基本方針
  • クライアントは順番に再生していくだけ
  • 新しいミッションも簡単に追加できる
• サーバエラーがおきたらホーム画面に強制的に戻る

DnLig/ngGo

• DnLib
  • ゲーム開発の共通ライブラリ
• ngGo

開発拠点

• サンフランシスコ
• 日本

• パキスタン

• SKypeチャットが主なインフラ

• git
  • git flow
• ドキュメントSphinx

ngGo/ngBuilder

• – データ駆動で行えるように
• - パラメーターチューニングのしやすさ

デバッグとテスト

• デバッグメニュー
  • サーバにデバッグ用画面がある
• Jasmineを使ってる

今後のngCore

• 3D対応、HTML5対応

まとめ

JavaScriptベースで

オフラインWebアプリケーションの作り方 (白石)

Google Gearsを使ってオフラインアプリケーションを作ったことがある。

オフラインWebアプリケーション

Google Gears

• Google Gears終了 –> HTML5へ以降を推奨
  • HTML5を中心にするようになった

オフラインでも読めるアプリの作り方

• それほど実装は難しくない
• アプリケーションキャッシュを利用すればいい

アプリケーションキャッシュとは

• 静的なリソースをキャッシュすることができる機能
• ローカルキャッシュの利点
• IE以外のブラウザでは実装されてる

キャッシュマニフェスト

• リソースのリストを作成する
• Titanium Mobileのリファレンスはローカルキャッシュされてる

アプリケーションキャッシュのJavaScript API

• window.applicationCacheにJavaScriptから操作できるアプリケーションキャッシュAPIがある。

アプリケーションキャッシュを利用する上での注意点

• キャッシュマニフェストを更新しないとリロードで反映しない
• キャッシュ容量が限られている
  • モバイルとかだと10MBぐらい

オフラインでも書けるアプリの作り方

• 割りと面倒なもの
• デスクトップアプリとやりたい事はあんまり変わらない

オフラインWebアプリを作るポイント

• 基本はリッチクライアント+同期機能

利用できるローカルストレージ

• Web Storage
• Web SQL Database
• Indexed Database API
• File API
  • ドメインごとに仮想的な空間
  • セキュリティ的なものがあるため

双方向同期

かなり難しく面倒くさい – フェールセーフ – 更新の衝突 – 同期のタイミング – ネットワーク状態、データの状態管理 – ローカルDBのスキーマ管理/サーバのスキーマと2つできてしまう – ローカルDBのクオータ(5MBぐらい)

- 容量の限界がきたときにどうするか

まとめ

• オフラインアプリケーションといっても読む/書くの2つがある
• 書く/同期的なアプリケーションはかなり面倒臭い
  • 割り切ったほうがいい

スケールするUIについて – @monjudoh

Objective-Cで非同期処理のチェーンライブラリとか

要素数

ループの中でbind/unbindしてたので大量に追加されたときに重たかったのでliveメソッドに変更 bindはここの要素に付けるから、要素が多いと死ぬ。delegateとかliveはその枠の方にイベント一個張るだけだから軽くてすむ。

D&D

• ユーザが触れる範囲だけにイベントを付ける
• D&Dは複数のイベントから成り立つので複雑(down->move-up)

要素の生成

• UITableView
  • 表示範囲+ぐらいのみを描画してる
  • 再利用してる

JavaScriptのテスト事情 – @os0x

• JavaScriptのテスト
  • まだまだ未成熟
• 二種類
  • JavaScriptのテスト
    • JavaScriptだけなので比較的わかりやすい
  • JavaScriptを含めたテスト
    • UIとかも含むインテグレーションテスト

インテグレーションテスト

• インテグレーションテストは書くのが大変
• 動いてあることが保証できるので重要
  • 後から追加修正とかも

インテグレーションテストの定番 – Selenium

• インテグレーションテストは遅い

テスト実行環境

• カピバラさん + Webkit

QUnit,Jasmine

• Jasmineの方がアプリケーションテストは向いてる

jasmine-headless-webkit

• jasmine のspecをCUI環境で実行できる

Titanium Mobile – Masui Yuichiro

• ココログ
• liblis
• AKB
• サイボウズLiveの
• MobSnap

Titanium Mobile

• JavaScriptだけでアプリを作成できる
• Titanium Mobile のモジュール売買できる
  • mobile market place

モバイルのUX

• それぞれのプラットフォームに合わせた形に変換する
• それぞれに合わせたUIはUXに
• タブバーの位置がAndroid/iPhoneで逆になったり

飯食う

• 追加モジュールとサポートのみが有料
• 認定トレーニング

感想

• ちょっと落ち着きがなかった気がするの
• あまり掘り下げた感じにはならなかったのは少しもったいない気がした。

メモ環境

• Mou

イベントのページ: Mozilla 勉強会＠東京 6th
Twitterのまとめ: Mozilla 勉強会＠東京 6th – Togetter

• 14:30 – 15:00: 開場、発表者準備

• 15:00 – 15:10: Opening

自己紹介の流れ。

• コマンドの補完

Inspector

• 次世代のセキュリティポリシー
  • XSSの攻撃防止
• コンテンツ種別で読み込み制御
  • 画像やCSSやJSなども制御できるようにする
• Webkitではほぼ開発されてる

• デフォルトセキュリティポリシーがいろいろ強化される
• CSPの使い方
  • X-Content-Security-PolicyのHTTPレスポンスヘッダを送信
  • HTMLのメタタグは書き換えできたりするものだからヘッダーで
  • Apache でCSPの設定
• CSP対応に移行する
  • JS,CSSは外部ファイルに
  • evalを使わない
  • ポリシー違反レポートでどこがおかしいのかも確認できる
    • ヘッダーでレポートを報告するURLを指定してログを残せる
  • CSPブックマークレットもある

HTTP Strict Transport Security

• Do-Not-Trackヘッダ
  • ブラウザ側でサイトに通知する
  • IE,Safariも対応
  • Chromeだけ非対応
• 受け取ったらユーザー追跡をしない

• ALT
• back to owner tab
• Fox Splitter

restartlessのコードリーディング

• アドオン SDK を利用した初めてのアドオン開発– by knagato
  
  • 初めてアドオン開発する人が対象
  • SDKを使ったアドオン開発を特徴
    • HTMLやJavaScriptなどが中心で、XULやXPCOMなどMozilla特有の機能を使わなくても開発できる
  • 開発環境の種類
    • Add-on BuilderをWeb上での開発
      • 再起動不要なのでその場で試せる
    • Addon SDKを使った開発
      • コマンドラインベース
  • Add-on SDKのチュートリアル
• Thunderbirdアドオンによるワークフロー開発について– by Nakashima
  
  • 提案するツール
    • 自分自身でのプロセス改善が可能
    • やり取りの簡略化ができる
  • http://www.p2pwf.com/ に仕様の詳細
• Forking Secure Login – by saneyuki_s
  
  • Secure Loginアドオンのフォークの話
    • 現在はメンテナンスアップデートのみになってる
    • 全面改装してる
  • 一部機能の省略
  • レガシーコードの除去
  • doorhanger対応
    • Firefoxに入ってるSSLのポップアップするやつ
• jQueryで破棄されたrequestAnimationFrameとJSでのアニメーション実装で注意すること – by kyo_ago
  
  • requestAnimationFrame
    • setIntervalの問題点としてアニメーション向けではない
  • jQuery 1.6から削除された
    • setIntervalとrequestAnimationFrameが衝突してキューがたまる
    • タブがバックグランドにあるときの挙動
• ES.next WeakMap– by mooz (@stillpedant)
  
  • WeakMap = 連想配列
  • Firefox6から利用可能
  • {}やObject()と比較して
    • keyにオブジェクトが指定可能
      • ハッシュはkeyに文字列しか指定できない(toStringされてる)
      • WeakMapはkeyにオブジェクトが指定可能
        • オブエジェクトしか指定できない
        • プリミティブ値はエラー
      • オブジェクトの外部拡張
        • DOMノードに独自プロパティは危険
        • ES5ではオブジェクトの拡張がfreezeできる
        • オブジェクト自体は拡張しないで、外部に付加情報を持つ
        • WeakMapを利用する
          • キーとして外部情報をもたせる
    • keyに指定されたオブジェクトを弱く参照
      • CGにたいして
• Firefox4以降のE4X– by teramako
  • ワイルドカード
    • *が指定子に使える
  • 属性アクセス
    • @が使える
  • Firefox3.6までは上記のものがE4X以外でも使えた
    • Firefox4以降は禁止された
    • ざんねんでしたね

翻訳許可のメールをわずか15分で返してくれた著者のJan Odvarkoさんに感謝を。
Thnak you, Jan Odvarko.

原文: Software is hard | Page load analysis using Firebug

ページ読み込みパフォーマンスはWeb開発者にとって重要なトピックです。
各ページロードの例において、FirebugのNet panelから得たデータをどのように解析するかを見ていきます。

このテストにおける例はFirefox 3.6 + Firebug 1.5 + NetExport 0.7においてのNet Panelの結果をNetExportによりHAR形式で出力したものをオンラインで表示しています。
(HAR形式はChromeのWeb Inspectorからも出力できます。)

• HTTP Archive Viewer 2.0.10(オンラインビューアー)

Example 1: Simple Page Load

ここでは2つのリクエストが表示されています。
1つめのリクエストではページは16msで取得できていて、load event (赤いライン)は58msで発生している事がわかります。ログ上にマウスオーバーさせると詳細な表示がされます。

• 青の縦線であるDOM Loaded はDOMContentLoaded event
• 赤の縦線であるPage Loaded はLoad event
• 灰色のReceiving がページの取得にかかった時間

同じように2つ目のリクエストを見てみると、5msでXHRが実行されています。
そして合計経過時間は408msであることもわかります。

2つ目のリクエスト(XHR)上でもマウスオーバーで詳細な情報が表示されています。
こちらでもload event を表していますが、こちらはXHRのリクエストからの相対値が表示されています。XHRが発生(Started)したのは403msなので 403 – 357 = 58msでload event が発生したことがわかります。(load eventはページの取得を見た方がわかりやすいからこう見る必要はない気がするけど)

Example 2: Connection Limit

各ブラウザは一つのページをダウンロードするのに同時接続制限あります。もし、同時接続の制限に達したとき、他のリソースは接続してるリソースが解放されるまでブラウザ内部のキューで待機させられます。
次の2つのページログを見ると、同時接続制限数の違いで8つの画像をロードするのにどれぐらいの違いがでるかがわかります。

#1 Cuzillion (同時接続制限 == 6)

• Firefox 3.6の同時接続制限のデフォルト値は6で、最初の6つの画像をダウンロード開始した時点でドキュメントは利用可能(DOMContentLoaded event が発生する)
• 他の2つの画像はコネクションが空くまで待っている(light-brown 色の部分がblocking部分)
• 他の2つの画像がダウンロードされたときは緑色のconnectionフェーズ無いのは、最初の6つの画像をダウンロードに使用したconnectionを再利用しているためです。

#2 Cuzillion (同時接続制限 == 2)

このテストだと、各画像ごとに2～3秒の時間がかかり、合計経過時間やload eventが発生時間に#1の2倍弱近くかかっていることがわかります。
同時接続制限が2なのはIE7以下のものやモバイル向けのブラウザなどがあります。
各ブラウザの同時接続数はHome – Browserscopeを見るといいでしょう。
Firefoxではabout:configのnetwork.http.max-persistent-connections-per-serverの設定から変更可能です。

同じように#2のポップアップされる詳細のログを見てみると、Blocking(light-brown 色)はページを取得(DOM Loaded)した時から4.63s待たされていて、リソースの取得は2.22sかかり、6.85sで完了している事がわかります。

Example 3: Pipelining

#2と同じページを使い、ブラウザのパイプライン処理がONとなっている場合を見てみる。

Firefox(3.6)でパイプライン処理が有効(network.http.pipelining == true)になっている場合を比べてみると、実際にはload eventが発生するまでにかかる時間が増えていることがわかります。
1から6の画像はそれぞれ異なる接続を利用していますが、7から8の画像は共有接続を利用してダウンロードしています。実際にどれと接続を共有しているかは明らかではありませんが(Firebugからそれを知るAPIはないため)、最後の2つの画像は接続を共有して合計時間を増加させているのは明らかです。

Example 4: Persistent Connections

このテストはHTTP Connectionヘッダーの効果を現しています。このヘッダーは既存の接続が閉じられているか将来のリクエストのために保持されているのかをサーバーに教えるために使われます。
それぞれKeep-Alive (default in HTTP/1.1) or Closeでどのような違いが出るかを見てみましょう。

それぞれのログで、最初のページと3つのリクエストとで合計4つが表示されています。
Connectionヘッダーは3つ(file1.php, file2.php, file3.php)のリクエスト時に要求されます。

#1 Test page (Connection: Keep-Alive)

• 一つ目のページのログでは、ページダウンロードのための一つの接続しか作られていないことがわかります。緑色のConnectionフェーズが一つだけになっていて接続が再利用されている事がわかります。

#2 Test page (Connection: close)

• 二つ目のログでは、ページダウンロードとfile1.phpのリクエストで接続が再利用されている事がわかります。しかし、他の接続ではConnection: closeなため、また接続を作り直す必要があります。

Example 5: Inline Scripts Block

インラインスクリプトがページのダウンロードをブロックすることはよく知られていますが、ネットワークの観点から見るとどのように見えるかを調べてしましょう。

#1 Cuzillion

3番目と4番目のリクエストの間に隙間ができています。これは5秒間のインラインスクリプトの実行によりブロッキング発生しています。 (*ここで言うインラインスクリプトとは<script>/*実行スクリプト*/</script>という感じで<script>タグ内で実行しているものを言う)
Inline Scripts Blockのページにて試すことができます。

Firefox5に試すとちょっと挙動が異なるけど、インラインスクリプトで隙間ができるのは同じ。
どちらかというとChromeがログに近い動きをしていた。
Firefox4からインラインスクリプトの実行タイミングが変わったのも関係するかもしれない。
詳細はSoftware is hard | Script Execution Analysis in Firefox 4に。

#2 Cuzillion

こちらはインラインスクリプトをページの底(</body>前かな?)に置いた場合のログです。
リクエストの合計時間は減っていますが、load eventは#1と同じくインラインスクリプトにより遅れていることがわかります。
こちらはCuzillionのようなイメージだと思います。

特にこれをどうとらえるべきかについては元記事に記述はありませんでしたが、この例はリソースのダウンロード時間よりもload eventなどへブロックが発生している事が重要な気がします。
負荷が大きいインラインスクリプトやdocument.writeなどのブロッキングを誘発するものがある場合loadやDOMContentLoadedイベントの発生を遅くしてしまいます。そのためdocument.writeそのものを避けることや、load eventなどイベントリスナーにして実行させるなどした方がページの表示は速くなるかと思います。

Example 6: Redirects

これはネットパネルにて、リダイレクトがどのように見えるかを表示した例。

#1 Final Page (one redirect)

サーバーによって301リダイレクトが行われて、URLの末尾に/がついたことがわかります。

#2 Final Page (infinite redirection)

無限ループしているリダイレクトの例
自分自身にリダイレクトしているのでいつまでもループしてしまいますが、Firefoxではデフォルトで20回で停止しています(network.http.redirection-limit の設定値)

document.getElementById("ASIN").value

Amazonはページ中のhiddenなinput要素にASINを持たせてるのでこういう手が取れる。

<input id="ASIN" type="hidden" value="4253196519" name="ASIN">

ページの構造が変わったらダメだけど、結構昔からこの部分は変わってないので意外と安定しているかもしれない。
amazon.comだと構造が違うものがあって、Amazon.com: Buried Prey eBook: John Sandford: Kindle StoreのようにKindle Storeだとページ構造が違ってID=ASINがない代わりに次のようなものがある。

<input type="hidden" value="B004LRPGPC" name="ASIN.0">

var ASIN = document.getElementById("ASIN") || document.getElementsByName("ASIN.0")[0];

もう一つの方法はwindowオブジェクトのプロパティから取得する方法

(2011年6月5日現在だと)

window.sitbAsin;

• Amazonの商品個別ページでASINを抜き出す – おれ ここ めも かきなぐる おまえ ここ よむ なぐる – subtech

最後はURLからASIN部分を切り出す方法

URLにはASINが入ってるはずなので、ページに構造の変化には強いけど、少しパースが面倒なところがある。
どのようなURLがあるかを把握する必要があるので、条件分けなども必要になる。
まあASINのフォーマットは\w{10}と決まっているので、ある程度安定するのかもしれない。

ついでに、replaceStateを使ってリロードなしでAmazonのURLを/dp/ASINだけの短いURLにするGreasemonkey書いた。

• Amazon URL Cleaner for Greasemonkey

有名な企業やライブラリはコーディングルールも公開している事が多いので適当にまとめてみました

JavaScript style guide – MDC Docs

Mozilla/Firefox向けのものなので、一部ECMAScriptの範囲を超えたものも含まれています。
多くの人が見ていると思うので、見たことない人は一度読んでみるといいです。

Google JavaScript Style Guide

Google JavaScript Style Guide 和訳 — Google JavaScript Style Guide 和訳(日本語版)
Googleのコーディングルールですが、ルールを並べるだけではなくなぜ悪いのかについても触れているので、一読をお勧めします。
Closure Linterというチェックツールもあるため、採用しやすいかもしれない。

JQuery Core Style Guidelines – jQuery JavaScript Library

jQuery Coreのもの。
Typeチェックの仕方についても触れている。

Dojo Style Guide – The Dojo Toolkit

Dojoのコーディングルール。
コード例が豊富で、命名規則やホワイトスペースの扱いなど細かいところまで入ってる。

Felix’s Node.js Style Guide

Felix’s Node.js Style Guide(和訳)(日本語版)
Node.jsにおけるコーディングルール。(公式なものではない。no official document)
Node.jsに限らず、クライアントサイドJavaScriptに置いても参考になる部分は多い。

Code Conventions for the JavaScript Programming Language

Douglas Crockfordによるもの。
コーディングルールというよりは慣習的なもの。
同作者によるJSLintも併用しましょう。(JSLint or JSHintは他のコーディングルールであっても採用してよいもの)

Code Guidelines for Rich Internet Application Development

コーディングルールではなくてガイドライン的なものです、HTMLやCSS、JavaScriptについてのガイドラインを書かれている。

Introduction to Apple JavaScript Coding Guidelines

JavaScript Coding Guidelines for Mac OS X(日本語版)
Appleによるコーディングのガイドライン。
“JavaScriptのベストプラクティス”でコーディングで気をつける事について触れている。

The WebKit Open Source Project – WebKit Coding Style Guidelines

JavaScriptではありませんが、Webkitにおけるコーディングルール。
ホワイトスペースやLine breakingの所はJavaScriptの場合でも参考になる。
uupaaさんがこれをベースに一部分を変更した感じで使ってるそうです。

• CodingStyle – uupaa-js – JavaScript Coding Style Guide – JavaScript Library for Casual Creator – Google Project Hosting

サイボウズで学んだこと – IT戦記

amachangによるもの。
大規模 JavaScript 開発におけるルールや命名規則、デバッグ、パフォーマンスについて触れています。
コーディングルールを整えてどのように実践したかについて参考になります。

JavaScriptパターン (オライリー本)

JavaScriptパターン ―優れたアプリケーションのための作法

posted with AZlink at 2011.5.27

Stoyan Stefanov,豊福 剛
オライリージャパン
売り上げランキング: 8213

Amazon.co.jp で詳細を見る

この書籍のChapter 2. Essentialsにおいて、JavaScriptのコーディングルールが紹介されています。
また避けるべき事やどう書くべきなのかについてもかなり深く書かれています。

コーディングルールは”どう書けばいいのか分からない”という人向けのものではないと思います。どう書いたらいいのか分からない人は、まずなぜそのように書いたらダメなのかを知るのがよいと思います。
そのため、書き方に不安を持ってる人はなぜダメなのかについても触れているGoogle JavaScript Style Guide 和訳を読むのがよいと思います。(読みやすい日本語版もあるしね)
コーディングルールはコードに一貫性を持つためにあると思います。頻繁にルールを変える必要はないと思いますが、必ずしもそのルールが、その時の(実行環境|JavaScript)において最適な書き方ではない場合もあります。そういうときはルールの更新をしましょう。

おまけ

自分の場合はWebStormの自動整形に任せている(といっても膨大なルール設定があるため、上記で紹介したコーディングルールを自動化できる)ので、基本的にはIDE任せという書き方にしています。
セミコロン忘れなどについてはcomplete current statement機能( [WebStorm]Complete Current Statementがとても便利な件(・∀・))を使ったり、WebStormのシンタックスチェックはかなり優秀なのでエラーも書いてる途中で発見しやすいです。(シンタックスチェックも細かく制御できる)
そのため、やっぱり道具任せといった感じではありますが、WebStormを使用していない場合も同じコードが書けるようにある程度のルールは持っています。
Google JavaScript Style Guide + WebKit Coding Style Guidelines に近いですが、ホワイトスペースなど見た目的なちょっとした違いにはそこまで厳しくしない感じで書いています。
if, for, while, doなどの{}は省略しない(WebStormの自動整形で中括弧を強制的につける)、誰が見てもある程度読める感じにする、ブレークポイントを打ちやすい空間を作るように配慮するなどなどで、他のコーディングルールに書いてある事と同じようなものだと思います。