4/17とちょっと前になりますが、TwitterでやっていたClient-Side Performanceについてのサミットに行ってきました。発表はなんと3人の女性エンジニアで、みなさんプレゼンもカッコよくて興味深い内容でした。ちょっと長くなりますが、是非内容を紹介したいと思います。
Mobile Caching Strategies by Chiu-Ki Chan
最初のプレゼンター@chiukiさんのテーマは「Mobile Caching Strategies」、携帯端末の不安定な回線下で、オンラインでもオフラインでも、いかに安定して動作するアプリをつくるか、でした。発表に使用された資料は以下より閲覧できます。
http://www.sqisland.com/talks/mobile-caching-strategies/
大きな考え方として、データ保持の仕方を次の4つの層に分けて考えて、それを使い分けることによってこれを実現します。
- - Installed （最初のインストール時にデータ自体もインストール、内部で常に保持されている状態）
- - Permanently Cached（初めてそのデータを使用するときにダウンロードされ、ユーザが明示的に更新や削除をしない限り保持されている状態）
- - Temporary Cached（キャッシュディレクトリに保持され、システムやアプリ側で定期的に削除される状態）
- - Never Cached（インターネットを通じて常にデータを取得し、内部にはキャッシュしていない状態）
どの層にどのデータを保持するかは、オフラインでもデータが必要か、どの程度でそのデータのを更新していく必要があるか、などなどそのデータの特性によって選択します。例えば、天気のデータなんかは「Installed」「Permanently Cached」の層に保持するのはとんでもなく無意味です。誰も、アプリをインストールした日の天気を永遠と見続けたくはないでしょう。
データの取得時にも色々な課題があります。データをどのタイミングで、どのように取得するか、また取得中はユーザをただ待たせるのか、それともスプラッシュスクリーンを見せるのか、なども考えるべきポイントです。
ケーススタディーが3例ありましたが、さすがに3つは長いのでガイドブックアプリのTriposoの1つだけ紹介します。Triposoは、基本的にオフラインで十分にその機能を果たすように設計されています。4つの層を元にデータ保持の仕方を表すと、以下のようになります。
- - Installed: ガイドブックの地域リスト、はじめに
- - Permanently: ある地域のガイドブック本体及び地図
- - Temporary: 天気情報、通貨情報
- - Never: なし
使用の流れとしては、まずアプリをインストールすることによりガイドブックの地域（国）リストが入手出来ます。で、今度の休みにオランダに行こうということで、そこでオランダを地域リストから探し、ガイドブックを入手します。この時点で、自分の携帯端末にはオランダのガイドブック本体、地図がPermanently（半永久的）に保持されることとなります。
家でそのままダウンロードしたガイドブックを片手に予習をしている時は、天気情報、通貨情報がTemporary（一時的）情報としてアプリ側で随時更新して表示されます。旅先で、ホテルでネットが繋がっている時なども同様です。もしオフラインなら、通貨情報は古いまま表示し、天気情報は表示しないといった仕様になっています。
この仕組があれば、オフラインでも十分に地図やガイドブック情報が閲覧出来ます。また、このアプリにはCheck in機能があり、旅先で寄った場所にオフラインでもチェックインし、写真やコメントといった記録を残すことが可能です。これは、ローカルストレージに一時的に情報を保存し、次にオンラインになった際にデータをアップロードするといった仕組みです。
ケーススタディもあり、非常に分かりやすいプレゼンでした。携帯端末用アプリの開発時には、このような枠組みがしっかり頭の中にあり、どこにデータを保持するか、どのタイミングで更新するのかなどをしっかり決めておくと、設計もしやすくなると思いました。
Security, Poisoned Caches and Cost vs Benefit by Lien Mamitsuka
2番目のプレゼンター@lientmさんのテーマはデータの保持に関するセキュリティについてでした。実は全体的にちょっと速度が早く、プレゼン資料自体に文字があんまり載ってなかったので理解できた部分が少ないのですが、私のメモによると次のようなことを話していました。
- - 外部のストレージにデータを保持するのは危険である、内部のストレージに保持すべきだ
- - もしアプリがマルチユーザを許可するなら、ユーザ毎にデータはセキュアであり、あるユーザから別のユーザのデータにアクセスできるようなことがあってはならない
…メモを見なおしても、恥ずかしながらビックリするくらい何も書いてありません。英語の聞き取り、もっと精進します。
プレゼン中に一つ、とてもみんなにウケていたクォートがあったので紹介します。
There are only two hard things in Computer Science: cache invalidation and naming things – Phil Karlton
日本語に訳すと、「コンピュータサイエンスで難しいことは二つだ。キャッシュの無効化と、ネーミング。」といったところでしょうか。確かに色んなものに名前をつけるのは大変！みんな納得してました。
Client-Side Storage for Twitter.com by Sarah Brown
最後のプレゼンター@esbieさんのテーマは、Twitter.comで実際に使用されているクライアントサイドのキャッシュについてでした。プレゼンでの笑いの取り方が男性顔負けで、めちゃめちゃかっこ良かったです。発表資料は、どこかにアップしてもらうようSarahさんにお願いしました。連絡がきたら是非リンクを載せたいと思います。
クライアントサイドでのキャッシュには、色々種類があります。この中で、Twitter.comにて使用しているのは次のとおりです。
- - cookies
- - javascript memory localStorage
- - sessionStorage
localStorageやsessionStorageは、クライアントサイドのデータ保持方法です。モダンなブラウザなら全てで対応しています（IE8+）。5MBまでと大きな容量の保存が可能なところが、cookieとの違いです。localStorageはブラウザを閉じても保持され、sessionStorageはセッションごとに保持されます。
例えば、Twitter.comではオートコンプリート機能、未読DM、下書きツイートなどがlocalStorageに保存されています。このlocalStorageなどの使用に対し、csXSS（client-side cross-site scripting）の危険性、つまり何者かによってlocalStorageが書き換えられてしまうことに対する注意の呼びかけもしていました。
最後に、ためになるFriendly Adviceを紹介されていたので記載します。
- - HTMLとしてではなく、JSONの形式でデータを保持しよう – アプリケーションのレイヤーじゃなく、もっとデータそのものを保持しよう
- - ちょっとデリケートなデータには、encryption（暗号化）を考慮しよう – 人が「読める」ものじゃない形にして保持しよう
- - ちょっと疑う時は、sessionStorageを使おう – もしかしたら別窓で別ユーザでログインしてるかもよ
- - 大量データのストレージへの読み書きは慎重に行おう – 書き込み処理は同期処理なので、大量データ=それだけ時間がかかるということ
長くなってしまいましたが以上です！今回は写真無しですが、@womengのアカウントで写真が数点アップロードされていました。Twitterの鳥さんクッキーや、鳥さんケーキがあってとっても可愛かったのですが…カメラを持って行かなかったことが悔やまれます。
ではでは
Leave a Reply