Life is beautiful: Ajaxの本質、「非同期メッセージ型ウェブ・アプリケーション」のススメ
最近、「これからのウェブ・アプリケーションはAjaxだ」という声を良く聞く。ソフトウェアを生業としているエンジニアとしては、この手の「流行もの（hype）」に触れた時には、表面的なものに踊らされずに、その本質を自分なりにしっかりと捕らえて消化・吸収して自分のものにしなければいけない。今までも、「オブジェクト指向」、「マルチ・ティアー・アーキテクチャー」、などの言葉が一人歩きするたびに、「これからは○○だ」とか「○○の時代は終わった」などと、過激なことを言って読者の目を引こうとだけするマスコミや企業のマーケティング戦略に数多くの人が踊らされてきた。 そんなノイズだらけのメッセージに混乱させられた結果、「Ｃではオブジェクト指向のプログラミングは出来ない」と信じているエンジニアがいまだに沢山いることは全く嘆かわしいことだ。「オブジェクト指向のプログラミング」は、設計姿勢・プログラミングスタイルに
「RESTful MVC」なアーキテクチャの話
最近、増井君と私でアーキテクチャの話をすることが多いのだが、そんなディスカッションの中で気に入っているのは左の図のようなアーキテクチャ。 もちろん、核となるのはビジネスロジックを含んだModelの部分。そこをしっかりと実装し、内部構造を隠す粒度の荒いインターフェイスを定義し、外から何をされてもデータの整合性が壊れない様にすることは何よりも大切。 そして、そのModel層へのインターフェイスを特定の言語に依存したクラスやAPIではなく、HTTP上でJSON（XMLでもかまわない）をやりとりするだけの RESTfulなWeb Serviceにすることがミソ。こうすることによりにより、どんなに締め切りに負われようが、誰がControllerを実装しようが「ずるができない」ように作っておく（ずる＝本来使うべき外部インターフェイスだけでなく、Model内部に直接アクセスして依存関係を作ってしまう事）
Ruby on Railsの「えせMVC」の弊害
先日のエントリーでも少し触れたが、Ruby on Railsの最大の問題点は、それが持つ「一見そのフレームワークがMVCの形をとりながら、MVCの最も大切なところを外している『えせMVC』である」点にある。MVC（Model View Controller）がなぜ必要かを根底の部分でちゃんとと意識せずにRailsアプリケーションを作ると、後々ひどい目に会うので注意が必要である。 その意味では「RailsでMVCを学ぶ」などもっての他だし、「JavaにもRailsと同じようなフレームワークを作って業務用アプリの開発を効率化しよう」などという発想もとても危険である。 ということで、今日はまずはMVCの解説から。 MVCの発想の根底には、「モジュール化と情報の隠蔽により、プログラムがスパゲッティ化するの（コード間の相互依存関係が複雑に入り込んでしまってにっちもさっちも行かない状態になること）を避
Google App Engine入門：フレームワークの選択
Google App Engine向けのアプリを作る際に最初に悩んだのはフレームワークの選択。Google App Engineにはwebappという最低限の機能を持ったフレームワークが付いて来るが、Python使いの人たちの間では、DJangoというフレームワークが広く使われているらしいし。かといって、あまり大きなフレームワークを使うと、パフォーマンスのチューニングとかもしにくくなるし、フレームワークそのもののバグや制限に悩ませられる可能性もある。 そんな中で増井君が見つけてくれてまず試したのが、Junoというフレームワーク。DJangoと比べると遥かに小さく、WebappよりもURLのルーティングのメカニズムとかが充実している。 そこで一旦はアプリをJunoの上で作り始めたのだが、Junoのソースコードを見ているうちにいろいろと気に入らないところが出て来た。不必要にオプションが多いし、
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
