Macでのやり方はこちら
Help.GitHub – Set Up Git

SSH keyを登録するところがキモだが、コマンドまで全てちゃんとヘルプに書いてあるのでつまずいたところはなかった。拍子抜け。

最初に作ってみたレポジトリがこれ。
seckie/jQuery.ui.vScroll – GitHub

今年の春に作ったものだけど、今また案件で使う必要があって引っ張り出したら無駄なところがあったりしてちょっといじることになった。案件の制作物は当然会社のレポジトリに置くんだけど、これは個人的に作ったものだったりしたので、せっかくなのでGitHubに挑戦してみた。

第10章の内容について、議論の対象となった部分を引用する。

10.3 変数の初期化のガイドライン

変数は最初に使用する場所の近くで初期化する

リスト10-2: 悪い初期化（Visual Basic）

' すべての変数を宣言する
Dim accountIndex As Integer
Dim total As Double
Dim done As Boolean

' すべての変数を初期化する
acountIndex = 0;
total = 0.0
done = False
...

' accountIndexを使用するコード
...

' totalを使用するコード
...

' doneを使用するコード
While Not done
...

…中略

リスト10-2の例では、done変数を宣言した後、done変数を使用するコードが実行されるまでに、done変数が変更される可能性がある。

…中略

もう1つの問題は、すべての初期化を1か所にまとめると、done変数は最後の方でしか使用されないにもかかわらず、すべての変数がルーチン全体で使用されるという印象を与えることだ。

…中略

これは、「関連する作業を1つにまとめる」という近接の法則の一例である。

なるほどなるほど。しかし僕は普段の業務でプログラミング言語らしきものはJavaScriptしか使わないので、JavaScriptに置き換えて考えよう。

var accountIndex = 0,
    total = 0,
    done = false;
// accountIndexを使用するコード
...

// totalを使用するコード
...

// doneを使用するコード
while(!done) {
    
}
...

これが本書で「悪い例」とされているコードをJavaScriptに置き換えたコードだ。しかし関数の先頭で var hoge = 0, fuga = false; のようにして変数をまとめて宣言（＆初期化）するのはJavaScriptではよく見られるコードだ。あのjQueryですらそのような記法を多用している。
JavaScript: The Good Partsによると

ほとんどの言語では、変数は一般的に最初に利用される場所で定義するのが最も良い方法だ。しかしこれは、ブロックスコープを持たないJavaScriptでは好ましくない。すべての変数は、それぞれの関数の先頭で定義したほうが良い。

とある。そう、JavaScriptはブロックスコープを持たない（{}でくくられた部分限定の変数スコープ）といういわゆる変態言語であり、変数のスコープを生成するのは関数ブロックのみだ。それが理由で、変数はまとめて関数の先頭で宣言するという記法がベストプラクティスとされている。

さてしかし、Code Complete第2版による「変数は最初に使用する場所の近くで初期化する」ほうがよいという理屈の続きはこうだ。

10.4.1 変数の参照はまとめて

変数を参照してから次に参照するまでのコードは、「脆弱性の窓」（無防備な時間帯）である。その窓では、新しいコードが追加されたり、何気なく変数が変更されたり、変数に含まれていなければならない値が忘れられてしまったりする。変数の参照は、常に近いところにまとめて局所化するのが望ましい。

…中略

これを測定する方法は、変数の「持続間隔」を計算することである。

…中略

リスト10-6: 1と0の持続間隔（Java）

a = 0;
b = 0;
c = 0;
b = a + 1;
b = b / c;

この場合、bの1つ目の参照と2つ目の参照の間にコードが1行あるので、その持続間隔は1である。bの2つ目の参照と3つ目の参照の間にはコードがないので、その持続間隔は1である。bの2つ目の参照と3つ目の参照の間にはコードがないので、その持続間隔は0である。

…中略

リスト10-6では、bの平均持続間隔は (1 + 0) / 2 = 0.5 である。変数の参照を近くにまとめると、コードの読み手がコードをセクションごとに読んでいけるようになる。

…中略

10.4.2 変数の「寿命」はできるだけ短く

