Legacy 2.1.3 RC リスケ

１２月２３日に Legacy 2.1.3 RC を出そうというリスケ案です。

話としては、

バグ取りと軽量級のフィーチャーリクエストの実装をお願いします。コミット権がある人は直にやっちゃってください。ない人はパッチ送付をお願いします。あと、パッチ送ったことがある人はコミット権を申請できますよ。やり方は Wiki の Get_Involved を参照してください。

……という話です。

Next XOOPS Cube 邦訳

プロジェクトのフォーラムに投稿した内容の邦訳です:

---- ここから ----

XOOPS Cube はまだバージョン 0.9 に留まっているため、私たちはフルバージョンを作るべきです。長い間、私は Legacy にかかりきりだったので、 XOOPS Cube の本質を見失ってしまいました。しかし今、私が自分の仕事に集中できたので、私は XOOPS Cube 設計の短所に気づきました。私たちは理想の XOOPS Cube のために未完成パートだけでなく既存設計の一部を変更するべきです。

私は休憩時間にこれらのポイントを整理しました。

1. XOOPS Cube controller は、 XOOPS の冠を自らに与えんがために X2 のシークエンスを見すぎました。Cube は OGRE にインスパイアされたのですから、私たちはコアをもっと OGRE に近づけるべきでした。
2. Cube はオブジェクト指向設計の表面に囚われています。原因のひとつは、私がウェブ技術のトレンドを反映させようと試みたことです。しかし、本来、コアシステムはトレンドに密接である必要はありません。私たちはもっと伝統的な技術を使うべきでした。たとえば、現在、デリゲートは万能と解され State、Strategy そして Listener の役割（存在）を曖昧にしてしまっています。
3. 私たちは PHP の性質について考慮する必要があります: ランタイム-コンパイル、ダックタイピング等
4. 最新の Web 開発のトレンドは「迅速な開発」ですが、私たちのトレンドは知識をオープンワールドで共有するための「モジューラブル設計」「換装可設計」であるべきです。
5. そのために、ウェブアプリケーションはシーケンシャルな処理ですが、私たちはいかにそのシーケンシャル処理を構築するかについて考慮するべきです: ジョブコントローラ、ソフトウェア（仮想）スレッディング。他方、 XCube_Service は並列処理に近いです。
6. XOOPS Cube における開発はいつでもどこでも優れたツールとともにあるべきです。

たとえば、 cubson によって生成される ActionFrame はウェブアプリケーションプロセスをすばやく扱うことが可能ですが、それは有限状態機械(FSM)としてみると奇妙な実装です。というより、ウェブアプリケーションのトレンドが現在厳密な FSM の実装を必要としていないといえます。しかしながら、もし私たちが伝統的なプログラミングパターンを使用すれば、ソフトウェア設計をめぐるファイトは起こらないでしょう。

言い換えれば、私たちはプログラムを作りましたが、私たちのプログラムデザインの正当性について考慮してこなかったということです。

現行の XOOPS Cube はライトウェイトとヘビーウェイトの中間地点にいます。私たちは XOOPS Cube が何で、 Base が何であるかを定義すべきです。私が思うに、 XOOPS Cube は Web のトレンドに囚われないヨソの＆伝統的なテクノロジーに基づいているべきです。そして、 Base モジュールは最新の Web アプリケーション設計のひとつであればよいでしょう。

熟練プログラマが地味にコツコツと作り上げたソフトウェアを想像してください。おそらくそれは特別なサプライズを備えてはいません。私たちにできるかどうかともかく、 XOOPS Cube はそのようなソフトウェアを目指すべきでしょう。

PHP プログラマは外来技術を避ける傾向があると聞きます。しかし、プログラマは未知に挑戦することが好きです。その外来技術が独自技術ではなく正当性のある技術に基づいてさえすれば、 Cube の設計に興味を持つでしょう。

私は Web 技術の詳細を知りませんが、そのような方法で XOOPS Cube をより良くする手伝いができると思います。

私が XOOPS Cube に必要だと思う何かは以下のとおりです。

