かつて私も オブジェクト指向なJavaScriptプログラミングのススメ なんていう翻訳記事を書いてはいるのですが、正直なところ prototype.constructor の存在は知りませんでしたし、Function.call や Function.apply をどう使えばよいのかなどをちゃんと理解できてはいませんでした。

そんな中、2011年12月に書かれた Doc Center | Mozilla Developer Network の記事 オブジェクト指向 JavaScript 入門 は、オブジェクト指向の概念と JavaScript のプログラミング言語仕様をほどよくバランスさせながらも、「JavaScript のオブジェクト指向プログラミングはこうだ！」っていう大胆な書きっぷりが、私的にはスイッチが入ったのでした。

もちろんこの記事に目を留めてもらった人と私のバックグランド （仕事上は組み込み系の C → UML → C++ です） は違いますし、また優れた解説記事が多数ある中、私がこの記事を共有する価値があるのかどうか分かりません。が、私のように クラス に馴染んだ人間に教える良い方法でもあると思ったので、翻訳を中心に、その 感じ を伝えるチャレンジを再度してみたいと思います 。

オブジェクト指向 JavaScript 入門

JavaScript には強力なオブジェクト指向プログラミング能力が備わっていますが、他の言語と比べたときの違いによって、今まで様々な議論がなされてきました。

本稿では、まずオブジェクト指向プログラミングの入門的な解説から入り、次いで JavaScript のオブジェクトモデルを紹介します。そして最後に JavaScript におけるオブジェクト指向プログラミングの概念を、例を用いて示したいと思います。

JavaScriptの復習

もしあなたが、例えば変数や型、関数やスコープといった JavaScript の概念についての理解をより確かなものにしたいなら、JavaScript 再入門 を読むと良いでしょう。また Core JavaScript 1.5 ガイド も参考になります。

オブジェクト指向プログラミング

オブジェクト指向プログラミングは、実世界に基づくモデルを構築する際に、抽象化という技法を用いるプログラミングのパラダイムです。そのために、既に確立されたパラダイムであるモジュール化やポリモーフィズム、カプセル化といった幾つかの技法を用います。今日、広く普及している多くのプログラミング言語 （Java、JavaScript、C#、C++、Python、PHP、Ruby、Objective-C など） がオブジェクト指向プログラミング （OOP） をサポートしています。

古典的なプログラムが、関数の集合、あるいは単なるコンピューターへの命令リストに過ぎないのとは対照的に、オブジェクト指向プログラミングは、オブジェクトの集合を用いるソフトウェア・デザイン手法と見なすことができます。OOP ではそれぞれのオブジェクトが、メッセージを受信し、データを処理し、他のオブジェクトにメッセージを送信することができます。どのオブジェクトも、異なる役割や責務を持つ独立した小さなマシンと見なすことができるのです。

オブジェクト指向プログラミングは、プログラミングにおける柔軟性や保守性を向上させることを意図していて、実際、大規模なソフトウェア・エンジニアリングの領域において広く普及しています。またモジュール化に強く重点が置かれているため、オブジェクト指向のコードはモジュラ・プログラミング手法 （訳者注：単一目的の小さなモジュールを単位とするプログラミング手法。OS などの構築手法としてよく言及されている） に比べ、開発がよりシンプルで、後々の理解がし易く、またより複雑な状況や手順を分析し、コーディングすることに適しているのです。

用語の解説

クラス

オブジェクトの特性を定義したものです。

オブジェクト

クラスのインスタンス（実体）です。

プロパティ

例えば 色 といった、オブジェクトの特性です。

メソッド

例えば 歩く といった、オブジェクトが持つ機能です。

コンストラクタ

オブジェクトが生成されるときに呼び出されるメソッドです。

継承（インヘリタンス）

あるクラスが別のクラスから特性を継承することができるという性質のことです。

カプセル化

クラスにはオブジェクトの特性だけを定義し、メソッドにはそのメソッドをどのように実行するかだけを定義します （訳者注：一般的なカプセル化の概念としてこの表現には違和感を感じますが、特に JavaScript の OOP の場合、プロパティはコンストラクタで、メソッドはプロトタイプで定義するということを指しているのではないかと思います。もちろんコンストラクタ中でもメソッドは定義できますが、オブジェクトのインスタンス毎に定義されるためメモリ効率が良くありません。一方コンストラクタ中で定義すれば、後述するように各インスタンスはただ1つの関数を参照するようになり、また必要であればインスタンスごとにオーバーライドすることもでき、OOP 言語として自然な感じになります）。

抽象化

オブジェクトの継承やメソッド、プロパティなどの組み合わせを駆使し、問題領域のモデルをシミュレートできるようにすることです。

ポリモーフィズム

複数の異なるクラスに属するメソッドまたはプロパティを定義することができるという性質のことです。

さらに詳しいオブジェクト指向プログラミングの定義については、Wikipedia の オブジェクト指向 をご覧ください。

プロトタイプ・ベースのプログラミング

プロトタイプ・ベースのプログラミング は、オブジェクト指向プログラミングの中でも、クラスを持たないスタイルをとります。オブジェクトの振る舞いの再利用 （クラス・ベースのプログラミング言語の継承に当たる） は、既に存在するオブジェクトをプロトタイプとして流用する形で行われます。このようなプログラミング・モデルは、クラスレス、プロトタイプ指向 あるいは インスタンス・ベース のプログラミングとして知られています。

プロトタイプ・ベース言語 の原型は、David Ungar と Randall Smith によって開発された Self というプログラミング言語に見ることができます。しかしながら近年、クラスレスなプログラミング・スタイルが急激に広まりつつあります。例えば JavaScript、Cecil、NewtonScript、lo、MOO、REBOL、Kevo、Squeak （訳者注：スクイーク は、学校教育でも取り入れられているメディア・オーサリング・ツールです） といったものがその代表ですが、他にも多数 存在します。

JavaScriptオブジェクト指向プログラミング

コア・オブジェクト

JavaScript はそのコアに、幾つかのオブジェクトを内包しています。例えば、Math、Object、Array、String といったものがあります。次の例は、Math オブジェクトの ramdom() というメソッドの使用例です。

[javascript]
alert(Math.random());
[/javascript]

JavaScript に含まれるコア・オブジェクトのリストは、Core JavaScript 1.5 Reference: Global Objects を参照してください。

JavaScript では、どのオブジェクトも Object のインスタンスの1つで、そのプロパティとメソッドを継承しています。

カスタム・オブジェクト

（訳者注：定義済みのコア・オブジェクトに対し、後から定義するオブジェクトを指しています。）

クラス

JavaScript は C++ や Java と異なり、クラス宣言を持たないプロトタイプ・ペースの言語です。これは、クラス宣言を持つ言語に慣れ親しんだプログラマにとっては混乱の元かも知れません。代わりに JavaScript では 関数 を クラス のごとく使います。クラスの定義は、関数の定義同様に簡単です。以下の例は、Person という新しいクラスを定義していることになります。

[javascript]
function Person() {}
[/javascript]

（訳者注：「function をクラス宣言と思え！」という大胆な書きっぷりが、私が気に入った最大の理由です 。これ以降、用語も含めて クラス・ベース の文脈で解説されています。）

オブジェクト（クラスのインスタンス）

オブジェクト obj の新しいインスタンスを作るためには、obj という型を後で参照できるよう new 宣言子を用いて変数に割り当てます。

次の例は、Person という名前のクラスを定義し、person1 と person2 という2つのインスタンスを作成しています。

[javascript]
function Person() { }
var person1 = new Person();
var person2 = new Person();
[/javascript]

コンストラクタ

コンストラクタは、オブジェクトの実体を生成するときに呼び出されます。コンストラクタはクラスのメソッドです。JavaScript では、関数がオブジェクトのコンストラクタとして機能するので、明示的にコンストラクタ・メソッドを定義する必要がありません。クラス内で定義されたどんなアクションも、インスタンス化のたびに実行されるのです。

コンストラクタは、オブジェクトのプロパティを設定したり、オブジェクトを準備するメソッドを呼び出すために使われます。クラスにメソッドを追加／定義する別な方法は、後ほど説明します。

次の例は、クラス Person のインスタンス生成時に、アラートを出すコンストラクタを定義しています。

[javascript]
function Person() {
alert(’Person instantiated’);
}

var person1 = new Person();
var person2 = new Person();
[/javascript]

プロパティ（オブジェクトの属性）

プロパティは、クラスに内包される変数です。どのオブジェクトのインスタンスもプロパティを持っています。また継承を正しく行うためには、プロパティはクラス （関数） の prototype プロパティの中で設定される必要があります。

クラスの内部でプロパティを機能させるためには、現在のオブジェクトを参照する this というキーワードを使います。クラスの外部からプロパティへ read/write アクセスするには、InstanceName.Property というシンタックスを使います。これは C++ や Java、その他多数の言語と同じ方法です （クラスの内部でプロパティの値を set/get するには、this.Property というシンタックスが使われます）。

次の例は、Person クラスに gender というプロパティを定義しています。

[javascript]
function Person(gender) {
this.gender = gender;
alert(’Person instantiated’);
}

var person1 = new Person(’Male’);
var person2 = new Person(’Female’);

//display the person1 gender
alert(’person1 is a ‘ + person1.gender); // person1 is a Male
[/javascript]

メソッド

メソッドは、プロパティと同じロジックに従います。違いは、メソッドは関数であり、関数として定義されるということです。メソッドの呼び出しはプロパティのアクセスと似ていますが、メソッド名の最後に () （カッコ） を付けなければなりませんし、必要であればそこに引数を指定することができます。メソッドを定義するには、クラスの prototype プロパティに function とい名前のプロパティを割り当てます。即ち関数に付けられた名前が、そのオブジェクトで呼び出すことのできるメソッドの名前になります。

次の例は、Person クラスにメソッド sayHello() を定義します。

[javascript]
function Person(gender) {
this.gender = gender;
alert(’Person instantiated’);
}

Person.prototype.sayHello = function() {
alert (’hello’);
};

var person1 = new Person(’Male’);
var person2 = new Person(’Female’);

// call the Person sayHello method.
person1.sayHello(); // hello
[/javascript]

JavaScript におけるメソッドは、プロパティとしてクラス（オブジェクト）にバインドされている通常の関数オブジェクトです。これが意味することは、メソッドはコンテキストの外で呼び出すことができるということです。次の例を見てください。

[javascript]
function Person(gender) {
this.gender = gender;
}

Person.prototype.sayGender = function() {
alert (this.gender);
};

var person1 = new Person(’Male’);
var genderTeller = person1.sayGender;

person1.sayGender(); // ‘Male’
genderTeller(); // undefined
alert(genderTeller === person1.sayGender); // true
alert(genderTeller === Person.prototype.sayGender); // true
[/javascript]

上記例では、同時に幾つもの概念を表しています。その1つは、JavaScript には オブジェクトごとのメソッド というのはなく、メソッドへの全ての参照は、prototype で定義された、ただ1つの関数を指しているという点です。そしてもう1つは、関数がオブジェクトのメソッド （正確にはプロパティです） として呼び出されたとき、その時の オブジェクトのコンテキスト が this という特別な変数に バインド されるという点です。これは次のように関数オブジェクト （この場合 genderTeller） の call メソッドを通じて （この場合は person1 の） this を提供すること同じです。

[javascript]
genderTeller.call(person1); // alerts ‘Male’
[/javascript]

（訳者注：実際に試した方が良く理解できると思い、少しアレンジした Fiddle を作ってみました。call メソッドのメリットは、次の継承でより明らかになります。）

継承（インヘリタンス）

継承は、1つ、あるいは複数クラスの派生バージョンのクラスを作る機構です （JavaScript の場合、単一クラスの継承だけがサポートされています）。派生クラスは一般に 子 と呼ばれ、その他のクラスは一般に 親 と呼ばれます。JavaScript では、親クラスのインスタンスを子クラスに割り当てることで実現させます。その後、派生部分を定義します。

