月別アーカイブ: 8月 2010

Webサイトの読み込み時間に関して検索大手のGoogleは敏感になっている。Googleの検索サービスの検索速度は速い。Google Chromeの表示までの速度の追求には恐れ入る。そして今年4月には、site speedを検索順位に反映すると発表している。 これらの事象から推測するに、Webサイトをいかに高速に表示するかは、多くのサイトにとって課題になるだろう。 Webサイトの表示速度を高速にするためには、いくつかの方法があると考えられる。 動的コンテンツではなく静的なコンテンツとして扱う（MovableTypeやWordPressのキャッシュのような） 多くの画像を1つの画像にまとめる（CSS Sprite） 先読みを行う 遅延読み込みを行う 多くのサイトにとって、画像を利用しないという選択肢は存在しない。時にモバイルでサイトを閲覧しようものなら、画像の読み込みに多くの時間を費やすこととなる。 以前にもページ分けについてニュースサイトが記事のページを分ける理由を考えてみたことがある。Googleが100件ではなく10件しか結果を表示しないことについて、 一度に全内容を送ると読めるまでに時間がかかる という意見は、今になって振り返れば、テキスト情報を送信するという意味において、それほど問題のあることだと思えない。これはユーザから何のクエリが来るか分からないため、事前にキャッシュを行うことができず、常に動的生成しなければならないために生じる制限であり、10件を100件にすると単純に10倍の時間がかかるということが関連しているのだろうと思うようになった。 検索試行の8,9割は1〜10件までの検索結果しか見ない。そういった数字がどこかにあるのだろうと仮定する。そうしたときに、残りの90件あまりの計算は無駄になる。そして検索時間が10倍になることによってユーザー離れが起きる。そのことから、10件程度が妥当だ、という考えに至ったのだろうではないか、と推測している。 しかし、このような問題がニュースサイトやショップサイトに当たるのか？、と考えた場合、否である。ニュースサイトやショップサイトは、自身が持つ情報を全て把握しており、動的コンテンツからキャッシュした静的コンテンツで問題ないはずである。そうした方が、常に動的に生成するよりも何倍も高速になる。その方が有利なはずだ。 課題は、その製品の現在の状況（価格や在庫）がどうなっているかなどの情報や、各個人に個別に合わせた商品の見せ方をしたい場合、そして画像が多い場合である。 例えば、在庫の状況などを逐一変更できるシステムを作成した場合、その変更ごとにページのキャッシュの更新が行われることになる。そのときの問題は、”キャッシュを生成してから誰にも閲覧されていないのに再度キャッシュを更新したときにかかる負荷”であると考えられる。これは、閲覧：更新の割合に関連しており、常に閲覧されている状況であればキャッシュ生成は効果的に働くと考えられるが、更新が多いシステムの場合は事前キャッシュ生成に時間がとられてしまい、その間システムの負荷は高くなってしまう。 その真ん中の案しては、”更新が合った場合には関連するキャッシュを削除し、アクセスがあったときにキャッシュを生成する”というものだが、キャッシュが削除されている間にアクセスする人は待ち時間を感じてしまう。更新が多いシステムの場合、常にキャッシュ生成を訪問者が行うことになるので、結局は読み込み時間のかかるサービスに見えてしまう。 この状況を打破するべく、少し前に流行ったものがAjaxである。更新される情報というものは一部であり、他の多くの固定の情報はキャッシュしてしまう。更新される情報は、後から読み込みしよう、というものである。こうすることで、固定の情報にかかる生成時間は削減され、動的な情報のみを引き出すことができる。一例を出せば、RSSやTwitterの更新情報を引き出すブログパーツというものも、ブログシステムに負荷を与えずに表示することができる。この負荷の分散という考え方がマッシュアップ近辺で行ったもので、提供する側も提供される側もお互いに得になるという話だ。 ページ送り、ページ分けの話に戻ると、こうした遅延処理をしっかり行えるのであれば、ページ送りなどというものは必要ないのではないか、という考えがある。しかしながら、遅延処理を行っても、1ページ100件の要求を1ブラウザがサーバに送りつけるのだから、たまったものじゃない。せいぜい1ブラウザが表示できるのは10〜20件程度じゃないか、と。画像についても同様であるが、例えば100件の画像を一気にブラウザが読み込みという状況は望ましくない。 これに対してTwitterでは、ボタンを人の手で押させることで遅延読み込みを実現している。だが、この作業は非常に面倒だ。 昨今では、ブラウザのスクロールにあわせて情報を追加していく、という流れが出てきている。ブラウザの画面に表示されるので、画像を取得する・情報を取得する、ということが必要なのであって、見られないのであれば情報を取得する必要も無い。見られる可能性というものは、ブラウザのスクロール位置に強く関連している。つまり、スクロール位置とコンテンツの位置から、割り出し、表示されそうだということがわかってはじめて遅延読み込みを行う。 この1例が例えばAppleの商品ページに見られる。98件の商品をページ送りすることなく表示している。ページをスクロールしていくと、画像がフェードしながら表示されるが、これは遅延読み込みをうまくごまかしている。 その他の例として、AutoPagerizeというGoogleの検索ページの下に来ると勝手に次の検索結果のページを読み込んでページをつなげてくれるプラグインがあるが、これも遅延読み込みである。 楽天の商品ページを見ていると、売れ筋商品のページは、ものすごく縦に長い。カルチャーショックを受けるが、そこにはページ送りをさせない（というよりできない仕様？）という形が存在している。それでも物が売れるのであれば、ページ送りとは何だったのだろうか、と最近は思うに至る。 # ちなみに先読みに関してはWebStorageが熱いと感じた次第であります

