tonextone.com/note/

PEAR との付き合い方を探っている。
これまで使った事があるもの:

1. 誰が作っても同じ API になりそうな比較的堅いもの。
   ( HTTP_Request など)
2. 自作するには労力がかかりすぎるもの。
   ( XML_Serializer など)

つまり、いろんな意味でブラックボックスとして扱いたい単機能は PEAR で充分。
逆に、開発のモチベーションに直結する機能、ブラックボックスでは困る機能に関しては、
自作ライブラリを使って来た…と言える。今にして思えば。

大きめの開発の立ち上がりは、いつもライブラリ/フレームワークの設計から始めていた。
フレームワークの開発自体に面白味を感じていたからこそ、そういうスタイルでやって来たわけで、
それが今では自分の力になっている。
一人で開発・メンテナンスするなら、それで良いと思う。

ただ、これからは、いろいろとオープンにしたいので、
まぁ共通語としての PEAR を読み書きくらいは出来るように勉強中。

今日のメモ:

1. PEAR に channel:// という概念が導入され、
   レポジトリを切替えてパッケージ管理できるように?なったらしい。
   

   $ pear config-show;

   してみると、デフォルトの channel なんかが見れる。

   $ pear upgrade 'channel://pear.php.net/XML_Serializer-0.18.0';

   とか使う。
2. DB は抽象化クラス。
   DB_DataObject は O/R マッパークラス。
   基本的な部分しか試してないけど、分かりやすい。
   O/R マッピングってこういうことか…。
   O/R マッパーじゃないけど似たような使い勝手のライブラリ
   (非オブジェクト指向)を自作してあるので早くも興ざめ。
   

次は、Auth, Mail_Mime を。
さらにその後は web2.0 な、 HTTP_Request, XML_Serializer, XML_RPC, HTML_AJAX で遊ぶ予定。

自ドメインのメールアドレスをいくつか使用している。
でも、このサーバには SMTP サーバ( qmail )は立ててるけど、POP サーバは立ててない。
だって面倒。
で、どうしているかというと:

1. Reply-To: <[email protected]> ヘッダをつけて送信する。
2. [email protected] 宛てのメールは dot.qmail-foo で、[email protected] に転送。

基本的にこれだけなんだけど、POP に proxy を 2 段ほど刺している。 Norton AntiVirus と POPFile。

PC 環境を再構築するハメになってみて、この辺の設定がメンドかったのでメモ。
( OutlookExpress の場合です)





百聞は一見に如かず。

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 で良いかなぁ?)

対策

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

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