既に多くの方が JavaScript のオブジェクト指向的側面についての解説を記事にされていますが、読み手側から見ると、例えばプログラミング言語への習熟度やオブジェクト指向自体に対する理解度がマチマチなわけで、私自身、「おお、なるほど！」 っていう、頭の中のスイッチがパチンッ！と入るような境地には達していませんでした。 かつて私も オブジェクト指向なJavaScriptプログラミングのススメ なんていう翻訳記事を書いてはいるのですが、正直なところ prototype.constructor の存在は知りませんでしたし、Function.call や Function.apply をどう使えばよいのかなどをちゃんと理解できてはいませんでした。 そんな中、2011年12月に書かれた Doc Center | Mozilla Developer Network の記事 オブジェクト指向 Java

前回、GitHub Pages 活用の概要を書きましたが、実際に運用していくと、master と gh-pages をどう使い分けるか、また両者の同期をどう行うかなど、いくつかの課題が浮かび上がってくると思います。 そこで今回は、実際に GitHub Pages 上で運用されている Dive Into HTML5 をよく知る立場から書かれた記事 「GitHub Pages Workflow and deleting git’s `master` branch – Oli.jp」 の翻訳を中心に、関連するいくつかの記事から、ユースケースと運用のシナリオ、及びそれに応じたワークフローをまとめてみました。 以下は、その参考記事です。 Git post-commit hook to keep master and gh-pages branch in sync by Paul Irish 2011

GitHub がオープンソースの場として魅力的な理由は、Git という優れた分散・協調型リビジョン管理システムのリポジトリー・ザーバーとして誰でも利用できるということはもちろん、README などのドキュメント生成機能やコメンティング機能、問題のトラッキング機能など、Git を補助し、オープンな分散・協調開発を支えるサブシステムが充実している点が挙げられるでしょう。無料でもかなりのことができるのに、ビジネスとしてもちゃんと成立している理由はこんなところにあるように思います。 ただ、同種サービスの Google Code や Bitbucket と決定的に異なり、GitHub の最大の魅力となっているのは、GitHub Pages という1種のホスティング・サービスではないかと思います。成果物をただずらずらと味気ないページに並べるのではなく、趣向を凝らした紹介ページを自由に作り、プロジェクト

Firebug の console.log() って JavaScript のデバッグ時にはすごく威力を発揮するのですが、Firebug を閉じている時や他のブラウザをチェックする段になると console is undefined のエラーが出て、鬱陶しいですよネ？ 次の様にすれば回避できますが、全ての箇所に if (...) を付けるのもイマイチです。 if (typeof window.console != 'undefined') { console.log(a); console.trace(b); ... } ということで、つまらない Tips を2つほど。 1.Firebug lite をインクルードする Firebug lite は IE6+、Firefox、Opera、Safari、Chrome で Firebug の簡易版を使えるようにするためのものです。クロス・ブラウ

Easel JS は、HTML5 の Canvas へのリアルタイム描画を簡単にしてくれるライブラリです。Canvas 要素には、動的に描画を行う仕組みがないので、絵を動かそうとする場合、表示更新のプログラミングが必要なのですが、この Easel JS にはそういった機能はもちろん、例えば頭や胴体、手足といったパーツをグループ化して動かすコンテナ機能、マウスイベントを扱う機能等が備わっているため、ちょっとしたアニメーションやゲームなどが簡単に作れそうです。 ライセンスは MIT、現在のバージョンは0.1のα版ですが、β版からはGoogle code と GitHub で公開するとの事です。iOS や Android でも動作するので、アプリしだいでは一気に広まりそうな気がしますネ。 何はともあれ、デモをご覧ください。 game sparkles rollover / drag & drop

先日、YSlow が 2.1.0 にバージョンアップされました。リリースノートを見ると、主に次の2つが目に付きます。 img、link、script、iframe タグ、あるいは JavaScript の Image() オブジェクト等において、空の src や href 属性をチェックし減点する新たなルール 「画像に対する空の src は避けよ」 を追加した。 head タグ内に動的に script タグを挿入する Deferred Script は、レンダリングを妨げず、ページ内の他要素と平行にダウンロードされるため、ルール 「JavaScript はページの最後に」 の減点対象としないロジックを追加した。 1. は、空の src があった場合、ブラウザがこれを現在のページと解釈し再度リクエストしてしまう結果、トラフィックが倍になってしまうという問題に対するペナルティーとして追加されま

Yslow ルールでは、スクリプトはページの最後尾、つまり </body> 直前に置け、と言っています。なぜなら、スクリプトの読み込みや実行により、他のページ要素の読み込みやレンダリングがブロックされてしまうからです。 一方、古くは IE4 の時代から Microsoft はこの問題に対処するため、defer 属性という独自の解決策を実装してきました。これは HTML 4.01、XHTML 1.0、1.1 で仕様として採用され、HTML5 にも発展する形で引き継がれています。 IE 以外のブラウザも既に対応されており、IE の独自仕様という色合いが濃かった従来と異なり、これからは広く利用されていくのではないかと思います。 下のビデオは、スクリプトの位置と defer 属性のあり／なしによる、ページの読み込み／表示速度の違いを Pagetest.com でテストしてみたもので、明らかな差異が

