Redmineに入れたプラグイン一覧 - プログラマの思索
RedmineのVer0.8.4、0.8.6に入れたプラグインのうち、使っているものを公開してみる。 1年前に比べると、プラグインが充実していて楽しい。 結局10個以上も入れていた(^^;) 【コードレビュー】 r-labs - Code Review - Redmine Redmineのプラグインが充実している: プログラマの思索 リポジトリ画面からコードレビューのチケットを発行して、レビューをワークフロー管理できる。 お手軽にコードレビューできるのがいい。 レビューもチケットにするから、ワークフローのカスタマイズも可能。 【Hudson】 r-labs - Hudson - Redmine Redmineのプラグインが充実している: プログラマの思索 Hudsonと連携して、ビルド管理する。 SimpleCIプラグインよりもはるかに機能が充実している。 【Wiki拡張】 r-labs
チケット駆動開発のFAQ - プログラマの思索
チケット駆動開発についてのFAQをまとめてみた。 他に聞きたい質問があれば、コメントして下さい。 チケット駆動開発のFAQを集めれば、チケット駆動開発を普及させるのに役立つと思うから。 【元ネタ】 チケット駆動開発 … ITpro Challenge のライトニングトーク (4) - まちゅダイアリー(2007-09-07) TiDD：チケット駆動開発: ソフトウェアさかば RedmineとTracの機能比較: プログラマの思索 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 Tracのワークフロー: プログラマの思索 ワークフロー機能のカスタマイズ方法 - かおるんダイアリー そろそろTracのワークフローについて語っておくか - almost nearly dead チケット駆動開発は進捗報告作りをどのように解決しようとするか？: プログラマの思索
金曜にバグを発生させるコミットが多い - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
プロジェクト管理サーバーとは - プログラマの思索
僕が考えているプロジェクト管理サーバーについて良い記事があったのでメモ。 【プロジェクト管理サーバーのイメージ】 そろそろプロジェクト管理ツール群について一言言っておくか - Talking Nonstop プロジェクト管理サーバーの目的は、SW開発で必要なインフラを提供することにある。 基本は、タスク管理(Redmine・Trac)とバージョン管理(Subversion)。 タスク管理の目的は、プロジェクト内部の作業全てを見える化して、一元管理すること。 RedmineやTracの運用の鍵は、タスクをチケットにどこまで分割して、アジャイル開発のイテレーションへどのように落とし込むか、という点にある。 つまり、分割したチケットをリリース単位にまとめて、小規模リリースできるか、という観点が大事。 バージョン管理の目的は、プロジェクト内部で発生する全ての成果物を一元管理すること。 バージョン管
プログラマの思索: ツールが開発プロセスを改善する
Redmineでチケット駆動開発(TiDD)を運用して気付いたことは、開発プロセスが大きく改善されただけでなく、従来の開発プロセスの弱点が浮き彫りになったこと。 下記の記事を読んで考えたことを書いてみる。 【元ネタ】 ケント ベック氏のアジャイル開発における開発支援ツールの役割についてのホワイトペーパー 元請SIerがTracのような環境を提供できない３つの理由 - なからなLife 元請け企業が用意すべきもの - T/O 【1】強力な構成管理ツールが無い時代はライブラリアンが独裁者 構成管理の基本は、任意のバージョンのシステムを再現できること。 今時、Subversionのようなバージョン管理ツールの無いSW開発プロジェクトはありえないだろう。 CVSやVSSが無かった頃は、構成管理ツールなど存在せず、構成管理を人手でやるしかなかった。 今でも、Excelなどの設計書はバージョン管理で制
Redmineインストールメモ - プログラマの思索
Redmineのインストールや設定に関するメモ。 【1】Passengerをインストールすると、RailsをApache単独で稼動できる。 http://redmine.jp/tech_note/apache-passenger/ gem install passenger passenger-install-apache2-module 後は、httpd.confの設定だけすればいい。 Passengerの利点は、RailsがPerlやPHPと同じ感覚で運用できることだ。 今後のビジネスを考えると、RailsをJRubyで動かすか、Apacheで動かすか、どちらかが重要になるだろう。 要注目の技術だと思う。 【2】Wikiを使うには、下記を実行。 gem install RedCloth 但し、活動欄に表示されるチケット内容は、Wikiのシンタックスがそのまま表示されてしまう。 【3】日
プログラマの思索: Subversionコードラインのライフサイクル
Subversionを使ったブランチモデル、バージョン管理戦略がだいぶ分かってきたのでまとめてみる。 ＃走り書きなので後でロジカルにまとめる。 元ネタは下記の記事。 複数のアジャイルチームでのバージョン管理 【1】Subversionブランチが作られるタイミングは、2つある。 一つは、本番リリース直後に作るリリースブランチ。 他方は、突然やってきた大きな機能追加に対応するタスクブランチ。 【1-1】リリースブランチは普通で頻繁に作る。 リリースブランチのライフサイクルは、下記の通り。 これがVer1.0, 2.0とバージョンアップするたびに作られる。 Create：本番リリース直後にtrunkから切られたTagから作る。 ↓ Update：緊急のバグ修正を反映する。当然、trunkにもマージする。 ↓ Delete：次のバージョンが本番リリースされた直後に廃止される。 ここで重要なポイント
大規模プロジェクトはバージョン管理が重要になってくる - プログラマの思索
ソース管理について良い記事があったのでメモ。 Subversionベストプラクティス 複数のアジャイルチームでのバージョン管理 「複数のアジャイルチームでのバージョン管理」の指摘は非常に重要なので、まとめておく。 【1】バージョン管理の目的 1-1. Fail First コードのコンフリクトや統合の問題を早期に解決する。 1-2. 常にリリース可能 どんなに悪いイテレーションでも、その成果物はリリース可能にならねばならない。 1-3. シンプル チェックインやマージ作業などのポリシーはシンプルで明確であること。 オブジェクト指向のパッケージ原則の一つに「再利用できる粒度とリリースできる粒度は同じだ」という法則がある。 つまり、最終的にリリース可能であるということは、その成果物が公開された時、他の誰もが安心して使える品質レベルを保障しているということ。 我々プログラマは、結局、他の開発者が
プログラマの思索: Subversionのブランチを有効活用してアジャイルに開発せよ
デブサミ2008講演資料の「SubversionとMaven 2 による構成管理」を読んで、改めてソフトウェア開発ではソース管理が最重要であると再認識した。 ソース管理について振り返ってみる。 【1】ソース管理の歴史 ソフトウェア開発では、ソース管理が必須だ。 ソース管理の本質は、履歴を辿って、いつでもソースをUndo、Redoできること。 昔のコンピュータ資源が希少な時、そもそもプログラムを履歴に残すことすらできなかっただろう。 今でもリリース時によくやるように、システム一式を複製して日付でリネームしていた。 僕は当初、ソース管理に、MSのVisualSourceSafeを使っていた。 CVSよりも直感的でGUIが使いやすい。 VSSを使い始めてから、下記の作業がルーチンになった。 朝、出社後、VSSから最新ソースを落として、VisualAgeForJavaのワークスペースにインポートす
プログラマの思索: オープンソースBTSはソフトウェア開発のベストプラクティス
ソフトウェア開発は3つのモードがあると思う。 最初は新規開発モード。 そしてソフトウェア開発の中で最も難しく、最もプロジェクトマネジメント能力を要求されるバグ管理モード。 最後は、運用保守モード。 BTS（バグ追跡システム）は、主にバグ管理モードで使われる。 つまり、各開発者のプログラムを繋ぎ合わせて正常に動かす結合テスト。 あるいは、色んなブラウザに対応しているか、とか、高負荷なアクセスに耐えれるか、などのようなシステムテスト。 BTSとは、そこで上がったバグを収集し、修正し、検証する一連の作業をフレームワーク化したもの。 主にWebシステムで作られている。 このBTSについて再考してみる。 【1】BTSに至るまでの歴史 一昔前。 結合テスト以降のバグ修正は、Excelベースだった。 バグを見つけた人が、Excelのバグ報告票に起票する。 そのExcelを修正担当者に渡し、修正してもらう
チケット駆動開発でXPの計画ゲームを実施する - プログラマの思索
昔、XPlannerというXPのアイデアを実現したWebアプリがあった。 そのソフトは、XPのタスクカード単位で進捗管理できるのがウリだった。 でも、正直使い勝手は良くなかった。 そして、最近、Redmineを触って初めて、XPを実現できそうなプロジェクト管理ツールだと直感した。 Redmineによるチケット駆動開発のアイデアをまとめてみる。 【1】Redmineの特徴は、プロジェクトの進捗の可視化 Redmineの最大の特徴は、ガントチャート。 チケットに作業内容と開始日、終了日を入れると、すぐにガントチャートが出来上がる。 これを初めて見た時は感動した。 プロジェクトリーダーは、ガントチャートを作って保守するために、殆どの時間を費やしている。 WBSさえ作って入力すれば、ガントチャートを自動生成してくれるのだ！ 他に、カレンダーもある。 開発時だけでなく、運用保守時にリリースする日やD
業界から見たIT技術の変遷 - プログラマの思索
IT技術の変遷について考えてみると、業界の変遷と照合すると分かりやすくなる。 最新のIT技術が必要とされる業界が、流れとして、鉱工業や金融から、小売などの商業やマーケティング系へ移りつつある。 昔は、工場や銀行のようなミッションクリティカルな業務システムに、メインフレーム＋Cobolで構築していた。 昨今は、メインフレーム＋Cobolを、Java/.NET＋オープン系システムへリプレースする案件が非常に多い。 それらの案件は大抵、大規模案件で、いつもデスマーチになる。 技術者としても、部品ばかり作って、システムの全体像が見えず、楽しくない。 昨今の小売などのネット注文Webシステム、SNSなどは、Java/PHP/Perl/Ruby＋Unixで構築することが多い。 例えば、Amazon、楽天、mixiなど。 それらの案件は中小規模だが、いつも最新のWeb技術を試すし、技術革新のスピードが猛
プログラマの思索: RubyよりもJavaが好きな理由
最近、Ruby関西に行ってRubyの勢いを感じている。 そんな時に、Javaの最近の動きを聞く機会があった。 Java6やSeasarの話を聞くと、JavaがC#やRailsの影響を受けているように聞こえた。 でも、話しているうちに、「やっぱりRubyよりもJavaが好きなんだ」と気づいた。 その理由は、「JUnitのようなテスト駆動ツールが揃っている」点に尽きる。 そこで「テスト駆動の観点から眺めたJavaの利点とプログラミング思想」について考察してみる。 【１】テストを意識するとメソッドの行数が自然に短くなる プログラミング初心者のプログラムを見ると、行数がやたらと長く、長いプログラムを書き上げた後からデバッグし始める。 だから、いつまで経っても動かない。 プログラミング中級者になると、行数は長いままだが、少しずつ書いてはプリント出力してデバッグで動作を確認し始める。 この
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
