lablab.jp （日本語版）

私は、今まさに英語で使用可能な cubson を作り終えました。私は、いくらかの特徴をチェックし、それをダウンロードページに置き、そして、ドキュメントを書き始めるでしょう。cubson は、モジュール開発者を支える良いツールのうちの 1 つになると思います。cubson は、 XC 2.1 の Legacy モジュールグループを開発するために使われました。あなたが XC 2.1 で見ることができるフレームワーク・プログラング・ライクなコードは cubson によって生成されたものです。

cubson は、 exFrame & extools と呼ばれる尊い犠牲の上に築かれています。exFrame は、 XOOPS2 のための mojavi2 ライクなシンプルなフレームワークと、易しいコンポーネントを持っていました。さらに、Ryujiさん意外は誰も exFrame に興味を抱かなかったので、コード・ジェネレーター extools を開発しました。それは、いくらかの開発物にとって有益でした。
しかし、それは、ベストではありません。

私は、 exFrame および extools に関する反省と共に cubson を開発しました。まず初めに、cubson は、昨日説明された ActionFrame のサブクラスであるシンプルなフレームワークを作ります。そして、データベースから、シンプル・フレームワークが受け入れ得る様々なクラスを作ります。

差異を見てください:

コンセプト

* cubson はコンポーネントのサブクラスの代わりにインラインコードを生成します。
* extools は exComponent と呼ばれるコンポーネントのサブクラスを生成します。

基底クラス群

* cubson の場合、シンプルフレームワークの基底クラスはそれぞれのモジュールの中に作られます。従って、多くのコード・クローンが発生します。それはモジュール単位のカスタマイズに向いています。
* extools の場合、基底クラスは exFrame に収録されています。それは差異と単位のカスタマイズに向いています。

ライブラリ

* cubson の場合、開発者は exFrame のような多くのライブラリを使用できません。しかし、彼らは XOOPS Cube プロジェクトで作られたいくつかのスマートなクラスを使うことができます。
* extools の場合、開発者は exFrame の多くの太ったライブラリを使うことができます。

XoopObject

* cubson が生成したコードは XoopsSimpleObject と XoopsObjectGenericHandler を使います。ご承知の通り、これらのクラスは XoopsObject より良く、型安全です。
* extools が生成したコードは、 exXoopsObject と exXoopsObjectHandler を使います。これらのクラスは XoopsObject と比較してただのデブです。

ActionForm

* cubson が生成したコードは XCube_ActionForm と XCube_Validator を使います。これらのクラスはよく整理されています。
* extools が生成したコードは exActionForm を使います。 exActionForm は XCube_ActionForm のための尊い犠牲でした……

テンプレート

* Cubson は XoopsForm とコンポーネントなしでテンプレートを構築します。デザイナーは容易にそれらを変更し得ます。
* extools はコンポーネント・スタビライザとしてのテンプレートを生成します。それを変更することは困難です。

ツール同期

* cubson は１回の呼び出しで自動的に複数のコマンドを呼び出します。たとえば、ひとつのコマンドがメッセージカタログを要請すると、別のコマンドがそれを受け取ります。
* extools は１回で複数のコマンドを呼び出すことはできません。

開発言語

* cubson は extoolsD.dll の一部です。それはGUI版のためにC#で書かれています。cubson は extoolsD プロジェクトにおける CUI フロントエンドです。C# はもちろん PHP ではありませんが、 PHP プログラマが C# を使うことは容易なことです。
* extools は PHP プログラムです。PHP プログラマは容易にそれをカスタマイズし得ます。

環境

* cubson は XOOPS Cube 2.1 専用です。
* extools はいくつかの XOOPS で動作します。

XCube は、本格的なフレームワークを持っていません。なぜなら、それは、開発フレームワークではないからです。「フレームワーク」は PHP にとって特別な意味を持つようになっており、 PHP プログラマを刺激します。ですから、私は、余計な討論を誘発しないためにこの「フレームワーク」という単語を使いたくないのです。
（「フレームワーク」は、ウェブプログラムの世界で特別な待遇を受けています。私は、「フレームワーク」の代わりに日本語の「枠組み」を使おうと考えました。しかし「枠組み」の意味は、フレームワークなのです……）

XCube_Controller は、コントローラクラスです。XOOPS2 構造はうまくコントローラを持つことができないので、それは、 Legacy 2.1 において仮想コントローラと呼ばれています。モジュールは、コントローラにアクセスしなくても、機能することができます。開発者は、コーディングスタイルを変える必要がありません。

XCube_Controller は、モジュールプロセスについて空のメンバ関数を持っています。それは、 execute() です。そのメンバ関数は、 XCube_Controller のメンバプロパティである XCube_ActionStrategy のオブジェクトに（具体的処理を）委託します。そのメンバプロパティのデフォルト値は、 NULL です。つまり、あなたが方針を設定するまで、 XCube_Controller は、フレームワークとして機能しません。あなたは、あなたの ActionStrategy を作成し、そして、それを XCube_Controller に埋め込むことができます。そう、つまり、着脱式だということです。

ご存じのように、 Legacy は、フレームワーク・プログラミング・ライクなコードを多く含みます。しかし、私達は、それを開発者に強要することはしません。そして、そのフレームワークは、 Legacy のフィーチャーではありません。class/ ディレクトリを見てください。私達は、モジュール毎に XCube_ActionStrategy のサブ‐クラスを定義しました。

あなたが本職であるならば、あなたは、 mojavi2 や exFrame::mojaLE より簡素である Legacy の簡易フレームワークを使うことを望まないでしょう。私は、余計な討論を誘発しないために、行き過ぎなほどシンプルにそれを設計しました。それは、私が多くの注意を払った部分です。

このような情況は、私にストレスを加えました。そして、PHP 世界を知るために、私は、それを研究することを望みました。しかし、私は PHP 世界を研究するための十分な時間を保持できませんでした。それが私にとって別世界であるということは残念です。

しかし、私が思うに、大部分の開発者は、着脱式メインロジック方式である ActionStrategy があるので、「枠組み」が問題であるとは考えないでしょう。

XOOPS Cube2.1アルファー3はもうすぐやってきます。通知以外のすべてのXOOPS2の特徴のほとんどが Legacy モジュールでエミュレートされます。いくつかの特徴はDelegateによって実装されます。