• X2 シーケンシャルプロセスとの決別: executeCommon(), executeHeader() 等等
• MVC2 との決別（それは BASE に任せられればいい）
• 遷移制御責任からの決別: つまり、executeForward() や executeRedirect() を Cube のコントローラから取り除く
• マルチプラットフォームであれクロスプラットフォームではない（環境の実行時推測は行わない）
• そのために、 site_config.ini.php を使用した「ビルドオプション」の指定方法の体系化
• コード経路の体系化。おそらく、私たちはアクションフィルターのインスタンスに似た「ジョブ」を管理するジョブコントローラ（タスクコントローラ）を必要とします。
• コールバック手続きの体系化。おそらく、私たちは Delegate 以外に厳密な State と厳密な Listener を必要とします。リスナーは排他的 Delegate として使用されるでしょう。
• 個別のプログラム単位; ジョブとジョブの間のコネクタビリティを提供します。他方、開発者には独自の方法でジョブ間の通信を行うことを禁じます。
• 個別のプログラムのチェインの下では、 XOOPS Cube は「インオーダー実行」を保障する必要がありません。
• サービスはほかのプロセッサのジョブ、程度に位置づけ（並列処理扱い）ておきます。

さらなるリサーチのために二ヶ月ほど時間をください。

---- ここまで ----

ものすごく要約すると、XOOPS Cube 0.9 + Legacy は、さして PHP をリサーチしていない分際で「どうしたら PHP プログラマに違和感がないものに仕上がるか？」ということと「柔軟なライトウェイト言語を使いこなせない自分」の間の中途半端なものに仕上がってしまったと。次版は「どうしたら PHP の〜」の部分は各 BASE の実装に任せて、 XCube は外来技術概念といわれようがそれはそれでよそできちんとした考えなのだから、その経験を使ってなるたけ実直に組んでみたいということです。
たとえば、「配列のキーは ID で考える。 ID で考えると言うことは廃止番号があったら永久欠番になるということ」とか、「各グループ毎にアクセス可能なモジュールの ID をランタイム計算ではなく、変更時にあらかじめ抽出して保存しておく」とかです。こういう場合に、後者を「キャッシュ」と呼ぶと「うーん、なんか納得のいかない仕組みだなぁ」と言われそうですが、「ルックアップテーブル」と言い換えるだけで「ウン、ＯＫ！」ってなりそうな気がします。つまり、 PHP や Web というニューテクノロジに捕らわれず、先人が確立した技術とコトバの定義を共通認識としてうまく使っていこうということです。

そういう意味での（可及的）「実直」です。その中に PHP や Web やライトウェイト的に「ナシ」な要素があるかもしれませんが、変に妥協（恐れ）しないようにと考えています。よっぽど変であればフォーラムで指摘があると思いますし。

一方で、負荷を下げるという意味合いで、むやみにクラスばかり使うのではなくインナーでは配列を使ったり、PHPのダッチタイピング的な要素は容認していく（インターフェイスにこだわらない。C++だってハードの関係でパフォーマンスのボトルネックになる部分では純粋仮想関数をきっちり避けていく場合があるので）ようにしようかと思います。

XOOPS Cube Developers Meeting #1

sf.net のほうでも告知しましたが、コントリビュータの皆さんに集まっていただいて今後の開発に関するミーティングを行います。
sf.net のプロジェクトフォーラムから転送をかけていますが、 XUGJ で告知と募集をさせていただいていますので、詳しくはこちらをご覧ください。

「今後の開発をクローズドでミーティングするんですか」と突っ込まれるかもしれませんが、今回は、

• もはや元コアチームメンバーではオープンスペースにきっちりドキュメントが作れない
• 一人二人では空気を作り出せない

というところに端を発しています。つまり、オープンなところでやるには、一人二人がモチベーションが薄い状態で数カ月チクチクとドキュメントを書くしかありません。

それなら、初めにもっとも確実で最速のコミュニケーション手段 Face to Face で、

• 文書化の甘い & 未文書化状態の情報の共有
• この文書化のコントリビュート依頼（その場でガントチャート使う）
• 有名どころの開発者に現在の体制を理解してもらい空気醸成にご協力いただく

という３点を果たし、その戦力でオープンスペースを整備してしまおうというものです。
したがって、ミーティングで話し合われたことと同様のものが成果物として、あるいは空気として、近日中にオープンスペースにフィードバックされることになります。

一度これらのものが文書としてあがれば、

