フレクトのHeroku Lab

今作っているアプリでちょっとしたギミックをいれるのにCSS3のanimation-xxxxを使っているんですが、これがすこぶる便利です。(^^v

CSS3アニメについてはこちらのページが良くまとまっています。

http://ri-mode.com/rainbow/2013/06/10/css3_keyframes_transform/

ていうか僕はこのページ以外のリソースにはほとんど目を通してないんですが。。。(^^;;;

それでも、なんとなくエフェクトが作れちゃいます。

アニメーションの作成などまったくの門外漢で、やろうと思ったこともほとんどないんですが多分、

• 開始(0%)と終了(100%)の状態を定義して、
• 中間(n%)でどういう状態を経過するかを定義するだけ

という仕様がプログラマ脳と相性が良いんだと思います。

また対象要素を最初hiddenにしておけば、showした瞬間にアニメーションが始まるのもスクリプトとの相性が良くてGoodです。

さて、このCSS3アニメ、素のままでもそれなりに使えますが3つ4つと定義していくとやっぱりだんだん面倒になってくるので既存のコードを切り出してjQueryプラグイン化してしまいました。

http://shunjikonishi.github.io/jquery-animateDialog/

制作は全部で3時間くらい。GitHub IOのおかげでソースだけでなくホームページまでこんな短時間で準備できてしまうのは素晴らしすぎます！

使い方は多分、上記ページを見れば(僕の適当英語でも)わかると思います。

サンプルはテキストオンリーのシンプルな要素を使ってますが、もちろんイメージ等を駆使した凝った要素であってもアニメーションさせることができます。

自作のアニメーションを作るのもkeyframeを定義するだけなので、職人の手にかかればかなり凝ったものを作ることもできると思います。

いけてるアニメーションを作った方はプルリクくれればマージしますよ。(^^;

(適当英語の校正も歓迎です。)

ブラウザのJavaScriptはシングルスレッドで動いている。

そんなことは知っている。

いや、知ってはいてもちょいちょい忘れてていけてないコードを書いちゃうこともあるのだ。

JavaScriptでのWebSocketの使い方は以下のようなコードになる

var ws = new WebSocket("ws:...");
ws.onopen = function(e) { ...};
ws.onmessage = function(e) { ...};

このコードを見て「onopenをバインドするよりも前に接続が確立しちゃったらどうなるんだろう？」と疑問に思わないだろうか？

でも、実際にはそんなことは起こらない。何故ならWebSocketの接続が行われるのはコンストラクタを実行している関数の処理を抜けた後だから。

このことは以下のようなコードで検証できる。

function init() {
    console.log("Start init: " + new Date().getTime());
    var ws = new WebSocket("ws:...");
    ws.onopen = function(e) {
        console.log("WebSocket open: " + new Date().getTime());
    }
    for (var i=0; i<1000000; i++) {
        var dummy = new Date();
    }
    console.log("End init: " + new Date().getTime())
}

空ループを回さなければ20ms以下で接続が確立するが、このコードではループが終了するまで接続は行われないので数秒のタイムラグがある。

言い換えれば「End init」のログは常に「WebSocket open」よりも先に出力される。

(ただしFirefoxでFireBugを動かしていると途中で「スクリプトが応答していません。」のようなダイアログが表示されることがあり、その場合はそこに割り込んでWebSocketの接続が行われる。)

何が言いたいかと言うと、

function init() {
    var ws = new WebSocket("ws:...");
    //なんか重たい処理
    ws.send("hoge");
}

のようなコードは途中にどれだけ重たい処理があっても必ず失敗するのでちゃんとonopenを使おうという話でした。

先週のHTML5カンファレンスで@albatrosaryさんのセッションを聞いて自分がSessionStorageのスコープについて誤解していることに気が付いたのでちゃんと調べました。

SessionStorageのスコープってウィンドウ + ドメインなんですね。。。
半端知識でCookieと同じだろうと思ってたら全然違いました。。。(--

★誤解その１、同一ブラウザでもウィンドウ(あるいはタブ)が違うとスコープが異なる

同一ブラウザ上でタブを二つ開いて、両方で同じページを開いた場合それぞれのSessionStorageは別になり値は共有されません。

Cookieやサーバーサイドセッションでは同一ブラウザ、別ウィンドウは区別できないのでこれはSessionStorageだけが持つ大きな特徴と言えます。

★誤解その２、パスがちがってもドメインが同じであればスコープも同じ

ウィンドウが同じであれば「http://SERVERNAME/test1」と「http://SERVERNAME/test2」のSessionStorageは値を共有します。

Cookieの場合はPathでスコープを制限できますがSessionStorageにはそのような機能はないので同一ドメインであれば常に同じスコープになります。

ちなみにプロトコルが異なる場合(httpとhttps)は別スコープになります。

★疑問その１、別のサイトに移動して戻ってきた場合はどうなるの？

対象のページから全く無関係なページ(例えばyahoo.co.jp)に移動して、また同じページ(あるいは対象ページとドメインが同じな別ページ)に戻ってきても、SessionStorageの値はクリアされず維持されます。

要するにウィンドウを閉じない限りSessionStorageの値も残り続けるということです。

★疑問その２、モバイル端末がスリープした場合どうなるの？

ウィンドウを閉じさえしなければスリープしたりブラウザから別のアプリに移動した場合でも値は維持されます。

動作確認したのはAndroid 4.1.2(標準ブラウザ、Chrome)とiPad2です。

ちなみにモバイル以外はIE10 IE11, Chrome, Firefoxで動作確認しましたがすべて同じ動きになりました。

□□□□

なんというか思ったより都合の良い動作しているのでSinglePageAppを作る場合には割と使い勝手が良さそうです。(^^;

行ってきました。
予想以上に自分の興味分野とのマッチ度のかなり高いセミナーで非常に面白かったです。

会場は明星大学。つまり大学の教室での講演だったので机椅子完備なのはありがたかったです。
ていうか、そこで朝から7コマもセミナー聞いているのは完全に授業でしたね。(^^;

以下興味深かった内容のまとめです。

★AngularJSの魅力

AngularJS入門セッション
個人的に以前からAngularJSはイマイチ好きになれないなぁと思ってたんですが、このセッションを聞いてようやく理由がわかりました。

JavaScriptを1行も書かなくて動く各種機能が気持ち悪い

と、思っちゃうせいですね。(^^;
よくよく考えると単純なタブ切り替えの場合なんかでもBootstrap(スクリプト不要)よりもjQuery-UI($().tabの実行が必要)の方が好みです。

スクリプトを見て「ここでタブ切り替えやってるんだな」とわかる方が好ましいと思うんですよね。
スクリプトの場合ライブラリの細かい仕様を知らなくても、多分この辺でやってるんだろうなぁとある程度想像がつきますが、HTML内で完結されると知らないと絶対にわからないですからね。

自由度が高くないという特徴もこれに起因するものだと思っていて、HTML内に専用のタグを埋めるにしても最終的にはスクリプトでそれを制御する形の方が扱いやすいんじゃないかと思います。
まぁ、僕がJavaScript好きなせいかもしれませんが(^^;

YeomanとBower(JavaScriptのパッケージマネージャ的なもの)は最近急によく見かけるようになったキーワードだったので、さらっとでも紹介を聞けたのは良かったです。
近いうちに試します。

★HTML5セキュリティ入門

xhr2、WebSocket、WebStorageなどを使用する際に気をつけるべきセキュリティの話
これははっきり言って資料が完璧です。

http://www.slideshare.net/muneakinishimura/webhtml5-31749532

フロントエンド開発者は読んでおくべきと思います。

プロトコルによるoriginの付き方やブラウザの挙動の違いなど非常に実践的てためになる話でした。

★オフラインアプリケーション開発入門

SPA(Single Page Application)の話とその発展系としてのオフラインアプリケーションの話

http://www.slideshare.net/sagawafumio/ss-31750106

SPAについてはちょっともの申したいこともあるのでまたあとで。
オフラインアプリケーションについてはWebアプリでどの程度必要性があるんだろうという疑問がありますが、WebStorageは意外と応用範囲の広い技術かもしれないとは思いました。

例えばセールスマンの使うカタログアプリケーションで原則アイテムはネット上にあるけど、おすすめ商品だけは選択的にローカルに落としておくとか。

SPAならそれこそテンプレートを全部ローカルストレージに持たせるのもアリかと思います。

★「Selenium」を使った、開発・テストの効率化

Seleniumを使った自動テストの話
講師の伊藤さんとは懇親会でもかなりお話させていただきました。楽しかったです。
Selenium。そんなに使いこんでるわけではないけど、どうやら自分の知らない便利機能とかはあまりないっぽい。
もうちょっと面倒くさくなければ、嬉しいんだけどね。。。(--

今度作るアプリでは細かいテストをたくさん作るのではなく、長めのシナリオを少数作ってみようかなと思ったり。

★JavaエンタープライズアーキテクチャにおけるHTML5

Javaユーザーグループの鈴木さんよりSPA、適用できる部分もあるけどまだまだエンタープライズでの利用にはリスクもあるよ、という話。

http://www.slideshare.net/yusuke/javahtml5

何というかここまで割と空飛んでる感じの人が多かったのに最後にしっかりと地に足の着いた人がでてきて、そのギャップが面白かったです。

どうでも良いけど古いIEなどHTML5非互換のブラウザ対応の問題を指して「ただしイケメンに限る」問題と名付けたセンスが秀逸すぎます。(^^;
うん、それはどうしようもないわ。それはあきらめるしかないですね。(^^;

★番外 Vert.xの話

セミナーではありませんが、懇親会でVert.xの話が聞けたのも大きな収穫でした。
WebSocketをスケールさせるのであればVert.xが最強らしいです。

Vert.x。名前は時々見かけてたんですが、さらっと調べた感じ結構面白そうなフレームワークでもあるのでこれも近いうちに評価したいです。

家に帰ってから気が付きましたが、隣でSenchaの話をされてた方だったんですね。

http://www.slideshare.net/kotsutsumi/html5-31768731

そうと知っていればjQueryMobileとSenchaの比較をもっと聞いてみたかった。。。(--

★SPAの話

さて、今回大きなテーマのひとつだったSPA。
「エンタープライズ」という枕がついていたせいか思った以上に経験者が少なかった印象です。

SPAという単語自体がでてきたのは極最近だと思いますが、エンタープライズはともかくサービス提供者は多かれ少なかれSingle Page ArchitectureでWebアプリを作っていると思います。

(余談ですがSPAのAは、個人的にはApplicationよりもArchitectureと言った方がしっくり来ます。「Application」と言うとすべての機能がひとつのページで実現されなければならない印象ですが、別にそんなことはなくて複数の機能が画面遷移なしで実現されていればそれはSPAと言っても良いと思うのです。。。)

僕自身は最初にSPAモデルでアプリを作ったのは3年以上前ですし、それ以降自分でWebアプリを作る場合は常にSPAモデルを採用します。

1年くらい前には「お手軽Ajaxアプリケーションの作り方」というスライドも書きました。(今見ると直したいところがいっぱいありますけど。。。)

http://www.slideshare.net/shunjikonishi/ajax-app-20725783

個人的にはある程度JavaScriptが書ける開発者であれば通常の画面遷移があるアプリケーションを作るよりもSPAモデルで作った方が絶対に簡単だろうと思います。

だって画面遷移したら毎回ステート切れて必要な情報は都度サーバから取ってこなきゃならないじゃないですか。慣れてるからそれが普通に思えるのかもしれませんが、本来それはとても面倒なことです。

単純な例で

• フォームで情報を入力
• 確認画面表示(間違いがあれば入力画面に戻る)
• 登録

という画面を画面遷移モデルとSPAモデルで実装することを考えてみてください。
やったことなくてもSPAモデルの方が簡単そうに思えるんじゃないですかね？(これをSPAというかどうかはさておき)

このように本質的にはSPAモデルの方がアプリ開発は簡単になると思っているんですが、現状SPA特有の難しさがあることも事実で複数人で開発する案件に適用してもあまりうまく行くような気がしません。

これは何でだろうということをこの週末ずっと考えていたんですが、とりあえず

JavaScriptのコードを局所化することが難しいため

という結論に達しました。
グローバル変数は悪、というのは広く浸透した知識だと思いますがHTML内のidやclassは全部グローバル変数みたいなもんですからね。この課題をどうにかしないといずれは複雑さが理解の限界を超えて破綻するように思えるのです。

ていうかこれ破綻したときのダメージが再起不能レベルのような。。。(--

AngularやBackboneなどのフレームワークを使うのも有効な手段だとは思いますが、課題の存在に気づかず漠然と使っているだけだといずれは同じ結末を迎えるように思えます。

対処法はいくつかあるとは思うんですが、それらは整理できたらまたおいおい書きたいと思います。

とりあえず先週書いたこれも有効な対策の一つではあるかと思います。(^^;

良質なコードを高速に書くコツ
http://www.slideshare.net/shunjikonishi/ss-31700673

SPAを意識して書いたものではないですが、こういうJavaScriptの書き方に慣れておかないと多分SPAはつらいです。(^^;