ドコモゼミWebアプリラボ 結果発表

先月からちょこちょこアナウンスしていました、ドコミゼミ Webアプリラボ のWebアプリコンテンストの結果発表があり、ノミネートされたということで行ってきました。


結果は、、、、、

こちら! → http://d-webapp.jp/tb/index.html


最優秀賞は「インド式かけ算」!!
優秀賞には「The 雑草」が選ばれました。

我らが「かきまる」は佳作を頂きました。評価くださった皆様ありがとうございます。

開発者の皆さんは本当に真剣に作られていて、色々な想いが伝わってきました。

開発者のエピソード

最優秀賞のインド式を開発したのは、高校で数学を教えていたという元数学教師の60歳オーバーの方!デザイナの方とネット上でやりとりしながら作ったそうです。教師の経験を活かし子供でも分かりやすいように工夫した、計算方法を独自で編み出したと思ったらインド式だったw、などネタ満載でした。

優秀賞を受賞された「The 雑草」の開発者は、小さいお子さんがいらっしゃる女性でした。ご自身のお子さんもスマホを使うそうなのですが、スマホだけを触るのでは無く、外へ出て自然と一緒に遊んで欲しい、という想いで作られたそうです。母親の子を思う真摯な気持ちで作られたエピソードに感涙です。

審査発表会の後、懇親会で色々な方とお話しして大変刺激を受けました。皆さんの真摯な気持ちを見て、私たちに一番足りなかったのは真剣さだと痛感させられました。それでも佳作という賞を頂き、大変恐縮です。もちろん、不真面目に取り組んでいたわけでは無いですよ。それなりに真面目にやっていました。しかし他の皆さんの真摯さを見るとお恥ずかしい限りです。。

コンセプトが途中でずれていた。

反省点は諸々ありますが、一言で表すならばコンセプトが途中でずれてしまっていた、ということに尽きると思います。作っているうちに、モバイルWebのインターフェースを実験するような形になり、本来目指すべき子供と家族が一緒に楽しむ、というコンセプトが薄くなってしまいました。

そのため、何をするアプリなのか伝えることが弱くなり、スマホに絵を描くアプリだと思われてしまうことも。また、動物の名前もちょっと捻りすぎて子供には難しく、子供の興味を十分に引きつけられなかったこともあります。ネタの被せもちょっとやり過ぎたかな、と。。。

スマホだけに閉じたアプリではない、という狙いは良かったかと思うのですが、その魅力を十分に引き出せなかったのが残念です。

当たり前だけど一番重要なこと

面白いインターフェースや見た目のデザインも重要ですが、一番大事なことは、真剣に使う人の立場で考える、ということ。当たり前のことだけど、常にそのことを意識するのは案外難しい。つい誤魔化しそうになります。仕事ではもちろんそれを最優先に考えますが、特に今回ようなコンテストだと動きの方に注力しがちになります。そのあたりのことを審査員の方々はしっかりと見極めていたのだと感じました。

こういう企画に参加させていただき、大変勉強になりました。賞まで頂くことができ、本当にありがとうござました!!

f:id:dsuke:20130725183813j:plain

jQuery Mobile & Sencha Touch ハンズオンやりました

昨日、こちらのハンズオンイベントで講師させて頂きました。

AITC第2回勉強会「jQuery MobileとSencha TouchでWebアプリを作ってみよう!」~ 2大スマホ向けWebアプリフレームワークを使いながら比較 ~

猛暑の中、30名近い参加者にお越し頂き、ありがとうございました。

IT関連ではない会社や、マーケティング部などの非エンジニアの方々や、遠方よりこのために参加頂いた方々、学生さんなどなど、多種多様な方に参加頂きました。

資料のまとめは前回のエントリで。
jQuery Mobile & Sencha Touch ハンズオン資料まとめ

ある程度予想はしていましたが、やはり環境構築が鬼門でした。今回、node.js+express や、ruby + compass など非エンジニアの方には馴染みが無いツールを使う演習のため、本質的では無いところで時間がかかってしまったのがやや残念です。

とりあえず勉強会として、良かった点、改善すべき点などをまとめてみます。