海外から国内までの鉄板格安VPSサービスに個人情報を振りまく趣味をしているが、次の個人情報提供先にSaasesを選択した。512MBで月450円のプランは安い。ところが6ヶ月分の料金を前払いをする必要があるらしく、512MBでもし足りなくなったら泣けるので渋々1024MBの月980円プランを契約。それでも安いのだけれども。 Ubuntu 10.04のインストールをお願いした。入るためのIDパスワードはメール本文ではなく、パスワードつきのZipに入ったPDFであった。パスワードは後のメールで送ります的な。そのPDFの生成アプリケーションはOpenOffice 3.2で、埋め込みフォントはMeiryo。おお、このIDとパスワードは自動生成ではなくて、Windows機でOpenOfficeで作成したものですか？的な感動。Office Wordを使わない点はポイントが高い。 入ってみるとbourne shellのお出迎えだったので面食らった。今のところ、それだけ。 CPUは1つしか見えない。 $ cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 23 model name : Intel(R) Core(TM)2 Quad CPU Q8400 @ 2.66GHz stepping : 10 cpu MHz : … 続きを読む →

厳密なMVCについて書こうかと思ったが、そもそも厳密なMVCはSmallTalkのMVCで自分はそれを知らない、ということに気がついた。つまり、MVCと名前の付く派生としてはrobotlegsとPureMVCくらいしか知らないので、自分の解釈は間違っているのかもしれない、という不安はある。よって、今回の話はそれらの派生MVCの話として、話半分に読んでほしい。 前回はMediatorがMVCとMCVの明暗を分けるとか何とか。Mediatorについては、MVCの細かい機能分けの話が絡むので、今回の話で。 厳密なMVCの機能分け MVCは制約をつけること（例えばpublicやprivate）で、誰もがわかりやすくて保守性の高いプログラムを書きましょう、という認識を持っている。これは、つまり、Model層、Controller層、View層に分けるということだ。 MVCをもっと仕分けすると色々出てくる。2位じゃいけないんですか？ ・Controller 　・Command ・Model 　・Proxy 　・Service 　・Delegate 　・VO ・View 　・Component, UI 　・Mediator このほかに ・Event ・Facade あたりがその辺をうろつく。 これらの機能分けについて説明していく。MCVではなくMVC的な説明になるのでよろしく。 それぞれの役割 Component, UI 最近のIDE（統合開発環境）では、GUIもコピペーで簡単に構成することができる。これぞデザイナー向き機能。コピペーで作られた画面というものは、XML系(MXML,XAML)だったり、バイナリ系だったり。基本的には、プログラムコードは混入しない方がデザイナーに壊されないので都合が良い。 多少複雑な部品だと、それ1つでMVCの系を持っていたりする。自身で完結するMVCを持つなんてComponentくらいのもの。小さな宇宙。一見、FlexやC＃なんぞに触れると一番お世話になる部分だったりする。それがComponent。 Mediatorさん インターフェースをまとめる。 Componentにコード書きたくないので、代わりに必要な人。Viewに関わる色々なことをする。Viewで完結する（ControllerとModelが関係ない）ような動作はMediator内に収めた方がいい（ような気がする）。 あとは、Modelの値が変わった場合に監視する役もMediator。どの値を見に行くの？みたいな。Viewが叩かれてControllerにチクりにいくのもMediator。つまり、UI Componentに直接さわらせないぞ、という役の人がMediatorさん。 Commandさん Controllerさんのお仕事。一連の作業に名前をつけてまとめる。 叩くのは、主にModelさん。Modelさんのインターフェースをどんな風に叩くのか、どんな順番で叩くのかを持つ。 時に大事な仕事は、外部のサービスから取得したデータをModel（メモリ空間、もしくはDB）に格納するとき。Model（Service）でデータを取得したときにイベント箱が届けられるのだが、その箱の中のデータを別のModel（Proxy）に入れたりする簡単なお仕事です。 Modelさんがメタボになると仕事が無くなる。というか、だんだんControllerって自動生成でいいんじゃね？という気分になってくる。でもModelとModelの橋渡しをするときには必要な人。 VOさん ValueObjectの略。なぜか略されることが多い。 構造体のクラスバージョン。入れ物だけ用意。時々仕事するけれど、VOのメソッドで自身が変化するのはNG。変化したい場合は、分身してください。 Modelさんと、Eventさんの持ち物であるが、時にMediatorさんが開けることもある。 … 続きを読む →

