Virtual DOMを持つMV*ライブラリのmercuryについて
最近node-webkitアプリを書く時、何かしらのMV*やデータバインディングライブラリと言われるものを試しているのですが、floating-memo.appではRaynos/mercuryを使いました。 mercury は小さなモジュールを組み合わせたライブラリとも言えますが色々特徴的です。 完全にモジューラーな実装 Virtual DOM FRP ファイルサイズが小さめ モジューラーな実装とは何かというとmercuryのindex.jsを見ると面白い事が書かれています。 /* Pro tip: Don't require `mercury` itself. require and depend on all these modules directly! */ require("mercury") しないで、直接それぞれのモジュールを読み込んで使えるという事が書かれています。 (これ
中規模Web開発のためのMVC分割とレイヤアーキテクチャ - Qiita
TL;DR MVCもレイヤで捉えて関係性の設計をするといいのでは 普通のRubyオブジェクトを積極的に使いたいですね 「パーフェクト Rails」に期待しましょう 長くなって面倒くさくなり、途中から手抜き感が半端ないですが許してください この記事の位置付けなど 7 Patterns to Refactor Fat ActiveRecord Models - Code Climate Blog [翻訳] エリック・エヴァンスのドメイン駆動設計 エンタープライズ アプリケーションアーキテクチャパターン これらの参考文献を踏まえてRailsアプリケーションのリファクタリングをしていて、だいぶ方向性や考え方がまとまってきたので、これからチームに合流する人を想定読者に、Qiitaがどんな感じで作られているのかを文書化したものです。（参考文献の一覧は記事の最後にあります） 内容的には文献[2,3]を踏
Play Framework - Build Modern & Scalable Web Apps with Java and Scala
Play Framework makes it easy to build web applications with Java & Scala. Play is based on a lightweight, stateless, web-friendly architecture. Built on Pekko (Play 3) and Akka (Play 2), Play provides predictable and minimal resource consumption (CPU, memory, threads) for highly-scalable applications. Developer friendly. Make your changes and simply hit refresh! All you need is a browser and a tex
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
MVCの議論で思い出したこととか | TRIVIAL TECHNOLOGIES 4 @ats のイクメン日記
みんなのIoT/みんなのPythonの著者。二子玉近く160平米の庭付き一戸建てに嫁/息子/娘/わんこと暮らしてます。月間1000万PV/150万UUのWebサービス運営中。 免責事項 プライバシーポリシー たまにPython自体の技術コンサルみたいなことを頼まれることがある。プロダクトのコードを読ませてもらって，改善点を指摘したりするようなことをやる。 ただ，純粋にPythonにかかわるアドバイスって最初のうちだけで終わってしまい(Pythonは覚えること少ないからね)，だんだんと設計みたいな部分に切り込んでゆくことになる。フレームワークを使ったコードで本当によく見かけるのが「分厚いコントローラに薄いモデル」みたいな設計。もっと進んで「分厚いテンプレート(ビュー?)に薄いコントローラとモデル」というのもたまにあるんだけどあまりない，かな。 で，そういう場合は「テスト」を軸にして，設計上コ
Web アプリの MVC 設計まとめ - もやし日記
MVC 設計について考えていたときに、ちょうどその辺りの話をされている方々が居たので、今の考えをまとめてみました。 目次 前提 肥大化するコントローラを避ける ビジネスロジックをどこに書けば良いのか コントローラとモデルの間にもう一つの層があるとうまくいく？ まとめ 前提対象は Web アプリケーションで、画面数（ビューの数）は数個〜100個程度の規模です。WordPress、Twitter、37signals のサービスのようなものを作ろうとするとき、どういう MVC 設計をしていくかについて考えます。巨大なシステム、金融系システム、基幹系システムなどを作る場合とは異なる考え方もあると思います（そもそも MVC を使わない、など）。 肥大化するコントローラを避ける例えば、八百屋さんで「６０円で仕入れたリンゴ１つを１００円で売った」こと（Sales Transaction）を記録する場合を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
