2009-11-14

Mac mini に Maxima をインストール

ふと思い立って、Maxima をインストールしてみることにした。 まずは Mac mini (Server) でやってみた。

ちなみに、Maxima っていうのは GPL で配布されているフリーな数式処理システムだ。「はじめてのMaxima」によれば、

Maxima は 1960 年代の MIT の MACSYMA プロジェクトで開発された「MACSYMA」(MAC's SYmbolic Manipulation system) の「DOE(エネルギー省)版」を、Texas 大学のシェルター氏 (Schelter) が「Common Lisp: The language 第一版」に対応した「gcl」に移植したものです。

ということだ。手元にあるかなり古い雑誌(「インターフェイス」増刊の「archive」No.12) によれば、Maxima の前身である Macsyma の作成が開始されたのが 1966 年。1972 年に ARPA ネット(!) を通じて全米で使用可能となって、さらに一般で購入可能となったのが 1982 年だとのこと(ちなみに、同誌によれば現在数式処理ソフトとして有名な Mathematica の最初の版ができたのが 1988 年だそうな)。なかなかに歴史のあるソフトだ。

インストールを始める前はつまづくとは思っていなかった。MacPorts でインストールできるだろうと思っていたから。sudo port install maxima で後は待つだけ、そう高をくくっていた。世の中、そうそう甘くない。

2009-11-13

Realforce 86U、到着

キーボードこだわり概論

Realforce 86U: 外箱

わたし自身もそうだが、一般にキーボードに対する「こだわり」は大きく 2 つある。まず何より配列。次がキータッチ。どんなに心地良い叩き具合であっても、慣れた配列でなければ、しょっちゅうイラッとくる。だから配列が最優先。

パソコン用のキーボード配列には大きく 2 種類ある(PC であれ Mac であれ)。1 つは US 配列とか英字配列と呼ばれるもの。もう 1 つは JIS 配列あるいは日本語配列と呼ばれるもの。わたしは前者を好む。っていうか後者は使わない。「イラッとくる」から。最下段に変換、無変換のような時代遅れのキーが配置されているだけならまだしも、最上段の記号の位置が微妙に異なる。Enter キーの形状もおかしい。とにかく、JIS 配列は使わない。

キータッチにはいろいろとあるようだけど、配列の方を優先させるものにはこだわれるほどの選択肢はない。Mac ユーザだとさらに狭まる。加えて、かつてわたしは最高のキータッチのキーボードに出会ってしまっている。キータッチに関しては、あれ以外はすべて「にせもの」「まがいもの」だと感じる。「あれにくらべれば、どれも一緒、大差ないよ」と思ってしまう。

それは、昔の IBM 製 PC のために作られた日本語キーボード。パソコンがとても高い製品だったころのもの。今では手に入らないだろう。持っている人は幸運だ。わたしのいた会社では 106 キーボードと呼ばれていた。軽い叩き心地に、ほどよいストローク。何より音が良い。叩いている本人はもちろん、周囲にいる人の耳にも心地良い音だった。ただし、日本語キーボードだったから、わたし自身が使ったのはごく短期間。すぐに US 配列の 101 キーボードに乗り換えた。

今回、Realforce 86U に求めたのも上記 2 点。まずは配列。次がキータッチ。

第一印象

Realforce 86U: 左肩にロゴが入っている

この 86U は US 配列なので、第一関門はクリア。ただし、一口に US 配列とは言っても微妙な差異がある。具体的には最下段のスペースバー以外のキー、Mac OS X では修飾キーと呼ばれるキー群にその差異が現れる。Apple 純正キーボード(US)の場合、ここには[Control][Option]、そして[Command]の 3 種類のキーが並ぶ。コンパクトタイプなら[Fn]もある。わたしの場合、[Control]が最重要、続いて[Command][Option]については妥協の余地あり。

では、86U の最下段のキー配列を見てみよう。こんな風(↓)に並んでいる。

[Ctrl][W][Alt][  Space  ][Alt][AP][Ctrl]

[Ctrl](つまり[Control]) が両側かつ両端にあるのは good。ま、そうでなかったら買っていない。Emacs のキーバインドに慣れたものにとって [Ctrl] の位置は最重要。世間ではなぜか [Caps Lock] の位置に [Ctrl] を置くのが人気のようだけど、わたしは最下段のなるべく外側にないと困る。とても困る。両端ならベストポジション。ちなみに、Controlキーは指で押すもんじゃない。両方の小指のつけねというか手のひらの端というか、その辺りで押すものだ。そうすると両手に負荷を分散できる。(ノートタイプの場合は事情が変わる。)

スペースバーのすぐ外側にある[Alt]は、OS の設定で[Command]に替えよう。キーとしてはこの位置、この大きさで good。

[W]Windows キー[AP]アプリケーションキー(以下、AP キー)。 どちらも Mac には不要のもの。むかしはこんな余計なものは付いていなかった(十数年前)。ここに欲しいのは[Option]なんだよねえ。

キータッチは・・・「最高のあれ」と同じ感触でないことは確か。だからといって、ダメだってことでもない。今も 86U でこれを書いているが、こればっかりはしばらく使ってみなければ評価しにくい。ただ 1 つ、今の段階でも言えることは、音は悪いってこと。ストロークの深さも機構も違うから、比較してもしかたがないけど、今まで使っていた Apple Wireless Keyboard の方が音はマシ。

さて、箱から出して実際に使おうとすると、いくつか問題に遭遇した。

問題点 #1: 不要なキー

邪魔なアプリケーションキー

さて、Mac ユーザには意味のない AP キーだが、どうやら OSX には[Enter]のように見えるらしい。修飾キーだとは思ってくれていない。つまり、[Option]の振りをさせられないってことだ。

解決策

なし…orz
不用意に触れて [Enter] が入力されるのもうっとおしいので、Realforce の DIP スイッチで AP キーを無効にしておく(SW4 → ON)。押しても何も起こらない。ムダなキーだ。

問題点 #2: おかしな挙動

Mac OS X ではキーボード上の修飾キー([Command][Option][Control][ および [Caps Lock])をそれぞれ入れ替えることができる。この機能を使って、86U の修飾キーの機能を以下のように入れ替えた。ちなみに、Alt キーは[Option]、Windows キーは[Command]として認識されていた。

OptionCommand
CommandOption

ここで問題が起きた。この設定だと右側の[Alt][Command]キーとして機能しないのだ。なぜか[Alt](つまり[Option])のまま。これには困った。OS が悪いのか、86U が悪いのか(仕様? 故障?)。

解決策
システム環境設定:キーボード:修飾キー設定パネル:Realforce 86U用の設定

しばらく悩んだ末、回りくどい方法だけど解決できた。以下にその方法を示す。

  1. Realforce で[Ctrl][Alt]を入れ替える。(SW3 → ON)
  2. OS の設定で [Control][Command] に、 [Option][Control] に入れ替える。

不思議なもので、これだと右側の Alt キーもこちらの意図どおりに機能する。原因は不明。試行錯誤の末に見つけた、その場しのぎの方法だ。ま、使えれば良い。

先に入れ替えてあった、[W] → [Option]と併わせて、ほぼ望みどおりの配列になった。[Option]が左側にしかないのは気に入らないけれど、こいつは[Option] + Spaceしか使わないので、十分妥協可能。ちなみに、このキーで Spotlight 検索の小窓が開くように設定してある。

関連リンク

2009-11-12

Go - A Programming Language

Google で作られた新しいプログラミング言語。とりあえず Rob Pike の TechTalk を見てみた。約1時間。軽い気持ちだと最後まで見通せないぞ。英語だし。早口だし。むしろ、じっくりスライド(PDF)を見た方が良いかも。

最初は、とくに表記の仕方に戸惑った。なんと、型を変数名の後に書く。違和感ありまくりだったが、しばらく見ていると慣れるものだね。読むだけなら、これはこれで読みやすいかも、と思い始めている。書くとなったら、しばらく混乱しそう。

↑の Tech Talk 中で説明される言語の特徴、機能の中では、channel がおもしろそうだと感じた。

The Go Programming Language Specification
A channel provides a mechanism for two concurrently executing functions to synchronize execution and communicate by passing a value of a specified element type.

簡単に言ってしまえば、queue が言語に作り付けになっている、ってこと。queue は、ごくおおざっぱに言えば、右から入れたものが左から取り出せる筒のようなもの。すぐに取り出しても良いし、後で取り出しても良い。入れた人と取り出す人が別でも良い。入れた後、すぐに別のことを始めても良いし、取り出されるまで待っていても良い。取り出す人は筒がからっぽなら誰かが入れてくれるまで待つ。並列プログラミングのための仕組みだ。

この queue、Ruby だとクラスライブラリとして実現されている。用途はまさにスレッド間通信。

↑の Tech Talk で説明されていたマルチサーバの例で、この channel が使われていた。2 本の channel を使って、処理リクエストとサーバの制御(停止)を実現していた。mutex を使って共有変数を仕立てるなんていうのは primitive すぎるのだね、と目からウロコが2、3枚落ちた。

関連サイト

2009-11-11

Snow Leopard アップデート (→ 10.6.2)

送信者 Macをプログラムする

MacBook (Early 2008) の雪豹の場合アップデートファイルのサイズは 157.7MB。Mac OS X v10.6.2 アップデートについて をざっと眺めてみたけど何が変わったか実感できるような項目は見つけられなかった。

一方、Mac mini Server (Late 2009) の Server は 524.5MB。でかい。ビックリした。こちらも、Mac OS X Server v10.6.2 のアップデートについて を見た。やはり、特記したい項目は見つけられなかった。ただ、ページの一番最後にこう(↓)書いてあったので、当たり前だけどちょっと安心した。

Mac OS X Server v10.6.2 には、クライアントの Mac OS X v10.6.2 アップデート で提供されるその他のすべての改善事項も含まれます。

同時適用のセキュリティアップデートはクライアント版、サーバ版で共通。詳細はここ(↓)にある。ちなみに、日本語環境で上記の「・・・アップデートについて」からリンクをたどってもここにたどりつけない。途中のリンクが間違っている。(2009-11-11 23:00 時点)。一度、英語版を表示させてからだとたどりつける。

アップデート後の About ウィンドウ。

そうだ、今後の比較のために、カーネルのバージョンを記録しておこう。これが Server 版。

[foo:~] bar% uname -a
Darwin foo.private 10.2.0 Darwin Kernel Version 10.2.0: \
Tue Nov  3 10:37:10 PST 2009; root:xnu-1486.2.11~1/RELEASE_I386 i386

こっちが MacBook の方。

[baz:~] bar% uname -a
Darwin baz.local 10.2.0 Darwin Kernel Version 10.2.0: \
Tue Nov  3 10:37:10 PST 2009; root:xnu-1486.2.11~1/RELEASE_I386 i386

どちらも同じだってことがわかる。(行が長いので "\" のところで折り返してある。)

ScanSnap Manager アップデート

11月にアップデートが出るという噂をネットで見ていたので、公式サイトにアクセスしたところ、アナウンスが出ていた(↓):

[2009年11月 9日] ScanSnap Manager V3.0 アップデートパック1(Snow Leopard対応)
[2009年11月 9日] CardMinder V1.0 アップデートパック2(Snow Leopard対応)

Snow Leopard 対応となっているけど、何にどう対応したのかは書かれていない。テキスト認識が高速になった、とかならウレシイんだけどな。

公式サイトから dmg をダウンロードしてアップデートした後に気付いたんだけど、ScanSnap Manager、CardMinder ともにアプリを起動した状態から「ヘルプ」>「オンラインアップデート…」を実行すればアップデートの確認からダウンロード、アップデートとやってくれる。

関連記事

テンプレートを確認するためのサンプル

これは H4

この記事は、テンプレートで設定したスタイル等の見栄えを確認するためのサンプル集。ここは通常の段落(ただの p)。

  • これはリスト
  • MacBook (Early 2008)
  • Mac mini Server (Late 2009)
  1. これは番号つきリスト
  2. Snow Leopard 10.6
  3. Snow Leopard 10.6.1
  4. Snow Leopard 10.6.2
これは H5

↓はターミナルの出力を表示するスタイル。class つきの pre

[foo:~/] bar% git
usage: git [--version] [--exec-path[=GIT_EXEC_PATH]] [--html-path]
           [-p|--paginate|--no-pager]
           [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE]
           [--help] COMMAND [ARGS]

今度はソースコードを表示するためのスタイル。class つきの pre に code が入ったもの。

# This is a very long long long long long long long long long long long long line.
# This is a very long long long long long long long long long long long long long long long long line.
# This is a very very very very very very very very very very long long long long long long long long long long long long line.

次は本やウェブページからの引用に使う。blockquote

SICP
Program must be written for people to read, only incidentally for machine to execute.

そして dl

Macintosh
Apple 社が製造、販売しているパーソナルコンピュータ。
単価数量価格
1,0001010,000
10,0001001,000,000
合計-1,010,000

捨てることで見つける

【連載】Google世代の整理術「デジタル情報整理ハックス」 (21) 「どうしてもとっておきたいエントリ」はどうするか?
情報収集と一口に言っても、新聞のスクラップが主だった時代に比べて、インターネット時代の今は、収集のたやすさと情報量の豊富さにおいて、圧倒的です。こういう環境では、厳選のレベルをいくら高く設定しても、高すぎることなどないように思えます。

「気になったものはなんでも取っておくといい」というのは、むしろ紙の時代の箴言です。今ではむしろ、ちょっとでもいらないかなと思えた情報は、とにかく捨てた方がいいと言っても、過言ではないでしょう。

「はてブ」や diigo のような SBS の登場で URL を記録しておくことがとても簡単になった。その結果、ブックマークがあふれてしまう。で、せっかく取っておいた URL も埋もれてしまって見つけられない。しかたがないから、ブックマークを検索するようになる。で、ふと気付く、「あ、Google で検索すればいいじゃん。ブクマ、いらないな」と。

RSSリーダーの登場でウェブに流れる情報の監視がとても簡単になった。その結果、未読フィードがあふれてしまう。結局、読まないまま「既読にする」をクリックしてしまう。ちらっとタイトルだけを見た記憶から、あんな記事やこんな記事があったはず、とRSSリーダーに保存されたフィードを検索するようになる。で、ふと思う、「あ、これって Google で検索するのと同じ。RSSリーダー不要。ってか、最初から読まなくて良いんじゃないか?」

情報が大量に蓄積してしまうと、見つけるためには検索を用いるしかない。情報の山を始めから終わりまで(少なくとも見つかるまで)、順にたどるような方法は探索時にコストがかかりすぎる。蓄積時に整理、分類すれば探索の手間は省けるが、今度は蓄積するときにコストが発生する。加えて、たいていの人は体系立った分類法など身につけてはいない。一貫した分類を行おうとするだけで苦痛になる。整理が不要な量に収まっているときだけ効率良く整理できる。人はスケーラブルにはできていない。「大量」を相手にするには機械に頼るしかない。

一方で、検索には「見つからないかもしれない」問題がつきまとう。たとえ自分が蓄えた情報であっても目的の対象を見つけられるとは限らない。「ブックマークしたはず」という記憶が間違っていることもあるし、適切な検索語を思いつけないこともある。整理と探索にかかるコストを劇的に軽減してくれる「検索技術」は「発見する」という事象を確率化してしまうのだ。

「確率化されてしまった発見」に対して、「見つかる確率」を上げるためにさまざまな工夫が発明されてきた。SBS のように、ブックマークを共有し、タグづけを「みんな」で行うことで、集合知を味方につけようとする技術はその代表。けれど、ちょっと考えてみよう。これは Google が検索精度の向上の名のもとに日々取り組んでいることとかぶっているんじゃないか? PageRank はそもそも集合知を検索に生かそうという試みだ。ウェブ履歴は個人の嗜好を検索に反映させるものだ。

だったら、情報はどんどん捨ててしまおう。大丈夫、それがネット上のものであるなら、Google が拾ってくれる。きちんとしまっておいてくれる。必要になったら見つけてくれる(かもしれない)。見つからなければそれまでのもの。縁がなかったってことだ。心配ない、情報は、興味を引くものは他にもいっぱいある。

捨てて、捨てて、捨てまくって、それでもなお捨てられずに残るものがあるなら、それは自身にとって肝心な何か。「必要だから」じゃない、「役に立つから」でもない。それは自分にとって「忘れたくないモノ」。こだわらずにはいられない何か。捨てることで大事なものを見つける。それだけを手に持って、あとは全部、丸ごと Google に任せよう。

情報はしぼらなきゃならないという発想。これは、限られたリソースをどこに投資するかという問題(選択と集中)のバリエーションだ。そして、この問題はライフハック界隈で繰返し聞く「制御(コントロール)を取り戻す」という主張とつながくる。

「しぼる」は「捨てる」、「あきらめる」と同義。「あきらめる」こと、それが肝心。その代わり、あきらめなかったことはとことん追求する。こだわる。それが職人ってものだろう?

2009-11-10

MacBook にも Git を (あるいはリモートリポジトリの準備)

MacBook にも Git をインストール。先日の Mac mini Server のときと同じく ports まかせ。

こうして、ネットワークでつながった 2 台のコンピュータの両方に Git が準備できた。両者の間でリポジトリの clone や、変更の push を試してみよう。

プロトコルを選ぶ

Git は分散 VCS で、かつリポジトリの間に優劣の差がない。実際にそうするかどうかは別として、すべてのリポジトリはリモートリポジトリになることができる。他のコンピュータからのリポジトリの複製要求に応えることができる。適切に設定してやれば。

手元の(ローカル)なコンピュータに Git がインストールされていれば、ネットワーク上(リモート)のコンピュータからリポジトリの内容を複製するための準備は整っている。実際、GitHub などの公開リポジトリから git clone で複製できる。では、複製要求に応える方のコンピュータにはどんな準備が必要なのか。

その問いに応えるためには、まず、Git がリモートリポジトリにアクセスするプロトコルを選ばなくてはならない。プロトコルによって準備が異なるからだ。

「入門git」(p.97-100) によれば、Git が対応しているネットワーク接続のためのプロトコルは、SSH、git、そして HTTP/HTTPS の 3 つ。今回、このうちの SSH と git を使った接続をそれぞれ試してみた。以下に、それぞれの場合にリモート側のコンピュータで必要な設定について試した内容と結果を述べる。
(この記事では SSH の場合のみを扱う。git プロトコルについては別の記事で書く)

Git コマンド群への PATH 設定

さて、2 台のコンピュータ間で SSH 経由のリモートログインができるように設定されているとする (うちの MacBook と Mac mini Server ではすでにそうなっている)。この状態で以下のコマンドを叩いてみる(入門git; p.98, 101)。

[foo:~] % git clone bar.local:projects/greeting

foo.local から bar.local のリモートリポジトリを clone しようというものだ。もし、このとき git-upload-pack: Command not found. というエラーが出て、clone が失敗するようなら、リモート側での PATH の設定に失敗している。というか、うちの Mac mini Server ではこうなった。一方、MacBook をリモート側にするとこのエラーが出ない。clone に成功する。その原因を探るのに、2〜3時間かかってしまった。

リモートのシェルでの PATH の設定にはいろいろな要素がからむ。以下は、うちの Mac mini Server の場合の原因だ。同じ症状だったとしても、これがあてはまらない場合もある。自分にとっての記録と、誰かの参考のために残しておく。

MacPorts を使って Git をインストールした場合、(標準では)コマンド群が置かれるのは /opt/local/bin になる。MacPorts そのものをインストールしたときに、この場所が PATH に足されるよう設定ファイルが変更されるのだが、場合によっては(例: インストール後にログインシェルを変更した)この設定が有効にならないことがある。

MacPorts のインストーラは、その最終段階で .profile または .tcshrc を変更するようだ。うちの Mac たちのシェルは tcsh に変更してあるので、以下の記述は tcsh の場合のみにあてはまる。.tcshrc ではこんな行が追加される。

# MacPorts Installer addition on 2009-10-25_at_13:33:42: adding an appropriate PATH variable for use with MacPorts.
setenv PATH /opt/local/bin:/opt/local/sbin:$PATH
# Finished adapting your PATH environment variable for use with MacPorts.

これらの行がない場合(肝心なのは setenv の行、他はコメント)、MacPorts のコマンド群はすべて見つからない。ところで、PATH の設定は他にも方法がある。ログインシェルなら .tcshrc の後、.login も読まれるため、そちらで設定することもできる(というか、わたしはそうしていた)。つまり、.tcshrc 以外の方法で PATH を設定していた場合、対話的にターミナルから使う場合には問題なくコマンドが見つかるのに、対話的じゃないとき(つまりリモートシェルのような場合)には、コマンドが見つからず失敗する、という現象が起きる。

原因がわかれば対処できる。単純に、Mac mini Server の .tcshrcで↑に挙げた PATH の設定の行を追加するだけ。たった 1 行の追加だ。実は、ここに至るまで色々と試行錯誤を経たのだけど、この解決策がもっともシンプルなのでこれを採用。

clone する

実は SSH をプロトコルにする場合、以上でリモート側の設定は完了。後はコマンドを叩くだけ。こんな風になる。

[foo:~] % git clone bar.local:projects/greeting
Initialized empty Git repository in /Users/baz/tmp/greeting/.git/
remote: Counting objects: 16, done.
remote: Compressing objects: 100% (8/8), done.
remote: Total 16 (delta 2), reused 0 (delta 0)
Receiving objects: 100% (16/16), done.
Resolving deltas: 100% (2/2), done.

まとめ

さて、今回はここまで。Git の話題というよりは、MacPorts と SSH の話になってしまった。

この先、リモートのリポジトリに push したり、pull してきたり、実際に使う場合にはいろいろと覚えなきゃならないことがある。単にコマンドを覚えるだけでなく、どういった運用にするのかも考えなきゃならない。

想定しているシナリオは、普段デスクトップで作業をしていて、出張だとか何かで部屋やオフィスを出なればならないとき、ノートブックにデスクトップから clone して作業環境を持っていく、というもの。出先での作業の記録はノートブックのリポジトリに commit しておき、戻ってからデスクトップに push する。

何もリポジトリを分散させなくても、SD カードや USB メモリといったリムーバブルメディアにリポジトリを構築すれば、上記のようなシナリオには十分に対応できる。この方法なら Subversion のような集中リポジトリタイプの VCS でも可能。好みの問題だ。集中と分散、どっちが好きか。

上にも書いたが、SSH を使わず Git オリジナルのプロトコルを使う方法もある。そちらについては、また別の機会に書くつもり。調べたいことがまだ残っているので。

参照情報

関連記事

2009-11-08

平等分散リポジトリの見せる夢

はじめての Git

LOG+REPOのテンプレートや素材、そして記事を保全するために Git で管理することにした。まずは「入門git」の第三章、「最初のプロジェクトを作る」に書かれた手順を追ってみた。

git init がすべての始まり。CVS や Subversion とは違い、中央リポジトリは存在しない。昨日までの作業場所がそのままリポジトリの置き場所にもなる(↓)。

(入門git; p.25)
Git で自分のリポジトリがあるのは、自分の作業ツリーとまったく同じ場所にある .git ディレクトリの中だ。

ファイルを作ったら git add、そして git commit。変更しても git add、そして git commit。さっき何を変更したかを忘れたら git status。これまでにどんな変更をしたかを思い出したければ git log。詳細な差分が知りたくなったら git diff

日常のサイクルを思い出すには Git早見表の "Commands Sequence" が最適。

Git は RCS っぽい

CVS や Subversion を一から導入するのはかなりハードルが高い。ソフトウェアのインストールのことではない。今時の有名なソフトウェアのインストールはとても簡単 (Git もそうだった)。よほどマイナーなプラットフォームにこだわっていない限り、迷うことはほとんどない。大変なのは、実際にプロジェクトをバージョン管理ソフト(以下、VCS)の管理下に置く作業の方だ。こっちには途方に暮れる点が少なくない。

何よりリポジトリをどこに置くかで迷う。ローカルなマシンに置くのか、ネットワーク上の共有フォルダに置くのか。ネット上に置くなら、むしろ VCS をサーバとして動かすべきじゃないのか。いっそのこと、Google に頼むか。・・・などなど。

慣れているなら迷わない。けれど、最初にこれをやるのはかなりハードだ。失敗してしまえば(後からもっと良い方法を思いついたら)、やり直しはメンドウ。そう思うと、ますます指が動かなくなる。

その点、作業場所がそのままリポジトリだという Git の方法は迷いがない。思い立ったら、ただ git init と叩くだけでいい。「やっぱ、や〜めた」となれば、rm -rf .git で、キレイさっぱり忘れてしまえる。

ふと思った。「あ、これって、RCS と同じ感覚だ。」

RCS は、もうずっと以前に unix 界隈でメジャーだった VCS (→ Wikipedia:Revision_Control_System)。そんなの聞いたことないや、っていう人はターミナルを開いて /usr/bin あたりを見てみるといい。ci とか co というコマンドが見つかるはずだ。少なくとも Snow Leopard には入ってる (Xcode と一緒に来たのかもしれない)。

RCS は、基本的に個人の作業成果を管理するためのシステムだ。独立したリポジトリの概念はなく、作業場所がリポジトリも兼ねる (ディレクトリごとに RCS ディレクトリを作れば、そこがリポジトリになる)。だから、チームで作業するようなプロジェクトには向かない。

個人からチームへ

ソフトウェアの規模が増大するにつれて、ソフトウェア開発の主役は個人からチームに移っていった。VCS にもチームでの作業を前提とした機能が求められた。CVS の誕生だ(→ Wikipedia:Concurrent_Versions_System)。CVS の始まりは RCS への不満だったという。RCS をベースにして、そこに不足している機能を付け加える方法で開発が進められた。いつしか RCS への依存もなくなり独立した VCS として、オープンソースソフトウェアプロジェクトを中心に広く使われるようになった。

一方で、ソフトウェア開発は複雑化の一途をたどった。チームメンバーの増加、地理的分散、増大するリリース作業の負担。プロジェクトインフラとしての VCS には、大規模かつ複雑なプロジェクトをサポートする機能が求めらるようになった。つまり、CVS にも機能不足と呼ばれるときが来たのだ。

(Subversion実践入門 第2版;p.6 - 7)
Subversion のプロジェクトは、CVS に精通した開発者のチームによって開始された。(・・・中略・・・) 彼らは CVS が既に古くなりつつあることを感じて、それに代わるツールを開発すべき時が訪ずれたと判断したのだ。Subversion の開発者たちには CVS の短所が痛いほど分かっていたので、彼らは高性能で現代的なバージョン管理システムを設計することに特に重点を置いた。

集中から分散へ

リポジトリを集中させるか、または分散させるか。分散させ、かつどこかにマスターを置くハイブリッド型か。これらはスタイルの違いであり、どれが優れていて何が劣っているというものではない。プロジェクトとチームの特性に応じて適切なものを選択するのが賢いやり方だ。

だから、Git が現状(2009年末時点)で最高の VCS であり、他の VCS を使うことなど考えられない、などと言うつもりはない。しかし、個人が自分自身の活動を管理するために使うとしたら、Git のような分散タイプ、それもリポジトリ間に優劣の差(マスター/スレーブ)がない平等分散リポジトリタイプをサポートするものが良い。他の分散 VCS も「平等分散リポジトリ」をサポートするなら、あとは好みの問題だ。

個人の復権

GitHubの登場はコミッタを特権階級から追い落とす革命だった - Hello, world! - s21g

かつてはメンテナやコミッタが専権的にソフトウェア開発の決定権を握っていた構造が、Git/GitHubの登場によって、気がつかないうちに崩れ去っている。これはソフトウェア開発史上、非常に大きな出来事なんだろう

不思議なものでオープンなはずの、オープンソースソフトウェアでは↑のような状況が存在するのだという。一方で、クローズドな環境である企業の開発現場では、リポジトリの管理(昔はライブラリアンと呼ばれた)はメンドウなだけの労働であることが多い。誰も進んでやりたがる業務じゃない。そこでは管理者(マネージャじゃないよ、英語でいうならアドミニストレータ)は特権階級なんかじゃない。むしろ下働きだ。誰かがやらないといけない作業、大事なんだけど報われることの少ないロール。

オープンソースソフトウェアのプロジェクトにおいて、リポジトリに対する権限が開発者間に階級を生んでいるのだとしたら、そしてそれが開発者の間に感情の軋轢を生じさせるのならば、それはプロジェクトの特性に適していない管理方式なのだ。その場合、Git のような分散かつ平等なリポジトリを持つシステムは救いになる。

皆が自分のリポジトリを持ち、誰もマスターではなく、またスレーブでもない。ソースコードはブランチすることが前提で、世界中にさまざまな変種が存在する。誰もが自由にプッシュでき、誰もが自由にマージできる。ソフトウェアを中央のコミッタがデザインするのではく、個々のプログラマが自らの用途に合わせ、思うままにアレンジできる。何が正しくて何が間違っているのか、プログラマ自身が決めることができる。個人としてのプログラマの復権だ。

あとひとつ。Git のもたらすこのビジョンこそ、ソフトウェアの再利用というプログラマの(古くからの)夢を実現するものじゃないだろうか。再利用すべきはバイナリじゃない。ソースコードだ。皆がリポジトリを持つことで初めてそれが可能になる。