Twitter Flock 2015 Tokyo に参加した

2015-05-19 (火)、Twitter 社が開発者向けのカンファレンス「Twitter Flock」を開催した。Twitter Flock は世界中で開かれ、東京はそのツアーのラストだった。

概略

• 日時: 2015-05-19 (火) 14:00-18:10
• 場所: ラフォーレミュージアム六本木
• 参加費: 無料
• 定員: 200 人くらい?

会場は公開無線 LAN あり。電源はなし(?)。

講演内容

講演は 6 つのセッションから成った。内容は Twitter のモバイル向け (iOS/Android) フレームワーク Fabric と関連するライブラリーの説明。講演者は基本英語を話して、同時通訳用のヘッドセットが用意されていた。

簡単に内容をまとめてみる。

1. オープニング・スピーチ: Fabric の紹介とパートナー企業による利用事例紹介。招かれたのは三者: サイバーエージェント、cameran by リクルート、OneNews from かみあぷ速報。サイバーエージェントは各種アプリで Twitter のライブラリーを使っているということで全般的な話を、残る二者は代表するアプリに絞って話を聞いた。
2. Digits: 電話番号 + SMS による認証を提供するライブラリー。電話番号と SMS API は国をまたがると複雑化して管理しきれなくなる。Digits はそういった難しいことを全部ひき受けてくれる。多言語化もサポート。なによりフリーなのが嬉しい。Digits には HTML5 版も提供される。216 か国、32 言語に対応。
3. Crashlytics: クラッシュ・レポートを提供するライブラリー。(App Store/Google Play に申請する前の) 社内テスト配布のための仕組み Beta by Crashlytics の説明も。また、リアルタイム解析エンジン Answers の紹介もあった。これは Google Analytics のようなもの。Crashlytics を利用することが前提になっている、
4. TwitterKit: Twitter を使ったシングルサインオン、ツイート送信、タイムラインの取得+表示を行なうライブラリー。Twitter の API を叩くよりも簡単に、アプリから Twitter を操作できるのがウリ。先に紹介された OneNews は Twitter のタイムライン表示をこれでやっている (という話だったはず)。レンダリングまで任せられるのは便利。
5. プロモーション: Twitter を使ったプロモーションの話。スーパーボウルで流された CM や Path の事例が紹介された。話は少しそれるけど、ディープリンク (twitter:// など) の利用についても詳しく説明があった。
6. MoPub: Twitter が提供するアプリ向け広告 (Ads)。Twitter という巨大なネットワークを元にモバイル向けの広告を集めている・配信できる、というのが強みなのかな。

Fabric を使うと、Crashlytics, TwitterKit, MoPub を数ステップでアプリに組み込むことができるようになる。そうそう、デモで使用したアプリ Cannonball のソースコードは Github で公開している。ありがたい。

• twitterdev/cannonball-ios
• twitterdev/cannonball-android

あとがき

Twitter が提供するライブラリーの説明に終始していたけれど、どれもモバイル向けに特化していて一度は使ってみたいと思うものだった。企業によるアプリ開発だけでなく、個人開発でも使えそうなのが良かった。自分用のアプリに組みこんで遊んでみたい。

HTML5 ついに勧告となる

HTML5 がついに勧告 (Recommendation) になった。つまり、仕様が正式に固まったということ。

2014-10-28 に正式発表された。こちらは W3C によるニュース・リリース:

• HTML5勧告–オープン・ウェブ・プラットフォームの重要なマイルストーンを達成
• Open Web Platform Milestone Achieved with HTML5 Recommendation

そして仕様書。既に日本語訳もある:

• HTML5
• HTML5日本語訳

思えば勧告候補 (Candidate Recommendation) になったのが 2012 年の 12 月。この時点で、2014 年勧告予定とは書いていた。あと 2 か月で 2015 年というところで、ようやく勧告。本当に関係者の皆さんはお疲れさま!

• clmemo@aka: HTML5 勧告候補になる!

HTML5 勧告候補になる!

HTML5 がついに勧告候補 (Candidate Recommendation) になった。HTML5 の情報を集めている白石さんのブログの記事が詳しい。

• Shumpei Shiraishi's Weblog: ついにHTML5が勧告候補に！そしてそれが意味するもの

勧告候補後は、Proposed Recommendation (勧告案) を経て Recommendation (勧告) となる。勧告が仕様の最終確定 (2014 年を予定)。ただし、勧告候補になるということは、「仕様を大きな変更がない」ので「皆さん、実装お願いね」ということなので、HTML5 に関してはほぼ仕様が確定したと言っていい (らしい)。

ちなみに HTML5 は、一応これで「変化しない」けれども、次期バージョン HTML 5.1 の Working Draft が現在作成中となっている。

HTML5 勧告候補の意味

さて、今回 HTML5 の仕様が固まってきたことに対してどういう意味を持つのか。白石さんのブログから引用したい。

(勧告候補は) 終わりなき仕様開発作業における、単なるスナップショット以上の意味は持たないのではないかと。

(中略)

スナップショット以上の意味は「ある」と感じるようになりました。

(中略)

それは、実装者にとっての明確な目標が定められたということなのだろう、と。

常に変化し続けるMoving Targetではなく、明確なバージョン番号を持つ静的な目標が確立されたことにより、私たち開発者はその仕様への準拠をブラウザベンダに期待します。そしてブラウザベンダもそうした期待に応えようと、実装の優先順位を静的なバージョンの追随に向けて調整せざるを得ません。そしてそれは、現在のWebが抱える実装度合いの断片化という問題を解決することにもつながっていくでしょう。

Shumpei Shiraishi's Weblog: ついにHTML5が勧告候補に！そしてそれが意味するもの より引用

そんなわけで、実装が明確になることでぼくらプログラマーもより HTML5 を利用しやすくなる。ひいては開発スピードやバグが減り、ユーザーに対しても良い効果が生まれることが期待される。これは嬉しいね。

使って欲しい 3 つの HTML 5 — ruby, details, scoped style

HTML 5 には面白い新機能が沢山ある。その中で、特にブロガーが使うのに便利そうな 3 つの新機能について紹介したい。

ルビ

ruby 要素はテキストにルビを振る。古い HTML 時代から存在しているので、見かけることは多いけれど、HTML5 のルビはシンプルなフォーマットで書く様になっている。

<ruby>文字 <rt>ルビ</rt></ruby>

たったこれだけ。ただし、これだとルビ非対応のブラウザーでルビ文字が連続して現れる。例えば、次の様に入力すると

<ruby>都 <rt>みやこ</rt></ruby>

非対応ブラウザーでは

都みやこ

と表示されてしまう。これは見苦しいので、次のテンプレートをぼくは使っている。

<ruby>文字<rp> (</rp><rt>ルビ</rt><rp>) </rp></ruby>

こうしておくと、ルビ対応なブラウザーでは rp 要素内が消え、非対応なブラウザーでは rp 要素の中身が現れる。サンプルを一つ。

<ruby>都<rp> (</rp><rt>みやこ</rt><rp>) </rp></ruby>

非対応ブラウザーの出力は次の通り。

都 (みやこ) 

Google Chrome の出力は次の通り。

details 要素

details 要素を使うと、「詳細はこちらをクリック」「続きはこちらをクリック」みたいなことが JavaScript なしで出来るようになる。使用例として、過去記事「Google 乗換案内がバスルートをサポート」で「地域別サポートバス会社一覧 - 49 社（五十音順）」を隠しているのでよければ触ってみて欲しい。

文字部分をクリックすると、サポートバス会社一覧が表示される。

details 要素の書式は次の通り。

<details>
<summary>サマリー文字</summary>
詳細...
隠したい文章...
</details>

JavaScript を使わなくて良いのがオススメ・ポイント。なお、非対応ブラウザーでは details 要素内は「見えて」しまう。ユーザー・アクションがない限り絶対に見せたくない、という用途には向いていない。

スコープのある CSS Style

普通、CSS はスタイル・シートを別ファイルに持つかウェブ・ページの先頭で指定する。けれどブログでは、この記事でだけ使いたい CSS スタイルが欲しい場合がある。

先日、新しい iPad と Google Nexus 7 の違いをテーブルに書いた。そして優れている方を「青文字」で書いた。scoped style を使わないなら、次の様に書く。

<td style="color: blue;">優れている</td>

このやり方は二つの点でスマートじゃない。一つは、何故優れている方が青字なのかが分からない点。もう一つは、色を青から赤に変えようとした時に置換に頼らなければならない点。特に後者はケアレスミスを招きやすい。今回の例では、blue を red に置換すると「bluetooth」が「redtooth」に誤置換される恐れがある。

そこで、scoped style を使う。書式例は次の通り。

<table border="1">
<style scoped="scoped">
  .better { color: blue; }
</style>
<tr><th>解像度</th><td class="better">264 dpi</td><td>216 dpi</td></tr>
...
</table>

こう書くと、ソースコードを見て 264 dpi が better だと分かるし、色を変えたい場合は scoped style の CSS を書き直すだけで良い。

そうそう、「スコープ」の説明もしておこう。style 要素に scoped 属性を上記の様に設定すると、一つ上の親の要素の中でだけ、そのスタイルは適用される。上記の例では style 要素の親は table 要素だから、table 要素の中でだけスタイルが適用される。

こういうスタイルは、全体のスタイル・シートで決定することが難しい。もしかして、better の他に worse があるかもしれないし、良し悪しの比較ではなく別のことに色を付けているかもしれない。それはブログの記事によって変わるもの。scoped style は正にそういう悩みを抱えるブロガーにピッタシの機能。

サポート・ブラウザーについて

デスクトップ版の Google Chrome と iPad の Safari が上記の機能を全てサポートしていることを確認した。

なお、ブラウザーに限らず Google Reader では、全ての機能がサポートされていないことも確認した (2012-10-01 現在)。この点に関しては、一刻も早い Google のサポートを期待したい。

あとがき

ルビに details 要素に scoped style は一年位い前からこのブログでよく利用している。フィード・リーダーがサポートしてくれていないのは痛いけれど、それにも増して「書きやすい・読みやすい」というメリットがある。

少くとも Blogger のテンプレートは HTML 5 なのでこれら要素を使うことに問題はない。また、他の HTML 5 じゃないブログでも、おそらく HTML 5 の書き方をしてもブラウザーが良きにはからってくれると思う。よければ試してみて欲しい。

HTML5 Conference 2012 に参加した

2012-09-08 (土)、HTML5 Conference 2012 に参加した。1000 人の受付に対して、受付開始 30 時間で定員達成。参加できただけでも、運が良かった。

概要

• 日時: 2012-09-08 (土) 11:00-18:00
• 場所: 慶應大学 日吉キャンパス
• 定員: 1000 料
• 参加費: 無料

ノベルティは大したものじゃなかったけど、大学キャンパスの学食券 500 円分が支給されたのは助かった。ホールに電源環境があったのは良かった。無線 LAN は会場側が用意していたけれど、タイムアウトで接続できなかった。

基調講演

管理人の白石氏と Google の及川氏が HTML5 の過去・現在・未来について語った。

HTML5 の進歩とともにウェブの可能性が拡がり、技術が複雑化し、安全・安心への責任が問われる様になった。しかし、過渡期を経て「使われる技術」になる。とのこと。

HTML5 の歴史なんかが語られて、あまり基調講演らしからぬ講演だった様に思う。

HTMLとか CSSとか APIとか

今まで W3C と WHATWG で Editor を務めていた Ian Hickson 氏が WHATWG HTML に専用することになった件について解説。HTML5 業界では大きな話題になっていたけれども、W3C と WHATWG が喧嘩しているわけじゃなくて、Hickson 氏にとってオーバーワークになっただけ。HTML5 は WHATWG のスナップショット的な位置付けだけど、その立ち位置が変わるわけじゃないよ〜、というお話。

この後、最新の HTML5 の要素や CSS の説明をしてくれたけど、スライドが速すぎてメモが追いつかなかった。CSS4 なんてもう始まっているのにびっくりした程度。あとは... 本当に仕様に組み込まれるのか分からない話だったので割合。

HTML5 時代の Web デザイン

ウェブページをパソコンのウェブ・ブラウザー用に Flash やピクセル指定でレイアウト設計していた人には耳の痛いお話。

ウェブ・ブラウザーの数は過去バージョンを含めると膨大になった。デバイスは多様化しディスプレイの大きさも千差万別。回線の太さも違いが大きい。利用シーンも変化してきた。

もはや、今までの考え方を変えていかないと多様化している環境に対応することは難しくなってきている。「見た目」がどの環境でも「同じ」である必要はどこまであるのか? Web をデザインするということを皆で考え直してみませんか? 今まで良しとされてきたその価値感を壊すくらいに。

更に進化する CSS の表現力と新しい Web ツール

Adobe の人が講演者というので、正直期待していなかった。終わってみたら、一番面白くて一番笑った講演だった。Adobe 侮りがたし!!

Adobe の HTML5 に対するトライは下記ページで公開されている。

• Adobe & HTML

Backets

Open Source で開発されているシンプルなコード・エディター。HTML, JavaScript, CSS で作られている。コード・エディターで変更した文書は、すぐにブラウザーに反映される。

HTML 要素で Ctrl + E すると、関連する CSS が表示できる。目から鱗な機能。ぼくが Emacs から離れることはないだろうけれども、興味ひかれる機能。ちょっと遊んでみたい。

WebKit -- CSS Regions

CSS の最新仕様を頑張っているとのこと。CSS Regions のデモを見せてくれた。

CSS Regions は雑誌のようなレイアウトをシンプルな CSS で表現する。

CSS Exclusions というのもあって、これは自由なレイアウトに沿ってテキストを流し込むという。パイ・チャートの中に文字を入れたり、車 (の写真) を回り込む様に文字を配置したりできる。

CSS Regions の設定は chrome://flags から「領域」を検索してチェックを入れる。

Adobe Shadow

モバイル・サイトのリモート検証ツール。

PC を母艦に接続したデバイスを複数リモート操作する。PC の Chrome で画面遷移すると、PC に繋っている全てのデバイスで画面が遷移する。複数デバイスの UI テストに力を発揮しそう。

あとがき

とにかく Adobe の発表が面白かった。他は既知の事だったり、未知すぎることだったりで追いつけなかった。

小さなチャンスを掴んで参加権を得、Adobe という思わぬ伏兵のセミナーを聞くことができた。運が良かった。

NTT R&D: リアルタイムグラフ可視化技術

NTT R&D フォーラムで見た展示のメモ。

• ref. clmemo@aka: NTT R&Dフォーラム 2012 に参加した

リアルタイムグラフ可視化技術の展示

Twitter から拾い上げたキーワードをリアルタイムにネットワーク・グラフ化して表示していた。

メモ

本展示は、HTML5 の技術を使うことでリアルタイム処理を行なえる様になることの実演デモ。キーワードは 3 つ。

• WebWorkrs
• WebGL
• WebCL

キーワードを理解していれば、驚くほどのこともない展示。ただ、知らない用語があったので、勉強を兼ねて自分の言葉で説明してみる。

WebWorkrs

JavaScript をスレッド化する技術。JavaScript は描画と演算を同時に行なう場合、計算結果を表示するようなウェブ・アプリは計算が重いと描画が止まってしまう。WebWorkers で描画と演算を別スレッドにすることにより、描画処理を向上させる。

WebGL

三次元描画用の API。二次元描画には Canvas と SVG があるけれども、三次元は扱えない。結果、プログラマーが三次元情報を二次元に落とす様なプログラムを書く必要がある。WebGL は最初から三次元を二次元表示する仕様なので高速。またグラフィック・ボードの支援を受けて更なる高速化も期待できる。

WebCL

JavaScript の計算を GPU で行なう API。つまり、グラフィック・ボードの支援能力を使う技術。CPU が不得手とする計算を GPU に任せてしまう (CPU/GPU には得手不得手がある)。特に三次元描画系の計算は CPU より GPU が得意とする。

WebWorkers, WebGL, WebCL とグラフィック・アクセラレーションを使うことで、従来の 200 倍の高速化を実現。

あとがき

用語は知っていても、プログラミングしてみる機会のなかった分野。ちょっとプログラミング熱がわく展示だった。

NTT R&D: パーソナル情報スタイル

NTT R&D フォーラムで見た展示をレビューする。

• ref. clmemo@aka: NTT R&Dフォーラム 2012 に参加した

本エントリーでは 2 つの展示を一緒にレビューする。というのも、2 つの展示がセットになっていたから。対象の展示は下記:

• C-6 パーソナル情報スタイル
• J-2 HTML5 による次世代コンテンツ流通サービス

パーソナル情報スタイルの展示

TV が一台、NHK の番組を映している。主役はユーザーに渡されたタブレット。タブレットには今見ている番組の関連情報が表示されている。ユーザーのアバターを中心に、キーワードがネットワークで繋がっている。この UI を InfoSkin と呼ぶ。

※タブレットの画面を撮影しようとしたら、照明の光が反射してどうにも上手く撮れなかった。幸いディスプレイにもタブレットの画面が表示されていて綺麗に写真が撮れたので、こちらをサンプルとして使う。本来はタブレットで使う UI。

キーワードはウェブ・サイトへのリンクになっている。タップすれば、そのサイトに飛ぶ。番組を見ながら、Amazon や Google News にアクセスできるというわけ。

更に画面をよく見ると、「父」の周りに輪っかがあるのが見てとれる。これがパーソナライズの UI になっている。輪の中にキーワードをドラッグすると、「そのキーワードに興味あり」と判断される。ネットワーク図が描き変えられ、そのキーワードに関連した情報が多く表示される。逆にキーワードを輪の外に放り出すと、「そのキーワードに興味なし」と判断される。そして、ネットワーク図が再び描き変わる。

表示されるキーワードは、番組の進行に従っても変わってゆく。ネットワーク図もそのたびに変わる。

一つ注意したいのは、この UI に今まで一度も「キーワード入力」が使われなかったこと。

1. テレビ局側からの情報
2. ユーザーのキーワード移動

この 2 つだけで、見ている番組の関連情報を手に入れられるのが面白い。父と娘が同じ番組を見ていても、各々が別々のタブレットを持ち自分の好みのキーワードを移動させると、違う情報が表示される。更に履歴情報も使えると面白いと思うが、そこまで手は入っていないとのこと。

技術のお話

どうやってこの仕組みは動いているのか? NTT 単独では出来なくって、放送局側の協力も得ている。

まず、TV が視聴中の番組を NTT のサーバーに通知する。サーバーは放送局にアクセスして、放送中の番号のキーワードを取得する (そういう仕組みを放送局側にセットする必要があるわけね: 今回は NHK が協力)。サーバーはキーワード情報をタブレットに送信。タブレットは受け取った情報を基に画面を描画。ユーザーがキーワードを移動させると、タブレットはサーバーに変化を通知して新しいキーワードをもらう。

うん? すると、家の TV とタブレットの関連付けもどこかでやっているんだな。その説明はなかった。

さて、タブレット用アプリの話もしよう。InfoSkin は HTML5 で書かれている。写真の上を見ると分かると思うけれど、アドレス・バーがあって URL が表示されている。そう、このアプリはウェブ・ブラウザー上で動いている。HTML5 のうち使っているのは、Push 通信に WebSocket、デザインに CSS3、画面描画に Canvas と SVG。このデモでは、HTML5 を使ってネイティブ・アプリと見間違う程の UI を作ることが出来ることも見せている。Android/iOS/Windows といった OS に依存しない点を強調していた。

あとがき

NTT 研究所は固い研究開発ばかりやって、ユーザーがすぐに使えるような物を出してこない。そんなイメージがあった。

今回のデモで自分の認識の甘さを知った。HTML5 でウェブ・アプリが作れることは、ウェブに特化したサービスが大きく進めていることではあるけれども、NTT もその有用性をちゃんと認識している。そしてデモで魅力的なアプリを発表するレベルにまで達している。とても喜ばしい。そして出来上がった InfoSkin という UI は、使い方が分かり易く、見た目もスマート。一本取られた気分。

TV からキーワード情報を飛ばすというアイデアも面白い。こういう放送局がからむ様なことは、NTT みたいに大きな会社が音頭を取らないと進みにくいものだから、是非頑張って実用化して欲しいもの。放送局から「データ」が配信される様になったらベンチャーが NTT のアイデア以上のアプリを出すかもしれない。というか、きっとそうなるでせう。だけど、それで良いと思う。そうやってインフラを整えて行けるのが NTT みたいに「大きな会社」の使命の一つだと思うから。

O'Reilly の HTML5 for Publishers が無料提供

O'Reilly から「出版向け」HTML5 の本が出た。題名は「HTML5 for Publishers」。電子出版での提供で、フォーマットは EPUB, PDF, MOBI(Kindle) の三種。価格は無料。

• HTML5 for Publishers - O'Reilly Media
• via. 無料で読める「HTML5 for Publishers」――米O’Reilly Mediaから - 電子書籍情報が満載! eBook USER

全四章。ぼくは EPUB 版を iPad でダウンロードして iBooks で読んでいる。ページ数はフォントの大きさで変わっちゃうから正確な値は出ないけれど、ぼくの iBooks では全 81 ページとなっている。それほど厚い本じゃない。目次は以下の通り。

1. Canvas for Publishers
2. Geolocation for Publishers
3. <audio>/<video> for Publishers
4. Embedding HTML5 in EPUB

本文は当然英語だけれども、HTML5 や出版に興味のある人は是非!

Firefox 4 の MathML 対応が素晴らしいことになってる

数式を HTML の中で使う試みとして MathML が挙げられる。MathML は XML アプリケーションの一つで、数学記号を含めて高度な数式表現を可能にする。数式エディターで描いた数式を画像化して貼り付けたりしなくて良くなるわけ。

期待度の高い MathML だけれども、ブラウザー側の対応が進んでいない。

その中にあって、Firefox 4 が一歩先じている。どれ位い数式が描けるのかを誇示するために、ウェブ・ページを作っているので覗いてみて欲しい。

• MathML in Action

Firefox 4.0.1 で上記ウェブページを開いた時のスクリーン・ショットをお見せする。

LaTeX には及ばないけれども、非常に高度な数式が描けているのが見て取れる。

一方、Google Chrome の開発版 (14.0.794.0 dev) でこのページを見るとどうなるか。

見事に壊滅的。MathML の「マ」の字もサポートしていない (;_;)。

他のウェブ・ブラウザー (IE, Safira, Opera) は試していないので、もし興味を持たれたら比べてみるのも一興かと。

あとがき

ぼくは TeX からプログラムの世界に入った様な人間なので、数式を美しく表現できるだけで嬉しくなってしまう。正直、MathML なんて数式表現がちょこっと上品になっただけだと侮っていた。今回、Firefox の完成度を見るに、認識を改めないといけないと痛感した。

Firefox に続いて、Webkit, Opera が一日も早く MathML 対応してくれることを望む。IE は... ごめん。期待していない。

HTML5 が Last Call になった

2011-05-25、W3C で作成されている HTML5 の仕様がついに「Last Call (最終草案)」となった。また HTML5 に関連する 5 つの仕様も Last Call となった。Last Call となった仕様は以下の通り:

• HTML5
• HTML+RDFa 1.1
• HTML Microdata
• HTML Canvas 2D Context
• Polyglot Markup: HTML-Compatible XHTML Documents
• HTML5: Techniques for providing useful text alternatives

情報源はこちら:

• Last Call: W3C Invites Broad Review of HTML5 and Five Related Specifications
• HTML5、W3C で Last Call （最終草案） へ | WWW WATCH
• HTML5がLast Callに | Web標準Blog | ミツエーリンクス

また、これに伴い「HTML5 differences from HTML4」も更新されている。これは羽田野さんの日本語訳版が既に出ている。

• W3C - 『HTML 5 differences from HTML 4』日本語訳 - HTML5.JP

今後の動き

W3C は「勧告」をもって仕様の決定とする。勧告までの流れは次の通り:

1. 草案 (Working Draft)
2. 最終草案 (Last Call Working Draft)
3. 勧告候補 (Candidate Recommendation)
4. 勧告案 (Proposed Recommendation)
5. 勧告 (Recommendation)

これからは最終草案のレビューに専念。上手くいけば勧告候補。ダメだったら草案にさし戻されるのかな?

あとがき

とりあえず、最終草案が出た。これから HTML5 の大きな変更はない... らしいんだけど、不穏な噂もチラホラ。少し不安は抱えつつも、HTML5 を使う側・実装する側としては良いニュースと喜んだらいいんでせう。