前回 に引き続き、Microsoft のコンサルタント兼トレーナー （であるらしい） で、本も出版している （らしい） Dino さんの記事 Functional vs. Object-Oriented JavaScript Development の後半を要約してみたいと思います。 今回は、jQuery の関数型プログラミング的な側面とオブジェクト指向プログラミング的な側面、そして JavaScript で OO プログラミングをする時の2つの手法 － クロージャーとプロトタイプについてです。 私の理解不足とヘタクソな翻訳を補うため、Dino さんの論点を先にまとめると、次の様になるかと思います。 jQuery は モナド のコンセプトを採用し、表に見えるところでは関数型のメリットを最大限生かしている。一方、拡張性を重視し、内部はオブジェクト指向で作られている。 JavaScript で

どちらも物事を的確に捉えようと努力することに変わりはありません。現在ではオブジェクト指向の方に軍配が上がるわけですが、そもそも問題領域を構造化して捉えようというアプローチは、人間の論理的な思考にとって自然な事ですし、歴史的に見ても、構造化分析・設計の手法は一定の成果を上げてきたといえるでしょう。 しかし、システムの規模と量の拡大に伴い、構造化分析・設計手法には次のような問題点が出てきました。 検証が困難、バグがなくならない 典型的にはデータフローやフローチャートを用い、次々に変わり行く様をモデリングするため、 複雑になればやがて人間には追跡が困難となります。さらに仕様変更が加われば、予期せぬバグ が発生するのも仕方のないことでしょう。 再利用できる範囲が非常に狭い 上位のプロセスが下位のプロセスを手続き的に呼び出すため、構造的に上位が下位に依存します。 再利用できるのは最下位の、それ以上依

2011年2月21日 追記 $script も新規参戦してきました。高々 643 バイトで、非同期読み込みや依存性の制御などができるそうです。いずれ紹介したいと思います。← 「新参の超軽量JavaScript非同期ローダー3種を徹底比較」で紹介しました！ これらのローダーのうち、LABjs の作者が 「On Script Loaders」 で HeadJS と ControlJS について意見をしていて、面白そうです。そのうち日本語訳や各ローダーの比較を行ってみたいと思います。 ローディング・スクリプトをめぐる議論 さてさて、本エントリーの本題は前述のローダーではありません。「Prefer asynchronous resources」 や Google Analytics のスニペット に示されているような、ローディング・スクリプトの変遷をまとめてみます。 これらのスクリプトのごく初期は

ブラウザ動作の理解の2回目です。今回はレンダリング・ツリーの更新に絡む、リフロー （要素の大きさ、位置などの再計算） とリペイント （描画） に関する解説を、「High Performance Web Pages – 20 new best practices」 の著者 Stoyan Stefanov のブログエントリーから 「Rendering: repaint, reflow/relayout, restyle」 を翻訳してお届けします。 同記事は、前半がリフローとリペイントに関する解説と、表示レスポンスを向上させるためのスタイル変更に関する Tips、後半は dynaTrace AJAX Edition と SpeedTracer を使った IE および Chrome の描画パフォーマンスの計測の解説で構成されてる、長い記事となっています。 今回はその前半部分をご紹介します。 レンダ

JavaScriptの読み込み・実行は、それより下にある画像など外部リソースの読み込みと表示をブロックするため、「ページ読み込み時間を短縮するJavaScriptローダー：LABjs」 や 「CSS/JavaScriptのAsynchronous Loadingをめぐる熱い論議」 で紹介したように、多数の JavaScript ローダーが開発されてきました。 これらのローダーは、「非同期スニペットのスタート ガイド – Google Analytics」 に代表される、script 要素を直接 DOM に挿入する方法が主流となっています。またそのタイプは、単一のスクリプト・ファイルを対象とした小規模なものと、Head JS、LABjs、ControlJS などに代表される、複数ファイルの依存関係をハンドリングする機能をもつものに大別されるかと思います。 後者のタイプは最小でも3KBytes

将来、何かの役に立つかもしれないので、メモとしてエントリー。 IEなんかの古いブラウザに対応するための CSS ハック方法は古くから知られていますが、CSS3 への過渡期の現在、（本当は使いたくない）ベンダー・プレフィックスや Modernizr なんかを使って新しいデザインにチャレンジしている人も多いことでしょう。 それでもなお、特定ブラウザの、特定バージョンで思った通りのデザインにならないことがあれば、やはり何かしらのハックに頼らざるを得ない状況は、今も昔も変わらないのかもしれません。 そんな場合のハックを An HTML5 boilerplate addon for CSS browser nitpicks から紹介です。紹介されているテクニックは、従来型の CSS 解釈時バグや CSS 属性のアリ／ナシといった特徴や機能ベースではなく、そのものズバリ、ユーザーエージェントによるブラ

