最近、ソースコードのレビューが熱い(と思っている)。各種フレームワークの台頭によって、ソースコードの質がだいぶ均質化されているように感じるが、だからこそレビューを通じて知識の共有化をするべきだ。 パッチを表示 とは言え、まだまだレビューを支援するシステムは数少ない。そこでPerl製のこちらをご紹介。 今回紹介するオープンソース・ソフトウェアはCodestriker、Webベースのソースコードレビュー支援ソフトウェアだ。 CodestrikerはPerlで作られているソフトウェアで、Diffファイルとリポジトリのパスに従ってパッチファイルにコメントを書けるようになっている。アップロードされたパッチに対してコメントをすることで再修正、または適用という流れになる。対応しているリポジトリはSubversion/CVS/Clearcase/Perforce/Virtual SourceSafeとなっ
※ 画像は一部公式サイトデモより Web2.0(?)の特徴はCGMや共有と言ったキーワードだ。サイト側から与えられるコンテンツではなく、ユーザが皆で協力してコンテンツを作り上げていく楽しさがある。ブックマーク、ニュース、コミュニティ…様々な要素がシェアされている。 そうした中、これもまた新しい共有の要素になるだろう。それはソースコードだ。 今回紹介するオープンソース・ソフトウェアはReview Board、ソースコードレビュー共有サービスだ。 Review Boardはリポジトリを登録し、そのDiffファイルを使ってReview Board上でソースをグラフィカルに表示する。そして差分に対して皆でコメントしていくのだ。ソースの一部分に対して的確にレビューできるので、分かりやすい。 SubversionやCVS、Perforce、Git、Mercurialのリポジトリに対応している。興味深い
継続的インテグレーションとは Hudsonの具体的な紹介に入る前に、まず簡単に「継続的インテグレーション」(Continuous Integration、以下CI)のおさらいをしましょう。CIは、Extreme Programmingに端を発し、Martin Fowlerによって広められた概念で、狭義には、別々に開発された部品を持ち寄ってお互いの動作を検証する「統合テスト」を早い段階から恒常的に行うことを指します。この当初の概念には必ずしも統合テストの自動化という考え方は含まれていませんでしたが、最近では、CIは単に統合テストだけではなく、広くビルド及びテスト全般を恒常的に行うことを指すようになり、またこれを現実的な工数で実現するための必須の手段として、ビルド・テストの工程を極力自動化する、という事が重要なポイントの一つになってきました。 この考え方の背景の一つには、コンピュータの高性能
Recent entries Apache2.4のリリース予定は来年(2011年)初め(あくまで予定) inoue 2010-12-23 Herokuの発音 inoue 2010-12-20 雑誌記事「ソフトウェア・テストPRESS Vol.9」の原稿公開 inoue 2010-12-18 IPA未踏のニュース inoue 2010-12-15 労基法とチキンゲーム inoue 2010-12-06 フロントエンドエンジニア inoue 2010-12-03 ASCII.technologies誌にMapReduceの記事を書きました inoue 2010-11-25 技術評論社パーフェクトシリーズ絶賛発売中 inoue 2010-11-24 雑誌連載「Emacsのトラノマキ」の原稿(part8)公開 inoue 2010-11-22 RESTの当惑 inoue 2010-11-22 「プ
下記の記事を読んで気づいたことをメモ。 【元ネタ】 TestLinkを検証しました ― ありえるえりあ 【引用】 テストケースの管理と、テスト計画(=テスト実施の記録)の管理のふたつの軸があるのがポイントです。 RDBアプリ風に言えば、前者がマスター(リソース)、後者がトランザクション(イベント)的な構造です。 テストケースは手順と期待値の記述で、何度も実施されればその度ごとに結果レコードができます。 テストケースの1レコードに対して、実施結果のレコードは1対多の関係で存在します。 テストケースと実施結果が1対多の関係になるのは、言われてみれば自然で当り前の構造なのですが、バグトラッキングシステム(BTS)とは違うんだという現実に改めて気づきました。 昔、wishlistもBTSで管理している話を書きました(http://dev.ariel-networks.com/Members/ino
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
今回の業務ではメンバーにテストのエキスパートがいるので、やっと TestLink を実戦投入できた。 そこで TestLink を使い始めていろいろと見えてきた。 良かった点 とにかく管理は TestLink でやってくれるので、こちらはテスト自体に注力できるようになったのが利点。 テストケースの管理が楽になった テストの実行が楽になった テスト結果の管理、集計がしやすい 気になる点 現状の TestLink や Trac と TestLink の連携で思っていること テストケースの作成が大変 Excel のツールはあるけど、文章を書くのは Excel には不向き(自分の使い方が間違ってる?) Trac との連携がまだ弱いのでなにか案がないか考え中 TestLink から Trac へのリンクは張れるが、Trac から TestLink へのリンクがない できました:Trac の Wiki
Nested Attributesを使うと更新がネストしたモデルでもできるとか。 詳しくはhttp://webtama.jp/series/railstips/articles/31を見てください. では早速、表示させてみる has_many throughでもできるかが気になったので試してみた Event <---> EventsUser <---> User こんな感じで多対多を実現 accepts_nested_attributes_forがミソでこれを指定するとネスト更新が扱えるようになる. class Event < ActiveRecord::Base has_many :users, :through=>:events_users accepts_nested_attributes_for :users end コントローラにインスタンス変数を作って値をネストさせる def
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く