今年最後の大物著作権裁判

来年からの著作権への認識が大きく変わるかもしれない、そんな裁判が開かれることになっていたようで驚いた。

最高裁、まねきTV訴訟で弁論日指定、テレビ局側敗訴見直しかという記事が公開されている。

以前、TV番組の海外転送は適法判断(知財高裁)という記事を書いた。まねきTVは、ソニー製のロケーションフリーテレビを預かり、海外出張・移住者向けにインターネットを通じてテレビ放送を見ることができるようにするための場所貸し、ハウジングサービスを行っていた。これについて、民放連が違法であると裁判を起こしていた。結果として、ハウジングサービスを運営する会社とかかわりの無い第三者が提供したサーバ(ロケーションフリーテレビ)を預かることは適法である、との判断が知財高裁によってされた。

まねきTVとロケーションフリーテレビは別会社だが、ロクラク事件においては同一の会社によって製品とサービスの提供が行われており、これも適法判断がされた。この事件においての適法判断は、まねきTVの適法判断がよりどころになっているようなものと私は思っている。

今回まねきTVの弁論期日が12月に指定された。重大な証拠の発見、もしくは判定の覆りの可能性がなければ、最高裁まであがらないものとの認識がある。つまり、まねきTVに関して、判定が覆りうる可能性がある。

可能性としてどの部分の判定が怪しいのか、久しぶりに著作権の間接侵害の判例マップの例を見直した。ロケーションフリーTV自体は録画機能は所有していない(どうやらHDDレコーダーと連携して利用するようだ)。複製しなければ問題ない、と判断されるような問題にはしないだろうなので、どうやら送信可能化権の侵害を行っているかどうかを争点にしているような気がする。次点としては複製の主体はサービス運営者である、との主張か。

今までの判断としては、複製権「複製しているか=YES」「複製の主体は=ユーザ=私的複製」、公衆送信権「自動公衆送信権を侵害しているか=NO、不特定配信していないし特定多数への配信もしてない、なぜなら、送信の主体=ユーザ」「送信可能化権を侵害しているか=NO、まねきTVはあたらない」というものだった。

この判決が覆るポイントについて法律を知らないなりに考えてみた。可能性は2つ、公衆送信の主体がサービス運営側にあるかどうかがポイント、そして、そもそもロケーションフリーテレビの存在自体が公衆送信権を逸脱しておりサービス運営者は幇助とみなされるかどうかがポイント(主犯はユーザ?)…のような気がしてきている。

で、前者の公衆送信の主体がサービス運営側にある説は、普通の集合住宅の場合と比較してもあんまり筋がよろしくないような。いちゃもんつけるとすれば、”アンテナ線は共有でしょう”と言いたくなるが、共同受信や大家さんが管理しているような状況と一緒のように見える。仮に主体がサービス運営者と認めれれば、ユーザは特定多数とみなされて公衆送信権の侵害。

となれば、有力なのは、そもそもロケーションフリーテレビの存在自体が公衆送信権を侵害しているという論法であるとしか思えない。つまり、ハウジングされようが、一般家庭にあろうが、海外に公衆回線を用いて送信するのは違法である、と。匂いしか感じられないけれども。その手がかりとして、ソニーのロケーションフリーテレビについてのサイトを開いてみたところ

AV伝送機器「ロケーションフリー」関連商品の生産は完了しました。

トンズラされていた。もう逃げの体制入っているじゃないか。一時は革命的製品とされて、賞までもらっていたのに。

送信可能化権は、許諾された人(団体)にしか認められず、例えばオリンピックの放送などは国内のテレビ局に対して国外に放送するべからずとの許諾がされているという話はよく聞く。このままでは許諾に影響が出て、またテレビ局のビジネスを根底からひっくり返ずような業態が出てくるはずなので、テレビ局側は無理矢理にでも送信可能化件についてひっくり返してくるはず。

ということで、送信可能化について著作権法を見直す。

九の五 送信可能化 次のいずれかに掲げる行為により自動公衆送信し得るようにすることをいう。

