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をいかにして根付かせるか

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

先週、九州産業大学で行われたWordCamp Fukuoka 2011に行った。仕事でWordPress使う機会はないけど、福岡のWeb業界がどんな感じなのか知りたくて行ってみた。

WordPressは ゴンゴンの見た映画 で使ってて、前職場でもウェブサイトにブログを付けるときによく使った。また友達のホームページにも導入したことがある。以下そのときに書いた過去記事から引用だけど、

WordPress 2.7やMovable Type 4とかもそうですけど、ブログのなかで読者が触れる部分っていうのはここ数年のアップデートの中でもそうそう変化なくて、書き手が触れる部分、書き手にしか見えない部分がえらく進化してます。サーバーにインストールして使うタイプのブログツールでも、外部のフィードを取ってきて管理画面に他サイトの更新状況や人気のプラグインが表示されたりしますし、まるでレンタルブログサービスを利用しているかのようです。いかに書き手を書く気にさせるか、ってのが今日のブログツールの潮流なのかなーって感じました。これ大事なことですよね。

portal shit! : Twitterのフィードを加工して自サイト内にマイクロブログを作る

このように、WordPressは管理系の機能が非常に進化しているように思う。バージョン2.7から、自動アップグレード機能がついて、何も知らん人でもWordPress本体をサーバーにアップロードして、MySQLにデータベース一個つくればそれで使えるようになる。面倒くさいアップグレードとかもボタン一つで完了、さらに世界中のデザイナーがデザインしたWPテンプレートが使える。

WordCamp Fukuoka 2011は “Publish” がテーマだったけど、本当に誰もが簡単に “Publish” できるようになりつつあると思う。開発者とデザイナーとユーザーがそれぞれたくさんいて、非常に活気があると感じた。それゆえにユーザーの声が反映されて、使いやすい管理画面（ダッシュボード）になってきてるんじゃないだろうか。一人でブログを書いてるのに、一人じゃないのがWordPressの良いところだと思う。後ろにオープンソースコミュニティが付いている感じ。

一方、かつてはブログツールの代名詞的存在だったMovable Typeは、Six Apartの買収などのいざこざがあり、アメリカの親会社から日本法人に権利が売却されてしまっていた。

なんでMovable Typeがダメになったのか。WordPressと異なり、元々オープンソースじゃなかったのが原因だろう。2007年にオープンソース化されたけど、そのときにはWordPressとの勝負には決着がついていたように思う。そもそもMovable Typeは、個人がPublishするためのツールというより、企業のホームページを管理するためのツールを指向していた。公式サイト（ウェブサイト管理の新標準。Movable Type 5 - Six Apart）を見れば、右上の目立つ位置に「ご購入はこちら」のボタンが配置してあり、基本的に有償のソフトウェアであることが分かる。

WordCampの活況とMovableTypeの身売りがあまりにも対照的で、コミュニティのあるなしで、ブログプラットフォームの盛衰が左右されることを実感した。一人で黙々とブログやプログラムを書いていてはダメで、何かしらで外とつながってなきゃいけないのだと思う。

ブログをリニューアルするにあたり、自分でRailsで簡単なブログを作ろうかとも思ったけど、いろいろ面倒くさいので今のところLokkaを使うつもりでいます。デフォルトデザインがお洒落だし、さくっとデプロイできそうなのもいい。LokkaはSinatraベースなので、気にはなっていたものの何も触れなかったSinatraの勉強にもなるでしょう。開発者の komagata さんのこのブログ記事が印象に残ってる。

何故LokkaはRailsベースじゃないのか - komagataのブログ

プログラマー兼カバラ占星術師komagataのブログ。

docs.komagata.org

Railsを追いきれる自信が無かったから。Rails文化に引っ張られてアプリが一生完成しない気がしたから。あとアプリとしては問題無いのにベースのRailsのバージョンが低いだけで残念っぽくなってるアプリ(Redmineとか)を見たから。

