| @WWW

Backlogユーザーのミートアップに行ってみた。Cacooなどで注目されているヌーラボのイベントなので何か面白い話が聞けるのではと期待して行った。

Backlog｜チームで使うプロジェクト管理・タスク管理ツール

Backlog｜チームで使うプロジェクト管理・タスク管理ツール

Backlogは、業務を可視化して、チームのコミュニケーションの促進を目的としたプロジェクト管理ツールです。シンプルな操作性と親しみやすい見た目で、開発者だけでなく、デザイナー、マーケターなど、チームで働くすべての人が使えるのが特徴です。

www.backlog.jp

Backlogのそもそもの開発経緯は、自分たちが受託開発のプロジェクト管理のために作ったものを公開したのだそう。37signalsのBasecampと一緒だなと思った。『小さなチーム、大きな仕事』に書いてある。「自分たちが必要なものを作れ」、「最初の顧客になれ」ってやつ。自分たちすら必要としないものは誰からも欲しがられないのだろう。

ユーザーの活用事例で面白かったのがドメインの失効管理にBacklogを使うという使い方。前勤めてたとこでドメイン切れ事故が起きてしまったんだけど、ああいうのはExcelで管理してるだけじゃ確かに忘れやすい。Backlogに課題として登録してリマインダーの設定しとくと安全だなと思った。

意外に知らなかったのが開発者向けAPIの存在。シャノンの堀さんはAPIにアクセスするプログラムを書いて月初にBacklogにタスクを登録してしまうそう。これをアジャイル開発の手法であるスクラムと組み合わせて運用しているとのこと。生産性が3倍以上になったそうです。

Backlogユーザ会 | KEY

Backlogユーザ会 | KEY

The document discusses an IT backlog tool used for project management. It lists features of the backlog tool such as a web interface, API access, integration with version control systems, and reporting capabilities. Usage statistics are provided showing that over half of users have 6 or fewer projects and over a quarter have only 1 project, indicating that the tool is suitable for both small and large projects. - View online for free

www.slideshare.net

人生初体験だったワールドカフェもなかなか興味深かった。テーブル上の紙にどんどん各人がアイディアを書いていき、時間を区切って席を替わりながら討論していく。紙の上にアイディアを書くので、声が小さい人の話も紙の上に残るし、話し好きの人が延々話し続けるタイプのディスカッションより話題に広がりが生まれるなと感じた。

ワールドカフェの議題は「あなたなら今後のBacklogをどうしますか」というもの。自分はGit対応や、37signalsのBasecampが幅を利かせている海外で勝負するには、オープンソースコミュニティには無償で使わせてあげるとPRになっていいのじゃないだろうか、といった意見を出した。

SkypeやGoogle Appsとの連携を希望しているユーザーが多くいる一方で、非ウェブ系企業ではファイル共有はおろかSVNさえ外部のリポジトリを利用することが禁じられ、Backlogの機能を十分に生かし切れていないとのことだった。

Backlogという製品に関してよりも、いろんな業種の人が異なる様々な条件でウェブサービスを使ってるんだなーということを知ることができて楽しかった。

また懇親会ではアラタナ研究所の @shunsuk さんとVimやRubyトークに花が咲いて非常に楽しかった。阿蘇にいた頃は技術の話ができる人が身近にいなくて悶々としてたもんだから、田舎から出てきて良かったなーとしみじみと感じた。天神で Kumamoto.rb やりたいです。

ヌーラボさんにはこのような場を提供していただき感謝しております。楽しかったです。ありがとうございました。

| @雑談

おっさんだけど夢を見てる。うんこしながら情熱プログラマーとか小さなチーム、大きな仕事とかを繰り返し読んでる。技術書も買ってるけど全然読めてない。積ん読してるだけ。なんとか状況を良くしたいと思ってるけど、なかなか状況は良くならない。時間だけが過ぎていく。

| @技術/プログラミング