例えば、backend.phpは一度削除されました。 古いバックエンドはニュースモジュールに依存しています。しかし、ニュースモジュールはXC2.1パッケージから取り外してあります。 したがって、どんなものにも、バックエンドは有効ではありません。 そこで、それはDelegateで再び書かれました。1File Hackingか、モジュールのデフォルトプリロードでモジュールのRSS機能を加えることができます。 あなたは、PreloadメカニズムとDelegateメカニズムを知っているので、新しいバックエンドを理解することができると思います。

ところで、あなたは、XOOPS CubeがXOOPSからフォークしたものではないことを知っていますか? 私たちはゼロからプログラムを作り始めました:

オフィシャル・ドキュメントには、間違ったコンテンツがありました。 私たちは、XOOPS 2.0.xシリーズがXOOPS Cubeに含められたと説明しました。 しかし、それは間違っています。 xoopscube.orgとxoopscube.jpを始めたとき、私たちはホームページで「XOOPS」を「XOOPS Cube」に取り替えました。それがオフィシャル・ドキュメントに間違った内容があった理由です。

事実はこのダイアログによって示されます。 XOOPS Cubeは新しいフィールドです。Legacy モジュールはXOOPS Cubeで働いて、XOOPS2 JPに関するいくつかの古いファイルを含み、そして、XOOPS2 JPをエミュレートします。私たちは将来、Legacyを捨てるつもりです。次のXOOPS Cubeの新しいベースパッケージはXOOPS2のコードを含まないでしょう。

オフィシャル・ドキュメントは現在、正しい説明に変更されました。

日本で翻訳された本は高価です。 私は多くのゲームプログラマがよく読むいくつかの本の価格差を調べました。

私は以下の本について調べました:

• Game Programming Gems series
• GPU Gems series
• The Cg Tutorial
• Real-Time collision detection
• Real-Time Shader Programming by Ron Fonser



それぞれの本の価格差は異なっています。なぜ？　 あなたは、合衆国の書店は割り引きができますが、日本の書店は割り引くことができないのを理解する必要があります。 日本では、書店のバーゲンセールを見ることはできません。 それは価格差の原因の1つです。

驚いたことに、日本のGemsシリーズは合衆国の価格の2倍です。価格差をチェックしたので、私は、私が英語を読むことができませんが、オリジナルを買うつもりです。 私は Amazon.com から Amazon.jp を使っていくつかの本を買いました。アマゾンは少額の送料を要求するだけです。

いくつかのオンライン野球中継サービスが日本にあります。 広島東洋カープの試合は私が住んでいる東京に十分放送されません。したがって、私はオンライン野球中継サービスを使用します。

私はよくYahoo.co.jpのLIVEサービスを利用します。それは、自動的にアップデートされるスコアボードを表示するシンプルなHTMLページです。私がYahooによるゲームを見るとき、カープはよく勝利します。しかし、簡単なページは私を興奮させません。私は仕事時間中にそれを使用します（叫ぶことができないので）。

ある日、私はGooのLIVEサービスを利用しようとしました。 そのサービスはFLASHアプリケーションでアニメーションLIVEを見せます。 それは非常におもしろいです!



私たちは野手と打球の動きを見ることができます:



そして、私たちは、選手に関するデータと他のゲームのスコアボードを見るために、いつでもメニューをクリックすることができます。 しかし……



結局、カープは負けました。私は、二度とこのサービスを訪問しないと決めました。

次に、私は、インターネット放送でカープ対東北楽天イーグルスを見ました。 楽天は日本の有名なIT会社です。彼らは、彼らの球団の試合を放送します。私は、LIVEとオンラインスコアボードを見るのを楽しむことができました。 しかし……



カープは負けました（大敗だ！！）。私は、二度とこのサービスを訪問しないと決めました。私はYahooへ帰ります……

XoopsObject は、XOOPS で最も悪いクラスののうちの１つです。Onokazu さんもそれを認めました。しかし、今になって新しいクラスを導入することは、難しいです。私が思うに、大部分のモジュール開発は、 RAD ベースになるでしょう。従って、クラスのコードがクリーンアップされるならば、問題は少ないといえます。

私達は、 XoopsSimpleObject 、及び、 XoopsObjectGenericHandler を作りました。XoopsSimpleObject は、我々が抽出した XoopsObject の共通インターフェースを実装します。クラスダイアログを見てください :


XoopsObject は、非推奨になりました。しかし、 XoopsSimpleObject は、独自のクラス、もしくは、有名なライブラリを持たないビギナーにとって便利です。XoopsSimpleObject は、タイプセーフ特徴、シンプルなアクセスメソッド、 BOOL INT FLOAT STRING TEXT である 5 つの DTYPE を持っています。Criteira クラスは、 SQL から分離され、そして、 XoopsObjectGenericHandler は、型安全性と共に Criteria によって SQL を生成します。

Criteria クラスは動的 SQL のための情報構造体に変わりました。Criteria::render() は XC 2.1 では非推奨です。

加えて、いくつかのツールが、開発者をサポートします。私は、直接 XoopsSimpleObject のサブクラスを書いたことがありません。XoopsSimpleObject を使うために常にツールを使っています。私は、自分より機械を信用しているのです。

私達は、それを強要することはしません。しかし、開発者が DB にアクセスする際の問題を理解しないのでならば、彼は、 XoopsSimpleObject やツールを使うべきだと考えます。

ところで、 XoopsObject には、多くの短所と、いくらかのメリットがあります。 Criteria::render() が XC 2.1 で非推奨ですから、あなたは、それを何にでも使うことができます。XoopsObject は、ハンドラによって DB から分離されます。従って、 XoopsObject 、ハンドラ、及び、Crteiraは、抽象的です。あなたは、そのようなクラスを使うことによってWebサービスを使うことができます。

$handler =& gethandler(...);
$criteria = ...;
$objs =& $handler->getObjects($criteria);

開発者は、どこからオブジェクトを得たかを知る必要がありません。それは、 DB 、または、WEBサービスであるかもしれません。しかし、 DB 、WEBサービスにかかわりなく、開発者は、彼らのコードを変える必要がありません。私が思うに、このことは、近い将来重要になるでしょう。それは、ブリッジ技術にとって有益なように思われます。

しかし、その感覚は、私がアマチュアである私の経験から来たかもしれません。それは、専門家には役に立たないかもしれません。

XOOPS Cube Developers Ring は XOOPS における Third Way です。Xoops オフィシャルは中央集権的です。そして、彼らは基金を設立しました。XOOPS Cube オフィシャルは（幻想の）ヒエラルキー構造と、オフィシャルと 3rd Party の違い（という感覚）を打ち砕こうとしています。誰も、オープンソースで政争を楽しみたいとは思いません。また、私たちは基金やNPOを設立することに時間を費やしたいとも思いません。