変数の持続間隔に関連して、変数の「寿命」という概念がある。変数の寿命とは、変数が存続する期間内に存在するステートメントの合計である。

…中略

変数の持続間隔とは異なり、変数の寿命は、最初に参照されてから最後に参照されるまでの変数の使用回数を計算に入れない。変数が最初に1行目で参照され、最後に25行目で参照された場合、変数の寿命は25（ステートメント）である。

…中略

変数の持続間隔と同様に、変数の寿命もできるだけ短くする、つまりステートメントの数を少なくすることが目標となる。持続間隔と同様に、ステートメントの数を少なくすると、脆弱性の窓が小さくなるという利点がある。

…中略

寿命を短くするもう1つの利点は、コードを正確に把握できることである。変数に10行目で値を代入し、45行目まで使用しない場合、2つの参照の間に空いている空間は、変数がその間に使用されていることを暗示する。

…中略

変数の寿命が短いと、コードが読みやすくなる。読み手が一度に頭に入れなければならないコードの行数が少なければ少ないほど、コードは理解しやすい。

変数には「平均持続間隔」と「寿命」という概念があるという。そしてそれらが短くなった方がコードの読み手にとって読みやすいコードになるという。

去年、僕がとある案件で数千行に及ぶJavaScriptを書いた際、最も頭を悩ませたのはコードを頭に入れることだった。機能を追加・修正するために一度に頭に入れなければならないコードが多すぎたため、開発が進めば進む程、コードの修正は困難を極めた。

プログラミング初心者が誰しも一度はぶつかる壁なのかもしれない。コードの分割をはじめとする、コードの設計の重要性を肌で感じた瞬間だった。
だからこそ、上記の「読み手が一度に頭に入れなければならないコードの行数が少なければ…」というくだりに深く納得したのだった。

さて、ではJavaScriptにおいて「変数の寿命を短くする」ことと「関数の先頭ですべての変数を宣言する」ことは両立するのだろうか？これについて隣席の@keiskeyの意見はこうだった。

関数1つの長さ自体を短くしてしまうのがいいのでは。Google Closure Libraryのコードを見ていると、中身が2行しかないメソッドに長々とした名前が付いていたりする。そんな長い名前を付けるんだったら直接コードを書いてしまえばいいやん、と思うけど、「変数の寿命」のポリシーをもって書かれていると考えると合点がいく。

なるほど…と再び納得するとともに、「この話、共有してよかった」と思った。

例えば上述（リスト10-2）のコードを一つの関数だと考えるとこうなる。

function Account() {
    var accountIndex = 0,
        total = 0,
        done = false;
    // accountIndexを使用するコード
    ...

    // totalを使用するコード
    ...

    // doneを使用するコード
    while(!done) {
        
    }
    ...
}

この関数をクラス風に書き直し、機能分割するとこういう感じになる。

function Account() {
    // コンストラクタ
    ...
}
Account.prototype = {
    getAccountIndex: function() {
        var accountIndex = 0;
        // accountIndexを使用するコード
        ...
        return accountIndex;
    },
    getTotal: function() {
        var total = 0;
        // totalを使用するコード
        ...
        return total;
    },
    checkStatus: function() {
        var done = false;
        // doneを使用するコード
        while(!done) {
            ...
        }
    }
}

prototypeにぶら下げたメソッド1つ1つを短くまとめて上手に機能分割することが、限りなく正解に近いのではないかと思った次第。

僕はプログラマと呼ばれる職種ではないのだけれど、プログラミングに関わる人間として、こういった考察はとてもおもしろいと感じる。また何か同じような話があったら書いていきたい。

[jQuery] getJSON callback not firing? – jQuery Forum

なんでinvalidなのかと調べたところ・・・、JSONでは文字列は必ずダブルクォートで囲まないといけないことが判りました。シングルクォートではダメです。それからオブジェクトリテラルの左のオペランドにも、ダブルクォート省略不可！あー、なんか初歩的なところでつまづいています。

A string is a collection of zero or more Unicode characters, wrapped in double quotes, using backslash escapes.

http://json.org/