1. コントリビュータの参加基準が明確化する
2. 人手不足に陥ることはなくなる
3. →クローズドミーティングは不要になる……

という展開になるだろうと期待しています。現在のドキュメント "Get Involved" では力不足ということですね。 (^^;

うまくいけば、第一回でオープン要素をオープンリソースのためにクローズドでやらざるをえない部分は完了すると思いますので、第二回からは普通のカンファレンスになると思います。

また開発者として走り出せるようなら、自分としては、今後はツールに注力したいと思っています。
スパンが短い Web 開発ではツールはあまり重視されないようですが、ゲームなどでは「ゲーム開発とはツール開発である」という主張をする企業があるなど、非常に重視されます。
ツールが充実すれば利用感や開発感がずっと楽になり、結果としてコミュニティに大きく貢献できると思うんです。また、海外からも「コード面が気になって参加しにくいのでツールやスニペットを整備してほしい」というリクエストをもらってます。
海外には MOD がそれを示すように、「少々困難でもツールとドキュメントがあればあとは情熱で乗り切ってしまう」というアマチュアハッスル文化があるので、期待しています。

気軽にボランティアな文化のある海外の方に気軽に扱ってもらえるツールが充実すれば、コミュニティはさらに活発になるのではないでしょうか。

他のＣＭＳと比較した時に「ツールの質と量が違う」と言われるようになれば、それが XOOPS Cube ワールドの特徴になると思います。

ともかく、管理業務以外のタスク、報告、修正・実装パッチなどが現在はコントリビュータ（およびそこからのコミッター）で進める体制に変わってることをご理解いただきたいなと思っています。

（それを広くこのプロジェクトの常識とするための下準備がミーティングということですね）

今回は旧コアチームを振り返らずして、話を先へは進められないと思っています。旧コアメンバーも何人か来ますし。大反省会でもあります……我々は最後まで立っていられるのでしょうか……

XOOPS Cube プロジェクトがウェブスペースのトップページを公募

XOOPS Cube プロジェクトがプロジェクトのウェブスペースのトップページを公募しています。ウェブページを作ることができる人は、そのスキルを使ってコントリビュートしてみてはいかがでしょう？

XOOPS Cube コアは抽象的なクラス群にすぎませんので、プロジェクトは、 XOOPS Cube の特定のベースモジュールを使いません。あと、別の理由として、 sourceforge.net が安全に共有されたウェブスペースを供給しないから……という理由があります。
（sourceforge.net は共有資産への支援者であって、ウェブスペースサービスプロバイダではありませんから、当然といったところ）

従って、静的なウェブページがベストチョイスです。

プロジェクトウェブページにはコミュニティへのリンクだけがあればよいという判断です。ほかプロジェクトの出している希望は、下記のとおり;

• 容易な保守。プロジェクトが新しいコミュニティリンクをページに加えなければならないとき、容易にそれが可能であること。
• 静的な HTML
• 我らが惑星・地球を感じるように……XOOPS Cube は、特定の国家、民族、言語のためのものではありません

実は、これらのイメージは、ソ○ー、任天堂などのゲームコンソールメーカーの国際トップページから来ています。プロジェクトは、トップページ例の準備をしましたが、なんでか、水色です。どうしてかというと、このページは、 Wii の国際トップページのパロディだからです。

参加もしくは何か一言あれば、こちらからどうぞ。

我、我のアイテムを閉じ得ず

XOOPS Cube 開発は、トラッカーにおいて「らしい」開発規則を試みています。それは、「バグアイテムを Fix したコミッターは、アイテムを Close することなかれ」というもの。例えば、ボブによって提出されるバグアイテムがあるとします。私、 minahito は、それを修正したとしましょう。そのとき、私は、その Resolution 状態を「Fixed」に変更することはできても、それを Close することはできません。別の人（第三者）がテストによってその Fix を確認したとき、そのアイテムは、閉じられることができます。

この規則は、開発の鉄則に準拠してます。えてしてプログラマは、自分を信じ、そして、自分の仕事はすべて成功すると思い込んでいますから、なかなか十分に Fix をチェックできません。従って、第三者がその働きをチェックすることがベストなのです。似たような規則が、私の会社でも使われています。それは、多くの開発チームで使われている良い規則です。

しかしながら、この規則は、全ての開発にとって有効であるとは限りません。一部の OSS プロジェクトは、この規則を導入できないでしょう。この規則を使うためには、開発は２～３人の行動可能状態の開発者（技術的コントリビュータ）を必要とします。XOOPS Cube で、私は、他のコミッターが担当したアイテムをテストするために、貢献することができました。これによって、これらのアイテムは、閉じられました。しかし、私は、私自身の担当アイテムにはタッチできません。

2.1.1 における私の 修正済み かつ Open のアイテムは１５個あります。XOOPS Cube は、コミュニティ (コミッターを含む ) がこのルールの下でこれらのアイテムの全てを閉じきれるのかどうかを試しています。私達がそれを完遂し得ないならば、我々は、この規則を使うのを止めるべきです。

それでですね...テストをコントリビュートするには、 2.11 (2.1.1) RC をダウンロードして、修正済みアイテムをチェックし、それをそのアイテムのコメントフォームにレポートすればＯＫです。

次バージョンは 2.11 それとも 2.1.1？

私は、５月２２日に sf.net のフォーラムで、次のバージョンが 2.11 であるという話をしましたが、日本人が読んでなかったため、３週間後の６月１２日に日本限定でちょっとした問題になりました。バージョンナンバリング規則が重要な話題であるので、我々は、再びそれについて論じるべきです。そのトピックはここにあります。

しかし、今回、 sf.net フォーラムがその役割を果たさなかったことは、問題です。現在、開発者用 ML は使用されておらず、すべてのトピックはフォーラムにあります。

今回、私は、このトピックがレスポンスを全く得なかったので、 2.11 に関する合意を得たものだと考えていました。議論が遅れてやって来たということに強くショックを受けます。そのような状況が、逐一、かつ、各国毎に容認されるなら、 OSS プロジェクトは、前に進むことはできません。しかし、今回、 sf.net フォーラムは、よく知られていませんでした。そして、そのトピックは、非常に重要で、ナンバリング規則についての意見を全く得ておらず、なによりリリースはまだ RC です。従って、我々が再び討論を始めることに何の異論もありません。

ただ、日本人が特別扱いされているように見なされるかもしれないことが気になります。二度同じことをすべきではありません。 sf.net フォーラムは十分に機能していなかったので、今回は特別＆最後です。

どこで、 XOOPS Cube Legacy についてチェックするのがよいでしょうか？

少なくとも、あなたは、 sf.net のモニター機能を使って、２つのフォーラム --- Developers - Legacy と Open Discussion を監視するべきです。

どうやって各コミュニティは、ファイルリリースを知るのがいいか ?

ファイルリリースもモニターできます。モニターをセットすると、ファイルリリースの担当者が通知ボタンをクリックすると、通知メールを受け取ることができます。このフィーチャーは、最新のリリースを知りたいユーザー全てに通知することができますから、私はそのモニタが各コミュニティマネージャに良いと思います。 あと RSS フィードも便利です。

一人のコミッターが一人で各国の各コミュニティにニュースを投稿してまわることはできません。今回は xoopscube.org がヘンテコ英語ＯＫという空気をまだ持っているので、私がリリースニュースを投稿しました。しかし、 xoopscube.org だって強化されていくでしょうから、これが永遠に続いていくわけではアリマセン。ですから、 sf.net をモニターすることが一番いい方法です。

あと、プロジェクトはモニターの使い方もアドバイスを出しているので、一度読んでおくとよいでしょう。（ついでにいうと、sourceforge.net はプロジェクトのモニタ方法を「マイページ」で丁寧に説明しています。これも一度読んでおくといいと思います）

言語ファイルのための命名規則に関するヒアリング

Legacy の次のマイナーチェンジバージョンは、'extras' ディレクトリ以下にふたつの UTF-8 言語ファイルを含むでしょう。現在、私達はこのトピックで '追加の言語' の命名規則を決定するために話し合っています。sourceforge.net アカウントを得て、フォーラムに参加してください。

韓国言語ファイルのふたつのエンコードタイプは wanikoo さんより提供されました。また、日本語 UTF-8 言語ファイルは GIJOE さんより提供されました。ありがとうございます！

XOOPS Cube プロジェクトはあなたのコントリビューション…とりわけ言語ファイルを歓迎します。詳細はこのトピックをご覧ください。