概要

仕事がドタバタしていた中で、最後まで参加できるかどうかかなり微妙な感じだったけど、無事参加。特にオフライン・ファーストの話は非常に面白く、試しで何か作ってみたいと思うような話だった。

また、イベント自体も参加人数が500人という大賑わいのイベント。HTML5がメインということでどちらかと言うとプログラマよりデザイナ系の人のほうが多かったかもしれない。少なくとも会場のアンケートの職業欄には、「プログラマ」という欄は存在しなかった。「サーバエンジニア」はあったんだけどなぁ。

USREAM

12105教室
: http://ustrh.am/TDVb

12106教室
: http://ustrh.am/TDV6

12107教室
: http://ustrh.am/TDUI

オフライン・ファーストの思想と実践。白石氏

オフラインファースト

「Offline first a better HTML5 User Ecperience」という記事で取り上げられた考え方。ただし「オフラインで使えるWebアプリケーション」という考え方自体は、2007年のGoogle Gearsなど昔からある考え方。しかし流行らなかった。

オフラインWebには、「オフラインで使える」「スピードが速い」という特徴がある。結果、ユーザビリティが向上する。

「Offline is Feature」

ではなぜ、今まで流行らなかったのか？。
オフラインで使えるということは「自然とそうなる」のではなく「一種の機能」である。機能であるがため、意図的に実装を行う必要があるが、読むのが中心のWebサイトでは、オフラインで使えるという機能を実装するコストがメリットを上回らない。

一方モバイルアプリなど編集が中心のWebサイトでは実装するためのコストがメリットを下回る。また、今後の企業向けモバイルアプリの大半はHTML5になるという予想も有り、オフライン・ファーストの考え方は大切。

読むのが中心のサイト
: コスト ＞ メリット

編集が中心のサイト
: コスト ＜ メリット

オフラインWebのためのAPI

オフラインWebを実装するためには、いくつかの手段がある

アプリケーションキャッシュ

Cache Manifestと呼ばれるファイルリストを作成し、ブラウザにキャッシュを指示するもの。大量のページを対象にするとキャッシュの容量の制限やキャッシュの構築の時間がかかるのが欠点。Titanium Mobile 2.0.2 API Documentsなどで使われている。

・#3 「あまりApplication cache（cache manifest）のことを甘く見ない方がいい」 Advent Calendar 2012 | tech.kayac.com – KAYAC engineers’ blog
・アプリケーション キャッシュ初心者ガイド – HTML5 Rocks

Web Storage

ブラウザに組み込まれているキー・バリューストア型のデータベース。格納できるのは文字列のみだが、JSONを使うことで様々なデータを格納することが出来る。JSONでデータのやり取りを行うため、使い方によっては遅いことがある。

Indexed Database API

ブラウザに組み込まれているデータベース。Javascriptのオブジェクトをそのまま格納することが出来る。また、非同期で使用できたりとWeb Storageよりも高機能だが、RDBMSほど柔軟ではなく、APIがイケてない。また、SafariやOperaでは実装されておらず利用できない。

File API

Chromeのみで実装されているAPI。なのでChrome以外では利用できない。GoogleのGoogleSlideではこのFileAPIを利用して実装されている。

オフライン・ファーストの勘所

オフラインWebは、通常のWebサービスと前提が全く異なるため、開発の途中からオフラインWebの機能に取り組むのは難しい。そのため、Webアプリケーションの最初の設計から想定しておく必要がある。

例えば、アプリケーションとサーバを切り離して開発を行ったり、Wrapperを通じてWeb側のAPIを呼び出すなどして、データソースやネットワーク呼び出しを抽象化しておく必要がある。

データの同期処理も難しい

オフライン・ファーストに必ず必要なデータ同期処理も難しい。これを楽に実装できるようなAPIなどが標準化されることが望ましい。
・同期の途中でオフラインになったら？
・更新が衝突したらどうする？
・必要最小限のデータ動機を行うためには？

NoSQL DBとJavascript。原田氏

NoSQL誕生の背景

Webの拡大によって、RDBMSとSQLの組み合わせでは手に負えない状況が増えてきた。そこで、各Webサービス提供者やデータベースベンダがそれぞれに問題を解決するため新しい仕組みを作り始めた。例えば、Google、Facebook、Twitter、Oracleなど。

そのため、NoSQLと呼ばれる一つのものがあるのではなく、様々な考え方のものが存在しNoSQLと一括りにはできない。また、それぞれに向き不向きがあるため、すべてのRDBMSがNoSQLに置き換わられるということではない。例えば、RDBMSはトランザクションや集中管理に向いている。

種類と特徴

NoSQLにはいくつかの大まかな種類と沢山のプロダクトが存在する。ドキュメントストア(html5 Indexed Database)、オブジェクトストア、グラフストア、キーバリューストア(html5 Web Storage)、カラムストア(Hadoop, Google Bigtable)など100種類以上のNoSQLが存在する。

よくNoSQLの特徴としてあげられているものもNoSQL全体の共通項目ではないので要注意する。例えば、スキーマ定義は不要、Rest/JSONのAPI、JSONを格納できる、Javascriptエンジン/シェルを含むなど。

Javascriptエンジンにも色々な種類がある

SpiderMonkey、V8、Javascript Core、Rhino、Trident、Chakraなど。それによってNoSQLに組み込まれているJSエンジンも異なる。Javascriptエンジンによっても向き不向きがあるため要注意。

Webの例(ライブコーディング)

