tonextone.com/note/

「PEAR その1」の続き。

web1.0 系

1. Auth は「帯に短し」。
2. Mail_Mime は普通に使える。

web2.0 系

1. HTTP_Request は個人プロジェクト(sparQuery)などで使っている。
   HTTP_Client より API の抽象化レベルが低いので、そのぶん強力。
   これからも使うだろう。
   
2. XML_Serializer も上記プロジェクトなどで使っている。
   XML_RSS より API の抽象化レベルが低いので、そのぶん強力。
   これからも使うだろう。
   
3. XML_RPC はこれからも自発的には使わないだろう(SOAP も同様)。
   サーバ間通信は REST でお願いします。
4. HTML_AJAX は思ったより良さそう。
   クライアントサイドから呼び出すクラスを登録(HTML_AJAX::registerClass(new SomeClass());)しておけば、

   <script>HTML_AJAX.call(SomeClass, someMethod, callBackFunc, arg1, arg2, ...);</script>

   とするだけで、サーバサイドの

   <? SomeClass::someMethod($args); ?>

   を呼び出せる。
   こういうのを RPC とか mapped-function とか言うのだと思っている。
   上記プロジェクトでは Sajax を使っているが、基本的に同様のものだ。JPSPAN も同様。
   ただ、Sajax も JPSPAN も、開発が停滞しており、
   HTML_AJAX と XOADとを、後継候補として検討中。

明日は、「MVC2.0 その2」として HTML_AJAX と XOAD との試用レポートを書く予定。

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

対策

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

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

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

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

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