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

「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

デジタルプラクティス

発行は季刊で1月（創刊号のみ2月），4月，7月，10月に発行されるのをPDFで読める。
内容も多岐にわたっていて、論文というほど堅くはないものもあり読みやすい。

デジタルプラクティスでは，実務の現場におけるIT 実践例・経験・ノウハウのレベルの成果でも社会的に有用なものならば歓迎し，IT実践における新たな発展を先導するような論文を積極的に採録します
創刊に当たって

また、著名な人も結構寄稿されているので、読みたいものが何かしらあると思います。

• プログラミング言語Rubyの世界普及戦略
  まつもとゆきひろ
• ウェブブラウザLunascapeの起業戦略と技術戦略
  近藤秀和
• クラウド時代のユーザインタフェースの方向性
  ～サービスサイエンスでUI の方向性を検証する～
  鹿島泰介

などなど

情報処理推進機構：ニューヨークだより

IPAにより月一でPDF形式で発行される。
アメリカのIT関係についての最新事情を扱っていて、ものすごく詳しく書かれている。
ITやスマートフォンなどのデジタル機器(OSについても)やITと政治についてなど、かなり詳細な情報を掲載している。
無料とは思えない質だったり、情報元のソースを脚注で入れてくれるので、情報元自体も見られてとても良い感じになっている。おすすめです。

Wizard Bible

Wizard Bibleとは、基本的に毎月リリースしているWebマガジンです
Wizard Bible

発行は月一でtxt形式で発行されている(最近不定期だった気がする)
内容はどういったテーマで書けばいいのか？を見ると分かると思いますが、セキュリティ関係のものが中心となっています。それに関係するプログラミングや数学などの内容も扱われています。

IS Report System

本サイトは 「同志社大学生命医科学部医情報学科 医療情報システム研究室」 及び 「同志社大学工学部インテリジェント工学科 知的システムデザイン研究室」 の所有する研究報告である ISレポートの管理システム
IS Report System

医療やソーシャルメディア、インターネットや携帯電話などの電子機器について書かれたレポートが公開されています。
HTMLとepub形式(一部PDFも)で配布されていて、図などが入ったものも多く内容も結構読みやすいです。
結構書かれているジャンルが幅広い気がします。

The Pragmatic Bookshelf | Read Our Magazines

Pragmatic Bookshelfにより毎月発行されるプログラミング関係の電子雑誌。
HTML PDF epub mobiが用意されている。

番外編

タイトルから外れて有料の雑誌。
といっても海外だと電子版の雑誌は珍しくないので、気になったものだけ。

JsMag – the magazine for JavaScript developers

JavaScriptについて扱う月刊誌。
一号毎に購入($4.99)か一年分まとめて購入($53.88 )ができる。
日本にもこういうの欲しいですね。。

Hacker Monthly – Print Magazine of Hacker News

Hacker Newsで話題になったものを厳選して扱う月刊誌。

おわり

電子雑誌というタイトルにしたけど、別に雑誌じゃないものが多い気がする。
今はブログやソーシャルメディア経由でだいたいの情報はカバーできるだろうけど、論文や雑誌、スライドなどある程度労力を伴って書かれたものにはブログとは異なるものがあると思ってるので、こういうものも読んでいきたいですね。

JavaScriptの論文かき集める仕組み欲しい。日本でも小さなもの含めて年間二桁は書かれてる感じする。
Twitter / @azu_re: JavaScriptの論文かき集める仕組み欲しい。日 …

とか思ったりするのはそういう理由です。

他にもおすすめがありましたらよろしくお願いします。