良かった点

jQuery Mobile と Sencha Touch を同時に扱うというテーマはなかなか面白かった

同時に見比べられるので、非常に違いが分かりやすいと好評を得ました。1回で両方できるお得感はあったので申し込んだ、欲張りすぎるww などの声も頂きました。

実は、当初は3つにするとか、もっとオープンデータを使うだとか、かなり要望は膨らんでいましたw
なんとかコンパクトにして、あのボリュームでした^^;

どちらも一通りの流れを、順を追ってできた

段々機能を追加していき、完成度を高めていくようなサンプルが良かった、という声も。
当初は完成形だけ用意して、部分コピペで進めていこうかと思ったのですが、初心者が多そうだという事前情報から、前日に段階的にできるサンプルに作り替えました。進める側からも、これはやっておいて良かった。あの状況だと部分コピペで進めるのはかなり厳しかったでしょう。。。

コピペでもとりあえず手元で動かせた

なんとか全員環境を構築できたので、手元で動かせる環境が作れて良かったです。
とりあえずは演習資料をそのままコピーでも、動かせる環境が手に入った、というの大きかったのでは、と思います。これできたので、あとはサンプルをちょこちょこいじりながら自分で勉強することもできます。あと、エディタも今回初めて Sublime Text を使ってみたけど良かった、という方も。

反省・見直しが必要な点

環境構築はアナウンスとかやりかたをもっと考える必要あり

今回演習の中でそれぞれ環境準備を20〜30分ほど予定を入れていたのですが、全然足りませんでした。演習の中に、特に最初に入れてしまうと、全体の進行が止まってしまうため、あまりうまい方法ではなかったですね。

インストールできてない方は早めにきてセットアップしてもらうとか、出来ている人は演習を進められるような流れにすれば良かった、という反省があります。そうすれば、進められる人は自分でコードをカスタマイズしたりして理解をもっと深められたかなぁ、とも思いました。

また、事前インストールの件があまり告知しきれてなかった問題もあります。イベント告知や申込が色々と分散されたのも情報共有漏れが起きる原因の一端ですね。この辺りは運営側の事前準備不足でご迷惑をおかけしました。

全体的にやはり詰め込みすぎ

環境構築もさることながら、演習内容もかなり詰め込み過ぎた感はあります。特に後半は早すぎて理解が追いつかない、とか自分でコードを書く暇が無かった、ということに。もっと自由にコードを書いてもらう時間を作りたかったですね。。

2つ同時にやるというテーマ自体は評価されたのですが、ハンズオンとするとどこまで踏み込むか悩ましいところです。コピーしてなんとなく動いた、というだけじゃ面白くないですし、どこまで解説するか難しい。

Sencha Touchが難しい印象を与えてしまったかも。。

みんなに言われたのが、Sencha Touchが難しすぎる、と^^;;
これは私の伝え方が良くなかったです。すみません。。言い訳するとちょっと時間がなさ過ぎた。。。ま、参加者の半数くらいは聞いたことない、というので仕方ないところも。しかし、JavaScriptに馴染みが無い人に言われるのは仕方ないですが、JS書く人にも言われたのはややショック。Sencha Touchを簡単に教える方法教えてください・・・・

その他

・アンケート出し忘れた。。 参加者の方には後日Webアンケートの案内をお送りします。
・後半、自分がだいぶ息切れして、ちょっとテンション落ちてしまってた^^;
・教室の温度がちょっと暑かったかな

総評

反省すべき点も多々ありますが、一応予定していた内容を全て時間内に終わらせ、参加者の皆さんにも開発環境とコードというお土産を渡せることができたので、まずは良かったんじゃないでしょうか。
私自身も大変勉強になりました。
参加者の皆様、スタッフの皆様、長時間お付き合いいただき、ありがとうございました!お疲れ様でした!

このカリキュラムをもうちょっと改善して、またリベンジしたいですね!w

jQuery Mobile & Sencha Touch ハンズオン資料まとめ

いよいよ明日に迫ったAITC第2回勉強会「jQuery MobileとSencha TouchでWebアプリを作ってみよう!」

