tonextone.com/note/

web2.0

最近流行の web2.0 とは何だろうか?

この問いに対する、2005/11/11現在の俺の回答としては、
「

1. XML-syndicated なコンポーネントの組み合わせで、別のサービスを組み立てておいて、
2. 各コンポーネントの組み合わせを、ユーザが自由に変えられるようにしたり、
3. なんだったら、ユーザ自身がコンポーネントの開発に参加できるようにしたり、
4. その勢いで「ソーシャル」展開したり、

みたいなもの
」
としておく(間違ってたら教えてください)。

早い話が、
「最近アツいウェブアプリってこんな感じ」を、なんとなく総称するための、
「そうそう。あなたが今まさに思い描いているアレですよ、アレ」的な、便利な代名詞。

なるほど。

Ajax

そこに登場したのが、
web2.0 を印象付けている仕掛け "Ajax" だ。

この Ajax の登場によって、
ウェブアプリケーション開発手法の見直しを迫られている開発者も少なくないはずだ
(かく言う俺もその一人)。

MVC2.0

これまでのウェブアプリケーションの MVC フレームワークは、
ほとんど全てサーバサイドで完結していた。

【サーバサイド MVC】
M(モデル)　　　 = RDB
V(ヴュー)　　　 = XHTML + CSS
C(コントローラ) = PHP,Perl,Ruby,...

ところが、Ajax では、
クライアントサイドにも MVC フレームワークが必要だ。

【クライアントサイド MVC】
M(モデル)　　　 = XML,JSON
V(ヴュー)　　　 = XHTML + CSS
C(コントローラ) = JavaScript

この文脈でのサーバサイドの役割は「M(モデル)に徹する事」になる。
(XML より JSON のほうが断然良いと俺は思う)

OK。ここで、話をまとめる。

問題

「Ajax なウェブアプリケーション」を MVC で設計するには、
「サーバサイドMVC」と「クライアントサイドMVC」とを、
局面毎に使い分ける必要がある。

これだけでも充分メンドウだが、

• single-page で展開するか?
• multi-page で展開するか?

で、MVC の設計が全く違ってくる気がする。 参考

更に、web2.0 というからには、
REST または SOAP な API も提供しておきたくなる。
(XML で提供するのが一般的だけど、XML メンドいし、JSON で良いかなぁ?)

対策

とりあえず、実際にいろいろなフレームワークを試してみて、
感じをつかもうと思う。

ということで、今回オチなかったので、続きます。

このエントリの続き。
どうも、文字コード周りが怪しい。
Sunbird で更新してリモートカレンダーファイルと同期するとデータが部分的に欠ける。
日本語が1文字ずつ欠けていく感じ。欠ける箇所はマチマチ。

とりあえず、「自動的に WEB で公開」するのを止めて、
手動で FTP するように変更して監視中。
これで workaround できれば、自動同期処理に難ありと判断する。
PHP iCalendar によるデータの記録(publish.mozilla.php)か?
それとも、Sunbird 自体の文字コード処理の問題か?

つーか、 Sunbird が吐いたカレンダーファイル(.ics)自体が文字化けてる気がするんだけど、
UTF-8 にも種類があるらしい( BOMってなぁに? )から、
その辺に詳しくない俺は、勉強しながらボチボチやります。

考えてみると、これといったスケジュール管理ツールを使っていない。
細かいスケジュールはメールで確認していたし、
それなりのプロジェクトのスケジュールは、都度エクセルで管理していた。

…これじゃイカン。
ということで、ここ2,3日、ツールを漁ってみた。
とりあえずこれで始めようと思う。

• Mozilla Sunbird
• PHP iCalendar

》公開

選んだ理由:

ポイントは、「共有」「UI重視」の 2 つ。
kiko が良さそうなんだけど、
kiko だと、データが「あちら側」にあるので、却下。
一瞬、自分で kiko を作ろうかとも思ったけど賢明にも日和る。
はてなグループも試したけど、元々はてな国民ではない私には良く分からない部分が多く、却下。
Mozilla Sunbird なら、それなりに使いやすいし、
PHP iCalendar と連携すれば、 自動的に WEB で公開できる。
iCalendar 経由で連携というのも、Web2.0 的で良い。

PHP - PostgreSQL の文字コード設定は、通常

PostgreSQL:

initdb --encoding=EUC_JP;
createdb hoge;

PHP:

output_buffering = On
output_handler = mb_output_handler
mbstring.encoding_translation = On
mbstring.language = Japanese
mbstring.internal_encoding = 'EUC-JP'
mbstring.script_encoding = 'ASCII,SJIS,EUC-JP,JIS,UTF-8'
mbstring.http_input = 'ASCII,SJIS,EUC-JP,JIS,UTF-8'
mbstring.http_output = 'SJIS'
mbstring.detect_order = 'ASCII,SJIS,EUC-JP,JIS,UTF-8'
mbstring.substitute_character = none

な感じにしている。

でも、Ajax するからには、UNICODE で統一したい。
ちょっと試した結果、

PostgreSQL:

initdb --encoding=EUC_JP;
createdb hoge;
psql> SET client_encoding TO 'UNICODE';

PHP:

output_buffering = Off
output_handler = none
mbstring.encoding_translation = Off
mbstring.language = neutral
mbstring.internal_encoding = 'UTF-8'
mbstring.script_encoding = auto
mbstring.http_input = auto
mbstring.http_output = 'UTF-8'
mbstring.detect_order = auto
mbstring.substitute_character = none

で、問題なく動作する。

[ 続きがあります ]

このエントリに関連して。
Ruby の Rails を真似た PHP 版フレームワークとして、 Cake に続き、 Biscuit を触ってみた。
Tutorial にしたがって、これを作ってみた。

特徴:

1. PEAR(DBその他)を使う。
2. テンプレートエンジンを使わなくて良い。
3. グローバルな、変数、関数を上手く使う。
4. 4つ(だけ!)のファイルで構成される。
5. そもそも構成ファイルが少ないので、どうにでもできる。

ファイル構成:

biscuit_forum/
|-- index.php (本体)
|
|-- biscuit/ (ライブラリ)
|   |-- activerecord.inc (モデル: クラス定義)
|   |-- activecontroller.inc (コントローラ: クラス定義)
|   `-- actionpack.inc (ビュー: 関数定義)
|
|   # 上記が構成ファイル。(参考)
|   # 下記のファイルでアプリを実装する。
|
|-- models/ (モデル: インスタンス作成)
|   `-- post.php (ファイル名 = モデル名)
|
|-- controllers/ (コントローラ: インスタンス作成)
|   `-- forum_controller.php (ファイル名 = コントローラ名_controller)
|
`-- views/ (ビュー: テンプレート)
    `-- forum/ (ディレクトリ名 = コントローラ名)
        |-- create.html (ファイル名 = アクション名)
        |-- index.html
        |-- login.html
        `-- show.html

所感

かなり好感触。
/index.php(100行) が本体で、これを読めばフレームワークの概要は理解できる。
グローバルな変数、関数を積極的に使う事により、
コアクラスのメンバが必要最小限に抑えられているので、
覚えなければならない事や、親子関係を意識しなければならない状況が少ない。
[一式]