だまってコードを書きます（＞＜；）
いつものJazzバーで、ブルース好きな遠ちゃんが来たのでブルースを聴いてました。 ACES超かっこいいです。 と書くとNikon 1 V1が当たる企画があるわけではありませんが、 http://b.hatena.ne.jp/articles/201203/7773 こちらの記事をTwitter連携した上でブクマすると、なんと！Nikon 1 V1 が当たるかもしれないそうです。 この企画、前回の記事（id:Youchan:20111218:1324217211）で惜しくもMacBook Airをもらいそびれてしまったのですが、その流れでアイデムさんから求人サイトにダメだしをする企画の依頼があって実現しました。 記事の中では書かれていませんが、一番のダメだしポイントはもちろんMac BookAirがわたしに当たらなかったことです。 今度こそNikon 1 V1がほしいです！！！！ 最近うちの
IoCについて調べてみる
cles::blog 平常心是道 blogs: cles::blog NP_cles() « 本日休業 :: 映画観てきました » 2004/04/26 IoCについて調べてみる aop 70 0へぇ AOPの研究絡みでJbossAOPなんかを調べていたら、いろいろなところでIoCという単語が出てきた。 ちょっと気になるのでいろいろと調べてみたら、リファクタリングなんかで有名なMartin Fowlerが書いたInversion of Control Containers and the Dependency Injection patternというものを見つけた。 かくたにさんが翻訳された日本語訳も公開されている。 † IoCとは Spring Pad - Inversion of Control "IoC(Inversion of Control)はデザインパターンの一種で、協調し
Transaction Script(Domain Logic Patterns)
Domain Logic Patternsは、ドメインロジック－よくビジネスロジックとか言われているもの－をどのように構成・配置するかについてのパターン。 概要 プレゼンテーション層からのリクエストを、ひとつのProcedureとしてまとめる形でドメインロジックを構成するパターン。メリット シンプルさ！-> 理解しやすい。 -> メンテナンスしやすい。 他のトランザクション（nearly equal ドメインロジック）のことを気にしなくていい。-> 多人数の並列開発に向いている。 -> スキルが低い開発者による低品質なコードの影響を局所化できる。 デメリット 同じようなコードがあちこちに出てきやすい。結果的に、規模が大きくなりやすい。注意 1メソッド・1クラスとして構成する必要があるわけではなく、必要に応じて構造化する（当たり前）。間違っても常に1メソッドとして作ったりしないこと。レイヤ構
PofEAA's Wiki - (ファウラー | 読書会)
PofEAAのWikiです。Martin Fowler氏とAddison-Wesley Pub Coの許可を得て、 パターンカタログの翻訳を行っています。bliki_jaと同じくどなたでも参加可能ですので、是非参加してみてください ;-) ※このサイトは書籍の邦訳とは一切関係ありません。 ■ PofEAAのパターンカタログ and PofEAAのパターンカタログ(邦訳版)ここから読み始めるとよいでしょう。対応表もあります。 ■ 読書会 第12回の開催予定は未定です。 ■ PofEAA読書会メーリングリスト読書会に関する話題を扱っていますが、読者会への参加を強制するものではありません。興味のある方の参加は随時受け付けています。
Inversion of Control コンテナと Dependency Injection パターン
以下の文章は、Martin Fowler の「Inversion of Control Containers and the Dependency Injection pattern」を、かくたにが翻訳したものです。原著者の許可を得て翻訳・公開しています。 翻訳にあたっては、kdmsnr さんにご協力をいただきました。ありがとうございます。公開後の改訂履歴を記事の最後に記述しています。 Java コミュニティでは軽量コンテナが花盛りである。 軽量コンテナは、異なるプロジェクトのコンポーネントをひとまとまりのアプリケーションとして組み立てることを支援する。 このようなコンテナの根底には、コンポーネントの結び付け方についての共通したパターンがある。 そのパターンのコンセプトは「Inversion of Control(制御の反転)」と、まことに包括的な名前で呼ばれている。 本記事では、このパタ
J Dev's LABO:ジェネレーションギャップパターンの意外な有用性 - livedoor Blog（ブログ）
ジェネレーションギャップパターンというデザインパターンがある 今回はその有用性について ジェネレーションギャップパターンはソースの自動生成を行う際に適用するもの 自動生成したソースを編集せず、そのサブクラスを作って編集することにより、自動生成するソースに仕様変更が発生した場合も、編集した箇所が消えない 考えてみて欲しい。自動生成したソースを編集していたとする 自動生成するソースに仕様変更が発生して、再度自動生成しなければならない 再度自動生成すると、編集していた箇所が０に戻るのだ。今まで編集していた箇所をすべてマージする必要が出てくる でもサブクラスを編集していれば、親クラスが変更されるだけでマージの必要はない そういうパターン でも今回はさらなる有用性を感じた 仕事で下記のような内容のコーディングを行うことになった --------------------- 作業▽ ソースの自動生成ツー
dpinfo.html
目次 はじめに Abstract Classパターン Abstract ClassパターンRuby版 (by 助田雅紀さん) Balkingパターン Before/Afterパターン Futureパターン FutureパターンRuby版 (by 助田雅紀さん) Generation Gapパターン Hook Operationパターン Hook OperationパターンRuby版 (by 助田雅紀さん) Immutableパターン Marker Interfaceパターン Monostateパターン MonostateパターンRuby版 (by 助田雅紀さん) MonostateパターンPerl版 (by 宮川さん) Null Objectパターン Null ObjectパターンとSingletonパターン Producer-Consumerパターン Sharableパターン Singl
3つのモデル - どのモデルを中心にするのか（ひがblog）
id:n-ichimuraさん、S2Laszloの開発は止まっているようですが、別の方に引き継いでも良いですか。よろしくお願いします。 http://d.hatena.ne.jp/higayasuo/20050825#1124957707で書いたActionとServiceの統合ですが、いろいろ考えてみましたがActionの責務が多いと思うので、やはりActionとServiceは分離すべきだと思います。 そもそもこの話は、Dxoをどこに置くべきかの話だったのですが、やはりServiceにおくべきだと思います。 モデルは、その使われる場所によって、プレゼンテーションモデル、ドメインモデル、ERモデル(RDBMSの場合)に分かれます。プレゼンテーションモデルはプレゼンテーション層で使われ、ドメインモデルはビジネスロジック層で使われ、ERモデルはリソース層で主に使われることになります。 どのモ
第2回 三層アーキテクチャとは | gihyo.jp
三層アーキテクチャモデル 今回は従来から一般的に言われている三層アーキテクチャモデルについて説明します。 三層アーキテクチャはメインフレーム上でのレガシーシステム時代から提唱され、さまざまな形になってきています。まず、プレゼンテーションレイヤ、ビジネスレイヤ、データレイヤの三層に分ける代表的な例を説明いたします。 ① プレゼンテーションレイヤ層 この階層はシステム操作するユーザに対してのユーザへのインターフェイスを提供します。 この階層にはユーザインターフェイスコンポーネントおよびユーザインターフェイスプロセスコンポーネントが含まれます。 ② ビジネスレイヤ層 この階層にはプレゼンテーションレイヤからデータなどが渡され、業務処理を実行します。 プレゼンテーションからのデータ授受をシンプルにかつ柔軟にするためにサービスインターフェイスを設計します。 ビジネスレイヤでは業務処理を実行するためビ
よくわかるソフトウエア・パターン - 特集 オブジェクト指向は難しくない！：selfup
Part3では，もはやオブジェクト指向開発では欠かせない存在となったソフトウエア・パターンについて解説しましょう。デザインパターンに代表される様々なソフトウエア・パターンを活用して，熟練者の経験を盗み，オブジェクト指向開発を円滑に進める術を習得してください。 ソフトウエア・パターンの全貌 皆さんは誰かが書いたプログラムを眺めていて，どこかで見たようなソフトウエア設計やコードに出くわしたことがありませんか？ 「このクラスの役割はどこかで見たことあるなあ」とか「このコードは何度も自分で書いたことがあるぞ」といった感覚です。そのような既視感は，そのコードを書いた人が，皆さんと似たような状況で，繰り返し発生する問題を抱えて，似たような設計/実装を行ったからかもしれません。 ソフトウエア・パターン＊1は，このような繰り返されるソフトウエア設計を集めたものです。それも単に集めたのではなく，様々なソフト
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.itarchitect.jp/enterprise/-/12321.html