何しろエラーが出ないので、何が悪いのかわかりにくいです＞＜ これで2時間はハマってしまった・・・。。

日本語が斜体になると激しく読みにくいので、日本語が含まれている場合は通常の字体で表示したい。そこで慣れない正規表現を使って頑張ってみました。

日本語が斜体になるとどうなるか　# ←読みにくい

日本語が斜体になるとどうなるか　# ←こっちのが当然読みやすい

<$mt:EntryTitle setvar="entry_title"$>
<mt:If test="$entry_title =~ /[^\w\s\-\&\;\:\@\|\\\/\=\(\)\'\%\$\#\!\[\]\{\}\`\*\+\?\<\>]+/">
<$mt:Var name="entry_title"$>
<mt:Else><i><$mt:Var name="entry_title"$></i>
</mt:If>

日本語自体を正規表現ではマッチさせることができないので、あらゆるアスキー文字の否定（ある文字以外の文字）という形でマッチさせてみました。マッチすると通常のMTタグが出力され、マッチしないと<i>で囲まれたMTタグが出力されます。
しかし、我ながら稚拙な書き方だと思いますし、これで例外なく正しくマッチできているのかは自信がありません。。。きっともっとスマートなやり方はあるはずです。

ちなみにtestモディファイアは中にPerlの式を書くことができるモディファイアです。
<mt:If>に仕込んでBool値が返るPerl式を記述しておけば、TRUEが返ったときに中身を実行させることができます。

ここのサーバーはさくらのレンタルサーバ（スタンダードプラン）なのですが、ここではデータベースが1つしか作成できません。 ・・・ということで使用中のデータベースを削除し、新しくデータベースを作成するしかありませんでした。

しかし一旦削除する、というのはなかなか勇気が要ります。なんせミスしたら復旧できませんからね。。
とりあえず念には念をってことで以下のように作業しました。WordPressに移行する前だったので、データベースにはMTOSのデータが入っている状態でした。

1. 現状使用しているMTOSの機能でバックアップを作成（一応、保険的な感じで・・・）
2. レンタルサーバのコントロールパネルからphpMyAdminを使い、データベースのエクスポートを行ってバックアップファイルを作成
3. ローカル環境（XAMPP）のMySQL5.1に(2)でエクスポートしたファイルをインポートし、問題なくインポートできるか確認
4. (3)で問題がないことを確認できたら、レンタルサーバのコントロールパネルから現データベースを削除
5. データベース削除を行うと「データベースを作成」みたいなボタンが現れるので、データベースをMySQL5.1で作成
6. 作成したデータベースのphpMyAdminから、(2)で作成したファイルをインポート
7. MTOSの mt-config.cgi の内容を新データベースに合わせて修正
8. MTOSにログインして問題がないか確認

これらの作業の中で特筆すべきポイントはデータのエクスポート、インポートのところですね。文字コードが一緒でないと、日本語部分が文字化けしてしまいます。
まず、phpMyAdminにログインする際に「日本語 – Japanese (utf-8)」を選択しましょう。

サーバーによっては「日本語 – Japanese」としか表示されない場合もありますが、問題ありません。さくらのレンタルサーバではこれでした。

それと、ログイン後の画面の「MySQL の接続照合順序:」でインポート側とエクスポート側で同じものを選択します。「utf8_general_ci」か「utf8_unicode_ci」あたりかと思います。

左フレームから該当データベースを選択し、右上メニューの「エクスポート」をクリック。

エクスポートの際は「ファイルに保存」するにチェックを入れる以外の設定はとりあえずそのままで。

エクスポートされた *.sql ファイルをエディタで開いてみて、文字コードがUTF-8になっているか、日本語のデータが文字化けしていないかを念のため確認。インポート時には「ファイルの文字セット」で「utf8」を選択しましょう。

MTみたいに静的なファイルを書き出すCMSだと、データベースを削除してもファイルは残るのでサイトには影響がないですが、動的生成のCMSの場合はデータベース削除はNGですね。サイトが見えなくなっちゃいますので。どうしても削除する場合、作業中には「現在メンテナンス中」的な画面を代わりに表示させるとか、そういった対応が必要なのかなと。