半年やってみてSinatra面倒クセー！っていっぱいあったけど、(Sinatra本体の)ソースが短いので完全把握できる掌握感は独自のOSS作る上で心強かった。

そう、Railsはバージョンアップが頻繁なため、仕事でRailsを使えないサンデー開発者にはバージョンアップを追いかけるのが大変すぎる。Railsのマイナーアップデートでアプリケーションが依存するgemが動作しなくなりアプリケーション崩壊みたいのを何度か経験した。それが毎週末続くと、「Railsめんどくせぇ」ってなる。 ~/Sites に作りかけのRailsアプリケーションがいくつもあります。

Lokkaを利用して、途中で挫折しないようにブログ移行をしてみようと思います。

ポータルシットをリニューアルしようかと思ってます。ブログプラットフォームは2003年の時点で完成されてて、P_BLOGの提供する機能に不満なところはないんだけど、コメント欄を含むP_BLOGのMySQLのデータをうまい具合に移行して作り直したらいろいろ勉強になるだろうなと思って。目指してるのはRESTfulであることと、シンプルであること、Ruby製であること。RubyベースのCMSかRailsで置き換えようと思います。納期は未定。

福岡に引っ越したので、熊本では参加することが難しいIT系のイベントに行ってみた。ANTENNAというイベントで、公式サイトには「Tech系サービスの発信とネットワーキングイベントです」とある。そのイベントのVol. 1に行ってみた。

Abbyのwagaco、もぐらのmaysee、FusicのZENPREのプレゼンが行われた後は名刺交換会が行われた。社交性皆無だし名刺も持ってないので同行者と駄弁ってひたすら飲み食いしてるだけだったけど（BacklogやCacooのヌーラボの社長さんとはちょっと喋った）、みんな自社のサービスについて楽しそうにプレゼンしててすごくうらやましかった。参加者からマネタイズどうすんのみたいな鋭い質問に対して、ZENPREをやってるFusicの中の人はマネタイズより福岡から面白いツールを作って世界に発信していきたい、ということを言っていた。

『情熱プログラマー』の中にGitHubの共同創設者のTom Preston-Wernerの書いたエッセーが載ってる。GitHubが始まったときのエピソードで、マイクロソフトからの30万ドルのオファーを蹴ってGitHubを始めたときの話だ。また37Signalsのブログ内のBootstrapped, Profitable, & Proudという企画で、GitHubのもう一人の創設者、Chris Wanstrathへのインタビューが掲載されている。

Bootstrapped, Profitable, & Proud: GitHub

Below: Q&A with Chris Wanstrath, CEO and Co-Founder of GitHub. This is part of our “Bootstrapped, Profitable, & Proud” series which profiles companies that have $1MM+ in revenues, didn’t take VC, and are profitable. Chris and Tom from GitHub have also answered reader questions i…

signalvnoise.com

そこでもGitHubを始めたときのきっかけとか、理念が述べられている。ZENPREについて言ってたFusicの人と同じで、お金のことより、Git自体が素晴らしくて、それを広めるためのハブを作ろうとした、マネタイズは後から考えた、と語っている。確かにGitHubはGitのチュートリアルが充実してて、自分も何度もGitHubのチュートリアルを読んでGitの使い方はもちろん、SSH接続のやり方も学んだ。こういうのとてもかっこいい。

GitHubは成功した会社だからそんなきれい事が言えるんだよ、と言われたらそれまで。そんなことは分かっている。でも自分がやってる仕事を楽しんで、誇りを持って取り組めなければちっとも楽しくない。金を稼ぐために夢や達成感や誇りを捨てるのか。世の中の役に立ちながら金も稼げて達成感を得るのが一番かっこいいじゃないか。

