portal shit!

昨日と一昨日の二日間、TDD Boot Camp 福岡に参加した。

参加しようと思ったわけ

勤めている会社にはテストがない。いや、テストはある。エクセルにテスト項目をたくさん書き出していって手動テストだ。テストコードがない。人力で三人くらいが夜なべしてテストする（だいたいスケジュールには遅延が発生する）。これはどうしたっておかしい。開発前に要件定義書、設計書を書いて開発して、開発が終わったらエクセルで長大なテストシートを作成し、手動テストを行う。そしてバグや思わぬ不具合が発見されるとプログラムに改修を加える。欠陥や不都合が発見される度に連動して設計書にも修正・変更が加えられ、Do Repeat Yourselfな感じになってる。毎日毎日ドキュメント作成などの開発以外のタスクに時間を割かれるので新しい技術に触れる機会がないし、遅くまで残って仕事してから帰宅するので趣味プログラミングで知見を広めることもできない（福岡に来てからのこのブログの更新状況を見ればおわかりいただけるかと）。この状況をなんとかしたいと思っていて、藁をもすがる思いでTDD Boot Campに参加した。

感想

一日目は『プログラマが知るべき97のこと』の監修やTDDで有名な @t_wada さんのレクチャーで、TDDとは何かが説明された。以下印象に残った点。

• 良いテスト
  • 自動化されている
  • 徹底している
  • 何度でも実行可能
  • 独立している
  • プロのコード
  • テストコードもプロダクトコードと同じ品質であることが求められる（リファクタリング、DRY原則の貫徹など）
• TDD三原則
  • 単体テストコードを書く前に製品コードを書いてはいけない
  • 適切に失敗する単体テストコードができるまで、次の単体テストコードを書いてはならない
  • 単体テストコードに対応する以上に製品コードを書かない
• なぜTDDするのか
  • 自分が完璧ではないことがわかっているから
  • 最初から思い通りにコードを書けるほどに私たちは賢くない
  • 最初から思い通りに動作するほど対象は単純ではない
  • 素早く対象に近づき、フィードバックを得て方向修正をしながら開発を行う必要がある
• テストの目的は健康
  • 変化に対応できるのは健康体のコードだけ
  • 変化に対応できるのは健康体のチームだけ
  • 毎日残業する、毎日レッドブル飲んだりしていてはダメ
• TDDの導入効果
  • MSやIBMでTDD導入後、欠陥の割合が4割から9割削減された。
  • コード実装時間は15%から35%増加した。
  • しかし結果的にはバグが激減するので開発工数自体は減る。
• TDDは才能ではなくスキル
  • 練習すれば習得可能
  • 量は質に転化する
  • 写経しましょう！
  • PCにGitをインストールし、ページをキープできるブックスタンドを買って、ケント・ベック本をひたすら写経。ビルドを実行する度にコミットする。

テストのみならず、自動化やバージョンコントロールの重要性が説かれた。

二日目には @bleis さんによるGitの効果的な利用方法やJenkinsを利用した継続的インテグレーションの実践例、 @akineko さんによるOMakeを利用した自動ビルド、自動テスト、自動コミットの話など。

ペアプログラミングを体験した

ペアプログラミングを生まれて体験した。 @mallowlabs さんとRubyでペアプログラミングをさせてもらった。講師陣が出題する課題を解いていくというもの。当然テスト駆動。テスティングフレームワークにはRSpecを利用した。

WEB + DB PressなどのRSpec特集を写経したことはあったけど、時間制限がある中で、他の人とペアを組んでプログラムを書いていく作業はかなりエキサイティングだった。

ただ自分のRubyスキルおよびVimのスキルが著しく劣っていたため、@mallowlabs さんの足を引っ張っていた感は否めない。正直申し訳なかったです。

全般的に、自分の知識のなさ、スキルのなさが実感できた

以下、初日に行ったFizzBuzz問題と主に二日目に取り組んだTwitterのタイムラインをカテゴリ分けするという課題の成果物。

TDD Boot Camp 福岡 — Gist TDDBC でペアプロした結果です — Gist

