うちの会社のRedmineプラグイン

2つほど公開します。
第10回shibuya.tracで発表したデモ用のRedmineに入れてたプラグインです。
同じものを会社でも使ってます。

簡単にRedmineを試してみたい人は、デモ用のRedmineをまるごと置いてあるのでここから使ってみてください。
http://yusuke-kokubo.appspot.com/events/shibutra10/

redmine_attachement_viewer

チケットに添付したファイルを一覧で見ることができるプラグインです。プロジェクトモジュールになっています。ActiveRecordがわからないのでSQLを直書きしてます。
%REDMINE_HOME%/vender/plugins/に配置するだけで動くはずです。DBマイグレーションなど特別な操作は不要です。
管理画面の権限レポートから「View attviewer 」にチェックをつけて、プロジェクトの設定のAttviewerにチェックをつけて有効になります。

https://github.com/YusukeKokubo/redmine_attachment_viewer

redmine_yojitsu

見積もり/作業時間に対しての予実をみれるようにするプラグインです。
つかうためにはBacklogsプラグインとOpenFlashChartプラグインが入っている必要があります。
見積もり時間はプロジェクトのカスタムフィールドとして取得しています。
プロジェクトの0番目に実数型のテキストフィールドを設定してください。

https://github.com/YusukeKokubo/redmine_yojitsu

オブジェクト指向はどこへ結びつくのか?

オブジェクト指向プログラミング(OOP)はとやかく歴史的な経緯と誤解によって様々な解釈が入る概念です。
人それぞれのOOPが出来上がっていますが実際のところ、なにに役立つのだろう?オブジェクト指向が結びつく先はどこなのか?そんなことをたまに考えます。
最近のぼくの考えでは「プラガバルなデータ構造を実現できることにOOPの意味がある」となっています。
プラガバルとはおそらくplugin + ableの造語です。「取り外し可能」とかそんな意味です。ちなみにこの言葉はSmalltalkで有名な青木 淳さんの日系バイトの連載で知りました。
その連載では「プラガバルMVC」を説明して、「View-Controllerの関係さえしっかりしてればModelは取り外し可能なんだよ」とぼくの記憶してる限りでは書いてあって、当時ジュンク堂で雑誌を立ち読みしながら、なるほど、と思いました。
オブジェクト指向ではとやかく部品化とか抽象化とか言われますが結局はこのプラガバルなデータ構造を作るということへ結びついてるように考えるようになりました。
プラガバルなデータ構造であることで、オブジェクトは自由に入れ替わることができて自分の仕事をこなせるようになるのです。
初っ端からOOPについてカプセル化とか継承とかポリモルフィズムとかから説明されるよりもよっぽどかわかりやすい気がします。
逆に、このプラガバルに結びつかないOOPは疑ってかかるようになりました。例えばデザインパターンで言うと、FactoryMethodやStateはデータ型を抽象化することでプラガバルに結びつくがSingltonはただコンストラクタをprivateにしてインスタンスの生成を抑えてるだけで怪しいな、みたいな感じです。
世間ではとやかくオブジェクト指向というキーワードさえ並べておけば良いんだろ?と思えるような記事をたくさん見かけますが、「それはプラガバルであるか?」という視点を持つことでそれなりに適正な見分け方ができるようになると、ぼくは思ってます。
もちろん、個人的な意見なので異論は多々あると思いますが。

Redmine Backlogsセットアップ

とりあえずセットアップするところまで。

基本的には公式サイトの通り
http://www.redminebacklogs.net/en/installation/

必要なライブラリをダウンロード

gem install holidays
gem install icalendar
gem install prawn


Redmine Backlogsをダウンロード

cd %REDMINE_HOME%\vender\plugins
git clone git://github.com/relaxdiego/redmine_backlogs.git
#[origin/master] or [origin/v0.4.0]をmasterにすること
#もしくはgit cloneするよりかは、ダウンロードした方が簡単かも http://github.com/relaxdiego/redmine_backlogs/downloads

DBマイグレーション

