RedmineとTracの機能比較〜コードレビュー、Hudson連携 - wyukawa's diary
ちょっと調べたのでメモ。 ・コードレビュー Redmineには http://www.r-labs.org/wiki/r-labs/Code_Review があり、 Tracには PeerReviewPlugin – Trac Hacks - Plugins Macros etc. がある。 これはRedmine Code Review プラグインのほうが高機能だろう。ソースのdiffにコメントつけてチケットに登録することができる。Peer Review Pluginにこれはできない。 ・Hudson連携 Redmineの場合、Hudson側に Redmine Plugin - hudson - Hudson Wiki を、Redmine側に http://www.r-labs.org/wiki/r-labs/Hudson を使う。 Tracの場合、Hudson側に Trac Plugin
OSC2009 Tokyo/FallでCukeとRSpecの紹介をしました - moroの日記
休んでいるうちにずいぶん時間が経ってしまいましたが、10/31のOSCにてお時間をいただき、Railsの昨今のテスト事情について紹介させていただきました。普段から申しているようにCucumberとRSpecをぐいっと推しています。 Rails testing environment, 2009 fallView more documents from Kyosuke MOROHASHI.あとはRSpec方面で、subjectやitsの使い方について、使いながら考えているようなことを書いています。 前にオブラブ方面でCuctomMatcherの話をしたときに、簡単なCustomMatcherを量産するのはだるいんじゃない?という懸念があったんですが、その一つの解としてits()はありかなー、と。使い分けはこんな風になると思います。 CustomMatcher作る 検証内容が複雑になるとき エ
レビュープロセスを効率化するには？ - プログラマの思索
ReviewBoardとコードレビューに関するメモ。 【元ネタ1】オンラインコードレビュー支援ツール「Review Boad」 これまで自分がやっていたソースコードのレビューは紙に印刷して、赤ペンでガリガリ書いていくというスタイルだったので、ちょっと目から鱗でした。そんな感じでコードレビューをやっていくと手間がかかる割には、使い終わった後はゴミ箱に捨てられていたりしたわけですが、これを使うとレビュー結果が蓄積されていくので便利ですよね。 そう考えると初等プログラミング教育用としても使うのも面白いのかなと思っています。先生をやっていて、その辺りが一番やりきれない部分だったので。。。。 昔も今もコードレビューする場合、大量の紙を印刷して、赤ペンでガリガリチェックするのが普通だろう。 パソコン上で差分表示しながらレビューしてもいいが、レビューコメントを残したりするのが面倒だから。 モニタでは目が
マネジメントのスピードが開発のスピードに直結する - プログラマの思索
倉貫さん(XPJUG代表)の記事を読んで、システム開発に関する洞察が優れている点についてメモ。 【元ネタ】 アジャイル開発のボトルネック - Social Change! (中略) つまり、発注側のかけるコスト（工数）の限界が、ソフトウェア開発における速度の限界点なのだ。プロジェクトが成功するかどうかの分水嶺と言える。 これは実はアジャイル開発に限らず、一般的なウォーターフォールのソフトウェア開発でも、まとめて要件定義や検収テストをしているだけで、結局、同じくらいの工数がかかっていたのではないだろうか。もちろん、要件定義の前のビジネスや業務検討のフェーズを含めれば、である。 アジャイル開発では発注側が行う作業へのコミットが細分化されて見えるので、開発と同程度の工数が必要だという傾向が顕著に見えるだけかもしれない。発注側と開発側にかかる工数比があるように思わせたのは、そうしないと儲からないS
【公開】SQIP2009の論文資料 - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
403 Forbidden
＼閉鎖予定のサイトも売れるかも？／ アクセスがないサイトもコンテンツ価値で売れる場合も… ドメインの有効期限を更新してサイト売却にトライしてみましょう
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