TDDをいかにして根付かせるか

勉強会に参加していきなりコードが書けるようになるわけでは当然ないので、継続的な勉強が必要だと感じた。いっぱい本を紹介してもらったので積ん読本を何冊か片付けたら『レガシー・コード改善ガイド』と『テスト駆動開発入門』を買おうと思った。

1年2ヶ月お世話になった職場を10月いっぱいで退職しました。

僕は2009年の9月から、阿蘇テレワークセンターというところで働いていました。ここはISP業務やホームページ制作をやってる会社で、1年4ヶ月前、東京で就職したのにたった3日で辞めて帰ってきてしまった僕は、ここに拾ってもらってHTMLコーディングの傍らCakePHPによるシステム開発やWordPressのカスタマイズ、JavaScript開発などを担当していました。

前職場ではかなり自由にやりたいことをやらせてもらい、家で一人でインターネットで遊んであるだけでは身につかないようなことを経験できました。CMSを作るのはCakePHPやRailsを使ってもやはりそんなに簡単ではないですし、Linuxサーバーの構築などもやらせてもらって大変勉強になりました。1年2ヶ月前はTerminalなんてなるべくなら触りたくないと思っていたのに、いまはTerminalでVimやzsh使うのが大好きになりました。

しかし阿蘇テレワークセンターは自由すぎた。僕はRailsによるアジャイルWebアプリケーション開発なんかを読みながら、ウォーターフォール開発も経験したことないのに自己流で勝手にアジャイルやってました。いや、アジャイルじゃなくてただの行き当たりばったり開発ですね。これではいかんなーと思い、一旦阿蘇を離れてみることにしました。

11月からは福岡で働いてます。福岡、食べ物が安くておいしくてびっくりですね。出張などで福岡にいらっしゃる機会のある方はご一報の上、もつ鍋おごってください。

いやまぁテキストエディターにはいろいろあるわけでして、皆さんEmacsとかVimで日夜しこしこコードを書いておられると思うんですけど、僕はGUIしか使えない情報弱者なので主にTextMateを使ってます。

TextMateで便利なのが "Run" っていう機能です。Rubyのコードを書いていて、⌘ + R でさくっと実行結果を確認できます。いちいちTerminal開いて

$ ruby hogehoge.rb

とか面倒くさいことをやらずにすみます。

で、これからが本題なんですけど、先月Ruby 1.9.2がリリースされて、さらに gem update でRails 3が入るようになってしまったので、お試しでRuby 1.9.2とRails 3を使ってみることにしました。しかし1.8系を完全に捨てることは恐ろしいので、RVMを使って複数のバージョンのRubyを切り替えながらしばらく過ごしてみることにしたわけです。

上に書いたとおり僕ちゃんは情報弱者なのでTextMateに依存したコーディングライフを送っており、⌘ + R で動くRubyもRVMのRubyにしたいと思ったのですが、これが分からなかった。RVMのサイトを見たらいろいろごちゃごちゃやり方が書いてあるんだけど（RVM: Ruby Version Manager - Textmate Integration with RVM）、結局この通りにやってもうまくいかず。

しかし先ほどなにげなく

$ rvm 1.9.2 --default

としてあげたところ、TextMateでもRVMのRubyが走るようになりました。

RubyKaigi 2010に行ったのでその感想を軽く。

自分のスペック

Rubyは使い始めて8ヶ月くらい。元々何もできなかったのでいまも初心者レベル。プレゼンテーション聞いてても分からないことが多かった。

感想

永和システムマネジメント永和システムさんの「Head First ふつうのシステム開発」は面白かった。プログラミングのやり方を人から教わったことがないので、普通の会社はこうやって開発してるんだってのが分かった。テストの様子を見られて参考になった。あとVimがすごくカスタマイズしてあってすごかった。用事があって途中までしか見られなかったのが残念。

MongoDBについてのプログラム（Practical Ruby Projects with MongoDB）で、気にはなっていたけどよく分からなかったMongoDBのことがより一層気になった。情報の連結とかそういうコムズイことはSQLでやるんじゃなくてプログラム側でやるべき、ってことなのかな。