rake generate_session_store
rake config/initializers/session_store.rb
rake db:migrate RAILS_ENV=production
rake db:migrate_plugins RAILS_ENV=production
#既存のデータ量が多いと結構時間がかかる

お決まりのキャッシュクリア

rake tmp:cache:clear
rake tmp:sessions:clear

Backlogs:install

rake redmine:backlogs:install
#Backlogsのストーリーとして使うトラッカーとマイクロタスクとして使うトラッカーの設定を聞かれるけど
#別にここでやらなくても後で管理画面からちゃんとできるのでやる必要はない
#日本語のトラッカー名だとちゃんと表示できないし

日本語の言語ファイルが存在しないので英語ファイルから作成

config/locales/en.ymlをコピーして
config/locales/ja.ymlを作成する。
2行目のen:をja:に変えればOK

動かしてみる。

script/server -e production

http://localhost:3000/settings/plugin/redmine_backlogs
ここからストーリーとして扱うトラッカーとマイクロタスクとして扱うトラッカーを設定できる。

後は適当なプロジェクトを作って、モジュールにbacklogsをチェックすれば、メニューに現れて使えるようになります。


編集履歴
2010/12/24 : v0.2.x系からv0.3.x系に更新(DBマイグレーションさえうまくいけば動くはず)
2011/04/26 : v0.4.0でRedmine1.1に対応したので独自パッチを削除

TDDBC名古屋 2日目のレガシーコード改善について

振り返り

レガシーコード改善の大きな項目として、

の2点があると思います。

自分はRubyのレガシーコードを提供してたこともあって、Rubyチームに入ってました。
みんなでワイワイ言いながらテストを書いてるときには気づきませんでしたが、今になってちょっと気になることが出てきました。
それはリファクタリングする時間がまったくなかったことです。
みんながテストコードを書くので精一杯になっていたため肝心のレガシーコードを改善するところまでは到達出来ませんでした。
自分としてはTDDの1番大事なことは「黄金の回転」だと思っているのでリファクタリングまでできなかったことはちょっと残念でした。

どうすれば良かったか(自分なりに考えてみた)

テストコードを書く前に、チーム内で計画を立てたら良いと思いました。
ここでいう計画とはXPの計画ゲームとか、スクラムのスプリント計画よりももっと簡単に「黄金の回転」に沿った計画を立てながら進めたらどうかということです。

  • どういうテストを書くか
  • テストコードの継ぎ目をどこにするか
  • どこをリファクタリングしたいか

こんなことを最初にチーム内で話しあえば良かったのかもしれません。
本当はそういうふうに進めるのが和田さんの想いとしてあったのかもしれませんが、Rubyチームとしてはちょっとそれが欠けてたように思います。

カバレッジ100%のテストコードを書くことにこだわらずに、その先のリファクタリングまで最初に見通したうえで作業できると、もうちょっと先のビジョンまでみんなで話しあって共有できて良かったんじゃないかなと最近になって思ったりしてます。

TDDBC名古屋 おまけみたいな雑感

先週末の10日、11日とTDD BOOT CAMP 名古屋が行われました。
内容や感想とかは色んな人が書いてるのでここでは客観的に雑感のみ書きます。

名古屋アジャイルの存在

今回のTDDBC名古屋は名古屋アジャイル勉強会が全面的にバックアップしていました。
KPTや朝会、振り返りというリズムがTDDと結びつくことで効果的に参加者の心に残ったと思います。
会場の設備の準備など自分もほんの少しだけお手伝いさせていただきました。

id:t-wadaさんとの会話

1日目夜の懇親会でいくつかお話させていただきました。覚えてる限りの記憶をメモ。

Redmineの話
  • (t-wada)Redmineの商用プラグインってあるの?
    • (こくぼ)プラグインはたくさんあるけど商用は聞いたことないですね
  • (こくぼ)Rubyの公式サイトもRedmine使ってますよね
    • (t-wada)そうですね
  • (こくぼ)Redmineのバージョンがかなり古いですよね
    • (t-wada)そうですね。いろいろカスタマイズしてるみたいだから
  • (こくぼ)ML連携とかですよね
