ソフトウェアアーキテクチャの歴史 - tasuwo's notes
改めて ソフトウェアアーキテクチャ GUI のアーキテクチャの歴史を調べてみたくなった。本来の MVC とは何か？何が正しくて何が間違っているか？も重要なのだが、それよりは、なぜそれが生まれたのか？何を解決しようとしたのか？どのような問題点が生まれて、それをどう工夫して解決・発展してきたのか？を知りたい。しかし、そういうことがまとまっている日本語の情報が少ないので、自分で色々かいつまんでメモしておく。 MVC の原点は 70 年代にまで遡り、実装としては Smalltalk-80 のクラスライブラリとして実装されたのが最初だと思われる。しかし、後世に大きな影響を及ぼしたポイントをいくつか持ちつつも、当時のアーキテクチャが現代においてそのまま利用されているケースはほぼないといっていい。したがって、単に MVC といった時には大抵最初期の MVC を指すことは少なく、区別するために最初期の M
アラン・ケイとMVC｜tenjuu99｜note
MVCについての記事なんてまたかと思われる向きもあるかもしれません。ですが、いままでMVCについての解説記事で、ここに書いたような内容のものを見なかったので(自分が調べ足りないだけかもですが)、書いておこうと思います。この記事は、一番最初のMVCの出発点について確認しておこうという内容です。特に論争的な意図を持った記事ではないですが、マサカリは歓迎します。 Trygve ReenskaugMVCの発明者はトリグヴェ・リーンスカウク(Trygve Reenskaug)氏だと言われています。 MVCの初出(といってもおそらく体裁からメールかなとおもいます)は多分これだと思われます。 http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf 翻訳はこちらにありますあります。原著者の了解も得ているとのことで、感謝しかありません。 実際に読
Martin Fowler's Bliki in Japanese - ドメインモデル貧血症
http://martinfowler.com/bliki/AnemicDomainModel.html これはずいぶん昔からあるアンチパターンのひとつですが、今になって台頭してきているようです。 Eric Evans と話したのですが、彼も、それがだんだんポピュラーになってきていることに気づいていました。 私たちほど大の「真Domain Model」推進者としてみれば、ちょっとうれしくありません。 ドメインモデル貧血症の基本的な症状は、一見、それが本物のドメインモデルに見えるという点です。オブジェクトがいくつかあり、それらはドメイン空間にある名詞から名前をつけられています。それから、オブジェクト同士がしっかりとしたリレーションで結びついており、本物のドメインモデルと同じような構造を持っているのです。 ただし、オブジェクトの振る舞いを見れば違いが分かります。それらのオブジェクトにはわずかな
Angular.jsでvalue="初期値"を使いたいときは、ng-initを使いましょう - dai-yamashitaの日記
タイトル通り。。。 http://docs.angularjs.org/api/ng.directive:ngInit マニュアル良く読もうね！！俺。。。orz <input type="text" name="name" ng-model="name" value="<?- param ?>" ng-maxlength="5" required /> とかして、あれー。。。なんでー？？テンプレートエンジン使ってるから？とか意味もなく、悩んでました。 正解は、 <input type="text" name="name" ng-model="name" ng-init="name='<?- param ?>'" ng-maxlength="5" required /> ってすれば、テンプレートエンジンと組み合わせても全く問題ないですね！！
AngularJSでng-repeat時の生成内容を分岐させたい
つまり var items = [ {type : 'A'}, {type : 'B'}, {type : 'A'}, {type : 'A'}, {type : 'A'}, {type : 'B'}, {type : 'B'} ]; を ng-repeat 越しに <ul> <li ng-repeat="item in items">Aな感じの内容物</li> <li ng-repeat="item in items">Bな感じの内容物</li> <li ng-repeat="item in items">Aな感じの内容物</li> <li ng-repeat="item in items">Aな感じの内容物</li> <li ng-repeat="item in items">Aな感じの内容物</li> <li ng-repeat="item in items">Bな感じの内容物</l
[JavaScript] Backbone.jsのModelとCollectionを入れ子にしたい « きんくまデザイン
こんにちは。きんくまです。 Backbone.jsは本格的に使ったことがなくて、Underscore.jsのテンプレート機能だけ使ったり、テンプレートとBackboneのViewだけを組み合わせて使ったりしてました。 そしたら、結構うまくいったので、これはなかなか良い！と思い、RoutingのところもIE7でテストしたところ、普通に動いてました。（#のハッシュの方で。） なので、今度はModelとかもからめて本格的に一度使ってみようと思いました。 で、ModelというかCollectionの入れ子構造ってどうやってやるのかと思いやってみたのが今回の記事です。 今回は、下のサイトの記事を参考にしてますので、オリジナルの記事も合わせてどうぞです。 >> Backbone.js – Structuring Nested Models and Collections 想定 会社の部署ごとのデータを
Rails のモデルはどうあるべきか - tomykaira makes love with codes
2013-07-05 Rails のモデルはどうあるべきか rails TL;DR: Rails の model が太りやすいのは、生まれつき責務過剰だから。開発者が設計段階で責務を絞り、食べる量を減らしてあげよう。 Rails の model というのは、概念も実装も、とても奇妙な使われ方をしている。 いささか不気味だし、実害もある。 fat model はずっと Rails 界で話題になりつづけている。 すでに Rails のプロフェッショナルは抜け出せているのかもしれないが、まだ議論の余地のある話題ではあるようだ。 なぜ model が太るかというと、なんでもかんでも model に食べさせるからである。 一日中食べてれば元々どんなにスレンダーでも太るに決まってる。 コードのダイエットは食べる量を減らすか、外に出すしかない。 太ってから外に出すのがリファクタリングである。 後知恵的に
7分半で作るNode.js+MongoDBアプリ - PolyPeaceLight
先日のJJUG SpringのLTをしてきた「7分半で作るNode.js+MongoDBアプリ」の動画を撮り直しました。 本番ではmongoose.Schemaのところをmongoose.modelとしてしまい、まさかのライブデバッグを初めるハメになり、結果として13分となってしまいました。 リベンジとして今日何回かトライしたところ10分を2分半も上回る7分半、スリークォーターの記録を出すことができました。 動画中でやってること 1 環境を証明 nvmとかnodeとかnpmとかがインストールされてないことを証明 env.shは確認するコードが書かれているだけです 2 nvmとmongodbをググる 3 nvmをgitで取得 $ git clone git://github.com/creationix/nvm.git ~/.nvm 4 nvmを環境に読み込む $ . ~/.nvm/nvm.
【雑記】 そろそろMVCモデルについて一言いっておくか
なーんて、MVCを語れるほどの知識はないのだが、琴線に触れてしまったので、私なりに言いたいことを言うことにする。 本当は、こんな話より先に、先日参加したGAE Nightの話や、Winnyの金子さんが無罪になった話を書きたいのだけど、ココとか、ココとか、ココとか、ココとか、毎日毎日毎日毎日、MVCを語られると、何かいいたくて、もう我慢できなくなってしまった。（これはエンジニアの性なのか！？） 中島さんのBlogのなかで最も釣られてしまうキーワードは「えせ」。これを使うということは、自分の考えだけが正しくて、他は間違いであるということを暗にいっているようなもの。多くの人はそれに反応してしまうから、感情論になって、あまりよい結論は見い出せなくなってしまっているんじゃなかろうか。中島さんの言っていることは概ね理解できるし、RESTfulな設計などは私の考えと被る部分もあって、ほぼ同意できるのだが
Web Applicationを綺麗に設計するためのMVACという考え方 - $shibayu36->blog;
【2016/03/04追記】以前まとめたこのMVACという名前の設計は既に古くなっており、今はこのようなアーキテクチャで設計していません。 こんにちは。最近ははてなでMVACというアーキテクチャに則って開発をしているのですが、ようやく意味を理解できてきました。そこで今回は「Web Applicationを綺麗に設計するためのMVACという考え方」について、サンプルを交えながら説明していこうと思います。かなり長くなってしまったので、時間があるときにでもどうぞ。 MVACって？ データソースやロジックを扱う「Model」、表示・出力を管理する「View」、複数のModelとControllerをつなぐApplication、ユーザのリクエストなどを受け取りViewやApplicationを制御する「Controller」の4つの要素を組み合わせてシステムを実装する方式。MVCをさらに抽象化した
マルチコア時代に備えて本気でメモリモデルを理解しておこう - リオーダー & finalフィールド 編 - - かとじゅんの技術日誌
長い文章になってしまったので、概要だけ先に書きます。 以下のJavaプログラムは、常に上から下に順番に命令が実行されると思いますか？つまり、aに1が格納された後に、bに2が格納されると思いますか？ 実は場合によってはこの実行順序が入れ替わる場合があります。これはJavaの言語仕様として定義されていることです。これを考慮しないと信頼性のある並行処理は実装できません。 気になる人は以下を読んでみてください。 a = 1; b = 2; すでにインターネットは社会インフラ化しています。ソーシャルネットワークで多くの人とコミュケーションやコラボレーションできる時代で、個人が情報を作り消費することは当たり前になってきています。そして、インターネット上のコンテンツは増加の一途を辿っています。「情報爆発」なんて言葉も耳慣れた言葉になりましたが、その問題解決のためにMapReduceなどの分散処理技術に注
%26utm_content%3Dlivedoor)
YappoLogs: あなたがData::Modelを使う10の理由
« JPerl Advent Calendar hacker track で Module::Setup の事書いたよ | Main | Module::Requires について hacker track last day を書きました » あなたがData::Modelを使う10の理由 前口上 一昨年書いた『あなたがRuby on Railsを使わない10の理由』を書いたら、おおむね好評とともに読んでもらえたみたいで(ほんとかー?)うれしい限り。実際あのあとも記事の影響ってわけじゃないと思うけどRoR使ってくれた人もたくさんいるし、ますます広まってきているみたいでこれも私設営業の人としてはとてもうれしい。 略 (例によって書きかけなので今後もいろいろ変わったりするかも) Data::ModelはCPAN Moduleである まあ上でああいったけどやはりCPAN Moduleであることそ
自己参照関係ってどんな関係？ - Xupper技術サポート部のページ
自己参照とは、参照するエンティティが自分自身である場合をいいます。 前述しましたが、この自己参照という関係は１対Ｎの参照関係のバリエーションです。 例えば、”上司社員”と”部下社員”の関係を考えてください。 ”上司社員”には、複数の”部下社員”が存在し、”部下社員”には直属の”上司社員”が一人だけ存在したとします。その場合、上司と部下との間には１対Ｎ関係が存在することになります。 しかし、上司も部下も同じ社員であるということは変わりありません。 また、社員は上司でもあり部下でもあるという関係があります。もしも、上司と部下というエンティティを独立して定義してしまうと、データが重複してしまいます。 そこで、”上司社員”も”部下社員”も同じ”社員”というエンティティに統合し、上司と部下という関係（リレーション）のみ残します。そうすると、この自己参照関係となります。 （図１）自己参照 この時の参照
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[ThinkIT] 第5回：テンプレートの作成 (1/2)