次の例は、Person クラスの子クラスとして Student クラスを定義します。そして sayHello() メソッドを再定義 （オーバーライド） し、さらに sayGoodBye() メソッドを追加します。

（訳者注：Student のコンストラクタで Person のコンストラクタを呼び出す際、コンテキストを Student とするために call を用いています。このようにすれば、継承したメソッドをオブジェクトのインスタンスに合わせて呼び出すことができます。）

カプセル化

前述の例題では、Student クラスは Person クラスの walk() メソッドがどのように実装されているかを知らなくても、そのメソッドを使うことができました。即ち Student クラスは、そのメソッドを変えようと思わない限り、明示的に定義する必要がないということです。これはカプセル化と呼ばれており、どのクラスも親のメソッドを継承することができ、変えたいと望むときだけ定義すれば良いのです。

抽象化

抽象化とは、問題領域をモデリングするためのメカニズムのことです。このモデリングは、継承とコンポジション （集約＝あるオブジェクトの中に別なオブジェクトが構成要素として入る関係） によって成されます。JavaScript では継承によって派生が作られ、またクラスのインスタンスが他のオブジェクトの属性値となることでコンポジションが構成されます。

JavaScript の Function クラスは、Object クラスを継承しています （これはモデルの派生です）。そして Function.prototype プロパティは Object のインスタンスととなっています （この関係は、コンポジションです）。

ポリモーフィズム

全てのメソッドとプロパティは prototype プロパティ内で定義されるため、異なるクラスで同じ名前のメソッドを定義することができます。つまり、メソッドはそれが定義されているクラスだけにスコープされているということです。これは、2つのクラスが親と子の関係 （継承チェーンにおいて、一方が他方を継承しない関係にあるとき） にない場合にのみ、真となります。

備考

本稿に記したオブジェクト指向プログラミングを実装するための技法は、JavaScript でだけ使われるものではありません。即ち、オブジェクト指向プログラミングがどのように実行されるかという点に関して言えば、他の言語にも適応性させることができます。

同様に、ここに示した技法はどんな言語のハックを使っているわけでもありませんし、他の言語のオブジェクト理論の実装を模倣したわけでもありません。

もちろんここで述べた以外にも、さらに高度な JavaScript のオブジェクト指向プログラミング技法がありますが、本稿のスコープ範囲外となりますので、ここまでにしたいと思います。

参考情報

（訳者注：MDN には、JavaScript に関する日本語リソース が多数ありますし、今回紹介した記事もいずれは日本語に翻訳されると期待しています。本記事の最後は、さらに理解を深めるために参照すると良いと思う MDN のリソースを順に紹介します。）

• Web開発の初歩
• Core JavaScript 1.5 ガイド – MDN
• JavaScript 1.5 リファレンス – MDN
• JavaScript「再」入門 – MDN
• その他 オブジェクト指向 に関する MDN の日本語リソース

参照元の記事に対する著作権およびライセンス表記

• Author(s): Fernando Trasvina <f_trasvina at hotmail dot com>
• Copyright Information: © 1998-2005 by individual mozilla.org contributors; content available under a Creative Commons license

訳者あとがき

今回紹介した記事は、一見何の変哲もない「JavaScript オブジェクト指向プログラミング入門」ですが、その実、少なくとも私には目からウロコの記事でした。なぜなら今までは、プロトタイプ・ベースとクラス・ベースの違いを意識し過ぎていたからです。そういった目先の違いを強調するのではなく、「大して違いはないさ、ほうらネ、こう思えばいいんだょ」 と、この記事は訴えているのだと思います。

もちろん元記事にもある通り、言語実装上の違いが色々語られているのも事実です。なぜならさらに高度に使いこなすには、その違いをちゃんと意識しなければならないからでしょう。

しかし元々上位概念的には共通なわけで、大雑把でもいいから一旦自分の中に取り込んだ後、今度はその違いに目を向けるというハードルの超え方もアリだと思いますが、いかがでしょうか？

前回、GitHub Pages 活用の概要を書きましたが、実際に運用していくと、master と gh-pages をどう使い分けるか、また両者の同期をどう行うかなど、いくつかの課題が浮かび上がってくると思います。

そこで今回は、GitHub Pages 上で実際に運用されている Dive Into HTML5 をよく知る立場から書かれた記事 「GitHub Pages Workflow and deleting git’s `master` branch – Oli.jp」 の翻訳を中心に、関連するいくつかの記事から、ユースケースと運用のシナリオ、及びそれに応じたワークフローをまとめてみました。

以下は、その参考記事です。

1. Git post-commit hook to keep master and gh-pages branch in sync by Paul Irish
2. 2011年10月13日 Easily keep gh-pages in sync with master | Lea Verou
3. 2011年10月13日 Quick tip: git checkout specific files from another branch
4. 2011年10月14日 GitHub Pages Workflow and deleting git’s master branch – Oli.jp
5. 2011年11月29日 Ryan Fitzer » Easy Syncing of GitHub Pages

これらの記事は、書かれた日付が近いのもそうですが、相互に参照したり、コメント欄で議論したりしていますので、それらをトラッキングしながら私なりの注釈も加えていきたいと思います 。

ちなみに GitHub Pages には、ユーザーページとプロジェクトページの2種類があることは前回説明した通りです。前者は基本的に master ブランチのみを管理すれば良いので、本記事では、master と gh-pages の2つのブランチを管理しなければならない後者を主な対象としています。

1.gh-pages作成のワークフロー（おさらい）

GitHub Pages の作成 は少々特殊で、作業ディレクトリ を クリーンな状態 （commit するか、stash で隠す） にした上で、次のようにして gh-pages ブランチを作成します。

[text]
cd /path/to/fancypants
git symbolic-ref HEAD refs/heads/gh-pages
rm .git/index
git clean -fdx
echo “My GitHub Page” > index.html
git add .
git commit -a -m “First pages commit”
git push origin gh-pages
[/text]

通常のブランチ作成 （例えば git checkout -b gh-pages） では、作業ディレクトリの内容が全て引き継がれることになりますが、上記により、親のない空の gh-pages が作成されます。独立した2つの異なるブランチの想定する使い方は以下の通りです。

• master : プロジェクトのコード
• gh-pages : プロジェクトの PR サイト

このような特別な作り方をする理由は、次の2つでしょう。

• master と gh-pages を、マージされることのない独立したブランチとして管理・運用したい
• リモート・リポジトリがクローンされた時でも、gh-pages はクローンされたくない

試しに gh-pages ブランチのあるリモート・リポジトリをローカルにクローンしてみてください。デフォルトで gh-pages はクローンされません。

[text]
$ git clone git@github.com:username/my_repo.git
Cloning into ‘my_repo’…
…
$ git branch
* master
[/text]

gh-pages をクローンするには、次のように 追跡ブランチ として明示的に指示しなければなりません。

[text]
$ git checkout –track -b gh-pages origin/gh-pages
Branch gh-pages set up to track remote branch gh-pages from origin.
Switched to a new branch ‘gh-pages’
$ git branch
* gh-pages
master
[/text]

これを応用すれば、クローンされたくないブランチを作ることもできますネ 。

参考情報

• 2009年5月22日 git – How do I publish to .github.com? – Stack Overflow
  • 別PCに gh-pages を含めてクローンする方法が紹介されています。
• 2011年2月21日 GithubのProject Pagesを作る手順を調べてみた。もしくはgitで空ブランチを作る方法を調べてみた。 – kanonjiの日記
  • gh-pages を作るコマンド列が、1行1行丁寧に分析されています。

2.GitHub Pages運用のユースケースとワークフロー

GitHubber 達が工夫を凝らしたワークフローを考案していますので、それらを紹介します。

2.1プロジェクトのコードとPRサイトを1つのリポジトリとして運用する

master の最新版から一部のファイルをチェックアウトし、PR サイト側 （gh-pages） でデモを動かすという、まさに典型的な運用のシナリオです。

Lea Verou は 参考記事2 で、master で作業している場合を想定した、次のようなワークフローを提案しています。

1～4行目までは通常の更新作業です。5行目で gh-pages に切り替え、6行目で master と同期させています。

Nicolas Gallagher は、この提案の6行目に問題があることを指摘し、参考記事3 を書いています。git rebase master は、master の歴史を含めて全てを gh-pages にミラーリングすることになります。元々2つのブランチがマージ可能（あるいは一方が他方の派生）であれば rebase が効果的な局面もありますが、一部の共通なファイルを異なるブランチで同期させる方法としては、次のように必要なファイルだけを更新する git checkout master -- ... の方が適切であるというのが彼の主張です。

[text highlight="6,7"]
git add .
git status # 変更されたコミットすべきファイルを確認します
git commit -m “…” # master でコミットします
git push # 変更を GitHub の master ブランチに push します
git checkout gh-pages # gh-pages ブランチに切り替えます
git checkout master — files… # master のステージング・エリアから現在の作業ディレクトリにファイルをコピーします
git commit -m “…” # gh-pages でコミットします
git push # gh-pages ブランチの変更を GitHub に push します
git checkout master # master ブランチに戻ります
[/text]

さて、いずれのワークフローでも master で何かコミットしたら、gh-pages への反映も自動的に行いたくなりますネ。こんな時には post-commit フック が便利です。

Paul Irish は 参考記事1 で、Lea のワークフロー を自動化するための shell スクリプトを Git リポジトリ中のファイル .git/hooks/post-commit に記述することを提案しています。

[text highlight="3"]
#!/bin/sh
git checkout gh-pages
git rebase master
git checkout master
[/text]

このスクリプトにより、Lea のワークフロー の4行目以降を git push --all という1行に置き換えることができます。

[text highlight="4"]
git add .
git status # 変更されたコミットすべきファイルを確認します
git commit -m “…” # master でのコミットを行います
git push –all # 全てのブランチの変更をリモートに push します
[/text]

さらに Ryan Fitzer は、これらの議論をふまえた上で rebase を merge に置き換えた運用を 参考記事5 に記しました。おそらく gh-pages をテストサイトと位置づけ、一部ファイル修正もあり得るという運用シナリオを描いているのではないかと思います。

2.2リモートのgh-pagesをmasterのサブモジュールとして運用する

Git の submodule は、「ふたつのプロジェクトはそれぞれ別のものとして管理したい。だけど、一方を他方の一部としても使いたい」 時のコマンドです。ここでの想定は、ローカル上の jekyll で生成したブログを gh-pages に送り込むというシナリオです。

例えば jekyll が _site というディレクトリにサイトを構築する設定だとすると、この _site にリモートの gh-pages と同期するブランチを作成すれば、最もシンプルにプロジェクトのブログを運営することができるようになるでしょう。この辺はちょっとマニアックな内容になりますので、詳しくは以下の参考情報をご覧ください 。

参考情報

• 2008年12月21日 GitHub Pages – GitHub
  • master 内で gh-pages を同期させる方法として submodule を使うことが提案されています。
• 2010年3月10日 Doxygen を github-pages にあげるのをお気楽にやる方法 – ”><xmp>TokuLog 改メ tokuhirom’s blog
  • gh-pages をサブモジュールに設定し、Doxygen で流し込む方法が解説されています。
• 2010年11月8日 Generate GitHub pages in a submodule – blindgaenger
  • GitHub Pages で jekyll のブログを設置する方法が解説されています。
• 2011年2月9日 GitHub 上に ページを作成する | Tanablog
  • 切り替えが面倒 （笑） は、ワークフローを工夫する上での最大のモチベーションです。サブモジュールの更新も重要です。

2.3gh-pages専用のリポジトリを作って運用する

