JavaScript MVC座談会。遅くならない？ それぞれの特徴は？ サーバとの通信は？（前編）
JavaScriptでの大規模アプリケーション開発を支援する「JavaScript MVCフレームワーク」がいくつも登場し、注目され始めています。7月11日に開催された「第31回 HTML5とか勉強会」では、このJavaScript MVCフレームワークがテーマとなり、主なフレームワークの紹介と座談会が行われました。 それぞれのフレームワークがどんな特徴を持ち、何に向いているのか。非常に勉強になる内容でしたので、この記事では座談会の内容を紹介したいと思います。 座談会に登壇したのは以下の方々です。 Backbone.js 清水大輔氏（NHN Japan） Spine 村田賢一郎氏（Acroquest Technology） Ember.js 斉藤祐也氏（サイバーエージェント） AngularJS 北村英志氏（グーグル） 司会はPublickey新野が務めました。 JavaScript MV
TodoMVC
Thanks for stopping by! Let's get started TodoMVC is a common set of JavaScript examples for MVC frameworks like SproutCore, JavaScriptMVC, Backbone, YUILibrary, Spine, Sammy, AngularJS and others. Live examples To preview a Todo implementation for a particular framework, simply select it from the menu to the right of the screen. Depending on the browser you're using, you may need to access the
Closure Library Geeks - MVC による設計
MVC パターンとはインターフェースを Model 、 View 、 Controller の 3 つに分割して設計する方法です。 それぞれがどの機能を担当するのかについては様々な流儀があります。 一般的には Model はロジック、 View は表示、 Controller は状態指示というように分担させます。 このような MVC パターンの目的は、表示と入力（状態指示）の互換性を高くすることです。 このパターンは多くのプロダクトで採用され、 MVC パターンを実現する様々なライブラリ・フレームワークがあります（参考：JavaScript MVCフレームワークはすでに十種類以上、その比較や最新情報などのまとめ）。 様々な流儀があるとはいえ、実績のあるパターンといえるでしょう。 たとえば、データベースに在庫状況の時系列変化が入力されていて、これを表示する Web サイトを考えます。 MVC
Backbone.jsを利用したクライアントサイドMVCの導入についてそろそろ書いておくか - 出町ミスド攻防記
jQueryヘビーなアプリケーションの問題点と、MVCによる構造化の必要性 jQueryは、ブラウザ上で動くJSアプリケーションの開発生産性を劇的に向上させました。DOM操作による動的なページ書き換え処理などは、セレクタを使ってちょろっとコードを書くだけで、ほんの数行で記述できてしまいます。 しかし、この方法の延長で、大規模なJSアプリケーションを構築することは果たして現実的でしょうか。例えば「GMail」や「New Twitter」程度の規模のJSアプリケーションを書かなければならないとしたら、どうでしょう？ 大規模なJSアプリケーションを開発するには、こういった手法を延長するのではなく、より洗練されたデザインパターンを導入する必要があります。この目的にぴったりのデザインパターンが、「MVC」デザインパターンです。 MVCパターンは、Webの世界ではサーバサイドプログラミングで広く知られ
JavaScript MVCフレームワークはすでに十種類以上、その比較や最新情報などのまとめ
グーグルが開発したJavaScript MVCフレームワーク「AngularJS」を紹介した1つ前の記事の反応が予想以上に大きく、1日たたずにブックマークが500以上もつきました。 本記事では、AngularJS以外にもすでにたくさん存在するJavaScript MVCフレームワークに関する情報をまとめて紹介したいと思います。 JavaScript MVCフレームワークの比較記事 既存のJavaScript MVCフレームワークを比較した記事が「The Top 10 Javascript MVC Frameworks Reviewed」です。Top10と書いてありますが、12種類のフレームワークの比較です。これは公開当時は10種類だったものが、その後11種類になり、今回のAngularJSの公開で12種類になったためです。 上記のような比較表を載せた上で、12種類すべての利点と欠点を説明し
こてさきAjax:クールなMVCを実現するフレームワーク Angular.js の紹介 - livedoor Blog（ブログ）
先週＆今週は、出張でアメリカ西海岸。そんな折、先週の金曜日（16日）の夜に BayJax meetup が Yahoo! 本社で開催されるということで、参加してきました。 BayJaxは、シリコンバレー地区のAjax & Javascriptに関するMeetUp。大体、半年おきに開催されているようです。今回参加したMeetUpの形態は、Conference形式（勉強会ののりに近い）。日本との勉強会との違いは、最初にピザを食べてお腹が満たされたところで勉強会が始まることと（こっちの考え方の方が、確かにリーズナブル）、質問が活発なこと（海外では一般的なことですが）。とても、楽しい時間を過ごすことが出来ました。 その中で講演された AngularJS について、今回は紹介します。 AngularJS AngularJSは、とてもシンプルにWeb Appを書くことができる軽量な MVC フレームワ
グーグル製のJavaScript MVCフレームワーク「AngularJS」、正式版が公開 − Publickey
グーグルは、JavaScriptでMVCアーキテクチャのアプリケーション開発をする際に便利な機能を備えたライブラリ「AngularJS 1.0」のリリースをブログで発表しました。 MVCアーキテクチャとは、ソフトウェアがデータモデル（Model）の部分とユーザーインターフェイスの部分（View）、そしてビューとモデルのあいだで制御する部分（Controller）に分離された構造のことを指します。 これらが分離されているとプログラムの見通しがよくなり変更にも対応しやすく、テストも容易になるため、何種類ものユーザーインターフェイスと複雑なロジックなどから構成される大規模なアプリケーションではMVCアーキテクチャの採用が望ましいものと考えられています。 しかしWebアプリケーションをMVCアーキテクチャで実現しようとすると、ビューの役割を果たすHTMLのコードの中に、どうしても複雑なJavaSc
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
サバクラ両方で動く JavaScript の大規模開発を行うために
サバクラ両方で動く JavaScript の大規模開発を行うために 原文：Scaling Isomorphic Javascript Code (This is just for study, please contact me at tily05 atmark gmail.com if any problem.) 考えてみれば Model-View-Controller とか MVC ってよく聞くよね。実際どんなものか知ってる？ 抽象的に言うなら「オブジェクト情報の保持されるグラフィック・システム (つまり、ラスターではないグラフィック。ゲームとか) 上に構築された、表示系を中心としたアプリケーションにおいて、主要な機能どうしの関わりをうまく分離すること」とでも言おうか。もう少し深く考えを押し進めてみれば、これは当然、他のさまざまなアプリケーションにもあてはまる言葉 (bucket te
【雑記】 そろそろMVCモデルについて一言いっておくか
なーんて、MVCを語れるほどの知識はないのだが、琴線に触れてしまったので、私なりに言いたいことを言うことにする。 本当は、こんな話より先に、先日参加したGAE Nightの話や、Winnyの金子さんが無罪になった話を書きたいのだけど、ココとか、ココとか、ココとか、ココとか、毎日毎日毎日毎日、MVCを語られると、何かいいたくて、もう我慢できなくなってしまった。（これはエンジニアの性なのか！？） 中島さんのBlogのなかで最も釣られてしまうキーワードは「えせ」。これを使うということは、自分の考えだけが正しくて、他は間違いであるということを暗にいっているようなもの。多くの人はそれに反応してしまうから、感情論になって、あまりよい結論は見い出せなくなってしまっているんじゃなかろうか。中島さんの言っていることは概ね理解できるし、RESTfulな設計などは私の考えと被る部分もあって、ほぼ同意できるのだが
MVCパターンとPACパターン - みるくCocoa
This webpage was generated by the domain owner using Sedo Domain Parking. Disclaimer: Sedo maintains no relationship with third party advertisers. Reference to any specific service or trade mark is not controlled by Sedo nor does it constitute or imply its association, endorsement or recommendation.
MVCとPAC - noopな日々
Presentation-Abstract-ControllerとModel-View-Controllerについてさらっと言及 MVCアーキテクチャはある程度の規模になると限界が訪れる。 http://c2.com/cgi/wiki?RecursiveModelViewController http://d.hatena.ne.jp/noopable/20090127/1233014697 この、1999年の記事でPACについて触れられているが、PACはMVCのスケール問題、その他を解消しうる。MVCでも、RecursiveMVCでMVCに階層構造を持ち込んで解決するという方法もあるらしい。 http://www.asahi-net.or.jp/~dp8t-asm/java/articles/OOAD/article.html#fig:pac 似たようなことは誰でも一度は考えることだろう
Life is beautiful
ここのところ「iPhoneアプリのUIの大半（ひょっとしたらアプリすべて）をHTML+JavaScript+CSSで作ることはできないか？」に挑戦している私。 そのためにまずは部品作りからとりかかっているのだが、昨日から今日にかけて作ったのは、プログレス・バー、スライダー、トグルスイッチなどの「連続値・不連続値」を表示・入力用UIコントロールをウェブページ上で実現するためのJavaScriptライブラリ。 見た目（Look&Feel）はCSSを使って自由に指定できるように作りつつ、シンプルでありながらいろいろな場面で使い回しがきくライブラリを作りたかったので、何度もリファクタリングを繰り返してしまったが、なんとか形になってきた。 ということで、そのライブラリ（jTouchControl version 0.10）を使ったiPhone風トグルスイッチを公開。一応、Safari (4.0),
えせ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の発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
ＭＶＣのモデルはDBじゃなくてもいいんだよ - D-6 [相変わらず根無し]
ＭＶＣのモデルはDBじゃなくてもいいんだよ id:charsbarさんが、先ほど書いたエントリに関して 後半その通りなわけですが、CatalystはModel::DBIC系のせいでMVCが誤解されてるのよねー と言っておられる。たしかにその通り。「モデルってDBでしょ？」みたいな印象が一般的にあると思う。 そういう印象を持ってる人に説明すると、「モデルを作る」って何かというと、DBのようなストレージにあるものをどうこうする、ではなくて「データに対する操作を抽象化したものを作る」ということです。例えば、ブログを作ると、Blog、BlogEntry、BlogUserみたいなモデルを作ります。そしてその操作方法はこんな感じ： # ブログを登録するみたいなAPI MyApp::Model::Blog->create({ user => $blog_user, title => $title, .
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Dátiles Sin Carozo 1kg