コグノスケ

D端子の力を見たまえ

Sena氏とジョーシンに行ったら、Wii用のD端子ケーブルがあったので買った。WiiはもちろんSena氏のものです。いいんです。

昔PS2を買った当初、綺麗だ綺麗だと言われていた画面がさほど綺麗じゃなくてがっかりしておりました。期待しすぎたのかなあ？って諦めていたのですが、映像ケーブルを替えたら（コンポジット →D端子）、見違えるほど綺麗になって…感動しきりでした。

Wiiの底力がこんなぼやけた画面のはずはないのです。これはつまり、ケーブルを替えればPS2の時の感動がもう一度なのです。

というわけで早速、氏の部屋に乗り込んで交換し、Wiiの電源をぽちっとな。

なんということでしょう！匠（任天堂）の技（高額な周辺機器）によって、再びぼやけた画面が…映し出されて？っておい、何も変わらんではないか。

何か間違ったのかと思ってコンポジットに戻し比べましたが、ほとんど違いがわかりません。テレビ側がD1しか対応してない、なんてことはないだろうし。WiiはD端子もコンポジットも同じ画を出してるのかなあ？

起きたら

夕方。これ定説。…おやすみなさーい。

腰砕け

メールでSena氏を晩飯に誘ったら用事があるから遅れる、先に戻っていてほしい、とのこと。ほいきた、とこんな返事を書いた。

（変換前）ようじがすんだられんらくください。（用事が済んだら連絡下さい。）

（変換後）幼児が住んだら連絡下さい。

あまりにナイスな変換に電車の椅子からずっこけた。前に居た人に「何や？こいつ…。」という顔をされた。

そしてそのまま送ろうかと思ったけど、なんとか踏みとどまりました。いやはや、通勤時間もなかなか捨てたもんじゃないな。

不思議がいっぱい

春のことだったか、定期券を継続申請しにみどりの窓口へ行ったら、なぜか長蛇の列ができていました。今日って何かあったっけ？とか思いつつ並ぶ。

ふと気付くと、自動販売機とずっとお話ししている人が居るじゃないですか。暇なのでその人をずっと観察することにしました。

見た目は普通のおばちゃん。どこかに行きたいらしくて、自動販売機と会話し（でかい独り言？）ながら目的地や出発地を選ぶのですが、そのボタンを押せば買えるのに！ってところでなぜか取り消します。ずっと同じことを繰り返して自動販売機とお話ししています。

自販機は一台しかない上に、おばはんは後ろに人が並びまくっててもガン無視。やがて並んでいた人達が諦めて窓口に並び直す…。そりゃ窓口も混みますわな。

自分が定期を買い終わってもなお、おばはんは自販機とお話ししてました。駅員が暇だったら構いに行くんでしょうけど、この長蛇の列では無理か。駅員にも客にもイイ迷惑ですね…。

常識を疑います

我々、金もらって働いてるいい大人ですよ。普通は共用物って綺麗に使うもんですよね。

何の話かというと、寮の洗濯機が汚いんです。今年度に入ってから特にひどく、しかも気にしない人が多いのか大抵汚いまま放置されています。タダで使わせてもらってる共用物の簡単な掃除くらいしても良いんじゃないですか。

洗濯槽に黒い点が見えます

先ほど、溜まった洗濯物を一気に洗、あ…アッーー！！服が黒いホコリと髪の毛まみれに。

ゴミ取りネットは綺麗にしたのにおかしいぞ？と、他の洗濯機を調べてみればゴミ取りネットを放置しすぎて、ゴミが取り切れなくなり「洗濯槽」にまでゴミが堆積していたのでした。黒い点や髪の毛が洗濯槽に散乱しています。きたなっ！

一体何回放っておいたらこんななるのん。いやそんなことより、だ。自分の服を洗濯するってときに洗濯機のネットが気にならないのはなぜだ？自分の服を綺麗にする気がないのか。

洗ったばかりの服はカビくさいです

まだある。洗濯直後に蓋を閉める人が居て、洗濯槽がカビ臭くなり服にカビ臭が移るようになりました。洗濯機が1台ご臨終でございます。