私たちの理想は、ユーザがいくつかの基点となるXOOPSユーザ・グループサイトを造って、互いにコネクトすることです。「公式か？それとも非公式か？」そのような感覚はありません。または、ユーザは彼らのために彼らの公式サイトについて決めるでしょう。例えば、GIJOE は XOOPS と Cube の公式サイトを訪問するのを止めるようになりました。しかし、彼はfabiさんと彼の友人が造ったXoopsユーザグループ日本に参加しています。

XC Dev Ring は公式ともユーザ・グループとも異なっています。開発者を1つのサイトにとどまらせることは難しいことです。これは、友人同士が XOOPS と XOOPS Cube の如何にかかわらず相互に接続するという挑戦です。そして、それはXOOPSユーザのひとりである minahito(私) によって始められました。したがって、公式も非公式もありません。私の振舞いが悪いなら、他のメンバーは私へのリンクを削除します。 そして、私がXOOPS Cubeから離れた後であっても、リングは保たれるでしょう。

ところで、XC Dev Ring "JP" と XC Dev Ring "EN" は異なっています。"JP" には、8人の日本人メンバーがいます。 "EN"には、英語を書く2人の日本人メンバーがいます。Dev Ring は技術的メカニズムではないので、だれでも、自身の国または自分の言語で同様のRingを造ることができます。もちろん、あなたが英語で書くなら、私とGIJOEは英語のリングにあなたを歓迎します。もしくは、あなたは新しい友人リングを組立てることができます。

不完全なルール

• メンバーは RSS をブログかニュースの上で発行しなければならない。
• 開発の話題をときどき書いてください。
• 次のメンバーは前のメンバーの RSS を受け取らなければならない。
• 最初のメンバーは、環状構造のために、最後のメンバーの RSS を受け取らなければならない。

XOOPS Cube Legacy 2.1 (XC 2.1) は管理画面でヘルプビューアを実装しました。もともと$modversion['help']はXOOPS2で予約されていました。しかし、それは何処にも使用されませんでした。XC2.1では、開発者はヘルプドキュメントをモジュールに添付することができ、そして、ユーザはコントロールパネル上で直接そのドキュメントを読むことができます。

ドキュメントの添付方法

ヘルプドキュメントをあなたのモジュールに添付しましょう。 初めに、$modversion['help']にインデックスファイル名を書いてください。このファイルは、ユーザがコントロールパネルのサイドメニューでヘルプをクリックしたときに、最初に表示されるページです。私は今回、それを"help.html"と命名します。

次に実際の"help.html"を language/english の中に作成してください。そうです、ヘルプビューアはマルチリンガルドキュメントに対応しています。もしあなたが、フランス語、スペイン語その他のドキュメントを持ちたいのであれば、それぞれの言語ディレクトリ内に同名のファイルを作ってください。

最後に、ドキュメントを書きましょう！

別のページにリンクする方法

ヘルプドキュメントはPHPによって表示されます。ヘルプのURLはPHPアプリケーションのページのアドレスになるため、相対リンクで（ヘルプ内の）他のページにリンクすることは困難です。

しかし、ヘルプドキュメントは純粋なSmartyによってロードされ表示されます。そして、特別なSmartyのプラグインはURLに関するいくつかの問題を解決してくれます。 helpurl は、ヘルプビューアのみで使用されるSmartyモディファイアです。

他のページへリンクするために、ヘルプドキュメント内で次のようなURLを書いてください。

<a href="<{'page2.html'|helpurl}>">The detail of functions</a>

ドキュメントで画像を使う方法

同様の原因で、ヘルプドキュメント内で画像を（相対リンクで）使うことができません。この問題を解決するためにSmartyモディファイアのhelpimageを使うべきです。

画像ファイルを language/****/helpimages ディレクトリに配置してください。キャプチャーイメージは各言語の文字を含むため、ヘルプビューアは、ドキュメントと同様にマルチリンガルなイメージファイルに対応しています。それから img タグを次のように書いてください:

<img src="<{'screenshot01.jpg'|helpimage}>" alt="..." />

イメージ・ファイルがユーザが指定した言語のディレクトリに存在していないなら、モディファイアはenglishディレクトリからデフォルトのイメージ・ファイルを手に入れようとします。 したがって、あなたは大量のイメージ・ファイルをすべての言語のために作成する必要はありません。

規則

私たちは、ヘルプのために特別なCSSを準備する計画を立てています。開発は原則そのCSSに従ってください。 現在のヘルプビューアの外観は調整されていません。デザイナーは、XC2.1アルファー4でCSSをクールに調整して、その規則を発表するでしょう。

C# は、デリゲートをイベントとして用います。イベントは、 C# の優れたフィーチャーのひとつであり、コンポーネントにおいてイベント・ドリブンなプログラミングのために使われています。

XOOPS Cubeも、イベントの概念を持っています。しかし、それはデリゲートとイベントを区別しません。私は、コアチームはデリゲートについてクラス設計を変更する計画を持っていると書きました。その計画は、XOOPS Cubeにこれらの概念を分離させるということです。将来、このエントリのサンプル・コードが動作しないであろうことに注意してください。

さて、 XOOPS Cube のイベントを学びましょう。現在、XOOPS Cube のイベントは、デリゲートと同じものです。あなたは、デリゲートとしてあなたの関数をイベントに登録することができ、そして、そのイベントが発生したとき、イベントはあなたのデリゲートを呼びます。

例えば、ユーザーがログインに成功すると、Module.User.Login.Successイベントが発生します。その引数は、 XoopsUser オブジェクトです。実際、デフォルトのデリゲートのうちのひとつは、オブジェクトの最終ログイン時刻に現在の時間を記録します。あなたは、デリゲートとしてのあなたの関数をこのイベントに追加できます。

日本のユーザーの間でポピュラーなセキュリティ・ハックがあります。それは、特定の IP を除いて、管理者としてのログインを許可しないという機能を持っています。このハックは、会社や、管理者のパスワードが盗まれたケースへのガードに有効です。XOOPS2 においては、そのハックは、直接 common.php 、または、 admin.php に書かれなければなりませんでした。XOOPS Cube Legacy 2.1 においては、ユーザーがログインに成功したときに、デリゲートを使うことで自前の関数を実行できます。あとは、あなたの関数が、特定のIP以外を跳ね返せばよいのです。

あなたは、それを Site.Login に登録すべきです。もしアタッカーがセッションハイジャックを行えば、彼は Module.User.Login.Success を通過しないかも知れません。しかし、 "Site.Login" は、常に呼ばれます。