イ 公衆の用に供されている電気通信回線に接続している自動公衆送信装置(公衆の用に供する電気通信回線に接続することにより、その記録媒体のうち自動公衆送信の用に供する部分(以下この号及び第四十七条の五第一項第一号において「公衆送信用記録媒体」という。)に記録され、又は当該装置に入力される情報自動公衆送信する機能を有する装置をいう。以下同じ。)の公衆送信用記録媒体に情報を記録し、情報が記録された記録媒体を当該自動公衆送信装置の公衆送信用記録媒体として加え、若しくは情報が記録された記録媒体を当該自動公衆送信装置の公衆送信用記録媒体に変換し、又は当該自動公衆送信装置に情報を入力すること。

ロ その公衆送信用記録媒体に情報が記録され、又は当該自動公衆送信装置に情報が入力されている自動公衆送信装置について、公衆の用に供されている電気通信回線への接続(配線、自動公衆送信装置の始動、送受信用プログラムの起動その他の一連の行為により行われる場合には、当該一連の行為のうち最後のものをいう。)を行うこと。

イは自動公衆送信装置についての定義。ロは自動公衆送信装置を公衆の用に供されている電気通信回線への接続を行うことについて。

いやーな予感がしていて、どうもイの部分で、ロケーションフリーテレビは自動公衆送信装置として認められて、かつ公衆の用に供されている電気通信回線への接続=インターネットという認識になっていそうな悪寒。そんな風にひっくり返ったら、自宅のサーバに保存しておいた著作物を外出先からインターネットを通じて見るというサービスそのものが崩壊するんじゃないか?との懸念。

個人的には間違いなく今年最後の大物著作権裁判の大見物となろう。この手のサービスで最近で最高裁まで上がった例は覚えが無いので。

と、ガクブルしつつ、なんでこんな調べごとに時間を使ったのだろうと思いつつ公開した。

カテゴリー: 著作権 | コメントする

リファクタリングの本を買った

色々と本を買っていたら財政が厳しくなってしまった。が、買わずにはいられなかった本。

リファクタリング:Rubyエディション
リファクタリング:Rubyエディション

元々、リファクタリング―プログラムの体質改善テクニックという本を読むと良いということは知っていて、読みたいなと思っていた。本屋を廻っていたところ、Ruby版の本書を見つけ購入に至った。JavaよりもRubyの方を最近はよく使っているため、嬉しい改定だった。

中身については、今は半分くらいまでしか読んでいない。1章はビデオレンタルの貸し出しを例にした1つの長文メソッドを、いかにリファクタリングするかについて。サンプルコードを元にしたリファクタリングが繰り広げられる。サンプルコードはUnixのdiffコマンドのように、改変前と改変後が両方とも掲載されている。分かりやすい。そのかわり空白も多い。

リファクタリングの中では、特にテストケースの作成が重要で、テストが成功するかどうかを確認しながらリファクタリングしなければいけない、ということがとても印象的。

2章から、リファクタリングについての文章的な説明。する理由や、問題点、歴史の勉強。3章もどんなときにリファクタリングをするのかについて臭いから語られている。4章はテストの構築。書き方。

…というところまで読んだ!

テストケースが面倒で必要ないと思っているが良いコードを書きたいと思っている人に、この本はいいかもしれない。良いコードを書くためにはリファクタリングが必要で、リファクタリングのためにはテストが必要だ、ということがよくわかる本だからだ。

ただテストの書き方そのものは詳しくは語られておらず、今はUnitにかかわらず色々とあるので、それについては別途何かしらの良書がないと、腰が上がらない〜と思ったり。そんなところです。

カテゴリー: チラシの裏 | コメントする

自動化と効率化

人は口で経験を伝える。他者の追体験を自分が体験しなくても、どうなるのか分かるようになった。口伝で教える仕事が生まれた。

口で教えていたが、一人ひとりに時間を合わせて場所を合わせて、話すのは難しい。そこで文字を使って伝えることにした。口で伝えたものを複製するには覚える必要があったが、文字はその必要性をなくした。その代わりに文字を知らなければ読めないという制限があった。