Nicolas Gallagher は、GitHub ヘルプ に掲載された方法にヒントを得て、ローカルの master を GitHub の gh-pages に [remotename] [localbranch]:[remotebranch] の書式で push しています。

[text]
$ git push origin master:gh-pages
[/text]

これは、Lea のワークフロー の5行目以降を置き換えます。ローカルの master ブランチは、リモートの gh-pages ブランチのミラーかサブセットであることが要求されます。もし gh-pages をローカルに持っているなら、それは GitHub 上のバージョンのコピーとなることを意味しています。これにより、ローカルの gh-pages を無視する （あるいは持たなくても良い） ことになります。もしローカルの gh-pages で何かの push に失敗しても （non-fast-foward updates were rejected）、fetch と merge でローカルの master に取り込んだ後、再び push するだけです。

一方ここまで来ると、ローカルのブランチも gh-pages としてしまった方が便利でしょう。次の例は、新しく gh-pages ブランチを作成し、master ブランチを削除します。

[text]
$ git checkout -b gh-pages
Switched to a new branch ‘gh-pages’
$ git branch -d master
Deleted branch master (was xxxxxxx).
$ git branch
* gh-pages
[/text]

参考情報

• 2011年2月23日 Setup GitHub Pages “gh-pages” branch and “master” branch as subfolders of a parent project folder (”grandmaster”). — Gist
  • 親プロジェクト（ディレクトリ）の下に、master、gh-pages それぞれのサブ・ディレクトリに作り、それぞれ別のリポジトリとして管理する方法が解説されています。

2.4GitHub上のmasterを削除し、gh-pagesだけで運用する

前章最後の続きとも言えますが、もはや GitHub 上にさえ master が要らないというプロジェクトもあり得るでしょう。例えばドキュメント自体がプロジェクトの対象であるような場合です。

GitHub 上の master ブランチを削除するには、次のようにします。

1. 「Admin → Options → Settings」 で、Default Branch を master 以外に設定する
2. 「git push origin :master」 を実行する （空のローカル・ブランチをリモートの master に push して リモートブランチを削除する）

3.CNAME（Canonical Name）で独自ドメインをGitHub Pagesに転送する

オリジナルのドメインを持っている人で、DNS レコードの設定ができる環境にある方（そういうサービスを受けられる方）は、そのドメインあるいはサブドメインの別名を GitHub Pages に設定し、GitHub Pages にはそのドメイン名を記述した CNAME というファイルを設置することで、自分のドメイン内の URL で GitHub Pages にアクセスすることができます。

例えば、最近見つけたサイト nothub.org は、GitHub のプロジェクトページ tricknotes/nothub.org （2.4章で述べた gh-pages ブランチしかないリポジトリです！） の GitHub Pages http://tricknotes.github.com/nothub.org （現在は 404 Not Found ですが、この理由と対応は後述します） に別名が設定されています。試しに http://nothub.org/CNAME にアクセスしてみましょう。nothub.org と書かれているハズです。

今回はプロジェクトページを主に扱いましたが、ユーザーページでも同様のことができます。CNAME の設定については、Glide Note さんの記事 「GitHub PagesでCustom Domainを利用する – Glide Note – グライドノート」 が参考になると思います。元々は www.glidenote.com で運用されていたブログを、blog.glidenote.com の別名として Octopress を導入した GitHub Pages にマッピングされています。

参考情報

• Custom Domains – GitHub Pages – Home
• CNAMEレコード

4.GitHub Pagesの寿命と更新タイミングについて

無料アカウントだからでしょうか、GitHub Pages はしばらくアクセスしないと 404 Not Found 状態になります。

gh-pages を更新し、コミットし直せば再びアクセスできるようになります。おそらく何
らかのキャッシュ機構が働いていて、アクセスのない古いキャッシュは削除され、gh-pages が更新されるまでは再作成されないのではないかと思います。

一方 CNAME を設定した場合、上記が発生していても、設定したオリジナル・ドメインにはちゃんとアクセスできることが 参考記事4 で報告されています。

私の場合、一定時間ごとにアクセスする CGI をサーバーの cron に設定し、GitHub Pages の寿命を延ばしています。もちろんこの方法は未保証ですので、あしからず 。

参考情報

• 2009年11月30日 github pages setup not working – GitHub | Google グループ
  • 1日か2日で GitHub Pages にアクセスできなくなる事象が報告されています。GitHub の技術サポートから 「再コミットせよ」 という返答が書き込まれています。

5.まとめ

GitHub Pages の典型的な使用方法以外にも、色々な使い方を 「ユースケースと運用のシナリオ」 という形で整理を試みてみました （厳密な意味 でのツッコミはご勘弁願います ）。結果的にオリジナルの記事をアレンジしてしまうことにはなりましたが、柔軟な運用ができるのは、元々の Git の自由度の高さを活かす設計の良さが GitHub にあるからではないかと改めて知ることができたように思います。GitHub Pages を活用したいと思う方の参考になれば幸いですし、「もっとこういうシナリオがあるゾ」 というご意見を頂ければ、激しく喜びます 。

最後に、GitHub サポートからのアドバイスを…。

何が起きるか分からない時はいつでも、最初にバックアップとしてローカルにクローンを作成し、全てを fetch してから試してみることです。もし何か問題が起きたら、リポジトリを再度 push すれば良いのです。

ただ、同種サービスの Google Code や Bitbucket と決定的に異なり、GitHub の最大の魅力となっているのは、GitHub Pages という1種のホスティング・サービスではないかと思います。成果物をただずらずらと味気ないページに並べるのではなく、趣向を凝らした紹介ページを自由に作り、プロジェクトの成果を世界にアピールする − GitHub Pages は、そんなことのできるサービスです。

2008年12月の GitHub Blog の記事 には、次のような GitHub Pages の紹介があります。

You can put anything here you like. Use it as a customizable home for your Git repos. Create a blog and spread your ideas. Whatever you want!
（GitHub Pages 上にはお好みで何でも置くことができます。Git リポジトリのホームページとしてカスタマイズしても良し、ブログを設置してあなたのアイディアを広げても良し。あなた次第です！）

ということで今回は、この GitHub ページの活用方法をまとめてみたいと思います。

目次

1. GitHub Pagesの概要
2. かんたん、カッコいいGitHub Pagesの作り方
3. GitHub Pagesプロジェクト・ギャラリー

1.GitHub Pagesの概要

GitHub Pages では、Git のリポジトリ管理機能とホスティング・サーバー機能とが連携し、次の2つのサービスが提供されています。ちなみに冒頭で 「お好みで何でも置くことができます」 と紹介しましたが、静的ページのみのホスティングです。

ユーザーページのホスティング

GitHub でいうユーザーページとは、自分自身の活動を紹介するためのページです。

特別なリポジトリ username.github.com を作成し、index.html や必要なリソースを push しておけば、http://username.github.com/ という URL でそのページを閲覧することができます。

まずは、ユーザーページ用のリモートリポジトリを作成 しましょう。

ユーザーページ用リモート Git リポジトリの設定

次は、ローカルの Git リポジトリの作成を促す画面です。

ユーザーページ用ローカル Git リポジトリの作成

「Next steps:」 を参考に、新しい index.html を含むローカル Git リポジトリを作ると良いでしょう （username は自分のユーザー名に差し替えてください）。

[text]
mkdir username.github.com
cd username.github.com
git init
echo “Hello” > index.html
git add index.html
git commit -m “first commit”
git remote add origin git@github.com:username/username.github.com.git
git push -u origin master
[/text]

余談ですが、GitHub リモート・リポジトリへのプロトコル／パスは、1クリックでコピーすることができます。

GitHubリモート・リポジトリへのパスを1クリックでコピー

もし http://username.github.com/ にアクセスして、次のような画面になっても焦る必要はありません。一番下にあるように、初めて GitHub ページを作成したときには、反映されるまで10分程度かかるということなので、落ち着いて待ちましょう。

最初は10分ぐらい待ちましょう

各プロジェクト・ページのホスティング

個別のプロジェクトを紹介するためのページです。

各プロジェクトのリポジトリで （例えば myrepos）、gh_pages という特別なブランチを作成し、必要なファイルを push しておけば、http://username.github.com/myrepos/ という URL でそのページにアクセスすることができます。

まずはローカルの Git リポジトリ （master ブランチがあるはずですネ） に移動し、未 commit のファイルがないことを確認します （あれば push します）。そして以下を実行し、とりあえずの index.html を作成しましょう。

[text]
cd /path/to/myrepos
git symbolic-ref HEAD refs/heads/gh-pages
rm .git/index
git clean -fdx
echo “My GitHub Page” > index.html
git add .
git commit -a -m “First pages commit”
git push origin gh-pages
[/text]

上記コマンドライン以外にも、「Admin → Options → Features」（プロジェクトページ右上の ボタンから入る） で、紹介ページを自動作成することもできます。

プロジェクト用GitHubページの自動作成

プロジェクトの情報を記入してページを作成

自動作成されたプロジェクト・ページ

自動作成したページは、次の git コマンドでローカルに持ってくることができるので、どんな項目を載せるべきなのかを知るためにも一度は作ってみるのが良いでしょう。

[text]
git fetch
git pull
git checkout gh-pages
[/text]

参考情報1

• GitHub Pages – Home
• github:pagesはもう使っているか？ – Meltdown Countdown

2.かんたん、カッコいいGitHub Pagesの作り方

ここから先はもちろん自由にページを作ってもらえれば良いのですが、おすすめの方法3つと、ページを彩るリソースを紹介します。

HTML5 Boilerplate、Initializr 2 を利用する

「カッコいい」という要求を「HTML5 + CSS3 + Web フォント + レスポンシブなページ + ソーシャル共有ボタン」という要件に置き換え、Initializr 2 をベースに作ってみたのがこれです。

プロジェクトページの例

HTML5 Boilerplate や Initializr 2 活用のコツやソーシャルボタンの設置については、拙作の 参考情報2 をぜひ参照してください 。

参考情報2

• HTML5 Boilerplate, Initializr 2をこれから使う人が押さえるべき5つの原則 | ゆっくりと…
• 最近海外で流行りのTwitter,Facebook,Google+1,Analyticsをまとめる非同期スクリプトにはてなを加えてみた | ゆっくりと…

jekyll を利用する

jekyll（ジキル）は、テンプレートを使って静的な Web サイトを構築するための Ruby ベースのフレームワークです。プロジェクトページをいくつも作る場合に便利でしょう。通常はローカルに Ruby 環境を整え、RubyGems（Ruby のパッケージ管理システム）から jekyll をインストールするのですが、GitHub Pages 上でもこのフレームワークが機能しますので、必ずしもこのような環境を整える必要がありません。

まずはローカルの gh-pages ブランチに次のようなファイルを準備します。

[text]
.
├─ _layouts
│ └─ default.html
├─ css
│ └─ style.css
└─ index.md
[/text]

default.html はテンプレートで、最も簡単には次のように書きます。

[html]
<!doctype html>
<html lang=”ja”>
<head>
<meta charset=”utf-8″>
<title>{{ page.title }}</title>
<link rel=”stylesheet” href=”css/style.css”>
</head>
<body>
{{ content }}
</body>
</html>
[/html]

{ ... } で囲まれた部分は jekyll によって解釈されます。{ content } に相当する部分を、例えば index.md （マークダウン） に記述します。

[text]
—
layout: default
title: プロジェクト・タイトル
—

プロジェクト・タイトル
===================
ここにプロジェクトの紹介を書きます。
…
[/text]

layout には先のテンプレートを指定します。そして title はテンプレート中の { page.title } に置き換わるという仕組みです。実は、GitHub Pages の解説ページ自体 がこの仕組みで作られています。

また、ここでは .md の例を載せましたが、.html や .textile でも OK ですし、demo.md や documents.html といったファイルを置いても自動的にテンプレートを適用し、マークアップしてくれます。マークダウンや、さらに複雑なテンプレートの作り方については、参考情報3 をご覧ください。