クックパッドのセッションも見学した。CTO氏が質疑応答で「専属デザイナーはいなくてデザインもできるプログラマーがデザインやってる」って言ってたのにびっくりした。大規模サービスをやってたら負荷分散のテクニックとか参考になったかもだけど、自分が作ってるサイトは多くても5000UU/日くらいなので「ふーん」という感じで聞いてた。

東京とつくばの移動に時間がかかったこと、他にも予定があったこと、帰りの飛行機の都合、などなどであまりゆっくり参加できなかったのが残念だったです。28日は用事があったので基調講演見られないから生Matzを拝むの諦めてたけど、Jeremy Kemperの基調講演がキャンセルになったかわりにトークセッションがあってて、そこにMatzも登場しててRubyの教祖を拝めたのでまぁ良かったと思います。あとジュンク堂RubyKaigi支店でで技術書買いすぎて散在した！

2010年9月26日修正

すみません、永和システムマネジメントさんのことを「永和システムさん」と書いてました。はてブのコメント欄で角谷さんに指摘されてた！

シャレオツプログラマーはみんなMacPortsからHomebrewに移行しつつあるっぽいので、真似してみることにした。

なんでHomebrew？

そもそもなんでみんな移行するのか？ なんかMacPortsはバッドノウハウの塊らしい。

twitter.com

MacPortsの何がバッドノウハウなのかちょっとよく分からなかったんだけど、でもよく考えてみたらMacPortsは .bash_profile とか .zshrc とかにへんてこりんなパスを埋め込まないといけないし、PerlとかRubyは一行目に

#!/usr/bin/perl

とか

#!/usr/bin/env ruby

とか書くのに使ってるバイナリ本体は /opt/local/bin/ にあるとかは気持ち悪いっちゃ気持ち悪い。

HomebrewはLinuxのパッケージ管理ソフトみたいに /usr/local/bin/ とかに何でもインストールするので精神衛生上ベターだ。

Homebrewのインストール自体はとても簡単。パッケージ管理スクリプトをRubyで書くってのも、UNIXのことよく分かってない僕にはなかなかよいかもしれない。詳しいことは公式Wikiとかを見て下さい。

Page not found · GitHub Pages

mxcl.github.com

Vimのインストールではまった

Homebrew自体は簡単に入った。試しにVimをAppleがコンパイルしたVersion 7.2のものから新しめの7.3に上げて、ついでにRubyオプション入りでコンパイルしたかったので

$ brew install vim

してみた。しかしながら

Error: No available formula for vim

と出た。GUI版のMacVimはFormulaパッケージがあるらしいけど、フツーのVimはないらしい。「えー、自分でFormulaファイルを書かなきゃいけないの〜？」って感じだったんだけど、GitHubでテケトーに検索したらいろいろ出てきたので、 /usr/local/Library/Formula/ に vim.rb を作ってコピペした。

Page not found · GitHub · GitHub

GitHub is where people build software. More than 100 million people use GitHub to discover, fork, and contribute to over 420 million projects.

github.com

そんで今度は意気揚々と

$ brew install vim

してみたんだけど、なんとmakeに失敗する。Python.frameworkを参照してるときにエラーが出てるっぽい。

ld: warning: in /Library/Frameworks//Python.framework/Python, missing required architecture x86\_64 in file

Appleが配布したのではないPythonを使ってるとこういうエラーが出るとかなんとか外人が言ってる。

http://vim.1045645.n5.nabble.com/Python-link-errors-td1214971.html

vim.1045645.n5.nabble.com

要するに64bit版のPython.frameworkを入れれば良さそうだった。何も考えずにHomebrewで brew install Python とかやって /usr/local/bin/python に新しいPythonを入れてみたりしたんだけど、これは意味なかったっぽい。大人しくPython公式サイトからPython 2.7のインストーラーパッケージをダウンロードしてきてGUIでインストールした。

Releases

