HTML5 Experts.jpも開設から4年5カ月が経ちました。2017年もエキスパートやコントリビューターの皆様のご協力のお陰で、様々な技術トレンドをタイムリーに記事として取り上げることができました。皆様、お楽しみいいただけましたでしょうか？

今年最後の記事は、恒例の「2017年の年間読まれた記事ランキングTOP20！」をお届けします。このランキングは、記事公開後１週間の閲覧数を元に作成しております。冬休みに気になる記事を読み返してみてはいかがでしょうか。

年間読まれた記事ランキングTOP20

＜1位＞
Nintendo Switchの中ではReactが動いてる！Nintendo eShop開発秘話を聞いてきた
── 白石 俊平

＜2位＞
デイリーポータルZの林雄司さんと、ヨッピーさんに聞いた「コンテンツを作る・伝える・稼ぐコツは何ですか？」
── 馬場 美由紀

＜3位＞
これからのCSSはmargin禁止！？CSSグリッドレイアウトやコンポーネント指向なCSSについて、矢倉さんに聞いてきた！
── 白石 俊平

＜4位＞
フェイクニュース、キュレーションメディア、SEO…藤村厚夫、古田大輔、辻正浩がメディアとテクノロジーの未来を語る──Webの未来を語ろう 2017
── 白石 俊平

＜5位＞
ReactはなぜFiberで書き直されたのか？Reactの課題と将来像を探る　　　　　
── 白石 俊平

＜6位＞
「最近のWebパフォーマンス改善について知っておきたいコト」についてあほむに聞いてきた
── 白石 俊平

＜7位＞
「Web Componentsが来る！CSS設計はどうなる？」―CSSのエキスパートに聞いてみた！
── 白石 俊平

＜8位＞
日本最大級のHTTP/2移行、TLS 1.3、そしてQUICについてヤフーに聞いてみた！
── 白石 俊平

＜9位＞
de:codeで澤円さんが伝えたかった「エンジニアに必要なマネジメント」の真意とは？
── 馬場 美由紀

＜10位＞
Firefox, Chrome, SafariがCSS Gridに一斉対応ほか──2017年2月と3月のブラウザ関連ニュース
── 矢倉 眞隆

＜11位＞
Vue.js製フレームワークNuxt.jsではじめるUniversalアプリケーション開発
── 花谷拓磨

＜12位＞
ブラウザ戦争は終わった！Webの最先端と未来を、ブラウザエバンジェリストたちが語る
── 白石 俊平

＜13位＞
毎週新しい機能をリリースしている、はてな「Mackerel」の開発環境やツールを聞いてきた
── 馬場 美由紀

＜14位＞
Webブラウザで高速な演算を可能にする低水準言語asm.jsと、WebAssembly詳解ーasm.jsを高速に動作させる新しいコンパイラーターゲットWASMとは？
── 清水智公

＜15位＞
「マストドンを支える技術」をソーシャルウェブから探る（前編） 〜Mastodon Tech Night#1潜入レポート〜
── 仲 裕介

＜16位＞
フォント素人のWebエンジニアが、「フォントおじさん」に聞いてみた！Webフォントの最近の事情とか
── 白石 俊平

＜17位＞
抽象化を避けるCSS設計方法論「Enduring CSS」 第1回
── 高津戸壮

＜18位＞
「次のモバイルファースト」がやってくる！UIと機能設計をIonic 2を使って学んでみよう
── 榊原昌彦

＜19位＞
マイクロサービスは万能薬ではない──マイクロサービスの生々しい話を聞いてきた
── 白石 俊平

＜20位＞
2020年末でサポート終了するFlash Playerを支えた、Flashテクノロジーの全盛期と衰退を振り返ってみた
── 馬場 美由紀

※集計対象期間：2017/1/1 – 2017/12/27
※集計方法：集計対象期間中に公開された全ての記事の公開後1週間のPVをカウントしランキング付け

来年もよろしくお願いします

HTML5 Experts.jpは2017年も多くの方々にご愛読いただきまして、執筆陣・編集部共々感謝しています。ありがとうございました。来年も引き続き宜しくお願いします！

今回の記事は後編です。前編はこちら

今回は、エンジニア向けニュースアプリTechFeedの運営や当メディアの編集長も務める白石俊平さんが主催する、Mastodon Tech Night#1に潜入してきました（会場は株式会社リッチメディアさん）。主催の白石さんと、ソーシャルウェブに詳しく当メディアのエキスパートでもあるえーじさんお二人がメインスピーカーとして進行し、３名の方のライトニングトークで締めくくるという内容でした。

「マストドンを支える技術をソーシャルウェブから探る」という副題が付けられた当イベント、エンジニア（特にSNSやソーシャルアプリ開発者）であれば垂涎の「濃い」内容でした。では皆様お楽しみください。

本イベントの会場となった株式会社リッチメディアさん

今回の進行用スライドはこちらです。

今回の記事は後編です。前編はこちら

ソーシャルウェブのプロトコルを探る

白石 では次に、マストドン、というかソーシャルウェブを構成するプロトコルのお話に入りましょうか。

Mastodonを構成する３つのレイヤー（再掲）

えーじ OpenIDについては先ほど説明したので、次はやはりOAuthですね。

サービスをまたいで情報のやり取りを行いたいというニーズに答えるためには、外部サービスのAPI呼び出しを安全に行える必要があります。また、ユーザーが自分に関する情報をどのサービスに、どこまで公開するかと言ったアクセス権を設定したいというニーズも出てきます。 そこで登場したのがOAuthです。OAuthは、Twitterクライアントを作りたいという人たちの間で急速に普及しましたね。

OAuthはもう一般的なので、今はもうそんなことも意識せずに、みなさん利用していますね。「Facebookでログイン」「Twitterでログイン」と言った機能を持つサイトは、みんなOAuthを利用しています。

白石 そうですね。最初期の頃、TwitterのAPIってBasic認証だったので、みんながTwitterのパスワードを外部のサービスに入力していたという(笑) 牧歌的な時代でしたね。

えーじ そうですね(笑)

では次に紹介したいのはWebFingerという技術です。 この技術は、端的にいうと、ユーザーIDが分かれば、そのユーザーに紐付くプロフィールページやWeb APIなどの一覧を取得できるというものです。 「(API)ディスカバリ」の技術と言えますね。

例えば、以下のURLにアクセスしてみて下さい。

https://don.techfeed.io/.well-known/webfinger?resource=shumpei@don.techfeed.io

※ resource=より後には自分のIDを入力して下さい。ドメインはインスタンスに合わせて変えて下さい

えーじ 結果はJSONで返ってきますが、色々と情報がここに詰め込まれています。

※ここに表示しているのは筆者のアカウント情報です

linksの中身を参照すると、APIのエンドポイントURLや、APIの種別などの情報が詰め込まれています。 ユーザーIDさえわかれば、サービス上でそのユーザーに関する情報にアクセスするための様々なエンドポイントが分かっちゃうんですね。これがWebFingerです。

※筆者注: WebFingerは、様々なホストやホスト上のユーザーの情報を取得できるFingerコマンドになぞらえて命名されたと思われる。

links.relの中に、salmonやostatusと言った文字列が見え隠れしていますね。 これが、ソーシャルウェブを構成するプロトコルの名称ですね。

マイクロブログ関連のプロトコルを探る

白石 では次は、マイクロブログ関連の各種プロトコルの話に入りましょうか。 以下が、マストドンのドキュメントから引っ張ってきた、プロトコルの一覧です。 マストドンのコードを深く知るには、これらソーシャルウェブの技術に通じておく必要があります。

マストドン Tech Night#1進行スライドより

白石 それは先程までえーじさんが語っていたソーシャルウェブの世界がその先にあるからなんですね。 そして行き着くところは、マストドンどころか、様々なSNSが自動でディスカバリーし情報連携できる世界。 そんな分散型SNSの世界を実現するための構成要素がこのプロトコルたち、という位置づけです。

じゃあえーじさん、一つ一つを簡単でいいので解説をお願いします。

Atom、ActivityStreams、Atom Threading

えーじ まずは、Atomですね。これはご存じの方も沢山いらっしゃると思います。

これはRSSなどと同じく、フィード情報をXMLで表現する技術で、情報を時系列で発信する場合に適切なフォーマットであるといえます。 サイトの更新情報を発信するのによく使われています。

白石 Atom Publishing Protocolというのもありましたね。 Atom形式で情報をポストしたりできるようにする技術。はてなダイアリーのAPIとかは、AtomPubで構築されていたはずです。

えーじ このAtomを拡張して、サービス上のユーザーアクティビティを表せるようにしたものがActivity Streamsです。 Activity Streamsは、JSON版の仕様も用意されていて、JavaScriptとも相性が良いよう設計されています。

白石 あまり馴染みのない方も多そうですが、SNS上の行動の事を技術的には「アクティビティ」って呼ぶんですよね。 Facebookにも、自分のプロフィールページに「アクティビティログを見る」って機能があります。

えーじ そう、なのでActivity Streamsはそのアクティビティをストリーム形式で参照できる仕様ということです。 一般的なAtomが持つ情報に加えて、写真を取りましたとか、物を買いましたとか、何らかのアクションに紐付いた情報発信ができるのがActivity Streamsの特徴です。

白石 ちなみに、ActivityStreamsといえば、activitystrea.msというドメインだったのを覚えてます。 こういう風に名前とドメインをかぶせるやつ、昔流行りましたよね。

activitystrea.ms

えーじ Web2.0の時代に流行りましたねー(笑)

次はAtom Threadingですが、これはあまり私も詳しくないです。 想像ですが、誰かがポストした時にそれをスレッド化するものなんじゃないかなと思います（※）。

※RFCによると、「Atom内でスレッド状のディスカッションを表現するためのメカニズムである」（This memo presents a mechanism that allows feeds publishers to express threaded discussions within the Atom Syndication Format）だそうです。

OStatus

えーじ 次は、OStatusです。 例えばメンションやフォロー、リプライと言った機能がTwitterにはありますが、そういった機能を異なるサービス間で行えるようにする仕様です。

白石 さっきやったように、マストドン上で @ID@ドメインの形式でメンションとかを行うと、OStatusのプロトコルが動作するというわけですね。

えーじ はい、そうです。

他のユーザーに対してメンションを行うと、まず先ほどお話したWebFingerが動作して、他のインスタンスが持つAPIのエンドポイントを取得します。 その後、実際のAPI呼び出しが行われて処理が実行されるわけですね。

例えばこれは、/api/v1/statuses（ドキュメントへのリンク）というAPIを叩いて、パブリックトゥートの情報を表示したところです。

※記事では適当なトゥートを題材にしています

えーじ mentions や inreply_to 等のキー情報がありますよね。メンションやリプライがあるとここに情報が格納されますが、これがOStatusをはじめとする様々な仕様によって付与された情報なんです。 「プロトコル」と言われるとなんだか仰々しいもののように感じてしまうと思いますが、実際にはこういうシンプルな処理を定義しているだけなんですね。

Salmon

えーじ 次はSalmonです。Salmonは逆流するという意味合いで使われています。鮭なので川を遡上しますよね。別のインスタンスでコメントが付いた場合に、自分のインスタンス上に「戻ってくる」仕組みを提供しています。 ぼく、これ以上のことは知らないんですが、何かご存知ですか？

Salmon Protocol

白石 いやー、知らないですね。 ただ、昔調べたのは覚えてます。2010年くらいに、DaVinciPadっていうサービスを一人で作っていたんですが、このプロトコルを使いたかったんですよね。 メモ＋SNSへのマルチポスト機能があって、そのポストへのリプライをツール上でキャッチアップしたかったんですよ。まぁ、だれも知らないことなんですが(笑)

えーじ あー、DaVinciPadって作ってらっしゃいましたね。なつかしい。

ちなみに、一つ懸念していることがあるんですが、Salmonをはじめこういうプロトコルって基本的に思想が古いんですよね。 XMLベースの仕様が多いことも含め、今のWebに最適化されていないんです。登場から7年も経っているわけなので、大量のトラフィックを捌いていくには、仕様をアップデートしていく必要があるんじゃないかなと考えています。