前回の話で、本来のMVCは、ViewからModelの依存がある、というところで終わった。 この依存がある、というのは、簡単には、ViewのソースコードでModelのメソッドを叩いたりするかどうか、のことだ。Viewから直接Modelに参照するかどうかの話なのだ。他のViewに差し替えても、Modelを叩く作法をViewに教えなければならないのは変わらない。 この依存が気に入らない、という分野があって、それはWebプログラムだったりする。 Webの世界にありがちなMVC Webプログラムの場合、コントローラー的な要素はHTTP通信によって指定されるURLとMethod（いわゆるGETとPOST）である。そしてGUIアプリケーションとは違い、１度のアクセスで1つの結果を見せるというフロー駆動な性質を持つ。中にはAjaxみたいに刻々と値を変えるものもあるけれど。 こうした性質を踏まえて、RailsやPHPのsmart的な考え方など、Webフレームワークは下図のようになっている。 ViewがModelに依存するのをやめ、ControllerがViewとModelに依存している。つまり、様々なViewの形からControllerが選びとる、という形式になっている。 これはHTTPリクエストが入り口となるControllerを叩き、URLに対応するデータをModelから引き出して持つ。Controllerが持ったデータをViewに差し込む、という手順になる。このような形は、イベント駆動ではなくフロー駆動的であるからこそ、なせるものである。 Webの場合、モデルから引き出した情報をHTMLだけではなく、JSONやXMLに整形したいという要望があったりする。また同じHTMLでも、携帯向けiPhone向けに整形したいということもある。そこで、Controller時点でリクエストされたViewが何であるかを判断（ほとんどの場合は拡張子かユーザーエージェント）し、指定されたView通りの返答を行う。 このときに、Modelがするべき作業をControllerが行ってしまうコードを書きやすい。本当に。そういうコードを書くと、多方面から怒られる。 このとき作られたView、主にHTMLは、モデルとの依存性が低いため、流用が容易である。その代わり、Viewに適したデータ形式に合わせる苦労をControllerが負う。 MCVなアプリケーション ということで、気分的には、M=C=Vな関係のMVCを、MCVと呼びたくなってくる。その気持ちをぐっと抑えてWeb MVCとかいう言葉の方がいいかもしれない。 このMCVな形を見ていると、Web MVCはWebプログラムの特性、すなわちフロー駆動に合わせたもので、イベント駆動では存在するのか？という疑問が出てくる。このMCVスタイルは、ビューからモデルを直接参照せずにControllerを必ず通すという形になるので、Controllerが整形してViewに渡すという苦労を伴う。 それをうまく解決しているのが、cocoaらしい。Cocoaの本質 MVCデザインパターンを見ると、確かにMCVな形をしている。どうやらCocoaバインディングなるものがViewとModelの橋渡しをするようなのだが、なにぶん、Cocoaは触ったことが無いので分からない。 Mediatorはおやつに入りますか？ 実際のところ、MVCがMCVに見えるのは、もともとのMVCのViewが持っていたMediatorという部分が、Controllerに組み入れられたことによるものだ、と感じている。 Mediatorとは何ぞ、というのはPureMVCなどの厳密なMVCの話が関わるので、また次へまわそうと思う。Facadeもあるよ。