37SignalsのJason Friedはことあるごとにベンチャーキャピタルの出資を受け入れるな（Bootstrapped）、利益を出せるようになれ（Profitable）、と言う。ここはアメリカじゃないし、37SignalsやGitHubみたいに何もかもがうまく行くとは思えない。でも夢や理念を実現しようとしない人生はつまらない。酒を飲みながら、自分たちが作ったものに対して誇らしげにプレゼンしてた人たちがとてもうらやましかったし、その熱にほだされた。

勉強しよう。

昨年末から今年の正月にかけてXREAで借りてたサーバーが障害に見舞われてデータがぶっ飛んだけど、なんと今週、DreamHostでも障害が発生してサーバー（budapest）が落ち、データがぶっ飛んだ。

Error

www.dreamhoststatus.com

Jekyllでやってるパソコンブログの方はGitとJekyllの組み合わせのデプロイ環境が最強すぎて一瞬で再開できたんだけど、 www.portalshit.net は正直結構大変だろうなぁと思ってた。ところがサーバーが復旧した翌日くらいにはちゃんとDreamHost側でとってたバックアップがコピーされ、自分では何もすることなくサイトが復旧してた。しかも、サーバー復旧後、一旦ユーザーディレクトリは空になってたので自分でドットファイルと tech.portalshit.net だけ再アップロードしといたんだけど、そちらはこちらでアップロードしたものが残され、 www.portalshit.net と cinema.portalshit.net の内容だけがバックアップからコピーされてた。DreamHost、やるやないけ。障害報告ページでいきなり「こちらにデータの復旧義務はない」とか高らかに宣言してるXREAとは大違い。

まじでDreamHostはSSHできるしPassenger使えるし、今回みたいな障害のときも頑張って復旧してくれるし、Railsっ子にも安心してご利用いただけます。商売には向かないと思うけどね。オヌヌメ。

外タレのJekyllブログを見てると、シャレオツな感じでコードがシンタックスハイライトされてる。どうもPygmentsというやつを使うらしい。公式Wikiでも触れられていて、コードをハイライトさせたいときは jekyll --pygments しろや、みたいなことが書いてあるんだけど（Liquid Extensions - jekyll - GitHub）、そういうオプションつけてもコードは全然色つきにならず、「サギやんけ」とか思ってた。

しかしマニュアルをよく読むと、PygmentsってのはPython製のソフトで、こいつを別途インストールする必要があるらしい。なるほどそういうことだったのか。そういうわけで

$ port search pygments

してみたところ、MacPortsでは三つヒットした。

py-pygments @1.0 (python, devel)
    Python syntax highlighter

py25-pygments @1.0 (python, devel)
    Python syntax highlighter

py26-pygments @1.3.1 (python, devel)
    Python syntax highlighter

Found 3 ports.

しかしSnow LeopardにはPython 2.6.1が入ってるので、

$ easy_install Pygments

でもオッケーかも知れない。僕は職場に持ち込んでMacBookにはMacPortsから py26-pygments を入れた。そしたらdependencyが発動してPythonとかXorg何とかというもののダウンロードも始まり、 /opt/local/bin/ に python-2.6.5 が入ったが、長々と時間がかかった。^※1

インストール完了後、これでシャレオツシンタックスハイライティングできるようになったと思い、意気揚々と

$ jekyll --pygments

してみたのだが、一向にハイライトされない。なんか「pygmentizeとか見つからないし」みたいなエラーが出る。なんでじゃ〜とイライラしながら公式Wikiを読んでると、次のような記述があった。

the pygmentize binary must be in your path

そうなのよ。 pygmentize-1.3.1 っていうバイナリファイルはあってパスは通ってるんだけど、 pygmentize そのものがないのよ。そういうわけで

$ sudo ln -s /opt/local/bin/pygmentize-1.3.1 /opt/local/bin/pygmentize

してやった。すると pygmentize というバイナリファイルにパスが通るので、めでたくシャレオツシンッタクスハイライティング環境が手に入った。ちなみにCSSはGithub互換のものを拾ってきて入れといた。