参考情報3

• 脱GitHub初心者を目指す人のREADMEマークダウン使いこなし術 | ゆっくりと…
• Big Sky :: Jekyllで始める簡単ブログ
• Jekyllによる静的 Webサイト構築入門
• GitHub Pagesで楽々ホスティング – Radium Software
• jekyllで作る簡単GitHub Pages | T.I.D.

Octopress を利用する

Octopress は、jekyll を使って静的なブログを簡単に構築できるようにしたフレームワークです。副題に A blogging framework for hackers. とあるように、Gist や jsFiddle など、多彩なコードスニペットの埋め込みプラグインが提供され、また GitHub ととても親和性よく作られています。

Octopress を利用するには、Ruby（1.9 2 以上）環境を整える必要があります。Mac の人は rvm（Ruby Version Manager）で、Windows の人は RubyInstaller でインストールすることができます。個人的には Windows であれば Cygwin を使うのが良いと思いますが、現時点では Ruby のパッケージ が 1.8.7 と古いので、別途 ソースコードを入手、コンパイルが必要です。

さて、Octopress のインストール自体は 参考情報4 に譲り、ここではローカルに作成した Octopress リポジトリのおすすめ管理方法を紹介します。

Octopress で記事を書くときは、source というブランチで作業をするので、そのまま origin （つまり GitHub） に git push することもできるのですが、無料枠の GitHub では公開が原則なため、誰かにクローンされると、原稿 （Octopress の場合、マークダウン・ファイル） まで持っていかれることになり、ちょっとイヤ〜ンな感じです。そこで私は、無料でもリポジトリを非公開にできる Bitbucket にアカウントを作って原稿を管理しています。

こうすると、記事を投稿するときは rake deploy で GitHub へ、原稿をバックアップするときは git push で Bitbucket へ送ることができて、イヤ〜ンな感じがなくなります。皆さんも使い分けてみてはいかがでしょうか？

参考情報4

• Big Sky :: githubとjekyllとoctopressで作る簡単でモダンなブログ
• GithubとOctopressでモダンな技術系ブログを作ってみる – Glide Note – グライドノート
• Octopressのインストールから運用管理まで – T.I.D.

GitHub Pages を彩るためのリソース

GitHub Pages が通常のホスティング・サービスと違うのは、公開リポジトリはフォークできるということです。つまり再配布が可能な状態となるため、画像などのリソースを載せる場合は要注意です。そこでパブリックドメインか GitHub で使えるリソースを紹介します。

• シンプルで使いやすいGitHub風のボタンを簡単に実装できるスタイルシート | コリス
  • GitHub リポジトリに登録された、CSS3 で装飾されたボタンを実装するためのスタイルシートとアイコン画像です。
• GitHub Ribbons – GitHub
  • GitHub 公式のリボン画像。ものすごい長い URL の画像は透過 png 画像 （149px×149px） です。
• ダウンロードリンク用 ファスナー付書類 zip 画像、tar 画像
  • 大きさが 144px × 142px とかなりデカいです。
• GitHub 関連の素材
  • GitHub 公認のロゴやオクトキャット、リボン、創業者の写真（？）などの素材です。
• GitHub Ribbon Using CSS Transforms § Unindented
  • 画像を使わず CSS3 で実装する GitHub リボンです。
• パブリックドメインやGPLライセンスの高品質なアイコンをパッケージで配布しているOpen Icon Library – かちびと. net
  • 商用／非商用を問わず、無料で再配布可能なオープンソースなアイコンの他、一部はパブリックドメインのアイコンが公開されています。
• パブリックドメイン/CCライセンスのピクトグラムアイコン素材のみを配布するThe Noun Project – かちびと. net
  • シンプルかつ高品質なアイコンが SVG フォーマットで公開されています。
• google-code-prettify
  • コードスニペットを載せる機会の多い GitHub Pages で活躍する、軽量なシンタックス・ハイライト用 JavaScript です。オリジナルなカラーリングも容易にできますし、各言語用に拡張可能なプラグインもあります。Apache License, Version 2.0 ですので、再配布が可能です。

3.GitHub Pagesプロジェクト・ギャラリー

こだわりのある GitHub Pages を集めてみました。プロジェクトページ作りの参考にしてみてはいかがでしょうか。

4.あとがき

従来からある SourceForge.net や SourceForge.JP、Google Code に加え、GitHub の登場によってオープンソース化の流れがますます加速した感のある今日この頃。今までひっそりと自サイトで （オレオレ的に） 公開していた人たちが、ここ数年で一斉に GitHub に流れ込んで来たように思います。そして今後は、単なるコーディング能力だけではなく、人を惹き付ける魅力的なプロジェクト・ページをデザインする能力や、さらには自分の成果を世に問いその発展や貢献をプロモートする能力も必要な時代になるという気がしています。

この記事は、そんなオープンソースの意義と醍醐味を一人でも多くの方が楽しんでくれれば良いなぁ、という気持ちを込めてまとめました 。

boilerplate とは、「再利用を意図した標準的な文例集」 だそうです。

その名の通り HTML5 Boilerplate は、Paul Irish が中心となり構築されてきた、HTML5 でサイトを構築するためのテンプレート、さらにはフレームワークをも含む内容となっており、その特徴は次のように語られています。

HTML5 Boilerplate は、HTML5 を扱う上で必要な数多くの機能強化を他のベスト・プラクティスの数々と組み合わせることで、最小限の先行投資でプロジェクトの磐石な基盤を提供します。

2011年02月08日 HTML5 Boilerplate を使用して Web 開発を容易に始める | IBM developerWorks より。

HTML5 Boilerplateをベースにすることで最初からベストプラクティスが適用されたサイトやページを構築できるという特徴がある。

2011年08月15日 待望のHTML5ベストプラクティス「HTML5 Boilerplate」バージョン2登場 | マイナビニュース より。

ここで言う ベストプラクティス とは、ブラウザ違いを吸収し効率の良い JavaScript や CSS のコードを書くためのノウハウはもちろん、Yahoo! の 「Best Practices for Speeding Up Your Web Site」 や Google の 「Web Performance Best Practices」 にまとめられている、主に応答性のよいサイトを作るためのフロントエンド改善策を指しているものと思われます。

また、HTML5 Boilerplate のお手軽なサブセットとなっている Initialir 2 には、「簡単に」 とか 「さくさく」 とかの形容詞が付けられて紹介されています。

さて、実際にこれらのテンプレートを使ってみると、ベストプラクティス という一言で、または単に 「かんたん、サクサク」 という一言で終わらせるのはもったいない、という気がしました。そこで、近年の技術トレンドに照らし合わせて 「5つの原則」 という形にまとめ、それらがどのようにテンプレートに織り込んであるかを考えてみました。

これからテンプレートを使ってサイトを構築してみようという方の参考になれば幸いです 。

HTML5 BoilerplateとInitialir 2の構成

それぞれもっともベーシックな構成をダウンロードすると、その構成は下図のようになっていることでしょう （2011年11月現在）。

HTML5 Boilerplate の構成

initializr 2 の構成

HTML5 Boilerplate には、サイトを最適化してリリースするためのビルド用スクリプトとツール群、サーバーの設定ファイル等が含まれていますが、これらについては、冒頭の IBM の記事等をご参照ください。

一方 Initializr 2 の方は、HTML5 Boilerplate からインデックス・ページと css、js だけを抜き出したサブセット的な内容となっていることが分かります。

次に CSS と JavaScript ライブラリの構成モジュールについてです。それぞれは既に有名ですが、簡単なサマリを載せておきます。

HTML5 Boilerplate では、「js/libs/modernizr-2.0.6.min.js = Modernizr 2 + html5shiv + Respond.js」 となっています。

一方 Initializr 2 では、「js/libs/modernizr-2.0.min.js = Modernizr 2 + html5shiv」 で、Respond.js は独立しています。

今のところトータルとして両者に機能的な違いはありませんが、HTML5 Boilerplate の Respond.js は、メディアクエリ判定に Modernizr のそれを流用している特別版ため、合計サイズが小さくなっています。

押さえておくべき5つの原則

さて、これらのテンプレートを使いこなすために押さえておくべき原則を、順に紹介していきます。

1. モバイル・ファースト
2. レスポンシブ・デザイン
3. プログレッシブ・エンハンスメント
4. 論理的でクリーンなコード
5. プログレッシブ・レンダリング

1.モバイル・ファースト

要は 「スマホ → タブレット → デスクトップ」 の順にデザインしなさいという原則です。何を デザイン するかは 参考情報1 をご覧ください。ここではテンプレート css/style.css に、どのように反映されているかを見てみます。

css/style.css の前半は、normalize.css によるブラウザの違いを標準化するための設定です。そして中盤以降 ～ 終盤にそれぞれ次のようなブロックがあります。

テーマのスタイルを設定するブロック（中盤以降）

[css]
/* ===== primary styles =========================================
Author:
============================================================== */
…
[/css]

デバイス用のメディアクエリを設定するブロック（終盤）

[css]
/* ===== media queries ==========================================
PLACEHOLDER Media Queries for Responsive Design.
These override the primary (’mobile first’) styles
Modify as content requires.
============================================================== */

@media only screen and (min-width: 480px) {
/* Style adjustments for viewports 480px and over go here */

}

@media only screen and (min-width: 768px) {
/* Style adjustments for viewports 768px and over go here */

}
[/css]

メディアクエリの設定で、min-width: 480px は 「幅 480px 以上 （最小幅 480px）」 を、min-width: 768px は 「幅 768px 以上 （最小幅 768px）」 を意味しています。

つまり、最初の 「primary styles」 にはスマホ用スタイルを、min-width: 480px のブロックにはタブレット用を、min-width: 768px にはデスクトップ用スタイルを設定することが想定されています。

「かんたん、サクサク」 と、デスクトップ用のスタイルから設定していくと、最後のメディアクエリで設定を逆にしなければなりませんので、ご注意ください。（何を隠そう、この私です ）

また、これらの設定は、index.html の次のメタタグと対になっていることを覚えておくと吉です。

[html]
<meta name=”viewport” content=”width=device-width,initial-scale=1″>
[/html]

参考情報1

• 2011年2月4日 モバイルファースト » 市場のお手入れ
• 2011年3月18日 allWebクリエイター塾 ブログ :「モバイルファースト」って何だ
• 2011年6月17日 アップルとマイクロソフトが採用をはじめた“モバイルファースト”とは？ | Web担当者Forum

参考情報2

メディアクエリや viewport の設定について参考になりそうな記事を下に挙げますが、本記事で紹介している デザイン原則 と異なる趣旨で説明されているものを含みますので、ご注意下さい。

• 2010年8月20日 CSS3のMedia Queries（メディアクエリ）の使い方と実装例
• 2010年10月12日 Media Queries（メディア クエリ）を使用したデバイスごとの指定方法のまとめ
• 2011年5月30日 スマフォ対応サイトのためにMedia Queriesをしっかり身につけるチュートリアル
• 2011年7月13日 CSS3 Media Queries を使って、Webサイトをスマートフォンに対応させるときの注意書き
• 2011年8月16日 スマートフォン・デスクトップなど要件に合わせたMedia Queriesの実装方法のまとめ
• 2011年10月24日 iPadの横向きと縦向きでレイアウトを変更するスタイルシート

2.レスポンシブ・デザイン

前章の モバイル・ファースト のデザイン原則を支え、様々な大きさのデバイスに最適なユーザー・エクスペリエンスを提供するために必要不可欠な原則です。ただし、古い IE などメディアクエリを解釈しないブラウザへの対応が必要で、HTML5 Boilerplate では Respond.js を採用して対応しています。

