技術をかじる猫

適当に気になった技術や言語、思ったこと考えた事など。

HTML5 Conference 行ってみたメモ

日記 勉強会

片っ端からメモだけのっける。
整形とか知らんし、個人的なメモもあるけど放置で

もっと真面目にやってくださってるまとめ

HTML5 Conference 2015 講演資料まとめ #html5j | Time to live forever

HTML5 Conference

基調講演

東京電気大学

CySec というコースを開設して、社会人学生を募集しているとのこと。

Web and things : JunMurai

海外で骨折って、レントゲン撮ったら、それを日本に転送。
帰国直後にいきなり手術できた。

ネットを使って横につなぐのが我々の仕事。

internet of things という考えがあり、あらゆる種類、業界を超えてデータ経路を繋ぐ考え。
物流の管理を考えると、荷物がどの業者がどこまで運んだ都下をトラッキングできる。

現在は超小型(小指の先)位のサイズでネットワークモジュールができている。
やれる！

House of cards という海外ドラマが賞を撮ったのだが、視聴者が何話まで見たのか、 どういう話でウケたのか、配役はどんなのが人気かとビックデータ解析してできてる。

3D プリンタが一般化すると、物があらゆる境界を超えて共有される。税関も何も関係がなくなる。
プライバシーや信頼性、法整備などが課題。
現在 3D プリンタ印刷時に、個別のRFIDを埋め込むという技術を作った。こういう動きも重要。

イノベーションにデータを活用していると答えた企業の割合は、日本は最下位。世界平均の 1/3 以下ってをい…

キーワード：IoT

Web技術の今後の展望 : Google 及川氏

wearable multicopter robot singlebordcomputer 等が出てきてる。IoT がなかなか一気に広まった。
IoT の検索率が１年くらいで一気に伸びた。

クラウドが普及し、低価格、コンテナ技術、ノンプログラミング、オープン標準なども当たり前になってきてる。

で、HTML5。

Web をコンポーネント化して作れるもの、デバイス機能を利用するもの等も出てきた。 この中でどう変わるのか？

これまで鯖蔵方式だった。IoT の考えから発展を考えると、デバイス自体もインターネットに繋がると予測できる。
その上で、機器がクラウドを経由してデバイス間連携をかけるのが当たり前になる。

現時点ですでに WebSocket なども含み、クライアントが複数のサーバにリクエストするということもある。

はじめてのWeb of Things : Saki Honma NTT Communications ROOM B

Web of things?

Internet of thing : インターネット基盤内で、様々なコンピューティングデバイスが繋がるという考え方。
IP で通信するネットワーク -> Internet と言える。
ここで繋がる thing というのは IP を持ったもの、そこから派生して読めるもの(RFID等)を指す。
よく出る例はスマートメータ等の、インターネットに繋がったセンサー系情報。

IoT はつまるところ、IP通信できるものと、それと通信できるモノのつながりを指す。

Web of things : インターネット層にとってのアプリケーション層を構築するもの。Web で通信できるもののつながりである。
ブラウザ以外での Web 利用が行われている。FaceBook とか。
Web -> ブラウザAPI が提供されているプロトコルだと考えて話を進める。

WoT のサービス作るには？

一般的な web はリンクをたどるものだ。だが、モノのつながりだとリンクなんてない。
ではどうやって繋がるか？

  1. ローカル

    家電の DLNA プロトコル等で使われるプロトコルだ。

  2. 仲介サーバを経由する
    デバイスがサーバにアドレスを登録して、使う側はそのサーバに問い合わせる。このサーバをブローカーサーバという。

デモ

  1. カメラ２台をSSDP経由で接続し、HTTP 通信でリモート取得する
  2. 遠隔地ロボットとの連携。
  3. 電飾デバイスをブローカーサーバ経由でコントロール。
  4. AppleTV を使った AirPlay

作るには、機器検出用のプログラムが必要になってしまう。
また、独自記述になってるからコード互換性がない。

標準化

W3C で標準化中。2010 年位から議論はしてた。

Web of things IG という標準化グループが動き始まった。そこで、 PresentationAPI を策定してる。
Web ページをセカンドスクリーンに写し、操作を可能にするAPI群。実装はまだない。

UserAgent でデバイスを検出して、セカンドスクリーン経由でコミュニケーションを開始するという動き。

ユースケースとして、プレゼン、ゲームとかを考えてる。

これを実装すると、ブラウザで機器の検出機能が入る。
スクリーンのないデバイスでも動くように拡張を狙ってる。

WebRTC 接続はそこそこ夢があるか

WebRTC/ORTCの最新動向まるわかり！ : 中祐介氏ROOM B

概要

ブラウザでテレビ会議を実現する技術として開始。P2P通信が可能になってる。
音声、映像、データのリアルタイムコミュニケーションが可能。

ブラウザ＝ネイティブアプリ両方で実行可能。電話と連携もできる。
WebRTC をサーバ経由でできるらしい。