自分にはプログラムは書けないと遠い昔に思っていたが、稚拙ながらなんとか書けるようになった。そう思わせてくれたのはJavaだったが、今ではRuby言語やAS3言語たちと遊んだりしている。 MVCとの出会い そうしたアプリケーションの楽な作り方があったら知りたい、という気持ちがあった。基本的に、これらの言語で何を作ろうとしても、作法はあるのではないか。そうして出会ったのはMVCという概念だった。MVCについて学ぶ必然性を与えてくれたのがRuby on Railsで、より積極的に学んだのはPureMVCやrobotlegsというMVCフレームワークだった。 MVCというのは、GUI（グラフィカルアプリケーション）の制作において、有用な形だ。これを使うことで、複雑なアプリケーションのスパゲッティが、少しは食べられるものになる。 だけれども、MVCのことを知らないで、ほかの人が作ったMVCアプリケーションのソースコードを見たときは、スパゲッティ以上に意味の分からない何かに見えた。経験的には、MVC適用を厳格にしなかったプログラムをMVCに書き換えた際には意味が分からなくなった、という意見をもらったことがある（大方、書き方が悪いのだろうけれども）。概念を知っていないとMVCフレームワークの読み込みは非常につらいものになるのかもしれない。 MVCの概念 MVCは、ものすごく単純には、プログラムのソースコードの中のディレクトリを3つに分けましょう、ということだ。その3つとは、View(見えるもの)、Model（データ）、Controller（操作するもの）のこと。WPFで言うところのXAMLやJAVAのswing、FlexのMXMLにあたる部分はViewに入る。それ以外のロジックはそれぞれModel,Controllerに入る、という感じだ。 まず始めにMVC的にプログラムを書くぞー、というときにはこんな風に適当に分けた。こうして分けようとすると、ModelとViewはなんとなく分かるけれどControllerとは何ぞ？ロジック書けばいいの？という気分になっていく。 MとVとCの関係 ユーザの操作の流れからすると、MVC内ではこんな風な流れ作業になる。 ユーザからの操作をControllerが受信する。ControllerはModelを叩いて値を変更する。Modelの値の変化をViewは監視していて、変化したことを察知したのでViewの値を変更する。 この図を見ていると、「ユーザーの操作が直接Controllerに入るのはおかしいじゃないか。だって、ユーザーの操作はビュー上の部品から行われるだろ？」という気分に襲われなかっただろうか。「いや、ジョイパッドのときはビュー関係ないだろ？」という意見もあるかもしれない。 View上の部品に対してユーザーが何かをした場合は、その部品からControllerにこっそりユーザーが何かした、ということを教える。その方がコードが分かりやすい。また、モデルの値が変化したときにも、Viewに対して”変化した”ということを教えなければなるまい。 つまり、このようなこっそり教える関係性がある。実はこれがイベント駆動とかイベントドリブンだとか、GUIアプリケーションの一番初めにぶつかる概念のイベントの伝播だったりする。 Modelの値の変化は必ずしもControllerが始点ではなくてもよくて、例えばTimerだったり、他のサービスへのPollingだったりが、そうしたものだ。そのために、Modelの変更をViewが見守るという関係であったりする。 MとVとCの関係度 で、コードを書くときに気になるのは、コードの使いまわし（GUIをCUIにしろ）だとか、コードの保守性（簡単に見通せて変更ができるか）だったりするのだが、一般にMVCは以下のような依存を持つとされている。 Controllerを変更してもViewとModelは大丈夫。Viewを変更したら、Controllerを変更しなければならないかもしれない。Modelを変更したらControllerとViewの両方を変更しなければならないかもしれない。そんな感じ。 特に大変なのは、Modelを交換したときで、ControllerとViewの2つの面倒を見なければならない。だから、Modelは最初にがっちりさせておく。まさに太らせる。Fat Model。Controllerを太らせてはいけない。Controllerは基本、使い捨てだから。 で、どんなViewを作ろうとしても、Modelの値の引き方というものはModel固有のものになってしまうので、ModelごとにViewを作り込むという結果になってしまう。依存度高し。 このViewのModelへの依存度を減らそうという考え方がある。 いつか書けるといいなリスト ・依存度を減らそうという考え方の話 ・カチコチなMVCって何なのさ的な話 ・規約なMVCってどんな感じな話