Respond.js は、HTML5 Boilerplate では js/libs/modernizr-2.0.6.min.js に組み込まれ、HTTP リクエストの削減を図っています （Initializr 2 では単独の js/libs/respond.min.js です）。

さてこういった仕組みもさることながら、レスポンシブ・デザインで重要なのは、デバイスに合わせて最適なサイズの画像を提供することではないかと思います。モバイル用デバイスの通信速度はデスクトップ環境のそれに比べ、まだ十分とは言えない状況にあります。デスクトップ用画像をそのままモバイル端末に食わせ、スタイル設定で縮小表示しているようではベストプラクティスとは言えません。

かといって各デバイス用に異なる大きさの画像を用意しておくのも大変です。そこで、PHP と JavaScript でこの問題に対応するスクリプトを 参考情報3 に紹介しておきます。

参考情報3

• 2011年9月2日 スマートフォン・デスクトップそれぞれに最適な画像を表示する -Adaptive Image
• Simple-RESS | Responsive Design + Server Side Components

3.プログレッシブ・エンハンスメント

最新のブラウザには最新のテクノロジを使ったコンテンツを提供し、そうでないブラウザにもそこそこのコンテンツを提供する、ちょっと乱暴な言い方ですが、プログレッシブ・エンハンスメント はそんな考え方です。

これを実現させるために HTML5 Boilerplate では、Modernizr を取り入れています。参考情報4 に Modernizr の典型的な使い方がありますので、参考にして下さい。

ここでは、バージョン2から取り込まれた yepnope.js の条件付き非同期ローディングを使い、CSS3 の box-shadow に対応する例を示しておきます。Modernizr が 他の非同期ローダー ではなく yepnope.js を選んだ理由は、こういう使い方を想定してのことだと思います。

[html]
<script>
Modernizr.load({
test: Modernizr.boxshadow, // box-shadow が使えるかテストし、
nope: “path/to/PIE.js”, // 使えなければ PIE.js を読み込み
complete: function() { // 読み込みが完了したら実行する
$(’適用するタグとかクラスとか’).each(function() {
PIE.attach(this);
});
}
});
</script>
[/html]

（注：PIE.js で CSS3 に対応する方法は、本家の CSS3 PIE では推奨されていません。良い例が思い付かなくてすみません ）

参考情報4

• 2011年3月19日 絶対に使いたい、modernizr 2.0

4.論理的でクリーンなコード

index.html の先頭に、ひときわ目につくコンディショナル・コメントがあります （lang="en" は、lang="ja" に変えましょう）。

[html]
<!–[if lt IE 7]><html class=”no-js ie6 oldie” lang=”en”><![endif]–>
<!–[if IE 7]> <html class=”no-js ie7 oldie” lang=”en”><![endif]–>
<!–[if IE 8]> <html class=”no-js ie8 oldie” lang=”en”><![endif]–>
<!–[if gt IE 8]><!–> <html class=”no-js” lang=”en”><!–<![endif]–>
[/html]

これは従来の CSS ハックや、ただでさえ遅い IE に追加のスタイルシートを読み込ませる、次のようなコンディショナル・コメントを駆逐するものです。

[html]
<link rel=”stylesheet” type=”text/css” media=”screen” href=”css/style.css” />
<!–[if IE 7]><link rel=”stylesheet” type=”text/css” media=”screen” href=”css/ie7.css” /><![endif]–>
<!–[if IE 6]><link rel=”stylesheet” type=”text/css” media=”screen” href=”css/ie6.css” /><![endif]–>
[/html]

Paul Irish が提唱する使い方 は、次のようになります。