半日でどっちも触ってアプリ作るという無謀な企画です。なんとか資料作成間に合いました。
とりあえず Slideshare に上げたのですが、バラバラとなってしまったので、こちらでまとめます。


最初の資料


まずは jQuery Mobile概要から


jQuery Mobileのハンズオン資料

続いて、Sencha Touch概要


Sencha Touchハンズオン資料


まとめ


なお、サンプルコードはこちら。Sencha Touch を含んでいるためGPLとなってます。


全部合わせると、総ページ数 91枚とかなってた。。
どおりで終わらないわけだw

しかし、これどこまでできるのだろうか。。。
戦々恐々です。

AITC第2回勉強会「jQuery MobileとSencha TouchでWebアプリを作ってみよう!」のご案内

そういえば、告知が遅くなりましたが、来週末の土曜日 7月13日(土)に、下記ハンズオンで講師を務めさせて頂きます。

AITC第2回勉強会「jQuery MobileとSencha TouchでWebアプリを作ってみよう!」

概要
 実際にコードを書きながら、スマホWebアプリを作るハンズオン形式の勉強会です。2部構成で、前半はjQuery Mobile、後半はSencha Touchを使用します。同じテーマのアプリを異なるフレームワークを使うことで相互理解を深めます。

お申し込みは Facebookイベントページより。

AITC会員企業外の方は有料になります。
事前登録をすると、いまなら早割が利用できてお得です!
今週末までなので是非お早めにどうぞ〜

内容は、jQuery Mobile と Sencha Touch で同じアプリを作って、それぞれの作りの違いを実感しよう!という感じです。お題は、気象庁防災XML を使った、防災速報なようなものを予定しています。

ただ、スケジュールを見てもらうと分かるのですが、各2時間くらいしか時間が取れません。。。2時間でこの巨大なフレームワークを一通りやるのは相当にハードです。なので、細かい説明よりも、とにかく手を動かして実際に動くものを作ってみる、という感じなるかと思います。写経になるかもしれませんが^^;

細かい質問は懇親会、または @dsuket へでも。
作ったサンプルアプリはまた後ほど公開したいと思います。

是非 参加お待ちしております〜。

HTML5機能を色々使ったスマホ向けWebアプリを作ってみた話:後編

前回のエントリでもお知らせしたように、ドコモゼミ Webアプリラボのコンテストにアプリを出しました!面白かったら下記ページの いいねをお願いします!

かきまる

スマートフォンを使いながらも、アナログな感触をもっと楽しんで欲しい。そういう想いで考えられた、デジタルとアナログを繋ぐお絵かきWebアプリです。

.

で、今回のエントリでは 前回のHTML5機能を色々使ったスマホ向けWebアプリを作ってみた話:前編 で書き切れなかった残りを解説します。

今回は次のトピックス

  • かわいい文字で表示したい。
  • 音があると楽しい。
  • スマホとタブレット両方対応。AndroidでもiPhoneでも。

Webフォントでオリジナルフォントを使う

Androidがいけてないの一つが、フォントにあると思っています。標準フォントや入っているフォントやが機種によりバラバラ。しかも標準フォントがダサイのが多い。あまりに違うためデザイン的なページの場合、テキストで統一的に表現するのは難しく、画像にしないといけなくなります。

画像にすると色々問題があります。まず変更がめんどくさい。文言ちょっと変更する度に画像を書き出さないといけない。さらに、昨今の高精細ディスプレイ用に2種類の解像度の画像が必要。そしてモバイルの場合特に重要なのが、ページサイズが増えること。画像が多くなると必然的にページサイズが増え、3G回線などでのモバイルではロード時間が遅くなってしまいます。

じゃあ、どうすればいいのか。そういう時に、Webフォント が使えます。Webフォントとは CSS3 から導入された仕様で、これまではOSにインストール済みのフォントしか使えなかったのが、必要に応じてWeb上からフォントデータをダウンロードして表示できます。これを使用すると、機種毎にバラバラなAndroidでも、iOSでも、PCブラウザでも同じフォントで表現できるようになります。