The official home of the Python Programming Language

www.python.org

その後、もう一度 brew install vim をしてみたところ、無事make完了。vim --version |grep ruby で

+ruby

となった。

まだApacheとかRubyGemsとかはMacPorts版を使っているけど、割と早い段階でHomebrewに移行して、シャレオツプログラマーの仲間入りをしようと思います。

やってみた。以下を参考にした。

http://www.taknado.com/en/2009/03/26/deploying-a-jekyll-generated-site/

www.taknado.com

これもうむかし.macとかについてたiBlogとかわらんわ。GUIのクライアントはないけど、VimとかCodaとか好きなエディタ（TextMateで日本語がネイティブに扱えたらなー）で記事書いて、gitで git push するだけ。

で、やり方なんですけどちょっとgitに慣れてない人には複雑かもしれない。三つgitのリポジトリを用意する必要がある。

まず記事を作成するパソコンでgitとjekyllのセットアップをしたあと、リポジトリを作る（リポジトリ1）。その後Dreamhostの公開ディレクトリでないところに空のリポジトリを作る（ git --bare init ）。ここでは blog.git という名前にしましょう（リポジトリ2）。そんでそこにリポジトリ1をpushする。その後リポジトリ2の /blog.git/hooks/ に post-update というファイルを作り、以下のように書く。ファイルに実行可能なアクセス権を与えることを忘れずに。

#! /bin/sh
unset GIT_DIR && cd $HOME/tech.portalshit.net/ && git pull

そんでもって git clone blog.git <公開用のディレクトリ名> する（リポジトリ3）。リポジトリ1から公開用ディレクトリにリポジトリがコピーされるので、この中に含まれる _site というディレクトリを panel.dreamhost.com で公開ディレクトリとして設定すると、git push する度にhookが発動されて、めでたく記事が公開されるという次第です。

まとめ

まとめると、

1. 記事を作成するローカルリポジトリ
2. ローカルリポジトリをpushするリモートリポジトリ
3. リモートリポジトリをcloneする公開用リポジトリ

の三つが必要なことを忘れないようにしてくだしあ。

これであなたもハイド博士だ！

FreeBSDでVimを起動しファイルを編集したあと、 :q でVimを終了させてるのに元のコンソールに戻らなくてなんか嫌だなーと思っていた。MacもUbuntuもDreamHostのDebianもVimを閉じると元に戻るのに、職場の本番環境のFreeBSDだけこれなの。ファイル編集前のコンソールの履歴とかを見たいこともあるので、Vimが終了したら元の画面に戻るようにしたいと随分長いこと思っていたんだけど、たったいまようやく出来たのでメモっときます。

ちなみにVimには restorescreen とかいうオプションがあるらしく、必死で.vimrcにこの設定を書いてたけど、これはなんかWindowsのVim専用のオプションらしいのでマカーやUNIXユーザーの方はこれを設定しても無駄です。

情報元は フルスクリーンアプリを終了したときに元のコンソールの状態に復元する - 技術メモ帳 というページ。

FreeBSDの場合、 /etc/termcap ってのの中にフルスクリーンアプリを終了したときにコンソールに戻るかどうかを設定する場所があって、こいつを変更すればよいらしい。

しかし自分はこのサーバーでroot権限を持ってない。なので cp /etc/termcap ~/.termcap したあと chmod 644 ~/.termcap して vim ~/.termcap し、自分の使ってるターミナルの環境に合わせて設定を変更してやるとOK。

僕の場合はMacの純正ターミナルを、シェルはzshで使っている。 echo $TERM してみると xterm-color と表示されるのでxterm-colorの設定が書いてあるところをいじった。

くわしくは上のリンク先を見てもらうといいんだけど、とにかく te ってのと ti ってのがあって、これをMacの場合は te=E7E[?47h 、 ti=E[2JE[?47lE としてあげればいい。そんでシェルの設定ファイルに export $TERMPATH=$HOME/.termcap と書いてやり、一端ログアウトして再ログインするとめでたくVimを終了したときにコンソールが復元されるようになります。