PHPカンファレンス2019での登壇資料。 書き起こし https://note.com/tenjuu99/n/n0232ccd1089d あとがき https://note.com/tenjuu99/n/nbbb4b273676d メインの話の骨格は、MVC発案者であるトリグヴェ・リ…

フロントエンドの特定技術について語る解説は多くあれど、そもそもフロントエンドのつくりかたについて語った解説は多くないのではないでしょうか。 フロントエンドという大きな領域ですので恐れ多くもありますが、私が GUI プログラミングに携わった経験をもとにお話した内容のスライドとその補足をここでしたいと考えます。 スライド スライドのページ数は多いですが、差分がほとんどですので、それほど構える必要はないです(カーソルキーに負担がかかるという問題を除いて)。 補足解説 大きなテーマごとに補足をしていきます。 スライドで取り上げているテーマは次の4つです。 GUI アーキテクチャパターン データの同期 エラーハンドリング コンポーネント構造 「GUI アーキテクチャパターン」はいわゆる MVC や MVP といわれるものがどういったものかを解説する章です。 「データの同期」は画面と実際のデータが離れ
なにやらMOVEが話題です。 MVC is dead, it’s time to MOVE on. http://cirw.in/blog/time-to-move-on [翻訳]MVCは死んだ。MOVEするときがきた きしだのはてな http://d.hatena.ne.jp/nowokay/20120704 Twitterで「”MOVEは生まれた瞬間死んだ” って記事まだー?」って騒いでたら「お前が書けよ」の流れだったので息抜きに書きます。息抜きなので図が無いのは勘弁してください。 MOVEが生まれていない理由 この文中ではMOVEが生まれた理由はMVCの問題点に関わるとされており、そのMVCの問題点としてされているのは次の2点です。 MVCではControllerが肥大化する MVCは10年古い技術で設計されていて、最新のプログラミングパラダイムに対応していない。 しかしこの理由のう
先週&今週は、出張でアメリカ西海岸。そんな折、先週の金曜日(16日)の夜に BayJax meetup が Yahoo! 本社で開催されるということで、参加してきました。 BayJaxは、シリコンバレー地区のAjax & Javascriptに関するMeetUp。大体、半年おきに開催されているようです。今回参加したMeetUpの形態は、Conference形式(勉強会ののりに近い)。日本との勉強会との違いは、最初にピザを食べてお腹が満たされたところで勉強会が始まることと(こっちの考え方の方が、確かにリーズナブル)、質問が活発なこと(海外では一般的なことですが)。とても、楽しい時間を過ごすことが出来ました。 その中で講演された AngularJS について、今回は紹介します。 AngularJS AngularJSは、とてもシンプルにWeb Appを書くことができる軽量な MVC フレームワ
グーグルは、JavaScriptでMVCアーキテクチャのアプリケーション開発をする際に便利な機能を備えたライブラリ「AngularJS 1.0」のリリースをブログで発表しました。 MVCアーキテクチャとは、ソフトウェアがデータモデル(Model)の部分とユーザーインターフェイスの部分(View)、そしてビューとモデルのあいだで制御する部分(Controller)に分離された構造のことを指します。 これらが分離されているとプログラムの見通しがよくなり変更にも対応しやすく、テストも容易になるため、何種類ものユーザーインターフェイスと複雑なロジックなどから構成される大規模なアプリケーションではMVCアーキテクチャの採用が望ましいものと考えられています。 しかしWebアプリケーションをMVCアーキテクチャで実現しようとすると、ビューの役割を果たすHTMLのコードの中に、どうしても複雑なJavaSc
Alignment and Autonomy in Cybozu - 300人の開発組織でアラインメントと自律性を両立させるアジャイルな組織運営 / RSGT2025
こんにちは。日曜から盲腸で入院中のama-chです。 普段は不健康の代名詞みたいに扱われていますが、これでも小学校は修学旅行の日以外は皆勤だったし、入院するのも初めてなんです。 退屈な入院生活ですが、PCとモバイル通信環境があると一気に世界が開けます。電源、食事、ベッドの三拍子が揃った理想的な職場がそこにはありました。難点といえば、21時に強制消灯されてしまうことと、なかなか風呂に入らせてもらえないことくらいです。 風呂の話はさておき、今年の2月頃から社内で「フロントエンド勉強会」というものを始めています。 JavaScript, CSS, HTML5, UI/UXなど、フロントエンドに関するテーマでざっくばらんに毎週開催しています。だいぶ前になっちゃいましたが、4月にその勉強会でクライアントサイドMVCについて話したので資料を公開します。 明日のためのクライアントサイドMVC 試しにSp
月曜日のclient-side templating 勉強会 http://atnd.org/events/28189 で喋った内容をうろ覚えに書き出す。 クライアントMVCが求められるようになった背景 AJAXの流行 PushStateの流行の兆し メディア系のゲームで使えるAPIの充実 今まではページ遷移の度にJSのオブジェクトを破棄していた。 => シングルページでリッチなコンテンツが作れるようになり、JSのやることが増えた PushStateとは 遷移なしにURLを書き換える技術。HTML5 History API。 Twitter, Github, Facebook URLを書き換えるだけなのでコンテンツ(DOM)の操作はアプリ製作者に一任されている。 大規模なHTML書き換えに、クライアントサイドテンプレーティングが重要になってきた。 PushStateのライブラリ defun
昨日バイト先で男子しか参加しない女子会して、開発の仕方どうするかみたいな話合いしたの面白かった。 押し付け合い回避のためにもレイヤ 趣味や価値観をリアルタイムで押し付け合うのはギスギスして良くないが、話し合うべきときを設けてやはり定期的に話し合うべきだと思った。コード内のインターフェースが少ないと、そういう押し付け合いが起こる可能性が多く出てきたり、それを避けるために心理的に間違った方向に実装しそうで良くない。データAPIが薄くてコントローラに書くことが増えると、コントローラ内で押し付け合いやすいみたいなそういう。レイヤ分けて「はい俺バリア〜ここからさき俺の実装〜〜」みたいなのが良さそう。 MVC界隈の知識源 MVC関係の話、まとまった情報源が無くて、Togetterかブログエントリあたりで適当にまとめられていることが多い。PoEAA(Patterns of Enterprise Appl
Web開発フレームワークとして人気の高いRuby on Railsの最新版、バージョン3を使ってWebアプリ開発の基本を学びます。 人気のフレームワークでWeb開発を学ぶ Ruby on Railsは、いまやWebアプリケーションの開発フレームワークの有力な選択肢の1つとなっています。Ruby以外の言語のWebアプリケーションフレームワークも少なからずRailsの影響を受けているので、現在Rubyを使っていないエンジニアにとっても、Railsを知ることは大いに参考になるはずです。もうすぐRails3認定試験が本格的に開始されるということもあり、この連載では、試験範囲の流れに沿って、Railsの基礎についてご紹介していきます(ただし、必ずしも試験対策というわけではありません)。 今回、連載第1回として本記事では、Railsを理解する上で基本となる考え方であるMVCについて説明した後、Rail
MVC 設計について考えていたときに、ちょうどその辺りの話をされている方々が居たので、今の考えをまとめてみました。 目次 前提 肥大化するコントローラを避ける ビジネスロジックをどこに書けば良いのか コントローラとモデルの間にもう一つの層があるとうまくいく? まとめ 前提対象は Web アプリケーションで、画面数(ビューの数)は数個〜100個程度の規模です。WordPress、Twitter、37signals のサービスのようなものを作ろうとするとき、どういう MVC 設計をしていくかについて考えます。巨大なシステム、金融系システム、基幹系システムなどを作る場合とは異なる考え方もあると思います(そもそも MVC を使わない、など)。 肥大化するコントローラを避ける例えば、八百屋さんで「60円で仕入れたリンゴ1つを100円で売った」こと(Sales Transaction)を記録する場合を
Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある RailsのえせMVC疑惑で盛り上がってますね。Railsが「えせMVCフレームワーク」ではないのは、みんな知っていると思うので、記事、コメントをみて勘違いしている人が多そうな部分に一言書いておきます。 まず、おかしいのはsatoshiさんのこの意見。 PhotoShareは主にRailsで作られているので、ModelはActiveRecordが担当しているわけだが、Modelのレイヤーが非常に薄いために(O/Rマッピングをしているだけ)、データベースの整合性の責任がController側にある。そのため、ちょっとした機能変更のたびにAPIレベルでのテストを大量に走らせなければならないし、それでもどうしてもミスが生じてし
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC(Model View Controller)がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの(コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること)を避
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.
ちょっと北海道に行ってたので間があいた。 このエントリーは、UIパターン その1、UIパターン その2の続きであり、Martin Fowlerの"GUI Architectures"について自分の理解を書くというもの。正しい理解のためには、できれば原文に当たってほしい。 前回までのあらすじだが、その1では「フォームとコントロール」と、古典的な「モデルビューコントローラ(MVC)」を説明し、MVCではモデルに納まらないようなプレゼンテーションロジックの置き場が問題になることを書いた。その2では、MVCの問題点を解決しようとする「プレゼンテーションモデル」と「アプリケーションモデル」を説明した。「プレゼンテーションモデル」は、純粋なモデルをラップし、プレゼンテーションに関する振る舞いを追加したモデルを作成するもの。「アプリケーションモデル」はプレゼンテーションモデルに近いが、より簡易にコー
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く