ただ、日本語フォントのように膨大な数があるとフォントデータが増え、画像データよりむしろ重くなることがあるので注意が必要です。必要な文字だけのフォントデータのする、などの工夫が必要です。今回のかきまるでは、ひらがなのみなのでサイズは woff 形式で11kに収まりました。この程度なら、画像を複数枚用意するよりも少ないサイズでいけます。また、フォントデータをキャッシュさせれば、別の文字が増えたとしても新たなダウンロード時間は増えません。

前回のひらがなの書き順を表現するため、文字データをSVGで作っていたので、それを元にWebフォントにしました。Webフォントに使える形式は幾つあります。最近だと WOFF が標準ですが、古い形式のために ttf や svg形式のものも用意し、CSS記述でフォールバックするようにしておくとベターです。

SVGからWebフォントの作り方はこちらを参考にしました → アウトラインのSVGからフォントを生成 #かな書いてみるFontForge の出力形式に woff、svgなどを追加すると、自動でその形式で出力してくれます。

ちょっとはまったのが、フォントデータにするときはアウトラインデータの方が良い、ということです。まぁ、当然なのですが。。。アウトラインから変換することを前提としているので、stroke の lincap や linejoin などは無視されます。今回の文字データは、書き順アニメーションのために1本のパス(stroke)で書かれていたのですが、そのまま変換するとうまくいきませんでした。そこで、フォント用に別途アウトラインデータも作成しました。

音を再生する

photo by vancouverfilmschool (CC BY 2.0)

Webで音を再生するには二つの方法があります。簡単なのが HTML Audio要素を使うこと。スクリプトからも操作でき、簡単な音声の制御ができます。もう一つが Web Audio API を使用すること。こちらはもっと複雑なことが可能で、合成やフィルタリングなどを使用してWeb上でシンセサイザーのようなことも実現できます。

ただし、Web Audio API はモバイル端末ではまだまだサポートが厳しい現状です。iOS 6から一部制限付きで使えるようになりましたが、Androidでは全然だめ。ということで、スマホ向けWebアプリは 今のところ HTML Audio要素一択という状況です。

HTML Audio要素ならスマホでも盤石か、と言うとそういうわけでもありません。スマホの限られたリソース(CPUや帯域)では、音声データのダウンロードやデコードで少し時間がかかる場合があります。そこで予めデータをプリロードしておきたいところですが、これも色々と制限されています。詳しくは 過去エントリ iOS/Android で HTML5 の audio/video を任意のタイミングで再生する方法 でも書いたのですが、audio を play する前に、load しておくことで対応できます。

「かきまる」では、当初 最初のページにタッチしたタイミングで全音声データをロードしていたのですが、それだと重すぎて最初のページめくりが固まってしまいました。そこで、各ひらがの書き順ページへ遷移するタッチイベントをトリガーに、次の動物の名前の音声データをロードするようにしました。書き順を表示している裏でダウンロードされるため、次の動物にいったときには、すぐに再生されます。

この方法の欠点として、書き順を表示しきる前に次々にページをめくると音声再生が追いつかない、という問題がありますが、これはもう致し方なしとして諦めました。また、Android Chrome の ver 25 くらいまではこの方法でうまくいっていたのですが、最新版の 27にすると事前 load が効かず、play時にのみロードされるようになってしまいました。