はじめは石に彫って伝えていたが、やがて、紙というものが発明され、利用されるようになった。顔を合わせて話をしないと信頼できないという声もあったが、筆跡で信頼するようにした。筆跡を鑑定する仕事が生まれた。

紙を閉じたものを本とした。本は一人ひとりが書き写して複製され、多くの人が読めるようになった。言語の問題はあったが、誰かが訳してくれた。書き写したり、訳したりする仕事が生まれた。

やがて、より多くの本を作成するために、活版印刷という技術が発明された。印刷機の製造やメンテナンスをする技師の仕事が生まれた。本を書き写す人の仕事はどうなったのだろうか。

口で教える仕事はまだ残っていた。電話の発明によって、地理的な要因を飛び越えられるようになった。当初の電話は交換手と呼ばれる、回線と回線をつなぐ作業員が必要であり、交換手という仕事が生まれた。しかし、やがて自動化され、必要としなくなった。しかし、1対1でしか伝えられなかった。有線の工事も必要だった。

毎回、口で教えるのは大変だ、ということで、録音が生まれた。レコードやテープに録音された情報は、口で話す作業から開放した。

やがて無線通信の発達により、ラジオなるものが生まれた。有線で接続する必要がなく、同時に多くの人へ、経験を伝えることができるようになった。

一方、本はコンピュータの発明によって、電子化された。インターネットを通じて経験は瞬く間に共有されるようになった。コンピュータを作る仕事が生まれた。複製のコストは限りなく小さいため、インターネットに接続する全ての人が簡単に経験を発信して、受信できるようになった。

この文章も、そうした歴史を経て、伝えられている。

交換手だった人々はどうなったのだろうか分からないが、口で教える仕事は残っている。写本をしていた人々はどうなったのどうか分からないが、翻訳をする仕事は残っている。そうした、時代ごとの浮き沈みのやるせなさを感じる。

最近、この種の自動化が人の仕事を奪い悲しい、という感覚を感じていて、時代に冷遇された今までの人はどうなったのだろうと思うときがある。自動化は人を仕事から解放したように見えるが、考えてみると自動化を主有した人が人を雇用することから開放されたようにも見える。そうした効率化されたものは多くの人により安価に提供され便利になる。

対して、仕事から開放された人は自動化の恩恵を受けているのだろうか。自動化による人が働かなくてもよい世界は、まだやってきていない。

それでも絶えず自動化していかなければならない。自動化され、効率化されれば、経験は瞬く間に広がっていく。その経験を種に、さらに自動化していかなければならない。自動化を持たなければ、束縛している何かから開放されないのだから。

でも、その自動化の先に、何があるのだろうなぁ、とふと思った。

カテゴリー: 謎理論 | コメントする

Webといくつかの遅延読み込みと読み込み速度

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を契約

海外から国内までの鉄板格安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         : 2666.362
cache size      : 2048 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu tsc msr pae cx8 cmov pat pse36 clflush dts mmx fxsr sse sse2 ss ht pbe syscall nx lm constant_tsc up arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm tpr_shadow vnmi flexpriority
bogomips        : 5332.72
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

df

$ df
ファイルシステム           1K-ブロック    使用   使用可 使用% マウント位置
/dev/xvda3           111463456   1034396 104772576   1% /
none                    504404       128    504276   1% /dev
none                    509792         0    509792   0% /dev/shm
none                    509792        32    509760   1% /var/run
none                    509792         0    509792   0% /var/lock
none                    509792         0    509792   0% /lib/init/rw
none                 111463456   1034396 104772576   1% /var/lib/ureadahead/debugfs
/dev/xvda1              103380     86460     13788  87% /boot

結構なHDD容量。これで困ることなんて、Wikipediaのデータを展開するときくらいだろう。

ということで使ってみよう。

カテゴリー: VPS, チラシの裏 | コメントする

MVCについて (3)

厳密な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さんが開けることもある。

Proxyさん、Serviceさん、Delegateさん

この3つの呼ばれ方をするModelが多い。

