RedmineをCakePHPに移植する「candycane」プロジェクトの開発合宿に参加してきました

安藤さん主導の「RedmineをCakePHPに移植する」というプロジェクト「candycane」が立ち上がり、2泊3日で8人で同時に開発を開始するという合宿に行ってきました。（厳密な開始は先に安藤さん他数名が開発の下地を整えてました）

Redmineとは、日本で急速に利用者が増えている、サーバーインストール型のBTS(バグトラッキングシステム)です。Redmine自体については以下をどうぞ。

• Redmine.JP
• Ruby on Railsで作られたプロジェクト管理ツールredMineを使ってみよう！：第1回　プロジェクト管理ツールの必要性／Tracとの違い／redMineがオススメな理由｜gihyo.jp … 技術評論社

candycaneプロジェクトの概要

candycaneプロジェクトの概要はまずは以下のスライドからどうぞ。

CakePHP開発合宿開始！＆candycaneを開発します - yandodの日記

参加した理由は「Cakeへの移植が面白そうだから」「インストールベース世界一を目指すから」

僕がこのプロジェクトに参加した理由は、Railsで作られたソフトウェアをCakePHPに移植するという内容が面白そうだと思ったことと、「インストールベース世界一のBTSを目指す」という目標にしびれたのが主な理由です。

また、8人で1つのアプリケーションを作りあげるという試みも自分的には目玉でした。ツールも「Redmine」「Git」「CakePHP」と最新揃いです。普段ヨセミテでは基本的には僕一人で開発しており、いくらCakePHPやGitを使っていても一人であるのであまりメリットを感じることができません。このプロジェクトによってRedmineやGitでの分散開発がどのようなものか経験を得られればという目論みも目的の一つです。

世界一は実現可能

スライドにもありますが、最近流行った/流行っているBTSのTracやRedmineは、基本的にはroot権限を持ったサーバーでしかインストールできません。それでも利用したいと思わせるのはBTSが解決する問題が大きい＝ニーズがあるということで、もしインストールが「PHPが動いているサーバーにアップするだけで済む」のであれば、大きなブレイクスルーが見込めます。

candycaneのインストールはファイルをアップするだけで、しかもPHP4/5両対応を目指しています。PHP4はまだまだ使われていますし、社内の古いサーバーにLAMPがインストールされていたりすることも多いでしょう。「とりあえずいれてみることができる」というのは、大きなアドバンテージとなります。

実際、PukiwikiやphpMyAdminやWordpressがこれだけ普及した理由の一つがインストールの簡便さであることは、誰しもが認めることでしょう。

このようにcandycaneが世界一のBTSになれるだけの仮説は十分に整っており、十分実現可能な目標であると思いました。

合宿の様子

合宿は2泊3日で、温泉旅館の合宿プランを用いて、会議室+客室で一人20～30時間程度×8人で作業が行われました。（candycaneチーム以外にも7名ほど同じ場所で合宿を行いました）

コードの共有はGit(thechaw.comのレポジトリ)を使い、機能ごとにブランチを切ってブランチも含めてリモートに全てアップするという方式をとりました。masterブランチは基本的には安藤さんが保守し、機能別ブランチは担当者が好きにするという感じです。

作業は約3時間ごとに区切られ、区切りごとに各自やったことと、次の3時間でやることを口頭で報告しました。ブランチからmasterへのmergeはこのときに一気に行われることが多かったです。

チケット参照系を担当しました

僕の担当はチケット参照系でした。参照は一覧ページと単独ページがあり、まずは一覧が表示されないと辿れないだろう、ということで一覧ページから手をつけました。

チケット一覧ページはJavaScriptとAjaxをふんだんに使い、フィールドの表示は動的で、検索条件も出たり消えたりと、一見しただけでも大変そうなページでした。後述するRedmineのコードの追い辛さも加わって（というかそれがほとんどの理由で）かなり体力を気力を消耗しました。

でも一応、基本的なフィールドの表示とフィルタの設定、Ajaxの動作は行えるようになりました。がんばった自分をほめてあげたいと思います。20時間ほど作業しておいて表示フィールドのカスタマイズ対応が未着手なのが悔しいですが、ほんと大変だったんですよ...！

チケット一覧ページの動作をスクリーンキャストで作りましたのでぜひ見てやってください。

続いて、合宿で得られた知見と教訓です。

Gitのmergeのかしこさは半端無い

gitのmergeは本当に賢くて、cvsやsubversionでは絶対にできない頻繁で高速なmergeができました。同じ行を編集しさえしなければ、基本的には衝突はおきません。masterから取り込んだり他のブランチから取り込んだり、取り込んだものをコミットしてまたそれが取り込まれて...という複雑なmerge関係を持っても、なんと自動的にGitがmerge元のhistoryの位置を考慮してくれてよしなにmergeしてくれます。これはほんとすごい。

cvsやsubversionでは、ブランチ間のmergeは1回だけなら特に何も考えなくてもうまくいくことがありますが、同じブランチを使って2度行おうとすると「ブランチ元の開始versionと終了version」を指定しないとほぼ衝突します。開始versionや終了versionなんて覚えてられないので、タグで「MERGE_001_BEGIN」とかいうタグをつけて管理します。これがかなりめんどくさい。

さらに別のブランチからの取り込みまで考えるとなると、もはやブランチ管理だけでいっぱいいっぱいになります。

ちなみにsubversionでもかしこいmerge機能がつく予定があった気がする(少なくとも1.5時代には無かった)ので、そのあたりは追い切れてないことを付け加えておきます。

Railsで作られているからといって読みやすいコードになる保証はない

僕らが最も期待して最も裏切られた点なのですが、RedmineはRailsで作られているので、きっと綺麗なMVCコードになっていると思ったら、全くそんなことはありませんでした。

Redmineの元のコードを追っていると、viewに渡されたデータを見ていたと思ったらデータに紐づけられたメソッドの中でmodelのDB呼び出しを伴うメソッドを呼び出したり、その中からヘルパーを呼んだらまたその中でもmodelを呼び出していたりと、かなり難解な構造になっていました。view以降はDBにはアクセスしないというMVCの前提は、ありませんでした。

これは単に思想の違いで、RedmineプロジェクトではMVC準拠は重要ではなかったのでしょう。

CakeはRailsとかなり似ていますが、PHPとRubyは似ていません。Rubyは完全なるオブジェクト指向で、値にプロパティを持たせることが容易に出来ます。PHPではそのようなことは容易にはできません。可能な限りの変数をインスタンス化すればいいところまでいけるかもしれませんが、その作業自体にかなりの手間がかかります。

ここから得られる業務上の教訓は、もし「Railsで書かれたコードがあるんだけど、保守してくれない？」といった案件があったときに、舐めてかからないことです。優れた言語やフレームワークはコードの読みやすさをもたらしますが、「読み辛いコードが書かれることを抑制する」ことに関しては無力なのです。

まだまだこれからです

candycaneはすでに40画面以上が動作し始めていますが、まだまだこれからです。実は僕自身は初めての共同でのオープンソースソフトウェア開発なので、がんばっていきたいと思います。

FAQ

candycaneの公式サイトはありますか？

candycaneの公式サイトはまだありません。

コードは公開されていますか？

コードはまだ公開されていません。時期がきたら公開される予定です。

国際化対応していますか？

英語をベースにして日本語対応しています。まずは英語と日本語の対応になるんじゃないかと思います。

このプロジェクトに参加できますか？

このあたりについてはまだ決まっていませんが、参加できる可能性はあります。ウォッチしていてください。