プログラマの思索

第11回RxTstudy勉強会「Redmine Plugin 活用最前線」の感想をラフなメモ。

【参考】
第11回RxTstudy「Redmine Plugin 活用最前線」 : ATND

第11回RxTstudy「Redmine Plugin 活用最前線」 - Togetterまとめ

RxTstudy公式サイト

RxTstudy　Facebookファンページ

【1】@haru_iidaさんの講演

Rails初心者レベルのRedmineプラグイン開発の講演内容なので、非常に参考になった。
「RedmineプラグインはミニRails」「フック処理の実装はRailsの黒魔術」など、Railsに触れたことがある人なら、ああそうか、と理解できることばかり。
Rubyの黒魔術を知りたい人には、「メタプログラミングRuby」をお勧めしていた。

他に心に残ったお話は以下の通り。

「Ruby＆Railsの開発環境は、Rubymineがお勧め。有償製品だが、オープンソース開発者は無償なので是非使うと良い。」
→デモはRubymineだったが、デバッグやリファクタリングがやりやすそうなイメージがあった。

「CodeReviewプラグインのVerUpでは、RailsのVerUpよりもPrototype.jsからJQueryに変更された影響が大きかった」
「CodeReviewプラグインのVerUpはまだなのか、と海外の人からも問い合せが何度もあった。パッチも送られてくるが、綺麗なソースコードでない時もあるので、無下に断るわけにもいかず、穏便に断るように、英語で書くのが大変だった」
「海外の人の障害フィードバックは、あなたのプラグインはとても素晴らしい、と持ち上げた後に、こんなバグがあります、と言ってくる。開発者としては、自分の趣味、または、自分が欲しいと思って作った動機があるから、褒められるとモチベーションがわく」
「日本人の障害フィードバックは、メールの最初から、障害の内容ばかりで、気が滅入る。海外の人のように、最初は褒めておだてて、その後に障害報告をする方が、開発者のモチベーションは上がります」

Redmineの最新情報チェックに「あきぴーセンサー」と言われたのはちょっと恥ずかしいかなw

【2】@pinzoloさんの講演

Redmineをプロジェクト管理やタスク管理ではなく、テーブル定義などの情報管理に使っている、とのこと。
こういう使い方も面白い。
Redmineプラグインのテスト方法、テストプログラムの注意点、ビルド実行など、開発者ならではのノウハウがたくさんあって興味深かった。

以下メモ。

Redmineのテストコードは、ユニットテスト、ファンクショナルテスト、インテグレーションテストで5千以上ある。

それらをrakeのCIコマンドで、一発で実行できる。

TravisCIがお勧め。Redmineコミッタの@marutosijpさんも使っている。
Rubyのバージョン＋Redmineのバージョンのマトリックステストも出来る。

tail -f pinzo.log: RxTstudy 11th で発表してきました

Redmineの全てのテストプログラム実行は2～3時間かかるらしいが、@akahaneさんの話によると、Ruby2.1.2上ではRuby2.0.xよりも40％速くなったらしい。
だから、Ruby2.1.2＋Redmineでは、性能が大きく向上されたのではないか、と期待されているらしい。

Feature #16194: Ruby 2.1 support - Redmine

Twitter / akahane92: お！待ってました！速度Upとメモリ節約に期待ですね( ^o^)ノ RT @g_maeda: @akahane92 チケットがクローズされ、2.5.2に入ることが確定しました。 http://www.redmine.org/issues/16194

Twitter / akahane92: 急がば回れ ／ Ruby2.1.2にすればITS（Redmine）の応答が向上する見込みなんだけど、提出物の締切で動けない…。H/W増強機材もSetup待ち。もったいないけど、体は一つだしね。

【3】@ogomさんの講演

第11回 RxTstudy「Redmine Plugin 活用最前線」 | ogom.github.io

Rails - sidekiqの使い方 - Qiita

sidekiqは非同期実行を実現するgem。
Redmine上で、ジョブスケジューラ機能を実現できる。

使い道としては、Redmineの画面上から、定期的にバッチ処理をキックしたい場合、とか、ユーザが画面からバッチ処理をキックしたい時に使える。
例えば、Redmineの実績工数や予定工数を月末に工数締めしたい時とか、案件完了でRedmineプロジェクトをCloseした後で検収締めをしたい時に、非同期で締め処理を実行する時に使えるだろう。

あるいは、メンバー全員に今日、または、今週の担当チケットを通知したり、放置されたチケットや停滞したチケットを通知する時に、メールで一括送信するバッチ処理にも使えるだろう。

今後の使い道に期待大。

【4】パネルディスカッション

テーマは色々あったが、Redmineが今後どのように発展していくべきか、というテーマに絞られたように思う。

@sakaba37さんが、パネルディスカッションでこんな話をされた。
IPAが作ったRedmineベースの定量的プロジェクト管理ツールEPM-Xの前身として、別の定量的プロジェクト管理ツールがあったが、結局普及しなかった。
その理由は、マネージャの観点で、プロジェクト管理ではこんな機能が必要だ、という要望を取り入れて実装したが、開発者の観点では、現場の開発作業の邪魔になるようなデータ入力などの煩雑な作業が多いだけで、開発者のメリットがなかった。

また、@haru_iidaさんは、こんな話をされた。
Redmineのプラグインを開発した理由は、自分が使いたかったからであって、誰かのために作ったわけではない。
だから、開発者の観点で作ったのであり、マネージャの観点で作ったわけではない、と。

では、Redmineは今後、どのように発展していくべきなのか？

Redmineは、開発の現場で、こんな機能があったら便利なのに、と開発者が気づいて、自ら開発したのがきっかけで発展してきている。
だから、コミュニティという場で、開発者とコミッタがお互いに有意義な議論を重ねながら、ソフトウェア開発の現場を改善する道具として、Redmineは発展していくべきなのだろう。

Redmine本家のフォーラムやチケットの議論を眺めていると、Redmineがアジャイル開発のプロジェクト管理と相性が良い、と気づいて、BackLogsプラグインで実現したり、PMBOKやITILで既に知られているプロジェクト管理のベストプラクティスをRedmineで実現できると気づいて、リスク管理やEVM、リソースヒストグラムの機能をプラグインで実現したりしている。
ユーザとコミッタがRedmineというオープンな場で、それぞれのアイデアを出して実現してフィードバックしていく、という議論はとても有益だと思う。

チケット駆動開発が進むべき道part1～ソフトウェア開発のベストプラクティスをオープンソースのツールで実現する: プログラマの思索

ITの地殻変動はどこで起きているのか？～チケット駆動開発が進むべき道: プログラマの思索

すると、@pinzoloさんの講演で言われていたが、今後は「Redmineのエコシステム」という発想が必要になるだろう。
Redmineの新機能の追加、新しいプラグインの公開だけでなく、Redmineを使った新しい運用方法、初心者向けのインストール方法やRedmineの使い方などの情報をコミュニティという場に集約して発信できるようにしていくべきだろう。

例えば、Redmine2.5.2から「プラグインアップデートチェック」機能が実装された結果、Redmine本家にプラグイン情報が登録され、集約される傾向になっていくだろう。

Twitter / sakaba37: 大切なのは、いいものを作るのではなく、いい循環を作ること #RxTstudy

Twitter / akipii: redmineのエコシステムが必要。プラグインの情報を集約したりなど。 #rxtstudy

Redmine2.5.2の新機能～プラグインアップデートチェック: プログラマの思索

今後もRedmineに着目していく。