そもそも寮の洗濯機は屋内設置なんだから、雨なんか入らんし、毎日誰かが回すからホコリも積もらないでしょうが。蓋なんか閉めなくてもいいだろがー。

何を気にしているのか知らんけど、いつもいつもいつもいつもご丁寧に全ての洗濯機の蓋が閉まってる。他の洗濯機がカビる前に、気付いてくれ…。このままだと全ての洗濯機が腐ってしまう。

洗濯機に靴が入っていました

極めつけが、洗濯機で運動靴だのサンダルだのを洗う輩がいること。短期間に2回見かけたけど、複数人か、常習犯？実に気分が悪い。

「洗濯機で靴を洗えることも知らない？そんなことも知らないなんて可哀想ですね(　´,_ゝ｀)プッ」
んなもんは自分の洗濯機で好きなだけやればいい。誰も止めないから。

寮で靴を洗ってる奴を見かけたら言ってあげると良いでしょう、
「誰が履いたか、どこを歩いたか、何を踏んだかもわからん靴を洗った後に、あなたのおしゃれ着を洗いたいですか？」
とね。

ついて行けません

つらつら書いてますが、わたくし、別に潔癖性でもなんでもないです。真のきれい好きだったらとうに寮を出てますし。

それなのに今年の洗濯機事情にいらつくのは、汚いからよりは、共用物の扱い方が悪すぎるからですね。シンプルに「後に使う人が今の状態を見たらどう思う？」と、ほんの数秒考えるだけで解決するのに…。

何これきめぇｗｗｗ

天橋立の日記を書いていた（今更）ら、自分の話声が入ったムービーが出てきた。

自分の話し声ってなんつーかキモいぞ。ずっとこんな声で話しかけていたのかと思うと、なんだか申し訳ない気分になった。

ぱわぽーいんと

先日注文したMicrosoft PowerPoint 2007が届いたので早速インスコ。

噂の使いづらさに絶句するかと思いましたが、リボンインタフェースでしたっけ、そんな言われているほど悪くないと思います。

ただ配置をアグレッシブに変えすぎたせいで、覚え直すのがかなり面倒です。巷で使いづらいと文句を言っている人の大半は、恐らく今の私と同じ心境なのでしょう。

Officeの箱は正直邪魔くせーです。しかも妙に立派なので捨てるも忍びないのです。CDと小冊子しか入ってないくせになんでこんな分厚くするんだか。同時に注文したOffice Personalが届いたら一緒に並べて写真でも撮って載せますか。

さいのみやこ、彩都（さいと）へ

車でガーデンモール彩都（大阪府茨木市）へ行きました。大阪モノレール彩都西駅のすぐそばですが、電車で行こうとすると2回も乗り換えなければなりません。しかもモノレールの料金がアホみたいに高い（往復で1,000円超）から、電車でなんか行けません。馬鹿馬鹿しい。

さいのみやこ、と書いて彩都（さいと）とは、さいたま市顔負けの恥ずかしさですね。

モスバーガーでご飯を食べた後、ガーデンモールを一通り見ました。つくばのララガーデン的なショッピングモールを想像していたのですが、全然違った。店は平和堂（スーパーマーケット）、本屋と、100均の店が離れて建っているだけです。うーん。率直な感想は「中途半端」だな…。

新興住宅地らしくて、周りの道路や建物は綺麗です。いかんせん人が居ないね。

体力の限界がきたらしい

最近の規則正しい生活にはやはり無理があったようです。ついに限界が来ていつもの生活に戻ってしまいました。

昼まで寝てSenaさんの「昼飯くわねー？」メールで起きる生活。ああ…これだよ、これ。やっぱり休日はこうでなければ。

飲み会

同期の人と飲み会しました。一応合コンという触れ込みだったのですが、知り合いは合コンとは言わんよなあ…。

四条駅近くのレストランIRO（京都府京都市下京区）というところです。

混んでいたらしく料理が全然出てこなかったり、かと思えばすげー早く出てきたりして店員さんがパニクってた模様です。

京都の飲食店でバイトなんて絶対やりたくないな…と思った。

奇跡の一週間

ここ一週間、目覚ましより早く目が覚め、一切寝坊もせず、電車にも余裕で間に合う、そんな朝が続いています。