[html]
div.foo { color: inherit;}
.ie6 div.foo { color: #ff8000; }
[/html]

このようにすれば、CSS ハックを使わず Valid なスタイルシートが出来上がりますネ。

さて、こういった IE に対する手厚い扱いは、次のようなマークアップにも表れています。

[html]
<meta http-equiv=”X-UA-Compatible” content=”IE=edge,chrome=1″>
[/html]

上記メタタグにより、複雑怪奇な IE の動作モードを、常にもっとも問題の少ない 最新モード にし、また可能であれば Chrome Frame を動作させます。

[html]
<!–[if lt IE 7 ]>
<script src=”//ajax.googleapis.com/ajax/libs/chrome-frame/1.0.3/CFInstall.min.js”></script>
<script>window.attachEvent(’onload’,function(){CFInstall.check({mode:’overlay’})})</script>
<![endif]–>
[/html]

上記は、IE6 に対して、右のような Google Chrome Frame のインストールを促すポップアップを表示するスクリプトです。

ちなみに、X-UA-Compatible のメタタグは、HTML5 Boilerplate に同梱されている .htaccess の設定を用いれば index.html からは削除することができます。

何だかこの章は、「IE に対する特別待遇」 というタイトルがピッタリの内容ですが、あくまでも本来的な 目的 を原則としてみました 。

5.プログレッシブ・レンダリング

プログレッシブ・レンダリング を簡単に言えば、「イニシャル・ペイロード （ページを読み込みの初期負荷） を最小にし、かつ主要な要素から可能な限り早期に描画を行わせることにより、ユーザーが感じるサイト速度の向上を目指すこと」 です。

この原則は、Modernizr と他のスクリプトの読み込み位置の違いに端的に表れています。

[html]
…
<script src=”js/libs/modernizr-2.0.6.min.js”></script>
</head>
<body>
…
<script src=”//ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js”></script>
…
</body>
</html>
[/html]

つまり、Modernizr はレンダリングが開始される前までに実行されていなければならず、単に Put Scripts at the Bottom や Defer loading of JavaScript に従ってしまうと、レスポンシブな機能が働かなくなるので注意しましょう。

ところで、最初に読み込まれる Modernizr が CDN にアップされているともっとウレシイと思いませんか？ 実は、CloudFlare がスポンサーの CDN にあります！

http://cdnjs.cloudflare.com/ajax/libs/modernizr/2.0.6/modernizr.min.js

Microsoft の CDN にも登録されています が、minify 版ではないので、デバッグ時などに使うにとどめるのが良いでしょう。

最後に、この原則に関する他のベストプラクティスを 参考情報5 に挙げました。色々コマゴマとありますネ。

参考情報5

• Princeton
  • 2007年10月25日 How Design Affects Performance : Progressive Rendering
• Stoyan Stefanov
  • 2009年12月21日 Progressive rendering via multiple flushes
  • 2010年10月25日 Progressive Downloads and Rendering – take #2
  • 2010年10月19日 Progressive Downloads and Rendering | Fronteers 2010
• Steve Souders
  • 2010年10月12日 Web Directions South – Even Faster Web Sites
  • 2011年5月11日 Even faster web sites – JSDay2011

まとめ

Web パフォーマンスに関するベストプラクティスが凝縮されているという HTML5 Boilerplate を、近年の技術トレンドに照らし合わせて、その中身を具体的に追いかけてみました。もちろんテンプレートという性質上、それ自体は単なる出発点でしかありません。そこにコンテンツを構築するためには、さらに細かなベストプラクティスを積み重ねていかなければならないでしょう。

しかし、基本的な原則を知った上でその仕組みをうまく活用していけば、それこそ 「簡単に、サクサクと」 スジの良いページを作ることができ、よりコンテンツ（中身）の制作に集中できるのではないかと思います。

おまけ

HTML5 Boilerplate と Initializr 2 の index.html を比較してみると、それぞれに考え方の違いがあるようです。

HTML5 Boilerplate

<header> ～ <footer> までが、container で囲まれています。

[html]
</head>
<body>
<div id=”container”>
<header>

</header>
<div id=”main” role=”main”>

</div>
<footer>

</footer>
</div> <!–! end of #container –>
…
</body>
</html>
[/html]

Initializr 2

全体を囲むラッパーはなく、<header>、<article>、<footer> が個別のブロックで構成されています。

[html]
</head>
<body>
<div id=”header-container”>
<header class=”wrapper”>
<nav> … </nav>
</header>
</div>
<div id=”main” class=”wrapper”>
<aside> … </aside>
<article>
<header> … </header>

<footer> … </footer>
</article>
</div>
<div id=”footer-container”>
<footer class=”wrapper”>
</footer>
</div>
…
</body>
</html>
[/html]

パフォーマンス上に違いは無く、単に好みの問題だとは思いますが…。私は後者の方が好きです。なぜなら、既に <body> ～ </body> で囲われているって考える方が自然に思えるからです。

参考情報6

• 2010年3月31日 How to Centre and Layout Pages Without a Wrapper

「CSS/JavaScriptのAsynchronous Loadingをめぐる熱い論議」 でも書きましたが、スクリプトの非同期読み込みは、Google Analytics のコードスニペット で一応の決着を見た感じで （実は、標準化を巡って第2ラウンドが始まってはいますが…）、今や Google+1 はもちろん、Facebook も同様の手法を推奨しています。

調べてみたら、「それなら Twitter のスクリプトだって同じように読めばいいじゃないか」 という感じでどんどん まとめスクリプト の改良が進んできたようです。

我が日本としてはこれに 「はてな」 を加えるしかない！、ということで作ってみましたので、公開したいと思います。

背景と経緯

事の発端は、冒頭の normalize.css の作者であり HTML5 Boilerplate の開発者でもある Nicolas Gallagher が2011年6月 Gist に投稿した 次のスクリプト です。

[javascript]
(function(d,e){
var u = [
('https:'==location.protocol?'//ssl':'//www')+'.google-analytics.com/ga.js', // Google Analytics
'https://apis.google.com/js/plusone.js', // Google +1 Button
'//connect.facebook.net/en_US/all.js' // Facebook JS SDK
],
f = d.createDocumentFragment(),
s = d.createElement(e),
t = d.getElementsByTagName(e)[0],
i = u.length,
z;

while(i–){
z = s.cloneNode(true);
z.src = u[i];
z.async = 1;
f.appendChild(z);
}

t.parentNode.insertBefore(f,t);
}(document,’script’));
[/javascript]

その日のうちに、同じく HTML5 Boilerplate 開発メンバーでもある Mathias Bynens が乱入し、コードが洗練されていきました。彼は、2010年4月のブログ記事 「Optimizing the asynchronous Google Analytics snippet」 で、Google Analytics のコードスニペットに関して、これでもかというぐらいに無駄なコードをそぎ落とす記事を書いていますので、この手のスクリプトにかけては造詣が深いのです。

ただこの時点ではまだ、Google Analytics、Google +1、Facebook の3つだけが非同期読み込みの対象でした。

一方、Object-Oriented JavaScript の著者である Stoyan Stefanov は、2011年9月にブログ記事 「Social button BFFs」 で類似のスクリプトを発表しました。おもしろいことに彼は、Google Analytics は対象とせず、Facebook、Google +1、Twitter を対象としています。

そこに先の Mathias が乱入し、再び Gallagher にフィードバックされ、2011年10月に出来上がったのが次のスクリプトです。Google Analytics はもちろん、Facebook、Google +1、Twitter の4つが統合されました。

[javascript]
/*
* Updated to use the function-based method described in http://www.phpied.com/social-button-bffs/
* but retaining the use of a document fragment to minimise the number of times objects are
* written to the DOM. Also, better handling of scripts without supplied ids.
*
* N.B. Be sure to include Google Analytics’s _gaq and Facebook’s fbAsyncInit prior to this function.
*/

(function(doc, script) {
var js,
fjs = doc.getElementsByTagName(script)[0],
frag = doc.createDocumentFragment(),
add = function(url, id) {
if (doc.getElementById(id)) {return;}
js = doc.createElement(script);
js.src = url;
js.id = id || null;
frag.appendChild( js );
};

// Google Analytics
add((’https:’ == location.protocol ? ‘//ssl’ : ‘//www’) + ‘.google-analytics.com/ga.js’, ‘ga’);
// Google+ button
add(’https://apis.google.com/js/plusone.js’);
// Facebook SDK
add(’//connect.facebook.net/en_US/all.js’, ‘facebook-jssdk’);
// Twitter SDK
add(’//platform.twitter.com/widgets.js’);

fjs.parentNode.insertBefore(frag, fjs);
}(document, ’script’));
[/javascript]

上記以外にも、似たような時期に類似の話題が出ていたのを拾ってみました。興味があれば読んでみて下さい。

• 2011年7月12日 javascript – is it possible to unite several async social button loaders into one? – Stack Overflow
• 2011年7月22日 GoogleAnalyticsで+1やTwitter、Facebookのソーシャルトラッキングを行う方法｜caraldo.net | WebとiPhoneとロードバイクが大好き！

「はてな」を加えたスクリプト

先のスクリプトを元に、Google +1 への日本語設定と、はてなブックマークボタンを加え、またコード自体も Clusure Compiler を通して最適化した後、jsfiddle の JSLint が通る程度には整形してみました。

[html]
<script>
(function(w,d){
w._gaq=[["_setAccount","UA-XXXXXXXX-X"],["_trackPageview"]];
w.___gcfg={lang:”ja”};
var c,e=d.createDocumentFragment(),f=d.getElementsByTagName(”script”)[0],
a=function(a,b){if(!d.getElementById(b)){c=d.createElement(”script”);
c.src=a;c.id=b||null;c.async=true;e.appendChild(c);}};
a((”https:”==location.protocol?”//ssl”:”//www”)+”.google-analytics.com/ga.js”);
a(”https://apis.google.com/js/plusone.js”);
a(”//b.st-hatena.com/js/bookmark_button_wo_al.js”);
a(”//platform.twitter.com/widgets.js”);
a(”//connect.facebook.net/ja_JP/all.js#xfbml=1″,”facebook-jssdk”);
f.parentNode.insertBefore(e,f);
})(this,document);
</script>
[/html]

UA-XXXXXXXX-X の部分は、トラッキングコードの ID を設定します。他の箇所にトラッキングコードを仕掛けている場合には、この行は削除し従来の設定を使用します。また、スクリプト以外の構成要素は、次のサンプルを参照してください。

各ソーシャルサービスとも複数の実装方法を提供しているため、従来はページの中が乱雑になりがちでしたが、これで少しはすっきりとするのではないでしょうか？

また、公式サイトの設置方法通りでは得られない、このスクリプトのメリットは次の2つとなります。

• Twitter が非同期読み込みになる
• はてなでは HTML5 対応のブラウザのみ非同期読み込みになっているが、IE8 以下でも速度向上が期待できる

おまけ：ソーシャルボタンの公式サイト設置方法まとめ

今回の記事を作成するに当たり、参考とした公式サイトの解説ページをまとめておきます。各ボタンとも、幾つかのオプションがありますので、参考にしてください。

• Twitter / ツイートボタン
  • Web サイト上にツィートボタンを設定するスクリプトを生成してくれるページです。各パラメータの詳細な解説が、「Tweet Button | Twitter Developers」 にあります。
• Like Button – Facebook開発者
  • Like ボタンを設置するためのスクリプトを生成したり、各パラメータの解説をしてくれるページです。oklahomer さんの日本語訳「Like Button : Facebook開発者向けドキュメントの日本語訳とTips」 がイイ感じです。
• プラスワン ボタン
  • +1 ボタンをサイトに設置するためのスクリプトを生成してくれますが、なんだか 「英語版」 の方が非同期スクリプトなんかも表示してくれて、イイ感じです。 ← 日本語版も非同期コードに更新されました！ またパラメータの詳細な解説が、「+1 Button – Google+ Platform – Google Developers」 にあります。
• Google アナリティクス – Google Code
  • トラッキングコードを設置するためのスタートページです。具体的なトラッキングコードは、「サイト アクティビティのトラッキング – Google アナリティクス – Google Code」 にあります。また、トラッカーの内部オブジェクトやメソッドの詳細な解説が 「Google Analytics トラッキング コード – Google アナリティクス – Google Code」 にあります。
• はてなブックマークボタンの作成・設置について
  • 必要な事項を入力していくと、ボタンを設置するためのコードを生成してくれます。どんなパラメータが使用可能かを知るには、色々入力してみるとよいでしょう。また、クッキーによる追跡を行わないバージョンが 「オプトアウト版はてなブックマークボタン」 に、その解説が 「行動情報の取得について」 にあります。

README がキチッと書かれているプロジェクトって、どんなに小さくても立派に見えますよネ。

GitHub の場合、大抵はマークダウン記法で書かれた README.md とか README.markdown とかいう名前のファイルが、HTML に変換 （マークアップ） されて表示されていることはご存知でしょう。

マークダウン記法自体はとても簡単なのですが、GitHub では GitHub Flavored Markdown （略して GFM） という GitHub 用にアレンジされたマークダウン・エンジンが採用されていて、一般のマークダウン・エディタでチェックしてからコミットしても、意図通りの見た目にならないことが多々あります。私 （もちろん GitHub 初心者です！） の場合、README ファイルだけで10回以上もコミットしてしまいました。「マークアップ （レンダリング） を気にして書くマークダウン」 なんて、何ともナンセンスですよネ。

ということで、私の二の舞にならないよう、スマートに README ファイルをコミットする方法を共有してみたいと思います。

マークダウンのこころ

GFM のノウハウにいく前に、そもそもマークダウンの 「こころ」 を知っておくのが良いと思います。マークダウンの発案者 John Gruber 本人は、その哲学を次のように語っています。

マークダウンは、簡単に書けるということを重視しながらも、プレーンなテキストとしても読み易くするために、そこに使われる記号は、それ自体で何を意味しているかが分かるよう慎重に選ばれなければならない。

例えば強調を表すシンタックスは、単語をアスタリスクで囲い *強調する単語* と表したり、blockquote を表す引用は、電子メールでよく使われる > 引用する文章 といった具合です。

マークダウンのシンタックスには、合計で11個の基本構成要素 （段落、改行、見出し、強調、リスト、引用、コード、リンク、画像、水平線、HTML タグ） が登場します。それぞれのシンタックスは非常に簡単なので、初めての方は一度、学習をしておくとよいでしょう。

お勧めの文献

• Markdown – Wikipedia
  • HTML タグを除く10個の要素がシンプルに解説されています。まずこちらを読んでから、本家の解説を読むのがお勧めです。
• Markdown文法の全訳
  • John Gruber による文法解説の日本語訳です。
• Syntax Guideの日本語訳
  • Showdown というオンラインツールに付属する Syntax Guide が、本家の解説をさらに詳しく補ってくれます。ツール右上のリストから Syntax Guide を選択すると、右側ペインに表れます。

README.md作成のワークフロー

ローカル側で README.md を書きながらプレビューで確認し、OK となったらリモート側にコミットをプッシュする、というのを1つのワークフローとするなら、その方法は次のいずれかでしょう。

1. 一般的なマークダウン・エディタを使う
   • 参考情報 に挙げたように、世の中にはたくさんのマークダウン・エディタが存在します。しかし、私がハマったように、これらのエディタで OK だったからといって、GFM で OK になるとは限りません。やはりその方言を掴むまでは、GFM 専用のマークダウン・エンジンを探す方が良さそうです。
2. GFM のマークダウン・エンジンをローカルにインストールする
   • github/markup – GitHub に情報がある通り、redcarpet をインストールすればよさそうなのですが、実はコレ、upskirt （現在では sundown という名前になっている模様） のラッパーだったりして、これらをひも解きながらのインストールは、初心者にはハードルが高いです。
3. GMF の Live Preview を使う
   • GitHub Flavored Markdown – Live Preview は、リアルタイムなプレビュー機能を持つオンライン・エディタなのですが、理解に苦しむほど性能が悪く （仕様が古い、多分）、使えたものではありません。私はコレでもハマりました。
4. GitHub Wiki のマークダウン・エンジンを使う
   • 結局たどり着いた方法がコレです。ご存知の通り、Wiki もマークダウンを採用しています。GitHub の Wiki は、リポジトリ作成後にあらためて開設しなければなりませんが、一旦開設してしまえば、プレビュー機能はもちろん、GUI ベースのリッチ・エディタやヘルプまで付いた GFM 専用のマークダウン・エンジンが使えるようになります！

ということで、以下、GitHub Wiki を活用した README.md 作成のワークフローを提案してみたいと思います。

参考情報

• 2011年9月20日 オンラインマークダウンエディタいろいろ比較
  • 本家の Perl スクリプト Markdown: Dingus とマークアップ結果が （メールアドレスの難読化以外は） ぴったり一致する Showdown.js を用いた Online Markdown Editor が使い易いと思います（日本語バージョンは こちら）。
• 2011年10月2日 リアルタイムプレビューができるMarkdownエディタ『Mou』
  • Mac 用です。
• 2011年10月20日 リアルタイムプレビューにも対応、Markdown専用のエディター「MarkdownPad」
  • Windows 用です。

GitHub Wiki を活用したマークダウン作成のワークフロー

提案するのは、GitHub Wiki 上のリッチ・エディタを使ってマークダウンを作成、ローカル側の README.md ファイルにコピペするという方法で、次のようなステップで作業するのがよいと思います。

1. GitHub 用マイ・テンプレートを作成する
2. GitHub Wiki を開設する
3. GitHub マークダウンのヘルプを参照する
4. GitHub 独自のマークダウンを活用する
5. プッシュ後にちょっとだけ修正する

1.GitHub 用マイ・テンプレートを作成する

まずは、基本となる自分用のテンプレートを作っておくのが良いと思います。簡単なチュートリアルも兼ね、ほぼ10個の基本構成要素を入れた サンプル を作ってみましたので、参考にしてください。

[text]
プロジェクト・タイトル
======================
ここにプロジェクトの概要を書きます。
行末にスペースを2つ入れると
改行されます。

段落を分けるには、[空行](http://example.com/) を入れます。

使い方
——
### インライン ###
インラインのコードは、**バッククォート** (“ ` “) で囲みます。

### ブロックレベル ###
function f () {
alert(0); /* 先頭に4文字のスペース、
もしくはタブを挿入します */
}

パラメータの解説
—————-
リストの間に空行を挟むと、それぞれのリストに `<p>` タグが挿入され、行間が
広くなります。

def MyFunction(param1, param2, …)

+ `param1` :
_パラメータ1_ の説明

+ `param2` :
_パラメータ2_ の説明

関連情報
——–
### リンク、ネストしたリスト
1. [リンク1](http://example.com/ “リンクのタイトル”)
* 
2. [リンク2][link]
– [![画像2][image]](https://github.com/)

[link]: http://example.com/ “インデックス型のリンク”
[image]: http://github.com/github.png “インデックス型の画像”

### 引用、ネストした引用
> これは引用です。
>
> > スペースを挟んで `>` を重ねると、引用の中で引用ができますが、
> > GitHubの場合、1行前に空の引用が無いと、正しくマークアップされません。

ライセンス
———-
Copyright &copy; 2011 xxxxxx
Licensed under the [Apache License, Version 2.0][Apache]
Distributed under the [MIT License][mit].
Dual licensed under the [MIT license][MIT] and [GPL license][GPL].

[Apache]: http://www.apache.org/licenses/LICENSE-2.0
[MIT]: http://www.opensource.org/licenses/mit-license.php
[GPL]: http://www.gnu.org/licenses/gpl.html
[/text]

マークダウンでは、11個目の要素である HTML タグも使うことができます。例えば <table> や <dl><dt><dd> などを使いたいこともあるでしょう。その場合、次の3つの注意事項があります。

• <u> や <del> などのインライン要素中では、マークダウン記法が使える。
• ただし <font> は使えない。
• <div> などのブロック要素中では、マークダウン表記は無視される。

ただし 「マークダウンのこころ」 からは外れてしまうので、Wiki 以外では極力使わないようにしましょう。

2.GitHub Wiki を開設する

特に難しくはありませんが、Wiki の開設 〜 リッチ・エディタまでの概略を以下に示します。各リポジトリ毎に開設するのも手ですが、無料枠でのリソース消費を抑える意味も含め、マークダウン専用のリポジトリで Wiki を開設、前章のテンプレートを載せておくという手もあるかと思います。

3.GitHub マークダウンのヘルプを参照する

Wiki のリッチ・エディタで 「?」 を押すと、ヘルプを表示させることができます。基本構成要素の10個が、ブロック要素とインライン要素とに分けて参照することができます。

GitHub マークダウンは、README だけでなく、コメント欄でも使うことができます。GitHub のどのページでも良いので、キーボードの ‘m‘ を押してみましょう。使いたいときにいつでも呼び出せる、マークダウンのチートシートを表示させることができます。

余談ですが、’?‘ キーを押すと、ショートカット・キーのチートシートが表示できます。お試しあれ。

4.GitHub 独自のマークダウンを活用する

知ってるとちょっと GitHub 通を気取れる Tips です。

• コードブロックのハイライト

  • コードブロックを 「```lang」 ～ 「```」 で囲むと、指定の言語に合わせてハイライトされます。通常マークダウンでは、コードの先頭にスペース4つか1つのタブを挿入しますが、この記法を使うとブロックが丸ごとそのまま 「<pre><code>」 〜 「</code></pre>」 で囲われるため、余計な空白ができてしまいます。注意しましょう。

    また公式ドキュメントには lang に指定可能な言語の解説がないので何とも言えませんが、html、css、javascript、ruby、python などは指定可能なようです。

    [text]
    “`html
    <script type=”text/javascript” src=”jquery.min.js”></script>
    <script type=”text/javascript”>
    $(function() {
    alert($); /* 先頭に4文字のスペース、
    もしくはタブを挿入します */
    });
    </script>
    “`

    “`python
    def MyFunction(param, …)
    “`
    [/text]

    この機能を使うと、現状ではコメントなどの日本語が化けてしまいます。ユニコード化すれば回避できると思いますが、プレーンなテキストを見たときに何が書いてあるか分からなくなるので、日本語は避けましょう。

    

• issue リストへの自動リンク

  • 「#番号」 で、該当の issue リストへのリンクが自動的に生成されます。この機能は、README や Wiki ページでは働きませんが、コミット時や他のコメント欄では有効です。

    

5.プッシュ後にちょっとだけ修正する

前章までで、Wiki 上で作成したマークダウンがローカル側の README.md にコピペされコミット、GitHub 側のリポジトリにもプッシュされているものとします。その後ちょっと直したい／プレビューも確認したい、という時には、次のように GitHub 上で修正・確認をすることができます。

最後に git pull で、ローカル・リポジトリの更新も忘れずに。

速攻追記！

kei-s さんからハテぶ経由で、「よければご利用ください」 というコメントとともに、Github Preview をご紹介いただきました。このツールがまたすばらしい！ GFM と同じ redcarpet を使っていながら、Ajax でリアルタイムなプレビュー機能が実装されていて、作業効率が格段にアップします！ 私は速攻で、ブックマークに叩き込みました。kei-s さん、ありがとうございます！！

ちなみにこの Github Preview で、Github Wiki の Markdown エンジンが腐ってる件について – 永遠に未完成 にダメなケースとして挙っているパターンを再現させてみました。bar の先頭にスペースを4つ入れれば、正しく変換されます。私がハマっていたのは、正にこういうバッド・ノウハウ的な所です。詳しくは述べませんでしたが、もちろん冒頭のテンプレートにもこの手のノウハウは投入してあります。皆さんも試してみて下さい！

脱初心者を目指すなら、最後にもう1つ…

個人利用のマークダウンであればどのように書いても自由ですが、GitHub では、いつ誰に fork されてもよいように、1行に記述する文字数にも気を配りましょう。

かつて VT100 のようなキャラクター端末しかなかった時代は、80桁×24行の表示が一般的でした。それゆえドキュメントは1行の文字数が80桁に収まるように記されたものです。1920桁×1440行といった巨大なモニターさえ手に入る現代でも、プレーンなテキストファイルは、横スクロールしなくても読めるようにするのがココロ遣いと言うものでしょう。

「オッ、コイツできるな」 と思われること請け合いです 。

おまけ

今回の記事を作成するために、マークダウンの本家仕様と方言を幾つか調べていた中で見つけた、興味深い記事を紹介しておきます。本家仕様の曖昧さゆえ、色々とあるようです。

• 2008年6月24日 Three Markdown Gotchas
  • 書いた意図と違う変換がなされてしまうパターンが3つ指摘されています。
• 2009年10月15日 Markdown, One Year Later
  • 本家仕様と GFM や Stack Overflow のマークダウン仕様の違いが述べられています。
• 2009年10月23日 GitHub Flavored Markdown
  • John Gruber 本人が、本家仕様と GFM が異なる点を3つほど挙げています。具体的には GitHub Flavored Markdown – Introduction に記述がありますが、現在の GFM 仕様と多少違う （古い） 部分があるようです。

ほとんど jQuery バージョン 1.0 のルーチンを使っているので、古い jQuery でも動くと思います （1.3.2 までは動作することを確認をしています）。

ブラウザは、IE6 〜 8 (IETesterで）、IE9、Firefox 7、Chrome 15 （いつの間に！）、Safari 5 での動作を確認済みです。

プラグイン本体は、GitHub に上げました （MIT ライセンス）。良かったら使ってやって下さい。またバグなどの報告は、issues に挙げてもらうと助かります。

また、デモを jsdo.it に上げてありますので、ご覧ください。本記事では、使い方、オプションの解説と共に、ほんの少し中身についても書いておきますので、カスタマイズの参考にでもして下さい。

How to use ?

まずはウィジェットをラップするマークアップを書きます。ラッパーとなる要素には、高さを指定しておくのが吉です。

[html]
<div id=”ticker” style=”height:400px”></div>
[/html]

次にウィジェットの起動です。引数には、振る舞いを指定するオプションと、スタイルを設定するオプションを指定します。name 以外のオプションはすべてデフォルト値を持っていますので、必要なものだけを指定すれば OK です。

[javascript]
<script type=”text/javascript” src=”https://ajax.googleapis.com/ajax/libs/jquery/1.6.4/jquery.min.js”></script>
<script type=”text/javascript” src=”doticker.min.js”></script>
<script type=”text/javascript”>
$(function() {
$(”#ticker”).doticker({
// Behavior options
name: ‘tokkonopapa’,
loop: true,
maxCodes: 10,
interval: 6000,
scrollbar: false,
duration: ‘normal’,
// Style options
width: ‘auto’,
height: ‘300px’,
background: ‘#9bc6f2′,
bodyground: ‘#fff’,
bordercolor: ‘#888′
});
});
</script>
[/javascript]

Synopsys

$(”#some-element”).doticker({options, …})

各オプションの解説です （カッコ内はデフォルト値）。

name [ 必須 ]

jsdo.it のユーザー名を指定します。

loop [ true ]

一定間隔毎に表示を更新する場合には true を、一気に表示させるには false を指定します。

maxCodes [ 10 ]

表示するコードの最大数を指定します。

interval [ 6000 ]

表示を更新する間隔をミリ秒で指定します。

scrollbar [ false ]

スクロールバーを表示させる場合には true を指定します。

duration [ 'slow' ]

アニメーションの遷移時間をミリ秒、または 'slow'、'normal'、'fast' で指定します。

width [ 'auto' ]

横幅のスタイルを、px または 'auto'、'100%' （ラッパー要素の横幅に応じて中央に配置される）で指定します。

height [ '300px' ]

ウィジェットは上から順にヘッダー （ユーザー名が表示される部分）、ボディー （コードが紹介される部分）、フッター （jsdo.it へのリンク） の3つのブロックで構成されていますが、そのうちボディー部分の高さを px で指定します。ヘッダーおよびフッターは、横幅に合わせて高さが変わります。

background [ '9bc6f2' ]

ヘッダー、フッターの背景スタイルを設定します。書式は CSS の background プロパティと同じです。

bodyground [ '#fff' ]

ボディーの背景スタイルを設定します。書式は background と同じす。

bordercolor [ '#888' ]

ボディー中の各記事を区切る点線の色を指定します。

Plugin description

基本的には、起動時に1回だけ $.ajax で jsdo.it の API 経由でコード情報の書かれた jsonp を読み込み、表示をしているだけのスクリプトです。ここではそれ以外の部分についての情報を若干記しておきます。

スタイルの設定

外部スタイルシートを設置しなくてよいように、スタイル設定はすべてスクリプトに内蔵しており、下記コードによってページの <head> に <style> として挿入されます。いまどき、<head> のないブログはないと思いますので…

[html]
var e = document.createElement(’style’);
e.type = ‘text/css’;
if (e.styleSheet) {
e.styleSheet.cssText = s; /* IE */
} else {
e.innerHTML = s; /* 他のモダンブラウザ */
}
document.getElementsByTagName(”head”)[0].appendChild(e);
[/html]

アニメーションを始める前に…

コンテンツをある DOM 要素中に挿入し、アニメーションで表示するコードは次の様なものです。

[javascript]
var e = $(’#some-element’);
e.append(contents).hide().slideDown();
[/javascript]

しかし、このコードは場合によってはアニメ開始時と終了時の位置計算が合わずに飛んでしまうことがあります。この問題の回避策として、次のように、要素の高さを予め計算するコードを入れてあります。

[javascript]
var e = $(’#some-element’);
e.append(contents).height(e.height()); /* 高さを計算する */
e.hide().slideDown();
[/javascript]

参考情報

• Fixing jQuery’s slideDown() effect (i.e. Jumpy Animation)

アニメーションの種類

Twitter 公式ウィジェットのように、スライドダウン後に、フワッとフェードインする効果は、次のコードで出すことができます。

[javascript]
var e = $(’#some-element’);
e.height(elem.height()) /* 高さを計算する */
.hide()
.css({opacity: 0})
.slideDown()
.animate({opacity: 1});
[/javascript]

しかし、なぜか IE8 でアニメ終了時に文字の位置が微妙にずれるという現象が出ます。まだ細かな要素のサイズ計算が合っていないのかもしれません。問題が解決するまでは、単純なスライドダウンの実装にとどめておきたいと思います。

↑ この問題は、フォントを指定することで解決しました。アニメーションの開始時と終了時で、適用されるフォントスタイルが異なることが問題でした。

Wish list

ToDo リストではありません。誰かが fork して実装してくれるのを願いつつ、あったら良いと思うものを記しておきます。よいアイディア （コード） は取り込ませて頂きたいと思います！ （なんと他力本願な ）

• 滑らかなアニメーション。よく見ると、スライドダウンだけでもまだ飛んでいます。 ← アニメーションをさせるブロックの、親要素の padding 分だけ飛んでいましたので、padding がゼロになる様に構成し Fix しました （この問題は、前章で述べている 「高さを計算させる」 問題とは異なります）。
• 更新のインターバルの最中にコンテンツを DOM に挿入し、コードのサンプル画像をプリロードする。次の表示のときに、画像読み込み中のマークが出ないようにする。これがちゃんと機能すれば、アニメーションの問題も解決するかも。 ← 更新の毎に無駄な HTTP リクエストを発行しないように修正しました。
• jQuery Plugin Boilerplate を参考に、ビシッとしたプラグインにする。
• 人気順にコードを表示する機能なんかあったら良いと思いません？ でもこれはサーバーサイドでやった方が良いかもしれませんネ。WordPress のプラグインとか。

変更履歴

2011年10月26日 v0.9.0

初版公開。

2011年10月27日 v0.9.1

滑らかなアニメーションのために、CSS の構成を変更しました。

2011年10月28日 v0.9.2

アニメーション終了時にボーダーが消える問題を修正しました。

2011年10月29日 v1.0.0

キャプチャ画像のプリロードに対応しました。

2011年11月3日 v1.0.1

IE8 と SyntaxHightlighter の組み合わせで起きる 「オブジェクトでサポートされていないプロパティまたはメソッドです」 のエラーを回避するため、opacity によるフェードイン効果を止めました。

さて今もそんなニーズがあるのかわかりませんが、jQuery Plugins にそんな思いを実現してくれる jqIpLocation というプラグインが紹介されていたので、試してみました。

実はこのプラグイン、IPInfoDB が無料で提供する DB サービスを利用して、IP アドレスからアクセスポイントの位置情報を引っ張ってきます。他にも同様のサービスがありましたので、そういった情報も共有してみたいと思います。

jqIpLocation

IP アドレスを指定すると、IPInfoDB の DB から $.getJSON() で国情報、国コード、都市名、地域名、緯度経度を引っ張ってくる簡単なラッパーとなっています。本家のデモ もあるのですが、（jQuery 1.5 から） $.getJSON() は jqXHR オブジェクト を Deferred オブジェクト でラップして返すので、これを活用したサンプルを作ってみました。

CCV.js （C-based Computer Vision Library） は、オープンソースな画像処理ライブラリ OpenCV の純粋なアルゴリズム部分を一部 JavaScript に移植したライブラリです。しかも元のライブラリではかなりの仮想化・階層化されていた画像処理用メモリ管理部分を簡素化し、Canvas で扱えるようにしてありますので、現在のモダンブラウザでも動作する軽量なライブラリとなっています。

ライブラリとはいうものの、現時点はまだ物体検出のアルゴリズムしか移植されていないようなのですが、顔検出のサンプルがありましたので試してみました。

サンプル

JavaScriptライブラリの中身

ccv を GitHub から落とすと、js ディレクトリに顔検出のサンプルが入っています。ccv.js には Canvas を画像処理用メモリとして扱うためのコア部分と、物体検出処理を呼び出すための API が実装されています。また軽量とはいえ、画像が大きくなるとそれなりに処理時間がかかるため、Web Worker で処理させるための API もあります。

顔検出部分は face.js に実装されていますが、プログラムというよりパラメータの固まりです。というのも、物体検出としていわゆる 機械学習 のアルゴリズムが用いられており、face.js は顔検出用に学習されたパラメータのセットとなっているからです。

とはいえ、OpenCV の顔検出用サンプルコードに添付されている学習済みパラメータセット haarcascade_frontalface_default.xml とも中身が異なるので、アルゴリズムが違うのかもしれません （詳しい方にフォローして頂けると助かります ）。

ただし、世の中ではあたかも JavaScript による顔検出がすぐに使える、完成した技術として紹介されている気がしてなりません（本エントリーもそのように受け止められるかもしれません） が、OpenCV に添付されている学習セットは正面を向いた顔用の単なるサンプルに過ぎませんし、事実 CCV.js も、どんな顔でも検出できると言うわけではなく、かなり限定された性能を示します。

いずれにしても物体検出の性能はこの 「学習」 の過程にかなり依存しますので、今後、強化された学習セットや、車や人を検出する学習セット、あるいは笑顔や我が子を検出する学習セットなどが出現してくれば、Web アプリケーションの幅がさらに広がる、そんな可能性を秘めているのではないかと思います。

応用

Canvas で画像処理が出来るのなら、HTML5/Video タグから映像を Canvas に取り込んでリアルタイムに顔検出して、さらに遊んじゃおうという強者がいましたので、紹介します。

Video から映像データを Canvas に取り込むスクリプトは、本サイトの記事 「Canvasを使ったグロー効果が幻想的!!HTML5/Videoタグ用jQuery Plugin」 でも紹介した通りそれほど難しくはありませんし、顔の検出結果を赤枠で囲う代わりにヒゲメガネをオーバーレイしただけの他愛もないものですが、「変装できるビデオチャット」 なんてアプリもまた一興かと思います 。

作者は将来、ビデオストリームをリアルタイムで処理するソフトを作ると言っているので、そのうちそんなアプリにお目にかかれるかもしれませんネ 。

参考情報

OpenCV の顔検出はかなり有名で、ちょっと検索すれば優れたリソースを多数見つけることが出来きます。ここでは本記事で紹介した文脈につながり、かつ分かり易く解説してくれている情報を掲載しておきます。

• OpenCVで学ぶ画像認識：第3回　オブジェクト検出してみよう｜gihyo.jp … 技術評論社
• opencv.jp – OpenCV: 物体検出（Object Detection）サンプルコード -
• ブースティング – Wikipedia

追記

今気づいたんですが、このネタって１年ぐらい前に話題になった Badass JavaScript の Face Detection in JavaScript via HTML5 Canvas と同じだったんですネ。当時はライブラリへのリンクが切れていたので、てっきり別物かと思ってしまいました。既出ネタですみません 。

ご存知の方も多いと思いますが、jQuery には .data() や jQuery.data() という、DOM 要素に データ を紐付けて記憶しておく仕組みが元々ありました。jQuery 1.4.3 からは、 API レベルでの 親和性 が考慮された形で HTML5 data-* 属性を取り込む仕様が導入されました。

HTML5 時代では、クライアント・サイドで実行されるコード量も増え、データ属性を扱う機会もちょくちょく出てくるのではないでしょうか。そこで今回は、

1. HTML5 data-* 属性のおさらい
2. jQuery Data API の経緯
3. jQuery Data API と HTML5 data-* 属性の共通点と違いまとめ

といった順にまとめておきたいと思います。

1.HTML5 data-* 属性のおさらい

W3C ドラフト で、ポイントとなる仕様は次の2つでしょう。

• data-* 属性は HTML 要素中の id や title、class といったグローバル属性中の、カスタム属性に位置づけられます。従って * に使える文字は HTML 要素の定義に準じます。（注）
• JavaScript から DOM 要素を通してアクセスする方法は次の2通りです。
  • Attribute 関連の関数によるアクセス ： getAttribute()、setAttribute()、hasAttribute() 等に、属性名をそのまま文字列として指定します。
  • dataset IDL 属性 によるアクセス ： 先頭の data- を取り除き、-（ハイフン）で分割した単語をキャメル・ケース化（先頭文字を大文字に）してつなげ、dataset の子要素としてアクセスします。

注 ： 正確には :（セミコロン）と英大文字を除く XML-compatible、かつ最初の3文字が xml であってはならないというのが定義です。XML-compatible な文字 とは、先頭が英文字または _（アンダースコア）で始まり、2文字目以降が -（ハイフン）と .（ピリオド）を含む英数字 （さらにいくつかの Unicode文字 を含む） です。ただし .（ピリオド）を含めてしまうと、dataset を介した際におかしくなるので、やめた方が良いでしょう。

具体例

次の様な HTML に対し、

[html]
<div id=’test’ data-foo-bar=’hoge’></div>
[/html]

データ属性にアクセスする方法は以下の通りです。

[javascript]
var e = document.getElementById(’test’);
console.log(e.getAttribute(’data-foo-bar’));
console.log(e.dataset.fooBar);
[/javascript]

う～ん、キャメル・ケース化とかややこしいですよネ。HTML 要素の定義と DOM 要素の定義の両面を満足させる、苦肉の策って感じです 。

2.jQuery Data API の経緯

2008年2月7日、jQuery 1.2.3 で初めて jQuery.data() および jQuery.fn.data() が公開されました。DOM 要素に 何らかのデータ を紐付たいというニーズは昔からあったのでしょう。キーとオブジェクト （文字列、数値、配列、関数など） をペアにして、特定の DOM に紐付ることができます。そもそもは、（文法的には間違いだが） HTML 要素の何かしらの不可視属性に （文字列の） データを埋め込こんだとき、うかつに DOM を操作すると IE がメモリー・リークを起こすという不具合があったため、jQuery で DOM を操作している限りはそういった問題が起きないようにするためだったようです。

さらに jQuery 1.4.3 では、HTML5 data-* 属性の属性名をキーとして指定すると、その属性値を jQuery 内のキャッシュに オブジェクトとしてコピーする という仕様が取り入れられました。例えば

[html]
<div data-text=’hoge’ data-boolean=’true’ data-object-value=’{”name”:”John”}’></div>
[/html]

に対し、次が成立します。

[javascript]
$(’div’).data(’text’) === ‘hoge’;
$(’div’).data(’boolean’) === true;
$(’div’).data(’objectValue’).name === ‘John’;
$(’div’).data(’object-value’).name === ‘John’; // この書式はHTML5と違う
[/javascript]

つまり、dataset を介してアクセスする時のルールとほぼ同じです （キャメル・ケースの仕様が正しく実装された のは jQuery 1.6 からです）。

気を付けるべきは、一旦コピーされた HTML5 データ属性は、元の値 （こちらは単なる文字列で、相変わらず HTML 要素上に存在しています） とは独立に評価され、それぞれの型を持つオブジェクトになるという点です。つまり、

[html]
<div data-value=’1e3′></div>
[/html]

に対しては、1e3 が浮動小数点として評価されることになります。

[javascript]
console.log(typeof $(’div’).data(’value’)); // ‘number’
[/javascript]

もしコピーされたキャッシュではなく、元のデータ属性自体にアクセスしたいのであれば、jQuery.fn.attr() を使う必要があります （結果は文字列となります）。使い方は、ネイティブな関数 getAttribute()、setAttribute() などと同様です。

3.jQuery Data API と HTML5 data-* 属性の共通点と違いまとめ

それぞれに都合や経緯があるのは 致し方ない ことですが、意識した上でなるべく混乱のないように使うべきです。もっとも、割り切って両者は違うものと考えるのも手ですが…。

共通点

はっきり言って HTML 要素から data-* 属性の値を読み出す時のルールだけです。

[html]
<div id=’test’ data-foo-bar=’hoge’></div>
[/html]

[javascript]
var p = document.getElementById(’test’);
var q = $(’#test’);
console.log(p.getAttribute(’data-foo-bar’));
console.log(q.attr(’data-foo-bar’));
console.log(p.dataset.fooBar);
console.log(q.data(’fooBar’));
[/javascript]

相違点

データを紐付ける対象が違うってことと、jQuery の場合、データ属性への最初のアクセス以降は、HTML （あるいは DOM） 要素とは独立に jQuery 内部にデータを格納するってところが最大のポイントだと思います。

属性名の命名規則について

HTML5 データ属性名にどんな文字が使えるか、幾つかのパターンを試してみました。その結果、混乱をなくすためには

アルファベット小文字で始まり、アルファベット小文字と数字からなる文字列を - （ハイフン） でつなげる

がよろしいかと思います （要は、小文字の変数名をハイフンでつなげるって感じ）。

参考までに jsdo.it で試したスクリプト を置いておきます。あるタグに W3C の定義に則った data-* カスタム属性を定義し、それぞれの方法で読み出します。スクリプトのいい加減さは、ご勘弁を。

参考情報

• Embedding custom non-visible data with the data-* attributes
  • W3C の HTML5 data-* 属性のドラフトです。
• .data() – jQuery API
  • jQuery Data API のマニュアルです。
• jQuery.data() – jQuery API
  • jQuery Data API のマニュアルです。.data() に対しては、下位関数の位置づけですが、その分高速に動作します。
• 2011年9月2日 Using jQuery’s Data APIs
  • jQuery Data API と HTML5 data-* 属性の違いや 混乱を防ぐためのシンプルなルール を解説してくれています。
• 2011年2月22日 jQuery を使用し、DOM に基づいてデータを格納、取得する
  • 私のこのエントリーがなくても、コレを読めば全てわかる、ってぐらいの記事です。