他にも、Galaxy Nexus(Android 4.2.2)の標準ブラウザと Chrome を組み合わせると、ブラウザ終了時やスリープ時に最後に再生した音声が勝手に再生される、というとんでもないバグがあったりします。しかも通知でも再生されるため、メール着信などある度に ”おおありくい〜” とか勝手着信音となってしまったり(ーー;; 他の端末では起きなかったため、対処は見送り。。

スマホ/タブレット/Retina対応。Androidでも。

一通り動くようになってから、最後に スマホ(縦横)と、タブレット(縦横)でもちゃんと見えるよう、CSS メディアクエリを使って調整しました。Android でもきちんと表示されるよう対応させるのに苦労しました。

SVGを画像として使う。

画像をスマホ/タブレット用に最適化すると、それぞれのRetina用も考えると、スマホ or タブ x 2解像度 = 4パターン必要になります。さらにそれの縦横まで対応すると、1つの画像に8パターンも必要になってしまいます。(実際には縦横は同じ画像を縮小で表示することが多いでしょうが)

今回は画像に SVGを使ったため、1パターンさえあればよいので非常に楽でした。Android 2.x は SVGに対応していないのですが、ここはもうばっさり切りました。Android 4以上なら問題なし!と言いたいところですが、まだ落とし穴があります。

SVGをWebページに埋め込みで使う場合、幾つか方法があります。

  • OBJECTタグで使う
  • IMGタグで使う
  • インラインSVGにする

古いブラウザなどの場合、IMGに使えなかったりするので、OBJECTタグを使用する必要がありますが、スマホの標準ブラウザ(Chrome)ならIMGで問題ありません。OBJECTタグにする問題点は、外部ドキュメントになるため、UIイベントがそちらに取られてしまうことがあります。また、インラインSVGにすると元ページにSVG要素を埋め込まないといけないため、画像の差し替えが煩雑です。なので、単に画像として使う場合は IMG要素として使うのがオススメです。(この節のSVGと書いてある画像も実はIMGタグでsvgを指定しています)

IMGタグでSVGを使う場合、画像サイズの指定はIMGタグで行います。width/heightの属性か、CSSの属性で指定できます。通常、widthとheightを指定すると、元画像のアスペクト比を保持したままスケールします。しかし、一部のAndroid標準ブラウザでは、アスペクト比が保持されず引きのばされてしまいます。iOS と Android標準ブラウザの表示違いは下の図のようになります。

Android標準ブラウザ

そこで svg ファイルの viewBox を見直しました。svgタグには、どの範囲を表示するか指定する viewBox という属性があります。このviewBox のアスペクト比と実際に表示させる画像のアスペクト比を一致させることで、この問題に対応することができます。

アイコン

一部のアイコンにも、SVGフォントを使いました。IcoMoon などを使えば簡単に導入できて便利です。ただし、Androidでは要注意です。

通常、Webフォントをアイコンに使う場合、特定の文字コードをアイコンに割り当てます。Unicodeでは、外字エリアとして私用領域という名称で U+E000〜U+F8FF、U+000F0000〜U+000FFFFDなどが割り当てられているので、これを使うことが多い。前述の IcoMoon はこの外字エリアを使っていて、U+E001 から埋めていきます。

ところが、一部Andoroid(Softbank端末など)は、この外字エリアに独自のアイコンを定義してたりします。→ 携帯電話の絵文字

U+E001 は ソフトバンクの絵文字ともろに被っています。今回は時間が無かった & ドコモ向けなので、残念ながら対応は見送りましたが、IcoMoon などを使う場合、コードには十分気をつけてください。

メディアクエリ

SVG画像のスケールは上記の対応で可能になりました。次は、メディアクエリを使い、幅に応じて画像や文字の大きさを変更します。メディアクエリで端末サイズを判定するには主に二つの方法があります。

  1. min-width, max-width で判定する。
  2. min-device-width, max-device-width で判定する。

1つ目の方法は、windowの幅で判定するのに対して、2つめは、端末の幅で判定します。PCブラウザから見るとどちらも同じように動きますが、スマートデバイスでみると大きく異なります。特に回転した場合に違いが出ます。デバイスの向きを横に回転したとき、1の方法で横幅の変更を検知し、レイアウトを変更できます。しかし、2つめの方法では端末自体の幅は固定のため、回転しても変更されません。そのため、向きを判定するためには orientation:portrait / orientation:landscape を組み合わせて使用します。 なお、この orientation は厳密には向きを見ているのでは無く、縦長か横長なのかを見ているだけです。なので、PCブラウザで縦長/横長を変更しても反映されます。

どっちの判定を使えば良いか、というと前者をオススメします。というのも、これまた一部のAndroid標準ブラウザでは、device-width を正しく認識しません。例えば、Galaxy Nexus, S2, S3 なんかでは、window.innerWidth は 360px なのに、メディアクエリの device-width は 320px として認識されます。細かい調整をする場合、正しく認識されないのは致命的です。また、device-widthを使用する場合は orientation も同時に指定しないと意味が無いため、記述も長くなり、お勧めしません。

まとめ

Webアプリでも表現が幅がだいぶ広がってきました。今後、WebRTC や WebGLとか使えるようになったらもっと凄いものができるようになると思います。まだ Android Chromeでもデフォルトはオフ、Safariは全然うごかない(今日発表の iOS7 で対応がでるかも!?)

現状では「かきまる」のようなシンプルなものでも、意外と苦労しています。スマホ向けWebアプリで、なめらかなUIや、複数端末への対応は骨が折れます。特にAndroidは本当にツライのでGoogleさんマジでなんとかしてください(切実

HTML5機能を色々使ったスマホ向けWebアプリを作ってみた話:前編

昨日、ドコモがやっているWebアプリコンテストのノミネート作品が一般公開されました。

私も、デザイナさんと協同して作品を一つ出しました!面白かったら下記ページの いいねをお願いします!

かきまる

スマートフォンを使いながらも、アナログな感触をもっと楽しんで欲しい。そういう想いで考えられた、デジタルとアナログを繋ぐお絵かきWebアプリです。

.

子供達が家の中でスマホだけをいじって遊ぶのでは無く、実際のリアルな紙と色鉛筆で本物の感触で遊んで欲しい。そのきっかけをスマホアプリで与えられないか?というモチベーションで作られました。そのあたりのコンセプトはデザイナさんのアイディア。私は主にその実装担当です。

そういう狙いはあるのですが、簡単に言ってしまえば紙芝居形式で動物の絵を表示して、それをお手本に絵を描く、という至ってシンプルなアプリです。

何も考えずに作れば、複数のWebページを遷移する単なるWebサイトとしても実現できます。しかし、それじゃあつまらないので、今回はそこに色々と実験的な要素を盛り込みました。

  • ページめくりをかわいくしたい。
  • ゲーム的な要素もちょっとあると面白い
  • ひらがなの書き順も同時に教えられたら。
  • かわいい文字で表示したい。
  • 音があると楽しい
  • スマホとタブレット両方対応。AndroidでもiPhoneでも。

これらの要望を HTML5 Webアプリとしてどうやって実現するか、が私の課題でした。今回のエントリーではその実装について簡単に解説します。要望があれば連載で詳しい内容も続けていければと思います。

カードをめくるように表現する

スワイプで次のスライドが表示されるようなアプリは良くあります。Webでもそういう表現が増えてきました。多用されているためやや食傷気味で、そのまま使うのは面白くない。ただ、スワイプジェスチャーでページをめくるという認識は一般にもだいぶ浸透しています。そこで、そのジェスチャーはそのままに、表現をすこし工夫しました。ページをカードに見立て、カードをめくるように次々と下のカードが出てくるような表現にしてみました。

スライドのライブラリは沢山あるのですが、カードのような表現ができるライブラリが見つからなかったため、一から自作しました。タッチイベントのドラッグを処理するには、jQuery プラグインの Hammer.js が便利です。それに CSS Animation を組み合わせて実現しています。

使ってみると、予想以上にカードページングはスマホと相性が良い気がします。後から気がついたのですが、スマホ用 Google Chrome のタブなどもカードアニメーションしていますね。このカードページングは jQuery プラグインとして作成したので、整理できたら公開してみたいと思います。

スロットゲーム

動物をしりとり形式で繋げよう、というアイディアは当初からあったのですが、最初の動物(文字)をどうやって決めようか、と悩みました。ここにゲーム要素を持ってくることにしました。ひらがながスロットのように表示され、タップすると少し遅れて止まります。このスロットもライブラリとして作成したので、公開できればしたいと思っています。スロットの向き、速さ、止まるタイミングなどを色々検討するため、各種設定値で変更できるようにも作りました。

このスロットの中身の文字は、実は普通のテキストです。当初、画像にしていたのですが後述のWebFontを使うことで、文字だけで表現することができました。

また、スロットのタップイベントにも一工夫が必要でした。実際に子供達に使ってもらうと、タップが反応しない、という問題が起きました。スロットを止めるという動作の特性上、狙って押すと結構力が入ってしまうんですね。そうすると、タッチがぶれるんです。ぶれると、タップイベントではなく、ドラッグイベントとして認識してしまうというのが原因でした。これは、以前 @IT にも書いた記事 タッチUXを実現する7つのポイント で、自分も指摘していました。自分で書いてるのに考慮漏れとは情けない。。。

このタップの問題も、前述の Hammer を使うと各種閾値を調整すれば解決できます。ついでに、アイコンやボタンなどについてももう一度当たり判定エリアや閾値を見直し、子供でもタップしやすいように調整しました。

ひらがなの書き順を表示する

ひらがなの書き順をアニメーションで表現するのには、少し悩みました。一番実装が簡単なのは、各コマを用意してcanvasにパラパラアニメのように順次描いていく方法です。しかし、それでは文字が増えたときに大変です。そこで次に考えたのが、SVGのモーフィングを使うことです。Raphaël を使えば、割と簡単に実現できます。しかし結果からいうと、これはうまくいきませんでした。モーフィングの補完をちゃんと指定すればいいのですが、全文字でこれを何コマか設定するのはとてもやってられません。

そこで、ひらがなをグリフではなく、単1のパスの組み合わせとして作ることにしました。それをSVGのパスで表現し、書き順でパス要素を上から並べます。「あ」ならば、1つめの要素が横1本のパス、2つめの要素が縦1本のパス、3つの目の要素が、ぐるっとまわるパス、というような感じです。先ほどの Raphaël を使えば、長さを指定して、パスのサブパスを取得することができます。これを使用して、各パスのサブパスを段々伸ばしながら描画しています。

この文字データを作る際に、どうせならあ段だけじゃなくてひらがな全文字作ろう!といってデザイナさんが頑張って作ってくれました!当初50文字だけかと思ってたら、濁音とか半濁音とか、小さいかなとか意外とあって大変そうでした^^; ここでかなデータをSVGで全部作ったので、これを元に SVG Fontをつくり、後編の WebFontへと繋がります。



簡単に説明するつもりが、予定以上に長くなってしまいました。
ということで、続きは後編で!

→ 後編書きました! HTML5機能を色々使ったスマホ向けWebアプリを作ってみた話:後編

Safari/Mobile Safari(iOS) にクロージャを使った計算で桁溢れするバグ

前回のエントリ JavaScriptのfor/forEach/jQuery.each/Ext.each のパフォーマンスを計ってみた。の検証中に発見したバグの話し。

Safari 6.0.4 (8536.29.13) 及び、Mobile Safari(iOS 6.1.4)では、クロージャを使った計算では、桁溢れする可能性があります。前回検証に使ったスクリプト http://jsfiddle.net/dsuket/DR33Q/ の、nativeForEach 関数などがその対象です。

    var nativeForEach = function() {
        var sum = 0;
        list.forEach(function(item){
            sum += item;
        });
        return sum;
    }

上記スクリプトをループ回数 1,000,000回以上にした場合、桁あふれが起きて計算結果が正しくでません。

WebKitのバグレポートにもありました。
Bug 104967 - Summary: javascript integer overflow

どうやらJITコンパイラの最適化のバグのようです。JavaScriptの仕様的には Number は IEEE754標準の64ビット浮動小数点数形式で、表現可能な最大値は±1.7976931348623157×10308 です。しかし、パフォーマンスアップのため小さい数の場合はJITが int32として計算するようです。大きくなるとint64となるはずなのですが、クロージャを使った場合うまくいかないという問題です。そのため32bitの範囲(+2147483647〜-2147483647)を超えると桁溢れを起こします。

なお、ChromeFireFoxではもちろん期待通り動作します。SafariでもWebインスペクタを開いていると、この現象は起きない(ちゃんと計算できている)ためデバッグ中は気がつきにくい。。。

上記のバグレポートでは半年も前に RESOLVED FIXED になっているのですが、まだ Safari/Mobile Safariには反映されていません。普段 Safari をメインに使うことはあまりありませんが、iOSの場合は注意が必要ですね。

実はこのような話は昔からあるようです。