E-Commerceから Conversational Commerceへ

ここ最近話題になることが多いAIやBotsですが、私の周りではConversational interface、Conversational UXなどという言葉が去年からたびたび使われるようになっているようです。

これはAmazon Alexaなどのデバイスや、Facebook Messengerなどチャットアプリケーションなどの対話型テクノロジーをいかに活用しその使い勝手をよくするか、ということなのですが、必ずしもアプリケーションのUIデザインそのものを述べているわけではなく、既存のサービスを延長することを指していることも多いでしょう。例えば、今まではモバイル上のアプリケーションのみで車を呼べていたUberが、Facebook Messenger のチャットからも車をを呼べるような機能を加えたり、Slack上でTaco BellからタコスをオーダーできるTacoBot、というのもが挙げられます。

Slack Botを書いてみよう

さて、というわけで何かBotを書いてみたいと思いませんか？ここはNode.jsでSlack botを作成する方法を紹介したいと思います。

このチュートリアルでは、ディベロッパー向けのHTTPステータスコードのルックアップができるスラッシュ・コマンドを作ってみます。ここでは私が５年ほど前に何気なく作って、Mashableなどで紹介され思わぬ反響を得てしまったHTTP Status Catsを使ってみます。具体的には、Slack上でユーザが、/httpstatus [code] （例えば /httpstatus 404）と入力すると、そのステータスコードの意味と猫が一緒に表示される、という簡単なbotです。

まず試してみたい方は、HTTP Status Cats command for Slackを自分がアドミン権限のあるのチャットチームにインストールしてみてください。

さて、このチュートリアルは２つのパートに分けられます。

1. スラッシュ・コマンドを書いて、自分のSlackチームにインストールする
2. OAuthを使ってボットをSlack’s App Directoryなどで誰もがインストールできるようにする

とりあえず動くbotを書いてみたい、と思う方は１だけ試してみてで十分ですが、botをみんなにシェアしたい方は２も読んでみてください。

ソースコードと実際のボットのインストールボタンは両方GitHubにあります。では始めましょう！

1 プライベートなスラッシュコマンドボットの作成

ここで作るのは、Slackの公式な用語でいうところのCustom Integrationsというもので、自分のチャットグループ専用のプライベートなbot、もしくはいわゆるAppとして発表する前にドライ・ランを行うことを指します。アカウントを持っていない方はまずサインアップしてから始めましょう。

1.1 スラッシュコマンドの設定

ログインして、my.slack.com/services/new/slash-commandsでコマンドを選びます。ここでは/httpstatusと入力しAdd Slash Command Integrationボタンをクリックして次のステップへ進みます。

Tokenなどの欄がありますが現時点では、(1) Command、 (2) URL、 (3) Method、の３つが必要になります。

(1)には、/httpstatus、(3)には、POST、そして(2)のURLは次のように設定してください。

開発中に使用するURLを取得するにはngrokを使ってみましょう。いろいろなツールがあるのですが、これは自分のローカルホストをパブリックURLとしてトンネルできるというとても便利なツールなので私のイチオシです。開発途中にデプロイすることなく、Webhookが手軽に使えます。自分のローカルホスト、たとえば http://localhost:3000/ をつかったままOAuthのテストもできるのです。（注：よく聞かれるのですが、ngrokはあくまでも開発ツールですのでプロダクションには適していません。デプロイメントに関しては最後の章を読んでください）

https://ngrok.com/から自分のマシンにngrokをインストールしたら、ターミナルで自分の使いたいポート番号（このチュートリアルでは 3000）を設定します。

$ ngrok http 3000

すると下のスクリーンショットのように、Forwardingアドレスが取得できるので、そのURL（例えばhttps://71f03962.ngrok.io/)をSlackセッティングの、上のスクリーンショットで示された(2)の欄で使います。

すべての設定が終えたらSaveボタンを押します。”Your settings have been saved!”のメッセージが画面上部に現れるのを確認してください。

1.2 Node.js を使ってレスポンスを書く

基本的にbotは、ユーザがSlackインターフェイス上でコマンドを実行した際HTTP POST（または設定次第では GET)によって指定先のURLにメッセージが届け、プログラムでその応答をユーザに返す、という作業になります。

たとえばそのユーザが/httpstatus 302というコマンドを送信した場合、指定URLに送られるデータは次のようになります。

command=/httpstatus
text=302
response_url=https://hooks.slack.com/commands/1234/5678
…

Botは、これに対する応答をユーザに返します。この場合はユーザが尋ねているステータス302の定義とこの猫を返しましょう。

ではそのコードを書いてみましょう。

まず、Express.jsとbody-parserをインストールします。

$ npm install express body-parser --save

index.jsで、expressのインスタンスを作り、先ほどngrokで設定したポート番号、3000でサーバを始動します。

'use strict';
const express = require('express');
const bodyParser = require('body-parser');
const app = express();
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: true }));

const server = app.listen(3000, () => { 
console.log('Express server listening on port %d in %s mode', server.address().port, app.settings.env);});

次はHTTP POSTルートメソッドで、コマンドを扱います。

app.post('/', (req, res) => {
 let text = req.body.text;
 // ここでbotを書きます
});

ここでtextの値を取得します。HTTP Status botの場合、/httpstatus コマンドの値、例えば”404″が textの値になります。同時に、ユーザが数字以外を入力した際にエラーメッセージを送るなどのエラーチェックもしておきましょう。

if(! /^\d+$/.test(q.text)) { // not a digit
 res.send('Error: enter a valid status code, such as 200');   
 return;
}

このエラーは、ユーザだけにプライベートに送信されるメッセージでチャットそのものには表示されません。

エラーがない場合は、コマンドに対する応答をJSONとしてレスポンスします。

let data = {
 response_type: 'in_channel', 
 text: '302: Found',
 attachments:[{
   image_url: 'https://http.cat/302.jpg'
 }]
};
res.json(data);

response_typeをin_channelとすることで応答はチャットメンバー全員に見えるように送信されます。デフォルトはその逆のephemeralで、コマンドを送ったユーザのみに表示されます。

このコマンドと応答は次のようになります。

このサンプルコードでは、応答をわかりやすくハードコードで示してありますが、実際はストリングなどは別のファイルに定義しています。下のスクリーンショットのように存在しないHTTPステータスに対してのエラーメッセージも定義しましょう。実際のコードはソースコードを参照してください。

ディスプレイはボーダー色などのカスタマイズが可能です。詳しくはSlackドキュメンテーションのBasic message formattingを参照してください。

次のステップでは、このボットを自分のチャットグループ以外に配布するために必要な認証とコードのデプロイについてです。

2. Slack Botのディストリビューション

この「Custom Integration」をインストール可能な「App」にするには、コードのデプロイをして他のチャットにもインストールできるようにせねばならないのですが、そのためにはあといつくかのステップが必要になります。

2.1 Appセットアップ

まず、自分のAppを申請し、クライアントIDやシークレットなどのクレデンシャルを取得します。https://api.slack.com/appsでCreate an Appボタンをクリックしてください。

このフォームにはいくつもの欄があり少しわかりづらいのですが、スラッシュコマンドのbotには次の3つが最低必要になります。

