スクラムのスクラム - 問題と価値
Agile Estimating and Planningの著者のMike Cohn氏(リンク)が「スクラムを大きなプロジェクトチームに適用させるのに重要な技術」と説明しているのが、スクラムのスクラムミーティング(the Scrum of Scrums: 以下SoS)である。これらのミーティングをすることで、いくつかに別れたチームが仕事について議論したり、チーム間で統合が必要な箇所や、オーバーラップしている箇所にフォーカスすることができるようになるのである。 Allan Shalloway氏(リンク)は"Lean Software Development: Scaling Agile to the Enterprise"(リンク)という書籍を執筆している。彼は「チーム間の調整にスクラムのスクラム(成功経験あり)と、スクラムをエンタープライズにスケーリング(これに関しては、何人かの人がいくつ
フィーチャーチーム
フィーチャーチームとは？ フィーチャーチームは、”組織の既存の枠やコンポーネント等にとらわれず、多くの顧客 のフィーチャーを1つずつ完成させる長寿命のチーム” です。フィーチャーチームは、大規模開発でアジャイル開発を実践するために必要不可欠です。フィーチャーチームがなければ、（その代わりに、コンポートネットチーム、コード所有権に基づく、もしくは１つの機能に基づくグループ、アナリストグループ、プログラマグループ、テストグループ等に分類）あなたの組織は、結果的に逐次的開発サイクル（ウォーターフォール, ...）となり、非常に多くの無駄を生み出したり、部分最適化を行います。フィーチャーチームは、多く無駄を取り除くと同時に、変化と挑戦を求めます。 フィーチャーチームのすること？ フィーチャーチームは大きなプロダクト開発で長期間、活躍します。例えば、テレコムシステム（Ericsson）やコンパ
14．Chain of Responsibility パターン
2012/04/26 一部修正しました デザインパターン 14章 Chain of Responsibility パターン 14.1 Chain of Responsibility パターンとは 14.2 サンプルケース 14.3 Chain of Responsibility パターンまとめ 第14章では Chain of Responsibility パターンを学びます。chain は「鎖」、responsibility は「責任」を意味します。したがって、 Chain of Responsibility は、「責任の鎖」と訳すことができます。Chain of Respoisibility パターンとは、「責任」を負ったものが、「鎖」状につながれた状態をイメージさせるパターンです。 例えば、何かの決済を「課長」にお願いすると、課長決裁で対応できるものであれば、課長が決裁します。しかし、
まつもと直伝 プログラミングのオキテ 第16回 ネットワーク・プログラミング（ソケット編）：ITpro
LinuxのようなUNIX系OSでは，ファイルに対する操作と同様にネットワーク通信を行うために，「ソケット」と呼ばれる仕組みを使います。今回はソケットについて学びましょう。 コンピュータは「電子計算機」という和名が示す通り，本来は高速に計算するための機械でした。しかし，現在のコンピュータは，Webブラウジングや電子メールのやり取りなどに使われることが多く，ネットワークと切り離すことができません。最近は「コンピュータを使う」ことと「ネットワークを使うこと」がかなり同義になっているのではないでしょうか。 今回は，ネットワークを介した通信の基礎になっている「ソケット」という概念を紹介します。 ディスクリプタでアクセスが単純に ソケットはネットワーク通信に用いるファイル・ディスクリプタ（file descriptor）です。そこで，ソケットの説明に入る前に，より一般的なファイル・ディスクリプタにつ
オブジェクト指向設計入門 品質を追及する設計
2006.4.28 2 � � � � 1. 2. 3. 4. 5. 6. 4 � � � � � � � � � � � � � � 5 � � � � � � � � � 6 � � � � � � 7 � � � � � � 8 � � � � � � � � � � 9 � � � � � � � � � � � � � � � 10 � � � � � � � � � � � � � � � 11 � � � � � � � – – � � � � 12 � � � � � � � � � � � 13 � � � � � API � � � � � 14 � � � � � � � � � � 15 � � � � � � � � 16 � � � � � � � � � 17 � � � � � � � � � � � 18 � � � � � � � � 19 � � �
ObjectClub - ソフトウェア原則[5] - パッケージ分割
先日、ある人から次のような質問を受けた。 クラスが多くなったので、パッケージ分割をしたい。 パッケージ分割をする時の、指針を教えて欲しい。 話を聞いてみると、1つパッケージが大きくなってしまい管理が煩雑になって しまったため、今更ながら一旦整理をする決心がついたという。いわばパッケ ージ分割のリファクタリングを行おうというわけだ。 さて、ここで読者の皆さんに問題である。パッケージ分割の「観点」(指針) をできるだけ多く出してみてほしい。あなたなら、どんな観点で分割するだろ うか？可能なら数分時間を取って、自分の観点をできるだけたくさん書き出し てから次に読み進めて欲しい。 * * * 以下が、私が現時点で持っている観点である。1つ1つ説明しながら見ていく。 解説には、設計原則との関わりについて考察を加え、さらに、私が感じている ことを書いてみた。 (1) 名前 クラス
連載: IBM Watson Workspace #鬼わか アプリケーション開発: 第 7 回: IBM Watson Workspace で AI を利用したアプリ連携の実現 #鬼わか 解説（前編）
オブジェクト指向を正しく理解する - 特集 オブジェクト指向は難しくない！：selfup
オブジェクト指向はしばしば，とっつきづらく難しい技術と言われます。その理由の一つには，対象とする分野が広く，それぞれに深みがあることが挙げられます。しかし，それ以上にこの技術を難しくしている落とし穴とも言うべき原因が二つあると筆者は考えています。それは比喩を乱用する説明の仕方の問題と，「もの中心」を意味するコンセプト自体の問題です。 そこで本特集では，「オブジェクト指向という言葉をよく聞くけど，実際どんなものかよくわからない」という方のために，初心者/入門者が陥りやすい落とし穴を明確にしながら，オブジェクト指向の全体像を説明します。余計な先入観やまぎらわしいたとえ話に惑わされなければ，オブジェクト指向そのものはそれほど難しい技術ではないことを理解していただきたいと思います。なお，オブジェクト指向プログラミング，デザインパターン，分析/設計といった個々の技術については特集2以降でそれぞれ解説
根本から理解するオブジェクト指向分析/設計
具体論に入る前に，まずオブジェクト指向分析/設計とは何を意味するのかを定義しておきましょう＊1。 そもそも「分析」とはどういったことを指すのでしょうか。辞書を引いてみると，“ある事柄の内容・性質などを明らかにするため，細かな要素に分けていくこと”とあります。オブジェクト指向分析を適用する場面で明らかにしたい事柄とは，どのようなシステムを作らなければならないのかということです。つまり，オブジェクト指向分析とは，“どのようなシステムを作らなければならないのかを，オブジェクトという要素を使って解明すること”ということになります。これに対しオブジェクト指向設計とは，“分析によって明らかにしたシステムの実現手段を，オブジェクトという単位を使って明確にすること”となります。 両者の違いがイメージできたでしょうか。では以降は，具体的なサンプルに基づいてオブジェクト指向分析/設計の仕方を見ていきましょう。
ぼくにもわかるデザインパターン 第2章 GoFパターン大カタログ ～パターンがみるみる頭にしみこむ～ | ウルシステムズ株式会社
GoFパターンカタログ本章では，GoF本に紹介されている23パターン（表1）すべてをカタログにして紹介します。クラス図と適用例に示したJDKのソースなどを参考にして，GoFのデザインパターンの基本概念を確認していきましょう。それでは，次からさっそく始まりです。 Abstract Factory：ハイグレード車用部品とローグレード車用部品を作る下請け工場たとえば自動車メーカTOYATAは，人気車種カラーラを生産しています。カラーラには2 000ccエンジン，本皮シート使用のハイグレード仕様と，1 800ccエンジン，布シートのローグレード仕様の2車種あります。いずれの部品も，製造はすべて下請けの勝どき機械に任せており，TOYATAは勝どき機械が作った部品を組み立てて製品にし，販売しています。勝どき機械には，TOYATAから「ローグレード車種何台分の部品」のように発注がくるため，管理のしやすさ
ももクロスライダーで測る Redis vs MongoDB on Heroku 第二弾 - from scratch
今日はみどりの日らしく、ももクロスライダーも緑の話が活発です。 さてさて、前回に続いてRedisの話です。 危険なほど速いと言われていますが、実際の実力はどうなのか気になるところです。 確かに他の参考記事を見ると、かなり高速なようです。 redis、それは危険なほどのスピード｜サイバーエージェント 公式エンジニアブログ FreeBSDで，mongoDB V.S. Redis - なぜか数学者にはワイン好きが多い じゃーって事で、RedisとMongoDBをベンチマーク比較してみました。 結論から言うと、Redisはやっぱり鬼のように速いです。 ベンチ方法 RedisとMongoにtwitpicから取得してきた ももクロの画像に関するデータを入れておき、それを取り出す処理がどちらが早いかだけを計測しています。更新系の操作も高速なようですが、ももクロスライダーは今は更新系の操作がないので、これ
GitHub - maccman/juggernaut: [DEPRECATED] Realtime server push with node.js, WebSockets and Comet
#Juggernaut Juggernaut has been deprecated! Read why here. Juggernaut gives you a realtime connection between your servers and client browsers. You can literally push data to clients using your web application, which lets you do awesome things like multiplayer gaming, chat, group collaboration and more. Juggernaut is built on top of Node.js and is super simple and easy to get going. ##Features Nod
![GitHub - maccman/juggernaut: [DEPRECATED] Realtime server push with node.js, WebSockets and Comet](https://cdn-ak-scissors.b.st-hatena.com/image/square/64bf45d0fd5cc195d3c6d0449906f6bba1bab05c/height=288;version=1;width=512/https%3A%2F%2Fopengraph.githubassets.com%2F5b7edef380d0aa552ea853a9506daa547c78b4e2ac43f9c45c3a8f462ab2970c%2Fmaccman%2Fjuggernaut)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
デザインパターン[モデリング] -TECHSCORE-