Portable Contacts

えーじ 次はPortable Contactsですね。これはIdentityに関係するものですが、友達リストを交換するためにフォーマットを合わせるための仕様です。 確か、GoogleにはPortable ContactsのAPIがあって、Gmailのアドレス帳のデータもPortable Contactsの形式で取得できます（残念ながら終了済み）。

白石 なるほど、フォロー／フォロアーのリストとかをやり取りするための汎用的な仕様ですね。 SNSが持つ様々な機能を細切れにして、それぞれ標準化したという感じを受けます。

えーじ その解釈は正しいと思いますよ。汎用的になるように、そして一部だけでも利用できるように、あえて細かく仕様を分けていったという感じじゃないでしょうか。 一つ一つの仕様は小さいのですが、まとめて組み合わせると理路整然としている感じです。

白石 なるほどー。でも、よくこれだけバラバラな、策定している団体や企業も様々な仕様を、うまくつなげることが出来ましたね。 当時、ソーシャルウェブはそれだけのムーブメントだったということですね。

PubSubHubbub、WebFinger、Link-based Resource Descriptor Discovery

えーじ 次は、PubSubHubbubです。 PubSubHubbubはいわゆるリアルタイム通知の仕組みです。サブスクライブしておくと、ハブを介してプッシュ型でメッセージを送ってもらえる。

白石 ちょっと補足すると、RSSなどのフィードって、基本的にはポーリングで取得します。15分に1回とか、30分に1回とか。 でも、更新がなくて空振りすることも多い。それじゃ効率が悪いということで、PubSubHubbubはサイト側からサブスクライバーに向けてプッシュで更新を通知するという仕組みでした。

こないだ、W3Cが急に標準化を進めて、「WebSub」と言う仕様でCandidate Recommendationにしたのはびっくりしました(笑)

WebSub

えーじ 残るはWebFingerとLink-based Resource Descriptor Discoveryですが、WebFingerは先ほどご説明したように、ユーザーやサービスに関する様々な情報を参照するためのプロトコルです。 Link-based Resource Descriptor Discoveryは、サーバ上に置く /.well-known/host-meta というファイルのフォーマットに関する仕様で、WebFingerのURLもこのファイルを参照して取得することができます。

※筆者注: 例えば don.techfeed.ioのhost-metaは https://don.techfeed.io/.well-known/host-metaにアクセスすると参照することができ、その中にWebFingerに関するURLも含まれている。以下がhost-metaファイルの内容。

<?xml version="1.0"?>
<XRD xmlns="http://docs.oasis-open.org/ns/xri/xrd-1.0">
  <Link rel="lrdd" type="application/xrd+xml" template="https://don.techfeed.io/.well-known/webfinger?resource={uri}"/>
</XRD>

マストドンはソーシャルウェブの理想を実現するか？

白石 ソーシャルウェブのプロトコルに関しても一通り眺めたところで、だいぶソーシャルウェブのスタックや、マストドンに関する理解も深まったように思います。 ではそろそろまとめに入りたいと思うんですが、昨今のマストドンブーム、そしてソーシャルウェブを振り返って、思うところがあればお聞かせください。

えーじ そうですね、まずソーシャルウェブの目指すところは、ウェブ上にアイデンティティのレイヤーを築くということ、その上で、サービスをまたいだコミュニケーションを実現するということにあると思います。 マストドンの流行は、そういう世界の実現を後押しするかもしれないと期待しています。

白石 なるほど。ソーシャルウェブの時代はまだまだこれからだ、と。

えーじ まあでも、ソーシャルウェブの理想が完全に実現するか…っていうと道は遠いだろうなあ、と思っているのが正直なところです。

今はとにかく、マストドンが流行ると良いなと思っています。熱狂していた頃から7年も経っているので多少は落ち着いたというか、あんまり純粋に理想を追い求めても、というか…何て言うんだろう。

白石 原理主義？

えーじ ああ、それだ。ソーシャルウェブ原理主義(笑) そういう原理主義的な思想は今は少し収まっていて、とりあえずマストドン流行ればいいや、マストドンが流行れば結果的にソーシャルウェブが流行ることに繋がるし…と、そんな風に感じているというのが正直なところです。

「マストドンの技術を応用して、既存サービスで何ができるか」を考えるのは面白い

白石 ほか、「マストドンの技術を応用して、既存サービスで何ができるか」って話もしたいとおっしゃってましたが、こちらはどうですか？

えーじ そうそう、ソーシャルウェブの技術って、ウェブをベースに考えられているので、既存のサイトとかに組み込むのは実はそれほど難しくないんですよ。 例えばメディアが吐いてるRSSフィードをAtomベースのActivity Streamsに変えたりするとか、そんなちょっとした変更を加えていくだけで、マストドンとコミュニケーションできるようになるかもしれないんです。

白石 なるほど。メディアが1マストドンインスタンス、もしくはマストドンユーザーにもなりうるということですね。

えーじ そうです。白石さんがやってらっしゃるTechFeedとかも、マストドンの技術を取り込む価値はあるんじゃないかと思いますよ。 この会場にいらっしゃる方々も、すでに何らかのサービス開発に取り組んでいらっしゃる方が多いと思いますが、そこにマストドンやソーシャルウェブを組み合わせるとどういうことになるか、ちょっと想像してみるのは面白いと思います。

ちなみに、前にフランスでもマストドンの流行の波が来ていたみたいなのですが、日本はそれの何倍もの大きな波がきているみたいです。 Twitterとかで、英語でこのことをつぶやくと、みんなその理由を知りたがるという状態です。 このままマストドンの活用でも一歩先んじて、マストドン先進国、もっと言えばソーシャルウェブの先進国になれたらいいな…なんてことを思ったりしています。

白石 なるほど、すごく夢のある話ですね…！えーじさん、今日はマストドンとソーシャルウェブについて、とことんまで深く付き合っていただき、ありがとうございました！

ライトニングトーク

えーじさんと白石さんの対談のあとは、ライトニングトークで締めくくりました。

Meganedonやってみた。

meganedonという独自インスタンスを立ち上げてみた話でした。運用する上で重要となるティップスが５分間のLTに濃縮されています。

ソース読む 今日のテーマは Mastodo

マストドンのソースコードを読むためにFreeBSDでインスタンスを立てた話。マストドンのソースコードを追いかけるためノウハウがわかりやすく解説されました。

マイ丼 ５分間　クッキング

TechFeedのCTOである、dsukeさんのLTで、AWS上でTechFeedonを立てた話が紹介されました。ソースコードもGithubで公開中とのこと。

https://github.com/techfeed/techfeedon

最後に

皆さん、いかがだったでしょうか？ 今大人気の分散型SNSマストドンですが、マストドンの裏側に見え隠れしているソーシャルウェブの思想や各種プロトコルについて、垣間見ていただくことは出来たでしょうか？ マストドンは単に流行りのサービス…というわけではないことがご理解いただけたと思います。マストドンに触れる際は、マストドンが実現しようとしている古くて新しいソーシャルウェブの世界観について是非思いを巡らせてみて下さい。

今回の記事は後編です。前編はこちら

今回の記事は前編です。後編はこちら

今回は、エンジニア向けニュースアプリTechFeedの運営や当メディアの編集長も務める白石俊平さんが主催する、Mastodon Tech Night#1に潜入してきました（会場は株式会社リッチメディアさん）。主催の白石さんと、ソーシャルウェブに詳しく当メディアのエキスパートでもあるえーじさんお二人がメインスピーカーとして進行し、３名の方のライトニングトークで締めくくるという内容でした。

「マストドンを支える技術をソーシャルウェブから探る」という副題が付けられた当イベント、エンジニア（特にSNSやソーシャルアプリ開発者）であれば垂涎の「濃い」内容でした。では皆様お楽しみください。

本イベントの会場となった株式会社リッチメディアさん

今回の進行用スライドはこちらです。

今回の記事は前編です。後編はこちら

マストドンのおさらい

白石 皆様こんにちは！本日は「Mastodon Tech Night#1 〜マストドンを支える技術をソーシャルウェブから探る〜」にお越しいただきまして、誠にありがとうございます。

まず最初にお聞きしたいのですが、マストドンのアカウント作った方ってどれくらいいらっしゃいますか？
…ほとんどの方が作ってきてらっしゃいますね。さすが皆さん、予習バッチリですね。

では皆様には「釈迦に説法」になってしまいますが、まだ話題になって間もないサービスでもありますし、マストドンの主要な機能についての軽いおさらいから入りたいと思います。

白石さん

白石 まずは、マストドンのREADME.mdより主要な機能のおさらいです。 開発者自身からすると、マストドンの特徴はこういうところにあるという主張が伺えます。 時間がない中で適当に訳したので、こなれてないのはどうかご容赦ください。

• GNU socialや、あらゆるOStatusプラットフォームと完全な相互運用性がある（Fully interoperable with GNU social and any OStatus platform）
• リアルタイムなタイムライン更新（Real-time timeline updates）
• 連合したスレッド解決（Federated thread resolving）
• 画像やWebMなどのメディアを添付可能（Media attachments like images and WebM）
• OAuth2と直感的なREST API（OAuth2 and a straightforward REST API）
• 長時間かかるタスクのバックグランド実行（Background processing for long-running tasks）
• Dockerでデプロイ可能（Deployable via Docker）

一方、ぼくらユーザーからすると、マストドンの主要な機能って、Twitterと比較するとわかりやすいんじゃないかと思います。 Twitterにも存在する機能としては以下の様なものがありますね。

• ユーザーフォロー
• コミュニケーション（ステータス更新、リプライ、スレッド）
• ハッシュタグ
• タイムラインのリアルタイム更新
• アカウント管理
• OAuthプロバイダー
• WebAPIを利用可能
• …

そして、マストドンならではの機能と言えるのは以下の様なものでしょうか。

• 連合タイムライン
• リモートフォロー
• …

連合タイムラインは、別のマストドンインスタンスからのタイムラインも合わせて表示するもの。リモートフォローは、他ののマストドンインスタンスのユーザーをフォローする機能です。このあたりは、分散型のSNSであるがゆえの機能ですね。

マストドンのコードツリーを眺める

白石 次に、マストドンのGithubリポジトリをざっくり眺めていくとしましょう。

実はぼく、RubyもRailsもほとんど知らないのですが、どうやら色んな人の話を聞く限り、割と素直なRailsアプリになっているみたいです。

マストドンのソースツリー

そこでサービスのコードを読んでみると、すぐに「WebFinger」とか「PubSubHubub」とか、ソーシャルウェブを追いかけていた人にとっては懐かしい単語がたくさん出てくるわけですね。 例えばリモートフォローのコードを読むと、webfingerという単語が出てくる。

どうやら、マストドンはソーシャルウェブと深いつながりがあるようだと。そこでぼく、すぐにえーじさんに連絡して、このイベントの企画を相談したわけです。 では、前置きはここまでにして、ここからはソーシャルウェブの専門家であるえーじさんを交えて、マストドンとソーシャルウェブのつながりを探っていきたいと思います。

マストドンを構成する3つのレイヤー

白石 えーじさん、まずは自己紹介からお願いします。

えーじ えーじです。8年ぐらい前、前職でOpenSocialをはじめとしたソーシャルウェブ技術全般に関わっていました。Social Web Japanというコミュニティも運営していて、ソーシャルウェブに関する勉強会も活発に開催していました。

白石 OpenSocial（※）って言葉を知っている方はどのくらいいますか？ この会場だと半分弱くらいですね。

※OpenSocial…SNSのWeb APIを統一しようとする標準化の動き、及びその仕様。日本でもmixiやGREEを始めとした主要なプラットフォームが対応し、ソーシャルゲーム／ソーシャルアプリの流行に大きく寄与した。

えーじ マストドンって、実は2010年ぐらいに盛り上がったものがベースになっている面があるので、個人的にはタイムトリップしたような感覚ですね(笑)

まずこの図を見て下さい。私は、マストドンは3つのレイヤーから構成されていると捉えています。

マストドン Tech Night#1進行スライドより

