多重接続というのは、1本のSSHコネクションで複数のセッションを同時に張るという感じのもの。たとえば、OS Xでターミナルを複数開き、それぞれのターミナルウィンドウで1つのサーバーに対しsshコマンドで接続を行った場合、通常はサーバー側では複数のsshdが起動し、それぞれのsshクライアントと通信を行います。いっぽう、多重接続を利用すると1つのsshdが複数のsshと通信する形となり、サーバー側のリソースをより効率的に利用できる、というわけ。

　設定は簡単で、クライアント側の.sshディレクトリに設定ファイルと一時ディレクトリを用意するだけ。

$ cd ~/.ssh
$ mkdir connections
$ chmod 700 connections/
$ vim config

　~/.ssh/configの内容は下記のとおり。

Host *
ControlMaster auto
ControlPath ~/.ssh/connections/%r_%h_%p

　あとは、通常通りsshでサーバーに接続するだけ。これだけで、体感できるほど2つめ以降の接続が高速化されます。下記は5つのSSHセッションを張った状態で、6つめのセッションを張ろうとした際の実行速度ベンチマーク。

多重化なし：
$ time ssh hylom.******.com uptime
 08:13:53 up 22 days, 10:18,  6 users,  load average: 0.00, 0.00, 0.00

real	0m2.123s
user	0m0.015s
sys	0m0.010s

多重化あり：
Last login: Tue Aug 24 17:15:34 on ttys006
$ time ssh hylom.******.com uptime
 08:18:53 up 22 days, 10:23,  6 users,  load average: 0.00, 0.00, 0.00

real	0m0.278s
user	0m0.006s
sys	0m0.007s

　多重化により、だいたい7.6倍くらい速くなっています。ちなみに、この状態で「ps ux」を実行してみるとこんな感じに。

$ ps ux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
hylom    17182  0.2  0.2   8292  1580 ?        S    08:21   0:00 sshd: hylom@pts
hylom    17183  0.0  0.2   2968  1584 pts/0    Ss+  08:21   0:00 -sh
hylom    17188  0.0  0.2   2968  1584 pts/1    Ss+  08:21   0:00 -sh
hylom    17193  0.0  0.2   2968  1584 pts/2    Ss+  08:21   0:00 -sh
hylom    17198  0.0  0.2   2968  1588 pts/3    Ss+  08:21   0:00 -sh
hylom    17203  0.0  0.2   2968  1580 pts/4    Ss+  08:21   0:00 -sh
hylom    17208  1.0  0.3   3484  1856 pts/5    Ss   08:21   0:00 -sh
hylom    17213  0.0  0.1   2432   908 pts/5    R+   08:21   0:00 ps ux

　sshdは1つだけで、接続毎にシェルだけが起動されるようになっていることが確認できます。

　この場合、下記のようにgit stashでいったん変更点を保存した上で直前のcommitに戻し、新たなブランチを作成してそこでgit stash applyを行えばよい。

$ git stash
$ git checkout hogehoge -b
$ git stash apply
$ git add hogehoge foobar
$ git commit

　git stash、便利だ。

　iPhone 4の動画再生機能については、Webサイトにその仕様が掲載されている（日本語のiPhoneページ）。ただし、日本語ページには一部誤訳というか不明瞭な表記があるたので、英語版iPhoneページを確認するほうが確実。これによると、iPhone 4の動画再生仕様は下記の通り。

• H.264：最大720p、30fps。Main Profile（レベル3.1まで、音声はAAC-LCで最大160kbs、48kHz、ステレオ）対応。ファイルフォーマットは.m4v、.mp4、.mov
• MPEG-4：最大2.5Mbps、640×480ピクセル、30fps。Simple Profile（音声はAAC-LCでチャンネルあたり最大160kbps、48kHz、ステレオ）対応。ファイルフォーマットは.m4v、.mp4、.mov
• MotionJPEG（M-JPEG）：最大35Mbps、1280×720ピクセル、30fps。音声はulawもしくはPCMステレオ。ファイルオーマットは.avi

