簡単にやり方を書くと、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

Shibuya.XSS

• Shibuya.XSSまとめ – Togetter

DOM Based XSSの傾向と対策 – mala

Shibuya.XSSで発表してきました – 金利0無利息キャッシング – キャッシングできます – subtech

機械的なスキャンで見つけづらいXSS

• location.hash経由で発火が多い、
• サーバ側にアクセスログが残りづらい
• ビーコンでlocation.hashを記録する事も可能だけど、実行順序で潰される事がある

location.hashでの問題

• XHR2

どんな時に見つけにくい

• パラメーターをパースして利用してる場合
• ソースを読まないと見つけにくい。
• 難読化されてるとしんどい
• レガシーコード

どうするのがいいのだろうか

• バリデーション?

バリデーションが必要な状況

• openにファイル名渡す -> パイプでコマンド実行可能
• ファイル開く関数とコマンド実行を分けて使うべき
• 役割に応じて「それだけを行うように」する

バリデーションが必要なライブラリ

• 直接使うときは安全に倒す

そもそも安全にすることを考える

• 外部リソース読み込めないようには無理

コーディング規約での対処

• jQueryの場合
• セレクタの使い方を徹底する
• findを使って$関数の直接使用を避ける
• $関数は汎用的すぎ

コーディング

• XHRのリクエストは必ず絶対パス+動的パス
• 絶対パスが/のみだと突破できる
• /api/的な感じに

問題点

• HTML5等で今まで安全だったかもしれないものが崩壊して、可能な攻撃が増える

DOM XSS撲滅装置

• location.hashにタグが会った場合は消す等
• その文字列を使わないことが保証されてるなら割りと効果的
• 広告やブログパーツ等、自分で治せないもの等の緊急的
• 潜在的なXSS

パスワードを盗めるか?

• ブラウザのパスワード自動入力機能でパスワードを盗める場合がある
• セッション乗っ取り + パスワード盗み

パスワードの盗み方

• 自動でフィルインされた値を読み取る
• 自動的に盗むことが可能
• 自動フィルイン + クリックジャッキング -> 半自動
• フォームの宛先を攻撃サイトに誘導

事例

?to=javascript:eval(location.hash)#攻撃コード

• ログイン後のリダイレクトのURL先でjavascript:を実行可能

対策

• そのパスワードを入力するドメインをサブドメインで独立させる
  • ログイン機能だけを持ったサブドメインを作成する
  • 他のjsを入れない、厳しめのルール

フェールセーフ設計

• サンドボックス
• パスワードを入力するページは外部jsを完全排除するとか
• パスワード入力ページはそれ専用のサブドメインへ

ブラウザ側のリスク軽減

• XSSフィルタ
• パスワードの自動フィルイン対策
• 元々危険だったものが更に危険になる => 理解されないことが多い

攻撃パターン

1. iframeで埋め込む -> サードパーティクッキー有効なら発動
2. 短縮URL + replaceStateでURL偽装
3. ポップアップWIndowとサードパーティ

ユーザー側の対策

• NoScript
• 複雑なルールを設定しないと安全に利用できない
• 攻撃者が嫌う設定を使う
  • サードパーティクッキーオフ、ポップアップのブロク、リダイレクトの防止
• 初見のURLは全部シークレットモードで開くとか

まとめ

• DOM Based XSSはたくさんある
• XSSがあっても安全にすることを考える

焼肉、刺身

• XSS発見者には肉か刺身をおごる慣例(*人徳が必要)

x-autocompletetypeの実験 by はまちちゃんさん

• x-autocompletetypeのデモ
• http://hamachiya.com/junk/x-autocompletetype.php

サニタイズ言うぞキャンペーン – TAKESAKO

mixiの新着検索ページでXSSで1件

• いぬぼくxSS

7年前と少し違う状況

• jQuery
• XHR2

サニタイズ的なものが必要になる場合がある。

kintone

• ライブラリ除いて10万行ぐらい

社内勉強会

• jQueryは甘え

Closure Templateのエスケープ機能について

• サニタイズコンテント
• JavaScriptでHTMLのパーサー的に書かれてる
• 問題を起こしそうな文字列などが定義されてる

Closure Template – Contextual Autoscape

• JavaScriptエスケープとHTMLエスケープ等の区別をおこなってくれる
• CSS、属性値等で異なるエスケープを行う
• 無毒化とかを文脈依存で対処される
• http://d.hatena.ne.jp/teppeis/20120318/1332092081

