PHP V5 でマルチタスク動作のアプリケーション開発
IBMサイトで面白い記事を発見したので、ここにメモっておきます。
PHP V5 でマルチタスク動作のアプリケーションを開発する
XOOPS Cube のXCube_Service なんかで使えないだろうか??
複数のサイトに検索結果をリクエストした時、並列で処理可能なようなので、高速処理が可能になるのでは無いだろうか?
« 2007年10月 | トップページ | 2008年3月 »
IBMサイトで面白い記事を発見したので、ここにメモっておきます。
PHP V5 でマルチタスク動作のアプリケーションを開発する
XOOPS Cube のXCube_Service なんかで使えないだろうか??
複数のサイトに検索結果をリクエストした時、並列で処理可能なようなので、高速処理が可能になるのでは無いだろうか?
Locale を利用するケースとしては、地域リストなどが考えられる。
locale : JP
-------------------------------
$AreaListArray = array(
0 => "LANG_HOKKAIDO",
1 => "LANG_AOMORI"
)
-------------------------------
language : ja-JP
-------------------------------
define( 'LANG_HOKKAIDO' , "北海道");
define( 'LANG_AOMORI' , "青森");
-------------------------------
language : en-JP
-------------------------------
define( 'LANG_HOKKAIDO' , "Hokkaido");
define( 'LANG_AOMORI' , "Aomori");
-------------------------------
locale : US
-------------------------------
$AreaListArray = array(
0 => "LANG_ALABAMA",
1 => "LANG_ALASKA"
)
-------------------------------
language : en-US
-------------------------------
define( 'LANG_ALABAMA' , "alabama");
define( 'LANG_ALASKA' , "alaska");
-------------------------------
language : ja-US
-------------------------------
define( 'LANG_ALABAMA' , "アラバマ");
define( 'LANG_ALASKA' , "アラスカ");
-------------------------------
つまり、プログラム側では、
JPの地域リストだろうが、USの地域リストだろうが意識せず、
適用されているlocaleの地域リストを呼び出す処理が必要。
コミュニティを維持する為には、基本的には、ある程度の組織構造が必要になると考えます。
ただ集まる事が目的のコミュニティであれば、コミュニティ規模が大きくても、それほど組織構造は必要無いでしょう。
しかし、OSSなどの開発を目的としたコミュニティであれば、その規模に比例した組織構造が必要になるでしょう。
コミュニティ規模が大きくなれば、情報の整理やコミュニティの管理など様々な仕事が増える為に、当然、作業・タスクの分担を行う必要があります。
但し、それは会社などの業務ではありませんので、担当者に対して「義務」としてタスクを与える訳にはいきません。
あくまでも、OSSのプロジェクトの担当としてですので、その当事者の意思にまかせるしかありません。
それは、往々にして、「集団無責任」な状態になってしまいます。
もしくは、特定の個人に全て皺寄せされてしまうケースだってあるでしょう。
いぜれにせよ、それでは、そのOSSプロジェクトが崩壊するのも時間の問題です。
それを回避する為に、「NPO法人」や「財団」という形にするプロジェクトもあります。
「NPO法人」や「財団」を形成する確かな基盤があれば、その選択肢もありだと思います。
もし、その確かな基盤が無いのであれば、当然ですが、「NPO法人」だろうと「財団」だろうと、続きませんし、崩壊するでしょうね。
OSSプロジェクトっていうのは、元々、個人の小さなプロジェクトから始まったモノが多いでしょう。
そして、それが優秀なプログラムや便利なアプリであれば、自然とユーザーが増え、開発協力者も増えてきて、ユーザーも含めた大きなコミュニティが形成されるのかと思います。
たいていは、その時に、どういう組織構造を取るべきか選択を迫られるのかと思います。
そうでなければ、「集団無責任」の道を辿り、コミュニティの崩壊に進むのかと思います。
せっかく育ったコミュニティが崩壊すれば、そのOSSプロジェクトは、また一から始めなければなりません。
業務でも無いプロジェクトに、それだけの魅力が見出せるほどのプログラム(アプリ)であれば、もしかしたら、やり直しは可能かもしれませんが、もしかしたら、また同じ道を辿るかもしれません。もしかしたら、それは大きな博打かもしれません。
「XOOPS Cubeプロジェクト」も、「XOOPSプロジェクト」からフォークした後、その選択をしなければなりませんでした。
そして、「XOOPS Cubeプロジェクト」が取った選択は、『大きなプロジェクトを形成しない』という方向に進む事に決定しました。つまり、「小さな政府」にするという事です。
XOOPS Cube自体を、Webアプリの中核(コア)となるべき部分のプログラムに特化し、可能な限り、縮小化しました。それに伴い、コミュニティも可能な限り、縮小しました。
しかし、Webアプリの中核(コア)だけではWebアプリは成立しません。
そのコアを元に、必要なライブラリ、システム、アプリケーションなどが必要です。
その為に、XOOPS Cube というコアを使った場合には、そのライブラリやシステムなどをモジューラブルに換装可能にして、開発者やエンドユーザーが柔軟にWebアプリを構築できる様な仕組みを目指しています。
OSやミドルウエアー等の他のOSSプロジェクトと比較した場合、Webアプリの場合は、よりエンドユーザーに直結していますので、そのニーズに対する要望は無限にある事になります。
それら全てに答える事、対応する事、取り入れる事は、ハッキリ言って無理です。
それを解決する為には、やはりコアを小さくし、モジューラブルに必要な時に必要なモノを連結出来る仕組みにしなければなりませんでした。
当然、それらのライブラリやシステムにも、個々にプロジェクトが形成されるでしょう。
そこで、XOOPS Cubeを中心とした小さなプロジェクト(コミュニティ)が集まる事で、全体として巨大なプロジェクトが形成可能になる筈です。
それらのプロジェクトは、XOOPS Cube とは独立したプロジェクトであり、基本的に個々に運営してもらいます。
そして、それらの中から必要なプログラムをチョイスして、パッケージングし、ディストリビューションなどへ発展していくと面白いですよね。そのような発展もXOOPS Cube とは全く関係無いところでも自由にやり安くなると思います。
一部の巨大なOSSプロジェクトを除けば、小さなOSSプロジェクトはテールエンドの如く存在する筈です。
これは、その小さなプロジェクトが生き残る為の一つの方向性では無いかとも思っています。
(本末転倒かもしれませんが・・・・、)
そのようなコミュニティ形態を形成する為には、XOOPS Cube 自体にモジュールブルにライブラリやシステムを連結出来るような仕組みを持たせる必要があります。
そのモデルとして、「OGRE 3D」を大いに参考にさせてもらいました。
XOOPS Cube 自体も、まだ理想とする完全なモジューラブルな世界には到達していません。
某氏の発言を引用するならば、その世界とは、
(*)ガンダーラ...どこかにあると言われているが行き方が不明のユートピア
なのです。
現在、ガンダーラを目指し(笑)、XOOPS Cube の更なる発展の為に開発がすすめられています。
♪どうしたら行けるのだろうか・・・、教えて欲しい・・・・。 (爆)
Language と Locale について( ..)φメモメモです。
language
locale
あとで、追記するかもしれない・・・・・^^;;;
日 | 月 | 火 | 水 | 木 | 金 | 土 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 |
最近のコメント