　iPhone 4の画面サイズは960×640。そのため、縦に持った際は幅640に、横に持った際は幅960に自動的に拡大/縮小されて表示される。また、iPhone 4のドックコネクタ経由での出力では1024×768サイズの出力に対応している模様。

　ちなみに、iPhone 4の動画再生仕様はiPadとまったく同一のようだ。なお、iPadの画面サイズは1024×768である。

　さて、iPhone 4で動画を見る場合、わざわざ容量がかさむMPEG-4を積極的に使う必要はない。そのため、下記ではH.264についてのみ考察を行っていく。

　上記のとおり、iPhone 4はスペック上はHigh Profileには対応していない。しかし、試して見たところHandBrake 0.9.4のプリセットである「High Profile」でエンコードした動画も問題なく再生できてしまった。High ProfileとMain Profileの違いは8×8DCTブロックやカスタム量子化マトリックス（CQM）、Cb/Cr別のQP制御、モノクロ（4:0:0）対応だが、実際8×8DCT以外については、設定の難しさの割に効果は微妙なところではある（そのうえHandBrakeでは設定できない）。

　High Profile非対応という機器でも8×8DCT対応のものはあるので、iPhone 4/iPadもそうなのだろう。HandBrakeでは「High Profile向け」と表示される「Pyramidal B-Frames」については、High ProfileでもOffになっているので気にしないことにする。

　ということで、とりあえずHandBrakeでiPhone 4およびiPad向けのエンコードを行う場合、プリセットのHigh Profile設定を利用すれば問題ないようだ。

　対応する縦横サイズやビットレートに関連する「レベル」については次の機会に。

　「Debian kFreeBSD」はカーネルとしてFreeBSD、ユーザーランドとしてDebianを採用したものだ。Debian GNU/LinuxとDebian kFreeBSDはカーネルだけが異なり、またDebian kFreeBSDとFreeBSDはユーザーランドだけが異なる。これらを比較することで、ユーザーランドもしくはカーネルだけの性能比較が行える（と期待できる）点で興味深いベンチマークである。

　ベンチマーク結果であるが、gzipでの圧縮やGnuPGでの暗号化、MAFFT（分子生物学向けの核酸・アミノ酸アライメント作成ツール）、GraphicsMagickによる画像のリサイズ処理、Himeno BenchmarkについてはDebian kFreeBSDやDebian GNU/Linuxが高パフォーマンス、という結果だった。いっぽう、C-Rayでの3DグラフィックレンダリングについてはFreeBSD 7.3/8.0が高速な傾向が見られている。

　また、Debian GNU/LinuxがFreeBSDやDebian kFreeBSDよりも高速だったのはdCrawによるRAW画像の現像処理、Sudokut（数独演算アプリ）、SQLiteのインサート処理。

　このようにベンチマークごとに結果はばらばらであり、DebianのユーザーランドとFreeBSDのユーザーランドのどちらが高速か、またLinuxカーネルとFreeBSDのカーネルのどちらが高速かは単純には言えないという、なんともモヤモヤとした結論となっている。このベンチマークでは実行マシンとしてThinkPad R52とThinkPad T61を使用しているが、マシンによって結果が違うのも微妙なところだ。

ただし、マルチスレッドによるI/O処理ベンチマークについては、特にランダムWriteについてはLinuxカーネルのほうがパフォーマンスを発揮する傾向があるようだ。

　prgmr.comはXenを使用したVPSで価格は$5/月からと低価格なのが魅力の1つだが、安さだけなら国内のVPSサービスと大きくは変わらない。ではなぜprgmr.comが注目されているのかというと、そのアレなたたずまいと、サポートの簡素さによるところが大きい。prgmr.comのトップページにはほかのVPSサービスのような画像による装飾は一切なく、アスキーアートで書かれた「prgmr.com」というバナーと「We don’t assume you are stupid.」という文言、そして料金やXenベースVPSの特徴が紹介されているのみ。一般人ならとりあえずこのサイトが何であるかも理解できないだろう、という作りである。