この図には出てきていませんが、一番下にはインターネットのレイヤーが存在します。

その上にIdentityというソーシャルウェブを構成するレイヤが重なり、その上にOStatus等のマイクロブログを構成するプロトコルがある。それらの上にマストドンがあるという図です。 逆に言えば、マストドンはOStatus、Identityというレイヤを取り除いてしまうと、ただのTwitterクローンになってしまうと思っています。

白石 なるほど。ソーシャルウェブの専門家から見ると、マストドンはむしろOStatusやIdentityなどの下位レイヤー、つまりソーシャルウェブのスタック上に構成されていることが重要なわけですね。

ソーシャルウェブとは何か？

白石 じゃあ、その「ソーシャルウェブ」って何かということが大事になるわけですが、簡単にご説明願えますか？

えーじ そうですね、じゃあちょっとSNSの歴史も振り返りつつ。

今では、SNSと言えばFacebookやTwitterを思い浮かべると思いますが、2004年くらいから始まった「Web 2.0」と呼ばれていた時代には、Myspaceや、Friendster、mixi、Google buzzなどの様々なサービスが存在していました。 今のような寡占状態じゃなかったんです。

その初期で登場した、当時としては画期的な機能があったんですが、なんだと思いますか？

白石 なんでしょう？SNSが出始めの頃ですよね…？とりあえずめっちゃ楽しかったですね(笑)

えーじ それはそうですけども(笑) 画期的だったっていうのは、招待機能です。招待機能を使ってリアルの知り合いを招き入れる事ができました。

白石 ああそういえば、mixiなんかも最初招待じゃないと登録できませんでしたよね。

えーじ 招待機能っていうのは、リアルな人間同士の関係性をネットに持ち込むってことで、すごく画期的だったんですよね。それはつまり、ネットに人格や人間関係を持ち込むということなんです。

それまでのWebでも、もちろんユーザーはサービスごとにIDを持っていましたが、そのIDは他の人とデータを区別するためのものでしかなかった。SNSではそのIDに、実際のユーザーのプロフィールを紐づけさせた。つまり、リアルワールドの人間とSNS上のアカウントが紐付くことで、ネット上に人間のアイデンティティ（人格）を持ち込んだんですね。

白石 なるほど。それが先ほどのレイヤー構成図で言うところの「Identity」に相当する部分ですね。

えーじ はい、そこの課題意識が、OpenIDなどの認証技術の発展につながりました。ここらへんはあとでまた詳しく述べたいですね。

そして、更にSNSが発展してくると、今度はSNSをまたいで情報をやり取りしたい…というニーズも生まれてきました。 例えば、TwitterからFacebookにつぶやきを送りたいというような。 その象徴的なサービスがFriendFeedでした。

白石 懐かしいですねー。みなさん、FriendFeed覚えてますか？覚えてる人手を上げてください。 …あれ、ほとんどいない(笑)

FriendFeedはFacebookに買収されて、静かに終わってしまったサービスですね。

えーじ はい。これは複数のSNS上での情報を一つにまとめるサービスでした。こういうサービスの登場からもわかる通り、サービス間で情報をやり取りしたいというニーズは確実にあったし、今もある。 そこから発展したのが、先ほどのレイヤー図で言うところの下から二番目の層、「OStatus」などのプロトコルから成るレイヤーです。

白石 なるほど、SNSの発展の歴史とともに、Identityやプロトコルが発展してきて、それがソーシャルウェブと呼ばれるスタックを構成するようになったということですね。 そして、マストドンはそのスタック上に構築されたサービスであると。

マストドン同士が情報をやり取りする世界は、ソーシャルウェブとしてはまだまだ序の口

白石 では、マストドンはソーシャルウェブの一実装だとすると、実は他のサービスとも連携できたりするんでしょうか？

えーじ はい、そのとおりです。その証拠に、マストドンはGNU socialとも互換性があるんです。

白石 あ、それってさっき紹介したマストドンのREADME.mdにも「GNU socialと相互運用性がある」と記載されていましたね。 GNU socialってなんなんですか？

GNU social

えーじ 一言で言うと「ソーシャルウェブ関連仕様の参照実装」ですね。

具体的に言うと、ソーシャルウェブの標準化にあたっては、W3C（※）にあるSocial Web Working Groupというグループが中心となって進めています。 最初は、SNS間の相互運用性を議論する目的で、status.netというサイト上で進められていたんですけどね。

そこで策定が進められた様々な仕様の参照実装 (Reference Implementation)という位置づけのサービス、それがGNU socialなんです。

GNU socialも、マストドンと同じく、自前でインスタンスを立てることもできる。それを使ったインスタンスもいっぱいありました。例えば、quitter。 これ、一昔前のTwitterとUIもそっくりだし、やれることもほぼ一緒です。

Quitter

※ W3C（World Wide Web）…本誌の読者にはいわずもがなではあるが、ウェブの標準化と発展を促進するための標準化団体。

白石 おお、こんなのあったんですね。思想的にはほとんどマストドンと変わらないじゃないですか。

えーじ そうなんです。ただ、サービスとしては動作が遅くて、使うのはかなりストレスフルでしたけどね。 quitterと比較してマストドンが流行ったのは、誰でも簡単にデプロイできる、そして快適でストレスなく利用できることだと思います。

で、quitterはGNU socialのインスタンスなので、マストドンとも繋がります。マストドンのアカウントをフォローしたり、メッセージを送ったりもできるんですよ。

白石 おお、それはすごい。なるほど、マストドン同士がやり取りできるのは当たり前に思えますが、ほかのソーシャルウェブ実装ともやり取りできるのはすごいですね。

えーじ ちなみに、ソーシャルウェブの実装と言えば想い出深いのはGoogle buzzです。Google buzzって覚えていますか？

白石 ぼくは覚えてますが、皆さんどうでしょう？…7名ぐらいしか手が上がりませんね。みんな忘れちゃったんだなあ。

えーじ Google buzzってGmailの一部として登場したし、皆さん一度は目にしたことあると思うんですけどね。 個人的には、Google buzzが出てきたときには大興奮でした。ソーシャルウェブの集大成をGoogleが出した！これはすごい！って。

白石 えーじさんが興奮してたのは、今でもはっきり覚えてます(笑)

えーじ 例えば今でもGoogle buzzが存在したなら、buzzからマストドン上の誰かをフォローしたりできていたかもしれないんです。 それだけじゃなくて、ソーシャルウェブのスタックを実装したどんなサービスとも連携できたはずなんです。

そういう世界を実現したいと思っている人は今でもいて、その人たちがW3C Social Web Working Groupを形作っているというわけです。

白石 じゃあ、今のマストドン同士が情報をやり取りする世界は、ソーシャルウェブとしてはまだまだ序の口で、ソーシャルウェブスタックを実装したサービス同士が自在に情報をやり取りできる世界というのが、ソーシャルウェブの目指す最終地点であり、実現したい世界観ということですね。

アイデンティティ、OpenID、そしてNASCAR問題

白石 では、マストドンで実現されているソーシャルウェブスタックについて、具体的なお話を伺っていきたいと思います。 まずは先ほどのスタックでいう一番下、アイデンティティのところからお聞きしたいです。

Mastodonを構成する３つのレイヤー（再掲）

えーじ まず、ソーシャルウェブでアイデンティティのレイヤーを語るにあたっては、 OpenID 抜きには語れません。

SNSの登場により、Web上で人々がアイデンティティを持つようになりましたが、そのアイデンティティがサービスごとに分断されてしまっていることが問題でした。 例えば、今Twitterを使っているとしましょう。「私はえーじです。」とネット上で表したい時、皆さんはどうしますか？

白石 TwitterのIDをシェアするとか？

えーじ そうですね。Twitterの◯◯、Facebookの◯◯、Google+の◯◯です。というように、各サービスに紐付けざるを得ません。

白石 サービスに関係なく、「私は私です」ということが言えないってことですね。

えーじ そうです。Web上でユニバーサルに「私は私です」と言えないんです。 また、サービスごとに認証情報を作成しなくてはならないのも問題でした。ユーザーとしては、一つのIDで様々なサービスにログインできるほうが便利です。

そこでOpenIDは、URLを利用してユーザーを識別できるようにしたんです。そして、そのURLさえ入力すれば、どんなWebサービスにでもログインできるようにするのが、OpenIDの目標でした。

白石 でもその「URLを入力する」っていうのが、実際にはめんどくさくてあまり流行らなかった印象があります。 ぼくは、OpenIDを利用しているサービスと言えばリクルートさんの「ATND」を思い出すのですが、ATNDにアクセスするとOpenID（一部OAuth）に対応したサービスプロバイダの一覧が出てきて、それを押すといろんなサービスのIDでログインできるという仕組みでした。

ATNDのログイン画面（現在のものです）

あれは、裏ではOpenIDのURLを生成してそこにアクセスしていましたよね。 ATNDにログインした人はたくさんいると思いますので、実際には皆さんOpenIDを使っていたという。

えーじ ATNDはOpenIDの普及に貢献しましたね。 でも、ああやってサービスのロゴを並べるのは、OpenIDの思想からすると問題だったんですよね。 それって、NASCAR問題って言われていたんです。

白石 NASCAR（※）？

えーじ ああやって企業やサービスのロゴを並べるのって、モータースポーツとかで、スポーツカーにべたべたと企業ロゴが貼られているのに似てるからそういう名前になったんです(笑) 今でもTwitterやFacebookのロゴを並べておくのは普通ですけどね。 ユーザーとしては、OpenIDのURLを入力するよりも便利なのですが、もともとのOpenIDの思想…サービスとアイデンティティの分離、からは後退してしまいました。

※NASCAR…Wikipediaによれば、「NASCAR（ナスカー、National Association for Stock Car Auto Racing, 全米自動車競争協会）は、アメリカ合衆国で最大のモータースポーツ統括団体であり（本部はノースカロライナ州シャーロット）、同団体が統括するストックカーレースの総称でもある。」とのこと。

マストドンの画期的なコンセプトの一つは、IDをメアド形式で指せるようにしたこと

えーじ 一方マストドンの素晴らしいところは、IDをメールアドレス形式の username@domain の形にしたところだと思います。 この、馴染み深くて簡潔な形式で、あらゆるマストドンインスタンス上のユーザーを指し示せるようにしたことが、サービス全体の使い勝手を大きく向上させている。

白石 そう言えばマストドンって、その形式のユーザーIDを使って、別のインスタンスのユーザーにメンションってできるんですよね？

えーじ できます、できます。ちょっとやってみましょうか。マストドンはテキストボックスに@id@domainと入力用とすると候補が出てきます。他のインスタンスのユーザでも出てきますね。ちなみに、このオートコンプリートは、マストドンの機能ですね。こういうところが、マストドンの洗練されているところだと思います。

マストドンでは、リモートフォローしたユーザーのIDも自動補完される

白石 なるほど。もしこれがOpenIDそのままだとしたらURL直打ちということになっていたかもしれないし、それだとオートコンプリートさせるっていうのもUI的に少し難しそうです。 IDをメアド形式で指せるようにしたことが、マストドンの画期的なコンセプトの一つということですね。

後編に続きます。

HTML5 Experts.jpも開設から3年5カ月が経ちました。2016年もエキスパートやコントリビューターの皆様のご協力のお陰で、様々な技術トレンドをタイムリーに記事として取り上げることができました。また、白石編集長と豪華なパネリストによる対談企画や、実際に企業にお邪魔し、開発スタイルについてエンジニアの方々に直接話を聞いちゃうインタビュー企画にも挑戦しました。皆様、お楽しみいいただけましたでしょうか？

今年最後の記事は、恒例の「2016年の年間読まれた記事ランキングTOP20！」をお届けします。このランキングは、記事公開後１週間の閲覧数を元に作成しております。冬休みに気になる記事を読み返してみてはいかがでしょうか。

年間読まれた記事ランキングTOP20

＜1位＞
モバイルWebのUIを速くする基本テクニックがわかる──Google I/O 2016 High Performance Web UI
── 川田寛