アジャイルについて
  • (こくぼ)仕事上のコンサルで1番大事だと思っているアジャイルの項目は何か?
    • (t-wada)振り返りをすること
    • (t-wada)朝会をしなくてもホワイトボード使わなくても最低限振り返りをすればなんとかなる *1
  • (こくぼ)Ditzを使う理由は?
    • (t-wada)分散型なので自分の好きにできる
    • (t-wada)自分だけのタスクはGitで管理して必要に応じて客先のRedminetracなどにエクスポート
その他いろいろ
  • (こくぼ)Seasar3がSpringベースで出るみたいですね
    • (t-wada)slim3も最初はSpringベースだったからどうなるのかわかんないよね
  • (こくぼ)結婚はしないのですか?
    • (t-wada)…。 (色々言っていたが聞き取れず)

あと、ぼくが考えるプロジェクト管理のあり方*2をお話させてもらった返答として「それはそうだよね」と言ってもらえたのが嬉しかったです。

id:Akinekoの激しい夜

省略

服装について言い訳

半そで短パンは予定内でしたが、サンダルは当初は予定外でした。家を出るときに焦ったための結果です。
実際にはそれほど浮いた感じもなかったので2日目も開き直ってサンダルで通しました。

Rubyの凄さ

2日目のレガシコードに提供させてもらったRedmine用のリマインダーメールスクリプトのテストをみんなで書きました。
実際のソースコードを一切修正せずにRedmineRailsもデータベースも使わずにテストができちゃうRubyの凄さに改めて驚嘆しました。
メソッド単位で動きを変える黒魔術を空気のように扱えるRubyの凄さ。後々テストの管理がすごく面倒なことになりそうですが、みなさんも知っておくとよいと思います。

昼食の質について

どうしてこうなった。と言いたくなるくらい酷かったですがちゃんと食べました。

遠方からの参加者

遠くまでありがとうございました。さすがに佐賀から来てるのはびっくりしました。

結論

TDDとは関係ないところで1人で盛り上がってました。

*1:ちょっと意図を外してるかも

*2:ざっくり言うと個々の作業者が自分のやり方で作業すれば勝手にセンター側で同期される

プロジェクト管理の理想

仕事の内容的にSE業務、PG業務ともに引き継げる相手ができてきたので自分は次のステップに入ろうと思います。お題は「プロジェクト管理の理想」です。これはぼくがずっと前から理想を追い求めていたことでもあります。
プロジェクト管理とひとくちに言っても色々な側面を持っているので語るのは難しいです。世間一般的なプロジェクト管理がどんなものなのかもぼくはよくわかっていませんし。*1
なのでここではあくまでも自分が考える理想を掲げます。

そもそも何故必要なのか?

なぜプロジェクトを管理する必要があるのか?その答えをとっても簡単には収まりそうにありませんがぼくが考えるのは「チームで作業するため」です。
本当なら企業にとって利益を出さないといけないのでコスト面も重視しないといけませんが「継続的に効率的なチームビルディング」のために管理する。というのがぼくにとっての理想です。あくまでも作業をする側からの目線です。

チームで作業するためには何が必要なのか?

プロジェクトは1つではありません。また1つのチームは継続的に安定して効率を出せる体制が必要です。そのためにチーム作業で必要なことを挙げてみると

  • タスクを洗い出す
  • タスクの割り振りを決める
  • スケジューリングする
  • 関係する情報(進捗、課題、リスク、作業履歴など)をまとめて共有する

といったことを継続的に安定して行う必要があります。*2この作業を行うのがプロジェクト管理だとここでは定義します。

プロジェクト管理をするために

さて、上述したプロジェクト管理を行うためには何が必要になるでしょうか。ここからどういったアプローチをとるのかが人によって変わってくるところだと思います。

どういうやり方で実現するかはひとまず置いといて重要なことがあります。ここからが本題。