　このようにアレゲ感たっぷりのprgmr.comであるが、その一方でかなり自由度は高く、OSはDebian GNU/Linux、Ubuntu 10.04、CentOS 5.5が選択できるほか、AMD64アーキテクチャのXen上で動作するOSなら（自力で）任意のOSがインストールできる（可能性がある）、追加料金なしでグローバルIP付与と、独自のサーバー管理＆Xenが分かる人にとってはかなり魅力的であったりする。

　ということで一部の人には魅力的なこのprgmr.com、ちょくちょく新規受付を開始しては定員に達して終了を繰り返しており、いつでも申し込みできるというわけではないのだが、ウォッチしていたらたまたま申し込み可能になっていたため、$12/月でメモリ512MiB、ディスク12GiB、月間ネットワーク転送量80GiBのプランを申しこんでみた。

Webでの申し込み後、メールでSSH公開鍵を送付。サーバー設定は必要十分

　Webで利用したいプランを選択し、オンラインフォームに必要事項を記入して申し込むと、下記のように利用したいディストリビューションとOpenSSH公開鍵を送信しろ、という旨のメールが来る。

you ordered a xen vps, 512MiB ram, 12GiB Disk 80 GiB transfer Xen VPS, $12/month username hylom

Before I can set you up, I need to know what distro you would like and an OpenSSH format public key (on a *NIX, run ssh-keygen and send me either the id_dsa.pub or id_rsa.pub file in an attachment)

　あとはこのメールの返信として公開鍵を添付し、Debian GNU/Linuxを使いたいという旨を伝えるだけだ。

Hi,

I want to use Debian GNU/Linux, and here’s my SSH public key.

Please check it.

　設定が完了すると、その旨がメールで連絡される。また、しばらくすると金払ってねメールがやってくる模様。料金の支払いはPayPal。

　続く。

　Small Basicブログによると、Small Basicコンパイラのパフォーマンス強化や新規ライブラリの追加などが行われているとのこと。ループが多いプログラムで、4倍ものパフォーマンス向上を達成できた例もあるそうだ。

　追加されたライブラリでは、MML的記法で音楽を再生できる「PlayMusic」機能が面白そうだ。教育用とはいえ、Flickr連携や作成したプログラムをSilverlightを用いてWebブラウザ上で実行する機能などもあり、ちょっとしたユーティリティなどを作成するのにも便利かもしれない。

　LLVMは「コンパイラインフラストラクチャ」という形で開発が進められているのだが、このLLDBは現代的な「デバッガインフラストラクチャ」とのことで、モジュラー化構造や再利用しやすいライブラリが特徴らしい。LLDBはLLVMの技術やAPI、パーサー、コードジェネレータ、JITコンパイラなどを利用して構築されているとのこと。

　現在は開発中の段階で、Mac OS Xでのコマンドラインでのデバッグのみに対応しているとのことだが、scriptableだったり、マルチスレッド対応など面白い話もある。さらに現状ではGDBよりも高速だそうで、特にC++プログラマにとっては使いやすいものになっているらしい。

　fetchするコンテンツはLINKタグで指定する。たとえば、次のようなLINK要素をHTML内に記述しておくと、ロード時に「page2.html」がfetchされる。

<link rel="next" href="page2.html">

　また、次のように明示的にprefetchを指定することもできる。

<link rel="prefetch" href="/img/img.jpg">

　この機能はすでにFirefoxでは実装済みで、OperaやChrome、Safariでもすぐにサポートされるのでは、とのこと。Internet Explorerでは2020年代まで利用できないかも;-) だそうだ。

　ちなみにMozillaのlink prefetchingに関するドキュメントによると、HTTPヘッダーでも次のようにしてprefetchするコンテンツを指定できる。

Link: </images/big.jpeg>; rel=prefetch

