サバクラ両方で動く JavaScript の大規模開発を行うためにYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
ダブルMVCの意味するところ [GoGaRuCo 2013] - ワザノバ | wazanova.jp
[Video] http://www.youtube.com/watch?v=s1dhXamEAKQ TildのYehuda KatzのGolden Gate Ruby Conference 2013での講演。 Ruby on RailsのクリエーターであるDavid Heinemeier Hanssonが、「JavaScript勢はダブルMVCで苦しんでいる。サーバとクライアント両方にMVCが必要で複雑すぎる。」とTwitterで発言したのに対して、Yehudaは、それでは誤解を与えると危惧し、GUIプログラミングが歴史的にどのようにMVCに発展してきたかを紹介することで、ダブルMVCが本当に意味するところを解説しています。 DHHの発言は、盛り上がってきたMeteor / Node.js勢に対する単なる批判っぽいですが、それに対してYehudaはロジカルに話をまとめてます。 スライドを
TDD Anti-patterns catalogue at Stack Overflow を簡単に訳してみた - joker1007’s diary
Stack OverflowのTDD Anti-patterns catalogueというスレがとても面白かったので訳してみた。 Stack Overflowのvoting機能でアンチパターンへの投票を行っている感じ。 上から投票の多い順になっている。 得票数はこの記事執筆時点(2013.7.9)のもの。 SQLアンチパターンっぽく、パターン名はそのまま片仮名にしてみた。 また、内容がかなり被っているとか、状況がかなりレアじゃないかと思うものは、一部省略しました。 (ブコメで訳間違ってるよ、って教えてもらったので、一部修正しました 2013.7.10) フリーライド (テストのただ乗り) 50pt 新しいテストケースを書くのではなく、他の機能のテストに新しいアサーションを追加して既存のテストケースに乗っかる。 セカンドクラス シティズン (二等市民) 47pt プロダクションコードのように
リソースモデリングパターン
Webアプリケーションについて、RESTfulなURL・リソース設計のパターンを見出すことで、 どのパターンかを判断するだけで、既存の Good Practice が適用できる 名前をつけて呼べるようにしたい Railsなどのフレームワークで簡単に適用できるようにしたい ということを目指しています。 ほんとうに役立つか これはパターンと言えるのか もっと他にもある だいぶ粒度がバラバラ 名前の付け方（パターンは名前重要） など、ぜひご意見をください。 パターン Collection & Member Resource パターン Singular (Singleton) Resource パターン Filtered Collection パターン Filtered Subresource パターン Multi-member Resource パターン Partial Resource パター
Inversion of Control コンテナと Dependency Injection パターン
以下の文章は、Martin Fowler の「Inversion of Control Containers and the Dependency Injection pattern」を、かくたにが翻訳したものです。原著者の許可を得て翻訳・公開しています。 翻訳にあたっては、kdmsnr さんにご協力をいただきました。ありがとうございます。公開後の改訂履歴を記事の最後に記述しています。 Java コミュニティでは軽量コンテナが花盛りである。 軽量コンテナは、異なるプロジェクトのコンポーネントをひとまとまりのアプリケーションとして組み立てることを支援する。 このようなコンテナの根底には、コンポーネントの結び付け方についての共通したパターンがある。 そのパターンのコンセプトは「Inversion of Control(制御の反転)」と、まことに包括的な名前で呼ばれている。 本記事では、このパタ
クロージャデザインパターン (PHP 版)
2013年4月13日追記: PHP 5.5 で finally 句が追加されたので Loan パターンを追記しました。 Closure Design Patterns で紹介されている Groovy のコードを PHP に翻訳しました。無名関数とクロージャを区別しても情報が分散してしまうのでクロージャに統一しました。Method Combination (関数合成)は省略しました。原文ではカリー化(currying) と書いている箇所を部分適用 (partial application) に訂正しました。カリー化と部分適用の違いについてはこちらのブログに解説があります。Groovy コアに本当のカリー化メソッドを採用することへの要望があり、長期的には取り込まれる見込みのようです。 これらのパターンは Venkat Subramaniam 氏および Neal Ford 氏のプレゼン資料から抜
エンタープライズアプリケーションアーキテクチャパターン・オブジェクトリレーショナル編 - Strategic Choice
書籍「エンタープライズアプリケーションアーキテクチャパターン」の、オブジェクトリレーショナルデータベースに関わる部分をまとめます。第11章 オブジェクトリレーショナル振る舞いパターン第12章 オブジェクトリレーショナル構造パターン第13章 オブジェクトリレーショナルメタデータマッピングパターン一覧「オブジェクトリレーショナル振る舞いパターン」（Object-Relational Behavioral Patterns） ユニットオブワーク（Unit of Work）一意マッピング（Identity Map）レイジーロード（Lazy Load）「オブジェクトリレーショナル構造パターン」（Object-Relational Structural Patterns） 一意フィールド（Identity Field）外部キーマッピング（Foreign Key Mapping）関連テーブルマッピング（
エンタープライズアプリケーションアーキテクチャパターン・オフライン並行性編 - Strategic Choice
書籍「エンタープライズアプリケーションアーキテクチャパターン」の、オフライン並行性に関わる部分をまとめます。第16章 オフライン並行性パターン前段知識オフライン並行性・前段知識：並行処理とはオフライン並行性・前段知識：安全性/活性とはオフライン並行性・前段知識：リクエスト/セッション/トランザクションとはオフライン並行性・前段知識：オフライン並行性とはオフライン並行性・前段知識：楽観的ロック/悲観的ロックとは一覧「オフライン並行性パターン」（Offline Concurrency Patterns） 軽オフラインロック（Optimistic Offline Lock）重オフラインロック（Pessimistic Offline Lock）緩ロック（Coarse Grained Lock）暗黙ロック（Implicit Lock）ソースコードasakichy/PofEAA＠githubPofEA
Post/Redirect/Get - Wikipedia
This article includes a list of references, related reading, or external links, but its sources remain unclear because it lacks inline citations. Please help improve this article by introducing more precise citations. (January 2013) (Learn how and when to remove this message) This article needs additional citations for verification. Please help improve this article by adding citations to reliable
アクティブレコード - Strategic Choice
アクティブレコード＠データソースのアーキテクチャに関するパターン行データゲートウェイ＋ドメインロジック。どういうこと？アクティブレコードは、データベースの「レコード」に対して、ゲートウェイの役割を果たすクラスを作成します。１つのインスタンスが、テーブル内の１つの行にあたります。かつ、そのクラスに「ドメインロジック」を配置します。どうすれば？アクティブレコードのクラスは、レコード構造と一致させます。よって、クラス内の各フィールドは、テーブル内の各列と一致します。同時に、オブジェクトが保持しているレコードデータを追加・更新・削除するメソッドを提供します。ここまでは『行データゲートウェイ』と同じですが、アクティブレコードは、さらに、データに適用されるドメインロジックを実行します。また、検索メソッドも、このクラスに静的メソッドとして用意するのが通常です。どうして？アクティブレコードのクラスは、レコ
行データゲートウェイ - Strategic Choice
行データゲートウェイ＠データソースのアーキテクチャに関するパターン１レコード１クラス。どういうこと？行データゲートウエイは、データベースの「レコード」に対して、ゲートウェイの役割を果たすクラスを作成します。１つのインスタンスが、テーブル内の１つの行にあたります。どうすれば？行データゲートウェイはのクラスは、レコード構造と一致させます。よって、クラス内の各フィールドは、テーブル内の各列と一致します。同時に、オブジェクトが保持しているレコードデータを追加・更新・削除するメソッドを提供します。行データゲートウェイを使用する場合、検索メソッドをどこに置くのかが問題です。静的な検索メソッドを用意することも可能ですが、ポリモーフィズムの邪魔になります。独立した検索用オブジェクトを作成するのがベターです。どうして？行データゲートウェイは、レコードそのもののように見えるオブジェクトを提供します。クライアン
テーブルデータゲートウェイ - Strategic Choice
１テーブル１クラス。どういうこと？テーブルデータゲートウェイは、データベースの「テーブル」に対して、ゲートウェイの役割を果たすクラスを作成します。１つのインスタンスが、テーブル内のすべての行を処理します。どうすれば？テーブルデータゲートウェイは、データの受け渡しが役割なので、基本ステートレスです。テーブルデータゲートウェイは、データベースからデータを取得するための検索メソッドと、追加・更新・削除の各メソッドから構成されるシンプルなインタフェースを用意します。各メソッドは、引数をSQL呼び出しにマッピングし、データベース接続に対してそのSQLを実行します。テーブルデータゲートウェイは、特に『テーブルモジュール』に最適であり、テーブルモジュールが動作するレコードセットデータ構造を作成します。テーブルモジュールには、テーブルデータゲートウェイが唯一の選択肢です。どうして？テーブルデータゲートウェ
サービスレイヤ - Strategic Choice
アプリケーションロジック。どういうこと？ビジネスロジックは2つ種類に分類されます。「ドメインロジック」と「アプリケーションロジック」です。「ドメインロジック」 ドメインでの問題を取り扱う。たとえば、特定のビジネスに特化した計算処理など。「アプリケーションロジック」 アプリケーションの責務を取り扱う。たとえば、担当者へのメール通知や、別の統合されたアプリケーションへの通知など。別名「ワークフローロジック」。サービスレイヤは、ドメインオブジェクトからアプリケーションロジックを分離します。サービスレイヤは、粗粒度のサービスを提供する層を生成して、アプリケーション境界を作成します。境界を通じて、クライアント側に操作のセットを提供します。アプリケーションのビジネスロジックをカプセル化し、その実装の中でトランザクションを制御し、応答を調停します。どうすれば？実装バリエーションには、「ドメインファサード
エンタープライズアプリケーションアーキテクチャパターン・アーキテクチャ編 - Strategic Choice
書籍「エンタープライズアプリケーションアーキテクチャパターン」の、レイヤ化アーキテクチャに関わる部分をまとめます。第09章 ドメインロジックパターン第10章 データソースのアーキテクチャに関するパターン第14章 Webプレゼンテーションパターン第15章 分散パターン一覧「ドメインロジックパターン」（Domain Logic Patterns） トランザクションスクリプト（Transaction Script）ドメインモデル（Domain Model）テーブルモジュール（Table Module）サービスレイヤ（Servic eLayer）「データソースのアーキテクチャに関するパターン」（Data Source Architectural Patterns） テーブルデータゲートウェイ（Table Data Gateway）行データゲートウェイ（Row Data Gateway）アクティブレ
テーブルモジュール - Strategic Choice
ビジネスロジックをデータベースの表ごとに。どういうこと？テーブルモジュールは、データベース内のテーブル１つにつき１つのクラスを持つドメインロジックを構築します。クラスの１つのインスタンスには、データに対して動作する各種の手続きが含まれます。どうすれば？テーブルモジュールは、担当のテーブルのデータ操作メソッドをもたせます。振る舞いとテーブルのグループ化により、カプセル化の多くのメリットが得られます。テーブルモジュールは、インスタンスの場合もあれば、静的メソッドの集合の場合もあります。「テーブルモジュールのインスタンス」と「テーブルの種類」は１対１です。例えば「注文」の場合、ドメインモデルでは１つの「注文」に１つの「注文」オブジェクトが使われますが、テーブルモジュールでは、１つのオブジェクトですべての「注文」を扱います。どうして？テーブルモジュールは、テーブル指向のデータを前提とする構造を持っ
トランザクションスクリプト - Strategic Choice
１ビジネスロジックを１メソッドで。どういうこと？ビジネスアプリケーションは、一連のトランザクションとして考えることができます。トランザクションには、データの単純な表示・登録や、ビジネスロジックが含まれています。トランザクションスクリプトは、ビジネスロジックを１つのメソッド（プロシージャ）にまとめて、データベースを直接ないし薄いラッパーを介して呼び出します。「トランザクション」という言葉を使用しているのは、ほとんどの場合、データベーストランザクションごとに１つのトランザクションスクリプトを使用しているからです。「スクリプト」という言葉は、「スクリプト言語」のことではなく、「コード片」を意味しています。どうすれば？それぞれのビジネスロジックが、それ専用のトランザクションスクリプトを持たせます。１ビジネスロジックに１トランザクションスクリプトなので、他のトランザクションスクリプトは気にする必要が
ドメインモデル - Strategic Choice
ビジネスロジックをオブジェクト指向で。どういうこと？ビジネスロジックにおいて、最も避けたい状況は、そのロジックが「複雑」になってしまうことです。とはいえ、現実のビジネスルールは多くのパターンを持ち、それを反映したロジックはとても複雑になりがちです。ドメインモデルは、この複雑性に「オブジェクト指向」をもって対応します。ドメインモデルは、対象となるビジネスエリアをモデル化したオブジェクトのレイヤを挿入します。ビジネスにおけるデータをモデル化するオブジェクトもあれば、ビジネスで使用するルールを扱うオブジェクトもあります。ドメインモデルは、データベースモデルと似ている場合もありますが、大きな違いもあります。ドメインモデルでは、データとプロセスが一体化され、複数値属性や複雑に絡み合う関係があり、さらに継承も使われています。どうすれば？シンプルなドメインモデルは、データベーステーブルごとに１つのドメイ
matarillo.com: UIパターン
UIパターン 追記 この記事の一部を加筆・修正したものを「開発者が知っておくべき、6つのUIアーキテクチャ・パターン」として@ITに転載しています。 MVVMを追加した上で、アプリケーションモデルとMVVMをプレゼンテーションモデルのバリエーションとして位置づけました。 MVPの2つのスタイルとして、監視コントローラとパッシブ・ビューを説明しました。 まえがき Martin Fowlerの"GUI Architectures"を訳したので公開しようと思ったのだが、FAQページに「EAA developmentとかDSLなんかは商業出版するんで例外ってことで」と書いてある。面倒だったので翻訳の公開はやめて、「自分の理解を書く」というスタイルにしようと思う。 Fowler氏が説明しているのは 「フォームとコントロール」、「モデルビューコントローラー (MVC)」、「プレゼンテーションモデル」、
[ 技術講座 ] Domain-Driven Designのエッセンス 第3回｜オブジェクトの広場
DDD難民に捧げる Domain-Driven Designのエッセンス 第3回 大規模なプロジェクトへの適用 株式会社オージス総研 アドバンストモデリングソリューション部 佐藤 匡剛 Domain-Driven Design Tackling Complexity in the Heart of Software Eric Evans 著 Addison-Wesley, 59.99ドル 560ページ ISBN: 0-321-12521-5 書籍『Domain-Driven Design』を紹介する本連載も、今回で最終回です。前回はDDDの第II部、第III部を紹介し、16のパターンによってドメインモデリングの基本的なアプローチを説明しました。今回は、残る第IV部から22のパターンを紹介します。 単一ドメインを扱ったドメインモデリングのノウハウは、前回までですべて終了です。第IV部「Str
![[ 技術講座 ] Domain-Driven Designのエッセンス 第3回｜オブジェクトの広場](https://cdn-ak-scissors.b.st-hatena.com/image/square/60719ddab4ac85c96737dd2e575f80b57b44d1c3/height=288;version=1;width=512/https%3A%2F%2Fwww.ogis-ri.co.jp%2Fotc%2Fhiroba%2Ftechnical%2FDDDEssence%2Fbook.jpg)
[ 技術講座 ] Domain-Driven Designのエッセンス -目次-｜オブジェクトの広場
［技術講座］ DDD難民に捧げる Domain-Driven Designのエッセンス 第 1 回 ドメイン駆動設計とは 第 2 回 DDDの基礎と実践 第 3 回 大規模なプロジェクトへの適用 DDDパターンカタログ パターン名 参考訳 I. Putting the Domain Model to Work Ubiquitous Language ユビキタス言語 Model-Driven Design モデル駆動設計 Hands-On Modeler 実践的モデラー II. Building Blocks of a Model-Driven Design Layered Architecture 層状アーキテクチャ Smart UI （アンチパターン） 利口なUI Entities エンティティ Value Objects 値オブジェクト Services サービス Modules モジ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
