Spring BootによるAPIバックエンド構築実践ガイド 第2版 何千人もの開発者が、InfoQのミニブック「Practical Guide to Building an API Back End with Spring Boot」から、Spring Bootを使ったREST API構築の基礎を学んだ。この本では、出版時に新しくリリースされたバージョンである Spring Boot 2 を使用している。しかし、Spring Boot3が最近リリースされ、重要な変...
前回は、1000人のエンジニアがRedmineを使い出すまでの事例を紹介させていただきました。今回は、Redmineの使い方や、大規模に変化してくRedmineの運用について、2年間の運用や改善から得たナレッジや、気がついたことをまとめていこうと思います。 1. Redmineのオブジェクト構造を理解した方がいい Redmineは以下の構造になっているので、タスクの属性をうまく分類する必要があります。 プロジェクト > サブプロジェクト > バージョン > 親チケット > 子チケット > トラッカー > カテゴリ 注意したいのは、プロジェクト・サブプロジェクトには期限が設定できず、バージョンには終了日時、チケットには開始日時と期限をつけることができる点です。期限があるものには、期限のあるものを当てはめるのがすっきりします。Redmineを使って「何を」「どう」管理していきたいのかを、まず考
.NET開発の継続的インテグレーション(Continuous Integration)の仕組みとして、Hudsonが利用出来ます。その備忘録を残します。 ここでHudsonがやっていること Subversionからソースファイルを取得する MSbuildでビルドを実行する NUnitで単体テストを実行する これだけです。 Hudsonに以下のプラグインを導入します MSBuild Plugin NUnit Plugin HudsonにMSBuildプラグインを導入 http://wiki.hudson-ci.org/display/HUDSON/MSBuild+Plugin msbuild.hpi をダウンロード HudsonにNUnitプラグインを導入 http://wiki.hudson-ci.org//display/HUDSON/NUnit+Plugin nunit.hpi をダウ
「Hudson」改め「Jenkins」で始めるCI(継続的インテグレーション)入門:ユカイ、ツーカイ、カイハツ環境!(21)(1/4 ページ) CIツール「Hudson」改め「Jenkins」とは 「Jenkins」とは、CI(継続的インテグレーション)ツールとして有名な「Hudson」の開発者たちにより開発されているCIツールです。Hudsonは商標上などの問題によりJenkinsと名前を変えて継続することが発表されたので、記憶に残っている方も多いと思います。現在では落ち着いて開発されているようです。 本稿では、今話題のJenkinsの使い方を紹介します。本記事の想定読者は、Java開発を行っている方で、「今までCIを導入していなかったけどこれから導入しよう」「Jenkins(Hudson)は使えそうだけど、難しそうだなぁ」と思っている方を対象としています。本稿を読めば、10分程度でJe
みなさんこんにちは。@ryuzeeです。 スクラムの概要を短時間で把握できるいくつかの動画や資料を紹介します。 動画Scrum in under 10 minutes (10分)早口な英語だけど分かりやすいです。 Scrum Basics (5分)アジャイルコーチングの現場で、あまり前提知識が無い人たちに見せたりすることもある分かりやすい動画。 スクラムマスターがゲートキーパーとして刀を振ってチームを守っているところがいいですね。 資料マイク・コーン氏作成で拙訳のAn overview of Scrumパワーポイント形式の資料がマウンテンゴートソフトウェア社のサイトからダウンロードできます。 ライセンスはCCライセンスなので自社での紹介等に使ってください。
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
アジャイル開発の本質をつかんだ各社は、大規模への適用を模索し、ハードルを引き下げる改善を続ける。アジャイル開発での品質基準の調整と、契約の結び方も見えてきた。 まず大規模プロジェクトへの適用だ。基本的な二つのコンセプトは固まりつつある。一つは小規模チームをいくつも並行して走らせるということ。 例えば米IBMは今年1月に出荷した開発ツール「Rational Team Concert」を3年をかけてスクラムで開発する際に、全体を管理するチームと個別機能を開発する20チームに分けて取り組んだ(図1)。全体管理は10人が担当し、関係性がある機能同士にずれが生じないように「バディ」と呼ぶ役割を設けて調整役となった。 個別機能は国をまたがり4~10人が1チームに所属し、全チームが同じ繰り返しの期間で開発を進めた。毎日のミ ーティングは時間を合わせてテレビ会議などで実施したという。「繰り返しと振り返りは
TeamTrickはRuby on Rails製のオープンソース・ソフトウェア。プロジェクト管理はただ多機能であれば良いという訳ではない。多機能すぎるとかえって余計な手間が増え、非効率的になる場合もある。プロジェクトの形態、規模に合わせたものを選定するのが重要だ。 スクラム開発に特化したプロジェクト管理 ここ最近アジャイルな開発形態をとるプロジェクトも増えてきた。そんな時に使えるのがTeamTrickだ。Ruby on Rails、Webベースで動作するプロジェクト管理で、特にスクラム型の開発に特化しているのが特徴だ。 主な機能はユーザと権限の管理、スプリントの登録、バックログの登録となっている。筆者環境ではエラーが出てしまったため、確認できていない部分があるがプロジェクトの進捗をバーンダウンで見られる機能もある。他にもストーリーを登録し、そのステータスを管理することも可能だ。 バーンダウ
アジャイルソフトウェアプロセスを使ってオフショア開発 (by Martin Fowler/訳: 金田忠士) http://www.andore.com/money/trans/agileOffshore_ja.html データベースの進化的設計 (03/6/17. 訳: 和田) 「The XP 2002 Conference」 (02/7/20. 訳: 小野 剛) 分厚過ぎる「ドキュメント」 - The Almighty Thud (訳: 小野 剛) 設計の終焉? - Is Design Dead? (訳: 小野 剛) 継続的インテグレーション -Continuous Integration (訳: 小野 剛) XP変奏曲 -Variations on a Theme of XP (訳: 小野 剛) ファウラー氏翻訳集 (中島@ブレーン) テスト熱中症 -Test Infected (訳:
Web2.0とは何かを定義するのは難しいが,大きな流れとしてテクノロジからビジネスへと多くのエンジニアが視点を移していることは間違いないだろう。言語,設計,コンパイラ,ライブラリ,といった要素技術から,SOA(Service Oriented Architecture)の視点,例えばGoogle APIをどのように使ってサービスをミックスし,新しいビジネス価値を提供できるか,というサービスの視点がより時代に合ったものになっていると思う。エンジニアがビジネス・モデルに関心を示し,ビジネスの言葉で技術を語るようになってきているのだ。さらに,アジャイル開発の考え方が浸透し,「ビジネス価値(Business Value)」を開発の最優先とする考え方が広まっているという背景もある。 この連載では,このような時代におけるソフトウエア製品開発にはどういった視点が必要か,また,その開発はどのような手法によ
WritingTestableCode - テストできるコードの書きかた 目次 この文書について まずいのその1: コンストラクタがやりすぎ まずいのその2: 深い仲になってしまっている まずいのその3: 脆いグローバルな状態とかシングルトンとか まずいのその4: クラスがやりすぎ テストできるコードの書きかた この文書について "Guide: Writing Testable Code" の日本語訳です http://misko.hevery.com/code-reviewers-guide/ 推敲歓迎: 誤訳, タイポ, 訳語の不統一, そのほか... TODO: 各 Flaw のリンク先も訳す Misko Hevery コードをベストな状態に保つために、 我々は Google でソフトウェアエンジニアに以下のようなをガイドを定期的に送っていた。このガイドを共有できてうれしいね。 この
アジャイル開発プロセスのプラクティスをどのように導入すれば効果的だろうか? 前編では、.NET開発者がアジャイル開発プロセスを導入できない理由と、筆者らが「ローカル・ライトウェイト開発プロセス」という名前を付けて、ウォーターフォール型の開発プロセスの中でアジャイル開発プロセスの手法を徐々に取り入れる方法について述べた。 後編となる今回は.NET開発環境においてアジャイル開発のプラクティスを実践するための具体的な方法を紹介する。 ローカル・ライトウェイト開発プロセスを実践するには ここでは、ローカル・ライトウェイト開発プロセスを実践してみようと考えている開発者のために、1人からでも導入できるプラクティスと数人のチームで導入するプラクティスに分けて、その実践方法の解説を行う。 1人からでも導入可能なローカル・ライトウェイト開発プロセス 最初は1人からでも実践できるローカル・ライトウェイト開発プ
「あなたのプロジェクトでは、どのような開発プロセスを採用しているだろうか?」 ご存じのとおり、「開発プロセス」とは、ソフトウェア開発の進め方を定めたものである。一般に開発プロセスでは、開発作業の手順と内容、それを実行すべき担当者の役割、各作業の成果物であるドキュメントやプログラム、さらにそれらの指針となるガイドラインなどが定義されている。 今日まで、そのような開発プロセスがソフトウェア開発を成功させるために数多く出現してきた。これらは、単に開発プロジェクトの規模や開発言語だけを背景に考え出されたわけではない。当然、当時のソフトウェア開発が置かれていた状況や要求が大きく影響している。 そこで本稿前半では、開発プロセスの成り立ちから、現在の最新開発プロセスが誕生するまでの経緯を、その時代背景を含めて説明する。このような開発プロセスの歴史を知っておくことは、開発プロセスの本質を理解するうえで役立
「自分を変えられるのは自分しかいない」。2006年9月5日,ソフトウエア開発プロセスの一つ,eXtreme Programming(XP)を提唱しているKent Beck氏を囲んで記者懇談会が開催された。自分が変われば,必ずまわりは変わる。そんな信念が感じられた懇談会だった。 Beck氏の著書である「XPエクストリーム・プログラミング入門 第2版」は「XP is about social change.」という文章で始まっている。日本語版では「XPとは社会改革のことである」と訳されているが,ソーシャルのニュアンスが少し違うという意見もある。そこでまず「XPでいうソーシャルとはどういう意味か」と質問した。 Beck氏はソーシャルの例として「14歳になる私の娘は,ある友人と1時間くらい話をし,別の友人と同じ話をまた1時間くらいする。彼女はソーシャルな子供だ」と語った。つまり「社交的」「コミュニ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く