＜2位＞
Qiitaのスライドモードは、mizchiが勝手に作った！？─Incrementsの縛られない開発スタイルを聞いてみた
── 馬場 美由紀

＜3位＞
もう、アルゴリズム自分で書いてる場合じゃない？機械学習が開発手法を変える─de:code 2016セッションレポート
── 白石 俊平

＜4位＞
Reactの最新動向とベストプラクティス ── HTML5 Conference 2016セッションレポート
── 小林徹

＜5位＞
Angular 2で10万行書いた人にナマの声を聞く─奥野賢太郎×白石俊平
── 白石 俊平

＜6位＞
React vs Angular 2ガチ対決！エキスパートたちによるハイレベル対談 (1 / 2) ー TechFeed Live#2レポート
── 白石 俊平

＜7位＞
Googleが新たに提唱するProgressive Web Appsの新たな開発パターン「PRPL」とは？
── 小松 健作

＜8位＞
プログレッシブウェブアプリ詳解 ─ 過去・現在・未来
── えーじ

＜9位＞
JSだけでVRできる！『WebVR』ことはじめ
── 比留間 和也

＜10位＞
この1年、Webのパフォーマンスで変わったことは？──HTML5 Conference 2016
── 川田寛

＜11位＞
及川卓也さん、河合良哉さんに聞いた「地方で日本で働く・海外で働くの話」（その２）──HTML5 Conference 2016セッションレポート
── 加藤拓明

＜12位＞
de:code参加者アンケートトップ！Microsoft澤円氏が語った「クラウド心配性な上司を説得するコツ」とは？
── 馬場 美由紀

＜13位＞
MS変革の立役者ナデラCEOが日本に来た！なんかマイクロソフトカッコいいぞ！ – de:code 2016基調講演レポート 止まらないMicrosoftの変革：デベロッパーと共に 〜 de:code基調講演レポート 〜
── 白石 俊平

＜14位＞
Webブラウザで高速な演算を可能にする低水準言語asm.jsと、WebAssembly詳解ーJavaScript が動く仕組み
── 清水智公

＜15位＞
React及びその周辺技術、事例から見るReact最新情報！──HTML5とか勉強会イベントレポート
── 佐川 夫美雄

＜16位＞
Webの最先端では何が起こっているか、今Googleが取り組んでいることは？──Google I/O 2016セッションレポート【後編】
── 河合良哉

＜17位＞
夏野剛・及川卓也・白石俊平が語る「WebRTCが切り拓く2020年のIoT」～リアルタイムコミュニケーションがもたらす破壊的イノベーション～
── 馬場 美由紀

＜18位＞
今、Webの最先端では何が起こっているのか？──最新機能目白押し！Google I/O 2016セッションレポート【前編】
── 河合良哉

＜19位＞
モダンWeb：たった今と、ほんの少し未来のはなし～「de:code 2016」セッションレポート～
── 佐川 夫美雄

＜20位＞
Electronプログラミング入門 — インストールからミニブラウザ構築まで
── 古川陽介

※集計対象期間：2016/1/1 – 2016/12/27
※集計方法：集計対象期間中に公開された全ての記事の公開後1週間のPVをカウントしランキング付け

【番外編】HX今年の顔

HTML5 Experts.jpには、エキスパート・コントリビューターの方々紹介ページがあります。今年も、紹介ページの中で今年もっともアクセスされたエキスパート・コントリビュータートップ３を集計してみました。題して、HX今年の顔!

今年は、昨年トップの白石編集長をおさえて、WebRTCの記事を執筆していただいたがねこまさしさんがトップでした。

＜1位＞
エキスパート がねこまさし さん

＜2位＞
白石 俊平 編集長

＜3位＞
エキスパート 高津戸壮 さん

来年もよろしくお願いします

HTML5 Experts.jpは2016年も多くの方々にご愛読いただきまして、執筆陣・編集部共々感謝しています。ありがとうございました。来年も引き続き宜しくお願いいたします。

こんにちは。編集部の仲です。de:code 2016はいかがでしたか？

この記事では、初日の最後に行われた、Microsoftのエバンジェリストであり「エバンジェリスト養成講座」などで有名な、西脇資哲さんのセッションをご紹介します！ AI、ドローン、ロボティクス、そしてテスラ Model Sまで会場に登場した、盛りだくさんのセッションでした。

Twitterのライブ配信

筆者が前回西脇さんのセッションを聴講した時も同じことをやっていたため、もはや恒例となっていると勝手に思ってますが、セッション中、Twitterにハッシュタグをつけてつぶやくと、前方スクリーンにその様子が表示されるという、イカした趣向が用意されていました。その日一番多くつぶやいた方には最後にプレゼントがあるとのこと。

ウェアラブルデバイス

最初のテーマはウェアラブルデバイスです。会場では、IoT☓医療現場での活用例として、Microsoft Band 2を利用したデモが披露されました。

このデモでは、Microsoft Band 2で西脇さんの皮膚の表面の汗の量や心拍数等を収集。BluetoothでRaspberry Pi（OSはWindows 10 IoT）に転送し、そこからSoracomのSIMでAzureにアップロードされます。アップロードされたセンサーデータは Motion Board Cloud というサードパーティのサービス(Azure上で稼働)を利用して、活動量という形で表示しているそうです。活動量は100を超えるとちょっと落ち着きないな、というぐらいの指標になるんだとか。

これが実際にどのようなシーンで活用されるのか、１つ例が紹介されました。

我々の国を含め、先進国は医療費の高騰が問題となっています。そのための対策として、患者さんに積極的に在宅医療をすすめるという試みが行われています。在宅医療をすすめるべきかどうかの判断について、今までは医者が個別に診察を行い、膨大な時間をかけて判断（トリアージュ）していました。

この活用例では、IoTデバイスからの生体情報や、過去の病歴、類似治療比較を基にマシンラーニングによって、各患者さんのシビリティレベル（治療が必要か否か）を自動判別しています。画面右側の上位に表示されている患者さんは緊急度が高い（すぐに治療が必要な）患者さんであると判断できます。

医療の現場ではIoTを活用して、このような自動化が行われているという事例の紹介でした。IoTデバイスとAzure、ソフトウェア・パッケージなどを開発者の皆さんが自由に組み合わせて、様々なソリューションを実現することができるため、是非チャレンジしてほしいとのこと。

ロボティクス

次の題材はロボティクス。今回のセッションでは基調講演でも出てきたPalmi（パルミ）君とPepper君が登場しました。

Palmi君

今回のデモは、西脇さんの予定を取り込み受付を行うデモでした。このデモはOfice365と連携しているそうです。その他、ドリンクオーダーのデモとして、パルミくんが音声認識しその結果をExcel Onlineのスプレッドシートに自動入力するデモや、音声認識したデータを、別のサービスで書かれた議事録に添付する等、ロボティクスとクラウドサービスを連携したデモが披露されました。

Pepper君

次はPepper君を利用した見守りを行うデモです。ある空間の見守りをPepper君にお願いすると、音楽に合わせてるんるん踊る感じで見守り。見守り中に目の前で起きたことを画像認識等を活用して把握し、事後報告するというもの。写真では伝わりませんが、とても面白いデモでした。また、認識精度もかなり高いです。

自動車

次は自動車です。今回はなんと、会場内にあのテスラの実写が持ち込まれていました。西脇さんいわく、内燃機関を積んでいるクルマをイベント会場に入れるためには消防法の関係などで、いろいろな制約があるそうです。しかし、テスラは電気自動車で内燃機関がないため、大型のコンピュータを導入するのと手続き的には変わらなかったということ。

今回はテスラをMicrosoft Bandから操作するデモが披露されました。仕組みはテスラに持ち込まれているSurfacesがコンパニオンデバイスとして機能しており、そのデバイスに対して、様々なアクションを与えることでテスラを制御、また、テスラから得られた車両情報をデバイスを通して収集し、クラウドにアップしたりすることが可能ということです。

このコンパニオンデバイス上のアプリは、C#やJavaでアプリケーションを書くことができるそうです。現在テスラは、安全性の面等から、サードパーティ制のアプリを認める（導入する）ことはやっていないそうですが、この取組には非常に大きな可能性があると、西脇さんは付け加えました。今まで、車両の制御等を自由にするということは難しかったが、Surfacesで.netやJavaを使いこの車両を自由にコントロールし、クラウド上から操ることが可能になる。非常に大きな可能性を秘めていると言っても過言ではないと付け加えました。

そして、もうひとつ、テスラに関するデモが行われました。テスラを持っている人が一番悩ましいのは、実は充電スポットを探すことだと西脇さんは言います。テスラは走行用バッテリーとしては、一般家庭1週間分の電気容量を蓄えているそうですが、実際に走行するとバッテリーの消費量は激しいのが事実。バッテリーを充電するための充電スポットを検索するアプリとして、EVSmartというものが出ているそうです。このアプリはXamarinで開発されているとのこと。

Xamarinを商用環境で積極的に活用してほしいと締めくくりました。

鉄道

次は、鉄道ということでNゲージが登場。鉄分が高まってきましたー。余談ですが、このジオラマは銚子電鉄をモデルにしているそうです。

このNゲージのデモでは、Windowsタブレット上のXamarinで開発されたアプリから電車を制御します。Nゲージをコンピュータから制御するというのはわりとありふれたことかもしれませんが、このデモで一番重要なのは、センサーを利用して在線検知（鉄分が高い言葉かもしれないがお分かりいただけるだろうか？）を行っているということでした。

仕組みは、線路上に電流を計測するセンサーを設置し、電車が通過すると電流が流れるため、その状態を検出して、電車が線路のどの部分に存在するのか判定するという。このデモでは、電流の情報はAzure IoT Suiteで収集し、タブレット上のアプリでそれを表示しているそうだ。（画面上部オレンジ色に変わっている部分が在線している位置）この仕組は、デモのために作ったわけではなく、今後実際の鉄道でも使われようとしている技術だという。

実際この技術を応用するとどんなことができるかといえば、速度・走行位置のリアルタイム表示も可能になるため、現在、人が電車の運行を集中管理しているところを、一部コンピュータに任せることができるかもしれないという。これに車両本体のセンサ情報（人がどれだけ載っているか等）を加えてマシンラーニングと組み合わせれば、実現できる可能性がある。可能性が広がっていると締めくくった。

船舶

次は、船舶について。まず最初にある動画が流されました。船舶の位置情報（AIS）は公開情報になっており、この情報を使って、Azure、マシンラーニング、PowerBIを組み合わせて、東京湾のすべての船舶位置の表示とすべての船舶の航行進路予測を行い、その結果から衝突予測を行い、必要な船舶に回避命令を出したり新しい航路を指示するというのを実現したそうです。この画像はその時の動画の一部です。

（とても良く出来た動画でしたが、おそらく公開されてないと思われます）

東京湾は世界でも有数の過密航路区間となっており、衝突事故が発生しないように、通常は東京湾に入ってくる大型船舶にはタグボートが付くことになっているそうです。しかし、小型の船舶はそんなことが出来ないため、それを解決するために、マイクロソフトと中央省庁で一緒に行った取り組みが、この動画だという。

船舶の安全は古くは灯台の明かりと人間の判断によって守られてきました。それが、無線になり、レーダーになり、ITの技術革新によって、今ではマイクロソフトのクラウドと機械学習技術がお役に立てる時代になった、と締めくくりました。

無線航空機

次は、空、ドローンの話です。昨今、Windows 10 IoTで動くドローンが登場し始めたということ。実際会場では実物が披露されました。

このドローンを利用して実際に無人航行を行った際のフライト情報（バッテリー残量、電圧、高度等）をクラウドに蓄積し、PowerBIで可視化するというデモが紹介されました。

　人／人工知能

最後は、基調講演にも登場した人工知能「りんな」の話題です。会場では画像認識のデモが行われました。

この画面は西脇さんのiphone上でLINEをつかってりんなと会話をしているところです。文章の代わりに柴犬のイメージをアップロードしています。

西脇さんいわく、柴犬の画像を送って、「これは柴犬です」と返すのは、人工知能ではなくアシスタントであるということ。りんなは、人と楽しく会話をするにはどうすればいいかを考えて実践する事を目的とした人工知能なので、そうは返さないようです。上記例では、「超かわいい」と、それ以降話を繋げられるような返しができていることがわかると思います。

