今年も最後となりましたので、自分の 2013 年の活動について振り返ってみます。
ちなみに去年の最後は[enja-oss について](http://blog.mitsuruog.info/2012/12/enja-oss.html)書いてます。 
それから「来年こそはもっと質の良いアウトプットしたいと思います。」と締めくくってますね。果たして私は今年、何をやっていたのでしょうか。。。



![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2013/mitsuruog.png)

1. 1 月〜3 月 翻訳と Backbone.js の SPA チュートリアル作成
2. 4 月〜6 月 HTML5j エンタープライズ部（旧えんぷら部）に参加
3. 7 月〜9 月 JJUG とのコラボレーション
4. 10 月〜12 月 技術研究所へ配置換え
5. 来年の活動

## 1. 1 月〜3 月　翻訳と Backbone.js の SPA チュートリアル作成

この間は、enja-oss にてひたすら stylus 関連の翻訳してました。

- [https://github.com/enja-oss/stylus](https://github.com/enja-oss/stylus)
- [https://github.com/enja-oss/nib](https://github.com/enja-oss/nib)

Javascript の勉強がてら、Airbnb の Javascript スタイルガイドの翻訳を行いました。 
現在では 9 カ国語に翻訳されている、Airbnb のスタイルガイドですが、私の日本語版が最初ですね。 
当時、Javascript どう書けばいいのか迷っている時期でしたので、このスタイルガイドの翻訳は自分にとって非常に良い活動でした。

[https://github.com/mitsuruog/javacript-style-guide](https://github.com/mitsuruog/javacript-style-guide)

おそらく密かに今年のアウトプットとしては一番のヒットだったのが、Backbone.js で SinglePageApplication を作るためのチュートリアルです。
現在では、自分でカンニングするほど w、当時そんなスペックが自分にあったなんて・・・信じられない。

[https://github.com/mitsuruog/SPA-with-Backbone](https://github.com/mitsuruog/SPA-with-Backbone)

当時、Bootstrap2.3 でエンタープライズ向けの Web アプリを作ってました。 
Bootstrap は余白が多いので頻繁にカスタムする機会が多く面倒でしたので OSS にしました。3.0 対応は未定です。

[https://github.com/mitsuruog/bootstrap-narrow](https://github.com/mitsuruog/bootstrap-narrow)

## 2. 4 月〜6 月　 HTML5j エンタープライズ部（旧えんぷら部）に参加

この時期は、HTML5j エンタープライズ部の運営メンバーとして活動していました。 
今の自分があって、ここまで努力できるのもコミュニティメンバーのおかげです。本当に感謝しています。
あまり、後先考えずに参加したのですが、結果としてその判断は間違っていませんでした。

[http://www.html5biz.org/](http://www.html5biz.org/)

この時期は黙々とコードを書いては思索する毎日でした。 
中規模案件のフロントエンドを一切合切任される立場となり、はじめて、フロントエンドのエンジニアとして本格的に仕事をすることとなりました。
普段の鍛錬の結果が実務に本当に活かせるのか、自分との孤独な戦いの日々でした。

## 3. 7 月〜9 月　 JJUG とのコラボレーション

この時期は社内でもフロント関連技術習得を目的としたコミュニティを作っていて、7 月に社内で初めて HTML5 関連技術の勉強会を開催しました。
そのとき未来のフロントエンジニアに向けて作った資料です。

[これからフロントエンジニアを目指すあなたへ](https://www.slideshare.net/mitsuruogawa33/ss-24060048)

7 月には会社のビジネスパートナー向けのセミナーで講演してます。 
ちょうどこの当たりから社内で「HTML5」関連の講演とか頼まれるようになってきましたね。

ただ、この時期仕事の方がテラ忙しくて大変でした。 
140 画面くらいのリッチな社内システム作っていて、フロント側 1 人（私 w）に対してサーバ側 30 くらいの体制でやってて、しかもバックエンドの技術支援とか共通機能とか作ってたので、自分が遅れる（デグレードも w）と開発が全部止まるというような、とにかく辛い立場でさんざん鍛えられました。
そのとき感じたのが、エンタープライズ現場のフロント力の低さで、今の自分の活動ポリシーである「進化し続けるフロントエンド技術とシステム開発の現場をいかに融合させるか！ 」が生まれた時期でした。

忙しい傍ら、勉強がてら co-meeting の未読数を通知するだけの簡単な chrome の extentions を作りました。

[https://github.com/mitsuruog/co-meeting-notifier](https://github.com/mitsuruog/co-meeting-notifier)

9/9 にエンタープライズ部と JJUG と共催で「Java×Web」をテーマに 200 人規模の勉強会を企画して行いました。いままでエンタープライズ部の企画は部長の川田さんが取り仕切っていたのですが、私が手を上げて企画しました。

参加者層を読み違えたので、勉強会自体はちょっとアレでしたが・・・ 
自分がエンタープライズ向けに伝えたかったメッセージはレポート記事などで伝わったと思います。レポート記事はこちらです。

[業務系システムは今すぐ脱 Struts を！」業務システムエンジニアのための HTML5 勉強会#04 活動報告](http://gihyo.jp/news/report/2013/09/1901)

## 4. 10 月〜12 月　技術研究所へ配置換え

10 月からは 1 年の期限付きで技術研究所へ配置換えしました。 
実は、ずっと本気で転職を考えているのですが、あえて現職で頑張る道を選ぶことにしました。
（このことについてはそのうち記事にしようかな。。。SI の退職エントリ多いし）

この時期から社内外問わず講演する機会が増えましたね。 
一番光栄に思ったことは 11/9 の JJUG CCC での講演機会に恵まれたことです。 
普段、Java をやっている身として JJUG CCC に出て話をするなんて、夢のような話でした。
そのとき発表した内容がこちらです。

[メンテナンス性の良い Web システムを構築するために Java とフロントエンドでやるべきこと](https://www.slideshare.net/mitsuruogawa33/webjava)

そうそう、11/9 の JJUG CCC の当日に Macbook Air が届きました。JJUG CCC も Mac で登壇しています。これまでずーと Windows＆lenovo でしたが、今ではすっかり Macbook Air の虜ですね。

仕事では、とあるベンダー製 HTML5 関連の UI フレームワークの国内初事例に挑みながら、フロントエンドのテスト自動化など、HTML5 時代の開発現場の負担やリスクをいかに軽減するか模索する毎日です。

12 月に社内で Node のハンズオンとかやりました。資料はこちらです。
来年も、社内でフロントエンドのキーテクノロジについてハンズオンしながら教えますので、今後もリソース増えそうです。

[https://github.com/mitsuruog/node_study](https://github.com/mitsuruog/node_study)

同僚が困ってたので、サクッと three.js のサンプルとか作りました。

[https://github.com/mitsuruog/richo-theta-with-threejs](https://github.com/mitsuruog/richo-theta-with-threejs)

ざっとこんな感じですね。 
うーん、去年の自分と比べると全くの別人なんですが、正直もっと頑張れたかなと。。。 
もっと頑張れ自分。

## ５. 来年の活動

来年は、今年（前 Windows マシンが壊れて）できなかった JavaEE とフロントエンドのチュートリアルを完成させたいですね。
とりあえず Backbone.js で作ってますが、他に有名どこのフレームワークでも作ってみてエンタープライズ目線で検証・評価したいと思います。

テスト自動化についても、何らかの結果を出したいです。
それからいくつかフロント技術に関する論文を書いて発表したいです。

それから、活動のフィールドを変えます。 
今年 1 年、エンタープライズ HTML5 の立場で活動してきましたが、フロントエンド技術のコアが Javascript と言うこともあり、ブラックボックス化が困難であり、企業としてマネタイズすることが難しいと感じています。 
近い未来では HTML5 特需、IE11 対応特需など見込まれますが、やっぱり一過性のものかなと思っています。

という訳で、表では今まで通りフロントエンジニアとして活動していきますが、裏では、本当にお金になる HTML5 とは？ということをキーワードで活動していたいと思います。

来年こそはもっと質の良いアウトプットしたいと思います。 
では、みなさん良いお年を。

2013年を振り返る

職場の同僚が[RICOH THETA](https://theta360.com/ja/)なる 360° 写真が撮影できるカメラを買って、何やら面白そうなことをやりたがってたので、three.js を使って全天球処理するところを手伝いました。 
全天球処理はさほど難しくなかったのですが、欲を出して行った Drag&Drop 処理が結構ハマったので、その辺りを話ます。

下の DEMO サイトに THETA で撮影した画像を Drag&Drop すると、いい感じに全天球にしてくれます。ソースコードもすべて Github に公開してますので参考にしてください。

- DEMO：[http://mitsuruog.github.io/richo-theta-with-threejs](http://mitsuruog.github.io/richo-theta-with-threejs)
- リポジトリ：[https://github.com/mitsuruog/richo-theta-with-threejs](https://github.com/mitsuruog/richo-theta-with-threejs)



![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2013/RICOH_THETA.png)

### 目次

1. RECOH THETA とは
2. three.js での全天球処理
3. HTML5 File API による Drag&Drop 処理
4. Cross Origin image load HACK
5. まとめ

## 1. RECOH THETA とは

[RICOH THETA](https://theta360.com/ja/)とは RICOH 社が製造する 360° 写真が撮影できるカメラです。

外見がシャレてます。でも結構お高いです。（¥44,800 執筆時）

しかも、公式サイトもおしゃれで流行の縦スクロール型のレスポンシブデザインですが、中身は HTML5 ではなく XHTML でした。残念 w。

スクロールで動く部分は jQueryPlugins ではなく、手組っぽいです。

## 2. three.js での全天球処理

three.js での全天球処理はこちらの WebGL サンプルを参考にしました。 
（とは言ってもほとんどコピペですが・・・）

[http://threejs.org/examples/webgl_panorama_equirectangular.html](http://threejs.org/examples/webgl_panorama_equirectangular.html)

全天球処理がさくっと終わったので、欲を出して image ファイルを Drag&Drop して three.js のテクスチャを変えようとおもったのですが、これがハマりました。

## 3. HTML5 File API による Drag&Drop 処理

HTML5 には FIleAPI という、ブラウザからローカルファイルのやり取りができる標準 API があります。今回は FlieAPI を使って image ファイルの Drag&Drop 処理を実現していきます。

処理の大枠は次のようなコードになります。

```js
//イベント伝搬をキャンセル
function cancelEvent(e) {
 e.preventDefault();
 e.stopPropagation();
}

//ファイルがドロップされたら動くコード
function handllerDroppedFile(e) {
 //
 //ここにthree.jsのテクスチャを変えるコードを書きます。
 //

 //デフォルトのイベントキャンセルしないと
 //ブラウザでイメージが表示されてしまう
 cancelEvent(e);
}

//画面全体
var droppable = document.getElementById("container");
//イベントハンドラ
droppable.addEventListener("dradenter", cancelEvent);
droppable.addEventListener("dragover", cancelEvent);
droppable.addEventListener("drop", handllerDroppedFile);
```

実装時の注意点としては、ファイルドロップ時にイベントの伝搬をキャンセルしないと、ブラウザで image ファイルを開いてしまいます。

## 4. Cross Origin image load HACK

実際にドラックされた image ファイルは`dataURI形式`に変換して、three.js のテクスチャに設定すればうまく行くと思ったのですが、dataURI を読み込む際に同一生成元ポリシー（same origin policy）に抵触していまいエラーとなってしまいました。

dataURI は、通常の Web のリソース命名方式（http とか）ではなく、独自の命名方式（data）で命名されてしまうため、ドラッグした image ファイルを Javascript で再利用しようとすると必ず同一生成元ポリシー違反となってしまいます。 
（[RFC6454 — The Web Origin Concept の仕様書](http://tools.ietf.org/html/rfc6454#section-5)に書いてありました。）

そのため一度、ダミーの img タグに紐づけてから再利用するような HACK を行う必要があります。

```js
function handllerDroppedFile(e) {
 //単一ファイルの想定
 var file = e.dataTransfer.files[0];
 //dummy imgタグwww
 var img = document.createElement("img");
 var fileReader = new FileReader();
 fileReader.onload = function (e) {
 //一度、dummy imgのsrcにセットしてから
 //再利用します。
 //いきなりこうやるとsame origin error
 //material.map = new THREE.Texture(e.target.result);
 img.src = e.target.result;
 material.map = new THREE.Texture(img);
 material.map.needsUpdate = true;
 };
 //imageをdataURIで取得
 fileReader.readAsDataURL(file);
 //デフォルトのイベントキャンセルしないと
 //ブラウザでイメージが表示されてしまう
 cancelEvent(e);
}
```

これで、[RICOH THETA](https://theta360.com/ja/)で撮影した画像を Drag&Drop すると、three.js でいい感じに全球体処理してくれます。three.js すごい！

## 5. まとめ

three.js はやってて面白いですね。

HTML5 の fileAPI を使うことで、ブラウザ上でローカルファイルを扱うことが簡単になってきましたが、それを javascript で再利用する際は、いろいろ問題があることも分かりました。

いつになったら、Web はこういうハックとかバッドノウハウが無い世界になるのでしょうか・・・まだまだ苦難の時代は続きそうです。

### X. 参考資料

- Reading files in JavaScript using the File APIs
 [http://www.html5rocks.com/en/tutorials/file/dndfiles/#toc-selecting-files-dnd](http://www.html5rocks.com/en/tutorials/file/dndfiles/#toc-selecting-files-dnd)
- How to develop a HTML5 Image Uploader
 [https://hacks.mozilla.org/2011/01/how-to-develop-a-html5-image-uploader/](https://hacks.mozilla.org/2011/01/how-to-develop-a-html5-image-uploader/)
- three.js change texture on material
 [http://stackoverflow.com/questions/13583103/three-js-change-texture-on-material](http://stackoverflow.com/questions/13583103/three-js-change-texture-on-material)
- Three.js Update Texture image
 [http://stackoverflow.com/questions/18436431/three-js-update-texture-image](http://stackoverflow.com/questions/18436431/three-js-update-texture-image)

**p.s**

同僚が[RICOH THETA](https://theta360.com/ja/)の競合製品を見つけて悶絶していました w
こちらはウェアラブルです。しかもサイトはしっかり HTML5 でした。もっと頑張れ RICOH

[http://bublcam.com/](http://bublcam.com/)

RICOH THETAで撮影した360°画像をthree.jsで全天球処理したついでにFileAPIのDrag&Drop対応してみた

「Node.js って何それ。おいしいの？」
「それってお金になるの？」
そんな SIer の社内で業後に有志を集めて Node.js のハンズオンをやってみたという、夢のある話を少しします。



1. 教材について
2. メンバー構成
3. ハンズオンやってみた感想とか
4. まとめ

## 1. 教材について

はじめに、教材の利用とリポジトリの Fork 許可してくれた[@yosuke_furukawa](http://twitter.com/yosuke_furukawa)さん、本当にありがとうございました！

本家のリソースはこちらです。

[https://github.com/yosuke-furukawa/node_study](https://github.com/yosuke-furukawa/node_study)

で、私が実際にハンズオンで使用した Fork したものはこちらです。

[https://github.com/mitsuruog/node_study](https://github.com/mitsuruog/node_study)

Fork した方は、以下の点を少し修正を加えています。

- jQuery 依存コードを VanillaJS に置き換え
- デバック関連についてのページを追加

目次については以下の内容となっています。

1. REPL
2. Node.js で HelloWorld
3. Node.js のモジュールの作り方
4. NPM でのモジュール探訪
5. Express 環境構築
6. Express 入門
7. Socket.io 入門

Node.js の基礎から Express ＋ socket.io をつかった websocket のリアルタイム chat 作成まで網羅されていて、一通り Node.js の楽しさについて学べると思います。

個人的には、Node.js のモジュールの作り方、EventEmitter の使い方など、Node.js のコアとなる考え方について、丁寧に解説されていたことが採用の決め手となりました。

## 2. メンバー構成

さて、肝心なハンズオンのメンバー構成は、講師役の私を含めて９名。

うちチューター役が１名の構成でした。

メンバーのほとんどは Javascript の経験がなく（中にはコード書かないマネージャもいたりして w）、エディタも windows のテキストエディタで行うといったような、開始前はゴールできるのか正直不安でした。

## 3. ハンズオンやってみた感想

で、やってみた結果、19:30 から開始して３時間後の 22:30 に無事終了しました。

2 名を除いて完走することができました。

Websocket のチャットをやっていた終盤は、あちこちで「動いたー」「おーすげー」と少しお祭り騒ぎとなって、プログラムを作って動かす楽しさを体験できたかなと思います。普段、コードを書いていない SIer のエンジニアにとってはいろんな意味で新鮮だったと思います。

自分も初めて Node.js 触って悪戦苦闘していた頃を思い出したりして、教えている方も楽しかったですね。

## 4.まとめ

後日メンバーにアンケートに協力してもらったのですが、結構評判良かったです。
社外でもこの手のハンズオンは結構あるのですが、同じ社内ということもあり、分からない部分について質問しやすい環境だったと思います。
自分でやったときは、周りに Node 詳しい人皆無だったので、夜こつこつやって 1 週間くらい掛かったかと思います。やっぱり知っている人に教えてもらいながらの方が、学習効率はいいですね。

この教材であれば、初心者でも講師さえいれば 3 時間でゴールできますので、どんどん活用してみてください。

SIerでNode.js初心者を集めてハンズオンをやってみたという夢のある話

私が担当するエンタープライズのフロント開発では、1 年ほど前から Grunt によるビルドプロセスを導入していて、自分でもプロジェクトの特性に応じて Gruntfile.js のタスクをデザインする機会が多いのですが、最近流行の Yeoman が吐き出す Gruntfile.js を見るとなかなか参考になる点があったので、いくつか紹介したいと思います。



![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2013/yeoman-logo.png)

### 目次

1. load-grunt-tasks
2. テンプレート
3. ファイル指定方法あれこれ
4. 外部パラメータによるタスクの分岐処理
5. 外部定義ファイルインポート

## 1. load-grunt-tasks

[load-grunt-tasks](https://github.com/sindresorhus/load-grunt-tasks)とは package.json に定義されている Grunt タスクを見て、タスク起動時にロードしてくれるモジュールです。これでタスクを変更するたびに Gruntfile.js を変更する必要がなくなりました。

```js
/**
 * before
 */
grunt.loadNpmTasks("grunt-shell");
grunt.loadNpmTasks("grunt-sass");
grunt.loadNpmTasks("grunt-recess");
grunt.loadNpmTasks("grunt-sizediff");
grunt.loadNpmTasks("grunt-svgmin");
grunt.loadNpmTasks("grunt-styl");
grunt.loadNpmTasks("grunt-php");
grunt.loadNpmTasks("grunt-eslint");
grunt.loadNpmTasks("grunt-concurrent");
grunt.loadNpmTasks("grunt-bower-requirejs");

/**
 * after
 */
require("load-grunt-tasks")(grunt);
```

## 2. テンプレート

Grunt には[Underscore.js](http://underscorejs.org/#template)ライクなテンプレートエンジンが内包されています。

`<%=%>`とすることで、中のプロパティが純粋な Javascript として評価され、Gruntfile.js 内に展開されます。

また、`<%=%>`とすることで、任意の Javascript コードを実行させることも可能です。

Yoeman の中では、開発用のディレクトリとビルド用のディレクトリパスを使い分けてます。こちらも、タスク内でよく使う定義情報などはファイルの先頭で定義しておいて、テンプレートで挿入すると後々メンテナンスし易いですね。

```js
grunt.initConfig({
 yeoman: {
 // Configurable paths
 app: "app",
 dist: "dist",
 },

 copy: {
 dist: {
 files: [
 {
 expand: true,
 dot: true,
 cwd: "<%= yeoman.app %>", // <- ここ
 dest: "<%= yeoman.dist %>", // <- ここ
 src: ["*.{ico,png,txt}"],
 },
 ],
 },
 },
});
```

## 3. ファイル指定方法あれこれ

Gruntfile.js でタスクを書いていると、ファイルのマッチング指定を書く部分がほとんどだと思います。

内部的にファイルのマッチングには Glob と呼ばれる仕組みを使っており、[node-glob](https://github.com/isaacs/node-glob)と[minimatch](https://github.com/isaacs/minimatch)のライブラリが使われています。本当に様々なマッチング機能を提供しているのライブラリなのですが、今回は Yeoman でよく使っている範囲で紹介します。

### 「\*」

「/」パス以外の任意の文字列と一致します。次のように使われることがよくあります。

- フォルダ以下一致「vender/\*」
- 任意のファイル一致「\*.js」
- 任意のファイル名一致「.git\*」

### 「{}」

中の文字をカンマ区切りで指定して or 条件とします。次のように使われることがよくあります。

- 拡張子の or 条件「\*.{gif,jpeg,jpg,png,svg,webp}」

### 「`{,*/}`」って何？

Yeoman の Gruntfile.js でよく見る「`{,*/}`」ですが、任意のフォルダ以下の 1 階層のみ一致という意味です。 
サブフォルダ指定する場合は通常「`**`」でいいのですが、パフォーマンス的な理由で 1 階層に止めたい場合は、「`{,*/}`」を使います。

この当たりも、使いこなすことで余計なファイルマッチングを書く必要がなくなります。（Glob 形式が読めない人がいるという別の問題があるとは思いますが w）

## 4. 外部パラメータによるタスク分岐

Grunt タスクを呼び出す場合の次のように「`:`」以降の文字列をパラメータとして渡すことができ、Grunt タスク内で分岐処理を行うことができます。

```
grunt serve:dist
```

通常は`grunt.registerTask`の第 2 引数にタスクの文字列を配列で渡すのですが、ここにコールバック用の function を渡すことで、タスク呼び出し時の処理をある程度柔軟に書くことができます。
とはいえ、可読性という観点では使いどころ微妙かな。。。と

```js
// 普通はこんな感じ
grunt.registerTask("serve", [
 "clean:server",
 "concurrent:server",
 "autoprefixer",
 "connect:livereload",
 "watch",
]);

// grunt serve:distと呼ぶことタスクの中で分岐ができる
grunt.registerTask("serve", function (target) {
 if (target === "dist") {
 return grunt.task.run(["build", "connect:dist:keepalive"]);
 }

 grunt.task.run([
 "clean:server",
 "concurrent:server",
 "autoprefixer",
 "connect:livereload",
 "watch",
 ]);
});
```

## 5. 外部定義ファイルのインポート

Yoeman の generator 界隈ではあまり見かけないのですが、知っていると便利な機能です。

Grunt では json と YAML の外部定義ファイルをインポートする機能が内包されています。次の例 Grunt 公式の例ですが、package.json から定義情報をインポートしています。

```js
grunt.initConfig({
 pkg: grunt.file.readJSON("package.json"),
 uglify: {
 options: {
 banner:
 '/*! <%= pkg.name %> <%= grunt.template.today("yyyy-mm-dd") %> */\n',
 },
 dist: {
 src: "src/<%= pkg.name %>.js",
 dest: "dist/<%= pkg.name %>.min.js",
 },
 },
});
```

## まとめ

Yeoman に学ぶモテる Gruntfile.js の書き方いかがだったでしょうか。

いままでオレオレ Gruntfile.js を書いている方も、モテ期を謳歌している Yeoman が作る Gruntfile.js を読んで、もっとモテる Grunt タスクを書いてみましょう！

**p.s**

いつの間にか generato-webapp の`grunt server`が deprecated になっていることだし、時代の流れは早いものですね。 
こんな記事書いておいて、流行に流されるのも注意しないとなーっと思う今日この頃です。

Yeomanに学ぶモテるGruntfile.jsの書き方

socket.io で有名な LearnBoost が公開している Node 製 SeleniumServer クライアントをさくっと紹介します。
だって、フロントエンドエンジニアは Javascript で Selenium 動かしたいんだもん。

この記事は[Selenium Advent Calendar 2013](http://www.adventar.org/calendars/128)の 19 日目の記事です。

前の記事は[[hinac0 さん]Selenium vs Mercury](http://0dan5.wordpress.com/2013/12/18/1-3/)

次の記事は[[らんさぶさん]Selenium Tips - つれづれなるままに。](http://dolias2010.hatenablog.com/entry/2013/12/20/012714)



1. soda とは
2. soda を使ってみる
3. soda の注意点
4. まとめ

## 1. soda とは

[soda](https://github.com/LearnBoost/soda)とは socket.io で有名な LearnBoost が公開している、Node 製 SeleniumServer クライアントです。
簡単に言うと、Selenium の実行コードを Javascript で書いて、Nodejs で実行するためのモジュールです。
公式では「**Selenium Node Adapter.**」と謳ってます。

# 2. soda を使ってみる。

（ちなみに、私の環境は Mac です。一応、会社の windows7 も動作してます。）

まず、SeleniumServer をインストールします。Mac の場合は brew で一発インストールです。
本当に brew 偉大。

```
brew install selenium-server-standalone
```

公式サイトからダウンロードしても、もちろん構いません。
[http://www.seleniumhq.org/download/](http://www.seleniumhq.org/download/)

brew でインストールすると起動用のコマンドが表示されまうので、一旦覚えておきます。
面倒なかたは ailas 張った方がいいでしょう。

```
java -jar /usr/local/opt/selenium-server-standalone/selenium-server-standalone-2.37.0.jar -p 4444
```

soda を動かす際は、事前に SeleniumServer を起動させておきます。

まさか、Selenium やるのに Firefox インストールしていない方はいないと思いますが、インストールしていない方はインストールしましょう。(自分がそうでした w)

それでは、サンプルのプロジェクトを作成して soda を動かしてみます。

適当なフォルダに soda を npm からインストールします。

```
mkdir soda-sample
cd soda-sample
npm init
npm install --save soda
```

プロジェクト直下に「google.js」ファイルを作成して、次のようなテストコードを書きます。

```js
/**
 * Module dependencies.
 */

var soda = require("soda"),
 assert = require("assert");

var browser = soda.createClient({
 host: "localhost",
 port: 4444,
 url: "https://www.google.co.jp/",
 browser: "firefox",
});

browser.on("command", function (cmd, args) {
 console.log(" \x1b[33m%s\x1b[0m: %s", cmd, args.join(", "));
});

browser.chain
 .session()
 .open("/")
 .type("q", "Hello World")
 .click("btnK")
 .waitForTextPresent("Hello World")
 .getTitle(function (title) {
 assert.ok(
 ~title.indexOf("Hello World"),
 "Title did not include the query: " + title
 );
 })
 .end(function (err) {
 browser.testComplete(function () {
 console.log("done");
 if (err) throw err;
 });
 });
```

後は node コマンドから起動してみます。

```
node google.js
```

そうすると、横で Firefox が勝手に起動してテストしてくれます。
正常にテストが行われた場合、ターミナルにはこのように表示されます。

```sh
mitsuruog:soda-sample mitsuruog$ node google.js
getNewBrowserSession: *firefox, https://www.google.co.jp/
http.createClient is deprecated. Use `http.request` instead.
open: /
type: q, Hello World
click: btnK
waitForTextPresent: Hello World
getTitle:
testComplete:
done
```

## 3. soda の注意点

このように簡単に Node から Selenium を呼び出せる soda ですがいくつか注意点があります。

まず、「http.createClient is deprecated. Use `http.request` instead.」が象徴しているように、ここ１年くらいメンテナンスされていません。また、Chrome など他の WebDriver には対応してないようです。つまり「Firefox only」です。

## 4. まとめ

Node で Selenium を起動できる Driver モジュール soda いかがだったでしょうか。

機能限定ながらフロントエンジニアが Javascript でテストコードを書けて Node で実行できるというのは、ハマればメリットがあると思いました。

また、Node から Selenium を起動できるものは他にも[wd（https://github.com/admc/wd/）](https://github.com/admc/wd/)というものがあり、他の WebDriver をサポートしているなど、機能が豊富でなかなか強力です。

機会があれば、こちらも紹介したいですね。

NodeからSeleniumServerを動かすLearnBoost製クライアントがあるsoda

2013/10/30 に「[Frontrend x Chrome Tech Talk Night Extended](http://frontrend.github.io/events/chrome/)」が開催され、Addy 氏、Jake 氏、Paul 氏が来日して、最新のモバイル開発のための様々な手法を紹介してくれました。
そこで聞いた内容をもとに、エンタープライズで適用できそうなものを、中立な目線で評価・検証していたのですが、ChromeDevtools のが凄すぎて、終わってみたら ChromeDevtools ばっかり評価・検証していた（おいおい！）という話をします。

ちなみに、Android 開発はほとんどやったことはありません。 
あうあう。



これの記事は[Frontrend Advent Calendar 2013](http://www.adventar.org/calendars/62)の 12 日目の記事です。 
前日の記事は[light Chen さん]・・・まだ書いてない＞＜; 
明日の記事は[[pocotan001 さん]Gist Slides（仮）を作った。 - pocotumblr](http://pocotumblr.tumblr.com/post/69868810750/gist-slides)

## はじめに

（今日は Android と Chrome 限定の話です。）

最近、エンタープライス領域においても、本格的にモバイルへの対応が求められるようになってきました。

あちこちの勉強会などで聞く、Android 開発の現場でのあるある光景として、開発者が背中を小さくして多くの実機でデバックやテストしている姿が挙げられます。それぞれのデバイス間で微妙に操作方法が異なったり、そもそもデバイス自体が操作しにくかったりと、開発者への負担が大きく、時間がかかる作業です。

また、開発以降のフェーズにて「コードを修正して実機にて確認」という一連のイテレーションサイクルを、どれだけ高速で安定した形で回せるかが、エンタープライズでの本格的なモバイル対応の際に、最も重要なポイントの一つだと感じています。

そんな悩みを一気に解決してくれる可能性を秘めているツールの一つが、フロントエンジニアが普段慣れ親しんでいる ChromeDevtools だと思います。
今日は ChromeDevtools で最近追加された、Android 開発が楽になる機能を２つ紹介します。

詳しくは本家のサイトが一番詳しいので参照してください。
[https://developers.google.com/chrome-developer-tools/docs/remote-debugging](https://developers.google.com/chrome-developer-tools/docs/remote-debugging)

## Remote Debugging

Remote Debugging とは、デバイスを USB で接続し、閲覧しているページをローカル PC 上の Chrome Devtools でデバックするできる機能です。Android4.0 以上の端末で有効です。

### Remote Debugging の設定

Remote Debugging を行うためには、まずデバイス側で USB デバックを受け入れる準備が整っていること、ローカル PC 上にデバイスの USB ドライバがインストールされていることが前提条件です。
Google で調べるといろいろ出てきますので、詳しくは紹介しません。
（windows の場合は、USB 接続時にドライバが自動でインストールされないようです。デバイス多い場合、結構泣くと思います。）

まず、デバイスを USB で接続して、ローカル PC 上の Chrome のアドレスバーにて「chrome://inspect」と打ってください。下のような画面が表示されて、接続してあるデバイスが表示されれば準備は OK です。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2013/Screencasting1.png)

### Remote Debugging 使ってみる

実際に Remote Debugging するためには、「inspect」リンクを押せばいいです。非常に簡単です。後は、ローカル PC の Devtools と同じ感覚で操作できます。
例えば、elements タブでスタイルを変更した場合、即座にデバイス側へ反映されます。

さらに、ブラウザのバージョン番号が表示されている横のテキストボックスに URL を入力することで、デバイス側へ表示させてたいページを送ることができ、Remote Debugging と組み合わせることで、ローカル上で開発中の画面をデバイス側でデバックすることができます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2013/Screencasting2.png)

### Port Forwarding

Port Forwarding とはローカル PC 上の TCP ポートをそのままデバイス側に転送する機能です。具体的にはローカル PC 上で開発している「localhost:9000」など、今まさに開発中の Web ページをデバイス側へ転送して表示させることができます。
（本家のサイトに記載されてますが、ネットワークなどの制限により動作しない場合があるようです。）

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2013/Screencasting3.png)

### Port Forwarding + Grunt + livereload

最近のフロント開発では、「Yeoman+Bower+Grunt」を組み合わせた高速開発手法がトレンドです。中でも[grunt-contrib-watch](https://github.com/gruntjs/grunt-contrib-watch)の「livereload」を使ったコードの変更からブラウザのリフレッシュまでの一連の操作を自動化したものは、今のフロント高速開発を象徴しているものです。

この livereload と Port Forwarding を組み合わせると、ローカル PC 上に USB 接続してあるすべてのデバイスを livereload させることができます。
具体的には次のようにします。

話の都合上、ローカルにて開発中の Web ページの URL が「localhost:9000」とし、livereload 用の Port を「9002」とします。
次のように 9000、9002 ポートを転送するように、Port Forwarding 設定をします。
（livereload のデフォルトポートは 35729 なのですが、Devtools 側が 4 桁ポートしか受け入れてくれないので、9002 にしてます。Devtools チームの皆さんなんとかしてくださーい。）

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2013/Screencasting4.png)

設定が正しく行われると、転送されるポートが画面上で確認できます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2013/Screencasting5.png)

これで、9002 ポートを経由して livereload ができるようになりました。
コード修正のたびに、デバイスのブラウザをリフレッシュするという手間がなくなりましたね。

## Screencasting

Screencasting とは、デバイスで表示されている画面をローカル PC で閲覧できる機能です。イメージとしては Remote Debugging の Port Forwarding の逆ですね。
これは Chrome のバージョン 31 から追加された機能です。

### Screencasting の設定

（まだ実験的な機能です、将来的には普通に使えるようになると思います。）

Screencasting を使うためには、ローカル PC 上の Chrome のアドレスバーにて「chrome://flags」と打って、実験的な機能が使えるように設定する必要があります。
表示された画面にて、次の２つの機能を有効にしてください。

「デベロッパー ツールのテストを有効にする（#enable-devtools-experiments）」
「USB でリモート デバッグを有効にする。（#remote-debugging-raw-usb）」

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2013/Screencasting6.png)

変更したら、下の方に Chrome を再起動するためのボタンが表示されますので、再起動してください。
そして Devtools の設定画面を開いてみると、見慣れない「Experiments」メニューが表示されるはずです。
そこで「Enable screencast」にチェックをすると準備は OK です。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2013/Screencasting7.png)

### Screencasting を使ってみる

とりあえず、先ほどの Remote Debugging と同じ要領で、デバイスを USB でつないで Remote Debugging してみてください。今度は、Devtools の下の方に見慣れない「□」が表示されているはずです。（ちょっと分かりにくいですが w）
これを押すとデバイスで表示されてるページがローカル PC 上に転送されてきます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2013/Screencasting8.png)

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2013/Screencasting9.png)

ちなみに、Screencasting された画面では次のことができます。 
素晴らしい！！

- キーボード入力の転送
- クリック
- タップの転送
- スクロールの転送
- ズームやリサイズの転送
- Devtools 上での操作を転送

## まとめ

Chrome の Devtools に追加された 2 つの機能。
Remote Debugging と Screencasting。非常に強力でしたね。これらを組み合わせることでデバイスを操作することなく「コード修正から確認」まで行うことができ、開発時のイテレーションを速くまわすことができそうです。

個人的には、Screencasting での livareload を試してみましたが、他にもスクリーンショットやスクロールの同期など、デバイス間のリアルタイム連動が Devtools 上でできるともっと開発が楽になると思いました。

また、世の中には Android 開発をサポートする OSS や Web サービスが多数ありますが、Devtools 上に同じ機能が取り込まれてしまうと、差別化が難しいですね。
エンタープライズで導入を検討する際は、少し頭の片隅に入れておいたほうが良さそうです。

さくっと livereload 体験してみたい方は、こちらにサンプルが動かせるリポジトリ準備しましたので、ローカルに clone して動かしてみてください。

[https://github.com/mitsuruog/awesome-chrome-devtools](https://github.com/mitsuruog/awesome-chrome-devtools)

### 謝辞

最後に、この内容は 2013/10/30 にサイバーエージェントで開催された「[Frontrend x Chrome Tech Talk Night Extended](http://frontrend.github.io/events/chrome/)」で聞いた内容を元にしています。

本当にサイバーエージェントの Frontrend の方々、最高です！！
ありがとう！！

Androidやってる人でChromeDevtoolsのRemote DebuggingとScreencasting知らない人は使ってみた方がいいよ！

このエントリは[HTML5 Advent Calendar 2013 ３日目](http://www.adventar.org/calendars/125)の記事です。

前後の記事はこちらです

← youhei.iwasaki8 [[iwahei の日記]geolocation api を使った位置情報取得](http://d.hatena.ne.jp/iwahei0813/20131202#1385943993)

→ あおいたん [[GCG 研究所]手元にあった HTML5 アプリを FxOS と Tizen で動かしてみるの巻](http://www.gcg.bz/labo_blog/?p=590)

「Internet of Things」と呼ばれる「モノがインターネットする」時代のコンテンツは、人が目にして理解できる程度では十分ではありません。すべてのモノが理解できるコンテンツ、その鍵は HTML5 が持つ「セマンティック」と「WAI-ARIA」での仕様の標準化だと思います。



### このエントリでお伝えしたいこと。

1. たまに目にする「role=""」の意味を理解して欲しい。
2. 「aria-」で意味付けすることで、ちょっと得することがある。
3. 「セマンティック」は再利用してこそ意味がある。

エンタープライズにいるエンジニアとして、「なぜ HTML5 なのか？」「HTML5 になると何かいいのか？」という問いに対する答えを探し続けています。
まだ、答えは見つけられていませんが、ぼんやりと「セマンティック」の先にある何かではないかと感じています。今日は、そんな頭の中のもやもやを少し文書化してみました。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2013/ariaweb1.jpg)

## 私が思うセマンティックとは

今日まで数々の論者の方がセマンティックについて語って来ましたので、今更わたしのセマンティック論なんて聞きたくないと思いますが、あえて言わせていただきます。

**「HTML 文書に意味付けを行って、機械がその意味を理解して振る舞えるようにすること」**

セマンティックとは人が自己満足でやるものではなく、あくまで機械（デバイス）などで HTML 文書が再利用できて初めて価値があると思います。エンタープライスにて今後「HTML5」を導入する企業は多いと思いますが、一度この辺りを真剣に検討した方がいいと思います。

## アクセシビリティと WAI-ARIA

[WAI-ARIA(Accessible Rich Internet Applications)](http://www.w3.org/TR/wai-aria/)とは、
アクセシビリティ（どのような条件や環境下でも Web を利用できる）の問題を解決するために、W3C が仕様を策定しているもので、現在勧告候補となっています。

一般的にアクセシビリティとは、高齢者や障がい者向けへのブラウザ読み上げ機能を想像していただけると理解しやすいかと思います。

様々なデバイスが普及して Web に繋がるようになった今日、様々なデバイス（特にタッチスクリーン）・環境下（特に屋外）で Web を利用するケースが増えてきたこともあり、意外なシーンで Web のコンテンツを利用できないことを体験された方も多いかと思います。

そんな、通常の手段（人が目で見て手で操作する）で閲覧することができない場合、デバイス側への代替え手段の提示方法として、WAI-ARIA が存在しています。
これを人だけではなく、機械（デバイス）が利用してブラウジングできれば面白いですね。

また、WAI-ARIA が持つ一面として、[動的な振る舞いやコンテンツが持つ状態を仕様化](http://www.w3.org/TR/wai-aria/states_and_properties)があります。

HTML5 のセマンティックは文書の静的構造についての意味付けを行っており、現在の Web が持つ動的な振る舞いやコンテンツが持つ状態までは当然カバーしていません。

今後、本当の意味で「Internet of Things」になっていくためには、コンテンツが持つ振る舞いや状態まで標準化され、機械が理解できるようになる必要があると思うのは、当然な流れなのではないでしょうか。

## WAI-ARIA を使ってみる

では、WAI-ARIA を使ってみましょう。
試しに iOS の VoiceOver 機能を使って、Safari の画面を読み込ませてみました。

WAI-ARIA では、HTML のタグにカスタム属性「role」にて役割を、「aria-」にて振る舞いや状態を定義することができます。
（変なマークアップがあるかもしれませんが、雰囲気をつかめればいいのでご了承ください。）

なんからのポップアップのリンクがあったとします。
WAI-ARIA 対応されてないマークアップの場合は、VoiceOver はただのリンクと解釈しています。

```html
<a href="//www.google.com" target="_brank">google</a>
```

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2013/ariaweb2.png)

ところが、WAI-ARIA の「aria-haspopup」を使うことで、VoiceOver はポップアップリンクであることを認識しています。

```html
<a href="//www.google.com" target="_brank" aria-haspopup="true">google</a>
```

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2013/ariaweb3.png)

次は、状態の例です。

Ajax などによるコンテンツを動的に更新するケースは非常に多いと思います。
WAI-ARIA では次のように「aria-live」を使用することで、コンテンツの動的更新を通知することが可能です。

Javascript 側でタイマーを仕込んでコンテンツを動的更新させていきます。

```js
var p = document.getElementsByClassName('hoge')[0];
var count = 0;
setInterval(function(){
 p.innerText = count++;
}, 1000);
```

HTML のマークアップは次の通りです。

```
<p aria-live="polite" class="hoge"&gt;0&lt;/p&gt;
```

このようにすることで、VoiceOver はコンテンツが動的に変わった瞬間を検知して読み上げてくれます。

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2013/ariaweb4.png)

必須入力も「aria-required」で知らせてくれます。

```html
<input aria-required="true" />
```

![](https://s3-ap-northeast-1.amazonaws.com/blog-mitsuruog/images/2013/ariaweb5.png)

ほかにも WAI-AREA で定義されている属性は非常に沢山ありますので、詳しくは仕様書を読んでください。

- [Accessible Rich Internet Applications (WAI-ARIA) 1.0](http://www.w3.org/TR/wai-aria/)
- [WAI-ARIA（日本語訳）：日立のユニバーサルデザイン](http://www.hitachi.co.jp/universaldesign/wai-aria/)

## まとめ

このように、WAI-ARIA を意識したマークアップを行うことで、デバイス側が振る舞いや状態を理解した上で、我々に機能を提供できる可能性があることを感じました。

少しでもアクセシビリティを考慮した Web が増えることで、デバイス側でそれを二次利用できるケースが増えると思います。
また、今後 WAI-ARIA を使った華やかな事例が出て、一気にデファクトスタンダードになるかもしれません。

まだ、デバイス側の挙動が統一されていないとか、そもそも実装されてないなど問題は多くありそうですが、HTML5 が持つ「セマンティック」と WAI-AREA の「アクセシビリティ」の組み合わせで、我々が普段目にする華やかな HTML5 とは少し違う、目に見えにくいけど、Web との関わり方そのものを変える（かもしれない）可能性を感じてもらえたらなと思いました。