対応状況として、IE/Safari/iOS系は現時点では対応していない。
検討中。

  • ICE
    インタラクティブコミュニティビティイスタブリッシュメント。
    • 内部ではSTUN(IP/Port を知る)TURN(Nat に穴が開かない場合のサーバ経由プロトコル)を利用
    • NAT に穴を開ける技術に、UDPホールパンチングというのがある。
    • 要するに、常に繋がる訳でもないと
  • シグナリング
    サーバ経由で、どういう通信、データ形式が可能なのかという情報をやり取りする。プロトコルはSDP
  • DTLS
    通信経路暗号化。共通鍵交換制御とか。
    データは全てこれを通過。音声、動画は、ここから鍵を取得してエンコードする
  • ブラウザはPCの音声映像ストリームにアクセスすると

標準化

W3C

  • WebRTC WG
  • MediaCaputure WG

IETF (通信プロトコルの規格とか制定)

議論中API

  • RTCPeerConnectionAPI
  • MediaCaputure API

提案レベル、議論レベル

  • WebRTC Stats API : 通信状態等、統計情報を収集するAPI (Draft)
  • DTLS KeyControl : 鍵証明書発行を JS でできるようにする。(先送り中)
  • WebRTC RtpSender/Reciever : SDPを扱うための新しいアプローチ。Google提案。ORTC の提案内容がまさにこれ。大枠合意。
  • Promises : ストリーム的な処理がかけるようにしたいって話。大枠合意。

ORTC

ORTC:
WebRTC がイケてないので、どげんかしたい。から作る！
API が高機能すぎて細かい事ができない。レガシーすぎて使いにくい。
ステートレスに処理が書きたい！データ構造JSON使いたい！
一方的の単方向通信したいねん！
そこで SDP よりこっちをしたい。

MS は強く賛同してた

しかし反対多数で不採用に。

WebRTC への融合

少しづつ取り込まれる想定

事例

SkyWay を NTT さんが公開。開発者使ってよー。
海外でもWebRTCは結構使われてる。
FireFoxHello というサービスもある。

talky というサービスがいい感じ。デスクトップシェアとかFireFoxでできる。

WebRTC Conference

国内初！
３万する。会社でくるか、CodeIQ 答えてきてー。

同時刻の e ルームの話

http://fracoco.co/2015/01/25/html5-conference-2015-now.html

HTTP/2の現状とこれから : 大津氏(IIJ)ROOM B

http://www.slideshare.net/shigeki_ohtsu/http2-ohtsu-html5conf2015

HTTP2 はRFC直前です。桜が咲く前には出そう。
HPACK : Header の圧縮化仕様は承認済み。

HTTP1.1 の問題

2012 年まで結構なぁなぁだった。

  • Head of line blocking
    １本のTCPでやり取りは基本的にシーケンシャルでしか処理できなかった。
    サーバもリソース的にTCP本数制限をしていたので、尚更遅くなる。
  • ネットワーク通信の効率化
    ネットワーク通信のアルゴリズムがひどい。帯域を意識しながら少しづつ速度をあげてる
  • 曖昧でテキスト処理が煩雑
    テキストで返すな！遅いんだよ！

解決方法

  • Head of line blocking
    一つの TCP コネクションで、複数のリクエストとレスポンスを行う事で解決
  • ネットワーク通信の効率化
    コネクション数が少ないので、バラバラで待機を意識しなくていい。
  • 曖昧でテキスト処理が煩雑
    バイナリ通信にしたらええやん

現状

nginx/apache2 plugin あり。
ブラウザも最新の物は全て対応。FireFox 35 over / Chrome 41 / IE 10

Google/Twitter は既に対応済み。

最終仕様：

  • priority
    • ファイルタイプによる優先度指定
    • タブ切り替えによるロード優先度の変更
    • 分割ビデオデータなどのロード順等
  • ホップバイホップヘッダの利用禁止
  • TLS 利用条件の厳格化 TLS ないと http2 入らんよ。tls 1.2 必須ですわー。

これから

  • http3
    • 負荷分散やメンテナンスなどのサーバ切り替え、プロトコル切り替え
    • WebSocket が多重化できるように
    • 明示的プロキシ機能
    • 日和見暗号
      http の通信でサーバ認証せず暗号化だけ行う
  • Web Push
    • ブラウザ上でPush
    • ブラウザは立ち上がってても、アプリが立ち上がってない場合
    • ブラウザが立ち上がってなくてもプッシュしたい
    • 一つのブラウザでアプリを複数インスタンスで立ち上げてる場合に選んだり、全体等にプッシュ ServiceWorker + ServerPush を使って、Push 専用サーバを立ててしまい、このサーバにはコネクションを貼りっぱなしにするなどする
  • QUICプロトコル
    Google 独自開発プロトコル。
    UDP で TCP + TLS 相当の機能を実装するというもの。
    Google 全サービスでテスト中。

同時に何かあったスライド

