System.Exit

入門git でびあんぐる オーム社 2009-08-12 売り上げランキング : 2359 Amazonで詳しく見る by G-Tools

これ読みましたー。
最近は日常的に git を使っててそこそこ詳しくなってたつもりだけど、基本をちゃんと抑えておくという意味でこれは読んで良かった。

久々にブログ書いてるので文章がうまく書けません。

git のインストール

えっと。
そうそう、git はソースから入れるのが一番いい気がした。

以下のようにするとドキュメントもインストールされていいらしい。

make prefix=/usr/local all doc
sudo make install install-doc

Mac の場合は以下のようにすると git-svn も入るしいい感じっすね。

sudo port install git-core +svn +doc

git diff

git diff はたぶん一日一万回くらい使ってるけど、このを本読むまで --cached オプションなんていう便利なオプションがあるのを知らなくてすごく損してたなーと思った。
git diff をオプション無しで実行すると、git によって管理されていてかつまだステージされてない（index に入っていない、つまり add してない）変更の差分が出力される。
git diff に --cached オプションを付けて実行するとステージした変更と HEAD との差分を見ることができる。
今まではそういう差分を見るためにわざわざ git commit -v を使ったりしてた。
git diff には --stat なんてオプションもある（使ってないけど）。

git blame

そうそう、git blame を使えるようになりたいと思いつつも全然使ってない。
あ、普通に使う分には git blame README.rdoc とかやればいいのか。
そうすると以下のような感じでファイルのどの部分を誰が編集したのかとかがわりと簡単にわかる。

...
da557a52 (jugyo         2009-03-24 20:51:04 +0900  43)   % sudo gem install termtter
43752d7d (mattn         2009-01-08 14:13:28 +0900  44)
31e0dd9c (jugyo         2009-03-24 15:19:12 +0900  45) == CONFIGURATION:
a9a95484 (ujihisa       2009-01-06 18:43:43 +0900  46)
cd062ba3 (jugyo         2009-03-24 15:21:25 +0900  47) Termtter generates a configuration file named '~/.termtter/config'.
a9a95484 (ujihisa       2009-01-06 18:43:43 +0900  48) You can edit the file anytime.
d5ad26db (jugyo         2009-01-05 15:28:09 +0900  49)
da557a52 (jugyo         2009-03-24 20:51:04 +0900  50)   % vim ~/.termtter/config
...

行を指定する場合は以下にように -L オプションを使うのか。

git blame -L 10,20 README.rdoc

なるほどね。
さらに -L オプションには正規表現を指定できるらしい。

git blame -L"/def call_commands/",+10 lib/termtter/client.rb

これは便利だ。
git blame の出力に色が付いたらもうちょっとわかりやすいのにな。

git rebase -i

git rebase で個々のコミットをいじくり回すなんてことは今までやってなかったけど、この本読んで git rebase -i をやたら使うようになった（-i がポイント）。
git rebase -i は対話的に rebase を行うためのコマンドで、素晴らしく便利です（使い方は本書を読んで調べてください）。
僕はだいたい人間がやりそうなミスは一通りやってしまうたちなので、「あのコミットにこれも入れておけば良かったー」というような状況がしょっちゅうあって、そういう時に git rebase -i とか git commit --amend はとてもとても役に立ちますね。

branch と rebase について

branch と rebase について理解しないで git を使うのは結構つらいと思うけど、逆に考えるとそれらをだいたい理解していればたいていの場合はなんとかなる（はず）。

github T シャツについて

「入門git」とは全然関係ないんだけど、こないだ github T シャツを勝手に作った。

というわけで、今すぐ買うといいと思うよ！

入門git でびあんぐる オーム社 2009-08-12 売り上げランキング : 2359 Amazonで詳しく見る by G-Tools

Amazon EC2/S3クラウド入門 学びing 秀和システム 2008-12 売り上げランキング : 1837 Amazonで詳しく見る by G-Tools

わかりやすくて良かったです。

EC2 や S3 なんかについては、なんとなくしか知らなかったのですが、これ読んで知った気になれた。文字通り「知った気になれた」だけで、実際に使う段になってまたいろいろ苦労するんだろうけど、知った気になれていると不安がかなり減るので良い。「ああいうふうにやって、あそこに気をつければいいんだな」みたいに、自分が実際に作業をしているところをイメージできるようになった。

僕を含め多くの人は、よくわからないものをデフォルトで怖がる（または敬遠する）ように初期設定されているんだと思う。

プログラミング言語 Ruby 卜部 昌平 (監訳) 長尾 高弘 オライリージャパン 2009-01-26 売り上げランキング : 14678 Amazonで詳しく見る by G-Tools

これ読みました。
これ読んでRuby技術者認定試験受けたら合格しました。

ひとりっ子 (ハヤカワ文庫SF) Greg Egan 山岸 真 早川書房 2006-12 売り上げランキング : 106272 Amazonで詳しく見る by G-Tools

これ、かなり面白かった。
グレッグ・イーガンは最高のSF作家だと思う。

以下は印象的だったところ。

「まじめに言ってるんだよ。仏教の神秘用語じゃなくて。これは現実の話だ。きみが自分の行動規範をつらぬけば、当然ものごとはきみにとってうまくいくーーそのために命を失うことがなければ。それが心理学の初歩だ。人間は、相互関係の感覚、他人からうけるあつかいが適切かどうかを判断する感覚を、高度に発達させている。自分にとってものごとが順調すぎると、『これに値するようなことを自分はしただろうか？』と思わずにいられない。そして納得できる答えが見つからないと、自分を責める。つねにではないが、かなり頻繁にだ。というわけで、自尊心がふくらむような高度をとったあとーー」