Proxyさんは代理人さん。Mediatorさんも代理人さんっぽいけれど、Proxyさんの名前がつくと主にModelの仕事に就くことが多い。この3つの呼び名は、外部のサービスを呼ぶModelの名前。例えばFlickrService.getFlickr(keyword)とかメソッドが存在すると、ちょっとFlickrまで行ってくる…という作業を行う。Flickrからブツを持って帰ってくると、イベント投げてCommandを発令して、仕事は終わる。

失敗すると、Mediatorに「失敗したよ!てへ☆」といって死ぬ。市

外部にクエリを投げないModelさんは、素直にModelさんと呼ぶことが多い。そういうModelさんはVOをたくさん持っている。

Event箱

箱にしたくない箱。夢と希望と絶望が詰まってる。MVCのそれぞれをつなぐ線。

MediatorやModelの中にはEventDispatcherさん(イヴェントディスパッチャ・タイ人か?)という人がいる。この人がEvent箱を川にぶん投げる。

Facadeさん

ModelとControllerとViewの管理者。

EventDispatcherさんがぶん投げたEvent箱を、郵便局勤務10年の手さばきのごとく、パスする。Serviceの例だと、Flickrから取得が成功するとFlickrEvent.成功したよ、が帰ってくるが、それをShowPicturesCommandに投げる。ここで、投げるリストに登録しなくて、動かなくて涙目になることがある。

概観

順番的には、以下の感じ。

ユーザ操作で外部APIを叩く

Mediatorさん→EventDispatcherさん→Facadeさん→Commandさん→Modelさん(ユーザ操作)

(1)ユーザ操作がUIからMediatorに伝わり、MediatorはFacadeに投げる
(2)FacadeはEvent内容を見てCommandに投げる
(3)CommandはModel[Service]を操作する(外部サービスからのデータ取得を依頼する)

外部APIの結果を格納する

Modelさん→EventDispatcherさん→Facadeさん→Commandさん→Modelさん(外部からデータ取得)

(1)Model[Service]が取得した結果をFacadeへ
(2)FacadeはEvent内容に応じて指定のCommandに渡す
(3)CommandはModelを変化させる(取得した結果の格納を依頼)

外部APIの結果を表示する

Modelさん→Mediatorさん(値変更によるView変化)

(1)(結果の格納によって)ModelがMediatorに値が変わったことを教えて
(2)MediatorがModelに値をとりにいく

ちなみにユーザ操作で直接Modelの書き換えもあり。単純なので今回は略。

Mediatorのお仕事

ということで、UIとその他Controller, Modelとの橋渡しを行うのがMediatorなのだが、この仕事はM=C=V形式のCの仕事に該当するような気がしてならない。

今回のフレームワークではCommandは一連の作業を行うデザインパターンであるが、この作業は実はModel内のビジネスロジックに含まれるべきもので、実質はModel間のデータ受け渡しくらいしかControllerはすることがない(ような気がする)。このデータの受け渡しは、Model間の依存関係を気にしなければ、Model組み込みで行ってもかまわない。そうなると、ほとんどContollerはする仕事がない。

ということで、Controllerには他の仕事をさせないで、Controller≒Mediatorという扱いにしたのがMCVなのだろうかなぁという印象がある。

というところまでが、今回のMVCについての話。余力があったら、CoCとMVCの関係について書くかも。

カテゴリー: チラシの裏 | コメントする

MVCについて (2)

前回の話で、本来のMVCは、ViewからModelの依存がある、というところで終わった。

この依存がある、というのは、簡単には、ViewのソースコードでModelのメソッドを叩いたりするかどうか、のことだ。Viewから直接Modelに参照するかどうかの話なのだ。他のViewに差し替えても、Modelを叩く作法をViewに教えなければならないのは変わらない。

この依存が気に入らない、という分野があって、それはWebプログラムだったりする。

Webの世界にありがちなMVC

Webプログラムの場合、コントローラー的な要素はHTTP通信によって指定されるURLとMethod(いわゆるGETとPOST)である。そしてGUIアプリケーションとは違い、1度のアクセスで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もあるよ。

カテゴリー: チラシの裏 | コメントする