メガネラボ

個人ブログで書いた方法 を，サーバ内 mp3 ファイルの遠隔再生 にも適用してみました．

こんな感じです．

Opera のパネルで音楽再生．

う～ん，この無駄なスペースを見ていると，やっぱりプレイリストとか欲しくなってきます．．．

先日，といっても 1ヵ月ほど前ですが，ファイルサーバにUSB音源をセットアップした，ということを 一行ほど 書きました．それ以来事務所は （安物スピーカのショボい音ながら） 音楽の流れる空間になっています．

音楽の再生には，Linux で定番の mpg123 を使っていますが，毎回コマンドラインでファイルやオプションを指定したりするのはメンドイ，というのが正直なところ．

さて，現在 Ajax についても勉強中でありますが，せっかくなのでこれを使わない手はありません．ということで，ブラウザからサーバの mp3 再生を制御する仕組みなんぞを小一時間考え，テキトーに実装してみました．

(more…)

WordPress で記事を書くときは，こまめに “保存” するよう心がけています．その時点でのプレビューも表示されるので，一石二鳥です（？）．

そんなプレビューが，前回の記事を書いているあたりから “該当する記事はみつかりませんでした．” と，表示されなくなってしまいました．

先日，2.0.4 から 2.0.5 へバージョンアップしたのを知り，早速アップグレードしたのが原因か？と思って WordPress Japan フォーラム を覗いてみたものの，そんな現象の記事は見当たりません．

投稿ページのソースの，プレビューを呼び出すあたりを眺めてみると，

  <iframe src="http://blog.meganelab.net/?p={草稿記事ID}...

となっています．

index.php がおかしいのかな，と，そのソースファイルを開こうと思ったそのとき，ちょっと前に .htaccess をいじっていたのを思い出しました．

現在，当サイトの本コンテンツをまだ制作できていないため，トップページは，metaタグでこのブログへ移動させる記述がなされているだけです．それを，.htaccess 内で Redirect や Rewrite を使って直接リダイレクトさせよう，とか id:sakudo と話してました，そういえば．

さっそく .htaccess の該当部分を元に戻してみました．

プレビューが表示されました．ドキュメントルートのディレクトリと WordPress のインストールディレクトリ，それぞれの .htaccess の記述内容が干渉してしまっていたようです．

なにはともあれ，めでたしめでたし．．．WordPress，試行錯誤してませんね．

本日夕方，進行中の一プロジェクトの準備説明会に出てきました．まぁ “会” といっても，いつものミーティング＋α な人数でしたが．

内容は，プロジェクトの構想に関する話とシステムのデモ．

我々が担当しているのはシステム部分，本日のために数日前からいくらか調整しとりました．その甲斐あってかなくてかはどうでもいいことですが，特にトラブルもなく済んだのでホッとしてます．

デモの様子．やっぱプロジェクタが欲しいところ．

しかし，やるべきこと，要求されていることはまだまだたくさんあります．着実にこなしていかねば．

（本文とあんまり関係ナシ）

StrutsやらRoRやらCatalystなんかはMVCパターン（MVC:Model View Controller) に基づいて作られているらしいんですが、そもそもMVCって何なんだ？ってことで、ちょっと調べてみました。なんで、記憶が新しいうちにメモメモ。

MVCパターンって？

簡単な話、役割分担の１つの方法ってこと。「システムを実装する際、役割M、役割V、役割Cにしっかりと分けて実装しましょう。そうすれば、お互いの依存度が低くなって色々御利益がありますよ」というわけ。

MとVとCって何だ？

M、V、Cはそれぞれ、Model、View、Controllerに当る。まあ、それだけじゃよくワカランので、さらに詳しく書くと、

Model:
情報担当。ひたすら受身。自分からアクションは起こさない内気な性格。
システムの内部状態を保持。また、その内部状態を操作するメソッドを持つ。

View:
見てくれ担当。ユーザのための見てくれをこさえる。