ブラウザに組み込まれているIndexed DatabaseとWeb Storageを使ってJavascriptによるデータベースアクセスをライブコーディング形式で紹介。

Local Storageはブラウザ全体で共通して使える。永続化も。使用できるのはSame Originポリシーの適用範囲内で利用可能になる。Same Originポリシーは、同一ドメイン、同一ポート、同一プロトコルの範囲のみ。Session Storageは、一つのタブやウィンドウで独立したストレージ。永続化は行われない。 Indexed Databaseは使うのに手間がかかる。白石さん曰くイケてない。

ハイブリッドアプリ開発最前線から見たHTML5ｎ理想と現実。田中氏

ハイブリッドアプリとは

・モバイルのは様々なOSが混在、そして今も増加中
・html5で作るとマルチプラットフォームで動く？でも遅い？

ハイブリッドアプリとは、ネイティブアプリの良いところと、HTML5の良いところを組み合わせて開発するアプリ。ガートナーの予想では2015年には企業向けアプリの50%はハイブリッドアプリになる。

例えば、HTML5＋(PhoneGap、TriggerJO) + (Zept-js, Jquery,Sencha Touch) + (Objective C, Java)などの組み合わせ。世界的にはとりあえずPhoneGapを使っておこうという風潮もある。

HTML5の利点と欠点

Monaca(デモ)

HTML5で作られたハイブリッドアプリの開発環境。ブラウザベースのWeb IDEとPhoneGapベースのフレームワークの2種類の形態で提供中。

AndroidやiPhoneアプリとして提供されている「Monaka デバッガー」を使用することで、Web IDEで開発した内容が自動的に更新され確認することができる。また、HTMLで苦手なLook&Feel(メニュー、アニメーション、ツールバー、タブバー)や速度が出ないところ、ネイティブの機能などをネイティブ開発することで補うことができる。

ハイブリッドアプリの問題点

デバッグがしづらい、クロスプラットフォームへの対応の難しさ、フルネイティブと比較した時のヌルサク感、ネイティブを組み合わせること
によるポータビリティなど、問題点はある。

HTML5は本当にマルチデバイス対応の銀の弾丸か。羽田野氏

マルティデバイスとは？

Web業界では、PC、携帯、スマホ、タブレットなどに対応することをマルチデバイス対応ということがあるが、本当にそれだけだろうか？例えば、ゲーム機、テレビ、車、デジタルサイネージなどHTMLやWebの技術が利用されている領域は増え続けている。それにより、スペックの多様化、OSのフラグメンテーション、ブラウザの多様化など、個別の作りこみにも限界がきている。

では、HTML5ならばOne Source Multi Deviceが可能なのだろうか？これは独自のAPI、独自のパッケージング、独自のUIなどデバイスごとにことなるため不可能。これが現実。

例）テレビに組み込まれているブラウザ(OperaやNetFront)のHTML5対応度は下手なスマホよりもよっぽど高い。でも、テレビのマシンスペック自体が低いため、実行速度は遅い。

例）スマホやタブレット、カーナビ、テレビなど、用途によってUIは全く異なる。

コンテンツ流通の限界

レイアウト、スケール、プログレッシブ・エンハンスメントなどが異なるため、微妙な調整が難しい。MVC的な考え方を導入し、MCと共通化し、Vのみを各デバイスごとに準備するなどの対応は今後も必要になっていく。

HTML5でOne Source Multi Useは可能か？

同じ言語でアプリが作れることは、学習コストやトータルのコストが低下するためHTML5の利用する意味はある。ただし、常に理想と限界のギャップが存在するため、今後も環境に応じた調整を行なっていく必要は続く。そして、HTML5自体も進化が続いていく。

Web技術の目利き

HTML5によってビジネスの競争の土台が変わった。アプリの基盤や開発技術のコモディティ化が進んでいる。そのような世界で起業や開発者が生き残っていくためには、採用する技術やマーケットを最先端の業界の中で見極めて集中と選択を行なっていくための目利き(ソムリエ)としての能力が必要になって行くのではないか？

気になった話

デジタルサイネージには、動画コンテンツは向かない。なぜならサイネージを見つけて通り過ぎるまでにかかる時間は5秒以下。そのようななかでコンテンツを見せようとしたとき、動画のコンテンツでは間に合わない。もちろん休息所など人が長時間留まることが考えられる場所であれば別。

サイネージに表示する画像についても、通り過ぎるまでの時間を考慮して切り替える必要があるし、動きをつけるのならばその秒数以内とする。

クロージング

クロージングでは、プレゼントの当選者の発表や全体の質疑応答などがあったので、その中からいくつか。

HTML5をより高速化するにはなにができるか？

・JSではなくCSSでやる
・HTTPのリクエストを少なくする
・minifyやgzipなどを行いデータサイズを減らす
・ファイルの数を減らす
・例えばCSSで影をつけるより、影付きの画像をあえて使ったほうが早くなることも

Adobe Edge Codeは単独提供されないのか？

自分が聴講していない話の中でそういうアプリが紹介されたらしい。

Adobe Edge Codeはオープンソースプロジェクト「Brackets」のディストリビューション版とのこと。なので、それを利用してもいいかもしれないとのこと。Adobe Edge CodeはCSS編集、CSSエディタらしい。

参加者のブラウザの使用状況

ブラウザ毎に挙手してもらったところ、会場の参加者は、ほぼChromeユーザ。9割くらいだったかも。

IE = Safari < Opera < Firefox <<<<< Chrome