オフレコ – 春山

• ベンチャーから始めると、フローの把握ができてない所が存在する
• そのフローの把握が重要

JS Array Hijacking with MBCS – hasegawa

Shibuya.XSS テクニカルトーク#1 開催しました。 – 葉っぱ日記

• Array形式のJSONをジャックする
• Firefox 修正済み
• UTF-8をShift-JISで解釈すると壊れた解釈をしてしまう問題

Mozillaはポテンシャル的な脅威にも対処してくれる

• Content-Typeとcharset をちゃんとつける

LT

mixi scrap Challenge

• 学生向けのセキュリティイベント
• 用意したmixiクローンサイトに攻撃してもらって脆弱性を見つけてもらう

イベント用に使ったサイト

• イベント用のmixiサイトをクローンしてXSSを探してもらう
• 日記ページにあるXSSを探して、スタッフアカウントに対して攻撃URLを送ってもらう
  • 得点方式

問題

• ネギ男に、イラクとnicknameがalertされるURLを踏ませて下さい
• ネギ男に….

みたいな問題形式

実際のサービスのクローンを舞台にして

• 盛り上がった
• より実践的な体験をしてもらえた
  • XSSをみつけるだけではなくSNSの使用を考慮して実践的な内容になった
  • 問題をつくやすかった
  • git-grep “XSS” revertで過去に対応してXSS問題から引き出す

AjaxアプリケーションのXSS対応入門 – 徳丸

• 入門書にもAjax的な問題
• X-Content-Type-Options: nosniff

JSONハイジャック

• JSONを罠サイトからスクリプト要素を呼び出す
• 通常はただのデータなので、読み取りはできないはず…
• JSONハイジャックで読み取りができてしまう => 既にブラウザは対策済み
• Androidだとまだ発生する(4.0.3だと問題ない)

対策

• ヘッダチェックが無難
• あんまりいい方法がない
• 外部APIは基本的に信用しない

CSS HTML Attribute Reader – kyo_ago

The Sexy Assassinで紹介されてるCSS HTML Attribute Readerがどこまで危険か検証してみた http://bit.ly/HU74ad

• CSS Attributeでパスワードの取得 -moz-anyと合わせ技
• 外部からCSS書けるということ自体が問題
• :visited の履歴取得も最近のブラウザは対策されてる

ロングIPアドレス

• ドット無しでドメインを書くことができる
• ドットを無効化しても、数字だけでドメインを書く事ができるので問題が起こる場合があるかも

セキュリティ小ネタ – send

http://d.hatena.ne.jp/send/20120405/p1

rootkit

• rootやadminが使えなくなってた
• 対策
  • 別の所からpsやkill等のバイナリを持ってきてきて殺してた
• chattrされてた
  • 細かい改ざんをやっていた
• 対策として改ざん検知などの導入で数ヶ月使った

よく狙われる脆弱性

JSだとimg onerror

• src属性指定後すぐ発火してしまう
• ドキュメントに追加しなくても発火してしまってる(高速)
• onerrorは除去しにくいので対策しにくい

余談

• 最初にサブドメイン以下にtest. やadmin.とかを見る
• crossdomein.xml

パスワード入力はやっぱり別ドメインに分けるべき

DOS

くよくよくよくよ

• セキュリティを使うと守ると考えるは違う

メモ : 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 に置いてあります。

Mozilla Vision 2012 Conference Dayに参加してきたので、その時のメモです。(いつも通り正確性は保証されません)

Boot to Gecko

B2G = Boot to Gecko

なぜ必要なのか

モバイルは閉鎖的すぎる

過去を振りかえる

• 2002年 ブラウザの場合

IE のみだったので、拡張性はなかった。 拡張する必要がなかった

やがて複数のブラウザが登場して競争するようになった。 ブラウザ間で実装の競争が起こると

• UXが良くなる
• ユーザーはハッピーになる
• 標準化も良くなっていく -> 書き手もハッピー

ブラウザとモバイル

モバイルプラットフォームは閉鎖的で、プラットフォーム側がコントールできるようにしている。

様々なプラットフォームに対応しようとするとそのプラットフォームに対応しないといけない -> 時間の無駄になってる。

プラットフォームを移行するとデータが移行できない。 このようなsilosがあるとオープンではない

これを変えるためにB2Gを作っていく。

Webプラットフォームができる事

オープンなものにするために必要なもの