次に、りんなにテレビの音声を聴かせるというデモが行われました。左の写真のように、テレビの横で音声認識機能を利用して音声を取り込み送信してあげます。時間にして５秒程度。そうすると、写真右のようにどのテレビ局のどういう番組名なのか、その番組に出演しているタレントさんの名前や関連する話題を喋ってくれるんです。

このデモは、りんなとクラウド上の深層学習によるデモということです。マイクロソフトのデータセンタは地デジの映像をリアルタイムですべて蓄積しているそうです。今放送されている音声とアップロードした音声をクラウド上でリアルタイムにマッチングして、番組名を推測する。そこから、出演者の情報などを検索し、会話につなげていくということ。これはすごかった。

今日紹介した、りんなを使ったデモは皆さんも自分のスマホで試すことが出来るようなので、是非試してみてください！

技術革新に付いていこう

最後に昨今の技術革新について、こんな話がありました。

「技術革新が進むと今までの職業がなくなるのでは？」とよく言われます。最近では人工知能の話題が熱いですし、尚更。そこで登場したのがこの写真。

1905年のマンハッタンの写真と1925年のマンハッタンの写真。（写真は1925年の方） 両方の時代の写真を比較し、1905年は馬車が全盛。当然馬の世話をする職業があったはず。しかし、20年後の1925年の写真では馬車が姿を消し、すべて自動車に置き換わっています。では、1905年当時馬の世話をしていた人達は、1925年には職を失っているのでしょうか？

西脇さんはこう言いました。

「違うんです。1925年になったら、駐車場やガソリンスタンド、板金工場を運営してるんです。カーアクセサリを売ってるんです。技術革新についていった人は職業を変えるんです。技術革新についていった人は職業がなくなることはありません。プログラミングできる人は絶対に職業が無くなることはありません。」

マイクロソフトのテクノロジーとそれを支えるエンジニアの皆さんのおかげで、将来は大きく変わって魅力あふれる未来になる。そんな未来を一緒に作っていきましょう。

最後にそう締めくくり、西脇さんのセッションは終わりました。

Angular2の失敗しない始め方 / 稲富駿氏

株式会社トップゲートの稲富 駿氏によるセッションです。セッション資料や配信動画は記事末尾でご確認ください。このセッションでは、大きく3つの点について触れられました。それぞれのポイントを書き起こします。

1. Angular2に関するよくある質問や誤解について
2. Angular2を構成する基礎技術について
3. Angular2を学ぶために必要なこと

1. Angular2に関するよくある質問や誤解について

Angular2について正しい知識を知ってもらうために、よくある質問とその回答について幾つか取り上げる。

Q1. AngularJS2なのか？Angular2なのか？

Angular2が正しい名称。ここが大事。Angularはただ単にJSフレームワークライブラリではない。JSフレームワークであると同時に、 ElectronやNativeアプリで動くライブラリでもあり、Serverサイドで動くためのライブラリでもある。つまり、Angularはアプリケーション開発のためのプラットフォームと認識するのが正しい。

Q2. Angular2を学ぶためにTypeScriptを勉強する必要があるのか？

必ず必要というわけではないが、勉強すべきである。Angular2はコードベースがTypeScriptベースになっている。勉強すべき理由はそれだけではなく、TypeScriptを利用することで、次の大きく3つのメリットを享受でき、安全で開発自体の生産性向上を図ることが可能になる。特にTypeScriptを採用できない理由がない場合は、TypeScriptで書くべきである。

メリット１：静的型チェックが利用可能

TSの一番大きな特徴である静的型チェック。静的型付けされたコードは常に正しいAPIドキュメントだと言える。型が付いている限り、常に正しいコードが書けるし、コンパイラでエラーを事前にチェックできる等のメリットがある。また、型があることで、エディタやIDEで入力補完の恩恵をうけることができる。

メリット２：Decoratorsが利用可能

デコレーター（＠Decorators）は次世代のWeb標準（ESnext）として提案されている機能。TypeScriptでもオプションを付けることで利用可能。Angular2ではこれを推奨している。デコレーターを利用することで、コンポーネント作成にあたっての属性設定はデコレーターで、コンポーネントの実装はclassでというふうに分けて書くことができる。それによってコードの視認性も向上する。

@Component({
    selector: "app-profile",
    template: "<p>Name: {{ name }}</p>"
})
class ProfileComponent {
    name: string;
    constructor() {
        this.name = "laco";
    }
}

メリット３：Type-Base DIが利用可能

Type-Base DI（Type-Safe DI）を利用すると、DIを型ベースで行うことが可能。例えば、コンストラクタに渡す変数名が間違っていたとしても、型を指定するため、エラーを未然に防ぐことが可能。誤字（typo）に強いDIができる。DIについての詳しい説明は省略する。

import {Http} from "angular2/http";

@Injectable()
class MyService {
    constructor(private anyNameForHttp: Http) {
    }
}

Q3. Angular１系はサポート終了になるのか？

Angular1系は、1.4系と1.5系が今後もサポートされ続ける。これがステーブルとなり、基本的には破壊的変更は入らない。もし、破壊的変更が入る場合は、1.6、1.7とバージョンが上がっていく予定で、遅れてバックポートしたものが1.5にもマージされることになる。

Angular1.5ではComponent Helperが追加された。これは、Angular2への移行をサポートするためのもので、将来的に移行を検討している場合は、使っておくと良い。また、Angular2のRouterについては、Angular1用のライブラリが出ており、利用することでAngular2とほぼ同じAPI、書き方で実装することができる。

Q4. 双方向バインディングはなくなったのか？

存在する。しかし、Angular2は原則単方向バインディングを利用することになっている。双方向バインディングを実装したい場合は、二重カッコ[()]で記載する必要が出てくる。

<input [(ngModel)]="myName">

このように記載すると実行時に、以下のように単方向バインディング＋イベントハンドラが自動生成される。

<input [ngModel]="myName" (ngModelChange)="myNameChanged($event)">

Q5. Dirty checkはなくなったのか？

存在する。しかし、Angular1に比べて爆速で動作するようになった。理由は、Angular２は実行時に変更検知を行うためのコード生成を行う。具体的には、Angular2の各コンポーネントは、自分自身の変更検知のために、専用のChange Detectorという変更検知器を生成する。それぞれのコンポーネントに最適化された変更検知器のおかげで、Dirty checkのパフォーマンスが改善（10msで100000チェックが可能）された。watchの個数は基本的に気にしなくて良くなる。

Q6. サーバサイドレンダリングはできるようになるのか？

Angular Universalというnodejs上で実行されるAngular2が存在する。コアのコードはAngular2とまったく同じ。また、nodejsにかぎらず、今後は、Java/php/.net/python等の環境でも利用できるようになる予定。

Q7. WebComponentを利用しているのか？

利用していない。しかし、Angular2はWebComponentと併用可能である。例えば、ShadowDom。Angular２は独自の機能でShadowDomをエミュレート（CSSのスコーピング）を行うことが出来る。

@Component({
    selector: "my-component",
    encapsulation: ViewEncapsulation.Native
})
class MyComponent{}

ディフォルトはViewEncapsulation.Emulatedである。もしブラウザにShadowDomの機能がついていれば、 ViewEncapsulation.Nativeを指定することで利用可能。パフォーマンス面では、ブラウザのShardDomを使うほうが早い。現時点ではChromeでしか動作しないが、対応ブラウザがChromeの場合や、Electron上で動作させる場合は、こちらを活用してパフォーマンス向上を狙ってほしい。

2. Angular2を構成する基礎技術について

次に、Angular２を構成する基礎技術について解説する。Angular２は様々な技術を利用して作られているので、個別の技術について理解すると、より効果的にAngular2を習得することが出来る。

SystemJS

SystemJSは動的なモジュールローダー（NodeJSのrequireと同じような役割をもつ）である。SystemJSはES.nextのimport、exportに対応するのが特徴で、将来ブラウザに実装されるモジュールローダーのポリフィル的存在。これを活用すると、遅延ローディングが可能になる。必要なコンポーネントのみを都度読み込む事が可能になり、よりパフォーマンスが向上する。

しかし、利用は必須ではない。JavaScriptのライブラリを静的に読み込みたい場合（npmなどでダウンロードしてくる場合）は、今までどおりBrowserifyやWebpackなどが利用可能。動的ロードしたい場合のみ、SystemJSを使えば良い。

RxJS

Angular2を利用するにあたって必須の機能。Observableのポリフィルとして利用されている。Observableはリアクティブプログラミングに基づいた考え方であり、Promise同様に非同期処理を実現する。Angular1はPromiseで、Angular2はObservableで非同期処理がそれぞれ実装されている。両者には様々な違いがあるが、Webの非同期処理についてObservableの利点を幾つか挙げる。

onkeyup等のDOM Eventに関しては、連続して発生した場合に、Promiseではその発生順序を知るすべはないが、Observableではイベントの順序どおりに処理が可能になる。DOMのAnimationについては、Promiseでは一度始まるとそれが完了するまで値は取れないが、Observableでは途中で処理をキャンセルすることが可能。WebSocketの通信についても、ストリームとして順序どおりに扱うことが可能になり、Ajaxに関しては処理途中でキャンセルが可能になる。

このように、Webにおける非同期ではObservableの方が適しているシーンが多々ある。そのため、Angular2では非同期処理の根幹はObservableで実装されている。そのため、RxJSとObservableの修得は、Angular2を学ぶためには必須とい言える。

Zone.js

ZonesというES.nextに提案されている機能のポリフィル。これを利用すると、非同期処理のコンテキストを開発者が自由に設定可能になる。具体的には、setTimeout等あらゆる非同期処理の前後にフック可能なポイントを挟むことができる。

Webにおける非同期処理の後にはかなりの確率で何らかの変更が行われる可能性がある。例えば、Ajaxでレスポンスを受け取った後はそれを受けてModelが変更されるなど。そのため、Angular２では、Zone.jsを利用し、全ての非同期処理の後に変更検知処理を行っている。処理速度も早い。

reflect-metadata

リフレクションのためのAPIを追加するためのポリフィル。reflect-metadataの機能もES.nextに提案されている。Angular2は内部的にTypeScriptのコンパイルに利用している。インストールは必要だが、開発者は覚えなくても問題はない。

3. Angular2を学ぶうえで必要なもの

次に、Angular2を学ぶ上で理解しておくことを幾つか取り上げる。

Angular2はAngular１よりシンプルになった

Angular1はAPIが多すぎたため、Angular２ではかなりシンプルになった。データバインディングと双方向バインディングの設定方法、イベントハンドラの設定方法はかなりシンプルになった。また、APIについても基本的には’@Component’を覚えれば良い。

Angular2はパフォーマンスが改善されている

Angular1はdirty-checking、two-way bindings、$digest loopが遅いと言われてきたが、Angular2でChange Detection（変更検知）が革命的に変わり、パフォーマンスが改善された。

Change Detection

Change Detectionは、例えば、Modelのここが変更になったらViewに描画するなどの処理を行う際に必要になる。重要なのは、どこでどんな変更が起きたかを素早く検知して、それを反映すること。Angular2の変更検知メカニズムはよく考えられている。全てのコンポーネントには個別のChange Detecter（変更検知メカニズム）が存在する。そして、Angular2の全てのコンポーネントはツリー構造になっており、変更検知が必ず一方向（親から子へ）に行われるようになっている。そして、各コンポーネントでは変更検知を行うかどうかを個別に設定可能になっており、親のレベルで変更検知を停止したり、子のレベルで変更検知を停止したり、非常に柔軟で戦略的な変更検知の設定が可能になっている。

Angular2では静的解析ツールが利用可能

Angular1では静的解析ツールが利用できなかった。例えば、バインディングの記述に[]を利用するようになったため、機械的にバインディングかどうかのチェックが可能になっている。

まとめ