プラネット・グーグル Randall Stross 吉田 晋治 日本放送出版協会 2008-09 売り上げランキング : 9664 Amazonで詳しく見る by G-Tools

面白かった。
最近の話題まで、よくまとまってる印象。
だいたいがなんとなく知ってたような内容だけど、通して読むとより鮮明に見えてくる感じがする。
Google について知った気になれる本。

LinuxサーバHacks―プロが使うテクニック&ツール100選 Rob Flickenger 山口 晴広 イメージズアンドワーズ オライリージャパン 2003-11 売り上げランキング : 93707 Amazonで詳しく見る by G-Tools

これ、なかなかためになった。
ていうか、Linux にまつわることで知らないことってやたらあるなぁ。
知らないと損することがたくさん。

もっと本読まないと。
最近全然本読めてないんだよなぁ。
なんか、邪念が多すぎる。
一つのことに集中できていない。

ソフトウェア開発者採用ガイド 青木 靖 翔泳社 2008-03-20 売り上げランキング : 12836 Amazonで詳しく見る by G-Tools

これ読んだ。
いやー、Joel の文章はどれもいい。
書いてある内容もそうだけど、とにかく文章がいい。
例えるなら、めちゃくちゃいい絵を描く漫画家みたいな感じ。
こんなふうに書けたら（描けたら）いいなぁと思わせる。

印象に残ったところをいくつか引用。

この６年の間、友人のマイケルと私でソフトウェア会社を率いてきた。私たちは最初の最初から第一に優先することは優れた人を採用することだと考えていた。どんなソフトウェアを作るか考える前からだ。そうしてその年月の間、優れた人たちが私たちのところで働きたいと思うようにすることに注力し続けた −− まだ誰かを雇えるようになる前からだ。私たちはいくつか間違いをし、そこから多くを学んだ。今では優れた人を得るというのは Fog Creek にとって唯一問題を感じないことと思えるほどになった。

逆にいうと、すごいアイデアがあったとしても優秀な人間がいないと実現に至らないんだよなぁ。
金で技術は買えるかもしれないけど、見極める力がなくて間違った技術を買っちゃったらどうするの？、とかも思う。
A ランクの人は自分よりも能力のある人を雇い、B ランクの人は自分よりも能力が劣る人を雇う、みたいな話があったな。

ソフトウェア会社を作るのは、それまで解けなかった何かの問題を解決する巧妙なアイデアを見つけて実現し、それによって富を得るのが目的なのだ、と一般には信じられている。これを「より良いねずみ取り作りの信条」と呼ぶことにしよう。しかしソフトウェア会社の本当の目的は、資本を役立つソフトウェアへと変えることであるべきなのだ。

Joel が言いたかったことからは若干ずれるかもしれないけど、最近僕はこんなふうに考えてる。
「誰でもすごいアイデアを思いつけるわけじゃない」
というか、人間の発想なんてたかが知れてる。
すごいアイデアで何かを成し遂げたい！って思うのは、そうすることがすごく魅力的に見えるからだと思う。
なぜそれが魅力的に見えるかというと、すごいアイデアで何かを成し遂げるということができていない今の自分が全然魅力的に見えないからなんだよね。
状況を変える何かが欲しいんだよね。
とにかく努力あるのみ。
中途半端な努力で思いつくようなアイデアなんて誰もが思いつくようなものばかりだと思う。

開発者が現在の作業のために最適でないプログラミング言語を、それがボスの好みだからという理由で使うように言われることほど、彼らを憤慨させることはない。人々が厳格に能力によって昇進するのではなく、コネによって昇進することほど、彼らを怒らせることはない。組織で自分より上にいるか、より強いコネをもった人間が要求しているために、技術的に劣った方法でやらなければならないということほど、彼らをムカつかせることはない。

まあ、これはその通りですね。
プログラマじゃなくてもこういう事態になったら普通怒ると思うけど。
ただ、ちゃんとした根拠もなく最新の技術を使いたいとかお気に入りのフレームワークを使いたいとか言うのはちょっと違う。
あくまでその状況において最適な技術・ツールは何か、ということをちゃんと考える必要がある。

私たちの信条は長期的視点で採用するということだ。現在たまたま知っているどんな技術も、来年には古くなっている可能性がある。しかもそれらの技術の中にはいとも簡単に学べるものもある。 [略] 基本的に優れたソフトウェア開発者には、別なプログラミング言語を学ぶというのはまったくたいしたことではないのだ。彼らは２週間で非常に生産的になっていることだろう。２年後には、まだ発明されていないプログラミング言語でまったく違ったことをやってもらっているかもしれない。

これもその通り。
Joel の話からはちょっとそれるけど、僕が前から思っているのは「PHP しか知らない人は PHP すらも知らない」ということ。
他の言語を理解するということは、その言語の理解も深めることにもなる。
そもそもプログラミングを学ぶというのはそういうことだと思うんだけどなぁ。
あ、Lisp 勉強しないと。

問題のある開発者の多くは、単純に優れた開発者になるための素養を欠いているものだ。頭は良いがポインタや再帰を決して理解できない人がいるというのは私が強く思っていることだ。

そうかもしれない。