• Basic Information (at https://api.slack.com/apps/YOUR_APP_ID/general)
• OAuth & Permissions (at …/YOUR_APP_ID/oauth)
• Slash Commands (at …/YOUR_APP_ID/slash-commands)

2.1.1 API Keyを.envファイルに保管

ここで取得したClient ID、Client secret、Verification tokenは .env ファイルに別に保管してbotのメインのコードから切り離すことを推奨します。gitを使う場合は、このファイルを .gitignore ファイルに付け加えるのを忘れずに。

SLACK_CLIENT_ID=12345XXXXX.09876XXXXX 
SLACK_CLIENT_SECRET=535d2f9....
SLACK_VERIFICATION_TOKEN=42P829U...

2.1.2 Foremanを使う

他にも手段はありますが、Herokuにデプロイするために私はNode Foremanを使っています。Foremanを使うには、npmを使ってglobalフラッグでインストールしてください。

$ npm install -g foreman

アプリケーションの Root に .procfile を作成し、この一行を加えます。

web: node index.js

index.jsを実行するには node index.jsの代わりに次のコマンドを使います。

$ nf start

2.2 ユーザの認証

Slackは認証にはOAuthを使っています。実際には自分でOAuthを実装しなくても、Slack ボタンを使えば簡単に認証できるようになっています。

公式のドキュメンテーションのダイアグラムに手を加えて、流れをわかりやすくするためにGIFアニメーションにしてみました。

ここでの実際のフローは次のようになります。

1. ウェブページを作成し、認証ボタンを置く。ユーザがボタンをクリックするとパラメータがSlackに送信される(ユーザは認証ページにリダイレクトされる)。
2. Node appには、SlackからGETで10分だけ有効な仮のコードが送られる。
3. アクセストークンを得るために oauth.access API使い認証コードをPOSTする。Node app側から`200 OK`を受け取り次第、このプロセスが完了。
4. オプションとして、このトークンを使ってSlackの他のAPIにもアクセス。例えば、認証後、ユーザをhttps://team-name.slack.comにリダイレクトするなど。/

2.2.1 Slack ボタンの設定

Slackボタンを使うには、まずウェブページを作成してください。私の場合はこのNode Appとは切り離した別のHTMLページを作成し、GitHub Pagesにホストしました。

次にボタンを設定しましょう。 https://api.slack.com/docs/slack-button に行き、Add the Slack button までスクロールして下さい。

このボタン作成ツールのCommendsのチェックボックスをチェックします。

上で示したフローの４を実行したい場合は、このGETパラメータを下のように変更します。

<a href="https://slack.com/oauth/authorize?scope=commands+team%3Aread&client_id=your_client_id">

ここでscopeに着目してみてください。commandsの他にteam:read(コロンは%3Aとエスケープ)が必要になります。詳しくはOAuth scopes on the Slack API docsで。

2.2.2 トークンの発行

さて、Nodeコードに戻りましょう。仮のコード(req.query.code)をGETで取得するためにまたExpress.jsを使います。

何でもよいのですがここでは/slack routeを使いましょう。この場合ngrokのURL は http://71f03962.ngrok.io/slack のようになります。Slack App設定ページ（https://api.slack.com/apps/YOUR_APP_ID/oauth）の、OAuth & Permissions セクションにある、Redirect URLの欄にはこのURLを設定してください。

仮のcodeを取得されたら、それを自分のAPIクレデンシャルとともにPOSTで送って、トークンと交換します。POSTするためにここではNode.jsのHTTPリクエストクライアントである、Requestを使いましょう。

$ npm install request --save

仮のcodeを取得し、それをtokenと交換するコードが下になります。

const request = require('request');

app.get('/slack', function(req, res){
 let data = {form: {
   client_id: process.env.SLACK_CLIENT_ID,
   client_secret: process.env.SLACK_CLIENT_SECRET,
   code: req.query.code
 }};

 request.post('https://slack.com/api/oauth.access', data, function (error, response, body) {
   if (!error && response.statusCode == 200) {
     // おしまい！
     // ここからはオプションでチーム情報を取得
     let token = JSON.parse(body).access_token; // Auth token
   } ...

2.2.3 オプショナル： ユーザをチームURLにダイレクトする

認証が済んだらそこで終えてもよいのですが、この画面でユーザを置き去りにするのはあまりよいUXとはいえないので、チームページにリダイレクトしてみましょう。

リダイレクトURLのサブドメインとなるチーム名はteam.infoAPIで取得できます。

このAPIを使うにはトークンが必要なので前述のコードでの、トークンにアクセスする箇所に下のコードを追加します。

...
request.post('https://slack.com/api/team.info', {form: {token: token}}, function (error, response, body) {
 if (!error && response.statusCode == 200) {
   let team = JSON.parse(body).team.domain;
   res.redirect('http://' +team+ '.slack.com');
 }
});

これで API からチーム名(team.domain)が返されました。最終的にこれを使ってチームURLにリダイレクトしてできあがり！

このチュートリアルでは簡素化したコードを使いましたが、全ソースコードはGitHubで見てみてください。

2.3 サーバにデプロイする

最後にデプロイしておしまいです。APIクレデンシャルのenv vars設定を忘れないように！私はHerokuを使っているのですが、Herokuの場合、heroku configコマンドを使います。例えば、heroku config:set API_KEY=123456というふうに設定してください。

Slackの設定で画面で指定したngrok URLを、デプロイ先のURLに変更するのもお忘れなく。

さて、プロセスが少し面倒ですが、コード自体は簡単だったと思います。もし何か面白いボットを作った際にはぜひ教えてくださいね！

HTML5 Conference 2016の展示ブースでお届けしたカンファレンス ラジオコーナー。Increments及川卓也さんとヤマハ河合良哉さんがゲストに来てくれた「地方で日本で働く・海外で働くの話」を完全版テキストの後編をレポートします！

日本と海外の違いの話

前編に引き続き、ゲストはIncrements及川卓也さんとヤマハ河合良哉さんです。

「実際に今年海外に行かれて困ったことや、こういうところが違うの？とか、びっくりしたエピソードがあればお聞きしたいのですけれど、何かギャップとかありますか？日本のカルチャーと（比べて）」

「ギャップですか？」

「はい。例えば、僕が一番気になるのは食べものとかです。海外の姿は想像ではあるんですが、日本だとそこらへんに自動販売機やらコンビニやらがあって、買いたいジャンルのものがすぐに手が届くところにいっぱいある。たぶん海外というか、今お勤めされているサンフランシスコは土地も広いこともあるし、そういうのはないんじゃないかなって思って。

「そうなんです。そこおっしゃる通りで、日本に帰ってきていつも便利だなって思うのがコンビニエンスストアの存在なんですね。アメリカにもコンビニエンスストアはあるんですけど、そこに陳列されているものが全然違ってるんです」

「日本だとちょっと小腹がすいたなって思うとおにぎりだったり、サンドイッチや菓子パンは大体100円とか200円くらいで手に入るというのが大体じゃないですか。向こうに行くとおにぎりとか、サンドイッチとか…おにぎりはないにしてもサンドイッチとかは結構な値段しちゃったり。買って食べると、えっこれすごいまずいみたいなのがあったりして。気軽に買えないんですよね、怖くて。逆にがっかりしちゃうことがあるので（笑）」

「こっちで買うような気持ちで、サンドイッチ買うっていうことはできないんですね」

「やめたほうがいいかなと（笑）。そこは日本に帰ってきてすごい便利だなと思いつつ、便利すぎて日本に帰ってくるといっぱい食べちゃうんで、夜寝るときなんか胃がもたれてるなとか」

「なんかアメリカのそういったコンビニにとかで売ってるやつって、見た目からしてまずそうですよね」

「そうですね」

「見た目あまりこだわらないじゃないですか」

「こだわらないですね」

「こだわるときはなんかカラフルな感じになっていて、これはこれで食べたらまずそうな感じだなって（笑）」

「本当M&M’sの配色の感じですよね。もうすごい赤とか、すごい黄色とか」

「なんか脳の奥の方でこれ食ったらダメだよって、自分に語りかけてるようなものしかないんですよね（笑）」

「そうですね（笑）」

「色に対する感覚が違うんですかね？」

「原色が好きなんじゃないですか？知らない（笑）」

「原色系本当多いですよね。例えば食べ物の話じゃないですけど、MicrosoftのWordとか開いて、1番最初に図形とかパッと入れるとすごく緑の色が出てきたりするわけですよ。これすごい昔から不自然だなって思ってたんですけど、アメリカのそういう食材とか見ると、なるほどなって逆に納得しちゃって（笑）」

「そういうことですか」

「おそらく。だから色に対する感覚が、日本人と違うところは間違いなくありますよね」

「やっぱり、普段慣れ親しんでいる色がそういう配色のものが多いという環境による要因なのか、人種による気質がそうなっているのかというと、どっちなんでしょうね？それはわからないですね」

「どうなんでしょうね」

「とりとめのない質問をしてしまって、今は反省しています」

年齢が違う人とのコミュニケーション

「この後、僕らはどこにいく感じになるんですか？」

「えっとですね…」

「別に早く終われって言っているわけじゃないですよ。まだ全然話してもいいんだけど、この議論はどこに流れ着くのかなと思って（笑）」

「本来僕がここでやらなきゃいけないのは、ゲストのお二方の面白い話を伝えないといけない」

「今ね、加藤くんが面白い人になっているから（笑）」

「ごめんなさい。では、みんなが聞きたいんじゃないかなって思ったことを及川さんに質問していいですか？」

「いいですよ」

「去年転職されて大きく環境が変わったと思うんですけど、お若い方が多い会社に入られたじゃないですか。年齢が違うと、共通の話題だったり当時流行っていたものも違うと思うんですけど、年齢が違うことでコミュニケーションが難しい部分があったりするんでしょうか？」

「たぶんね、みんなが気使ってくれるんですよ。だからあまりそういうので困ったことはないですね」

「なるほど（笑）」

「長老が入ってきたという感じで、一生懸命おじいちゃんから聞いた話とかを思い出して話してくれるから」

「皆さんとは飲みに行ったり、遊びに行ったりするんですか？」

「そうですね。でもね、真面目な話わからないというか、今同じ世代でも趣味が違ったら全然話通じなかったりしません？昔って、視聴率30%取ったようなドラマがあったらみんなそれ見てるとかってあるけど、今は高校の時見てたドラマで全員に絶対通じるものってなかったりすると思う。趣味が違った人とはあまり通じないっていうことは、普通だったりするんじゃないかなって思うんですよね」

「なるほど」

「あまり困らないし、わからなくても別に気にしないし、そこで教えてもらえればいいかな。それ何？って言って、あーそんなのあったんだ、その頃俺何やってたかなー？みたいな感じで。で、気にせず僕、昔の話ガンガンしますから（笑）」

「素直にやり取りできるのってすごく大事ですよね。そういった謙虚さってすごいです」

新しい技術に対する取り組み方の違い　

「僕は仕事が変わって、学生とやり取りすることが多くなったんですけど、彼らってどんどん新しいことをやろうとするのに物怖じしない子が多いなと思って。新しい言語が出たら、『よしやってみよう！』ってやるんですけど、僕だと『これいつまで使えるのかな？』とか、『実際これ覚えたとして何の役に立つんだろう？』とか考えてからやっちゃうんですよ」

「彼らは、『それ面白い使ってみよう、動いた！』って。で、どんどんやっていくっていうので、なんか自分歳をとったなって感じることがあって。一概にそういうわけじゃないですけど、年齢が離れれば離れるほど物事に対する取り組み方って変わってくるのかなって思って」

「でも、技術がずっと使われるかどうかなんて全然わかんなくって、僕だって大学時代に使ってたのってFortranですけど、今Fortranなんて全く忘れてる。10年くらい前Web系のやつやっていた時はPerlだったけど、Perlもほとんど覚えてないし、その時にFortranが自分の30年後、40年後も使ってるかなんて考えたこともないし」

「Perlの時だって別にそこまで考えたわけじゃなくて。そこはあまり気にしないし、逆に、大きく内容が違うならともかく、技術ってどこかで関連性があるから一つの技術を覚えた時に、ここの応用だとか、これはここでいう何だっただろうってことを考えるだけで飲み込みが早いってことは多いと思うんですよ。プログラム言語じゃない話をすると、僕OSを作ってたわけですよね、Microsoft時代に」

「はい」

「今Webブラウザって結局はOSなんですよ。中でやっているものっていうのは、普通にスケジュール管理みたいなものもあれば、スレッド管理みたいなものもある。メモリ管理みたいなものもあるし、ガベージコレクションどうしようとかっていうところとかって中で普通にガチガチ入ってたりするわけですね」

「そうすると、ブラウザがOS化してくっていう流れになった時に、OSを作っていた時のいろんな知識だとか経験って役に立つんですよね。たぶんそれプログラム言語でも一緒ですし、ネットワークプロトコルでも一緒だし、なんでも同じだと思うんですよ。例えば、ネットワークって昔TCP/IPが流行る前とかっていうのは、普通にシリアルコネクタRS232Cっていうのがあったんですよ」

「はい」

「その上で、パソコン通信のためのやり取りだとか、ファイル転送のプログラムがあるわけですよ。Kermitって言われているのがあって、僕はKermitをあるプラットフォームに移植したんだけれども、そこでやっているプロトコルのいろんな手順で、結局はその後TCP/IPで見た時に同じ様なことをやっているんですよ」

「結局はウインドウ制御みたいな話が出てきたりとかっていうのは、基本は一緒なんですね。ヘッダーがあってトレーラーがあってだとか、あとはチェックサムだかなんかをつけて、ちゃんとそこのところのデータの妥当性をチェックしてますみたいな当たり前のところっていうのは、どんなプロトコルになったってそんな変わらなかったりするんですよね」

「なので、一旦覚えたってやつが完全に無駄になることはないと思うんですよ。そのままその技術が使えるかっていうとそれはこの世の中だし、これだけ技術が早いんで、それは期待しないほうがいいとは思うけど、なんかで流用できるし、生きてくるんじゃないかなと思います」

「なんかこれエラー発生しましたけど大丈夫ですか？」

「これは…よくないエラーですね」

「じゃあ、僕らは会場にいる人に語りかけましょう。会場限定！」

「YouTubeの配信の方が今壊れてまして」

「配信の方は申し訳ないです」

「聞こえてないですけどね、配信の人には（笑）」

「そうですね（笑）」

「河合さんはなんかそういうのないんですか？僕はいいことばっか言っちゃったけど、こういうのを見て、その技術には取り組んだ方がいいかもしれないけど、それはちょっと流石に慎重になった方がいなって思うようなものとか」

「まだ僕はおそらく経験が浅すぎていっぱい取り込んでる方だと思っているので、そこまでのところはないですけど、おっしゃった通りです。1つ学んだことっていうのはそこで学んだものが終わったとしても死ぬわけではなくて、必ずどこかで生きてくるっていうことが所々感じるとこはもちろんある。だからやっぱり物怖じしてやらないというよりは、やってしまった方が面白いんじゃないのかなっていう気はします。私事をお話しするんですけど、このWebBluetoothを始めたのは1カ月か2カ月くらい前なんですよ」

「そうなんですか」

「面白そうだなっては思っていたんですけど、やれる機会があまりなくて、まあちょっとやってみようって始めてみて、もちろんまだGoogleのChromeしかおそらく対応していないので、このあと使える技術かどうかなんてわからないわけなんですよ。なんですけど、やっぱり面白いからやってみよう感じになっているので」　

「そうそう！だからその技術がなくなっちゃうっていうことを恐れている人は、会場にもいたんですけど、あんどうやすしさんっていう人がいるんですね。知っていますか？」

「はい！」

「彼ね、今日ね、引っ張り出したっていうウエーブ(Google Wave※)のTシャツ着てきてましたから。ウエーブ本出したらウエーブがシャットダウンすることになって、シャットダウンのアナウンスがあった数日後に出版になったっていうね（笑）。人生で一番不幸な人みたいな。なんか彼が取り組んだ技術はだいたいdeprecateされるっていうDEATH NOTEの生き証人みたいな人がいるんです。でも全然恐れていないで、いろんなことどんどんやってますよ」

「なるほど。これからはそういう姿勢をとっていった方がいいことが多いかもしれませんね。学生のやり方を見て僕がいいなと思ったのが、Webの質問サイトとかに質問をたくさん書いていたんですよ。それが1個2個じゃなくて10個20個とかすごく書いていて、調べて分からなかったらすぐに聞いてどんどんやっているんだって思って」

「まとめたものがあったらまさしくQiitaとかに書けばいいし、そうすると最新の技術が出てきた時に、早めにキャッチアップできてQiitaみたいな記事が書けると、みんなに注目されて界隈で目立てるというか、そういうプラス面があるじゃないですか。その姿勢ってすごくいいなって思いました。スモールスタートというか、物怖じするんじゃなくて、面白そう、ちょっとやったらできるんじゃないか、頑張ってやってみよう、わからなかったら周りに聞こう、まとめたらアウトプットしようみたいな、そういうエンジニアになっていくのがいいんじゃないかって」

「でも技術者って、基本面白いからその技術に取り組むんじゃないですか？例えばArduinoだとかRaspberry Piとかも、今でこそIoT的に使えるかもしれないけど、最初はただの電子工作じゃないですか」

「いわゆるおもちゃみたいな位置付けだったんですよね」

「すべての技術はおもちゃから始まるんですよ。僕それもうずっと言っていて、要はイノベーションのジレンマっていう話あるじゃないですか？あの破壊的イノベーションっていうのは、基本的にその時にその業界において、ほとんどおもちゃって思われているやつなんですよ。メインフレームがあった時に、僕がいたDECって会社が作っていたミニコンっていうのは、ほとんどおもちゃみたいなものなんですね。ミニコンとかがある程度出てきてダウンサイズが見えた時にもうワークステーション、さらにそれ飛び越えてパソコンなんておもちゃなんですよ」

「当時のNECの98シリーズを作った時に、おそらくNECの98をやれって言われていた技術者の人は、メインフレームをやっていた時に、そこに部隊異動になったら勘弁してくれって思うわけですよ。ほとんどおもちゃって言われていたのが、あっという間にメインストリームの技術を追い越していくっていうのが破壊的イノベーションなんですね。基本おもちゃっていうところで、これ面白いっていうのが実は人が集まってきて育っていくと、それがメインストリームになって、今までの事実を置き換えていくということが起きているんですよ」

「みんなが面白いって思っているやつとか、さっき言った生き残るかもっていうのは何かあると。生き残るかもしれないっていうのは、確率論でいうとあるかもしれないですよ」

「そこにいろいろ面白い展示がありますけど、WebのMIDI関係今一番面白いなって思っていることってどういうことですか？」

「面白いなって思っていることですか？」

「さっき及川さんが、空間の？概念がWebで表現できるって、そしたら音もその空間、例えばちょっと動いたらそっちから聞こえるっていうそういう表現ができたりっていう風になっていくんでしょうか？」

「この間Chromeの方に実装されたJUMP(※)っていう、Googleの出している専用のプラットホームでしか見られない映像でしたっけ？音響をWebブラウザ上で再現できるようになっていて、そのJUMPでフォーマットで録られた音声は3Dの音響でちゃんと聞けるっていう状態になっていたりします」

「もうそういうことができる時代になっていたんですね」

「そうですね。だいたい音って、結構最初は取りかからないんですよ。最初は映像が入って、目で見る方が完成し出すと、音ができるみたいな。WebオーディオとかMIDIもそうだったんですけど。Canvasが動くようになって、WebGLが動くようになって、じゃあは次は音だろってみたいな流れになるわけですよ。音ができると、その次は3Dだという話になるわけですよね。CanvasからWebGLになったみたいに。今その流れがきているかなって感はありますけどね」

「なるほど」

「最近WebVRとか言ってWebブラウザ上でVRができるようなフレームワークができていたりするんですけど、そこは面白いかなっていう気はします」

• Google Wave：過去に米グーグルがサービス提供していたコミュニケーション及びコラボレーションツール。2010年5月にはサービスを一般公開したが利用者が増えず、同年8月4日に開発中止を表明。サービス自体は2012年4月末まで継続された。
• JUMP：グーグルが提供するVRコンテンツ作成システム

まとめ

「この後13時からセッションされるんですよね？」

「そうですね。13:20ですね、そろそろ」

「そちらの方で今のような話とかも？」

「そうですね。まさに今頭の中でそこで話す内容ちょっと話しちゃったな、みたいな。どうしようみたいな感じだったんですけど（笑）」

「今ここで先にお話ししてしまったかもしれませんが、その話も聞けるということなので、ぜひご興味ある方は河合さんのセッションをご覧になってみてはと思います」

「よろしくお願いします」

「準備のお時間もありますよね、すみませんでした」

「いえいえ、13:20からなんで大丈夫です。おそらくまとめをするとなると、とりあえずやってみろっていうことですよね。口で言う前にとりあえず手を動かしてみろと。それが自分を作るっていう感じなんですかね？」

• 河合さんの講演動画はこちらからどうぞ！

「純粋に面白いんじゃないじゃないですか？学生さんもきっと面白いと思ってやっているんで。逆に言うと、なんで加藤さんやんないのかなっていう（笑）」

「なんかちょっとひねくれているんでしょうかね？」

（笑）

「ごめんごめん、いじめたかったわけじゃないから（笑）。元気出そうよ！なんかツラいことあった？」

「いえ、大丈夫です」

「今日夜行のバスで福島から来てるんですよ。おそらく疲れてらっしゃる」

「なるほど」

「すみません、多大なフォローをいただきありがとうございます！」

「いえ、とんでもない」

「すみません、スピーカーを入れていただいた方もどうもありがとうございました。この辺りで、第1回目は終了したいと思います」

「ありがとうございました！」

ラジオブースで放送した全ての内容を動画で公開！

放送1回目だけでなく、ラジオブースで放送した全ての内容を動画でも公開中です。「地方で日本で働く海外で働くの話」は、動画の[3:03:38]-[3:50:50]です。

• 「地方で日本で働く・海外で働くの話」 by DJ KATO [ゲスト：及川卓也さん、河合良哉さん]
• 「ハードウェア楽しいですよね」 by DJ KATO [ゲスト：中川友紀子さん、羽田野太巳さん]
• 「ハートブレイクカフェ」 by DJ KATO & 物江修さん

HTML5 Conference 2016の展示ブースでは、私DJ KATOによる特別ラジオをお届けしておりました。
すごく面白いので、Increments及川卓也さんとヤマハ河合良哉さんがゲストに来てくれた「地方で日本で働く・海外で働くの話」を完全版テキストで書き起こしてみました。ぜひ、カンファレンスレポートの番外編としてお楽しみください！

まずは、自己紹介をお願いします

「海外にも地方にも行っていないのに、なぜか呼ばれています。Increments株式会社の及川卓也です」

「ヤマハ株式会社の河合良哉です。よろしくお願いします」

「地方にも海外にも行っていないというお話がありましたが、環境が大きく変わったという面で共通点があると考え、広い意味での定義としてとらえてほしいです」

「はい」

「まず、及川さんは…」

「ちょっと待って。お前は誰だという感じだから（笑）」

「あ！僕ですね！私、会津若松にあるIT系の会社に勤めております、加藤と申します。DJ KATOと名乗って、こういった司会をやらせていただいてます。どうぞよろしくお願いします」

「イエーイ！」

及川卓也さんの基調講演のお話

「先ほど基調講演を終えられたばかりですよね？（基調講演の後で）時間ありました？」

「1つセッションを聞いてきましたよ、React.jsの難しいやつを。途中で抜けてきちゃったんだけど」

「結構技術的な話を聞いてきたんですね。及川さんはどのようなお話をされたんですか？僕は聞きに行けなかったので…」

「聞いてなかったんだ！（笑）」

「準備をしていたので…」

「そうですか、ご苦労様です。僕は何の話をしたんだっけ？Webの話をしたんですよ。一応Webのカンファレンスなので。なんか飲んでもいないのに酔っ払ってるみたいですみません（笑）」

「Webは3つの側面がありますねという話で、アプリケーションの技術としてのWebとメディアとしてのWeb。あとはインフラ技術としてのWebで、それぞれいろんな局面を迎えている。でも今後も投資して、さらに発展させていかなきゃいけないですね、というすごくいい感じの話をした気がします」

「なるほど。そういった広い視点でのお話をされたという感じですね」

？？？？？？？？？？？？？

「ごめんなさい！緊張してしまって、わけのわからないことを言って申し訳ないです」

「基調講演を聞いていないのに申し訳ないのですが、プラットホームとしてのWebって、例えばどういう変化が起きてて、これからどうなるということなんでしょうか？」

「ずっと起きている話で、要は機能的にもどんどん追加されてきていると。で、ある程度WebのAPIってそこそこ揃ったようには見えるんだけれども、実はWebって古くからコンピューターディスプレイがあって、キーボードがあって、マウスがあるというところから、やっと今スマホみたいなところになってきている。そういった今までのデバイスやメディア系のものを超えたものに、これからはなっていくでしょうという話をしました」

「はい」

「ちょうど私の前にW3Cで慶応大の中村修先生が、HDRの話をされていました。要は輝度の部分をJavaScriptでWebからコントロールできたならば、映像が大きく変わるだろうって話を少しされてたんです」

「それにインスパイアされて、音の部分もaudioタグがあって、Web MIDIがあって、Web Audioもある。そんな状況ですが、実は2009年という早い段階からGoogleは考えていたんです。空間音響みたいなところで、要はVRのサウンド版。どこの位置にいたならばどういうふうに音が聞こえるはずだということを、拡張機能として公開しているのがもうあったりするんですね」

「はい」

「今までの普通にコンピューターディスプレイやスピーカー、ヘッドホンだけでは想像もつかなかったようなところまで、実はそのアプリケーションとしての可能性もまだまだ可能性がありますねって話」

「あとはWebAssemblyの話で、もはやそうなってくるとJavaScriptとHTMLとCSSとは全く違うアプリケーション開発技術も出てくるから、楽しいと同時にいろいろと考えなきゃいけないねっていう話をした感じです」

• 【基調講演】Webはオープンな分散型OS、アプリケーション・メディア・プラットフォームとしてのWeb技術─中村修教授、及川卓也氏が語ったHTML5の未来

「大丈夫ですか？これで今回のテーマにだんだん近づいてきます？」

「まだ1mmも近づいていないんですが、話の流れを大事に進めていこうと思います」

「了解です、任せます。ちょっと不安になりました（笑）」

河合さんに聞いたWeb MIDIのお話

「河合さんはWebとMIDIに関してお仕事上関わりがあると思うのですが、その方面で、今までできなかったことが今後できるようになるものにはどのようなものがありますか？」

「この隣にWeb Music Developers JP(※)というコミュニティーが主催している展示会場があって、そこで缶が鳴っていますけど、実はMIDIで動いていたりするんですよ。今まさに及川さんがおっしゃった、プラットホームとしてのWebのところでMIDIも入ってくるのかなと。外部のExtarnalのデバイスとブラウザが直接つながると、そこで起こったことは僕が言うのもすごく手前味噌なんですけど、楽器業界がWebの業界にどんどん入ってきたと言えるんじゃないかと思います」

「楽器が…Webに？」

「これも手前味噌なんですけど、ヤマハがrefaceというシンセサイザーを去年出したんですね。そのシンセサイザーは、普通のシンセサイザーだと大体ボイス、音色のパラメーターを保存するのに楽器に載っているメモリに保存するんです。だけど、そのrefaceというモデルに関しては保存する部分がなくて、どうするかというとWeb MIDIで接続をして、ブラウザから直接Cloudの方に保存する。そういうことで少し形が変わったかな。Webをストレージとして使うというような考え方に移ったと」

「なるほど」

「もう少し話すと、プラットホームとしてのWebという意味で、僕も昔から思っていて、やっぱりブラウザというとディスプレイがあってキーボードが目の前にあって、そこから外にあまり出ないよみたいなイメージがあると思うんですけど、それがまずMIDIで楽器の業界で外に出ましたと」

「はい」

「今ですね、GoogleのChromeにしか搭載されていないのかもしれないですけど、WebBluetoothっていうのがあって。このWebBluetoothというのを使うと、今度Bluetooth SMARTって呼ばれる世の中でいうBLEというやつですね。BLEの機器に直接接続ができるんですよ」

「はい」

「あそこにM&M’sが入ったおもちゃみたいなのがあるじゃないですか。あれ実はBluetoothで接続をして、ボタンを押すと中に入っているM&M’sがババババーッと出てくるおもちゃなんですけど、ああいうものが作れるようになるわけです」

「なるほど。これたぶんラジオで聞いている人にはちょっと…」

「見えないですね（笑）」

「見えづらいかなと思うんですけど、このすぐ隣にWeb Music Developers JPさんのブースがありまして、そこにWeb MIDIといろいろなものがあって、PCとMIDI楽器なんでしょうか？あれは？」

「そうですね。真ん中に並んでいるのはMIDIを使ったコントローラーで、その次に並んでいるのがライブビーツっていうブラウザを楽器にしてしまうような作品です。で、その隣にあるのがシーケンサー、これFirebaseを使って、いろいろな人と進行しながら音楽を作っていくハッカソンでハックしてもらった作品が展示されています。その隣には、これもWebの技術を使って照明をコントロールしようというもので、照明がコントロールされています」

「照明を、MIDIで？」

「はいそうですね」

「あ、そうなんですね」

「MIDIってミュージカルインストゥルメンタルデジタルインターフェイスという名前なんですけど、そのプロトコルを別の用途で使ってしまっているということですね」

「つまりMIDIって、タイミングだったり音色だったりという概念があって、それを表示のタイミングだったり、どの色にするかに置き換えて命令を出すという感じなんでしょうか」

「そうですね。おっしゃるとおりでございます」

「なるほど」

「その隣に並んでいるのがMIDIに関係ないですけど、WebBluetoothで接続されているお菓子が出てくるおもちゃです」

「さっき河合さんがブースを作っている準備段階をお見かけしたんですけど、M&M’sが勝手に動いてチョコレートをバラバラと吐き出しているのを見ましたけど、あれもMIDIでやっていた？」

「いや、あれはMIDIとは関係なくて、Bluetoothで接続をしてBluetoothで動かしています。もう一回出してみます。……あんな感じで」

※筆者注：↑Bluetoothで動かしているとさっき河合さんが言ってました。話を聞いていない。

「今出てる！」

「ここから接続しているんですけどね、全然見えないですよね（笑）」

「今まではMIDIというと、鍵盤があってそれをUSBでPCに繋ぐと、そのPCのソフトで楽器が鳴る。それは専用のソフトがあってそのソフトが鳴るイメージだったものが、今はWebブラウザがあればそのWebブラウザの表示の機能でMIDIのUSBに繋ぐだけで全部音が鳴ったりだとか、専用ソフトになるようなことが全部出来てしまうという状態になっているということですね」

「そうですね。それを楽器以外のもので使うことのも可能なので、そういったとこに応用していくっていうのもありかな」

「なるほど」

＜参考情報＞

• Web Music Developers JP のgoogleグループ
• reface

河合さんがサンフランシスコに拠点を移されたお話

「ちなみに今年サンフランシスコの方に拠点を移されたということで、それはどういった目的で移動されたのですか？」

「夢にも思ってもなかったのですが、ありがたいことに駐在の司令を出してもらえ、今年1月下旬からアメリカに住んでます」

「日本でのWebのMIDIの普及と、海外でのWebのMIDIの普及には違いがあるんでしょうか？ご自身で決めていったというわけではないという話だったので、そういう依頼があったわけではないと思いますけど、海外に行ったことで日本のWebMIDIの盛り上がりと、海外の盛り上がりの違いがあったらお聞きしたいです」

「基本的に僕がまだ全然知らないだけかもしれないですけど、日本で今展示しているのがWeb Music Developers JPなんですけど、ここが異常に盛り上がっている感があるというのが僕の印象です（笑）」

「海外にWebでミュージックをする方たちがいるかなというと、あまりいないかなという気がしています。とはいえ、音楽で盛り上がっているというコミュニティはあるみたいで、その方々はいろいろなことをやっているみたいです。例えばWebGLを使って音楽と組み合わせて作品を作ったり、そういうのをアメリカでよく見かけることがありますね」

及川さんが海外で仕事をしていた話

「及川さんは海外で勤務された経験もおありなんですよね、いつ頃でしたでしょう？以前働いてらっしゃったのは日本DEC(※)にいらした後、Microsoftで働いていた時に海外にいらしたと…」

「そうです、よく知っていますね！」

「ネットで調べたら出てきました」

「その前に加藤さん声ちっちゃくない？」

「すみません、気持ちの萎縮が声に出ていたのでちょっと張ります」

「あと、マイクは柄の部分を掴んだ方がいい気がするよ（笑）」

「はい、こんな感じでよろしいでしょうか？（笑）」

「はい、ぜひ元気よくいきましょう！」

「私今から20年ちょっと前にまだMicrosoftが小さかった時ですね。Windowsのエンタープライズ版のWindowsNTっていう今のWindowsなんですけど、それの元のバージョンを作った時に1年くらい派遣されました。シアトルというか、郊外のレドモンドにある今Microsoftの本社があるところに行きました」

「その時に、日本から海外に行かれたということで、暮らす環境だったり仕事のやり方だったり、すごく違いを感じたのではないかと想像するのですが、その辺りはどうでしたか？」

「そうですね、だいぶ違いましたね。しかも当時ってインターネットまだないんですよ。あるんですけど、Webはまだ作られていない時だったんですね。ちょうど私がレドモンドにいた時に、Webっていうものがあるらしいぞというので、NASAの宇宙の写真とかを最初に見たのを覚えているくらいなんですよね。なかったんですよ」

「つまりどういうことかというと、行く前に現地の情報とかそんなに分かんなくて、ニフティサーブという今のニフティの原型があり、そこがアメリカのコンピュサーブっていうパソコン通信にゲートウェイで接続きたので、そっちの方のフォーラムに入ったりしていろんな情報を入手したりしていたんですね。また逆に、アメリカ勤務していても、日本の情報がほとんど入ってこないんですよ」

「そうなんですね。

「なので、どっちがいいかというと正直分からなくて、昔は昔でそういった現地に行かないと分からないものを、現地に行って分かる面白さとか醍醐味があったんですけれども、不便といえば不便でした」

＜参考情報＞

• 日本DEC：日本 ディジタル イクイップメント株式会社
• ニフティサーブ：NIFTY-Serve、のちにNIFTY SERVE、1987年から2006年までニフティ株式会社が運営していたパソコン通信サービス。
• コンピュサーブ：CompuServe、アメリカのパソコン通信会社。

インターネットで知ることと、現地に行って知ることの話

「なるほど、それは良し悪しあるんですね。今は狙った検索ワードを入れれば、大抵のものはヒットして分かるという状態になっているじゃないですか。それは日本にいても海外にいても見れるので、ネットで繋がっていれば一緒に仕事もできるし、知らなかった情報もすぐネットでキャッチアップできるような環境に今は変わってきている気がする。なので、海外に行って困るというのは前と比べると少なくて済む状況になってきているのではないかと思うのですが」

「そうですね。今僕も向こうにいるわけなんですけど、インターネットから大体情報が入ってきますし、すごく変わったかなと思うのが、テレビもすごく変わったと思うんですよ。家にソニーさんが作っているnasne（ナスネ）™というサーバーを、日本の自宅に置いているんですね。そうすると、海外からも日本のテレビ番組が普通に見れるんですよ」

「撮りためておいて、普通にそれが見れるという感じなんですか？」

「そうですね。撮りためもできるし、リアルタイムで見ることもできたりするので、アメリカにいるのに日本のテレビ番組を見てたりすることもあったりして、その辺は本当に情報がすごく入って来やすい。自分で取りに行こうと思えばいつでも行けるという状態になっているというのは間違いなくあるという気はするんですけど、1つ僕が結構思うのは、情報ってやっぱり情報なんですよ」

「はい」

「重要なのって情報の周りにある雰囲気だったり、文化的な背景だったり、そういうところが結構重要だということを僕は思っているんです。情報は入ってきやすくなってきたけど、ディテールのところは現地に行かないと分からないかなという気がしているんですけど、及川さんその辺いかがでしょうか？」

「そうなんですよね。英語圏でアメリカにいると、インターネットで得られる情報と、現地で得られる情報っていうのはもちろん差はあるけれど、そんなには多くないんですね」

「はい」

「ただ他の国に行った時に、我々が現地の言葉を知らなかったりすると、どうしても英語の情報に頼るじゃないですか。もしくは日本語の情報に頼ると。例えばヨーロッパに行った時に現地の人から教えてもらったのは、トリップアドバイザーの情報でいい店だって言われて行くわけですよ。それはアメリカ人のテイストにあってる店がレコメンドされるだけだよってはっきり言われたんですね」

「なるほど（笑）」

「だから、本当に現地の人が行くところで推奨している店が、そこに引っかかるとは限らないということを言われたから、やっぱりインターネットで得られる情報と現地の本当の情報は必ずしも一致していないことは覚えておいたほうがよくて。ただ、今ちょっとトリップアドバイザー、最近元Googleの僕の友人が日本法人の社長になったんですけど」

「そうなんですか（笑）」

「まあ、それはいいんですが（笑）」

「だけれども、逆に言うとそれはそれで便利なんですよ。なぜかというと、トリップアドバイザーでいいって言われているのは確実に英語が通じたりだとか、アメリカ人と日本人のテイストはだいたいあっているんで、そんなに間違いはない」

「ただ、やっぱり今言ったみたいに、本当に現地で価値があるって言われているものが英語で情報として流通しているかどうか分からないところはあったりするんで、やっぱりネットの情報で便利になったと思う反面、ネットだけでいろんなところに行こうとしたら、実は現地でしか味わえない醍醐味だとか、本当に大事なものを見失ってしまう可能性はあるかもしれないなって思いますね」

「そういう側面もありますね」

「例えば、逆にふっていいですか？　地方に東京から移住した加藤くんに聞きたいんですけれども」

「はい」

「要は、もう日本語で普通に会津若松の情報って分かるじゃないですか。でも現地に行ってみたら全然違ったっていうようなことって、実際に暮らし始めてみてからあるんですか？」

「いくつかやっぱりありますね。そもそもあんまり店がないのかなって思っていたら、みんながWebにあげていないだけで、実際に足を運んでみるとすごく美味しい店が近くにたくさんあったりとか、そういうギャップがあったり。あとは食べログとかを見てお店を選ぶんですけど、評価が普通なお店でも行ってみると店員さんがすごく優しくてフレンドリーで、何回か行ったら一品増やしてくれたりとか、これはちょっと分からないだろうなとは思いました。それは現地に行ってこそ分かるものだなって分かりました」

「今は逆に検索すればわかるから、ネットがつながってるから、情報共有も簡単にできるだろうと思い込むのは危険なところはありますよね。その辺は会社によってやり方は違うと思うんですけど。Microsoftなんかはレドモンドに社員を皆さん集結させて、なるべく物理的に近くにいてコミュニケーションロスを減らそうとしているとどこかで見たのですが、そういう会社もあれば、Googleは逆にどこにいても仕事はできるからというかたちで、物理的に散らばって要所要所で集まって意思疎通をしていると聞きました」

「そういうスタイルや、会社さんごとにいろいろなやり方でやっていると思うんですが、1つ言えるのは以前よりも単純な情報の共有はすごくやりやすくなったので、海外にいきなり行くとなった時も、以前のような準備がそこまでいらなくなってきているのかなと感じました」

＜参考情報＞

• ナスネ：nasne、地上/BS/110度CSに対応したデジタルチューナーと大容量ハードディスクを搭載したネットワークレコーダー＆メディアストレージ

──後編は「日本と海外の違いの話」「年齢が違う人とのコミュニケーション」などの話を紹介します。

2014年10月24日、米サンフランシスコにてPhoneGap Day US 2014が開催されました。3年前から始まった本イベントですが、これまでアメリカではオレゴン州ポートランドで開催されていて、残念ながら参加する機会がありませんでした。今年は同じくサンフランシスコで開催されたHTML5 Dev Conf 2014と同じ週となった関係で、両方のカンファレンスに参加することができました。

HTML5ハイブリッドアプリ開発として幅広く使われているPhoneGapは、またの名を「Cordova」と呼ばれます。CordovaはApache FoundationベースのOSSプロジェクトで、それをAdobeが製品として出している名称がPhoneGapとなります。そのため、PhoneGap Dayの内容も、主にCordovaに関するものがほとんどです。それもGoogleやMozilla、Microsoftなどに所属するCordova開発者のスピーチが多く、とてもオープンなカンファレンスとなっています。

司会は毎度ながらPhoneGap開発チームのリーダー的存在なBrian LeRoux。PhoneGap Desktop Appの紹介などが行われました。

.@Adobe's @brianleroux kicks off PhoneGap Day 2014 http://t.co/PJqfunCgwE #pgdayus14 #pgday14 pic.twitter.com/cIiYBoSYPP

— Eric Oesterle (@erico) October 24, 2014

ハイライト紹介

CrosswalkエンジンでAndroid WearでもCordovaが動いた

Joe Bowserの「Many Webviews on PhoneGap Android」より。Intelがオープンソースプロジェクトとして進めているCrosswalk Project。これは、Chromium互換WebViewエンジンをCordovaに組み込み、ハイブリッドアプリの大きな課題であるAndroidバージョン依存や実行パフォーマンス、JavaScriptデバッグ機能の強化などを解決してしまおうというものです。PhoneGap Dayに先立ち公開されたCordova 4.0では、WebViewをAndroid標準WebViewからサードパーティ製のものに切り替える仕組みが備わり、Crosswalkの導入も簡単になりました。これを使うと、WebViewを持たないAndroid Wearにおいても、Cordovaアプリを動作させることができるとのこと。メモリーの問題等で実用ではないらしいですが、面白い取り組みです。

Visual StudioでCordova開発。次バージョンでiOSにも対応

現在プレビュー公開されているMulti-Device Hybrid Appsですが、近日中にアップデートが行われ、iOSのビルドができる機能が搭載されるとのこと。Windowsローカル環境で具体的にどうやって実現するのかなと思ってみていると、どうやらMac上にエージェントを起動し、Visual Studioはそのエージェントに対して、ネットワーク経由でリモートビルドをかけることで対応するようです。これでMonacaを使わなくてもWindowsユーザーがCordovaでiOS開発ができるようになりますね！

Ionic Frameworkの正式リリースは11月末か？

モダンなUIフレームワークとして注目されているIonic Frameworkですが、11月末ごろに正式リリースされるという話がありました。これまで1年間ずっとベータ版のままでしたので、正式リリースでどのようになるのか楽しみです。

まとめ

他にも、PhoneGapアプリのデバッグをするツールや、Mozillaが開発中の新しいWebViewエンジン、iOS 8で登場したWKWebViewの話など、PhoneGap/Cordovaデベロッパーにとって非常に面白いテーマが目白押しで、個人的にとても楽しむことができました。それと同時に、HTML5ハイブリッドアプリの世界は、CordovaというOSSフレームワークを通じて、メジャーどころが共同で開発を担っていることが実感されました。今後、PhoneGap Blogではセッションの録画ビデオを掲載していくと思いますので、ぜひチェックしてみてください。

PR: Cordovaユーザー会で一緒に最前線を探索しませんか？

PRとなりますが、このたびHTML5ハイブリッドアプリ全般の技術を扱うためのオープンソースコミュニティ「Cordovaユーザー会」を立ち上げました。この会では、HTML5ハイブリッドアプリ、とりわけCordovaの普及に向けて、実際にアプリ開発を実践されている方々が積極的に情報共有をしていくことを目的としています。キックオフ第1弾として第1回Cordova勉強会を11月5日、午後7時から開催する予定です。ぜひ興味ある方はご参加ください。

P.S. Google Chrome Apps Mobileの方に、Monacaの紹介をしてもらいました。Cordovaプラグインを開発しやすくするためのツールを作っていきます。

斉藤祐也の海外WEBテク定点観測＜Issue.14: 2014/05/01-2014/05/31＞

今月の定点観測はURLバーの改善、Object.observe()、アクセシビリティに足りないことなどを紹介します。

注目ニュースピックアップ

URLバーの改善 – JakeArchibald.com

原題: Improving the URL bar

iOS SafariではURLの表示がドメイン名になっています。(URLを表示しているエリアをタップするとURL全体を表示します。)
Google Chrome Canaryの、しかもExperimental Flagのオプションを有効化することで同様の機能を利用できるようにしています。
この機能と記事の筆者であるJake Archibald氏の『一般的なユーザにとってURLはノイズです。プロトコル、オリジン、パスを混ぜ合わせたものです。このターミナルのコマンドのようなものをユーザにそのまま送り返すUIはよいUIであると言えない。URLは共有のしやすさを失わないように、セキュリティにフォーカスしていくべきだ。』という記事の最後に書いた意見は、下記の関連リンクで様々な意見を集めています。

関連リンク:

• URLy warning – Adactio
• On Chrome hiding URLs to protect users from phishing – remy sharp’s b:log
• URLs are already dead – NCZOnline
• Do we really need to hide the URL? – FT Labs

Object.observe()を使ってデータ・バインディング革命を – HTML5 Rocks

原題: Data-binding Revolutions with Object.observe()

JavaScriptでMVCを、というムーブメントが発生し、実際のプロダクトでも利用されるシーンが増えてきています。そんな中で生まれたデータ・バインディングと呼ばれるような機能へのニーズの高まりは必然ともいえるでしょう。そんなニーズに答えるObject.observe()という機能がChrome 36ベータ版にて利用できるようになりました。このAddy Osmani氏によるHTML5 Rocksの記事では、そのObject.observe()の使いどころから、現状の多くのMVCライブラリでの解決との比較など非常に詳細にわたる解説をしています。

『なぜ』と問うことが常に最適な戦略とは言えない – Inside Intercom

原題: Asking why is not always the best strategy

『なぜ』を繰り返すことは本質的な問題にたどり着く方法だと言えると思います。しかし、HubSpotのプロダクト・デザイナであるDaniel Ritzenthaler氏は、闇雲に『なぜ』を繰り返すことは生産的ではないとしています。
記事では、より生産的な『なぜ』を問うには3つのレイヤーを意識するべきだとしています。
1つ目は利便性レイヤー。ここはある機能を使って実際に何を行おうとしているのかを問うレイヤーです。
2つ目はユーザビリティレイヤー。ここはある機能を使うとどんな結果を得ることができるのかを問うレイヤーとなります。 3つ目は結果の望ましさのレイヤー。ここでは、目的を達した後、何が変化するのかを問うレイヤーです。
Daniel Ritzenthaler氏はプロダクトに対してこの3つのレイヤーを念頭においた『なぜ』はしっかりと時間を取って考え、答えるべきであり、その時間は決して無駄にならないと記事を結んでいます。

アクセシビリティにはなにが足りないのか? – A List Apart

原題: Accessibility: The Missing Ingredient

WAI-ARIAが広くブラウザでサポートされている現在においても、アクセシビリティが必要要件とされるケースは決して多いとは言えないのではないでしょうか?
このA List Apartの記事で、IBMのフロントエンド・デベロッパであるAndrew Hoffman氏はアクセシビリティに足りていない材料は、実装の順番に対する認識であるとし、さらにコード例を通じてWAI-ARIAのroles、states、そしてpropertiesに関する簡単な実装を紹介しています。

1回で正しく – Ryan Clark

原題: Do it once. Do it right.

Webのプロダクトの多くがアジャイルを採用し、短いサイクルのイテレーションで新しい機能をリリースすることは今では珍しくはありません。
Virbのプロダクト・マネージャを務めるRyan Clark氏はそのイテレーションにひそんでいるほころびを3つ指摘しています。

• イテレーションを言い訳にしない / 次のサイクルがすぐ来るからと言って、問題を先送りにしていいわけではない。
• イテレーションの破綻 / ただリリースするだけではなく、きちんと振り返り、フィードバックを次のサイクルに反映すること。
• 中長期計画なきイテレーション / 闇雲に機能をリリースするのではなく、最中的な、あるいは中間のゴールを持って開発をすること。

記事のタイトルにある通り、『1回で正しく』できることはそうするべきです。

海外トレンドコラム

デザインをレビューする時にJason Friedがする質問 – Jason Fried

原題: Questions I ask when reviewing a design

BasecampのJason Fried氏がデザインをレビューする際に質問する事柄。
リストアップされている質問は毎回全て聞くことはないし、順番には意味はありません。自分がデザイナだったらどう答えるか、あるいはデザインを評価する立場なら、聞くべき質問を忘れていないか、優れたチェックシートになるのではないかと。

ツールを使わなくても問題ない – Jonas Downey

原題: It’s OK not to use tools

2連続でBasecampのブログ、Signal v.Noiseから紹介。こちらはJonas Downey氏による記事。
昨今フロントもサーバーもインフラも新しいツールがあふれています。それらツールの取捨選択、そしてもちろん利用することも開発者にとっては重要なタスクであると思いますが、それも時と場合を考えて。単純なHTMLとCSSのページを作るのに大仰なツールは必要なく、シンプルにできるものはシンプルに。適切なツールを適切に使いこなすことが大切です。

モバイルにおけるWebアプリケーション標準化の現状とロードマップ – W3C

原題: Standards for Web Applications on Mobile: current state and roadmap

このW3C作成のページでは、SVGやCanvasなどのグラフィックス、音声や動画などのマルチメディアなど13の標準についての現状とロードマップがまとまっています。仕様そのものの現状はもちろん、実装の状況、開発者向けのドキュメントの有無、テストの状態について一覧できる表があって便利です。

スタートアップにおけるデザインの役割 – Google Ventures

原題: Cheat sheet: Understanding the role of design in startups

記事のタイトルにはスタートアップにおける、とはありますが、Webに関するデザイン全般にも通じるデザインの役割について紹介しています。

A Complete Guide to Flexbox – CSS-Tricks

原題: A Complete Guide to Flexbox

CSSにおいての次世代レイアウト・プロパティともいえるFlexboxですが、弱点が1つだけあるとしたら、機能の全てを覚えきれないことではないでしょうか? このチートシートはそのFlexboxの機能をビジュアルとともに丁寧に解説してくれているので、これから覚えようという方はもちろん、いつもドキュメントを読み返している方もぜひ。

An Introduction to IndexedDB – Dev.Opera

原題: An Introduction to IndexedDB

まだまだブラウザの対応具合には難があるものの、IndexedDBの持つブラウザ側でデータベースを持てるという機能はかなり期待が高いものです。この記事でOperaのTiffany Brown氏は、そもそもIndexedDBとは何か、ブラウザの対応状況を解説し、おなじみTODOアプリを実装していく行程をコード例と共に紹介していきます。

パフォーマンス最適化 #perfmatters

Script-injected “async scripts” considered harmful – igvita.com

原題: Script-injected “async scripts” considered harmful

JavaScriptを非同期で読み込むことが、モダンブラウザにおいてもはやベストプラクティスとはいえない。
Ilya Grigorik氏はブラウザの内部動作を元にこの説について検証しています。

Docs on Performance Considerations – Modernizr

原題: Docs on Performance Considerations

プログレッシブ・エンハンスメントを行うのに便利なModernizrのパフォーマンスを鑑みた上で利用するにはどのようにするべきか。
Paul Irish氏によるアドバイス。

The Illusion of Motion – The Sea of Ideas

原題: The Illusion of Motion

レンダリング・パフォーマンスについて語る上でFPS(Frames Per Second)という単位は欠かすことができないものです。
この記事ではFPSとはなんなのか、そして人が動きを感知する錯覚とはどのように発生するのかについて詳しく解説しています。

Parallax Done Right – Dave Gamache

原題: Parallax Done Right

エフェクトの多い少ないはあるにしても毎日のようにパララックスを活用したWebサイトを見かけます。
皆さんもすでにお気づきのように大抵はパフォーマンスに難があり、時にはブラウザがクラッシュしてしまうこともあるほど。
この記事ではそのパララックスのパフォーマンスを向上させるいくつかのテクニックを紹介しています。

FrameViewerの使い方 – The Chromium Projects

原題: FrameViewer How-To

60FPSのゴールを達成するためには1フレームあたり16msの予算しかありません。
そのゴールを達成するのに必要なことはまず計測することです。
この記事ではGoogle Chrome(Canary推奨)が密かに提供しているFrameViewerという計測ツールの使い方について詳しく解説しています。

クローズアップ“ビデオ/スライド”

スライド/ビデオ

Breaking news at 1000ms – Patrick Hamann

原題: Breaking news at 1000ms

イギリスの新聞Guardianが次世代のWebサイトを作るにあたり実行したパフォーマンス最適化についてのスライド。
そもそもなぜパフォーマンスが大切なのか、よくあるパフォーマンスのボトルネックはどこにあるのかについてよくまとまっています。

Progressive Enhancement for JS Apps – Garann Means

原題: Progressive Enhancement for JS Apps

JavaScriptをメインとしたWebアプリにおけるプログレッシブ・エンハンスメントの仕方についてのスライド。
なぜプログレッシブ・エンハンスメントを行うべきなのかから、アプリケーションの状態の管理についてなど細かい部分についてのノウハウについて紹介されています。

Principles of Mobile Site Design: Delight Users and Drive Conversions

原題: Principles of Mobile Site Design: Delight Users and Drive Conversions

Googleがまとめたモバイルサイトデザインの原則。119時間にもおよぶユーザビリティテストの結果を5つのポイントに集約し、わかりやすく具体的なアドバイスをしています。

★次回の「斉藤祐也の海外WEBテク定点観測」は2014年7月2日にお届け予定です。★

斉藤祐也の海外WEBテク定点観測＜Issue.13: 2014/04/01-2014/04/30＞

今月の定点観測はWeb Componentsベストプラクティス、誰のためのWebなのかについて、そしてソースコード・レビューをどう行うかなどを紹介します。

注目ニュースピックアップ

Web Components ベストプラクティス – WebComponents.org

原題: Web Components Best Practices

Web Componentsはまだこれからの技術であることを念頭に、この記事では現時点でのベストプラクティスを紹介しています。

1. 名前空間: 名前空間が他のWeb Componentと重複しないよう、また3文字以内に止めることが望ましい。
2. すでに存在している要素を可能な限りまねる: ブラウザ側で実装している要素と同じように実装すること。
3. エラーを出さずに失敗する: ブラウザ側で実装している要素と同じようにDOMとのインタラクションはJSのエラーを出さないように。
4. 属性の使い方: Boolean値の属性は selected=“true” ではなく、selected のように指定する。
5. イベントを使ってデータを渡す: データが大きいか、頻度が多くない限りはカスタムイベントを利用してコンポーネント間のデータのやりとりを行う。

上記に加えて、11のリスト、合計16個のベストプラクティスが現時点で上げられています。

関連リンク:

• Accessible Web Components – Part 1 – Polymer
• The Web’s Declarative, Composable Future. – Addy Osmani
• Custom Element Interoperability – Polymer

開発者のためではなく、ユーザのために – The Sea of Ideas

原題: Winning for users, not developers

iOSやAndroidなどのネイティブアプリとWebアプリは様々な観点で比較されてきています。記事の筆者であるPaul Bakaus氏はその議論の多くで大切なポイントを見失っているとしています。
例えばURLの存在がWebの優れた点としてあげられますが、URLそのものが優れているのではなく、URLはユーザにとって共有するのに、またアクセスしやすいものであるからこそ優れているのだとしています。
議論が開発者視点のものになってしまっていて、ユーザの視点を見失ってしまっているのではないかという主張。

タスクにかかるコストと得られる価値について – NCZOnline

原題: A framework for thinking about work

あるタスクにかかるコストが高すぎるという感覚値は、開発者として経験を積んでいけば、ある程度は得られるものです。しかし、単純にリクエストに対して『コストがかかりすぎる』というだけでは、『大切な機能なんだ』と言われると議論が終わってしまいます。Nicholas Zakas氏は、この記事でタスクにかかるコストと得られる価値について、どのように考えるべきかのフレームワークを紹介しています。

ソースコード・レビュー。どうやってますか? – Shane Tomlinson

原題: How Do You Do Code Review?

複数人での開発が当たり前になるにつれ、ソースコードのレビューを行うことも増えてきています。しかし、そのソースコードのレビューをどうやるのかについての情報は、決して多くありません。Shane Tomlinson氏はこの記事で彼が実際に気をつけている点について共有しています。
記事では、どのレベルの精査が必要なのかをどう決めているのか。そして、複雑なパッチに対してどう理解度を深めているのか、小さな変更で副作用を発生させないために、何をするべきか。最後に、どのようにフィードバックを返しているのか。
ソースコードをレビューする人も、レビューを受ける人も参考になる点が多いはずです。

GitHubでオープンソースに貢献する方法 – GitHub Guides

原題: Contributing to Open Source on GitHub

すでにご存じの通り、GitHubはオープンソースへ貢献する場としては最大のサイトとなっています。そのGitHubから、これからオープンソースに貢献したいと考えている人に対してのアドバイスがこちらの記事。
すでにオープンソースに貢献している方であれば、当たり前のことばかりかもしれません。しかし、反対に自らオープンソースとしてるプロジェクトを持っているのであれば、ここで紹介している事柄を揃えておくとオープンソースへの貢献者が増えるとも言えるはずですので、ぜひ。

海外トレンドコラム

Intercomではどうやってデザインをしているか? – Inside Intercom

原題: How we design at Intercom

デザインに関する非常に有用な記事を多く提供しているIntercomのPaul Adams氏による、Intercomではどうデザインをとらえ、そしてデザインしているかの記事。実際のメールとは異なる部分もあるでしょうが、この記事ではPaul Adams氏がIntercomのメンバーに送ったデザインについてのメールを掲載してます。

関連リンク:

• And They All Look Just the Same – Cognition

モバイル・デバイスにおけるリモートデバッグガイド – Telerik Developer Network

原題: A Concise Guide to Remote Debugging on iOS, Android, and Windows Phone

モバイル開発における頭痛のタネの一つであるデバッグ。この記事は実際のモバイル端末でデバッグを行うための手法である、リモート・デバッグに対するガイドをわかりやすく紹介しています。

Web Notifications API 事始め

原題: An Introduction to the Web Notifications API

ネイティブアプリだけではなく、Webアプリでもユーザに対してプッシュ型のお知らせ、いわゆるノーティフィケーションという手法はごく当たり前になっています。この手法に対する実装はサービスごとにさまざまですが、W3CはWeb Notificationsという仕様を発表し、標準化に向けての一歩を進めました。この記事ではその仕様を利用したノーティフィケーションについて紹介しています。

アニメーションを使って支払いに関するユーザー体験を改善する方法 – Michaël Villar

原題: Improve the payment experience with animations

Stripeというサービスで、どのように支払いに関するユーザ体験を改善したのか。5つのアニメーション手法を、実際のアニメーションを見ながら紹介。アニメーションは「間」のデザインであり、支払いのようなフォーム要素で大きな影響を持つ手法ですので、参考にどうぞ。

関連リンク:

• Understanding CSS Timing Functions – Smashing Magazine

Sassを使ったユニットテスト – mts.io

原題: Sass Unit Testing

フロントエンド開発において、JavaScriptのテストは当たり前と言えるほど一般化してきました。しかし、同じくらい複雑なはずのCSSプリプロセッサのテストはどうでしょうか?
この記事では、Sassにおいてのロジック部分についてのテストをどう行うかについて紹介しています。

よりよいコード書くために知っておきたいコツ – Treehouse Blog

原題: Tips for Writing Better Code

より優れたコードを書くために、知っておきたいコツを5つ紹介。中級者くらいの経験者にとってはごく当たり前の5つですが、考えずにやっている事柄こそ、言語化するのは難しいものですので、初級者だけではなく、中級者、あるいは上級者の方にも読んでおいてほしい記事です。

パフォーマンス最適化 #perfmatters

300msのクリック遅延を抑制するための調査 – QuirksBlog

原題: Suppressing the 300ms click delay

タッチデバイスにおける300msのクリック遅延問題には多くの問題が潜んでいます。Chromeは最近この300msをmetaタグに「width=device-width」と設定することで無くし始めています。この記事でPeter Paul Koch氏は例によって事細かに「width=device-width」と300msの抑制について、実際のデバイスを使ってテストした結果を共有しています。

V8に関する資料まとめ

原題: V8 Resources

V8エンジンは言わずもがな、ChromeでもNode.jsにも利用されている非常に優れたJavaScriptエンジンです。V8エンジンのもう1つの特徴はこの種類のツールとしては多くの情報が公開されている点です。
このページではそれら情報を1箇所にまとめて紹介しています。

クローズアップ“ビデオ/スライド/ツール”

スライド/ビデオ

HTTP2.0について

原題: http2 explained

HTTP2.0をプロダクションで利用しているというサービスはまだないかも知れませんが、今後はそれも変わっていくことでしょう。このページでは、そのHTTP2.0をプロトコルレベルから説明しているPDFそしてスライドを紹介しています。

CSS Grid Layout – Alex Danilo

Flexboxの利用が増えてきた、というタイミングですが、このスライドはCSSでグリッド・レイアウトを実装するための仕様である、CSS Grid Layoutについて紹介しています。
なかなか複雑な仕様なので、ビジュアルで解説してくれているこのスライドは非常にわかりやすくオススメです。

静的型付けは過大評価されている!? – Eric Elliott

原題: Static Types are Overrated: Dynamic Duo – Loose Types and Object Extension

ニューヨークで開催されたVelocityにて、Eric Elliot氏による『静的型付けは過大評価されている!?』と題した発表。
型の正しさだけでは、プログラムの正しさを補償するものではないとしています。彼はこの発表で、JavaScriptが持つ動的型付けの性質がアプリケーションを開発する上で、大きな武器になる点について触れています。

ツール

Internet Explorer Web Platform Status and Roadmap – status.modern.IE

Internet ExplorerにおけるHTML5、CSS3などの仕様の実装状況とロードマップを一覧できるサイト。
ちなみに、Chromeにも同様のサイトがあるので併せてどうぞ: Chromium Dashboard

SIZER SOZE

レスポンシブ・デザインにおいて、頭を悩ます問題の一つである画像の取り扱い。この扱いをおざなりにしてしまうと、単にパフォーマンスのよくないページが生まれてしまいます。このツールは、サイトのURLから画像をどれくらい無駄遣いしているのかをチェックしてくれます。

関連リンク: Picturefill 2.0: Use the picture element today – Filament Group, Inc., / Picture要素のPolyfillが最新の仕様に併せてリニューアルしていますので、上のツールの結果が気になるものであれば、導入を検討してみては?

CSS Vocabulary

CSSの用語をインタラクティブに実際のソースと照らし合わせて教えてくれるツールです。チームでの開発における共通認識は非常に大切ですから、しっかり覚えておきましょう。

Animated Bézier Curves – Jason Davies

ベジェ曲線について。アニメーションを使ってベジェ曲線がどのように描かれるかについて解説。アニメーションはD3.jsを利用して作成されているそう。

★次回の「斉藤祐也の海外WEBテク定点観測」は2014年6月2日にお届け予定です。★

HTML5 Rocksは、開発者向けのHTML5周辺技術に関するリソースを公開しているサイトです。Googleによって運営されており、記事が多言語に対応しているものもあります。

html5j英語部の今回のイベントでは、いくつか記事をピックアップし、グループに分けて翻訳を行いました。

今回翻訳対象としてピックアップした記事：

• User Timing API: Understanding your Web App – HTML5 Rocks
• Avoiding Unnecessary Paints: Animated GIF Edition – HTML5 Rocks
• Avoiding Unnecessary Paints – HTML5 Rocks
• High Performance Animations – HTML5 Rocks
• Scrolling Performance – HTML5 Rocks

英語部名物・ライブ翻訳

前回と同じく、今回も英語部・部長の斉藤さんによるライブ翻訳がありました。

今回のライブ翻訳で挙げたポイントは、次のような斉藤さんが翻訳するときの手順についてです。

抜粋元：JavaScript Promises

In browsers, JavaScript shares a thread with a load of other stuff.

頭から順に訳していきますが、はじめからきっちりと、きれいな日本語に置き換えようとはしません。まず主語（S）と動詞（V）を見つけます。この一文でいえば、「JavaScriptは共有する」というが重要です。その上で具体的に訳していきますが、最初はラフな日本語で大丈夫です。それからきれいな日本語に整形します。

1. 「JavaScriptは共有する」
2. 「JavaScriptは共有する、ひとつのスレッドを、他のものの読み込みと一緒に」
3. 「JavaScriptは、他のものの読み込みと一緒に、ひとつのスレッドを共有します」
4. 「ブラウザーにおいては、JavaScriptも、他のものの読み込みと一緒にひとつのスレッドを共有します」

翻訳の難しさは、英語にあるのではなくて、日本語にあると部長は言います。
英語が得意な人でも、英語のままとしての意味はわかったとしても、それを日本語として意味を違えずに表現することは難しいです。英語部では、オフライン/オンライン問わず、翻訳の経験者による監訳サポートがあるので、翻訳の初心者であっても、アドバイスをもらいながら進めることができます。

HTML5 Rocksの翻訳フロー

今回会場提供をしていただいたグリーの宮崎さんからは、HTML5 Rocksの翻訳フローについてのLTを行ってもらいました。

スライド: HTML5 Rocks translation

宮崎さんは、すでにHTML5 Rocksの7つの記事を翻訳した経験があります。
ちなみに宮崎さん曰く、HTML5 Rocksの記事の単位はrockだ、ということで、7rocksを翻訳したということになります

HTML5 Rocksの翻訳フローは、Git/GitHubを使ったプロダクト開発と同様で、Pull Requestを通して翻訳済みのドキュメントを取り込むという流れになっています。

1. HTML5 RocksのWebサイトのレポジトリをForkする
2. 翻訳したい記事を見つけ、コピーをして/ja/ディレクトリで展開、翻訳をする（詳細は後述）
3. Fork元にPull Requestを送る（送り先はmasterブランチ）
4. Reviewを受けて、Feedbackがあれば対応、問題なければ取り込まれる
5. サイトに公開（liveブランチにマージされる）

未翻訳記事の見つけ方

翻訳したいとおもっても、その記事がすでに日本語訳されていたり、もしくは進行中である場合は、残念ながら翻訳しても載せてもらうことはできません。

翻訳済みの記事は、Localizationsに翻訳された言語へのリンクが存在していますので、その記事は翻訳できません。（もし翻訳内容に誤りなどがあれば、それはそれで修正してPull Requestを送るとよいでしょう）

まだ公開はされていないけれど、進行しているものはIssuesおよびPull Requestsを確認するとわかります。Openのものだけでなく、Closeして公開待ちのような記事もあるかもしれないので、Closeの中も確認しましょう。

翻訳の進め方

記事ページは/content/の中に格納されています。

翻訳したい記事のURLを確認し、該当のディレクトリを探っていくと、/en/ディレクトリが確認できるはずです。その中に原文のindex.htmlがはいっているので、/en/ディレクトリをコピーし、/ja/ディレクトリをつくったら、その中のindex.htmlを翻訳します。 （/ja/ディレクトリがある例）

翻訳対象はこのHTMLファイルだけでなく、/conf/locale/ja/にもある場合があります。記事タイトルはこちらにも含まれている時があるので、該当の記事をみつけたら、msgstrに日本語訳を書きましょう。

また翻訳者のクレジットを残すこともできます。クレジットは、下記のフォーマットで記事内に差し込むことで追加されます。

{% block translator %}
<div class="translator">
  <strong>翻訳:</strong> <a href="https://github.com/hiloki/">Hiroki Tani</a>
</div>
{% endblock %}

翻訳者クレジットが差し込まれている例

その他、翻訳やページの追加に関することは、下記のドキュメントに記載されているので、一度目を通しておくことをおすすめします。

• LOCALIZATION.md（日本語訳）
• CONTRIBUTING.md

翻訳しながら技術的に学ぶ

HTML5 Rocksが素晴らしい技術記事が充実したサイトということもあり、英語を翻訳する経験と力をつけるとともに、技術的に新しく学べるという点で、翻訳のしがいがあると思います。

今回オフライン活動のひとつとしてHTML5 Rocksをグループで翻訳しましたが、引き続きオンラインでも継続しておこないます。

本レポートやhtml5j英語部の概要をみて興味を持ち、また監訳などを受けながら翻訳したい方がいればぜひ参加してください！その際には英語部リポジトリのHTML5 Rocksの内容を一読ください。

もし不明なことがあればIssuesやGitterに連絡をください。

最後に大事なことを伝えておくと、html5j英語部はあくまでも有志による翻訳コミュニティです。 オリジナルであるHTML5 Rocksとは関連はなく、全てのHTML5 Rocksの日本語訳が本コミュニティを通じて行われているわけではありません。HTML5 Rocksの翻訳をしたい！という方は個人でどんどん翻訳をしてもらえれば良いのではないかと思います。

今回会場をお貸しいただいたグリーの皆さん、ありがとうございました！

斉藤祐也の海外WEBテク定点観測＜Issue.12: 2014/03/01-2014/03/31＞

今月の定点観測はWeb Componentsに関するパネル、WebとDOMとの関係性、ARIAのWeb標準化などを紹介します。

注目ニュースピックアップ

Web Componentsに関するパネルディスカッション

原題: EdgeConf 3: Components

3月21日にロンドンにて開催されたEDGE Conferenceにて議論されたWeb Components。このカンファレンスでの議論そのものも非常に興味深いものですが、このカンファレンスをきっかけに多くの議論がブログなどで展開されました。Web開発の未来を担うとすら表されるWeb Componentsがその未来へと着実に歩みを進めるためにどんな障害があるのでしょうか。様々な領域で活躍するエキスパートたちの意見を以下に関連リンクとしてまとめましたので、興味がある方はぜひそれぞれ一読を。

関連リンク:

• A Detailed Introduction To Custom Elements – Smashing Coding
• Web Components Best Practices – WebComponents.org
• Web Components and the Three Unsexy Pillars – Aerotwist
• The Web’s Declarative, Composable Future.
• Notes on accessibility of Web Components – Bruce Lawson’s personal site
• The Golden Path
• Notes from the edge – Adactio

Shadow DOM – Acko.net

Steven Wittens氏により書かれたこの記事のタイトルはShadow DOMですが、あのShadow DOMではなく、DOMに関する問題点へ指摘と解決策の提言です。React.jsのようにDOMらしいものを生成しDOMを制御するアプローチがあったり、Angular.jsのようにHTMLによく似たシンタックスでDOMへのアプローチを隠蔽するアプローチがあったりと、DOMから離れれば離れるほどWebそのものがよいものになったように思えてくる。氏の狙いは非常に的確なものだと言えると思いますが、以下に関連リンクとして紹介しているCSS TricksのChris Coyer氏による反論も併せて読んでおくと良いでしょう。

関連リンク: Hatin’ on Web Tech by CSS-Tricks

WAI-ARIAがWebのアクセシビリティを拡張する – W3C Blog

原題: WAI-ARIA Expands Web Accessibility

Accessible Rich Internet Applications 1.0 (WAI-ARIA)、そして関連する仕様であるWAI-ARIA 1.0 User Agent Implementation GuideがW3C Recommendationとなりました。つまり、WAI-ARIAはWeb標準となったことを意味します。広範囲に及ぶ、実装だけではなく、テスト、そしてバグ修正を行い、多くのモダンブラウザですでにサポートされ、モバイル・ブラウザにおけるサポートも広がってきています。またHTMLだけではなく、EPub 3.0やSVG 2などの仕様にもWAI-ARIAを適応し、より広範囲でのアクセシビリティを提供していくそうです。

関連リンク:

• We Make the Web. Let’s Make It Accessible. – The Changelog
• What is WAI-ARIA, what does it do for me, and what not? | Marco’s accessibility blog

Browsiness – Adactio

本連載、Issue. 11にて紹介したJeremy Keith氏による「Webに課せられたある1つの矛盾」の考察に対する追記に当たる記事といえるでしょうか。記事はAndroidとiOSの違いについての考察から始まり、ネイティブとWebの差に話が及ぶ。その段になってKeith氏はWebとは何かという根源的な疑問に対し、氏がどのように考えているかについて語っていきます。
氏は次の文で記事を締めくくります。 『分裂として捉えるのを辞め、多様性として捉え始めるべきだ。』
氏の言葉通り、WebとはHTMLやCSS、JavaScriptで書かれたものだけを意味するものではないでしょう。

関連リンク: Why don’t designers take Android seriously? : Cennydd Bowles

Web標準化に貢献するために必要なこと – Anne’s Blog

原題: Contributing to standards

Anne van Kesteren氏はWeb標準化に貢献するためには、Web標準がコミュニティによって作られていることに気がつくことが大切なステップだとし、そのコミュニティでコミュニケーションに利用されているミディアムを追いかけることを次のステップとしています。もちろん貢献しようとしている標準そのものに詳しい必要もありますが、それらを取り巻く環境にまず慣れることが活動の第一歩だとしています。

関連リンク: How to win friends and influence standards bodies – Domenic Denicola / Domenic Denicola氏がLXJS 2013にて発表した彼自身がどのように標準化団体にアプローチしたかについてのプレゼンテーション。

海外トレンドコラム

Picture要素に関するQ&A – An A List Apart

原題: [A Q&A on the Picture Element

Picture要素の復活に尽力したMarcos Caceres氏とYoav Weiss氏に対して、同じくResponsive Images Community Groupに所属しているMat Marquis氏がインタービュー。 Picture要素が以前のバージョンとどこが違うのか、それまでに登場したsrcsetやsrc-nという仕様や提案が現在のPicture要素にどのように影響しているのかなどについて詳しく解説しています。

Srcsetとsizes – ericportis.com

原題: Srcset and sizes

Picture要素の現行仕様はどうしてそのシンタックスを採用したのでしょうか? この記事ではその疑問に対して、具体的なソースコードを見ながら現行の仕様とほかのレスポンシブ画像に対する解決案を比較しています。srcsetに加えて新たに追加されたsizesという属性が重要な役割を担っているのが一目でわかります。

モバイル・ファーストはもう終わった、のか? – Forbes

原題: Mobile-First Is Dead, Says Google Display Ad Chief Neal Mohan

Googleのディスプレイ広告部門の副社長を務めるNeal Mohan氏によると、多くのユーザーはもはやモバイルだけにフォーカスをしているだけでは時代遅れになりつつあるとしています。消費者達は多くのデバイスを駆使して、利用シーンに合わせてタスクを完遂しているとしています。なんと約90%ものユーザーがあるデバイスで開始したタスクを別のデバイスで完了しているとしています。モバイル・ファーストはすでに過去の問題を解決しようとしているに過ぎないと氏は語り、今後はマルチデバイスの最適化にフォーカスを移していくべきだとしています。

若いデザイナー、デベロッパに対するアドバイス – Andy Budd

原題: My Advice to Young Designers and Developers

日本ではそうでもないと思いますが、大学を卒業するよりも業界の経験を積んでいる方が重宝される業界であるWeb業界において、大学に行く意味とはなんなのかをAndy Budd氏がアドバイス。

パフォーマンス最適化 #perfmatters

Paul Lewis氏のパフォーマンスチェックフロー – Aerotwist

原題: My Performance Audit Workflow

Googleの中でもパフォーマンスに注力しているPaul Lewis氏本人のパフォーマンスチェックのワークフローについて。氏はまずPageSpeed Insightsでサイト全体の状態を確認し、WebPageTestを使ってネットワーク周りのパフォーマンスを細かくチェック。それから、レンダリングに関わるパフォーマンスチェックを、このリストを参照しながら行っているそうです。このワークフローは手動で行うものがほとんどですが、自分が担当するプロダクトでは自動化できる部分は可能な限り自動化をしているとのこと。

ブラウザキャッシュは”とても”壊れている – JakeArchibald.com

原題: The browser cache is Vary broken

HTTPキャッシュはURLとHTTPメソッド(GETやPOSTなど)でコントロールするものですが、”Vary”ヘッダを利用してより細かく制限をすることができます。しかし、この”Vary”ヘッダは少々やっかいもので、IEでは”max-age”が無視され、Safariでは少々バグがあったりもします。この記事では具体的な例を見ながら”Vary”ヘッダの挙動について詳しく紹介しています。

CSSアニメーションとトランジションのパフォーマンスについて – Web Platform Team Blog

原題: CSS animations and transitions performance: looking inside the browser

ブラウザ内部がどのように動作しているのかを知ることで、CSSアニメーションやトランジションの記述をする前に、そのアニメーション/トランジションのパフォーマンスがよいものか、そうでないのかを知ることができます。この記事では特にGPUがどのようにパフォーマンスに作用するのか、そしてなぜ特定のプロパティをアニメートすることがパフォーマンスのボトルネックになるのかについて、詳しく解説しています。

WebKitのCSS JITコンパイラについて – Surfin’ Safari

原題: Little overview of WebKit’s CSS JIT Compiler

ブラウザはユーザーに対してよりよい体験を提供するために日々改善を行っています。この記事ではWebKitがCSSの解析にかかる時間をどう改善していくのかについて、JavaScriptの解析では当たり前のように利用されているJIT(Just In Time Compilers)をCSSのセレクタの解析に応用してみた結果について紹介しています。

jQueryはモバイルには大きすぎるのか? – Flippin’ Awesome

原題: Is jQuery Too Big For Mobile?

モバイルWebにおいて、パフォーマンスが特に重要なファクターであることはよく知られています。パフォーマンスの最適化に際し、デスクトップの時代には当たり前のように利用していたjQueryは、そのファイルサイズからモバイルでは利用されない傾向にあります。しかし、本当にjQueryはモバイルには大きすぎるのでしょうか?　この記事では実際のモバイル端末でjQueryを読み込み、どのくらいの時間がかかったのかを詳しく解析しています。また読み込みだけではなく、解析にかかる時間も加味した詳細なデータで疑問に答えてくれています。

クローズアップ“ビデオ/スライド/ツール”

スライド

Viewportとレスポンシブデザインの関係

原題: Viewports or: why responsive design works

Peter-Paul Koch氏がjQUery EUで発表したこのプレゼンテーションは氏の得意とする詳細なテストによるデータを使ったViewportから見たレスポンシブ・デザインに関する実利的なアドバイスについてです。氏はまずピクセルとはなにかから解説し、モバイルとデスクトップのViewportsの違い、JavaScriptやMetaタグによるViewportsの仕組みについて詳しく解説しています。

関連リンク: The Great Table / Peter-Paul Koch氏による本プレゼンテーションで発表したViewportに関連するコンセプトのモバイルブラウザ別の対応状況をまとめた表。

Flexboxを使って一歩上行くレイアウトを – Zoe Gillenwater

原題: Leveling Up with Flexbox

Smashing ConferenceにてZoe Gillenwater氏が発表したFlexible Box Layoutを使ったレイアウトテクニックに関するプレゼンテーション。
仕様として少々バタバタしていたFlexible Box Layoutですが、ようやく様々なブラウザで同じシンタックスが利用できるようにもなってきて、現実的なアプローチとして注目が集まってきています。氏はこのプレゼンテーションで様々なレイアウトテクニックを紹介しつつ、Flexible Box Layoutをサポートしていないブラウザに対するフォールバックについても紹介しています。

関連リンク: Leveling Up With Flexbox presentation at Smashing Conference

Guardian誌のレスポンシブデザイン対応について

原題: Responsive design at the Guardian

イギリスの新聞であるGuardianにて、クライアントサイドWebデベロッパとして働くMatt Andrews氏によるプレゼンテーション。数年前にレスポンシブデザインを採用したBoston Globe誌を始め、最近ではBBCもレスポンシブデザインを採用しています。ニュースサイトにおけるレスポンシブデザインはなかなかハードルが高い部分がありますが、そのいくつものハードルをGuardianではどのように超えていったのかについて詳しく紹介しています。

ツール

HTML5 Security Cheatsheet

HTML5に関連する技術を使ったセキュリティに関する注意点と、その回避についてのチートシート。

CSSynth

CSSアニメーションを実際に目視しながらカスタマイズできるエディタ。特定のアニメーションに限ったエディタではありますが、エディタが作り出すスムーズなアニメーションは見ていて飽きません。

CSS Filters Demo

上で紹介したCSSynthの作者による別プロジェクト。こちらはCSSのフィルタを使ったデモ。

★次回の「斉藤祐也の海外WEBテク定点観測」は2014年5月1日にお届け予定です。★

斉藤祐也の海外WEBテク定点観測＜Issue.10: 2014/01/01-2014/01/31＞

今月の定点観測は、CSS Regionsに対する問題提起、新picture要素仕様、Webスタンダードの新フェーズなど合計20件の記事や動画などを紹介します。

注目ニュースピックアップ

CSS Regionsへの問題提起 – An A List Apart Blog Post

原題: CSS Regions Considered Harmful

タイトルからしてすでに議論を呼び込むようなタイトルとなっている、CSSの父であるHåkon Wium Lie氏によるCSS Regionsの仕様に対する問題提起。
時を同じくして、GoogleのBlinkチームがCSS Regionsを実装しないという議論も始まり、大きな議論に発展しています(関連リンクを参照してください)。
この記事でHåkon Wium Lie氏はRegionsはダミーのdivを使う必要がある、レスポンシブではない、テキストフローが分かりづらい、33行にもおよぶほどのコードで実現するしかない、コードの再利用性が低いという5つのポイントを問題点として挙げています。

関連リンク:

• CSS Regions in Blink: status, future work / CSS Regionの実装についての議論
• CSS Regions Matter – Flippin’ Awesome / CSS Regionsを実利的に利用した例を豊富に紹介

The picture Element

レスポンシブ画像に対する飽くなき議論の末、議論の始まりとなったpicture要素の新仕様が発表されました。これまでの議論をうまく集約した提案となっています。フォールバック要素としてのimgではなく、picture要素内に必須となる要素としてimgを利用している点が、以前のpicture要素との違いとなるポイントとなっています。

関連リンク: picturefill – Shawn Jansepar / 新仕様に合わせたPolyfill

2014年、Webデザインは死んだのか? – Jeffrey Zeldman Presents The Daily Report

原題: It’s 2014. Is Web Design Dead?

Jeff Croft氏による「Web Standards Killed the HTML Star」という記事を見かけた方も多いかも知れません。その記事へのJeffrey Zeldman氏からの反論がこの記事です。Zeldman氏は確かにChroft氏が言う通りの部分があることは認めつつ、Webスタンダードには2つのフェーズがあり、現時点ではその内の1つ目がようやくまともになってきたタイミングだとしています。
Zeldman氏はWebスタンダードは当たり前の存在であるべきとしつつ、さらにウェブサイトを構築することを簡易にし、その上でデザイン、コンテント、そして体験を生み出すことにフォーカスしやすくするのが次のフェーズであると主張しています。

関連リンク: Web Standards Killed the HTML Star – JeffCroft.com

フロントエンド開発における問題解決へのプロセス – CSS-Tricks

原題: Thought Process of a Front End Problem

海外の第一線で活躍するフロントエンド開発者であるChris Coyier氏が自身が実際に解決しようとした「Opera mobileでフォントのレンダリングがおかしい」という問題へのアプローチについて詳細を語っています。
共感できる点が多く、やはり第一線にいるCoyier氏でも環境が大きく異なるブラウザの世界では同じように苦労しているのだなというのが分かります。
彼自身がどのように問題に対峙したのかの記録は似た問題を解決する際の参考になるのはもちろん、フロントエンド開発における問題の多くの解決に参考になります。

アルゴリズムはフロントエンド開発者にも必要な知識か? – Aerotwist

原題: Algowhatnow?

フロントエンド開発者の面接に、アルゴリズムに関する問題を出す意味はあるのでしょうか？
フロントエンドに関わる多くの開発者コンピュータサイエンス関連の大学を卒業していないケースもあり、アルゴリズムそのものよりもクロスブラウザに対するアプローチや知見などのほうが優先度が高いという議論もありますが、コンピュータとの対話を行うためにやはりアルゴリズムは欠かすことができないのかもしれません。
ロジカルシンキングの指標としても利用できるアルゴリズムへの知見は持っていて損はしないという主張。

海外トレンドコラム

ボタン要素はいつ使うべきなのか? – CSS-Tricks

原題: When To Use The Button Element

a要素とbutton要素はどのように使い分けて行くべきでしょうか？ CSSを利用して、どんな要素でも自在にスタイリングできるようになったからこそ知っておきたいことです。

EMEの利点と欠点

原題: EME pro and con

W3Cが仕様を策定しようとしていることで話題になっているEME(Encrypted Media Extensions)について利点と欠点をコンパクトにまとめたGoogle Docs。
これまでに多くの議論が行われてきているので、今からその議論に追いつきたい場合に非常に役に立つ文書です。

アクセシブルなアイコンフォントの使い方 – Filament Group, Inc., Boston, MA

原題: Bulletproof Accessible Icon Fonts

アイコンフォントを利用するケースが徐々に増えてきています。しかし、アイコンフォントの利用に際して忘れられがちなのがアクセシビリティ。音声ブラウザがアイコンフォントに使っている文字を発してしまったりするのは避けるべきです。この記事では、アクセシビリティを考慮したアイコンフォントの利用について、詳細に紹介しています。

CSS Will Change Module Level 1

レンダリングのパフォーマンスを向上させるために、利用せざるを得ないtranslateZなどを活用したハック。有効でありかつ手軽である反面、ハックである事実は変わりませんし、それなりのコストもかかります。
このCSS Will Change Moduleはそのハックを必要とせずに済むように提案されている仕様です。

関連リンク: Bye Bye Layer Hacks – Aerotwist

Promisesガイド – w3ctag

原題: Promises Guide

Promisesの仕様を作成しているチームにより、どのようにPromisesは利用するのかについてのガイドラインが公開されました。ライブラリなどを作成する際に参考になるだけではなく、少々とっつきづらい文章ながら、既存のPromisesライブラリを利用する際にも参考になるはずです。

jQueryはもう必要ない?

原題: You Might Not Need jQuery

数年前までは、jQueryなしでのクライアントサイドの開発は想像できませんでした。しかし、レガシーブラウザへの対応の必要性が少しずつ減ってきた今、jQueryは本当に必要でしょうか？
このサイトでは、ネイティブJavaScriptでjQueryが提供しているAPIを代替するスニペットを紹介しています。

関連リンク:

• Why You Still Need jQuery / いわゆるモダンブラウザでもクロスブラウザの問題を解決するのにjQueryが行っているワークアラウンドを示しています。
• Twitter / jeresig: I keep writing and deleting … / jQueryのオリジナルの作者であるJohn Resig氏のコメントにも注目してください。

head要素内にCSSを入れるのは何故なのか? – Aqeel

原題: What’s with putting the CSS in the head?

これまで知られているベストプラクティスでは、CSSは外部CSSファイルから呼び出す。となっています。本質的には現時点でも間違いではありません。しかし、近年CSSをstyleタグ内に記述する例も増えています。なぜそうすることがパフォーマンス観点でプラスに働くかについて、ブラウザのレンダリングの仕組みなどを踏まえて詳細に解説しています。

Promise nuggets – Gorgi Kosev

なかなか理解するのに苦労するPromisesについて、コールバックとの違いを実例を通して解説してくれているのがこのサイト。コールバックを使ったアプローチとの比較のおかげで、Promisesの利点や実装イメージがわきやすくなるはずです。

HTML、CSS、JavaScriptを合わせたモジュールデザイン開発へのアプローチ – Techwraith

原題: Atomic Product Development

モジュールデザインというアプローチは、今ではウェブ開発において欠かすことができないものとなっています。近年はJavaScriptにおけるモジュールデザインが盛んに議題に上がっていますが、CSSについてはあまり言及がありません。この記事では、HTML、CSS、JavaScriptが持つ依存関係の低減に必要なアプローチについて、詳しく解説しています。

CSSOMを使ったCSSの機能テストについて – Ryan Morr

原題: Feature Testing CSS At-Rules

ブラウザでどのCSSのAPIが実装されているかを調べる手法の紹介。この記事では「@」を利用する機能のテストについて紹介しています。

クローズアップ“ビデオ/スライド/ツール”

Promises/A+ 実装を通じて仕様について学ぼう v.1.1対応版 – Modern JavaScript

原題: Promises/A+ Understanding the spec through implementation v1.1

ネイティブでJavaScriptに実装される予定であるPromises。その元々の仕様であるPromises/A+と呼ばれる仕様が、昨年の8月にバージョン1.1に変更されました。その変更を踏まえて、実装と仕様を合わせて解説しているのがこのスライド。細かい部分についても分かりやすく解説してくれているのでおすすめです。

JavaScriptにおけるSOLID – Derick Bailey

原題: SOLID JavaScript In A Wobbly (World Wide Web)

オブジェクト指向における有名な5つの設計原則をまとめたSOLIDを、JavaScriptで実践する際に気をつけておくべきポイントについて、詳しく解説している動画です。スピーカのDerick Bailey氏はBackbone.jsのプラグインMarionette.jsの作者でもあります。

CSSの3D、アニメーションについてインタラクティブに学ぶ – Chris Ruppel

原題: Unfolding the Box Model

CSSの3D Transformsについて、インタラクティブに学ぶことができるサイトです。アニメーションはもちろん、3Dのコンセプトは実際に動いているものを見ることが一番わかりやすいので、初心者、中級者の方はぜひ。

JS: The Right Way

JavaScriptに関する優れた様々な情報を集めて紹介しているサイトです。Superhero.jsと同じようなコンセプトではありますが、記事だけではなくライブラリなどもコレクションしています。

Remote.js – Hage Yaapa

WiFiもBluetoothも使わずに、音を使ってスマートフォンからデスクトップブラウザを操作するためのライブラリ。
実際に動作する(試してみたところ、少々怪しげながら動作します)デモもあり、非常に興味深いツールです。

★次回の「斉藤祐也の海外WEBテク定点観測」は2014年3月3日にお届け予定です。★

斉藤祐也の海外WEBテク定点観測＜Issue.9: 2013/12/01-2013/12/31＞

今月の定点観測は、JavaScriptにおけるPromises実装について、CSSの変数(Custom Properties)、Quartz ComposerのプラグインOrigamiなど合計20件の記事や動画などを紹介します。

注目ニュースピックアップ

JavaScriptにおけるPromises実装について – HTML5 Rocks

原題: JavaScript Promises: There and back again

これまでJavaScriptの『限界』であるシングルスレッドを解決するために、コールバックやイベントを利用してきました。そのJavaScriptにもう1つ、Promisesと呼ばれる機能が追加されます。
Q.jsやwhenなどのようなライブラリを使ってすでにPromisesを利用している人も多いことでしょう。
現時点ではChrome CanaryとFirefox Nightlyにて一部の機能が利用でき、Polyfillも存在しています。
JavaScriptネイティブのPromisesはrsvp.jsのAPIとほぼ同じとなっているようです。

CSSの変数(Custom Properties)で遊んでみよう – That Emil

原題: Playing around with CSS variables – “custom properties”

CSSに変数を追加することは開発者から長期にわたって要求されてきました。CSSプリプロセッサがまだない時代からのこの要求に対し、様々な試みがされてきましたが、ついにFireFox Nightlyに「CSS Custom Properties for Cascading Variables Module」という仕様に則り実装されました。
Emil Björklund氏による記事はその実装に対しての実験を行っています。
詳しい仕様についてはCSS Working Groupのメンバーの1人であるTab Atkins Jr.氏が昨年2013年にCSS Dayにて発表した『Variables & Conditionals』にて詳しく解説しています。

またTab Atkins Jr.氏が2012年に提案したドラフトの頃からCSSに変数が必要であるか否かについての議論が途絶えたことはありません。
それら反論についても知っておくとよいので、以下に関連リンクとして紹介しておきます。

関連リンク:

• About Variables in CSS and Abstractions in Web Languages – CSS-Tricks
• Sasstraction – Adactio

Quartz Composerを使ってのプロトタイプ制作プラグイン: Origami — Julie Zhuo

原題: Introducing Origami for Quartz Composer

Webでもアプリケーションでもデザインに求められることが表層にある見た目だけではなくインタラクションなども含まれるようになって来ています。
Facebookではそのインタラクションを含むデザインを行うのにQuartz Composerを利用してプロトタイプを作成しているそうです。
Quartz ComposerはMac OS Xの開発環境の一部として提供されているビジュアルプログラミング言語で、元々はプロトタイプを行うためのツールとして提供されているわけではありません。
Origamiはそのやや取っ付きづらいQuartz Composerをよりプロトタイプツールとして使いやすくするパッチを提供するオープンソースツール群です。
この記事ではFacebookのプロダクトデザインディレクタであるJulie Zhuo氏がツールの紹介をしています。

関連リンク:

• FacebookのOrigamiグループ
• How to Survive in Design (and in a Zombie Apocalypse)
• Go Big by Going Home

オフライン・ファーストでウェブアプリケーションをデザインする – A List Apart

原題: Designing Offline-First Web Apps

前回の本連載でもとりあげた、オフライン・ファーストというアプローチについての続報。
記事ではなぜオフライン・ファーストを重要視するべきなのか、オフライン・ファーストのアプローチを採用する上でどんな問題点があるのかについて詳細にわたり解説しています。 offlinefirst.orgを牽引するHoodieチームの一員である筆者のAlex Feyerke氏は以下のように述べています。

『オフライン状態のWebサイトやアプリケーションの利用に対する体験はよりよくならなければならないし、もっとがっかりさせないようにしなくてはならない。もちろんもっと便利である方がいい。接続されていない、マルチデバイスの世界についてのガイドやパターンのカタログ、レスポンシブウェブデザインが築いてきたようなUXがオフライン・ファーストを行うためにも必要だ。』

関連リンク:

• Offline First: Learning from native experiences — Dion Almaer
• ServiceWorker & the offline web – Tom Ashworth

ベンチマークに関する注意点について – Aerotwist

原題: Bad Benchmark, Right Result

Googleの中でもパフォーマンスに関するすばらしい記事を常に提供してくれるPaul Lewis氏によるベンチマークに関する注意点。
結論から言うと、現時点では3D Transformsを扱うために非常に便利なCSSMatrixを使うと結果的に（少なくとも）toString()を利用して処理するため、パフォーマンス観点ではあまりプラスにはなりません。
しかしこの記事ではその結論よりも、彼がどのようにAPIを使ってよりパフォーマンスを向上させているのか、そしてそれをどのようにベンチマークしているのか。JSPerfを使ったベンチマークにおける注意点なども含め、一連の流れについて着目していただければ。

海外トレンドコラム

ブラウザへの12個のパフォーマンス要望リスト – Performance Calendar

原題: Browser Wishlist 2013

2013年の年末にSteve Souders氏がまとめた12項目からなるブラウザへのパフォーマンス観点での要望リスト。
この時点で要望されるということは気をつけておく必要があるリストでもあるので、各項目をしっかりレビューしておくとよいでしょう。

Chromeの開発者ツールをFirefoxで使えるとしたら? — Kenneth Auchenberg

原題: What if you could use Chrome DevTools with Mozilla Firefox?

先月の本連載で紹介したremotedebug.orgの中心的人物であるKenneth Auchenberg氏によるFirefoxでChromeのDevToolsを利用する様のデモ。こうして実際に動作するものを見ると、remotedebug.orgが進めるBridgeという概念がいかに強力なものであるかが分かります。

アクセシビリティに合わせたコーディングをしよう – 24 ways

原題: Coding Towards Accessibility

アクセシビリティが重要であることはことさら今改めて伝えることではありませんが、どうしても難しいものというイメージがつきまとうものです。この記事ではそのアクセシビリティについて、習慣化しやすい実利的な手法について詳しく紹介しています。

Chrome開発者ツールを使って60FPSを実現するためのワークフロー – Wingify Engineering

原題: Getting 60 FPS using Chrome devtools

パフォーマンス改善はルールを覚えることより、ツールを使って実測しながら行うのが鉄則です。この記事ではそのツールの中でも最も優れた機能を有しているChrome DevToolsを使って一連の改善に関するワークフローを紹介しています。スクリーンショットも多く非常に分かりやすいです。

Position: fixedに関する最新情報 – QuirksBlog

原題: position: fixed update

モバイルWebサイトやアプリケーションの制作に携わったことがある人であれば、必ず遭遇する問題の1つであるposition: fixedにまつわるバグについての現状を、Peter-Paul Koch氏がまとめています。実際の動作を動画で表示しているので、ぜひ自分の目で確認してください。

MEANスタックをYeomanで素早く構築する方法

原題: Full-Stack JavaScript With MEAN And Yeoman

MongoDB、Express.js、Angular.js、Node.jsそれぞれの頭文字を取ってMEANスタックと呼ばれるフルスタックJavaScript開発フレームワークをYeomanを使って素早くセットアップする方法について紹介。
そもそものMEANスタックとは何かについても理由を含めてきちんと紹介してくれています。

JavaScriptでキネティクス・スクロールを実現するためには – don’t code today what you can’t debug tomorrow

原題: JavaScript Kinetic Scrolling

EsprimaやPhantomJSの制作者として知られるAriya Hidayat氏による、パート4(パート5もあるそう)にまで及ぶキネティクス・スクロールについてのJavaScript実装に関する記事。iOSに見られるような自然なスクロールを実現するために必要な事柄を分かりやすく解説しています。

WalmartにおけるNode.jsセットアップ

原題: Walmart Mobile node.js Setup

PayPal社がバックエンドをJavaからNode.jsに移行したという記事が話題になっていましたが、この記事はアメリカ最大のスーパーマッケットチェーンであるWalmartにおけるモバイルサイトでのNode.jsのセットアップについて触れられています。ブラックフライデーを乗り越えたWalmartのセットアップは今後のNode.jsの可能性を感じることができるすばらしいリソースになるはずです。

クローズアップ“ビデオ/スライド/ツール”

The Need for Speed – Guillermo Rauch at dot.js 2013

今ではWordpressを運営するAutomattic社に買収された、クラウドシェアリングサービスのCloudupのGuillermo Rauch氏による、シングルページアプリケーションにおけるパフォーマンス改善のティップス集ともいえるスライド。

Faster JavaScript web apps – Alex MacCaw at Fronteers 2013

こちらはAlex MacCaw氏による、シングルページアプリケーションにおけるパフォーマンス改善に関する発表の動画。よくあるボトルネックについて丁寧に解説しており、シングルページアプリケーションに限らず利用できます。

CSS module system in Google+ – Shubhie Panicker at CSSconf.eu 2013

Google+は、どのようにCSSをモジュラー化しているのか。2013年の9月に、CSSconf.euにてShubhie Panicker氏により発表されたプレゼンテーションの動画。
単純に1ファイルにまとめるだけでは無駄が多いCSSのこれからの課題がここにあると思っているので参考に。

関連リンク: Your CSS needs a dependency graph – Techwraith

Project Hubs: デザイン・プロジェクトをどう管理するべきか – 24 ways

原題: Project Hubs: A Home Base for Design Projects

プロジェクト管理のツールは多く存在しているが、デザインに関しては便利なツールが存在しません。そこでBrad Frost氏は、Project HubsというシンプルなHTMLベースのツールを作りました。この記事ではそのProject Hubsが解決しようとしている問題とその解決方法について紹介しています。

関連リンク: bradfrost/project-hub

Web Browser Compatibility Tables – Cody Lindley

1％以上のマーケットシェアを持つブラウザについてどの機能が実装されているのかを一覧できるWebツール。
類似のツールは多くありますが、幅広い機能とブラウザについて一覧できるので非常に便利です。

SpinKit – tobiasahlin

Ajaxでコンテンツを取得する際や、巨大なテーブルデータをソートするような場合によく利用するローディングをCSSアニメーションで実現し、例示しているGitHubのレポジトリ。
現時点で7種のローディングのデモをこちらから閲覧できます。

Poly Maker – Aerotwist

ポリゴンシェープを生成するPoly Makerというツールの紹介。
今となってはややローファイさを感じるポリゴンを美しいカラーで表現しているツール。ツールそのものもすばらしいがどう作るかについての紹介のほうが興味深いです。

★次回の「斉藤祐也の海外WEBテク定点観測」は2014年2月3日にお届け予定です。★