if (!defined('XOOPS_ROOT_PATH')) exit();

define("ALLOW_AS_ADMIN_IP", "127.0.0.1");

class IPChecker extends XCube_ActionFilter
{
    function preBlockFilter()
    {
        $delegate =& new XCube_Delegate("IPChecker", "siteLogin");
        $this->mController->mRoot->mEventManager->add("Site.Login", $delegate);
    }

    function siteLoginSuccess(&$sender, &$eventArgs)
    {
        //
        // Delegate doesn't know own turn. Call static function
        // of the user module to login.
        //
        if (!is_object($eventArgs->mXoopsUser)) {
            UserCommonEventFunction::Login($sender, $eventArgs);
        }
        
        //
        // If the current user is guest, return.
        //
        if (!is_object($eventArgs->mXoopsUser)) {
            return $eventArgs;
        }
        
        //
        // If the current user is a administrator, check IP.
        //
        if ($eventArgs->mXoopsUser->isAdmin()
            && $_SERVER['SERVER_ADDR'] != ALLOW_AS_ADMIN_IP) {
            $_SESSION = array();
            $sender->executeForward(XOOPS_URL . "/");
            die();
        }
        
        return $eventArgs;
    }
}

このファイルを XOOPS_ROOT_PATH/preload/IPChecker.class.php に保存してください。

さて……このような機能は XOOPS Cube の本体に含めることが可能です。しかし、一部の人のみが必要とするリクエストが、どれくらいあるでしょうか？　一体だれが、これらのコードを取り込んで、管理して、メンテナンスできるでしょうか？　肥満プログラムは、えてして良好なメンテナンスを失いがちです。私達は、小さなコアを選択しました。それはそれほど多くの機能を内蔵していません。しかし、プリロードとデリゲートは新しいハック手段と共有をもたらすでしょう。

ユーザーのアイデアは、しばしばコアを超越します。そして、ユーザーは、これらのアイデアのうち必要なものだけをセットすることができるのです。

デリゲートは、本質的にコールバック・メカニズムです。デリゲートによって、コールバック・プログラミングの全ての長所を利用することができます。交換可能性においては、クラス継承もデリゲートと同様に役に立ちます。したがって、クラス継承とデリゲートを区別して使い分けることが、重要になってくると思われます。そのために、クラス継承とデリゲートの特性の違いを理解する必要があるでしょう。

以下のクラスを見てください。

1. PMMonitor と呼ばれているこのクラスは、１週間読まれていないプライベートメッセージを持つユーザーをリストアップして、彼らにメールを送ります。
2. このクラスを使用するコードは、ブロックに含まれています。
3. その機能は、ブロックをサイトに置くことによって動作中になります。

言い換えると、プログラム・カウンタは、このクラスのコードを通過（実行）します。

さて、あなたは、このクラスが管理者に CC を送ることができるならば、それが自分にとってより便利になると考えました。そして、あなたはサブクラスを定義して、CC を送るために基底クラスをオーバーライドしました。



しかし、それは動作しません。他のコードが、あなたが新作したサブクラスの名前を知らないため、そのサブクラスは、どこからも呼ばれません。言い換えると、プログラムカウンタは決してこのサブクラスを通過しません。あなたがサブクラスのインスタンスを作成するコードで、基底クラスのインスタンスを作る元のコードを取り替えるまで、あなたのサブクラスは機能しないでしょう。

クラス継承は、プログラム上で開発者に機能を交換する可能性をもたらします。しかし、それはソースコードの変更を必要とします。 PMMonitor がデリゲートを持っていれば、機能を交換するか、機能を加えるためにそれを活用することができます。この場合、サブクラスを定義して他の箇所のソースコードを変更する必要はありません。

デリゲートを持つクラスが「PMMonitorDash」であると仮定しましょう。PMMonitorDash は、固定機能の代わりにデリゲートを使います。したがって、 PMMonitorDash のデリゲートにあなたの関数を登録すれば、あなたのコードが PMMonitorDash で働くことになります。



XOOPS Cube ではカスタマイズするために基本クラス群を取り替えることができます。それは、最も抜本的な改造方法ですが、しかし、ハードワークでもあります。ユーザーは、それを最後の手段と呼ぶかもしれません。その点、デリゲートは XOOPS Cube で最も簡単な改造方法になるでしょう。

デリゲートは、 XOOPS Cube における新しいフィーチャーです。それは、統一的なコールバック手続きということになります。開発者は関数と同様にそれを使うことができます。そして、それは、交換可能性をもたらします。しかし、私達は XOOPS Cube 2.1 RC バージョンまでに Delegate に関するいくらかのクラスの設計を変える予定です。この計画は、このエントリシリーズのサンプルソースコードに関する問題を誘発します。

デリゲートは、Ｃ＃、Ｄ言語 、及び、いくらかのプログラミング言語のが持つフィーチャーです。それは、ファンクションポインタのようなものです。ご存じのように、プログラムは、コンピュータの原始時代からファンクションポインタのようなものを使用してきました。それは、アドレスレジスタによって指定されるアドレスへのジャンプです。

本来であれば、 XOOPS Cube が、 PHP でコールバックのための手続きを定義する必要はありません。PHP は、コールバックのための関数を持っており、そして、プログラマはいくつかの方法をコールバックに使うことができます。しかしながら、プログラマが彼のすべての関数にプラグイン・メカニズムの実装を試みるのであれば、彼はプログラミングと説明に多大な時間と努力を払わなければなりません。

プログラマは、プラグインファイルをロードし、関数をチェックし、コールバックを実行するプログラムを組まなければなりません。プラグイン・メカニズムを持ついくらかの XOOPS モジュールを見てください。これらのモジュールのコールバックのための方法は、すべて異なります。そして、もし、コールバックについて設計されていないモジュールへプラグイン・メカニズムを付け加えるならば、それは大変な作業になるでしょう。

デリゲートはは、統一されたコールバック手続きによってこれらの問題を解決します :

• プログラマは、彼の関数を C# と同様に、デリゲートに変更できます。
• プラグイン開発者は、 XCube_Delegate メカニズムのみ学習すれば大丈夫です。
• プラグイン・ファイルをロードすることについて考える必要はありません。（プリロードメカニズムを思い出してください）

モジュール開発者は、最初にコールバックなしでプログラムを完成させることができます。次に、リファクタリング・ツール、もしくは、手動によって通常の関数をデリゲートに変更します。この２ステップによって、交換可能なモジュールが、今まさに完成しました !