プロジェクト管理の理想

プロジェクト管理の理想とは

  • スケジューリングや情報共有のために手を動かすのは「必要最低限」であること
  • 末端の作業者が管理側を意識しなくても「自分のやり方」でやれば自動的に情報共有されること
  • 管理側は作業者からヒアリングして進捗を埋めるだけのような「単純作業をしなくてよい」こと*3

結論としては「みんながプロジェクト管理を意識しなくても自然と情報が共有されること」それがぼくが考えるプロジェクト管理の理想です。*4
個々人が個々のやり方で自分のタスクを管理するといつのまにかサーバー側と連携してみんなと繋がるシステムが欲しいと思ってます。
そのために頑張ってRedmineを使ったりRedmineAirを作ったりしてるわけですが、究極の理想型をいうと資料の裏紙やノートに書いた内容が自然とみんなで共有されるところまでシステム化したいと思ってます。
そこまでいくとアナログとデジタルの完全な融合ができて最高に面白い世界になってそうでワクワクします。*5

*1:どうせ大したことはしてないだろう、とは仕事で関係してる他社(大企業)を見てよく思います

*2:不足分があればフィードバック歓迎

*3:これが1番バカらしい作業だと思う

*4:もちろんプライベートな情報が勝手に共有されたら困るけどそれは別の話

*5:当分は夢のままだろうけど

最速ローカルRedmine構築 (Windows編)

RedmineAirを動かすためにはRedmineがどうしても必要になります。
すでに社内にRedmineが動いてたら良いのだけど、そういうわけにもいかない時のために構築の手順をメモ。

Redmineをチェックアウトする前に

Rubyインストール

artonさん作成のインストーラを使います。
http://arton.hp.infoseek.co.jp/indexj.html


Railsのインストール

お馴染みのgemsを使ったインストール

gem install rails -v=2.3.5
sqlite3のインストール

こちらからsqlitedll-3_6_XX_X.zipをダウンロードして、ruby.exeが置いてあるディレクトリ(もしくはPATHが通っているところ)にコピー。
http://www.sqlite.org/download.html

gemsからsqlite3へのアダプタをインストール

gem install sqlite3-ruby

ここからRedmine

チェックアウト

適当なSubversionクライアントを使ってtrunkをチェックアウト。 *1 *2

http://redmine.rubyforge.org/svn/trunk
config/database.ymlの編集

productionの設定をsqlite3にします。

production:
  adapter: sqlite3
  database: db/test.db
セッション用のキーを生成
rake config/initializers/session_store.rb
DBテーブル作成・初期データ投入
rake db:migrate RAILS_ENV=production
rake redmine:load_default_data RAILS_ENV=production

これで完成

動かしてみましょう。

ruby script\server -e production

これでhttp://localhost:3000/にアクセスすれば動くはずです。
最初はid:pwともに「admin」のユーザーしか存在しないので適当なユーザーを作ってください。

その他、MySQLへつなぐようにしたり、メールを飛ばすようにする設定はこちらをご覧になった方が良いでしょう。
Redmineのインストール — Redmine.JP

ついでにRedmineAirを試してみよう

こちらからインストールできちゃいます。 (開発中なので不安定+低機能なのはご容赦ください) *3
redmineair.air
アプリが起動したらURIとあるテキストフィールドにhttp://localhost:3000(最後に/をつけちゃダメ)、API KEYとあるフィールドにAPIアクセスキー*4を入力して「再読み込みボタン」を押してください。
後はGridにチケットが出てくるので付箋にしたいチケットをダブルクリックしてください。(チケットが1つも作成されていないと何も表示されないので注意してください)

*1:最新版でなくても良いならbranches/0.x-stableでもよいと思います

*2:RubyForgeアーカイブされてるやつは更新が面倒になるだけなのでおすすめしません

*3:RedmineAirはREST APIを使ってるのでtrunkをチェックアウトする必要があります

*4:Redmineログイン後に右上に表示される「個人設定」というリンクを辿ると次画面の右サイドバーに表示されます