TwittterのログはTogetter – 「第3回 ブラウザー勉強会(#BrowserWS)のまとめ」にまとまっています。

第3回 ブラウザー勉強会

午前の部 :コミュニティー セッション

ショートセッション : kyo_ago  (http://tech.kayac.com/)
「Testで始まる物語（ストーリー） QUnit CUIの紹介」

[Ustream] [発表資料]

jQuery Plugin testフレームワーク

• 非同期実行されるコードのテストが面倒
• UIのテストが面倒

テストコードは次の３つから構成される

• テスト前のHTML
• テストするコード
• テスト後のHTML

コードにすると以下みたいな感じ。

<script type="dom/base" /> <script type="test/code" /> <script type="dom/comp" />

• iframe内でこれを行うので、セレクタなどの心配が不要
• 自動的にdiffをとれる
• 複数端末上で分散実行
• 複数ブラウザでの比較
• pluginのテストコードを生成

ショートセッション : はせがわようすけ 「Using Win32 API inside Chrome Extension」

[Ustream] [発表資料]

Chrome Extensionの構成

• HTML + JavaScript
• マニフェストとリソース

Chrome Extentionの制約を超える

NPAPI DLL – プラグインを書くためのもの

• OSに依存する
• Extension内にplugin DLL
  • リモートHTMLから直接利用は無理

マニフェストにdllのロードパスを書くだけで読み込める。

• 拡張の制約が超えられる
• 化石のようなもの

NPWIN32

何でも使える汎用DLL * JavaScriptから何でもできる

JavaScriptからネイティブコードを呼び出すことができる

• Windowsの方のalertを呼び出す
• デスクトップ情報の取得

NaCLとの違い * NaCLは OSネイティブの機能は呼び出せない。

ライトニング トーク : normalian さん (http://d.hatena.ne.jp/waritohutsu/)

[Ustream] [発表資料]

「ブラウザ戦国時代で考えるクロスブラウザなテスト方法（仮題）」

• ブラウザのバージョンアップ頻度が高くなった

• ブラウザレンダリングの差異

• JavaScriptのイベントハンドリングの差異
• HTMl5の対応状況の差異

jQuery & Modernizr

jQuery

• jQuery Core
• jQuery Mobile
• jQuery Template
• jQuery Validate

Modernizr

• ブラウザのHTML5対応度合いの確認

jQuery UIとjQuery Mobileはソースコードは一部流用されている。 混ぜると危険。

モバイルブラウザのタブの傾向と対策 -Androidスマフォを主に- saneyuki_s

[Ustream] [発表資料]

• モバイルブラウザのタブの傾向まとめ スマートフォンブラウザの「タブ」の様式にデファクトがない

• ウィンドウ式

• メニューからウィンドウを出して切り替える

• 画面下部に表示
  • Opera
  • Sleipnir Mobile
  • サムネイル付きが多くてわかりやすい
• 画面上部に表示
  • Dolphine Browser
  • タブレットでは一般的
• FIrefox Mobile式
  • サイドに格納する

番外

* IE9 Mobile – タスクスイッチャーと連動
* Sleipnir Mobile – タブグループ機能 -  面倒くさい工程

まとめ

様式は落ち着かないだろう。

Google Chromeはエンタープライズの夢をみるか : Hebikuzure

[Ustream] [発表資料]

• ユーザ権限でインストールできる
• 勝手にアップデートできる
• Google Chrome Frame

管理者が投げ捨てる可能性

Chrome にはグループポリシー機能がある

(Windows版について) Documentation for Administrators – The Chromium Projects

Chromum Projectの方に書かれてる

• HTTP認証の動作
• コンテンツの設定
• 検索プロバイダ
• パスワードマネージャー
• プロキシ
• ホームページ
• 拡張機能
• スタートアップページ
• Google Chrome Frameの動作(無効にできる)
• Google Updateの動作
  • Google製品の個別で自動アップデートの有無
• Google Installerによるソフトウェアのインストールの設定

Chromeのmsiインストーラーもある(?msi=trueでダウンロード)

• Active Directorで配布できる
• 特定のバージョン縛りができる

グループポリシーのテンプレート(ADM,ADMX)が配布されているので、グループポリシーの追加ができる。
PolicyDefinitionsというフォルダーにコピーする事で入れることでも読み込める

Q&A

• セキュリティアップデートも無効にできる

午後の部 : テーマ セッション 「ブラウザーと Web が描く『夢』」

加藤 誠さん (Mozilla Japan)
「Openness, Innovation, and Opportunity」

[Ustream] [発表資料]

Mozillaのミッション「Openness, Innovation, and Opportunity」

非営利法人が扱えるお金が制限されているので、Mozilla Corporationという株式会社ができた。

Mozilla Labsをメインに

• 実装だけではなくて、モックなどでもあり
• RUST 言語

• 将来のFirefoxで取り入れられることも

  • FIrefox Syncなど
• UI/UX
• WEB API

などがLabの範囲

Design Challenge

• 特定のテーマでデザインやモックでアイデアを募る
• アイデア(デザイン)の発表する場所
• 実装ではなく、あくまでもアイデア

Test Pilot

• ユーザーのブラウザ利用データーを取得して解析
  • 収集用のアドオン
  • 結果を公開
• データが偏る傾向があるため、偏りを取る手法を使う
• ユーザーのクリックするホットスポット調査とか

Prospector

• ユーザーが目的のサイトにたどり着くためのUXの模索
• Prospectorは実装ありきのアイデア

Firefox SHARE / F1

ソーシャルネットワークとの結合

Q&A

アップデートスピードが早くなったのはなんで? * Webの流れが早くなってる

UI/UXのアプローチ

• 目線の移動がおかしいとか
• 公開された議論してるので、おかしいとクレームがくる

検索バーとURLバーの統合について

• 一応Firefoxとしてもそういう議論がある
• ユーザーからのフィードバック次第になる。

Daniel Davis さん (Opera Japan)
「ブラウザの未来：HTML5の先には？」

[Ustream] [発表資料]

1899年に書かれた未来2000年について。

未来的なものを想像しても、洋服や建物が変化していない。

More than HTML5

Device APIs

• まだまだカメラでデータ取得は先だけど 。
• Web APIとARを連動してやるなど(Tweetの取得など)

逆にカメラにブラウザが乗ることもあり得る

More like a platform

Web on TV * ブラウザが載ってるTVも増えている * ブラウザはWebを見るためではなく、Appとして利用されてる * 多くのメーカーはSVGでUIを使ってる(レンダリングエンジンがブラウザ)

• TVのUI(user input = リモコン)は最悪
  • これが改善されないとWeb on TVが流行らないかも
  • ジャイロリモコン
  • キーボードタイプ

ブラウザの進化

• ブラウザによりUIが静的から動的に
• 動的からインタラクティブへ
  • ペーパーレス = 静的なものがまだ多い => マルチメディア

履歴書の事例 * 履歴書に動画を入れる * マルチメディアをもっと普通のドキュメントに使う

再生だけではなく、作成もブラウザで? * contenteditable * 今はまだ非力

ネイティブよりウェブ?

• JavaScriptは早く、パワフルになった
• 比較的に書きやすく勉強しやすい
• 100%オープン
  • ひとつの会社などにコントロールされてない
  • 未来的にそれはいいこと

未来の予想は人によって違う

• ウェブはひとつの団体にコントロールされないのが重要
• コントロールされないウェブは未来も一緒に作る

Q&A

ブラウザがいろいろなものに乗った場合、それぞれに対して最適なUIは異なるが、それを上手くやる工夫

• OSとブラウザは大きくは変わらない
• ブラウザを一番下において、その上に何かをかぶせて作らせれば異なるものに対して拡張を作りやすい。

春日井 良隆さん (日本マイクロソフト株式会社 UXエバンジェリスト)
「マイクロソフトにとってのWebって？」

[Ustream] [発表資料]

MSとしてIE6のシェアを減らすのに取り組んでいる。 @mskkie の中の人 with ミゾグチさん

管理者キット9(IEAK 9) * カスタマイズしたIEをパッケージ化、配布、管理するためのツール
なんとか版IEというのはIEAKでパッケージ化したものを使ってる

The Internet Explorer 9 Blocker Toolkit
WindowsアップデートやMSアップデートを管理するツール

HTML5 Native to WIndows

• ウェブの技術をネイティブに持っていく
• ウェブサイトをアプリケーションと同じように使う方向性

タブレットPCは失敗した…

HTML5+JavaScriptでアプリケーションを作る。

MSは同じ表示をするという基本思念がある。

Windowsはカーナビ専用のOSがある。

Windows Phone はIE9ベースのブラウザ

MSと携帯会社である程度端末の取り決めがある

• ボタンは3つを付ける
• 性能についても取り決めがある
• 解像度は固定

IE10は8-12週でリリースする。

MSはブラウザ固有の機能は付けない方向

IEの拡張性について

• IEはカスマイズは上げて行く方向ではない感じ
• 拡張を簡単に作る仕組みはまだ見検討

IE7について

• IE7さんはわすられています。
• まずはIE6からなくしていく。

IDE, Expression について

• Expressionはdevよりの作り
• デザインはDWの方がいいかも
• ExpressionはそっけないVisual Studioな感じ

• IE10は今年はでない
• Windows 8 がタブレット