もし、コアがデリゲートとしてのトラックバック関数を持っているのであれば、ユーザーは、それをモジュール、または、 1 File Hackings が持つ他の関数と交換し得ます。私は、デリゲートなしの XOOPS Cube を想像できません。デリゲートは、コア開発、モジュール開発、カスタマイジングにとって便利です。

私たちはいくつかのすばらしいツールからドキュメンテーションツールを選ぶことができます。あなたがオープンソース作業でそれを使用するなら、Doxygenはあなたのための最高のアプリケーションであるかもしれません。それは十分、有名なアプリケーションです。 Doxygenのすごい特徴は複数のプログラム言語をサポートするのが可能であるということです。 C、C++、Java、Objective-C、パイソン、IDL、PHP、C#そしてDからドキュメントを作るので、Doxygenはほとんどのオープンソースプロジェクトの役に立ちます。あなたは、あなたが新しいオープンソースプロジェクトをダウンロードした後にすぐ生成したドキュメントでソースコードを読み始めることができます。

また、Doxygenは、あなたのプログラムの設計に関する考えをクリアにするために使用されます。 IDEスクリーンの上で汚いコードを再考することは難しいことです。Doxygenと一杯のコーヒーは、それを簡単にします。

私は、Doxygenが私たちに良い理由が、Ｃ＋＋の良いUMLモデリング・ツールがないということであると思います。私が何らかのツールで私たちのソースコードからUMLダイアログを生成しようとしたとき、それは深いクラスを分析することができませんでした。高価なツールもまた時折いくつかのクラスを見逃しました。そして、複雑なクラステンプレートは役に立つダイアログを決して生成しません。C++(または、PHP)の場合、Doxygenによって作られたドキュメントはUMLツールで作られたダイアログより私たちに有益です。

Doxygenは良いのですが、この事情はC++でプログラムを作らなければならない私たちにとって深刻な問題であるかもしれません。

私は XOOPS Cube のためのいくつかの Windows アプリケーションを開発しています。

For Development

私はcubosonとcubson GUI Forceをリリースするつもりです。 Cubson GUI ForceはcubsonのGUI版です。 それは私が考える新しいモジュール開発スタイルを実現します。Cubson CUIはプログラムを作るのを楽しむプログラマーのために作られています。しかし、Cubson GUIはXOOPS Cubeを楽しみたがっているすべての人のためのおもちゃです。

Cubson GUI Force は私が長い間求めていたものになるでしょう。しかし、それは十分ではありません。私は設計段階からRADのために設計されている理想的なCMSを求めています。 私は次回、それについて書くつもりです。

特別なDLLを使用するので、現在、Cubsonはクローズソースです。私はcubsonの最新のソースコードからそれを既に取り除きました。しかし、まだコンパイルに対して完全ではありません。

For Destribution

ディストリビューターはXOOPS Cubeの新しい重要な存在です。それはユーザ・グループの一種です。彼らは、彼らが望む１つのベース・モジュールといくつかのモジュールから成るオリジナルのパッケージを配布します。それらはユーザの中心になるでしょう。

彼らのためにパッケージを自動的に作成する特別なツールが必須になります。そして、それは GUI ツールであるべきです。 彼らがマウスだけでパッケージを作成することが可能なツールが存在しないならば、ディストリビューション・グループは現れないでしょう。

For Management

自動アップデートのための手段はしばしば検討されます。それらのうちの１つはPEARのような仕組みです。それは、いい方法であり、だれかによって作られるでしょう。私が考える手段は、FTPプロトコルを直接使って、最新のプログラムを手に入れて、それをユーザのサーバにプットする自動メンテナンス・アプリケーションです。サーバのパーミッションに関する設定が必須ではないので、初心者にとって、そのようなアプリケーションはお手頃だと考えます。もちろん、このアプリケーションの目標は、GUIとマウス専用です。

すべてのモジュールとテーマは、自己の情報をそのようなアプリケーションに示すために、package.ini.php というファイル名のマニフェストを持つようになるでしょう。テーマには、マニフェストが既に導入されてます。しかし、マニフェストの形式はまだフィックスしていません。

ザウルスSL-C3100は、PIMとして便利とはいえません。特に、ザウルスのカレンダー・アプリケーションは、人間への挑戦です。それは、ウェブ・カレンダーのようです。私は、カレンダーの上で直接私の予定を動かしたり、部分修正することができません。ドラッグ＆ドロップは、サポートされていません。修正のために、スタイラスペンでスケジュール・アイテムをタップし、編集フォームを開く必要があります。スケジュールを細かく調整しなければならないときは、ひたすらタップを繰り返さなければなりません。さらに、私は週間スケジュールグラフの上で、スケジュールの件名を見ることができません。私はバーだけを見ることができます。中身を見るためには、またしてもタップしなければなりません。。。

しかし、それがマイクロ・ハードディスク・ドライブに大きなファイルを格納することができるので、 SL-C3100 は電子辞書として良好です。ザウルスのデフォルトの電子辞書アプリケーションは EPWING フォーマットをサポートします。私たちは、EPWING フォーマットにコンバート可能なあらゆる電子辞書を追加することができます。もし、あなたのザウルスがハードディスクを備えていなくても、辞書ファイルを圧縮することができます。

私は、先日私のザウルスへ英語の辞書である英辞郎を追加しました。その手順は、以下のとおりです:

1. 英辞郎の第二版 CD-ROM を購入し、そしてそれをあなたのＰＣに挿入してください
2. EBStudio フリーウェア版をダウンロードしてください
3. EBStudio を実行し、eijiro-all.ebs を開いてください
4. あなたの CD-ROM を基準ディレクトリとして指定してくだい
5. 「電子書籍作成の実行」をクリックしてください
6. "eijiro" ディレクトリを Zaurus の /dict2 の中で作成し、生成されたファイルを /dict2/eijiro にコピーしてください
7. ザウルスの辞書アプリケーションの設定フォームを開き、英辞郎を付け加えてください

私は、英辞郎なしではいかなるエントリも書くことができません。ザウルスの英辞
郎によって、通勤電車の中で、私はブログを書くことができるようになりました。

ノート

私は、日本の状況でこのエントリを書きました。あなたのザウルスが日本製でなければ、それは不可能かもしれません。

1File HackingとModuleの違いはどのようなものでしょうか？　 例えば、あなたのサイトが家だとしましょう。モジュール、１ファイルハッキング、および他の要素は次のように考えることができます:

• コアは土地です
• モジュールは柱です
• １ファイルハッキングはデコレーションです
• (ディストリビューションはモデルハウスです)

モジュールには、素晴らしいコンセプトがあります。 しかし、それは大きめの仕事です。プログラムを作ることができたとしても、ほとんどのユーザはサイト・カスタマイズのためだけにモジュールを作ろうとしません。 一方で、軽量できめ細かいカスタマイズをもたらす１ファイルハッキングを手にするでしょう。ユーザにとって、専用の１ファイルハッキングを作ることは全く問題がありません。 (もちろん、彼はそれを共有することができます)

１ファイルハッキングはXOOPSの使い方を変えるかもしれません。XOOPS Cubeのインストール手順は次のようになるでしょう。

1. パッケージをお気に入りのディストリビューションからダウンロードします
2. XOOPS Cube本体とパッケージをインストールします
3. 好みのモジュールをインストールします
4. 好みの１ファイルハッキングをインストールし、チューン・アップを行います。もしくは、１ファイルハッキングを自作して、それを公開します。

私は、１ファイルハッキングが、バージョンアップを難しくする直接的ハッキングの大半に取って代わることを期待しています。また、サイト・オーナーは彼らのフォーラムで、この１ファイルハッキングに関する新しいトピックを得るでしょう。

XOOPS Cubeのデリゲート・メカニズムはPreloadの可能性のすべてを発揮させることができます。 OSC2006/Springでは、Nobunobuさんが1個のファイルだけでbbcodeに関するtextsanitizerの動作を変更するデモを示しました。 それはデリゲート・メカニズムを使用しました。 もちろん、デリゲートを使わない１ファイルハッキングであっても、問題ありません。私は近い将来、デリゲートについて説明するつもりです。

1 ファイルハッキングはXOOPS Cubeの新しいカスタム手段につけられたニックネームです。それはPreloadとActionFilterの組み合わせによって実現されます。サイト・オーナーはピンポイント・カスタマイズにそれを使用します。

Preloadは初期化コードをXOOPS Cubeの手続きに追加するメカニズムです（DOSのバッチ・ファイルを想像してください）。ActionFilterは初期値設定のためのmojaviライクなクラスです。CVS上の最新の2.1では、Preloadの規則は以下のようになっています:

• /setting/site_default.ini.php の AutoPreload 値は真でなければなりません。しかし、それがデフォルト値であるので、あなたはそれを編集する必要はありません。
• 拡張子が'.class.php' であるファイルを作成してください。
• そのファイルで XCube_ActionFilter を拡張するクラスを定義してください。
• そのクラス名は、そのファイルのボディー名と等しくなければなりません。

私は実例を用いて１ファイルハッキングのPreloadを説明します。あなたは XOOPS Protector をご存じかと思います。GIJOEさんはXOOPS Protecorの最大効果のために、mainfile.phpをハックすることを勧めています。ハックされたmainfile.phpと同様に動作するファイルを作成しましょう:

1. XOOPS_ROOT_PATH/preload ディレクトリ内で 'ProtectorLoader.class.php' ファイルを作成してください。
2. 以下のコードをプログラムしてください:

class ProtectorLoader extends XCube_ActionFilter
{
  function preFilter()
  {
    include( XOOPS_ROOT_PATH . '/modules/protector/include/precheck.inc.php' ) ;
  }

  function preBlockFilter()
  {
    include( XOOPS_ROOT_PATH . '/modules/protector/include/postcheck.inc.php' ) ;
  }
}

ミッション・コンプリートです。 このファイルは、共有するのによいでしょう。 何らかのモジュールをインストールした後に、サイト・オーナーはこのようなファイルでサイトをチューン・アップすることができます。

ノート:

あなたはX11ライセンスの下で、このエントリーを扱うことができます。 しかし、このエントリーは毎日成長するXOOPS Cubeアルファーバージョンに依存しています。あなたはそのことに注意しなければなりません。
(日本では、著作権を放棄することはできませんが、X11ライセンスは日本の著作権法に矛盾しません)

なお、公式の仕様が定められた際に、公式のテクニカル・ドキュメントが公開されるでしょう。

GIJOEさんは、記事の中でポリモフィズムのためにXOOPS_TRUST_PATH^[1]を利用することを提案しました。それは良いアイデアです。 Nuke と PageController の組み合わせは、'複製可能'のためのいくつかの弱点を持っています。それに関するエクセレントなコードを書くことはなかなか難しいといえます。GIJOEさんはそのような問題を解決しようとしています。

私は以前、私の会社に関するイントラネット・ウェブ・プログラムで同様のメカニズムを実現する面白いコードを見かけました。私はそれの詳細を書くことができませんが、おおむね以下のようなものでした:

define_class('myData', 'tableA');
$instance = new myDataHandler();

function define_class($className, $tableName)
{
  //
  // Define class
  //
  $code = "class {T}_Handler {" ...

  $code = str_replace("{T}", $className);
  $code = str_replace("{table}", $tableName);

  eval($code);
}

これはeval()による簡単なC++テンプレートメカニズムです。実行コードが直接関数に書かれているので、これはほとんど安全です。 私は、それからヒントを得て、extools^[2]のClassTemplateを開発しました。

eval()は、XOOPSにおいて'複製可能'メカニズムのためによく使用されます。 C++ライクなテンプレートメカニズムはeval()の使用のための統一手順ということになります。それは設計を気楽にしてくれるかもしれません。しかし、eval()はしばしばセキュリティーホールを作ります。 このような使用方法をするときがきたら、十分注意してください。

---
^[1] XOOPS_TRUST_PATHはウェブブラウザがアクセスすることができない安全なディレクトリです。
^[2] extools はexFrame(XOOPSクラスライブラリ)のためのコードジェネレータです。

CG WORLDの最新号で曲面のモデリング方法が特集されていました。その記事の冒頭で、曲面の変遷が簡単に説明されていました:

1. ポリゴンはもっともポピュラーな方法である。しかし、この方法は、複雑な形状を作るときに、膨大なデータ量に悩まされるというウィークポイントがある。
2. 一方、自由曲線のデータサイズは小さくて済む。が、計算負荷が高く、複雑で、取り扱いも難しい。データが軽量で済むため、一時期、ポピュラーな方法だった。
3. ポリゴンは複雑な形状に対する欠点を持っているものの、最近のコンピュータのスペックが上がってきているので、現在では曲面処理にもよく使われている。

