Webアプリケーションの構成に関する予備知識 - Qiita
自分の担当したWebアプリケーションを引き継ぐ際に、予備知識として説明したことのまとめ 注意事項 もともと明確に定義されていない概念や、簡単に説明するため正確さを犠牲にした部分が多い 間違っていることを前提に、疑いながら読むのがベター アプリケーションの層構造 アプリケーションを構成するオブジェクトには非常の多くの種類がある アプリケーションの（より良い）構成をオブジェクト単位で考えるのは難しいので、もっと粒度の大きい単位で考えたい アプリケーションをいくつかの層（オブジェクトの所属するグループ）に分割し、層単位でアプリケーションの構成を考える View層（ビュー層） レスポンスをクライアントにとって都合のいい形（i.e. 画面）に変換する層 View層のオブジェクトは Controller層のオブジェクトから利用される DomainModel層のオブジェクトを利用して、ユーザーに表示した
建築エコノミスト 森山高至『新国立競技場の工事費が下がらない理由』
昨年、連載いたしました「新国立競技場をめぐる議論について」なのですが、 この問題が広く世間で建築工学や建築文化をめぐる問題の共有につながれば 本望です。 思いのほか多くの方々に読んでいただいたみたいで、 いろいろとご質問などもいただきまして、ありがとうございました。 新国立競技場の建設コンペをめぐる議論について 1（ザハはイラク出身の建築家） 新国立競技場の建設コンペをめぐる議論について ２（アンビルドアーキテクトと磯崎新） 新国立競技場の建設コンペをめぐる議論について ３（新国立競技場コンペ応募資格） 新国立競技場の建設コンペをめぐる議論について ４（ザハの仕事と今の国立競技場） 新国立競技場の建設コンペをめぐる議論について ５（建築と哲学の諸問題） 新国立競技場の建設コンペをめぐる議論について ６（新国立の募集要項と大きさ） 新国立競技場の建設コンペをめぐる議論について ７（脱構築とは
NoSQLデータモデリング技法
NoSQLデータモデリング技法.markdown #NoSQLデータモデリング技法 原文：NoSQL Data Modeling Techniques « Highly Scalable Blog I translated this article for study. contact matope[dot]ono[gmail] if any problem. NoSQLデータベースはスケーラビリティ、パフォーマンス、一貫性といった様々な非機能要件から比較される。NoSQLのこの側面は実践と理論の両面からよく研究されている。ある種の非機能特性はNoSQLを利用する主な動機であり、NoSQLシステムによく適用されるCAP定理がそうであるように分散システムの基本的原則だからだ。一方で、NoSQLデータモデリングはあまり研究されておらず、リレーショナルデータベースに見られるようなシステマティック
フロントエンドJavaScriptにおける設計とテスト
今日話さないこと JavaScriptの基礎知識、jQueryの導入 気持ちいいUIやUXがうんちゃら CanvasやWebGLを使ったリッチでイケてるゲームの作り方
わたしたちがDDDを実践するに当たってDoctrineをやめようと決断した動機 - Qiita
断り書き:自分たちがやりたいDDDにDoctrineが必ずしも向いていないという判断をしたものです。Doctrineには非常にお世話になっており、批判するものではありません。どのツールにも適材適所があると思います。 機械的なORMでエレガントに表現できないものがあった（ValueObjectなど） Entityが1テーブルに固く対応していて、さらにその知識がインフラストラクチャレイヤからドメインレイヤに漏れ出していて、密結合が発生していた Doctrineロックから脱出したい。Domain ServiceはRepositoryに依存しており、RepositoryはDoctrineに依存している。Doctrineが破滅への道を歩めば、アプリの心臓であるDomainも道連れとなる。 ストレージロックを脱出したい。ドメインレイヤがある具体的なRepositoryに依存していると、簡単にストレージ
AgileData.org in Japanese - オブジェクト・リレーショナル・インピーダンス・ミスマッチ
http://www.agiledata.org/essays/impedanceMismatch.html この論文は、Agile Database Techniques Chapter 7より抜粋。 オブジェクト指向技術はデータと振る舞いを持つオブジェクトを使ったアプリケーションの構築をサポートする。リレーショナル技術はテーブルへのデータの保管をサポートする。また、データベース内部においてはストアドプロシージャ、外部からはSQL呼び出しを用い、データ操作言語（DML; Data Manipulation Language）を使ったデータの操作をサポートする。 さらに進歩したリレーショナル・データベースには、内部的にオブジェクトサポートするようなものもある。 データベースがより強力になるというこの傾向は、時とともに強まりこそすれ弱まることはないだろう。 多くの組織において、オブジェクト
DCI(Data-Context-Interaction)からASI(Actor-Scene-Interaction)へ - ずっと君のターン
あ、タイトルは釣りというか、なんかそれっぽいこと書きたかっただけです。ごめんなさい。 世間から3周くらい遅れてDCIというものの存在を知って、今さらネットで記事をあさって読んでたりします。この辺とか。 http://d.hatena.ne.jp/digitalsoul/20100131/1264925022 http://uehaj.hatenablog.com/entry/20100528/1275011951 https://speakerdeck.com/kakutani/dci-sprk2012 http://mikepackdev.com/blog_posts/24-the-right-way-to-code-dci-in-ruby これらをいい加減に読んで、考えたのではなく感じたことをまとめると 従来よく利用されてきたMVCというアーキテクチャだとユーザーのメンタルモデルと齟齬
DCI in PHPについて考えてみる
DCI(Data, Context and Interactions)というキーワードがRuby界で流行っているとか。 DCIアーキテクチャ - Trygve Reenskaug and James O. Coplien - Digital Romanticism DCIアーキテクチャについて語ってみるよ - uehaj's blog まだよく消化できていないのですが(そもそもMVCだって理解できた気がしない)、PHPではどう実装すればいいかを考えてみました。 DCI概略 斜め読みしたところ、MVCのModelが肥大化しがちなところなので、じゃあModelをData、Context、Interactionに3層分割して実装すればすっきりしますよ、という概念だと読めました。実装によってはContextではなくUseCase、InteractionではなくRoleと書いていることもあるみたい。
DDD アンチパターン：賢すぎるエンティティ
Symfony Advent Calendar JP 2012 - Day 3 ドメイン駆動設計にしたがってドメインモデルをソフトウェアとして表現するのにエンティティが使われます。エンティティは、ドメイン駆動設計におけるモデル駆動設計パターンの1つに分類されます。 賢すぎるエンティティはアンチパターンRuby on Rails由来のアクティブレコードと直結したMVCフレームワークでは、本来エンティティとして扱われるべきクラスを「モデルクラス」と呼び、そこにビジネスロジック等を実装することが推奨されていました。これらのフレームワークでは、自らモデルレイヤー部分もカバーしておきながら、すべてをエンティティとして実装することを強いるため、ドメインモデルの実装にはほとんど自由度がありませんでした。 このスタイルに慣れてしまうと、ピュアなクラスでドメインレイヤーを実装できる状況においても、誤った設計
[ThinkIT] DIxAOPコンテナ「Seasar2とSpring」 第5回：AOPとは何か (1/4)
AOPとはアスペクト指向に基づいたプログラミングのことです。しかし「アスペクト指向」や「それに基づいたプログラミング」とは何でしょうか。 今までにAOPについて様々な文献を読んでみたけれど、よく理解できなかったという方もいらっしゃるのではないでしょうか。何を隠そう、筆者も最初はよく理解できませんでした。 でも、それもそのはず、AOPを解説する人の多くは、アスペクト指向の思想や未来を含めて語っているからです。読者の多くは思想や未来はいいから、今の開発現場にAOPを取り入れると何ができるのか、取り入れると何がよいのかなどを知りたいのだと思います。今回はなるべく思想や哲学を除外した形でAOPの疑問に応えていきます（注1）。 ※注1： 本連載ではアスペクト指向について用語も含め意訳して記述しています。アスペクト指向について正しく学びたい方は「アスペクト指向入門 千葉滋著 技術評論社」を是非お読みく
CPUのアーキテクチャをトイレに例えると | Hinemosu
おもろい。たとえ方がうまいなぁ。 消え気味なのでコピペ。 155 ：・良く分かるパイプライン ：04/04/26 17:20 ID:B6tZVOSS 「おしっこをして手をあらってでてくる」。 トイレが一室しかないと混雑時は長蛇の列ができます。 1.おしっこをする 2.手を洗う。 二段のパイプにすると、手を洗ってる間に別の人が用を足せるようになります。 トイレ一室で二人が気持ちよくなれて、効率が倍になります。 もうすこし深くしてみましょう。 1.ジッパーを下げる 2.ちんちんとりだす 3.放尿する 4.しずくを切ってちんちんしまう。 5.ジッパーをあげる 6.手を洗う 7.紙を使って手をふく 7ステージに分解すると、なんと 7人が同時に処理できます。 これがパイプラインです。 156 ：・良く分かるスーパスケーラ ：04/04/26 17:21 ID:B6tZVOSS トイレの利用はおしっこ
S2AbstractServiceを用いたAction-Service-Logicパターン - 出羽ブログ
以前に「1.5階層のAction-Service-Logicパターン」を紹介させて頂きました。今回は、このアーキテクチャにS2AbstractService を導入した場合のアーキテクチャについて検討してみました。 主な変更点として、S2AbstractService を導入する場合は、アクションやロジックから直接JdbcManagerを使うこと得策ではないと考え、データアクセスロジックは全てサービスを経由するようになった点です。 まずは、アーキテクチャを図示したものをご覧ください。細かい解説は別エントリにて書かせて頂きますが、エンティティ単位のサービスを採用しつつも、ユースケース固有のロジックはアクションに記述する方法を提示したいと思います。 アーキテクチャ（レイヤ構成図） アーキテクチャ（モジュール相関図）
1.5階層のAction-Service-Logicパターン - 出羽ブログ
趣旨とあんまり関係ないですが、Service・Logicをとりまぜた3階層にするならば、エンティティによったものをService、アクションによったものはLogicと呼んだ方が、フレームワーク側の呼び方との親和性は高いように思います。 ちなみに、今はこんな感じの設計はどうかと思っています。 Serviceクラス：エンティティと対につくる。ドメインモデル的な考え方がプロジェクト内でついていけないならばいっそのこと導入しない。 Logicクラス ・ユースケースを跨がる画面まわりの制御処理や、ユースケースをまたがるビジネスロジック特有の処理を書く。いわゆる、サブシステム間共通関数のイメージ。たとえば複数ユースケースであるケースでは沢山の表にインサートするが、あるケースではアップデートのみするようなものを使う。 ・ただし、Serviceクラス的設計が難しい場合には、画面制御的なクラス Servic
Mapping Objects to Relational Databases: O/R Mapping In Detail
Mapping Objects to Relational Databases: O/R Mapping In Detail Most modern business application development initiatives use object technology such as Java or C# to build the application software and relational databases to store the data. This isn't to say that you don't have other options, there are many applications built with procedural languages such as COBOL and many systems will use object d
MVCは死んだ。MOVEするときがきた - きしだのHatena
Conrad Irwinさんの「MVC is dead, it's time to MOVE on.」を訳してみました。 MVC is dead, it's time to MOVE on. この訳文も原文のライセンスを引き継いでCC-BY-3.0ライセンスで利用可能とします。 追記13:58 すでに訳してた方がいました。MVCの時代は終わった。MOVEを使い始めましょう。 - ふじこのプログラミング奮闘記 MVCは死んだ。MOVEするときがきた MVCはすばらしいアイデアだ。モデルを持ち、モデルは内部に少しの状態をもつ。ビューは内部に少しのUIをもつ。そして、コントローラは内部に少しの・・・ 何を持つ？ 私は確かにこのことに気づいた最初の人物ではない。しかし示されたようなMVCの問題のために、あなたは最後には過剰なコードをコントローラに詰め込むことになる。なぜなら、他にどこに入れていいか
Java の語彙で Maybe を説明してみる - ぐるぐる～
java-jaで例外処理の話をしてきました - 西尾泰和のはてなダイアリー を読んで。 Maybe は値があるかないかを型で表すことができます！そう、直和型なんです！とか言われてもイミフだと思うのです(リンク先のエントリがそう説明してるわけではないですが)。 Java の語彙で Maybe の説明をできたら嬉しい人もいるんじゃないかなぁ、とかなんとか。 ただし、書いてたら結構長くなりました。時間がある人はどうぞ。 Maybe？ null より安全に「値がないこと」が扱えるものだよ スタート地点としてはこれでいいでしょう。 以降で、「なんで安全なの？」という全うな疑問に答えてみたいと思います。 問題点 int で説明すると煙に巻いてしまうような気がしたので、User クラスを見てみます。 import java.util.*; class User { final String name;
java-jaで例外処理の話をしてきました - 西尾泰和のはてなダイアリー
ブログを書くまでがjava-jaですが、もう眠いのでとりあえず1行だけ書いて、あとは徐々に書き足す。 会場を無料提供してくれたグリーさん、ありがとうございます！ 誰かが検査例外の話をするだろうと思って書かなかったら結局誰も言及しなかった、Javaのコミュニティなのに。 っていうか聴衆が100人もいると、もしかしてそもそも「検査例外ってなに？」って人もいたんじゃないか？「検査例外がOCPを壊す」とか「Liskovの置換原則のLiskov」とか通じてるんだろうか？とりあえず直和型が通じてないことだけはひしひしと感じた。 Twitterの自分の発言を転載しておく。 ちなみにZen of Pythonでも「エラーを握りつぶすな」と書いてあります 禅 of Python: 20の格言 「例外はそもそも何のため」ってところ、ざっくり省いたんだけどもそういうところのほうがニーズあったかね？？ 「C#1.
ドメイン駆動設計 実践ガイド
Este documento presenta conceptos clave de diseño de dominio y arquitectura de software. Explica patrones como agregados, fábricas y repositorios para modelar entidades y servicios, y describe técnicas como capas de anticorrupción y contextos de dominio acotados para dividir una aplicación. También cubre temas como modelado de eventos, diseño estratégico y mapeo de contextos de dominio.Leer menos
フロントコントローラ - Strategic Choice
フロントコントローラ＠Webプレゼンテーションパターンリクエストすべてを受け付けるコントローラ。どういうこと？フロントコントローラは、一旦全てのリクエストを1つの「ハンドラ」オブジェクトが受けて、それらを「コマンド」オブジェクトに振り分ける仕組みです。どうすれば？フロントコントローラは、「ハンドラ」と「コマンド」から構成します。ハンドラは、URLとリクエストから必要な情報を抽出します。どのようなアクションを実行するかを判断し、アクションを実行するコマンドに委譲します。ハンドラは、レスポンスを返さないため、サーバベージとしてではなくクラス*1として実装されます。ハンドラ自体は極めてシンプルなプログラムであり、実行するコマンドを判断する以外は何も行いません。コマンドは、アクションの実処理を行うクラスです。最終的なビューの決定も、コマンドクラスで行います。コマンドもサーバページではなく、クラス*
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MOVEは望まれなかった子 - the sea of fertility