HTML6 でも CSS4 でもない Web 技術のゆくえ - WCAN 2015 Winter に登壇してきました
@kazumich さんにお声がけいただき、WCAN 2015 Winter でおよそ 60 分ほどのセッションを登壇してきました。32:9 のスクリーンがあるという、TED でもやるんかオイという特殊な環境でした。普段はプロジェクター的な投影なので、スクリーンの前に立つのが微妙なんですが、ここはディスプレイが壁面に大量に並んでいて自ら発光するので、部屋を暗くしなくてもテレビのように十分に見えますし前に立っても平気です。 一緒に登壇したのが @yhassy さんと @Hidehisa さんということもあり、近年まれに見る胃痛を伴う緊張を味わいながらお話させていだきました。（リアルにセッション終了後、1時間くらい胃痛がズキズキしてました） 技術的なお話でした 参加されたみなさま、メインセッションや LT に登壇された各位、ならびに運営されたスタッフの方々、ひとまずお疲れさまでございました。貴
PhantomJSのリモートデバッギング的なアレ
Remote Debugging Remote debugging permits inspection of the script and web page via another WebKit-based browser (Safari and Chrome). Troubleshooting · ariya/phantomjs Wiki PhantomJSにおける地獄のconsoleデバッグよりも、場合によってはマシかもしれないリモートデバッグのメモ。 phantomjs --remote-debugger-port=9000 test.js --remote-debugger-port オプションで、ポート番号を指定するとリモートデバッガにアクセスできる。上記の例であれば、http://localhost:9000 で開ける。 手順 --remote-debugger-port:9
RAIL という Web パフォーマンスモデルの概要
RAIL を簡単に紹介する 主に Googler が、という趣ですが今年に入ってから RAIL というパフォーマンスモデルが紹介される機会が増えてきました。 RAIL は Response / Animation / Idle / Load の頭文字をとった命名で「アプリケーションのライフサイクルの観点から、それぞれのフェーズの基準時間（限界時間）を示したもの」です。 手前味噌ながら Webパフォーマンスにおけるイニシャライズとランタイム で紹介したうちの「ランタイム」部分が細分化されて、それぞれに基準時間を割り当てたようなイメージです。 Idle や Animation あたりの時間は紹介する人・タイミングによって多少ブレている印象ですが、大まかに以下のような感じです。 Response : 100ms 「UI が操作されたときユーザーにレスポンスするまでの応答時間は 100ms 以内」
Pixateでアプリのインタラクションモックアップが捗りそう
インタラクションのモックアップ ネイティブアプリを作っていて、いわゆるインタラクション・アニメーションの部分をモックアップできるツールの必要性を感じたので @hiloki さんに聞いたツールをいくつか試してみました。 The Next Generation of Mobile Interaction Design | Pixate Justinmind: Interactive wireframes for web and mobile Briefs 昔ながらに Flash を使うという選択肢もあった気はしますがせっかくなので、そういう用途に特化したツールを探したかった次第。（メンバーに Flash 使えるひとがいなかったという事情もある） Pixateがよかった The Next Generation of Mobile Interaction Design | Pixate 結果、一番
2014年のWebパフォーマンスふりかえり - 来年以降の期待etc
ひさびさにWebフロントエンドパフォーマンス系の話題をつらつらと書いてみます。例によってモバイル系開発者寄りの視点かもしれません。文中の参照リンク多め。 ファクタ まずはパフォーマンスに影響を与えるファクタについての所感。Webパフォーマンスにおけるイニシャライズとランタイム ::ハブろぐ で示した分類に基づきます。 イニシャライズ（いわゆるページロード） 4GやLTEが普及してもコンテンツの肥大化には追いついていない concat と CSS Sprites の呪いが解けない HTTP/2 の Streams and Multiplexing に期待 HTTP/2 の Server Push にも期待 画像周りだと <picture> 関連仕様も使いたい（srcsetだけならいける？） WebRTC とか WebSocket とかストリーミングとかは？ （やや疎い、てかイニシャライズじゃ
HTML5 Conference 2013 レンダリングパフォーマンスお話してきた！
HTML5 Conference 2013 で、僭越ながら1セッション担当させていただきました！やっっったら、奥行きの深い部屋で、後ろのほうの方にはスライド見えづらかったかもしれません。ごめんなさい。部屋の奥行きのわりに、スクリーン小さいという不遇がありました orz ということで、スライドのURL共有とか、イベントの感想とかです。 Rendering Performance 動画 Webフロントエンドのパフォーマンスは、今やページの初期表示を早くすることだけではありません。昨今のHTML/CSS/JavaScriptを駆使したWebコンテンツを、スムーズに動かすには、ブラウザのレンダリング(描画)処理について知る必要があります。このセッションでは、レンダリング上のよくあるボトルネックの見つけ方と対処を中心に、最適化Tipsをお届けします。 ちと粗いのですが、今回の参考URLリストです。
フロントエンドチューニングの箇条殴り書き
普段気をつけてるよリスト "モバイルで、WebViewとブラウザのコンパチで、特にセオリー化されていないデザインモジュールのなか、装飾画像もふんだんに使うぞ系サービス開発" の文脈における、パフォーマンス確保のため気をつけてるよリスト。 よく、パフォーマンス「向上」とか「確保」とか申しますが、メンテナンスコストなどと天秤にかけて、「必要十分」のラインを狙うのが重要だと思う次第。 画像リソース 画像リソースを揃えるときのセオリ。圧縮率とか最適化とか細かいチューニングはあれど、大雑把に下記を守る。そしてImage Optim（or 相当の処理）。 JPEGはプログレッシブで画質60くらい（オレ目安） PNGは差し支えない範囲で色数をきちんと削る 50px未満のサムネイルは@2.0xなリソースにしない 案外、Androidあわせの@1.5xや@1.0xでも大丈夫なことすらある GIFアニメを入れ
GPUアクセラレーションとposition: relativeによるレイヤー生成について
またアニメーション... ボタンなどのUIにGPUアクセラレーションが効いたアニメーションをつけたとき、iOSにおいてはiPhone4か4SのWebViewあたり、Androidにおいては….まぁ機種依存的(げんなり)に、アニメーションの立ち上がりが遅いことがあります。 その辺を調査していたところ、position: relativeの指定による、意図しないレイヤー生成＆GPUアクセラレーション巻き込みによって、何かしら合成レイヤー周りでオーバーヘッドが発生してしまっているんではないかな、という憶測に行き着いた次第。今回はその辺りを見ていきます。 GPUアクセラレーションが効いたアニメーションは、CSS Animations、CSS Transitionsのほか、特殊なプロパティ（transform3d: scale(1,1)とか）で強制的にGPUアクセラレーションを効かせたCanvasア
FlashからCreateJSに出力されたCanvasアニメーションをスマフォ用に組み込んだ断片メモ
CreateJSのコードを組み込んでみた 前提、ともかく現在の仕事においてアニメーションの導入という要件が出てきて、JavaScript書いてる者としてどのように解決しようかと相談した結果、下記の状況・前提からFlashのToolkit for CreateJSを利用することに決めた次第。 自分でアニメーションの動きを作ったことない アニメーターな方がFlasher 取り急ぎカッコ良く動いて欲しい が、今後を考えるとCSSでFlashの動きから書き起こすのダルい という理由から下記のソリューションを導入する方向になりました。（今の時点で本当にデプロイまで至れるかは、まだ手探りなので参考までに） CreateJS | A suite of Javascript libraries and tools designed for working with HTML5 Flash to HTML5
Backbone.js コメント付きソースコード日本語訳
Annotated Sourceのコメントを訳しました 地味に道のりが長い作業でしたが、何とか先々週末にやっつけて、例によって@cssradar氏に確認していただいたりとかして今に至りご紹介する次第。 日本語訳コメントがついたソースコード· enja-oss/Backbone · GitHub なんだかんだで全域を網羅する必要があったたので、非常に勉強になりました。ソースコード自体は短く簡潔なので、Backboneをこれから使い始める/もう使ってるを問わず、まだ読んでない方は一度読んでみると良いです。 監訳謝辞 Revert original text for supervise by ahomu · Pull Request #12 · enja-oss/Backbone 上記Pull Request＆監訳依頼につきまして、多大なるレビューをしてくださった@cssradar 氏に感謝を。
モバイルブラウザのキャッシュとデータストレージについて
表題の件について情報を漁った 現時点で裏取り検証をまったくしていないので、議論対象の参考程度でお願いします。 これから実際に手元のプロダクトで検証していく予定ですが、誤読や内容などの疑わしきはTwitterとかでマサカリ投げてください。 ここでは海外のイカしたgeekらが調べてくれた、貴重な情報を信じて話を進めて参ります。素直が一番って、ばーちゃんが言ってました。 Browser Cache キャッシュと言っても無限の領域ではなく、むしろ現実的に出回っているモバイルデバイスのリソースは、ごくごく有限です。その上でブラウザの振る舞いを理解できていないことを反省して、ちょっと調べてみた次第。 まずはブラウザキャッシュに依存したストラテジを支える、キャッシュコントロール + ユーザー操作に関するブラウザの基本的な振る舞いについて。 Early findings: Mobile browser c
jQueryについての所感
昨今jQueryについての所感とつきあい方を考える はじめはPHPとa-blog cmsがメインだったこのブログも、いつの間にかJavaScript（jQuery）とご飯レシピブログという謎な方向への珍走を遂げています。 そんな中、個人的にjQueryとのつきあい方について色々聞いたり思ったりで、だらだらとアウトプットしてみます。オチはつきませんでした。ﾀﾞﾗｧ...('A`) ってこれ、今年の3月に大半書いていて、なぜか8月も末の今頃に加筆修正かけたので色々アレなところあったらごめんなさい！！！もったいないから公開させてください、、てへぺろ(・ω<) なぜjQueryなのか jQuery周辺のノリ（何でもjQuery・コスト感なくjQuery・jQueryスニペット信仰）などに、正直ネガティブな感情抱くこともありますが、素直な気持ちで見ればjQueryはとても効率的だと思います。Web上
はじめてのjQueryMobile - WCAN 2011 Autumn フォロー記事
当日のスライド さる2011年9月10日に，WCAN 2011 Autumnのセッション2-Cで，jQuery Mobileについて紹介させていただきました．jQuery Mobileを都合良く取り回して，モバイルサイトに役立てようという主旨でございます． WCAN 2011 Autumn ~ はじめてのjQuery Mobile HTMLスライドですが，なるべくWebKit系のフルブラウザでご覧ください．（FirefoxやIEは閲覧を確認できておりませんので...） 当日の要点 当日は，下記のように各トピックにフォーカスをあてて，jQuery Mobileの光と闇（嘘）について紹介させていただきました． スマフォサイトを取り巻く背景 jQuery Mobile自身の特徴・メリット 実装のデモンストレーション jQueryMobileを活用している国内外の事例 使い所を選びつつも，モバイル
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
