データモデル考え中 - 急がば回れ、選ぶなら近道
ただいま社内的に論争中なのでちょっとまとめておく 分散環境でのデータモデルはどうあるべきか という議論。 分散環境は非同期処理が中心にはなるのだが 画面系を中心に同期処理も入ってくるので その組み合わせを前提に考えないといけない。 基本的に外部から変更不能のタイミングが必ずある というのが、まずは原則論にはなる。 分散処理のレイテンシーはこの先下がる一方なので ますます使われるようにはなると思う。 その辺りを前提として 各考え方のメリット・デメリット をまとめて置きたい。 1プロセス中心指向 プロセス・フローを中心にモデル（型）の議論をすべき という考えかた。 フローモデルは、プロセス->プロセスが基本で 受け渡しをするエッジの部分がデータモデル的位置付け そもそもデータモデル自体は、 黙示的に一種の振る舞いを想定するはずなので 振る舞いの記述にウェイトを置いた方が良い、 という考え方でも
仮想パネル：ソフトウェアアーキテクチャの文書化について
Len Bass氏, SEI (Software Engineering Institute)のテクニカルスタッフのシニアメンバ、Software Architecture in Practiceと、もうすぐ第2版の出る "Documenting Software Architectures: Views and Beyond"の共著者。 Grady Booch氏, IBMフェロー、 Webサイト"Handbook of Software Architecture"の著者 Paulo Merson氏, SEI (Software Engineering Institute)のテクニカルスタッフのシニアメンバ、"Documenting Software Architectures: Views and Beyond"の共著者 Eoin Woods氏, Barclays Global Inve
BigtableとSmalltable - スティルハウスの書庫の書庫
App Engineによる設計手法でひとつ私が実案件で試してなかなかうまくいったと思ったのは、「Smalltable」って私が勝手に呼んでいるアーキテクチャです。簡単にいうと、「複数クライアントのローカルのSQLite間をDatastoreを介して同期する」仕組みです（こういうの一般に何パターンと言うのでしょう…教えてください！）。 クライアントはHTML5やAIR、iPhone、Android等のリッチクライアントで（実際に実装したのはAIRとiPhoneです）、SQLite等の小規模RDB（以下、Smalltable）をローカルに持つことが前提 Smalltableは、Datastoreが保持するすべてのデータのうち、そのユーザーが常時使用するデータのみ保持するサブセット アプリケーションの大半のロジックをリッチクライアント内のSmalltableだけで実装する すべてのレコードにはク
NOSQL Patterns
Over the last couple years, we see an emerging data storage mechanism for storing large scale of data. These storage solution differs quite significantly with the RDBMS model and is also known as the NOSQL. Some of the key players include ... GoogleBigTable, HBase, Hypertable AmazonDynamo, Voldemort, Cassendra, Riak Redis CouchDB, MongoDB These solutions has a number of characteristics in common K
えせMVCについてそろそろ一言言っておくか - ひがやすを技術ブログ
Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある RailsのえせMVC疑惑で盛り上がってますね。Railsが「えせMVCフレームワーク」ではないのは、みんな知っていると思うので、記事、コメントをみて勘違いしている人が多そうな部分に一言書いておきます。 まず、おかしいのはsatoshiさんのこの意見。 PhotoShareは主にRailsで作られているので、ModelはActiveRecordが担当しているわけだが、Modelのレイヤーが非常に薄いために（O/Rマッピングをしているだけ）、データベースの整合性の責任がController側にある。そのため、ちょっとした機能変更のたびにAPIレベルでのテストを大量に走らせなければならないし、それでもどうしてもミスが生じてし
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
Javaアプリケーション開発におけるコード生成の役割
原文(投稿日：2009/09/03)へのリンク SpringSourceのSpring Roo、Skyway Builder Community Edition 6.3、Blu AgeのM2Springといった最近リリースされたコード生成ツールを見ると分かるのは、エンタープライズJavaアプリケーションの開発におけるコード生成の役割に再び関心が集まっているということだ。 コード生成も含んだモデル駆動開発（MDD）は、ますます関心を集めつつある。それは一般的なJavaアプリケーションで自動生成できるものがいくつもあるからだ。一般的なウェブJavaウェブアプリケーションはDAOのようなクラス、XMLのマッピングファイル、SpringやLog4Jの設定ファイルを利用するが、これらはどれも自動生成が向いている。 Rooは双方向型のコード生成フレームワークで、Springベースのウェブアプリケーショ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
dfltweb1.onamae.com – このドメインはお名前.comで取得されています。
はてなブックマークのシステムについて
97 Things Every Programmer Should Know
InfoQ: データの削除は非推奨
スケーラブルなWebサービスの構築