Angular2を学ぶためには、ES.next、Decorators、Observables、Zones等、最新のWeb標準技術について学ぶことが大前提である。Angular1の登場（2009年）から、Angular2の登場までの間に、Web標準の世界は大きく変わった。最新のAngular2がAngular1とまったく異なっているのは必然であり、この世界で生きていくには、勉強し続ける必要がある。枯れた技術にしがみついてはダメ。何もかも最新のものを使う必要はないが、最新の技術に常に目を向けて置く必要はある。

最後に、Angular2を使うのは素晴らしいことだが、まだベータ版であることを忘れてはならない。今後BREAKING CHANGES（破壊的変更）が発生する可能性が十分にある。そのために、チェンジログは必ず読むようにする。どうにもならなければコミットログも読む。そして、それ以上深く関わりたければ、issueを出したりPullRequestを送りましょう。それがハードルが高いと考える方は、カンファレンスに参加したり記事を書いたりしよう。開発者にTwitterで質問するのも効果的。

セッションをもっと詳しく知りたい方は？

以上で、セッションの書き起こしは終了です。
稲富駿氏のセッション資料はこちらで公開されています。

Angular2の失敗しない始め方

セッション動画もYoutubeで公開されているので、ぜひご覧ください！

Angular2実践入門 / 白石俊平氏

当メディアの編集長であり、TechFeedの開発者でもある白石俊平氏によるセッション。スライド40枚以上の大作でライブコーディングもあります。

ライブコーディングで学ぶAngular2

今日のライブコーディングを追体験できるスターターキットを作った。是非活用してほしい。 https://github.com/shumpei/angular2-webpack-starter-minimum
– Angular2をwebpackを利用してミニマムスタートできるプロジェクト
– 教育用途、もしくは開発環境を自作したい人向け

Angular2の特徴（かなり主観）

特徴その１：TypeScriptを推奨

TypeScriptを一言で言えば、ES.next全部＋型である。また、実験的なサポート扱いである「デコレーター」は、Angular2を使う上では必須となる。

特徴その２：コンポーネント指向

実際のコードは以下のとおり。JavaScriptとは大分変わった見た目になるのが第一印象。

import {Component} from 'angular2/core';

@Component({
  selector: 'my-app',
  templateUrl: '/src/components/app.component.html'
})
export class AppComponent {
}

importはモジュールをインポートする仕組み。@Componentはデコレーターであり、これを取り付けたクラスがUIコンポーネントとなる。上記サンプルはAngular2における、UIコンポーネントの例である。UIコンポーネントは簡単にいえば、自作のタグだ。上記サンプルだと、<my-app>タグをHTMLに埋め込めるようになる。また、templateUrlは実際に出力するテンプレートを指定する。

次に、my-alert-buttonコンポーネントをライブコーディングする。

import {Component} from 'angular2/core';

@Component({
  selector: 'my-alert-button',
  templateUrl: '/src/components/alert-button.component.html',
})
export class AlertButtonComponent {
}

<button>Click me!</button>

作成したコンポーネントdirectivesに指定し、実際に利用する。

import {Component} from 'angular2/core';
import {AlertButtonComponent} from './alert-button.component';

@Component({
  selector: 'my-app',
  templateUrl: '/src/components/app.component.html',
  directives: [AlertButtonComponent],
})
export class AppComponent {
}

<h1>My first Angular2 app!</h1>
<my-alert-button></my-alert-button>

これは、ボタンを押すとアラートを発生させる処理をコンポーネントとして実装した例である。

特徴その３：ちょっとキモい

テンプレートのシンタックスがキモい。例えば、クリックイベントを補足する処理は、以下のように、(click)="onClick()"と記載し、対応するイベントハンドラはonClick()としてコンポーネント内に記述する。

<button (click)="onClick()">Click me!</button>

import {Component} from 'angular2/core';

@Component({
  selector: 'my-alert-button',
  templateUrl: '/src/components/alert-button.component.html'
})
export class AlertButtonComponent {
  onClick(): void {
    window.alert('Hello!');
  }
}

特徴その４：Angularっぽさ

Angular2とAngular1はかなり違うが、似通っているところもある。例えば、サービス/DI/ディレクティブなど用語や概念を引き継いでいる。例として、loadData()というstring型の配列を返すサービスを作る。

import {Injectable} from 'angular2/core';

@Injectable()
export class MyService {
  loadData(): string[] {
    return ['a', 'b', 'c'];
  }
}

サービスをDIする場合は、事前準備としてprovidersでサービスを指定する。実際にDIするためには、AppComponentクラスのコンストラクタに指定する必要がある。

import {Component} from 'angular2/core';
import {AlertButtonComponent} from './alert-button.component';
import {MyService} from '../services/my.service';

@Component({
  selector: 'my-app',
  templateUrl: '/src/components/app.component.html',
  directives: [AlertButtonComponent],
  providers: [MyService]
})
export class AppComponent {
  private data: string[];

  constructor(private myService: MyService) {
    this.data = myService.loadData();
  }
}

特徴その５：やっぱりキモい

テンプレートでは、以下の様な記法を要素内に記述していく。

(),[],[()],#,*

全力を出すとこんな感じだ。だいぶキモい。

<input *ngif="alive" [(ngMode)]="name" #name>

例として、テンプレート内でループ処理を実装してみる。

<h1>My first Angular2 app!</h1>
<my-alert-button></my-alert-button>

<ul>
  <li *ngFor="#item of data">{{item}}</li>
</ul>

テンプレートは外部ファイル指定するのではなく、バッククォートで囲み、Component定義内に直接HTMLやCSSを記載することも可能。また、コンポーネントはCSSをカプセル化（そのコンポーネント内に閉じる）するので、コンポーネントのスタイルは外部に影響を与えない。

Angular2を始めたらあなたが出会うであろう１１のこと

TechFeedのモバイルアプリ版を現在開発していて、その開発でAngular2を使っている。その開発経験を基に感じたことを時系列で取り上げる。

TechFeed -テクノロジー情報に特化した情報キュレーションサービス-

その1:ハードル高くない？

使うにあたっての前提技術が多い（TypeScriptやモジュールバンドラー、RxJS）ので、当初ハードルが高そうだと感じた。前提技術が多すぎるように感じるからだ。

• TypeScript
• モジュールバンドラー
• RxJS
• もちろんAngular2

でも、意外とそうでもなかった。なぜか？

• Angular1の文脈を引き継いでいる（1系やったことがある人は学習コスト低め）
• TypeScriptはJavaっぽい（もともとJava屋の人は親しみやすい）
• RxJSは最初から詳しく知っている必要なし
• Webpackの調整が一番時間がかかった（でも、だれか一人がやればいいのであまり気にしない）

その2:言語はどれを選ぶ？

個人的には、TypeScript一択ではないかと考える。ドキュメントが完備されていて、型があり、デコレーターが使えるのが嬉しい。JavaScriptやBabelも止めはしないが、きっとTypeScriptで書くほうが楽だ。

その3:モジュールバンドラーは何にする？

TypeScriptを選ぶとモジュールバンドラーが必須。TechFeedでは、実績豊富等の理由からWebpackを選択した。Angular2の公式ではSystem.jsというものが使われているが、後発であり情報が少なめだったため、採用しなかった。

その4:エディタは何にする？

TypeScript対応のエディタやIDEは、AtomやSublime、WebStormなどいくつかある。白石は今のところAtomを使っている。

その5:テンプレートをどこに書く？

@Componentに直接埋め込む方法、URLで外部ファイルにする方法のほか、Webpackを使えばrequireでHTMLファイルを埋めこむこともできる。３つの方法を比較するとWebpack利用が一番柔軟性があるが、個人的には、コンポーネントとテンプレートファイルがひとまとまりになるので、埋め込み方式もわかりやすいと思う。

その6:テンプレートがキモい

これは慣れるしかない。ただ、慣れるには順序がある。以下のように、Angular2が指定する新しいメンタルモデルを理解すれば、少しは楽になる。

• こいつはHTMLじゃない。HTML Plusだ
• タグの属性とプロパティはそもそも似て非なるもの
• []は属性ではなくプロパティを指している
• 属性ってやつは、プロパティの初期化にすぎない

その7:Sassを使いたい

モジュールバンドラーの機能を駆使すれば、Sass/Less等もコンポーネントで利用することができる。Webpack側でSassのコンパイル設定を行っておけば、scssファイルをコンポーネントでrequireするだけで利用可能。

その8:RxJSとのつきあい方

RxJSはリアクティブプログラミング用ライブラリである。Angular2はHTTPやEventEmitterなどの頻出APIがRxJS前提（Observable利用前提）である。ObservableはES7にも提案されているため、この機会に勉強するのは良いかもしれない。なお、Angular2はRxJS５（beta）を利用している。

その9:ページネーションしたい

よくあるユースケースだが世界中が現在実装方法を模索中。TechFeedでは、Observableの簡単なラッパーを作った。もう少し使い勝手を良くしてOSSで公開したいと考えている。

その10:UIフレームワークを使いたい

TechFeedでは、Ionic2を採用した。Ionic2はAngular2で完全にリライトされているので、Angular2開発の参考にもなる。その他にも、Angular2対応のUIフレームワークとして、Onsen UI2.0や、angular-material2、ng2-bootstrap等がある。

その11:コンポーネント設計

コンポーネントの粒度や振る舞い、状態をどこに配置するかは、現在熱い話題。Presentational and Container Componentという議論の土台があるが、これがあるからといって全て解決するわけではないので、やはり悩ましい。（全て外部に移譲するのか？面倒くさくない？…等） 個人的に唯一の正解は、「必要になるまで分割するな」だと考えている。

セッションをもっと詳しく知りたい方は？

以上で、セッションの書き起こしは終了です。
白石俊平氏のセッション資料はこちらで公開されています。

セッション動画もYoutubeで公開されているので、ぜひご覧ください！

※白石俊平氏の講演開始時間から再生されます

今年最後の記事は、記事公開後１週間の閲覧数（PV）をもとに、2015年の年間読まれた記事ランキングTOP20！をお届けします。

年間読まれた記事ランキングTOP20！

＜1位＞
【及川卓也・清水亮・羽田野太巳・藤村厚夫】すごい人達呼んで「Webは死ぬか？」をマジメに語り合ってもらった（前編）
── 白石 俊平

＜2位＞
今話題のReact.jsはどのようなWebアプリケーションに適しているか？ Introduction To React─ Frontrend Conference
── 外村 和仁

＜3位＞
【及川卓也・清水亮・羽田野太巳・藤村厚夫】すごい人達呼んで「Webは死ぬか？」をマジメに語り合ってもらった（後編）
── 白石 俊平

＜4位＞
理解しておきたい、CSSによるインラインレイアウトの仕組み（inline-block編）Inline Layout─Frontrend Conference
── 高津戸壮

＜5位＞
昨今のCSS設計事情からみるCSS設計のあり方とは
── 谷拓樹

＜6位＞
Microsoftの本気をみた！新しいWebブラウザ「Microsoft Edge」にかける思いとは？
── 仲 裕介

＜7位＞
【速攻レビュー】よりモバイルフレンドリーになった「Twitter Bootstrap v4」
── 佐川 夫美雄

＜8位＞
フレームワーク対決！Angular VS React仮想パネルディスカッション
── 吉川 徹

＜9位＞
「StyleStats」を活用してCSSを評価する、Evaluating CSS─Frontrend Conference
── 石本 光司

＜10位＞
スクエニのデモすごかった！HoroLensも、Edgeも！見どころ多すぎで長文失礼！- Microsoft de:code基調講演後半レポート
── 白石 俊平

＜11位＞
【UIデザイナー不要説は本当か】現役クリエイターが「UI Crunch」で語った本音とは？
── 馬場 美由紀

＜12位＞
HTML5 Experts.jpはなぜこんなにパフォーマンスが悪いのか…全てお見せします！ーWebパフォーマンス改善企画（解析編）
── 仲 裕介

＜13位＞
JavaScriptにもクラスがやってきた！JavaScriptの新しいclass構文をマスターしよう
── 高津戸壮

＜14位＞
Webエンジニアが、量産品のハードウェアを作るようになるまで─Cerevoの中の人に聞いてみた！
── 白石 俊平