• オープンなApp Marketsが必要
• プラットフォーム間を移行する際にデータも移行できる Firefox Syncのデバイスを超えた同期システム。
• BrowserID

ネイティブアプリだと使えるケドWebからは使えないモバイルの機能があるのはWebのバグなども

Boo2Gecko

B2Gに必要なもの

• iOS負けないUX
• オープンスタンダートを構築する。B2G以外でも同じAPIが利用できる
• Apps。Web自体がapp storeみたいなもの

デモ

• ロックスクリーン、ホーム画面もWebアプリとして実装されている
• 60FPS出るようにしている

電話ができるようにWeb APIとしてDevice APIを実装してある。 ネイティブコードではなくてWebの技術で実装されている。

ホーム画面もHTMLベースなので、ソースコードが見られる

• Quake 3を使ったアプリ
  • WebGLのエンジン

クラッシュしたけど、直ぐ立ち上がる。

B2Gの実装

iOSなどのネイティブAPIの代わりに、Webエンジン/標準化されたDevice APIsがあり、ネイティブUIの代わりにWebベースのUIが存在する。

すべて再開発するわけではなく、Webレイヤー以外の部分は既存のものをサイっ利用したりする。

Gonk ( Androidのものも再利用) WebランタイムにMozillaは集中開発して、GPSなど他の部分に関してはAndroidのコードを利用する。

B2Gは何がしたい

• モバイルをオープンにしたい
• プランや開発やソースコードもオープンにしている
• 作成したAPIを標準化したい
• オープンなエコシステムを作成したい
• Boot2Webkit など他の実装も作れるようにしたい
• B2Gで動くものはB2Wでうごくようになるべき

一からはじめたプロジェクトではない。 Androidのコミュニティ

Q&A

Q どのようにして標準化していくのか。 それぞれの実装に対してそれぞれのUIがあるから、ポートする作業していく必要がでていく。 Gaiaに対してのUIのガイドラインが必要

A 標準化していくのはシステムのテーマ

Q non-nativeなものを場合、ゲーム等最大限の性能出すためにネイティブAPIを開発するの?

A ネイティブAPIを実装するつもりはない。 WebGLがOpenGLが遅ければそれはWebのバグである。 クロスプラットフォームを常に担保していくという目的を持っているので、少し遠回りでもWeb APIをやっていく。

Q アプリが落ちたときに他のシステムを巻き込むの?

A プライオリティの高いものを別のプロセスを走らせる事もできる。 OSがとても軽量なので、全てがダウンしても直ぐに起動できる。

電話のプロセスは別のものとして動いてるのでOSがダウンしても生きてる。 プロセスのセパレーションと呼ばれるものが実装できてる。

Linuxカーネルがあってその上にいくつかのXULや電話やBTなどのプロセスなどを起動していく。そして最後にB2Gのプロセスが起動して、その中でWeb Appが起動する。

Chromelessのようなイメージで、全てがiframeのようなものになって、iframeにマニフェストを与えて、iframeを別プロセスで動作させることができる。

Q どのようにB2Gを提供していくか? Mozillaがサポートするの?

A Mozillaは直接デバイスを出荷することはなく、 Mozilla Phoneパートナーと一緒してやっていく。 メジャーなキャリアとはやり取りを始めていて、最終的にそのキャリアが出していくことになる。

Q デバイスを買ってきて、OSとしてB2Gを後入れるということはできるの?

A 今サムソンのデバイスを使ってるが勝手に入れてる。 なので、将来的にはより多くのデバイスをサポートして行って、そのような事が可能になる

Web 標準の今、そして未来

Tantek Çelik

スライド : Open Standards Stories & Practices

CSSの標準化に参加したことについてのお話

• ISO

買った上で誰でも見ることができる => 昔のオープン

• CalConnect

お金を払った上にテストに参加できる。 テストスイートなのに、対象が限定されている。

W3Cはだれても見られるオープン

• W3C tests

CSS WGはレポートを公開していたので誰でも見ることができた。 CalcConnectは公開してはいけないという縛りがあった

オープンなテストは再現性が担保されている

まだCSS WG不満があった

更にテスト、レポートをオープンにしていく必要がある。

• Blog
• Wiki

CSS WGのWikiを作成した。まだ閉ざされていた部分があったが、IRCやバグトラッカーなども公開していくようにした。

当時にメーリングリストはあったが、W3Cのメンバーでないとみられないようになっていたが、テクニカルな内容のものは全てPublicにしていくようにした。