ポータルシットをLokkaに置き換えたくていろいろやってる。ポータルシットの過去記事をYAMLでエクスポートし、それをLokkaのDBに取り込む作業をやってる。TDD BootCampに参加したので、テストファーストしながらの作業。RSpecでテストコードを書き、ログが正しくインポートできることを確認する。テスト終了時 after(:all) フックで、取り込んだログを削除してる。コードはこんな感じ。ちなみにLokkaはDataMapperをORMに採用してるので以下はDataMapperでの話。

after(:all) do
  Category.all.destroy
  Entry.all.destroy
end

しかしこれでは AUTO INCREMENT の値がリセットされず、テストを繰り返す度に AUTO INCREMENT の値が増えていってうざかった。

DataMapperの機能で AUTO INCREMENT 値をリセットするのってないのかなと5秒くらい探してみたけど見つからなかったので、SQLを直接実行する方法を採用した。

ちなみにRDBMSに採用してるのはSQLite3。SQLiteでは UPDTE sqlite_sequence SET seq=0 WHERE name='テーブル名'; みたいなコードで AUTO INCREMENT 値を任意の値に設定できるみたい。

最終的な after(:all) フックはこんな感じ。

  after(:all) do
    Category.all.destroy
    Entry.all.destroy
    Entry.repository.adapter.execute('update sqlite_sequence set seq=0 where name="entries";')
  end

テスト実行後にはすべてのデータがデータベースから削除されて、AUTO INCREMENT の値もリセットされる。人畜無害なテストコード万歳。

| @技術/プログラミング

昨日と一昨日の二日間、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をいかにして根付かせるか

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

| @労働

いろいろ悩むことがあって、ここ一ヶ月くらい、ずーっと『情熱プログラマー』を携帯していた。

趣味プログラマーであれ職業プログラマーであれ、プログラミング好きならGitHubをチェックしてるはずだし、GitとかRubyとかPythonとかTDDとかに興味あってしかるべきだと思うんだけど、世の中にはそうじゃない人も結構いる。

“Love It or Leave It” を簡単に実行できたらどれだけ楽だろう。

| @映画/ドラマ/テレビ

ソーシャル・ネットワーク

『ソーシャル・ネットワーク』、面白かったです。マーク・ザッカーバーグよかった。真冬なのに短パン、サンダルで登校し、アイディアが思いついたら早速寮に帰ってもくもくとプログラムを書く。ルームメイトとアイディアを出し合い、窓にアルゴリズム式を書き、ああでもないこうでもないと徹夜で開発を行う。 “wget” やら “Emacs” やらみたいな単語が飛び交い、見る人の創作意欲を刺激する良い映画でした。サンデープログラミング頑張ろうという気にさせられました。ウェブ好きっ子は見て損はないです。

| @技術/プログラミング

福岡工業大学で行われた、オープンソースカンファレンス福岡2010に行った。

usp labのシェルスクリプトで業務用基幹システムを開発する話が面白かった。一般的なプログラミング言語は使わずに、シェルで生のLinuxを使って作業を行わせる。DBは使わずデータはTextで持つ。HTTP関連のあれこれもシェルスクリプトで行う。このためセキュリティのことは考えないといけないらしいんだけど（フロントエンドとバックエンドがシェルスクリプトでつながってるため）、大手のシステム会社が100人月とかみたいな見積を出す案件を10人月程度でやったそう。具体的には無印良品のシステムとか。遅めに会場に入ったので資料は売り切れで貰えず、細かい数字は自信がないんだけど、無印のやつは一年間に10億円かかってたシステム関連の費用が2億円程度に抑えられるようになったそう。mknodとかsedコマンドを駆使した並列処理のデモは本当に面白かった。へー、シェルスクリプトだけでこんなにできるんだー、っていう感じ。1億行のテキストデータ処理を53秒で終わらせたりとか。「Linuxはなるべく生で使いましょう」という言葉がとても深く印象に残っている。Railsみたいな便利なフレームワークを使った開発とはまったく異なるけど、UNIXの「小さいものは美しい」という理念のもと、とんでもなく効率的に開発を行っている様がとてつもなくクールだった。