＜15位＞
乗るしかない！Reactのビッグウェーブに！─isomorphic tokyo meetupに参加してきた
── 白石 俊平

＜16位＞
PolymerでMaterial Designなチャットアプリを作ろう
── Tomomi ❤ Imura

＜17位＞
『現実世界をWeb化する』「Physical Web」そして「Eddystone」について詳しく聞いてきた！
── 白石 俊平

＜18位＞
【Webデザイナー必読】IoT時代のデザイン思考を探る─久下玄×秋葉秀樹 デザイナー対談
── 白石 俊平

＜19位＞
ユーザーの期待に応えるクックパッドのUI/UXーWDF Vol.17 with HTML5 Experts.jp「アクセシビリティとUX」
── 仲 裕介

＜20位＞
トヨタCIOが来たりて熱く語る！Microsoft de:code基調講演前半レポート
── 白石 俊平

※集計対象期間：2015/1/1 – 2015/12/28
※集計方法：集計対象期間中に公開された全ての記事の公開後1週間のPVをカウントしランキング付け

【番外編】HX今年の顔

HTML5 Experts.jpには、エキスパート・コントリビューターの方々紹介ページがあります。筆者の思いつきですが、紹介ページの中で今年もっともアクセスされたエキスパート・コントリビュータートップ３を集計してみました。

題して、HX今年の顔! 結果は以下のとおりです。 編集長である白石を筆頭に、よく記事を書いてくださる人気ライターである、佐川さん、泉水さんが続きます。

＜1位＞
白石 俊平 編集長

＜2位＞
エキスパート 佐川 夫美雄 さん

＜3位＞
エキスパート 泉水 翔吾 さん

来年もよろしくお願いします！

HTML5 Experts.jpは2015年も多くの方々にご愛読いただきまして、執筆陣・編集部共々感謝しています。ありがとうございました。来年も引き続き宜しくお願いいたします。

TPACはWebの標準化団体であるW3Cが年一回開催する全体会合です。今年はその会合がなんと、札幌で開催されます。最先端のWeb標準に関する様々な議論が日本で交わされること記念して、TPACの魅力を伝えるとともに、Web標準の今をわかりやすく紹介するイベント「Leading the way to W3C TPAC 2015」が、8月終わりに開催されました。テーマは「Webの未来の肌触りを感じよう」。

来週TPACに参加される方もそうでない方も、全ての方に改めてWeb標準に興味関心を持っていただきたいと考え、そのイベントの模様をレポートします！

はじめに

イベントはW3C Keioサイトマネージャーの中村修氏の挨拶から始まりました。

W3CとIETFの関わり

今年は、Web標準を作るW3CのTPACと、インターネットプロトコルの標準を作るIETFが、それぞれ10月と11月に日本で開催される。この2つの会議が同じ時期に同じ国で行われることは歴史的にみても初めての試みだ。例えば、Webブラウザ上でP2Pによる通信を実現するWebRTCを例にとると、関連するプロトコルの議論はIETF、APIやアーキテクチャの議論はW3Cで議論が進められており、今や両者は密接に関わっている。そのため、今回のような取り組みは非常に重要な意味を持つ。また、IETFとW3Cが作る標準は「オープン標準」であることが最も重要なこと。みんなが自由にソフトウェアを書いて、その上で同じく自由に新しいサービスを作っていけるように、そのための基盤作っていく作業をIETFとW3Cは日々やっている。そこを理解してほしい。

TPAC2015の歩き方

最初のセッションはHTML5 Experts.jpのエキスパートでもある矢倉眞隆氏による「W3Cの歩き方」です。矢倉氏は以前、W3Cメンバーであるミツエーリンクスに所属しており、そこで標準活動を積極的に行っていた経歴を持ち、2007年からほぼ毎年TPACに参加しているそうです。

W3Cの情報ってどうやって収集するの

W3Cの標準化に関する活動の様子を知る手段としては、「メーリングリスト」、「GitHub」、「F2Fミーティング」の3種類がある。中でも今はGitHubでの議論が活発。Issuesを活用し様々なトピックについて議論がなされているため、議論に加わりたい方にはオススメ。気軽にコメントやPRができる。F2Fミーティングは、各ワーキング・グループ毎にTPAC以外で、年2回以上は開催されており（グループごとに差がある）、コミュニケーションが密に取れるという意味では大変重要な役割を担っている。例えば、CSSのワーキング・グループでは、図形に関する議論が多いため、F2Fでプロジェクターを見ながら議論することで、より捗る傾向にある。

TPAC2015ではどのようなことが行われるのか

TPACはW3Cの全体会合（TECHNICAL PLENARY）、運営会議（ACミーティング）、F2Fミーティング（グループミーティング）で構成されており、年に1回実開催される。スケジュールやどのようなグループが議論を行うかは、公式サイトに掲載されている。

中でも注目は、水曜日に開催される「TECHNICAL PLENARY DAY」だ。これは、アンカンファレンス形式で進められる。TPACの参加者自身が喋りたい内容をその日の朝に出し合い、早い者勝ちで予め用意されているミニセッション枠を確保する。他の参加者たちは好きなセッションに参加可能である。これは、各グループの垣根を超えたコミュニケーションを促進することで、イノベーションを促進する狙いがある。

なぜTPACに参加するのか

標準化に関する内容は、Webで簡単に手に入る時代になった。この時代に、あえてTPACに行く理由はなにか？開発者目線のTPACは、ブラウザベンダにこのようなAPIを実装してほしい、ここの部分が使いにくいので変えてほしい等、開発者の声を積極にアピールする場になっている。また、直接あって話がしたい、発表したい、他の開発者と差を付けたいなど、野心的な想いを持った開発者も多い。

これからの標準化と開発者の関わり方

最近では、ブラウザベンダも標準をかなり意識し始めている。標準じゃないと実装しないという風潮になりつつある。そして、標準化の現場も変わりつつある。これまで標準化の場で作り出されるAPIは、開発者からの要望に基づいたハイレベル（高機能）なものが多かった。そのため、新しく出てくる様々なユースケースに対応できなかった。（対応に時間がかかっていた）今後は、様々なユースケースに短期間で対応できるように、ブラウザで扱える範囲にはなるが、比較的ローレベル（低機能）なAPIの標準化が主流になる。それを組み合わせることで、開発者は様々なユースケースに迅速に対応できる。（いわゆるExtensible Webの流れ）また、JQueryのように、ローレベルなAPIを開発者自らがラッパーしてわかりやすいAPIを定義するということが、増えてくるだろうと期待もされている。

Developer Meetup in Sapporoが開催されます！

次のセッションは、TPAC2015の開催に合わせて札幌で開催される「Developer Meetup in Sapporo」の紹介です。登壇は、このイベントをホストするNTTコミュニケーションズの本間咲来（さっくる）氏。

TPAC2015は参加条件があるため、一般の開発者が参加するにはちょっとハードルが高いイベント。そこで、TPAC2015の為に来日する海外のエキスパートと日本のエンジニアの交流の場として、TPAC2015初日（10/26）に「Developer Meetup in Sapporo」が開催されます。会場はW3Cと同じ会場。展示やトークセッション、懇親会が企画されていて通訳も用意されるそうです。まだ参加登録を受け付けているようなので、興味がある方は是非参加してみては？（参加は無料です）

また、イベント開催に合わせて、クリプトン・フューチャー・メディア株式会社主催の北海道オープンデータハッカソンが10/17に開催されました。ハッカソンの優秀者の作品はDevelopers Meetupで展示されるそうです。

※写真はイベント開催時（8月末）のものです

Eddystoneで始まるPhysical Webの世界

ここからは、ゲストスピーカーによる最新のWeb技術に関する、テクニカルセッションが続きます。

最初のセッションはリクルートテクノロジーズの加藤亮氏。加藤氏は以前当メディアで取材したPhysical Webのエキスパートです。このセッションでは、Physical Webをテーマに、Googleが7月に発表したばかりの標準規格である、Eddystoneについて解説していただきました。

Eddystoneとはなにか？

EddystoneはGoogleが7月に発表したBeacon Platformを構成するもので、ビーコンの規格。ビーコンは、フレームと呼ばれるデータを定期的にブロードキャストするもので、この規格では、ビーコンデバイスの振る舞いや、発信するパケットのフォーマットを規定している。Googleはオープン・スタンダードを提唱している。

Eddystoneには3つのフレーム（Eddystone-TLM、Eddystone-UID、Eddystone-URL）がある。Eddystone-TLMは、ビーコンの管理情報を送信するもので、バッテリ電圧や温度、起動後の経過時間、パケット送信料などを送る。重要なのは、Eddystone-UIDとEddystone-URLの方。

Eddystone-UID

Eddystone-UIDは、NamespaceとInstanceIDと呼ばれる固有IDを送信します。ビーコン受信側では、Namespaceを見て自分のサービスのビーコンかどうかを判断し、InstanceIDを利用して複数のビーコンをまたがった移動などを検知することができる。iBeacon的な用途をカバーするする、洗練されたオープン・スタンダードな仕様だといえる。

Eddystone-URL

Eddystone-URLは、Physical WebのおけるURIBeaconのことであり、NamespaceとInstanceIDの代わりにURLを送信する。小さいパケットの中にURLを載せるための工夫がなされているほか、長いURLは短縮URLを使うといった配慮が必要。これは、いわゆるPhysical Webの世界を現実のモノにするためのモノで、実験フェーズから実践フェーズへの移行を象徴付ける存在である。

Eddystone-URLはビーコンの新たなエコシステムを作る

一番の醍醐味は近接通信をサービスに活用できること。Eddystone-URLを使えば、ビーコンからBluetooth Low Energy（以下、BLE）でURLをブロードキャストできる。近くにいるスマホは、複数のビーコンから受信したURLを元にOGPなどを収集、リスト表示してユーザに提示することができる。

URLが必ずしも必要かといえばそうではなく、UIDとURLの変換テーブルをもったスマホアプリを独自に作れば同じようなことができる。これは今までのBeacon（iBeaconやEddystone-UID）のエコシステムで、独自に設置したビーコンとそれ専用のスマホアプリを配布し使ってもらうというもので、開発費もかかり、ユーザにビーコン毎に別のスマホアプリを導入してもらう必要があり、ハードルが高かった。

Eddystone-URLを利用すれば、URLという共通のフォーマットでデータのやり取りができるため、スマホには標準準拠アプリ（例えばWebブラウザ）を1つ入れておけばよく、コンテンツ提供側はビーコンとWebコンテンツを用意すればよい。これは、標準規格の上で様々なコンテンツが充実したWebのエコシステムによく似ており、ビーコンにおける新たなエコシステムと言ってもいい。今後周辺ビジネス含めて新たな競争が生まれる可能性を秘めている。つまり、Eddystone-URLはただの機能的なイノベーションの話ではなく、プラットフォームとしての意味合いが強いと言える。

すぐに使えるのか

もともとPhysical Webと言われていたこの技術であるが、7月にGoogleがBeacon Platformを正式発表したことで、実験フェーズから実践フェーズに移行したといってもいい。Eddystone-URL対応ビーコンデバイスも出始めており、既存のiBeaconでもファームウェアのアップデートで対応できるものもある。（例：Estimote）

また、Beacon Platform発表のすぐ後にChrome（最新iOS）がPhysical Webに対応した。Physical Webの機能をONにすれば受信したURLをウィジェットにリストアップすることが可能で、もちろんEddystone-URLからの情報を受けることもできる。まだ実験的な対応であることは否めないが、普及に向けた第一歩であることは間違いない。尚、本命はGoogle Nowで活用したいのではないかと考える。キラーアプリの登場が普及の鍵を握っている。

Web開発者が考えなければならないこと

サービス提供側としては、ビーコンを活用する関係でリアル・ワールドを考慮したサービス設計（UI/UXデザイン）が必要になる。例えば、スマホは基本的にはインポケットデバイスである。ビーコンの情報を受信してもユーザがスマホを見てくれなければ意味がない。ユーザが自然にスマホを見るような環境に上手くビーコンを配置したり（バス停やレストラン等）、サイネージなどと組み合わせて、歩いているユーザを立ち止まらせるような仕掛けを合わせて考えなければならない。