• editor ‘s drafts

これもエディターが書いてる途中のものも公開していくようにした。

• last call

2011になってCSS2.1がやっとRCになった。9年もかかった。

CSS3の確固たる基盤になるCSS2.1ができた。

学んだ事

オープンは進化する

2. XFN

• 2003年

SXSWという会議に参加した時の話。

ブログロールの仕組みについての会議で、ものすごく複雑な仕様になっていた。

rel=”friend”がついてればいいぐらいな簡単なものを提案した。

実際にどういう状態がfriendなのかについて調査した。

CC

XFNは初めてのCCライセンスを使ったオープンな標準化となった。 そこからフィードバックをもらってXFN1.1をリリースした。

rel=me

一番大きな6文字。自分を示すrel属性で、多くのSNSなどで使用されている。

rel=me , OAuth

２つを組み合わせることで、OpenIDをよりシンプルなものを実現できるでは?

XFNから学んだものは単純でシンプルであるべきということ

3. MicroFormat

• rel=license

この時初めてMicroFormatという事が使われた

その頃はまだ標準に関するWikiがなかったので、Wikiで公開した。= 初めてのWikiで公開され知多Web標準

人を表現するhtml

classnameでつけていた習慣など、定義されていた言葉を元に定義した。

hcard , hcalendar

既にある用語を元に作成した標準。 既存のフォーマットを使用したので馴染みやすい。

Webレビューのフォーマット

いろいろ研究した

80/20の法則 : 比較などのある程度のフォーマットの表現が見えてきた

• hreview

hreviewという標準化した

microformats.org

これまでの標準化団体とは少し異なる。

• プロセスそのものを文章化
• 今までの教訓を掲載した
• IRCもオープンに
• パブリックなログを公開

wikiがemail以上の公式な文章であるとした。 -> Wikiが厳格であるようにした

• IRCに変更をとばすbot
• スパムの除去

Wikiのイイ点としては同時に翻訳が行えるようになった。 今も標準化作業中に17ヶ国に翻訳作業がされている。

どんどんフィードバックを送る。標準化は誰でも参加ができる環境に翻訳は重要

Wikiは誰でも参加できる。W3Cは組織としての参加が必要になってる。

全てPublic domain / CC0にすることで全てがオープンであることを体現する。

microformats2

更にシンプルになるMicroformat。 ユーザーはシンプルなしようが求められる。

4. HTML5

• 2004年

W3Cのワークショップが始まり。

HTM + CSS + DOM VS XHTML2 +XForms +etc..

これまでを進化させていく方向　VS W3CのXML

incremental VS replace

進化させていくと置き換えていくの対決

HTML VS XML は8:11でHTMLは負けた

ベンダーはHTMlの方を支持していた。MS,Apple,Mozilla等

Web自体は進化しないと行けない

WHATWGが設立

ここでHTMLは進化していった。

Web Apllication specがHTMl5になっていった。

Core+new APIsという構成はCSSも同じ

WHATWGはMITライセンスをしようした!!! これまであるライセンスを再利用した

W3Cは独自のライセンス – フォークが許されないライセンス

W3CとWHATWGの共通点

• 要素

エディタを信頼する VS WG全体で協議する

というような対立が生まれてた。

5. W3C CGs (コミュニティグループ)

• 2011年

2011にW3Cコミュニティグループができた

あるテーマに関するコミュニティグループは4人いればできる

CC0 & OWFa の仕様

Mozillaの弁護士にそれぞれ調べて持ったが、どちらもいい感じだった。 オープンに使えるライセンス。

仕様作成の10個のベストプラクティス

