単一責任の原則（Single responsibility principle）について、もう一度考える | オブジェクトの広場
単一責任の原則（Single responsibility principle）について、もう一度考える はじめに オブジェクトの広場をご覧の皆様ならば、「SOLID原則」という言葉を聞いたことがあるかもしれません。 SOLIDとは、以下の5つのソフトウェア設計原則を並べたバクロニムです。 Single Responsibility Principle：単一責任の原則 Open/closed principle：オープン/クロースドの原則 Liskov substitution principle：リスコフの置換原則 Interface segregation principle：インターフェース分離の原則 Dependency inversion principle：依存性逆転の原則 ソフトウェアエンジニアが知っておくべき設計原則のセットとして、Clean Architecture や
組み込みアジャイルコーチ James Grenning さんインタビュー ( 後編 ) | オブジェクトの広場
去る8月にアメリカ・テキサス州ダラスで開催された Agile 2012 にて James Grenning さんにインタビューを実施させていただきました。James さんは、組み込みソフトウェア開発におけるアジャイル開発のコーチ・トレーナー・コンサルタント、『Test Driven Development for Embedded C』[1] の著者、アジャイルソフトウェア開発宣言の著者17名の1人、そしてアジャイルな見積り手法「プランニングポーカー」[2] の考案者でもあります。 インタビューでは、日本の「 Test Driven Development for Embedded C読書会 」参加メンバーから挙がった質問について順次尋ねる形で進めました。 2012 年 10 月号の前編に続く後編の本記事では以下の話題についてお伝えします。 ・ モデリングやアーキテクチャ設計とTDDの関係
組み込みアジャイルコーチ James Grenning さんインタビュー ( 前編 ) | オブジェクトの広場
去る8月にアメリカ・テキサス州ダラスで開催された Agile 2012 にて James Grenning さんにインタビューを実施させていただきました。James さんは、組み込みソフトウェア開発におけるアジャイル開発のコーチ・トレーナー・コンサルタント、『Test Driven Development for Embedded C』[1] の著者、アジャイルソフトウェア開発宣言の著者17名の1人、そしてアジャイルな見積り手法「プランニングポーカー」[2] の考案者でもあります。 インタビューでは、日本の「 Test Driven Development for Embedded C読書会 」参加メンバーから挙がった以下の話題についての質問を順次尋ねる形で進めました。 ・ 組み込みソフトウェアに対するアジャイル開発やTDDの導入 ・ モデリングやアーキテクチャ設計と TDD の関係 ・
Jonathan Rasmusson さんインタビュー ( 前編 ) | オブジェクトの広場
永和システムマネジメントさんのご厚意により、去る 3 月に Agile Japan 2012 での基調講演を提供するために来日された Jonathan Rasmusson さんに対するインタビューを実施させて頂きました。 Jonathan さんは、「アジャイルサムライ」というアジャイル開発の入門書の著者です。 「アジャイルサムライ」は日本で空前のブームを巻き起こしており、現在日本の各地で勉強会（道場）が開催されています。 インタビューでは、以下の 4 つの分野に渡り、Jonathan さんに質問をしました。 1. Jonathanさんのこれまでの経歴 2. アジャイル開発一般 3. アジャイルサムライ 4. プライベートな生活 今月と来月の 2 回に渡り、Jonathan さんへの突撃インタビューの結果をお届けします。 1. Jonathanさんのこれまでの経歴について -- 今日は、イン
第 43 回 和田卓人 さんの巻 | オブジェクトの広場
ＯＯエンジニアの輪！ 第 43 回 和田卓人 さんの巻 今回のゲストは、和田卓人 さんです。テスト駆動開発の紹介など様々な活動で知られています。 ■ はじめに --- まこたんさんとのつながりは たぶん arton さんがまこたんを紹介した絡みに似てるかもしれないんですけど、以前「Seasar のからさわぎ」とか、 Seasar*1 のコミュニティが、よく飲み会やってたんですね。初めて会ったのもたぶんこの辺りだったと思う。 --- 2005 年ぐらいですか… ヨーロッパ選手権が 2004 年だから…… 2004 年、 2005 年ぐらいですね。 僕はサッカーが好きなんですが、サッカーファンというものは 2 年単位で年を覚えていられるんです。 4 年単位でワールドカップがあって、さらにそこから 2 年ずれて 4 年単位でヨーロッパ選手権があるので、大体あの時に何やってたってのは 2 年刻みで
OOエンジニアの輪！ ～ 第 42 回 黒枝 真(makotan) さんの巻 ～ | オブジェクトの広場
ＯＯエンジニアの輪！ 第 42 回 黒枝 真(makotan) さんの巻 今回のゲストは、makotan さんです。ワークステートエンジン Buri の開発などをはじめ Java のオープンソースプロジェクトの開発で知られています ■ 始めに --- 前回インタビュイーの arton さんから makotan さんをご紹介いただきました。arton さんとはどのようなつながりですか？ あの、宴会です。(笑) 20世紀ギリギリくらいの頃ですね。Seasar ( の開発 ) が始まる前後に飲み会があって、そのときに arton さんに初めて会いました。この人が arton さんなんだ、あの Ruby 邪道編を書いた人なんだ、というところから入りつつも、技術の話は一切してなかったですね。 --- じゃあ、Seasar 本関連とか Seasar プロジェクト関連とかとはちょっと違う。プライベート的
ＯＯエンジニアの輪！第 41 回 arton さんの巻
ＯＯエンジニアの輪！ 第 41 回 arton さんの巻 今回のゲストは、arton さんです。arton さんは ActiveScriptRuby や RJB の開発者であり、また Seasar や .Net 関連、Rails など幅広い分野の著作でも知られています。 ■ 自己紹介--- 簡単に自己紹介をお願いします。 最初は、外資系のコンピューター会社で、メインフレームのミドルウェア系の仕事をしていました。会社がメインフレームから撤退した後は、サーバをやったり、 POS をやったり、あっちいったりこっちいったり。 そういうことやっていると、ネットワークをいじる必要が出てきて、簡単にソケットがたたけて、正規表現が使えて、そういう簡単なスクリプト言語が使いたくなって、なんとなく Ruby*1 を使うようになったのかな。Ruby を使うようになると、GUI があるといいなぁということで、Ac
OOエンジニアの輪！ ～ 第 40 回 関 将俊 さんの巻 ～ | オブジェクトの広場
ＯＯエンジニアの輪！ 第 40 回 関 将俊 さんの巻 今回のゲストは、関将俊さんです。関さんは Ruby の分散オブジェクトライブラリ dRuby やテンプレートエンジン ERB 等を開発しています。また eXtreme Programming を実践されている方としても有名です。 ■ 自己紹介--- 簡単に自己紹介をお願いします。最近されていることのお話をお願いできますか？ 昨年末から、インターナショナル・ジャーナル・オブ・パラレル・プログラミング(International Journal of Parallel Programming)という学会誌か論文誌かの記事をやってます。そこの編集の人から「20ページ書いて」っていう依頼が来て、日本語で書いて、みんなが英訳してくれてと、年末から今年の初めまでやってたんですけど。編集の人かなと思ってた人は、エール大で L で始まる Linda*
OOエンジニアの輪！ ～ 第 39 回 須藤 功平さんの巻 ～ | オブジェクトの広場
「What about the attached patch?」 (英語で説明するのが大変(面倒)なのでパッチで説明しようとするときに使う慣用句) 笹田さんとのつながり ---前のインタビューアの笹田さんとのつながりは？ Rubyのつながりですね。Ruby関係のイベントでよくお会いしています。 実は、笹田さんとはプログラムの組み方で相容れない部分が多いです(笑)。 私はevalメソッド(動的に式を評価するメソッド)が大好きなんですよ。ところが、evalを使うとコードが動的にきまるので最適化しずらい。 笹田さんは処理スピードが速いのが大好きなので、静的に解析できないevalは嫌いだそうです。笹田さんには以前、「eval使ったらsleep(1)を入れとく。毎回余計に1秒かかるぞ」とかいわれました。(笑) 現在のお仕事 ---普段のお仕事って何をされているんですか？ ソフトウェア開発ですね。 メ
OOエンジニアの輪！ ～ 第 38 回 笹田 耕一さんの巻 ～ | オブジェクトの広場
現在のお仕事について ---最初に、今どういうお仕事をやっておられるか、お話していただけますか？ 東京大学大学院の情報理工学系研究科創造情報学専攻で特任助教をしています。ここ、情報理工学系研究科秋葉原拠点は、創造情報学という最近できた専攻のラボになっているんですが、主にここに常駐しています。 そこで具体的に何をしているかといいますと、文科省の「先導的 IT スペシャリスト育成推進プログラム」というプロジェクトに従事しています。産業界から「きちんとわかる IT 技術者が少ないので大学もなんとかしてくれ」という要請があったらしく、文科省の公募により、数拠点が選ばれました。 で、東大と東工大と NII（国立情報学研究所）の 3 つの研究機関が協力してそのうちのひとつ「情報理工実践プログラム」を行っているんですが、私はそこに雇われている、というわけです。 この拠点では、実際にソフトウェアを作ること
[ 技術講座 ] Domain-Driven Designのエッセンス 第1回｜オブジェクトの広場
DDD難民に捧げる Domain-Driven Designのエッセンス 第1回 ドメイン駆動設計とは 株式会社オージス総研 アドバンストモデリングソリューション部 佐藤 匡剛 Domain-Driven Design Tackling Complexity in the Heart of Software Eric Evans 著 Addison-Wesley, 59.99ドル 560ページ ISBN: 0-321-12521-5 「ドメインモデリング」は、アプリケーション開発において最も重要な部分だとされています。しかしその割には、フレームワークの使い方やアーキテクチャの設計方法など技術に関する解説書はたくさんあるものの、ドメインモデリングそのものを扱った書籍はほとんど無かったと言ってもいいでしょう。Eric Evansの『Domain-Driven Design』（以降DDD）は、「
OOエンジニアの輪！ 〜 第 34 回 比嘉 康雄 さんの巻 〜
特になし。 私は人を丸ごと尊敬することはありません。それぞれ好きなところもあれば、嫌いなところもある。できるだけいろんな人の素敵な点を見つけて、その素敵な点を 認識したいです。 現在のお仕事について -- まず最初に、現在の業務についてお話していただけますか？ 弊社でこの 4 月より「Seasar2 技術推進グループ」が新しくできました。そこで主に、弊社の中での Seasar2 を使ったプロジェクトへの支援や、商用サポートなどをやっています。 あるいは、ちょっと会社の仕事には関係ないんですけど、Seasar プロダクトの強化もやっています。 -- 基本的には技術的なリーダーをされているのでしょうか？それともマネジメントが中心ですか？ 時と場合によりけりで、会社ではマネジメントとして判断することがほとんどです。 Seasar ファウンデーションではチーフコミッターとしての役割がありますので、
大規模プロジェクトにおける UML 活用の業 | オブジェクトの広場
※本稿は、技術評論社刊『JAVA PRESS Vol.42』に掲載された記事「大規模プロジェクトにおける UML 活用の業」を加筆、修正したものです。JAVA PRESS 編集部の了承を得たうえで転載しています。 ※一切の転載をお断りします。 はじめに 筆者は，お客様の企業やプロジェクトのために UML を使った開発プロセスを策定したり，その実践をサポートする仕事が多いのですが，開発者の方がいざ UML でモデリングを始めると，ときには開発者のほうが行き詰まってしまうことがあります．このうちの大半は，UML やオブジェクト指向，そして開発ツールへの不慣れが原因ですが，一方で開発プロセスの策定時には予想していなかったケースで，どのように UML で表せばよいのかわからないために行き詰まっていることもあります．このような想定外のケースというのは，UML の教科書にはあまり取り上げられていないが
株式会社オージス総研
大変申し訳ございません。 お客様が指定されたページは見つかりませんでした。 このページは存在しないか、別のURLに移動された可能性があります。 恐れ入りますが、オージス総研トップページより再度目的のページへのアクセスをお試しください。
マイルドなアジャイル開発手法 AMOP | オブジェクトの広場
今回は, アジャイルモデリングを実践するためのベースとなるアジャイル開発手法として筆者らが考案したAMOP (Agile Method for Ordinary Projects) [1] という開発手法を紹介します. AMOP は, 既存の開発のやり方に慣れた開発者や管理者に受け入れられやすいものであることを目指したアジャイル開発手法です. 今回の記事では, まずスクラム [2] の短所や難しい点を説明し, 次いでそれらを XP (eXtreme Programming) [3] のプラクティスでどのように補おうとしたかについて説明します. さらに, AMOP を２つのプロジェクトに適用した結果を紹介します. 1. スクラムの短所や難しさ 前回の記事では, もっともシンプルで取り入れやすいと筆者が考えるアジャイル開発手法スクラムを紹介しました. その記事では, スクラムの長所を中心に説明
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