前回 は、「Creating Responsive Applications Using jQuery Deferred and Promises」 の記事と jQuery のリファレンスを翻訳し、Deferred の解説をお届けしました。が、今一歩、Deferred オブジェクトの うれしさ をお伝えできていなかったように思います。今回はその反省をふまえ、単なる翻訳ではなく、元記事の文脈に沿って、Deferred オブジェクトをどのように使うと／何がうれしくて／どうしあわせになるのか、私が学習して得た事をお伝えしたいと思います。 今回は、4本の jsfiddle を記事に埋め込んでいます。jsfiddle 上で自由に編集してテストしてもらえばうれしいのですが、4本すべて実行すると1.4MBものリソースを読み込む事になり、ブラウザに優しくありません。すぐに タブや をクリックせずに、 タブ

「jQueryのDeferredとPromiseで応答性の良いアプリをー実践編」 で述べましたが、Deferred には次の様なうれしさがあります。 非同期な処理をする部分と、その結果をインターフェースする部分を分離する事によって、（特にアプリケーションに近い部分で） コードの可読性が高まる 複数の Deferred オブジェクトをまとめて監視出来る 一方 Web Workers には、window オブジェクトや DOM へのアクセスが出来ないなど、ちょっと引いてしまう制限がありますが、考えようによっては、表示やマウス入力を扱う ユーザー・インターフェースな処理 と、その中身の 純粋にデータ的な部分を扱う処理 とを分離して Web アプリを作るという、オブジェクト指向的な考え方と極めて親和性が良いのではないかと思います。 ということで今回は、「Deferred と Web Workers

前の記事「HTML5でモダンブラウザのCSS3バグを回避するためのハック方法」に関連して、jQuery で HTML5 データ属性にユーザーエジェント文字列を格納する方法を調べていました。その結果、ちょっと整理をしておいた方が良いかなと思う点を共有したいと思います。 ご存知の方も多いと思いますが、jQuery には .data() や jQuery.data() という、DOM 要素に データ を紐付けて記憶しておく仕組みが元々ありました。jQuery 1.4.3 からは、 API レベルでの 親和性 が考慮された形で HTML5 data-* 属性を取り込む仕様が導入されました。 HTML5 時代では、クライアント・サイドで実行されるコード量も増え、データ属性を扱う機会もちょくちょく出てくるのではないでしょうか。そこで今回は、 HTML5 data-* 属性のおさらい jQuery Da

jQuery 1.6 が既にリリース されていますが、1.5 で追加された Deferred を勉強する意味で、Script Junkie から Creating Responsive Applications Using jQuery Deferred and Promises を翻訳してみましたので、共有したいと思います。著者の Julian Aubourg は、jQuery のコアチーム・メンバーとして、Ajax モジュールの書き換えと Deferred 導入を指揮した方だそうです。 記事の途中、各メソッドの説明部分は、jQuery ドキュメントの翻訳に差し替えていますので、リファレンスとして使ってもらうのも良いかと思います。 Deferred や Promise は、概念や用語が少々分かりにくいところがあるかと思いますので、読んでくださった方の、少しでも理解の助けになれば幸いです

SixRevisionsでオンラインでグラフを描画する場合に活躍しそうなJavaScriptライブラリの特集がありましたので、紹介します。個人サイトではあまり役に立たないかもしれませんが、観ているだけで楽しくなります。元記事に敬意を表し、なるべく趣旨が異ならずかつ変な日本語にならないよう心がけたつもりですが、訳に間違えがありましたら容赦願います。 2010年1月17日 by Jacob Gube 退屈な数値データを美麗かつインタラクティブに解り易く可視化するためのJavaScriptライブラリは数多くあります。通常はHTMLテーブルで表現するデータを、JavaScriptを使って可視化し美しく見せる事ができればあなたのデータはアクセシビリティーの優れたものとなるでしょう。私は2008年にデータのグラフ化＆チャート化のためのJavaScriptを書き上げましたが、今回再び単なるデータに生命を

CSS Sprites 化や画像サイズの最適化、Data URI 化、CSS/JavaScript ファイルの圧縮・結合・読み込み順番の整理やキャッシュ制御など、本サイトでは主に HTTP リクエストの数、データ量およびそれらの順番に関して色々なテクニックを試してきましたが、さらに深く掘り下げるには JavaScript の実行がページの読み込み時間に与える影響を知っておく必要があると思います。 「ウェッブサイトの表示速度を測定するフリーツール集」 でも紹介しましたが、dynaTrace AJAX Edition という優れたツールをフリーで公開している dynaTrace software のブログでこの問題を扱った記事がありましたので共有します。JavaScript 高速化 Tips は （例えば 「JavaScriptを高速化する6つのテクニック」 など） 多々あるかと思いますが、ペ