そして、Maya、3ds MAX、XSI、そしてLightWaveを使用するチュートリアルが掲載されていました。これらのチュートリアルのすべてが曲面(スプライン等)を使用します。確かに、これらのアプリケーションの曲線ツールはどれも非常に良いものです。しかし、Shadeはどこにいったのでしょうか？　コンピュータのスペックが低かった時代から、Shadeは曲面機能のみを実装してきました。Shadeには多くの弱点がありますが、曲面特集のときくらい、Shadeに対する敬意があってもよいのではないかと思います。Shadeが少し気の毒でした。

私はずっと自由曲面が好きで、リアルタイム処理でそれを扱いたいと思っています。それはまだしばらく難しいでしょう。

ほとんどの次世代ゲーム機は、直接スプライン曲線を使用する機能を持っています。しかし、私は道路のカーブがポリゴンで作られているのを、XBOX360のレースゲームで目撃しました。リアルタイム処理におけるスプライン演算が難し過ぎるので、だれもうまくスプラインを使用することができないかもしれません。 おそらく、リアルタイム処理には、サブディビジョン・サーフェイスのほうがスプラインより向いているでしょう。

ご承知のとおり、VisualStudio Express edition は無料ダウンロードになりました。 いくらかのオープンソースプロジェクトが、コンパイラのサポートに関する姿勢を変えるように思えます。 あなたはVisualStudio.NET C++ Expressを使う際に.NETを気にする必要はありません。無料のVisualStudio.NET C++でも、CLR(VM)なしで実行可能なネイティブコードをビルドすることができます。^[1]

OSS プロジェクトは gcc、Code::Blocks、VisualStudio C++ 6 などのフリーのコンパイラ、IDE、および古い環境へのサポートを要求されがちです。しかし……今や OSS プロジェクトが、VisualC++ 2003 以下の古い IDE をサポートする必要があるでしょうか？ VisualStudio Express edition は、microsoft の最新コンパイラを持っています。

VisualC++ 6 は古いコンパイラです。開発者はテンプレートを使うコードをうまく書くことができないケースがあります。私はMarijuanaさんからこの問題を聞いたとき、とても驚きました。なんと、次のようなコードを書くことができないのです:

std::List<SceneNode>::iterator itr = ...

このコードは構文エラーを引き起こします。信じられません……これではSTLを用いたプログラムを書くことは事実上不可能です。開発者は、この制限を避けるのに'typedef'を使用しなければなりません。

typedef std::List<SceneNode> SCENENODE_LIST_T;
SCENENODE_LIST_T::iterator itr = ...

VC++6が現役だった頃に、VisualStudioシリーズを使ったことがなかったので、私はこの問題を知りませんでした。 もちろん、gccやCodeWarriorなどでは、このような問題には遭遇しません。

VisualC++ 6のこのような制約の下では、STLの本格的な使用は困難です。OSSプロジェクトが古いVisualC++のサポートを諦めるなら、彼らはこの制限から自分たちのソースコードを解放することができます。OGREプロジェクトは以下の意見を発表しました:

Lastly, if you use Visual C++, note that we have dropped support for old versions and officially support only VC7.1 (.Net 2003) and VC8 (.Net 2005) with this release. The standards support in older versions of VC++ (especially VC6) was just too bug ridden to tolerate any longer since it was constraining our development, and the upgrade path to VC8 Express is free, so there is no reason to continue to use outdated versions. You also have the choice of Code::Blocks.

これは正しい判断のように思えます。

^[1]このケースでは、プロジェクトを構成する際に「マネージコードの使用」にチェックを入れてはいけません。

Xoops User Group Japan はXOOPS Cubeコミュニティの最初のユーザ・グループです。 彼らは、XOOPSのマニュアルを仕上げて、他のマニュアルを書き始めました。 そして、彼らは他のものに挑戦しています。

それらの成果物を公式サイトに追加したがっている人がいるかもしれません。 確かに、ユーザのすべての投稿が集められるサイトは便利であるかもしれません。 しかし、それは一部のサボリの願望です。大き過ぎる公式サイトとパワーはナンセンスな問題の引き金となるでしょう。 熱心なユーザの行動力を妨害するべきではありません。

そして、私たちが新しいウェブ技術を使用することによって複数のサイトをつなげることができるのを忘れないでください。「アグリケーション」は「統一」より良いでしょう。ティム・オライリーは、1つのサイトに対する忠誠心が現在古い要素であると主張しました。

さて、XUGJの他のコンテンツを見ていきましょう：

XOOPS Dictionary

これはXOOPSに関する辞書です。 あなたは辞書で専門用語を調べることができます。また、フォーラムの投稿からwikilinksに似ているものを用いることで辞書のすべての単語をリンクすることができます。その機能はGIJOEさんの素晴らしい仕事です。

XOOPS Cube2.1では、そのようなハッキングは、Delegateメカニズムを使用することによって、実装されるでしょう。 私は近いうちに、それに関して書くつもりです。

Xoops Q&A

このコーナーは質問して、それに答える特別なフォーラムです。うまく答えたとき、あなたはポイントを得ることができます。plzXoo(教えて！Xoo)モジュールがこのコーナーで使用されています。しかし、それは標準のヘボいplzXooではありません。 GIJOEさんはこのコーナーのためにすばらしい Alternative バージョンを開発しました。

私は、plzXooがうまく使用されるのを一度も見たことがありませんでした。しかし、Alternative バージョンはうまく機能するように見えます。私たちは Alternative バージョンの機能だけではなく、管理者の方々の良い仕事にも注意を向けなければなりません。

XOOPS CubeコアチームはXOOPS Cubeコミュニティの中央集権体制化に反対しています。 私たちは、XOOPS Cubeコミュニティが複数のサイトに分散されることを願っています。 このスタイルは自由と相互尊重をもたらすでしょう。

XOOPS.org の流儀は中央集権体制です。それは、たいへんパワフルで素晴らしいものです。しかし、私たちはそのようなスタイルを取りません。私たちのスタイルはXOOPS.orgの全くの正反対にあります。

私たちの分散スタイルの利点は以下です:

1. ヒエラルキーの崩壊

幻想のヒエラルキーは打ち砕かれるでしょう。権威ある組織(コアチーム)、独占的な権威、および権威ある（と自分で考えている）人は力を失うでしょう。これらの権威が存在するかもしれないという発想は、非常にナンセンスであり、まったく不要です。公式サイトはコードと同様に小さくならなければなりません。公式とコアチームは主役ではなく、黒子にすぎません。

多くの人の行動力は、一握りの人の肩書きより重要です。この目的のために、私たちは私たちの権限をソフトランディングで放棄したいと考えています。^[1]

