homebrewで複数versionのformulaを切り替えるには エンジニアなら、バージョン依存との戦いはだれもが頭を悩ますところですよね。 「このバージョンではバグがー」やら「Pull Requestは出てるけどmergeされてなくて」などなど。

最近ですとPowのv0.3.2はNodeのv0.6系と相性が悪かったりします。masterでは修正されているらしいですが。 メインの開発プロジェクトでは0.6系を使いたいけど、こっちのお気楽プロジェクトではpowりたいから0.4系が必要なんです><

そんなとき、homebrewではどうするか？答えは簡単、 switch しましょう！ homebrewには外部コマンドという位置づけでhelpには載ってないコマンドがいくつかあります。 その中の一つであるswitchを使えば即座にインストール済みformulaのバージョンを切り替えることができます！

Switch between installed versions of . If you have multiple versions of a formula installed, the standard brew link command will fail. switch tries to unlink all versions from HOMEBREW_PREFIX, then [re]links the requested version.

こんな感じ

便利ですね！！ (といっても、シンボリックリンクはりなおしてくれてるだけのような気もしますが)

ところでこの外部コマンド群、他にも色々かゆいところに手が届きそうなものが揃っているようですよ。 リンク先をご参照ください。

External Commands - GitHub

便利ですよね、git。

使い始めは、ステージに感動しました。 任意の変更だけをコミットすることで、それぞれのコミットを簡潔かつ整ったものにしておけます。

しばらく使っていて、今度はブランチの扱いがとても容易だった事に感動したと記憶しています。 トピックブランチで作業することにより、masterはつねに稼働可能な状態を保ちつつ、大規模な修正や機能追加も恐れることなく作業できます。 さらに、トピックブランチとしての作業記録が残ることによって、一連のコミットをグループとして認識可能になります。 このブランチングと、それに伴ってコミットログを綺麗にしておけることこそが、gitを使うキモであると考えています。 git習熟度は「いかにコミットログを綺麗にわかりやすくしておけるか」に大きく影響してくると断言できましょう。

では、綺麗でわかりやすいコミットログとはどんなものなのか？ これは、一概にはいえない部分があるのです。 多人数での開発では、ブランチングでの作業に何らかの指針があるかと思います。 その場合、それに従うのがわかりやすく、綺麗なコミットログということになるでしょう。 個人の場合は、常にmasterだけで作業するという話をたまに聞きますが、それでは綺麗なコミットログにはなり得ないと考えています。 適宜ブランチを切って作業し、どういった形でマージするかまでを考えてやることによって、初めてコミットログは美しくなるのです。

fast-forwardマージにするか、ブランチを残しておくか、はたまたマージコミットはどうするか等マージにはさまざまな手法があります、 どれを選択すべきかは時と場合によって変わってきますが、一つ覚えておいても損はないオプションが--no-commitです、 マージ時に自動的にコミットしないというオプションです。 fastforwardではないマージの場合、 自動的にMerge branch 'here-is-banch-name' into masterといったようにマージコミットがなされます。 このマージコミットがなされないのです。

これのなにが嬉しいのか？どんなときに使うのか？

わたしは、トピックブランチ作業中にすすんでしまったmasterの変更を取り込むときに使うことがあります。 Merge branch 'master' into topic-branchよりもImport update of masterというコミットコメントのほうがコミットを正確に表現しているとの考えからです。 masterの更新に追従する場合、rebaseを使うこともあります。 個人的には、トピックブランチの一連のコミットが完了してmasterにPull Requestを送る必要がある場合にはrebaseを、masterの変更を取り込みつつもさらにトピックブランチで作業を継続したい場合にはno-commitでマージを選択する傾向があります。 rebaseは便利ですが、マージの手法によってはブランチが残らない状況を生みやすいことや、コンフリクト時の対応が複数回必要となる場合があることを考え、使用を控える場面があることを書き添えておきます。

もう一点、これはおそらく余り正当な使いかたではないでしょうが、他ブランチとコンフリクトが発生しないかのドライラン代わりに使うこともあります。 no-commitでマージし、git statusを確認。 コンフリクトしてるファイルはないかどうかをチェックするのです。 そのままマージしてしまうこともあれば、git reset --hardすることもあります。 特に多人数で協調作業する場合、マージ時のコンフリクトを予め避けておくことは非常に重要ですから。 また、オープンソースのプロジェクトにPull Requestを送る場合は、適切なブランチングとともに各コミットを適切なサイズに分割しておくことも必要ですよね。