こんなことは去年一回もありませんでした。一体どうなってるんだろう。まさかどこか体を悪くしたのではなかろうか…？

推奨

友人と話していたら、水曜日は定時退社推奨日だよね、って話になった。そういえばそんな日だったかな。誰も実践していない気がするんだけどな…。

Mercurial Mini HOWTO

分散リポジトリ型のバージョン管理システムMercurialの簡単な説明と操作法を書きます。

そもそもバージョン管理システムって何さ？という話はしません。全て説明するのはここでは無理です。世の中には良い書籍がいっぱいありますんでそれを読んでね。

はじめに - Subversion以降のリビジョン番号について

CVSとSubversionの差は色々あるけれど、リビジョンの考え方が激変しました。これは大事だと思うから説明します。

CVSではリポジトリに対する変更をファイル単位でコミットし、リビジョン番号もファイルごとに振ります。

一方Subversionはリポジトリ全体に対してリビジョン番号を振ります。ファイル一つ変更するだけでリポジトリ全体のリビジョン番号が上がるのです。

Subversion等のリビジョン番号

図中の丸印が「ある時点のリポジトリ」を表しています。リビジョンを何かに例えるなら写真の番号でしょうか。コミットは「リポジトリ全体を写真に撮って、番号（＝リビジョン）を付けること」に相当します。

リポジトリには今までの全写真と番号が保管されていまして、好きな番号で写真を引っ張り出せます。二つの写真の間違い探し（diff）もできて、被写体（リポジトリ）がどれだけ変わったか（ファイルの追加、変更などの変化）が簡単に追跡できます。

便利な例を一つ。一週間前から今までの全変更点を追跡したくなったとします。

CVSですとリビジョン番号はファイル毎に付くので、一週間でファイルAはリビジョン100進んで、ファイルBはリビジョン1も進んでないなんてことが起こります。一週間前の状態に戻そうとすると、ファイル毎にどのリビジョンを見るべきかチマチマ調べなければなりません。

Subversionならば一週間前のリビジョン番号を調べ、そのリビジョンにリポジトリを巻き戻すだけ（update -r revision_number）です。すると全ファイルが当時の状態に戻ります。タイムマシンのようですね。

Mercurialもリポジトリ全体にリビジョン番号を振る方法を採ります。他のSCMもたぶんそうでしょう。

集中型リポジトリとの違い

区別のためにMercurialの管理方法を分散リポジトリ形式、Subversionの管理方法を集中リポジトリ形式と呼びます。正式名称は知らないです。

集中リポジトリ形式ではリポジトリは一つだけです。利用者はリポジトリの一部をコピー（checkout）していじって、変更を反映（commit）したり、他者が行った変更を取り入れ（update）て使います。

Subversionはさらにローカルにリポジトリのキャッシュを持っていて、diffやstatusコマンド実行の際、リポジトリとの通信が不要です。この機能はリポジトリにアクセスできない状態（オフライン）でも使えるのでとても便利です。

Subversionのリポジトリ

Mercurialは分散リポジトリ形式の名の通り、リポジトリがいくつもあります。大きく3つの領域に分類できます。

他人のリポジトリ

他の人が変更しコミットしているリポジトリです。他人の〜と言っても誰が作ったかではなくて、ローカルリポジトリ以外のリポジトリは全て他人です。
どこにあっても良いので、オフラインではアクセスできないかも知れません。

ローカルリポジトリ

自分がコミットする対象としているリポジトリです。HDDなどに置きます。オフラインでもアクセスできます。

作業コピー

実際に作業してファイルを変更する場所です。変更後はローカルリポジトリにコミットします。

以下の図でイメージを掴んでいただけるかと思います。

Mercurialのリポジトリ

実はmercurialの場合、ローカルリポジトリと作業コピーが同一の場所にあります。実用上は便利なんですが。説明する側から見るとやりづらいっすね。

オフラインでリポジトリにcommitできること、これこそが分散リポジトリ型の最大の利点です。
絵から分かる通りupdateもできます。オフライン状態でローカルリポジトリを変更できるのは自分だけだから意味無い？なんてこと言うんですか…。updateの節で詳しく説明しますが、バージョン管理のうまみはupdateで巻き戻せる点に有ります。