http://www.slideshare.net/YoshihiroIwanaga/web-technology-html5-conference-2015

Web of Things を実現する技術 - Mozilla が取り組む Web プラットフォームの進化 : TomoyaAsai (MozillaJP)ROOM A

Twitter : dynamis

2/13 にセミナーやるよ

FireFoxOS

SmartTV 出ます。あらゆるデバイスに乗せてもらって動くことを目標として作ってる。
全部オープン技術で繋がるのが一番幸せなんだよ

NativeDevice

Matchstick : Chromecast の FireFoxOS 版。
HW からしてオープンです。アドホック通信可能だし、単体で動くぜ。

AU で OpenWebBord という HTML デバイスも作ってる。

MozOpenHardware Webで繋がるハードというプロジェクトがある。

HigherLevelEvolution

WebAPI でセンサとかGPSとかふつーだよね。

JS に固定型配列も入ったし、asm.js でネイティブ速度で 3D できるぜ？
Emscripten で C から移植して動く。

最近は unity/playcanvas/UNREAL/Marmalade/turbulenz とかも移植されてる。
GPU処理がメインならネイティブとの差は殆どない。

スレッドやSIMED命令とかがネイティブの差か？

FoxEye project

  • MediaCapture & stream を拡張
  • 文字認識、顔認識とかできる
    基本書英は WebImage 複雑なのは OpenCV とかやる

最近は VR/顔認識/パノラマとかできるようにがんばってます。
Web も VR にしたいよね。

mozvr.com とかアクセスすると面白いかもね

LowerLevelEvolution

  • asm.js
    JavaScript サブセット。既存の JavaScript で動作。
    ひたすら最適化されたもので、静的型で事前コンパイル可能。
    経験的に JIT する必要がない形式にする

  • Emscripten 演算結果を固定型に、型を明示(Accotation)などなど。
    何をするって、LLVM の中間言語を JavaScript に直すという気持ち悪さ(褒め言葉)。そうすれば静的型で最適化・高速化できるよねー

HTML5ハイブリッドアプリ開発のベストプラクティス : ROOM A

  • HTML5 の弱点
    デバイス独自の機能が使えない点。 そこで、ハイブリッドアプリは、ネイティブ層を持つ。

他のクロスプラットフォームアプリとの違いは、言語が JavaScript 固定、実行環境が WebView
Cordova は実質、HTML ハイブリッドアプリではデファクトと言っていい。

Adobe が PhoneGap を買収した経緯があったので、Cordova という名前で Apache 上で細々と続いた。

Android/iOS はネイティブ実装層で動かして、他はブラウザで動く。
ちなみに、公式に「いずれ消えゆくもの」と言っている。

ちなみに Android の 5.6% は Cordova で動いてる。
Skype/Line なんかはこれを使ってる。

尚、インストールベースでは、ゲームがほぼ作られてないので利用率少ない。

個別カスタマイズよりも、共通化を考えるとできるが、環境ごとの独自機能を使い出すとしんどい。
UI を徹底しようとすると、速度が出ない -> ゲームに使われない理由。
あと、移植とかふざけんな

最近 WebView が選べるようになった。
iOS : UIWebView 以外に、WkWebView ベースで使える。なまら早い。
Android : WebView (android default) ChromiumWebView(CrossworkEngine)

Look & Feel は OS ごとに癖があるので、なんとなく似てるようなものを採用される。
具体的な内容は Cordova で吸収してくれる。

やる前に : * Cordova のドキュメントは読む * ある程度ネイティブ開発の知識は欲しい * OS フレームワークの基礎知識 * AndroidManifest, indo.plist とか * Cordova API の叩き方とか

プラグインは選定しよう :
プラグインを利用することで、幾つかの機能を追加できる。
写真を撮るとか、GIOLocationAPI 拡張とか。
デフォルトでは HTML5 機能を超えることができないので、欲しければプラグインで API を追加しよう。

癖として、SPA アプリケーション的に作らないとしんどい。AngularJS がよく使われてるっぽい。
UI フレームワークも使う Sencha(ExtJS) や、ionic/OnsenUI (AngularJS) を選定する。

IDE は Monaca かなぁ？

USB リモートデバッグができるようになってきてる。
Android4.0 以降の Crosswalk WebView もしくは Android4.4 以降 + ChromeDevTools。
iOS + Safari でもデバッグできる。

開発体制を考える必要がある: * UI 20 - 40% * フロントエンドエンジニア 50 - 70% * OS 側のエンジニア (アプリケーション間通信とかしたければ)

cross origin には気をつけないと危険です。

下記は対応するか、覚悟しれ:

  • WebView のバグ
  • XSS 等の脆弱性
  • コード隠蔽できない

課題: * Web だけでもネイティブだけでも知識としては微妙 * メンテナンス：バージョンアップ超重要。 * 情報なさすぎるわ

作ろう、FireFoxOS アプリ

http://www.slideshare.net/chikoski/firefox-os-43867933