–no-commitでのマージはもちろん、本エントリでは言及しませんでしたがgit merge --no-ffさらにはgit rebase -iをいとわず、綺麗でなおかつコミットの意図、ブランチングの意図が反映された美しいコミットツリーを形成していきましょう！

地味にめんどうなんですよね、Octopressでローカルプレビューするの。

普通にやるとするとrake generateでmarkdownを変換して、rake previewでローカルでjekyllを起動してブラウザで確認といった流れ。 エントリ投稿毎に再構築とか、なんかウェブログという言葉がメジャーになり始めた頃を思いましますね。 さておき、少しの変更のたびにコマンド2発、エディタとターミナルとブラウザをいったりきたりする必要があります。 そこで、やっぱりPowですよ。 rake previewせずにpublic/index.htmlをブラウザで確認できるようになります。 また、rake watchを使えば編集中のファイルを保存した時点でエントリを再生成してくれるので、rake generateが不要になります。

なんですが、公式ドキュメントにも書いてるので自力でOctopressを使えるひとなら言わずもがなですよね・・・

2011年のまとめ兼2012年の抱負みたいな、まとまりもとりとめもないテキストのはずです、これ。

そうそう、昨年終わり頃に最新型電気カイロを買いました。ポケットに入れておくとけっこう暖かいです。しかもWiMAXテザリングができたり、なかなか高機能です。

はい、メイン回線をWiMAXに切り替えたのです。据え置き用にはURoad-Homeを使っています。 あらゆる壁がコンクリート用ピンでも歯が立たずカレンダーをかける場所にすら困る鉄筋コンクリート賃貸住宅のわが家ですが、電波状況は5段階で2。弱めではありますが、必要十分な速度はでています。

切り替えたのは、会社から固定回線の利用補助がでていたのですが退職とともに失われてしまったから。 無線LANにしていたとはいえ、ルータ等で必要だった電源などの醜い配線がなくなりとても満足しています。 仮に転居するとなっても、ネットワーク断絶することがなくなるわけで素晴らしいですね。

転機

退職というか、転職ですね。昨年は大きな転機をむかえました。 「ゆるやかな死を脱せたので、これからは『いかに生きるか』」といったようなことをFacebookに書いたのですが、それがだいたい全てだと思います。 経済的な面はもちろん、エンジニアとして前職で与えられたキャリアを積み上げていくのに危機感を感じていたところを、転職という形で脱出することができました。 それによる今のところの一番大きな変化としては「まだ18時か…」が「えっ、もう22時?!」になったことでしょうか。

現状を変えるべくコードをgithubで公開したり、ブログを書いたりといったことにプライベートの時間を費やしてきたうえで訪れたチャンスであったわけですが、期待にそえるようなアウトプットをはたして出来ているものか。 前述の活動によるなけなしのインプットを隅々まで掻きあさり、さらには周囲の方々の力添えによってようやくその日のコードを生成しているといった状況です。 自分が一番の下手くそであるという情熱プログラマー的には最高な状況はとても大変です。 しかしながら苦しくはなく、とても楽しい。 ますます精進し、成長していきたいですね。 それと、github上でのオープンソースにPull Requestを送ったり、また送ってもらえたりといった活動ももっとしていけたらいいなぁ。

このブログについて

今までは、ウェブに公開する文章は主にはてなダイアリーに置いていました。 そして、それ以外にも開店休業中のブログ等がいくつかあったりします。 これからは、ある程度まとまった量の文章は、このブログに置いていこうと思います。 転職を思い立ってからのウェブ上の活動によって、はてなダイアリーは技術よりの内容が主でしたが、ここでは他のことも色々と書けたらいいかなー程度に考えています。 運用してみないと、実際どうなるかはわからないですね。

ちなみにここは、github:pagesとOCTPRESSによって成り立っています。 ドメインを取るほどには力を入れるわけではないですが、それなりに自由にできそうなのが良いですね。 また、エントリを生成する過程で、git、markdown、rakeといった（粒度バラバラですが）つぶしのきく技術を使えるのも良いです。 デザインなんかも、いじりたいですね、おいおい。

そんなところでしょうか。 ハロー2012年！