　さらに、METAタグでも指定できる。

<meta http-equiv="Link" content="</images/big.jpeg>; rel=prefetch">

　また、 Firefoxの場合、http://で始まるURLのみに対応し、https://はセキュリティ関連の理由のためprefetchされない。また、FTPなどもprefetch対象外。prefetchはブラウザがidle状態で、たとえばコンテンツのローディングやダウンロードが行われている間は行われないそうだ。あとはユーザー設定でFirefoxのprefetchを無効にできるとか、prefetchリクエストは「X-moz: prefetch」ヘッダー付きで送信されるとか色々あるが、その辺は上記のドキュメントを参照。

　server.bookmark.getCount()はURLをキー、被はてブ数の値とするdictionaryの形で返してくれるので、返ってきたデータの参照も楽勝です。URLの一覧を引数の形で与えなければならないのがなんか引っかかりますが……。

#!/usr/bin/env python

import xmlrpclib

def main():
    uri = "http://b.hatena.ne.jp/xmlrpc"
    server = xmlrpclib.ServerProxy(uri)
    urls = ("http://sourceforge.jp/magazine/10/04/26/0244255",
             "http://sourceforge.jp/magazine/10/04/27/0326224",
             "http://sourceforge.jp/magazine/10/04/30/0243232")

    t = server.bookmark.getCount(*urls)
    for item in t:
        print item, t[item]

if __name__ == "__main__":
    main()

　withを使ったコード例は、下記のような感じ。

c = ClassHogeHoge()
with c:
    c.foobar()

　上記のコードは、下記と等価となる。

c = ClassHogeHoge()
c.__enter__()
c.foobar()
c.__exit__()

　つまり、withに続くインデントブロックを実行する前に指定したオブジェクトの「__enter__()」メソッドを呼び出し、実行後に「__exit__()」メソッドが暗に呼び出される、という仕組み。

　__enter__()と__exit__()の定義は、Python リファレンスマニュアルの3.4.9 with文とコンテキストマネージャにある。__enter__()の引数はselfのみだが、__exit__()はself、exc_type、exc_value、tracebackの4つの引数をとる。withに続くインデントブロックが正常に実行された（つまり、例外が送出されなかった）場合、（self以外の）引数にはNoneが与えられる。なにか例外が発生した場合、その例外に関する情報が与えられるらしい。

　また、「with hogehoge as foo:」のような形でwith文を利用する場合、__enter__()の戻り値がfooに代入される。__exit__()の戻り値は例外処理の伝搬制御に使われ、Falseの場合例外が発生た場合でも例外を伝搬させず、Trueを返すと例外が伝搬されるとのこと。

　下記、使用例。

class CacheDB(object):
    DB_FILE = "database/db_dat"

    def __init__(self):
        self.con = None
        self.cur = None

    def __enter__(self):
        self.con = sqlite3.connect(self.DB_FILE)
        self.cur = self.con.cursor()

    def __exit__(self, exc_type, exc_value, traceback):
        if exc_type:
            self.con = None
            self.cur = None
            return False
        self.con.commit()
        self.cur.close()
        self.con.close()
        self.con = None
        self.cur = None
        return True

    def add(self, foo, bar, hoge):
        try:
            self.cur.execute("""insert into data ( foo, bar, hoge )
                           values (?, ?, ?);""", (foo, bar, hoge))

def main():
    usage = "%s logfile" % sys.argv[0]
    db = CacheDB()
    try:
        fname = args[0]
    except IndexError:
        sys.exit(usage)

    f = open(fname, "r")
    with db:
        for l in f:
            term = l.strip().decode("utf-8").rsplit("\t", 3)
            db.add(foo=term[0],
                   bar=term[1],
                   hoge=term[2])

if __name__ == '__main__':
    main()

　タブ区切りのデータファイルを1行ずつ読んでデータベースに突込む、という処理。withを使うことで、データベースアクセスの準備→データ挿入→コミットという流れをきれいに実装できました。