今後の展望

近接通信を活用したPhysical Webの普及で、WebブラウザからIoTデバイスへのダイレクトアクセスという需要が出てくる可能性がある。今でもWebBluetoothやWebNFCの議論があるが、FirefoxOSなどのWebOSで使えるようにすることが主目的となっている。今後、近接通信を前提とするWebサービスを作りたいという要望が出てくれば、純粋なWebブラウザ上のWebアプリケーションからもこれらの機能が必要となってくる。そして、これらの機能が整備されると、ビーコンにかぎらず、他の様々なIoTデバイスや近接通信機器とのIFとなり得るため、デバイスが普及した暁には、Webの大きなアドバンテージになっているはずである。

発表資料

加藤氏の発表資料はこちらで公開されているので、ぜひご覧ください。

終わりに＆次回予告

次回は加藤氏に続く3人のゲストスピーカーによるセッションの模様をお伝えします。そして、来週からはじまるTPACでの熱い議論、参加される方は現地で、参加されない方もインターネット等を通して、ぜひウォッチしてみてください！新しい発見があるかもしれません。

連載4回目の今回は、7月28日にリリースされた、SkyWay ScreenShareのチュートリアルをお届けします。

SkyWay ScreenShareは、WebRTCのWebアプリケーションで画面共有を簡単に実装できるライブラリ、画面共有に必要なChrome・Firefox向けのExtensionが簡単に実装できるソースコードが含まれています。

画面共有機能の概要

WebRTCの画面共有機能は、ブラウザ画面やPCのデスクトップ画面をリアルタイムで相手に配信できる機能です。

Chromeでの画面共有の様子

WebRTCの画面共有機能はChrome 34以上または、Firefox 33以上で利用可能です。

Chromeでの実装

画面共有機能は、Chrome 26で初めてブラウザに実装されました。当初は、Chromeのchrome://flagsからEnable screen capture support in getUserMedia()というフラグをONにし、getUserMedia()のオプションを指定することで、実現できていました。しかし、セキュリティ上の問題からChrome 34でそのフラグが削除され、代わりにChrome Extensionをインストールするか、Chrome Appsからしか利用できなくなりました。

Firefoxでの実装

Firefoxについては、Firefox 33から画面共有機能が実装されています。Firefoxの場合は、Chromeとは方式が異なり、about:configのmedia.getusermedia.screensharing.enabledという設定をtrueに設定し、media.getusermedia.screensharing.allowed_domainsという設定項目に、画面共有機能を許可するWebサイトのドメインを追加することで利用できるようになります。また、media.getusermedia.screensharing.allowed_domainsには、Mozillaが許可したサービスのドメインが予め設定されています。こちらにドメインを追加してもらいたい場合は、このサイトの下部に掲載されているフォームから申請が可能です。（筆者は申請したことはありませんが、恐らく審査があると思われます）

標準化の状況

WebRTCのJavaScriptAPIの標準化はW3Cで行われています。この画面共有機能についても、今年の２月に仕様書が作られて標準化が進められています。仕様書は「Screen Capture」です。仕様書についての詳細な解説は割愛しますが、現在、ChromeとFirefoxで実装されている画面共有機能はブラウザベンダごとの独自実装であり、今後実装が変更になる可能性は高いと考えられます。

SkyWay ScreenShareの使い方〜ビルド編〜

ここからSkyWay ScreenShareの使い方を説明します。はじめに、github.com/nttcom/SkyWay-ScreenShareからファイル一式をローカル環境にcloneして下さい。また、ここに書いている内容の詳細はREADMEにも掲載していますので、合わせてご覧ください。

Chrome Extensionの作成

まずはマニフェストファイルを修正します。JSONファイルのひな形にそって必要な項目を入力して下さい。アイコンファイルも必要です。

{
  "name": "Your extension name here",
  "short_name": "Your extension short_name here",
  "version": "Your extension version number here",
  "manifest_version": 2,
  "description": "Your extension description here",
  "icons": {
    "16": "icon16.png",
    "48": "icon48.png",
    "128": "icon128.png"
  },
  "permissions": [
    "desktopCapture",
    "tabs"
  ],
  "background": {
    "scripts": ["background.js"],
    "persistent": false
  },
  "content_scripts": [{
    "matches": [""],
    "js": ["content.js"],
    "all_frames": true,
    "run_at": "document_end"
  }]
}

尚、ここで重要なのは matchesです。ここには、このExtensionのりようを許可するWebサイトのURLを記載します。必ずご自身のWebサイトのURLを指定して下さい。ワイルドカードを利用して複数のURLにマッチさせることも可能ですが、その場合は、あなたのExntensionを他のWebサイトで利用される可能性があります。セキュリティ上もよろしくありません。

例："matches": ["https://*.skyway.io/*"]

次にビルドしましょう。SkyWay-ScreenShareではビルド用のgulpタスクとnpm-scriptでエイリアスコマンドを用意しています。SkyWay-ScreenShareディレクトリの直下で、次の２行のコマンドを実行します。npmコマンドは事前に使えるようにしておいて下さい。

npm install
npm run build-chrome

ビルドが完了したら、出来上がったファイルをChromeに読み込ませましょう。chrome://extensions/ にアクセスし、デベロッパーモードを有効にします。そして、パッケージ化されていない拡張機能を読み込むをクリックし、以下のディレクトリを指定します。

SkyWay-ScreenShare/chrome-extension/screenshare_chrome_extension/

読み込むと以下のようになります。（この画像はChromeウェブストアからダウンロードしたものが写っています）

Chrome Extensionを読み込みます

また、ディレクトリと同一フォルダにあるscreenshare_chrome_extension.zipは、Chromeウェブストアにアップロードする際に利用できます。

これでChrome Extensionの作成は完了です。

Firefox Extensionの作成

（注意）SkyWay-ScreenShareのリポジトリには、「Firefox Add-On」という表記で記載しておりますが、画面共有機能を利用するために作成するモノは、Firefox Extension（拡張機能）となります。Add-OnはFirefoxの拡張機能やテーマ等全ての総称となるため、リポジトリの表記とは異なりますが、本記事中では、Firefox Extensionと表記を統一させて頂きます。

Firefox Extensionでは、メインプログラムとパッケージファイルの二つを修正します。まずは、メインプログラムです。

var pageMod = require('sdk/page-mod');
var self = require('sdk/self');
var __temp = require('chrome');
var Cc = __temp.Cc;
var Ci = __temp.Ci;

var domains_to_add = [''];
var addon_domains = [];
var allowed_domains_pref = 'media.getusermedia.screensharing.allowed_domains';
var enable_screensharing_pref = 'media.getusermedia.screensharing.enabled';

 ~~ 省略 ~~

ここではdomains_to_add = [''];に、画面共有機能を有効にするWebサイトのドメインを指定して下さい。指定方法は以下のようになります。

例：domains_to_add = ['*.skyway.io']

次にパッケージファイルを修正します。ここではExtensionの基本情報を入力していきます。ひな形にそって必要な情報を入力して下さい。アイコンファイルも必要です。

{
    "name": "your_add-on_name_here",
    "title": "Your add-on title here",
    "description": "Your add-on description here",
    "author": "Your add-on author here",
    "version": "Your add-on version number here",
    "license": "Your add-on license here",
    "homepage": "Your add-on homepage url here",
    "icon64": "icon64.png",
    "icon": "icon48.png"
}

次にFirefox Extensionのビルドに必要なツール「cfx」をインストールします。インストール方法はこのサイトを参考にして下さい。

ツールのインストールが完了したら、まずはプレビルド（pre build）を行います。ExtensionをビルドするためにはランダムなIDを予めパッケージファイルに記載しておく必要があるため、初回のプレビルドで、パッケージファイルにIDを挿入しています。

npm install
npm run pre-build-firefox

初回のプレビルドでIDが挿入された場合、以下の様なエラーが発生します。これは問題ありません。

No 'id' in package.json: creating a new ID for you.
package.json modified: please re-run 'cfx xpi'

再度以下の通り、ビルドを行って下さい。

npm run build-firefox

ビルドが完了したら、Firefoxに読み込ませて動作確認を行いましょう。about://addonsにアクセスし、作成したExtension本体である、SkyWay-ScreenShare/firefox-addon/screenshare_firefox_addon.xpiをドラッグ・アンド・ドロップさせます。

Firefox Extensionを読み込みます

Firefox Extensionの配布は、通常のWebサーバ上に上記xpiファイルを設置し行って下さい。

これでFirefox Extensionの作成は完了です。

JavaScriptライブラリの作成

SkyWay-ScreenShareには今まで作成したExtensionを利用するためのJavaScriptライブラリ「screenshare.js」が同梱されています。自分でビルドする場合は、以下のように行って下さい。

npm install
npm run build-library

ビルドに成功すると、以下の通りライブラリが生成されます。

SkyWay-ScreenShare/dist/screenshare.js
SkyWay-ScreenShare/dist/screenshare.min.js

また、ライブラリはCDNでも提供しています。

<script src="https://skyway.io/dist/screenshare.js"></script>
<script src="https://skyway.io/dist/screenshare.min.js"></script>

最後に、ライブラリの修正や機能追加などは大歓迎です。TypeScriptのソースファイルを同梱していますので、その際はご利用下さい。Pull Reqestもお待ちしています！

SkyWay ScreenShareの使い方〜アプリ開発編〜

ExtensionとJavaScriptライブラリの準備ができたところで、同梱しているサンプルアプリケーションを例に、画面共有機能を使ったアプリの開発方法をご紹介します。

まず、newでオブジェクトを作成します。debugオプションを指定するとコンソールログにデバッグログが出力されます。

// スクリーンキャプチャの準備
var screen = new SkyWay.ScreenShare({debug: true});

次に、startScreenShare()メソッドを利用して、画面共有機能を開始するためのコードを実装していきます。このメソッドの第一引数には、取得する映像の縦横サイズとフレームレートを指定します。第二引数のコールバック関数は、正しく取得できた場合に呼ばれ引数としてStream Objectが返ってきます。これをVideo要素に入れてあげれば画面が表示されます。

また、第四引数についてはChromeのみ利用できるオプショナルなコールバック関数で、画面共有が何らかの方法で終了した場合に呼ばれます。Firefoxでは現状終了検知が出来ないため、Chrome限定です。

screen.isEnabledExtension() はExtensionが利用しているブラウザで有効かどうか（インストール済みかどうかも含めて）を判定します。

// スクリーンシェアを開始
$('#start-screen').click(function () {
	if(screen.isEnabledExtension()){
			screen.startScreenShare({
					Width: $('#Width').val(),
					Height: $('#Height').val(),
					FrameRate: $('#FrameRate').val()
			},function (stream){
					$('#my-video').prop('src', URL.createObjectURL(stream));
					if(existingCall != null){
							var _peerid = existingCall.peer;
							existingCall.close();
							var call = peer.call(_peerid, stream);
							step3(call);
					}
					localStream = stream;

			},function(error){
					console.log(error);
			},function(){
					alert('ScreenShareを終了しました');
			});
	}else{
			alert('ExtensionまたはAddonをインストールして下さい');
	}

});

次に、画面共有をプログラム側で終了させる場合のコードを実装していきます。現在は終了のための専用メソッドは用意していません。先ほど取得したStream Objectを保持しておき、終了したいタイミングでstop()メソッドを読んで下さい。これで、画面共有が止まります。いずれ、Stream Objectの管理機能を実装する予定なので、その時には専用のメソッドを用意します。

// スクリーンシェアを終了
$('#stop-screen').click(function () {
	localStream.stop();
});

アプリ開発方法の紹介は以上です。

おわりに

今回は、SkyWay-ScreenShareを使った、WebRTCの画面共有機能の実装方法をご紹介しました。画面共有機能は様々なユースケースで活用できる機能ですので、是非ご自身のアプリケーションに組み込んでみてください！

次回は、同じく7月28日にリリースされたSkyWay-DrivingVehicleについてのチュートリアルをお届けいたします。