2. ハイスピード

誰も、自分のサイトで自分の意見、モジュール、およびドキュメントのリリースのために「議会」から認可を得る必要がありません。情報が分散していても、ウェブ2.0的な概念が複数サイトをつなげてくれるでしょう。

3. 独立

公式サイトコミュニティはXOOPS Cubeのための唯一のコミュニティではありません。 それはXOOPS Cubeコミュニティの1つです。公式サイトコミュニティとXOOPS Cubeコミュニティは等価ではありません。だれかが公式サイトを気に入らなくても、彼は彼の仲間と共にサイトを始めることができます。そして、価値観を異にする2つのサイトは新しいウェブ技術で相互理解と共に繋げられるでしょう。

このように、独立は真の相互尊重をもたらします。 XC Developers Ring を見てください。これも1つのコミュニティ・スタイルです。

4. フォア・ザ・コミュニティ

重要なスローガンは「フォア・ザ・オフィシャル」ではなく「フォア・ザ・コミュニティ」です。誰もが自分のサイトや様々なサイトで、XOOPS Cubeコミュニティに関する自分の考えを実行に移すことができます。

以上の概念は、夢物語のように思われていました。しかし、日本ではXUGJのスタートによって実現に近づき始めました。

^[1] ソフトランディングで弾力的に進めることを考えている理由は、急激な変化はしばしば混乱のトリガーとなるためです。

2人の有名なXOOPS開発者が新しいサイトを始めました。 これらのサイトは現在、利用可能であり、XC Developers Ringに追加されました。

１つはXOOPS Cube 2.1で構築された龍司さんの新しいサイトRYUSLABOです。ryuji.beにあった古いエントリーと、このサイトで公開された新しいエントリを読むことが出来ます。知りうる限り、XC 2.1によって公開を行っている唯一のサイトです。

もう１つは XC2.1 のための nobunobu さんの新しいサイトである nobunobu.com です。のぶのぶさんは、コンテンツ状況が複雑になった古いサイトから心機一転をはかるためにこのサイトを始めました。このサイトではカスタマイズのケーススタディ（いわゆるハッキング）などに関して多くのおもしろい記事が読めるようになると思います。（OSC2006/Springでそのように公言されていましたので）

広島市民球場で広島対中日を観てきました……先発がロマノを含めて４名しかいないカープで、今日はローテーションの谷間。誰が先発なのか？ということが気になっていたのですが、これがG.W.明けの復帰といわれていた大竹！　このサプライズに球場は大盛り上がりでした！



しかし３回でピンチになるとブラウン監督はピッチャーを交代しました。ただ、大竹はよいピッチングをしていたと思います。交代した高橋は、かなり厳しい内容でした。どうせ打たれるなら大竹を続投させていたら……と思いましたが、怪我直後だとか、いろいろあったのだと思います。



昨日は満員御礼状態でしたが、今日のゲームも結構人が来てました。ただ、三塁側内野は結構空いてまして、昨日にはちょっと及ばなかった。雨も降りそうでしたし、仕方がないと思います。

試合結果？　思い出したくないですね。ただ、本当に久々に市民球場で野球を観ることができて嬉しかったです。

家族と一緒に面白い大会に参加してきました。日本の有名なマラニック（マラソン＋ピクニック）のひとつである「山口１００萩往還マラニック」です。この大会では35km、70km、140km、250kmのコースと、走る部門と徒歩部門が用意されています。両親はほぼ毎年参加しているものの、中国地方を離れた私は６年ぶりの参加になります。６年前は35kmを走って膝を怪我してます。今回は、母が病気のため長距離を走れなくなったことと、私の練習（＆減量）不足のため、35km徒歩部門に参加しました。

徒歩部門ではタイムレコードが記録されないので、走ったり歩いたりを自由に切り替えて大会を満喫できました。父は毎年70kmに参加しており、自分も来年は70kmの参加を目標にしています。

マラニックは通常のマラソンと異なり、ランナーは山中を走らなければなりません（この大会では山口市を起点に中国山地を越えて萩市を目指し、距離に応じて、これを往復する）。マラニックの35kmは平地の42kmよりきつい感じなのですが、目が飽きないので、個人的にはマラソンよりマラニックの方が好きです。萩往還マラニックはマラソン専門誌である「ランナーズ」で「走ったあなたが選ぶ全国ランニング大会100撰」に過去２年連続で総合１位に選ばれたことがある評価の高い大会です。



大部分のランナーは瑠璃光寺五重の塔（山口市）からスタートします。



萩往還は、参勤交代で萩城（萩市）から江戸方面への交通網が発達した山陽側へ移動できるように1604年に開通した石畳の道です。これがまた走りにくい＆急坂なのですが、ここを走ることがこのマラニックの大きな魅力になっています。



萩往還の寸断ポイントでは、日本のクラシックな景色の中を走ります。都会の人はこれに感動しながら、おのぼりさんは郷愁を感じながら走るわけです。

私は、もっとページを読みたいと思ったとき、反射的に CTRL+D を押してブックマークを作る傾向があります。

先日、それによって累積した４００超のブックマークを整頓しました。数が数だけに、それなりに重労働でした。最初に、興味をもっている主題についてのフォルダーをいくらか準備しました。しかし、これらのフォルダーは、ブックマークの全てを整頓するのに十分ではなく、「その他」フォルダーは１５０のブックマークで溢れました。そのために、更に大量の追加フォルダーを作らなければなりませんでした。

しばらくして、追加フォルダーが、自分が普段意識していない隠れた興味を示していることに気付きました。たとえば、「偉人伝」、「戦車に関する新技術」、「タコの生態」、そして、「美人の女性」などです。最初にフォルダーを準備したとき、自分が「タコの生態」に興味を持っているとは思いませんでした。しかし実際には「その他」に分類できないほど多くの、タコの生態に関するブックマークがありました。追加されたフォルダーが、その興味に気付かせてくれたわけです。

私は、ブックマークを wiki をエクスポートできれば、しばしばまとめページや備忘録に使われる wiki ページが興味深いものになったり、手間が省けるのではないかと考え始めました。さっそく、エクスポートのためのシンプルな Windows アプリケーションを作成しました。firefox におけるブックマークのデータは単に HTML ページですので、このアプリケーションは、容易に作成することができました。このテスト・アプリケーション FireWiki はここからダウンロードが可能です。

このアプローチは工夫を重ねればさらに面白いことになるかもしれません。そのために、このアプリケーションのDLL等を公開するつもりです。