1. オープンに作る(標準をオープンに作っていく)
2. オープンに反復を行う(完璧じゃなくてもいいから試行錯誤を出す)
3. オープンWikiを使う
4. オープンに討議をする
5. ブログ、Tweet、あらゆる手を使ってオープンに
6. オープンなアーカイブ&ログ
7. Wiki編集はIRCに投げる
8. オープンテストスイート(堅牢、反復的に
9. テストレポートをオープンにする
10. 可能な限りコミュニティを巻き込む( 多くの人を巻き込む)

境界を超えた範囲で巻き込んだ作業をする。標準はグローバル

Q&A

Q MicroFormats以外に草の根的なものはありますか?

A OAuthはメーリングリストだけでできてきた

Q ベストプラクティスはWeb以外に対しても適応できる?

A 他にも適応できるだろう.

Facebookがオープンプラットフォームということをやろうとしている

Q W3Cのノンフォークライセンスだということだけど、コミュニティができてフォークが行われてる。W3Cが変わってきてるの?

A 今は２つの方向ができてきてる。 HTML5はまだノンフォークなライセンスになってる。

将来的には切り替わるかもしれない。

pdf.js — HTML5 と JavaScript の限界に挑戦する

なぜpdf.jsが必要なのか

信頼されたネイティブコードは脆弱性があると問題になる。

pdfに何が必要なのか

portableなのに巨大なフォーマット

• Adobeのみが実装してるサブセットがある
• pdfの一部サブセットを実装することを目的にした

圧縮されたpdfを戻して、パースしてdrawTextみたい形にしてレンダリングする。

Document -> ページとオブジェクトがある。

HTML/CSS/JS

• JavaScriptはTyped Arrayなどを使用して高速化
• Fast 2D Canvas、GPUで加速的
• CSS @fant-face フォントに対応、ダイナミックにフォントをロードする機能
• data: URI バイナリデータをJavaScript上で作れる

SVGなどを使わなかった理由もある。 = スピード

pdf.jsの手順

ダウンロード

バイナリデータをXHRでresponseTYpe = “arraybuffer”でダウンロードできる。

デコード、解読、パース

• PNG,LZWデコーダーをJavaScriptで書いた
• パーサーもJavaScriptで書いた

レンダリング

パースしたものをレンダリングしていくのが大変

• 2D CanvasでLineやarcsなどを描いていく
• bitmapもimgで描画する

問題

• 2DCanvasは十分ではなかった。
• Dash line等Canvasには実装されてなかった。 even odd ruleなどもそう

解決方法として2DCanvas自体を拡張していく

bitmap画像のデコードをサポートしてなかった。

• img と Canvasはjpeg2000
• フォーマットを追加するのは大変
• JavaScriptでデコーダーを書く

フォントの問題

• OpenType , TrueTypesなどブラウザはサポートしてないTypeがあった
• Type1は一番PDFで使わてるのにCSS Font faceでサポートされてない

解決方法としてOpenTypeに変換して、中間フォーマット的にType1をサポートした。

まだまだやることはいろいろ

• Shading fillはCSS gradientsで実装されてる
• Image Mask はCanvasがネイティブでできる
• PostScriptオブジェクト – PostScriptのインタープリタをJSで
• TYpe3フォント PDF.js自体でレンダリングを行ってる

pdfをWeb技術でレンダリングする事に成功した。

デモ

• Web技術で実装するとモバイルでも動かせる
• フルのPDFレンダラーがブラウザ上で走っている

PDFビューアーのUI

UIを作っていく

• ページビュー(サイドでページをプレビューする)
• ハイパーリンクのサポート
• テキストの選択 – 難しい
• テキストの検索 – 難しい

ハイパーリンクの実装

2種類のリンク方式がある

• 相互参照
• 外部リング

Webブラウザが認識できるaリンクに変換した。 そのオブジェクトをpdf.jsでレンダリングした上にaリンクを重ねたものを表示して扱うようにした。

相互参照はポイントへ飛ぶようにしていて、バックボタンが機能するようになっている。

テキストの選択

Canvasは画素が並んでいるだけなので選べないが、オーバーレイに透過性を持ったdivタグでテキストを描画している。

アクセシビリティもサポートできている。

pdf.jsの高速化

コンパイル

pdf.jsはPDFのサブセットをレンタリング

• PDFレンダラーはインタープリタだった
• PDFレンダラーのJITコンパイルする switch等をコンパイルしたら省略できるので、直接draw*を呼べるようにできて十数倍の動作速度が得られる。
• Overview of pdf.js guts < Chris Pitchin’ Hey

ダイナミックなコンパイレーションを行なってFunction()で実行してる。

Web Workers

Web Workersを使って別のスレッドで、デコード、パース、フォント変換、デコードイメージを行う。

• main threadではdrawを行なっていく。(これはUIブロックを生む)
• 別スレッドで実行してるものはUIブロックの影響されない
• 同時併用でタスクを実行できるので高速化

pdf.jsの現状

• 大部分の機能は完成している
• Firefox,Chromeの拡張して利用できる

* HTML/JS/CSS Can redner PDFs *

next

• PDF内のテキストを検索
• HTTP byte-rangeリクエストを使ってPDFを分割ロード。メモリの削減になる
• Web Worker内でCanvasをサポート。UIブロックを潰せる
• (maybe) WebGLで高速レンダリング？？？ GPUをもっと使える

質問

Q なぜCanvasを使用したのか?

A JavaScriptが直接やり取りできる。SVGはDOMを経由しないといけないため、より早くするには難しい。

PDFではPDFファイルがあるのだからDOMを作成してやるのは不要だ。

Q 政府などでフォームとしてPDFを利用する場合。インタラクティブなPDFな方向はするのか?

A ２つのフォームフォーマットがある

• Acro format – 標準化されてる
• XNA format – プロレタリア

PDF.jsでも実装しやすい部類のもの。 AdobeではSpiderMonkeyベースのエンジンが使わていて、Validationが行われていたりする。

pdf.jsは100%のpdfのサポートするわけではないので、フォームなどのやり取りをべーすとするならばHTMLベースのほうがよいものになるかもしれない。

Q セキュリティポリシーについて

A pdf.jsの用途について

A メールクライアントなどの場合 HTMLのセキュリティポリシーに寄っていく(クロスドメインの問題がでるかもしれない)

Q テキストの描画方法

A PDFは左から右へ書けというようなコマンドが存在する。 まだ、サポートしてないが、Canvasの機能を一部利用かもしれない。

Q Canvasにテキスト選択を追加しなかった理由?

A Canvasにそれが実装されなかったのはとても管理が大変だったから。パフォーマンスとテキスト選択のトレードオフの結果

Q 対応するブラウザについて

A pdf.jsはオープンWeb標準を使って作っていくという方向から始まった。だが、ブラウザにはまだ実装されていない機能があって、その部分が拡張実装として、Firefox や Webkitに実装されていった。

dot line と even fill あたりが互換性ブラウザの問題を生んでる。 => スタンダートを追加していく

重要なのはTyped Arrayのサポートが大事で高速に動作するにはこれが必須。# LT

LT

“実践”Emscripten

• Alon zakai
  • EmScriptenの作者
• C, C++をLLVMでJavaScriptへ変換する
  • バイトコードになってそれをエミュレート
• 手作業よりも少し遅いぐらい
• まとめ
  • 2-4倍ぐらい遅くなる
  • 変換作業が短くすむ
• JSViz
  • GraphVizを変換
  • アニメーション機能付き
  • グラフを考えるようにするのを視覚化

ブラウザプレゼンテーションの教育的利用

• Nurota Lab.
• 教師と生徒とのやり取りが必要になる。
  • 臨機応変に内容を変えられるようにする
  • 黒板以上のことをできるようにする
• インタラクティブにコードを実行しながら事業を進行できる
• Webページを埋め込むとかWeb技術を使える
• 数学とか物理とか利用方法がある

Firefox Syncサーバを建てて見た

• Firefox Sync
  • 保存情報をアドオンを同期する機能
  • Androidとも同期できる
• Mozillaのサーバに情報が転送される
  • ローカで暗号化されてから送信している
• Syncサーバを自前で建てて利用する
  • 証明書を用意してHTTPSでやり取りできる
• Python, SQLite、Macurialで動く
  • ビルドして、コマンドだけ動く
• いろいろ調整しないと動かないけど

Firefox 布教大作戦

• Firefox を 灘高校 に広める
  • IE 83%のシェアな高校
• Firefoxノートを1300部発注
  • 教員に止められた
• 「布教」は簡単ではない

Firefoxのゴキゲンな通知UI

• Popup Notifications
  • doorhangerがコードネーム
• ノンブロッキングな通知UI
• PopupNotification.show()
  • 6つの引数で設定
• 通知の複数表示ができないバグ
• ドキュメントが充実してない
  • コードはドキュメントになってる
• まとめ

ドアハンガーをもっと簡単につかいたい! – Piro

• PopupNotication.jsmの罠
  • CSSでアイコンの表示
  • コードバックをたくさん指定しないといけない
• 簡単に扱えるライブラリを書いた

海外の開発コミュニティをを利用して世界デビューをしよう

• Linuxに企業として参加
  • コミニティに参加していくには
• ユーザーもどんどん参加する
• 英語のレベルはあまりきにしない
• 批判されても落ち込まない
• 思いついたらすぐ投稿(反応を早く)
• オープンにディスカッションをする
• キーとなる人を早く見つける
• まずは感謝

才能のソーシャルメディア

• Stylelist DirectoryというSNSサービス
  • 才能のソーシャルメディア
  • 美容師のソーシャルメディア
• 欧米だと美容師は芸術家的に個人活動
  • 日本だとサロン
• 美容師が才能を発揮できるようなサイト
  • 活躍のアピール
  • 一般の人たちもそれらに反応
• Joomla の CMSを使って運営してる
  • 他の業界とのコラボレーションとかやっていきたい

Scratchでつなぐオープンな学び

• Openな学び
• Scratch
  • 8 – 12歳向けのMITが開発してるソフト
  • 80万人ぐらいアクティブユーザー
• デモ

Interop Tokyoでのオープンなネットワークエンジニア育成

• Interop
  • ネットワークの国内最大のイベント
  • いろんな会社の機器を使ってネットワークを構築する
  • 超ネット
• ShowNet
  • STMプログラム
  • インターネット技術者を育てる

まとめ

Web 標準の今、そして未来 by Tantek Çelik がとても面白かった。仕様を作っている側からの視点の話は結構貴重な貴重な気がした。

Mozilla飯よかった。

メモツール(セッションごとに別々のファイルで保存)

• Qute for PC/Mac
• Mou

• 海外の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

iOSアプリケーションのUnit Test – 岸川

テストを習慣化するには

なぜテストを書かないか

• テストの効果がわかりにくい
• iPhoneアプリのテストってどう書けばいいのかワカラナイ
• デバイス固有のデータを利用していたりする

ツール/フレームワークを使う

• 繰り返し実行するのが簡単
• 自動化できる
• テスト結果が見えてくるようになる

無理をしない

• モデルのテストは書きやすい
• 論理構造はそう簡単に変わらないはず
• 繰り返し実行するメリットがあるので(正常系/例外/異常/境界値)をちゃんとテストする

表示は論理構造が簡単にひっくり返る事があるので、テストを無理に書こうとしない

テストしやすいコードを書く努力はする

• テストしやすいコードは、使い易いコードなので良い設計にも繋がる
• メソッドをきちんと分けてあげる

単体テストをワークフローに取り入れる

• OCUnit
• GHUnit

OCUnit

• XCode標準
• XCodeと統合されてるが、アサーションが貧弱
• 非同期テストがサポートされてない

GHUnit

• XCode非標準
• アサーションが豊富
• まともなテストができる(teardown/setup)
• 非同期テストのサポート(waitを使える)
• OCUnitのテストケースも実行可能
• viewのテスト機能が追加された

Viewのテスト

GHVerifyView あらかじめ取っておいた画面の画像と照らしあわせてテストしてくれる 画像での比較

Flashからcocos2dに移植した話 – CAつりポンチーム

• Flashとcocos2dに移植した

• 1万７千件のレビュー

• 平均4.5☆

• Twitterによる拡散

• 完全無料広告なし
• アメーバピグ
• ストレスフリー
• App Storeのレビュー誘導

オフライン対応

非会員対応

• ほぼすべての機能を非会員でも遊べる
• 会員と非会員の差別化
• タイトル画面の対応のみ
• ポイントの管理をローカルにおいて、サーバ側からポイント管理を排除

iPod Touchのユーザーが30% => オフライン対応の成果?

cocos2dとFlash

大量の画像を書きだす

• 手動は日が暮れるので
• アクションを作って、画像ファイル名=レイヤー名にしてバッチで生成

texturepacker を知る

• 一枚の画像に素材を貼り付けて、座標データからファイルを切り出して表示する
• CSS スプライトみたいな

AutoSD

自動でRetinaと通常の解像度を作成できる

Spriteはフォルダ管理

Finder上でフォルダ構造そのままにSPriteを管理できて楽 texturepacker上に反映する

見ていて飽きないガチャを作れという司令

まずはFlashで動きを作る

1. 色を選ぶ
2. ガチャを出すアニメーション

自作AIRツールで座標の抽出

swfから座標の抽出をするソフトを作成した

• 座標系の違いを補正する スクリーン座標 -> デカルト座標
• Flash上のレイアウトがそのままcocos2dに移植

cocos2dを利王した最適化と高速化

• 描画処理の高速化
• テクスチャロードの非同期化

iPhoneのOpenGLの傾向と対策

• OpenGLの描画を呼び出すほどオーバーヘッドが大きなリ重くなる傾向
• なので、texturepackerを使ってテクスチャを一回でロードしたりして 呼び出し回数を減らした。

テクスチャロードの非同期化

• 非同期で先にテクスチャを読み込んで、読み込み待ちを減少させる
• addImageAsyncを使って非同期ロード

テクスチャフォーマットの調整

• RGBA4444に統一してる(32bit -> 16bit)

モーション制御の最適化

CCPawnやCCSequenceを処理コストが多いでの、人体とかが苦手だった。 モーションデータを削減して、モーション制御をNEONで並列処理にして最適化

コンフィグの微調整

ccConfig.hでCCUSESVBOを無効にするだけで結構変わる

Time Profiler

順次上から見て最適化をしていく

まとめ

• テクスチャは一枚にまとめてCCSpriteBatchNodeで描画
• NEONなどSIMDを使って最適化
• ccConfig.hをみてチューニング

OCTOBAから見た面白いAndroidアプリ – 丸岡

Android Market

アプリ削除率

• 37%?

OCTOBA

• 男性が多い
• 30-40代が多い

パーミッションの問題

Any.Do

• 機密ログデータの読取
• このパーミッションを要求するアプリはレビューしない

いろいろなパーミッション

• 機密ログデータの読取
• 連絡先データの読取
• SMSメッセージの送信
• アカウントの認証情報を利用
• 起動中のアプリケーション情報
• 端末ステータスとIDの取得

広告SDKでGPSデータを利用してターゲティングを使用したりするものもある。 組み込んだアプリでGPSを使ってなくても、パーミッションが求められる

レビューの基準

人気ジャンル

セキュリティが5月(2011)あたりが入ってる

• ツール・設定系
• ゲームエンタメ系

昔はツール系が多かったが、ゲームエンタメ系が増えてきている

検索キーワード

1. 電話帳
2. 時計
3. メール

使ってもらえるアプリの考え方 – fladdict

ATMアプリを考えてみる

架空の事例で考える

リサーチ

• 既存のATMの機能?
• 既存のATMの不便?
• どういう時に使う

既存のATMの機能

• 残高確認
• 入金、引き出し
• 送金
• 設定変更

オンラインバンキングを含めるともっとたくさんあるので、 どの機能をアプリに含めるのかを考える -> 絞り込む、利用の想定

シナリオ

• 通販などの振込
• 通常の送金
• 支払い忘れへの緊急対応
• 残高確認

逆にスマートフォンで保険や税金管理などの操作はしないとのでいらないはず

90%のユーザーが必要な機能を入れる

• ヘルプなしでわかるアプリを作る
• アプリを起動してからそのアプリのタスクを1-2駅程度の間に完了できるようにする

必要な機能を絞り込んでから、コンセプトを立てる

コンセプトの定義

iPhoneアプリは大体4つの形がある

• ユーティリティ型
• ナビゲーション型(TableView)
• タブ型
• 没入型(全画面)

それぞれのタイプをプロトタイピングして検証していく。

ユーティリティ型

• 最低限だけの機能
• 残高の確認
• 送金ができる

ナビゲーション型

ユーティリティより機能は増える

• ニュース
• 残高
• 送金
• 設定

タブ型

ナビゲーション型と似た機能を持つが、平行して機能を使える

没入型

iPhoneのUIに頼らないので時間がかかる

• 実際の画面に似せるなど
• ナビゲーションを出してみたり
• 現実のメタファ

今回はナビゲーション型かタブ型

ナビゲーション型

• 拡張しやすい
• 単純

タブ型

• 拡張に限界がある
• 平行して機能を利用できるのが利点

ナビゲーション型は階層が深いと、作業を切り替えるにコストがかかるので、タブ型の方がやりやすい

タブ型のメニュー

よく使うものから左から右へ配置していく

ニュースを残高確認後に見る人はあまりいない ニュースをATM側としては配信したいので、ニュースを左に持ってきて自動的に見せるようにした。

設定画面

• ピンコード
• アカウント名
• 銀行アカウントのパスコード

入力UI

• Pickerを使って桁ミスなくすなど
• 送金時はボタンのミスタッチをなくす
• スライドで送金処理を完了させる <= 難しいUIな気がする…
• 最初にボタンを詰め込みすぎない

Edit Qute for PC/Mac

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

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の自動整形で中括弧を強制的につける)、誰が見てもある程度読める感じにする、ブレークポイントを打ちやすい空間を作るように配慮するなどなどで、他のコーディングルールに書いてある事と同じようなものだと思います。

「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