commit

作業コピーに対する変更点をローカルのリポジトリに反映させます。

push

pushできるのはリポジトリ同士なのでcommitしてからpushして下さい。そうでないと何も反映されません。

誰かが先にpushしていると、

$ hg push
pushing to /home/user/test-a
searching for changes
abort: push creates new remote heads!
(did you forget to merge? use push -f to force)

と警告されます。headとは最新状態のことです。ある地点を基点にブランチで枝分かれしていき、枝の末端が最新版となります。末端なのにheadというのも何だか変（※）ですけど、そういう用語なので仕方ないですね。

謎のキーワードheadがわかれば警告文の意味がわかります。このままpushすると最新の状態（head）が2つできるじゃない！何とかしなさいよ！！と言っているわけです。

図示すると以下のような感じです。

Mergeが必要な場合

この状態を解消するためには「誰かの変更」を取り入れる作業（pullしてmerge）が必要です。詳しくはpull, mergeの節を見て下さい。merge後はcommitしないと作業が進められなくなりますよっと。

警告文曰く、ブランチを作りたいならpush -fで作れるそうです。

（※）個人的にはleafの方がわかりやすいと思いますが、歴史的な経緯でしょうか？

pull

別のリポジトリにある変更点をローカルリポジトリに反映させます。さらに作業コピーに変更を反映させたければupdateをする必要があります。updateについては次節をご覧下さい。

update

作業コピーにローカルリポジトリの内容を反映させます。

他のリポジトリからpullした後は、通常はupdateをします。もし誰かが既に更新していた場合は「衝突」状態になります。その時は次節で説明するmergeを行って解決します。

別の使い方は「巻き戻し」です。○○という変更を入れる前に戻したい、1日前に戻したい、なんてことが簡単にできます。

merge(またはupdate -m)

他のリポジトリからpullした変更点をupdateしようとすると

abort: crosses branches (use 'hg merge' or 'hg update -C')

と、怒られることがあります。あなたがpullしたリポジトリに、誰かが先にpushしたことを表しています。

（ブランチの絵を入れます）

解消するためにmergeを行います。マージ用のプログラムが無い状態では、衝突したファイル名に .origが付加されてバックアップされます。

$ hg status
M a.txt
$ ls -1
a.txt
a.txt.orig

$ cat a.txt
a
b
c

$ cat a.txt
a
user a
c

$ cat a.txt
a
user b
c

同じ行を変更しているので機械的にマージが出来ません。するとマージプログラムは以下のようにlocal（自分の変更部分）と、other（他の人の変更部分）を示して、どちらか選んでよ、もしくは良い感じに修正してよ。

衝突したファイルはどうなるかというと、

$ cat a.txt
a
<<<<<<< local
user a
=======
user b
>>>>>>> other
c

修正後にcommitをお忘れ無く。

rollback(またはundo)

親リポジトリからpullした、あるいはcommitしたは良いけど、やっぱりやめたいときはrollback（またはundo） ができます。

ローカルのリポジトリを巻き戻します。最後にpull, またはcommitした部分まで戻りますが、二回以上は戻りません。

メモ置き場

後で調べて書きたいこと。

• ブランチの消し方？
• リポジトリを省略したときに操作の対象になるリポジトリの調べ方？
• 誰でも書きつぶせるのは危ない、アクセスコントロール、パーミッションなど？

とーどー(TODO)

• ビルド、make PREFIX=, PYTHON= あとはPYTHONPATHの設定あたり？
• statusとlog（tipまたはhistory）の説明も
• cloneとinitの説明も
• リポジトリ作成、clone -> コミット、プル、プッシュ、マージの一通りの流れ、実例交えて

使った感想

オフラインコミットは便利d(・∀・)イイ！

昔はそう思ってました、今はリポジトリが散らばりすぎて何だかわからなくなった俺ガイル…なんてことにならないように、ある程度の規模を扱う予定ならば運用ルールを敷きましょう。

本格的に使ってないので予想の域を出ませんが、リポジトリが大量にできるうえに全リポジトリが平等なので、集中リポジトリ型よりめちゃくちゃになりやすい気がします。