Controller:
事務担当。お客さまの要望に答える
ユーザから情報を受け取り、その情報を適切に処理する。

ってことらしい（僕なりの勝手な解釈）。MVCパターンでは、システムに必要な機能を、これら３つに分類して実装する。次節以降で具体例をば。

MVCパターンの具体例

例として、「名前」と「コメント」を残せる簡単な掲示板システムを、MVCパターンを用いて実装する場合を考えてみる。まず、掲示板の動作は下図みたいなイメージで。

次に、図の(1)～(4)のそれぞれの場合において、M、V、Cがどのような働きをするか考えてみる。

(1)「ユーザが掲示板にアクセス 」

ではまず、ユーザが掲示板のページを開く時の流れを、箇条書きで示してみる。

1. ブラウザ（＝ユーザ）がサーバ上のシステムに「掲示板のHTMLデータをクレクレ！」と言ってくる
2. システムは、これまでの投稿データを、データベースやファイルから取得する
3. 取得したデータをブラウザが解釈できる形（HTML形式）に整形
4. HTMLをブラウザに渡す

この流れをMVCパターンに基づいて役割分担すると、下図のようになると思う。

くどくどと解説すると、a.で「HTMLクレクレ」とブラウザは要求し、それに対してシステム側では「見てくれ担当」のVが動作する。このV自体は情報を持ってないので、Vは「情報担当」のMに問い合わせて、書き込みデータを貰う(b.)。ちなみに、この時M内部ではデータベースなどに問い合わせて、今までの投稿データを得ている。データを貰ったVはそれをブラウザが解釈できる形に整形して(c.)、それをブラウザに渡す(d.)。

MVCパターンを用いると、こんな感じで動作する・・・ハズ

(2)「掲示板に投稿」＆(3)「投稿完了を通知」

(2)と(3)は一連の動作なので、一緒に考えていく。この(2)、(3)での動作の流れを書き出していくと、

1. ユーザが投稿ボタンを押す
2. ブラウザがシステムにデータ（「名前」と「コメント」）を送る
3. システム側は送られてきたデータを保存する
4. 完了を通知するHTMLをこさえる
5. そのHTMLをブラウザに渡す

となる。そして、先程と同様、これをMVCパターンを用いて図示すると、下図のようになる。

ハイ、ここで問題発生。何が問題かって言うと、M、V、C各々が動作するには、自分以外から呼んでもらうことが必要となる。例えば、(1)「ユーザが掲示板にアクセス 」でVが動作するのも、(2)「掲示板に投稿」でCが動作するのも、ブラウザの呼びかけがトリガになっている。だから、上図において、Vは誰が呼ぶんだ？ってことになる。

アイツ呼んだの誰だよ！

前節の続き。Vは誰かが呼ばないといけない。じゃあ誰が呼ぶ？V以外の登場人物を挙げると、M、C、ユーザってことになる。でもユーザは除外。システム上での投稿処理について何も知らないユーザが、自分で「投稿完了♪」ってメッセージを表示するのは明らかにおかしい。となると、MかC。

で、実際の所はMでもCでもいいらしい。そして、MがVを呼ぶパターンをMVC0パターン、CがVを呼ぶパターンをMVC2パターンと呼ぶ、たぶん。Web用のフレームワークではもっぱらMVC2パターンが使われるようなので、今回は右に習えで、MVC2で行く。

MVC2パターンで

MVC2パターン、つまりCがVを呼んだ場合、先の図は以下のようになる。

「C’ 保存終わったから後はヨロシク」という動作が追加されている。つまり、Controllerはc. の動作が終わった後に、Viewを呼ぶ。これでOK。問題解決なり。

えぴろーぐ

掲示板の動作の「(4)再び掲示板にアクセス 」は(1)と同じ動作なので、割愛。

ということで、MVCパターンを用いた掲示板はこんな感じで動作する。 うーん、、なんか、あんまり上手くまとめれなかった感が。にしても、ちょっとし備忘録のつもりが、結構な量になってしまった・・・。あぁ、眠い。