おまけのおまけ:closeの停止とresolved対応
デフォルトでは上記プラグインが持っている機能は
- チケットにリポジトリのコメントを連携する
- チケットをクローズする
ですが、今回対応したケースでは、チケットクローズはマネージャがしたいので、勝手にクローズされては困ったりしました。そうじゃなくてステータスをresolvedにはしたい。困った困った。
ということで、プラグイン書き換えました。
vi /usr/local/lib/python2.6/dist-packages/Trac-0.12.2.ja1-py2.6.egg/tracopt/ticket/commit_updater.py
def cmd_close(self, ticket, changeset, perm):
if not self.check_perms or 'TICKET_MODIFY' in perm:
ticket['status'] = 'resolved' <== ここ
if not ticket['owner']:
ticket['owner'] = changeset.author
これでステータス変更対象が close じゃなくて resolved になりました。
あと、デフォルトではこのチケットステータス変更用のコマンドが「close」とかで気持ち悪いので、trac.iniにこんな感じで追加。
commit_ticket_update_commands.close = resolved resolve solve fix fixed fixes
関数名も変数名も close で多少気持ち悪いけど、Core ライブラリを必要以上にいじるのも気が引けるし、こんなもんでしょ。
簡単な構造
SVNからは、コミット後(post-commit hook)に、Tracに対して「コミットあったよー。」という連携をします。(trac-adminによるchangeset連携)
Tracは、連携を受けると、対応するsvnを確認して前述のプラグインを走らせることで、必要な対応を行います。
ここで、コメント内容(tracプラグイン用のコマンド:refsとか)はTracがsvnを参照して理解するので、先にTracにsvnリポジトリを登録しておく必要があります。
つまり、対応する手順としてはこんな感じになります。
- Tracに(svn)リポジトリを登録
- svnのhookポイントを利用し、コミット後にTracへ連携(このとき、リポジトリ名とリビジョン番号を連携する)
- Tracは連携を受けて、対応するリポジトリ名のリポジトリのリビジョン番号を検索し、そのコメント内に書かれているコマンド(refsとか)を判断して実行
以下、それぞれの具体的な内容を書きます。
業務系におけるDB設計1
業務系だと、DB設計は大体ショボくて、その割に今までのアプリを動かさないといけないという下位互換性は異常なほど求められるので(大抵はマネージャが既存機能を見切る度胸がない)、既存仕様を削らずに拡張するので、こんなことが起こる。
Table : User String name int gender_flag ( 0:male, 1:female ) ↓法人を追加したくなった Table : User String name int gender_flag ( 0:male, 1:female, 2:corporate )
で、こんなコードを書いていてバグる。
if ( gender_flag == 0 ){ // for male } else { // for female }
じゃ、どうするかというと、当然ながらソースコードは
if ( gender_flag == 0 ){ // for male } else if ( gender_flag == 1 ){ // for female } else { throw Exception }
にするわけですが、DB設計する時にも注意しないといけなくて、
- いいから flag は 0/1 にしておけ。
- 付け焼刃の設計は使い捨てだけにしておけ
ですね。
上の場合だと、対応方法としては、
- 法人の用途に合わせて、Userテーブルに追加するべきか、別途法人用テーブルを作成するのか、などを検討する
- boolean user_type ( 0:human, 1:corporate, default:0 ) を加える(可能であれば if user_type = 0, gender_flag should be set のような制約条件が欲しい)
とかでしょうか。
ちなみに、一般的には「クソ設計するなよ」というのが常識だとは思いますが、実は私は、付け焼刃設計してもいいときはあると思っていて、その条件はこんな感じ。
- エンハンス余地があまりない、作りきりのアプリケーション(SIで基本的には使って、せいぜい5〜10年程度で技術進歩により新しいシステムが欲しくなったりして使わなくなる。とか、企画として作成して、当たったら広げようかな、みたいなのとか。)
- 設計が複雑怪奇すぎて、手をつけること自体に非常にコストがかかる
- もうからない
- まともな設計ができる技術者がいない
要は、継続性を気にしない、もしくは下手に頑張ったら痛い目に遭う、といった場合は、敗戦処理にコストをかけない方がいいですよ、ということですね。
RadRailsことはじめ2
久しぶりに触りました。なんと1.5ヶ月ぶりですか。ひどいですね。
今日はscaffoldについて。
scaffoldはrailsをやってる人なら大抵一度はやったことがあると思います。
久しぶりに触りました。なんと1.5ヶ月ぶりですか。ひどいですね。
今日はscaffoldについて。
scaffoldはrailsをやってる人なら大抵一度はやったことがあると思います。
で、これをRadRails上でやるにはどうすればいいかというと。。
Generators というビューがあるので、これを利用します。
ふつーに使っているとパースペクティブの下の方に用意されていると思います。
どうしても見当たらない場合は
ビューの追加>Rails>Generators
をしましょう。
で、ここで注意。
Generatorsはこんな感じのビューですが、
実は、てきとーに、
Generator: scaffold Parameters: person name:string age:integer
とかやるとできちゃう。かのように見えます。
しかし、実はしれっとRailsプロジェクトが選択されており、ここで選択されているプロジェクトに追加されることになります。
図では「twitterbot」プロジェクトが選択されています。(途中で切れていますが)
プロジェクトの選択は、ビューの右上にある、フォルダマークをクリックすることで行うことができます。
ということで、scaffoldやるときには選択しているプロジェクトに注意しましょう。
プロジェクトが正しく選択されていれば、後は通常のRailsと同様にscaffoldingしてくれますよ。[[]]
追記:
どうも、起動時にaptana cloudに関するエラーが出る。
サービスがうまく稼動していないのかな?
まぁ、使わないからいいか。。。
毎日1つ、嫌なことをする
毎日1つ嫌なことをするのは魂を磨くにはよいらしい。ばーいバーテンダー。
禍福ならぬ良悪の仕事は糾える縄の如し。嫌な仕事を自分の糧にすることが成長の秘訣かもしれないですね。
と、自分を慰めてみる。