sunday-lab 日本語版

The spec of XOOPS Cube Legacy 2.2.0

2008-12-01T15:06:00.000+09:00

日曜日に名古屋へ行って、 2.2 の開発に参加する日本側の開発者とミーティングしてきました。まず 2.2 のアルファバージョンを半年先の来年５月頃にリリースするという線引きを行い、その中で実現可能なことと実現不可能なことを話し合ってリストアップしました。

　この内容を 2.2 のメインの開発者となるギガマスさんにフィードバックします。

　2.2 ではプログラム面の改修を日本側で、 UI 面の改修を海外で行います。細かい改修も多く入りますが、大きなところでは以下の改修が注目に値するのではないかと思います。

UIの改善
CSS Framework を使った新テーマ
新しい多機能ユーザーモジュールの追加
dhtmlteztarea を FCKEditor に変更可能
高速化

OSC2008 in Fukuoka

2008-12-01T09:25:00.000+09:00

サイトなくなったと思ってましたが、XOOPS9出展するんだ！行く予定にしとけばよかったなぁ～

XC's repository moved to SVN

2008-11-25T09:26:00.001+09:00

「オラは SVN しか絶対に触らねえ！」
という技術者の皆様に朗報です。昨日、 XC のリポジトリが CVS からSVN にお引越しいたしました。 CVS 時代のスクリプトの移植と SVN コミットログ ML を準備してくださった nobunobu さんに感謝しましょう。感謝～ m(__)m

より詳細は、プロジェクト phpBB フォーラムの該当トピックをご覧ください。

（ニュースにも投稿しなきゃいけませんが電車の中なんで許して……）

忙しいからこそフリー活動する

2008-11-22T13:24:00.005+09:00

前回の CEDEC で、私は稲船敬ニさんの基調講演を聴きました（彼は日本でもっとも有名なゲームプロデューサーの一人です）。彼は言いました "負けてる時、苦しい時は攻めに回らないと当然負けてしまう。しかし勝っているときにも攻め続けなければいけない"

稲船氏はこの姿勢では海外メーカーに勝てないという。この現状をサッカーに例えて、「日本のナショナルチームがブラジルと対戦して3点取られたとする。ここで監督は『これ以上得点はやれない、ディフェンスを増やせ』とは言わない。8人で攻めろといったほうが格好いい。日本のゲーム業界は、ここで8人で守れと言っている。日本のゲーム業界は海外に3点取られているのに、守れというのはおかしい」と述べた。

どのような状況でも攻める手を緩めるべきではない。

それはとても興味深い考え方です。そしてそのスピーチはふたつの意味で私の考え方を変えました。
私は、自分たちにやる時間があるかどうかに関係なく、大量のタスクをプロジェクトに追加する決断をしました。

彼のスピーチを聴くまでは、私はプロジェクトのミッションの数を減らしつづけていました、なぜなら具体的にプロジェクトを推進するマンパワーがなかったからです。そして私は有志が再び十分な自由時間を獲得する時を待ち続けました。しかしそれは間違った判断でした。

私達日本人はとても忙しいです。忙しいからこそ、プロジェクトはミッションを追加することがあっても減らすことをしてはならなかったのです。矛盾していると思うでしょう。しかし減った仕事の状態でプロジェクトが維持できてしまうと、状況はそこで固定されます。もし攻勢にまわる道が選択できないなら、プロジェクトは閉鎖されるべきでしょう。

ですから「これ誰が担当するの？」なんて考えなくてよかったのです。誰もやらなければ最後に立った一人ができるところまでやる。それができなければ遅延したり、停止したりするでしょう。マンパワーの補充がなく、それが続けばプロジェクトはそこまで。それはToDoが多かろうが少なかろうが変わりません。

いまプロジェクトには多くのプログラム的な目的や、日本 Xoops の歴史上 XUGJ しか成功していない Day-to-Day な活動項目を追加していますが、なんの秘策もありません。

XOOPS Cube Legacy 2.1.6 リリース！

2008-11-21T12:56:00.011+09:00

# すみませんここに書くのが精一杯。オフィシャルβのニュースやポータルへの投稿は帰宅してから。

バグレポート、パッチ、テストなど、開発へのご協力をいつもありがとうございます。バージョン 2.1.6 の RC （リリース候補版）の検証スケジュールは無事終了しまして、 2.1 系最新の安定版としてリリースを行いました。たくさんのバグ修正が行われてますので是非バージョンアップしてください。

プロジェクトはこれで 2.1 系の主な作業を完了しました。これからは Legacy 2.2 はもちろん、コア 1.0 や、新型 BASE の開発を本格的にスタートさせます。

== スタッフ ==
- 10key
- argon
- GIJOE
- gusagi
- hypweb (nao-pon)
- kilica
- Marijuana
- masarap
- Mikhail
- minahito
- mumincacao
- nor
- okuhiki
- ohwada
- onokazu
- orrisroot
- pcboy
- sacchan
- slayer_cg
- suin
- tohokuaiki
- tomoro
- Tom_G3X

更新履歴
[Bug Fix - From Bug Tracker]
- Fix Bug #1833191 - lisense message of installer
- Fix Bug #1865695 - XoopsToken Not in use. at legacy_comment_navi.html
- Fix Bug #1978064 - users_group_link doesn't have unique key
- Fix Bug #2014727 - Removed template variable code that is assigned many times.
- Fix Bug #2015589 - genId typo in some handlers in kernel.
- Fix Bug #2018226 - It's impossible to choose portuguese in the installer
- Fix Bug #2018271 - ThemeListAction.class.php resulting Warning and Fatal Error.
- Fix Bug #2018281 - xoopsmailer.php - path disclosure vulnerability.
- Fix Bug #2018284 - path disclosure vulnerability in greek\charset_mysql.php.
- Fix Bug #2018956 - xoops_redirect parameter: path disclosure vulnerability.
- Fix Bug #2019640 - invalid / unnecessary files in portuguese translation.
- Fix Bug #2019660 - "MSN" no longer exists. Replace with "Windows Live ID"
- Fix Bug #2028663 - Update Callback is not called at pending comments approval
- Fix Bug #2062535 - css.php doesn't work perfectly.
- Fix Bug #2073613 - Problem of parse_url().
- Fix Bug #2084802 - Users' posts should not be increased at the control panel
- Fix Bug #2101729 - Typo comment in Legacy_ModulePhasedUpgrader
- Fix Bug #2115390 - GPL V2 License Link is changed
- Fix Bug #2115634 - $db->query() cannot handle only limit query.
- Fix Bug #2121388 - Missing translation in japanese language file.
- Fix Bug #2123870 - register.php :: missing user_mail_ok
- Fix Bug #2129194 - A typo of SID's connector in redirect_header
- Fix Bug #2178519 - "showall" of the search feature doesn't show correct URL
- Fix Bug #2173864 - ModuleInstaller set invalid group permission.
- Fix Bug #2200366 - Cannot set block_read permission.
- Fix Bug #2205261 - A typo in user activation
- Fix Bug #2201567 - Some mistakes in japanese and ja_utf8
- Fix Bug #2209139 - JVN#20502807
- Fix Bug #2216013 - Doesn't assign reference in groupperm.php
- Fix Bug #2235005 - User_RegisterEditForm includes needless fields
- Fix Bug #2282727 - Controller cannot parse request path on IIS
- Fix Bug #2283070 - XoopsObjectGenericHandler cannot insert/update null value.

[Bug Fix - From "XCube" Bug Tracker]
- Fix Bug #2225372 - Bug in delegate signature checking
- Fix Bug #2232981 - Slight typo on error

[Other Changes/Enhancements]
- Patch #2062644 - Re-draw /html/images
- Patch #2120194 - Smarty 2.6.19 & phpmailer 2.0.2
- Patch #2223209 - simplified Chinese language file
- Some URLs description was changed for new lisence URLs.
- The Kick Start Guide was translated for Japanese.

I could not release 2.1.6

2008-11-17T09:35:00.001+09:00

先週末に忙しくて、疲れていたので、私は、2.1.6が完全に稼働するかどうかチェックできませんでした。したがって、私は昨日、安定版をリリースしませんでした。今日早く家に帰ることができるならば、私は、 HEAD の最終テストを行って、それをリリースするつもりです。

また、今週も非常に非常に厳しいです。私は健康に気をつけます。新しいリリースマネージャを追加しようとしたことはあるのですが、今のところうまくいっていません。うう……

作ってもらったテーマをテスト中

2008-11-02T16:14:00.005+09:00

私は長い間、XOOPS Cube コアの開発と次の BASE の開発をストップさせていました。私は数ヶ月ぶりに、それを再開しました。しかし、私はほとんどのコアコードを変更しませんでした、次世代テーマの1つを定義しようとする別の開発者のために、とりあえずテーマレンダリングだけでも可能にすることが最優先だったからです。

ご承知のとおり、XOOPS Cubeはテーマ形式を強制しません。したがって、このエントリにおけるテーマは「統一的な次世代テーマ」ではなく次世代テーマのうちの１つです。プログラマの視点からいえば、テーマフォーマットが本当に交換可能かどうかをテストしなければなりません。

jidaikoboさんにコントリビュートしていただいたこのテーマフォーマットは「スタイル」という仕様を持っています。スタイルはRapidWeaverの「スタイル」と同様です。下のスクリーンショットを見てください。（RapidWeaverで生成した）XOOPS Cube オフィシャルウェブサイト（β）と同じ外見です。

外観を変えるためにスタイルを変えます。ここは CSS だけを切り換えています。

ほとんどの次世代テーマ形式は恐らく X2 のようなテーブルベースのレイアウトではありません。そのため、テーマを作成することが（特にボランティア的には）タフな作業になってしまう可能性があります。そこで、このフォーマットでは「スタイル」で、同じテンプレートを用いて、CSSだけを切り換えることによって、多彩に外観を変更できるようにする仕様を検証しています。

Jidaikobo さん的には、CSSベースのテーマ形式のためのいくつかの考えがあります。テーマがテンプレートを持たない新しい方法が提案されました（これは撤回されたかも）。テンプレートの代わりに、テーマには、CSSファイルとイメージ・ファイルしかありません。言い換えれば、テーマは恐らく私がちょうどテストしたスタイルと等しいです。仕様が同等となると、切り分け解釈が難しいので、いくつかの議論があります。今のところは、「テーマ選択画面」で選ぶのが「テーマ」、「テーマのプロパティ」で選ぶのが「スタイル」ということになっています。

コードがえらいことになっているのでリポジトリへの反映はもう少し待ってください。

Little Big Planet gives many hints to XOOPS Cube

2008-10-30T00:17:00.000+09:00

Little Big Planet は明日、日本でも発売されます。このゲームは XOOPS Cube プロジェクトに多くのヒントを与えてくれるでしょう。もしあなたが PS3 を持っており、XCユーザーであるなら、 Little Big Planet を研究することには価値があります。

Little Big Planet は、お互いの作品をシェアするためのプラットフォームです。誰もが他のユーザーが作ったレベルをダウンロードすることができ、友達とそのレベルを一緒に遊ぶことができます。あなたは面白かったゲームの情報を世界と共有したり、タグ付けすることができます。

Little Big Planet はクリエーションツールです。誰もが新しいレベルを創ることができ、それを自由にリリースできます。いかなる創作も妨害することはできません。

Little Big Planet は楽しむためのコミュニティです。クリエーションが楽しいということは重要です。誰もがツールの前ではクリエイターです。

最後に大切なこと。Little Big Planet はあなたの日々の世界とは別の世界です。あなたはそこせ何かを創るための完全なる自由を手に入れます。

今更ながらOSC2008Shimaneを振り返ってみる

2008-10-08T00:44:00.021+09:00

今更ですが OSC2008Shimane の簡単なレポートです。べ、別に、「先月の国内 XOOPS Cube 情報ひとまとめLink」対策じゃないんだからねっ

……というわけで、出身地でもある島根県で開催されたOSC2008Shimaneに参加してきました。島根県は松江市で９月１２（金）〜１３日（土）という日程でした。

島根は遠い！？　いえいえ、そんなことはありません。僕は、開催前日の晩に寝台特急サンライズ出雲で松江に向かいましたが、これだと夜に関東を出て、朝には島根に着いています。実はその寝台特急券を紛失して横浜駅ですったもんだしたんですけど……
（しかも東京からすでに個室の中の人となっていたMySQLのsakaikさんの眼下ですったもんだをやったわけですが）

あ、これ岡山の車内販売で買った朝飯の祭り寿司です。うまかった。

会場は松江駅前の松江テルサ。大田区産業会館みたいなもんだと思ってください。

松江テルサのお隣は松江オープンソースラボです。 Ruby City Matsue ってありますね。この階下のローソンのあたりに昔喫茶店ありませんでしたっけ？　……なんにしても松江駅まわりは凄く整備されていて、浜田出身の僕は涙目です。

日程は二日間となっており、初日はスペシャルゲストを中心に、裏番組を持たない形で大規模なセッションが開催されました。二日目はいくつかの部屋に別れてそれぞれセミナーなどを行い、XOOPS Cubeのセッションも二日目に行いました。入場者数は地方開催としてはかなり多く、５００人以上が来場したと聞いています。

あ、これ二日目の昼飯の割子そばです。okuhikiさんもご用達のそば清ってお店でktamuraさんと食べました。

初日のセッションは、「コミュニティ（ホビー）系」「ビジネス系」とも違う、コミュニティ活動と地方のあり方を組み合わせて、趣味ベースの活動にせよ、ビジネスの活動にせよ考えていく……というような内容でした。そういう方面の話に初めて触れて、すごい衝撃を受けました。

「多様性は善」「まず隗より始めよ」とか、いい言葉でしたね。同じようなことXOOPS Cubeで言っても割と普通にスルーされますけど（涙）。やっぱこうでなきゃ！

もうひとつの衝撃は懇親会です。OSCの個人史を塗り替えるほど懇親会の飯が豪華でした。アニメ番組の打ち上げでもゲームの打ち上げでもこんなん食ったことないですよ！　とか思いながら食いまくってました。しかし余ってましたね。タッパに詰めたかった……

さっきから飯の話しかしてませんが、地元の民謡なんかも披露していただいたりして、これは嬉しかったなぁ。石見神楽なら死ぬほど観ましたが、安来節とか生では初めてでした。島根まで来た甲斐がありました。

また初日のパネルディスカッションで、本籍地たる広島のオープンソース団体の方がいらしていたので、懇親会中に挨拶してカープの話に興じてました。有意義な情報交換ができたと思います。（カープ的に）

そんな感じで、ともかく、Rubyの聖地・松江でやったからか、熱い官民一体のプッシュがあったからか、今までのOSCとはまた違う面白さがありました。松江市長が初日のセッションをハシゴされてましたし、懇親会から参加された島根県知事も中座されずに、日本UNIXユーザー会の方にUNIXの説明を求めたりしておられました。なかなか凄い光景だったと思います。

こういう場に来る偉い人の態度には何度かムカつかせていただいてきましたけど、市長はかなりユニークな方でした。市長や知事も楽しんでおられたんじゃないでしょうか！

僕自身もそうでしたけど、やっぱり「島根のために何かがしたい！」と人が集まった結果を人が「官民一体」と呼んでるだけ、という形でしたから、東京漬けになった身としてはすごく新鮮な熱さにあふれた二日間でした。山陰中央新報に「オープンソース全国会議」とか出てるし(^^;

ちなみに山陰中央新報のホームページはXOOPSだったりする。

あとXOOPS Cube的には島根のユーザーさんと知り合えたのは嬉しかったですし、 okuhiki さんにお会いできたのも驚きでした。まさか松江の方だったとは…… Tom さんいはく先月の OSC2008 Nagoya にもいらしていたそうですが。 orz

なお二日目の懇親会は近くの飲み屋さんで。ここの飲み屋の方は途中で鍵だけ預けて帰宅されまして、僕らビールサーバーでビールついで飲んでました。楽しかったなぁ……

これは二日目の懇親会で中座して食べにいった魚料理のお店。いかそうめんがおいしかった！

二晩泊まった後は名古屋組の方と松江観光をやりまして、行く先々で OSC の人と会ったのが面白かった。しかし松江は情緒豊かな街ですね。あれはIT企業は普通にアリなんじゃないでしょうか。エンジニアが行きたがる要素はたくさんあると思います。

最後は鯛めしで締め。

松江城から松江の町を見たときに思ったんですけど……宍道湖も綺麗ですけど、町を見れば車のほかに船が川上を行き交っていたりするんですよね。これはもうある意味外国ですよ。子供の教育には絶対いいし、僕がIT系のプログラマなら松江狙いますよ。

オープンソースで地域振興なんて無理でしょう……と最初は思っていたのですが、松江に行って感じたのは「オープンソースで地域振興する」のではなくて「何がなんでも地域振興する人たちが本気でオープンソースに入っていく」という熱気でした。

これ極論すればビジネスの話なんですけど、東京はもうちょっとクールというか、「オープンソースをうまく使う」という感じがあるような気がします。どっちが良いのかは分かりませんが、どっちが肌に合っているのか……まだ東京のほうにいて、フリーソフトウェア活動を続けるなら、どういうものを目指していけばいいのか、はっきりと固まりました。

また、IT寄りすぎるところがありましたが、ライトニングトークはまた違うノリでしたし、今後は OSC そのものにコミュニティの枠を越えてコミットして、もっと色々やってみるつもりです。本当に有意義な島根の旅でした。
（旅かい）

カナダより愛を込めて

2008-09-24T08:17:00.006+09:00

昨日はずっと2.1.6にコントリビュートされた日本語ヘルプファイルの翻訳修正をしていました。４時間あれば終わるだろうと思っていたら、なんと８時間かけても終わらないという、かなりタフなタスクになりました。でも、かなり面白かった。

実はこの日本言語ファイルはカナダの日本語クラスにいる大学生（つまりカナダ人）が作成してコントリビュートしてくれたもの。彼とはSNSで知り合い、XOOPS Cubeにも興味を持ってくれた彼は、日本語ファイルが全て揃ってないことに気付いて、勉強し始めて２年という日本語力でファイルをコントリビュートしてくれました。

国民性の違いとはいえ、日本人がおおかた３年近く誰も手を付けなかった翻訳を僅か４８時間で決断して３週間後にはファイルが届くとは……海外パワー恐るべし。

コントリビュートされたのはキックスタートガイドとユーザーモジュールのヘルプです。

まぁ日本人云々はβの頃からキックスタートガイドに関するステータス表記が変わっていなかったことも原因だと思いますけど、それも含めて誰も気づかなかったというか、ヘルプ機能自体の知名度が低すぎたというか……
（なにげに日本語は未訳ファイルの残る数少ない言語のひとつだった）

翻訳の修正はすごく楽しかったです。英語版を監修してくれた方もこんな気分だったのかなぁ。

たとえば、やっぱり翻訳ソフトを使うんだけど、翻訳された日本語が難しくて（というより無茶苦茶な翻訳になって）「訳せない！」ってなったり、
面白かったのが意外とカタカナ外来語が使えないこと。本人のポリシーかもしれませんが、基本的に日本語に訳そうとするので、それで独特の表現になったり、分かりやすくなったりしました。

たとえば「ユニーク」を「一意」と訳さず「他の人と重複してない」という訳し方にしたり……これ「ユニーク」だと日本人でも分からない人が多いと思うので、結果丁寧な翻訳になっていると思います。

結果、元の翻訳文の表現やニュアンスを守ったまま翻訳し直しというセンテンスがほとんどになりましたが、Yahoo!翻訳そのままで手がつけられなくてペーストしたセンテンスがあったり、カタカナ語で住むところを全部日本語にしてあったり……相当苦労されたと思います。ありがたいことです。

あと「ゲームのないゲーム機が役立たずなのと同じように、モジュールのないXOOPS Cubeは役に立たない」という一文に括弧で「ソニーはノンゲームって言ってますが」って書いてあったり。ウケたんですが、悩んだ末に一応削りました。まあこのヘルプが作られ始めた頃って、まだXbox360が出るか出ないかって頃でしたからね……表現が古いのはしょうがないってことで……

そんなわけで、このヘルプは2006年に作られた相当古いもので、オンラインのドキュメントが増えている今のXOOPSでは役に立たないかもしれませんが、作業された方の情熱を味わうという意味で一度目を通してもらえると嬉しいです。

Sf.net changed use of project web

2008-09-20T12:38:00.002+09:00

プロジェクトのホームページを更新するために、普段使っていた rsync のスクリプトを使ったら Connection refused になった。

shell.sourceforge.net への ssh アクセス自体が無効になっているようだ。最近、サーバーをシカゴに移すなど色々動きがあったことは知っていたが、詳細は把握していなかった。

Community Discussion Forums のこのトピックによると、Web のメンテナンスは、専用の web.sourceforge.net を使えば以前より簡単にできるようになったようだ。


rsync -av {your_directory} {account},{project unix-name}@web.sourceforge.net:htdocs

たとえば手元にある ./ja ディレクトリを http://xoopscube.sourceforge.net/ja/ に転送するには、


rsync -av ./ja minahito,xoopscube@web.sourceforge.net:htdocs

と書く。

shell で簡単に見に行く方法が今のところ分からないので、一度バックアップとして内容を取得してそれを覗くのがいいようだ。
（今回は本当はその目的で繋ごうとしていた;;）


rsync -av {account},{project unix-name}@web.sourceforge.net:htdocs {your_directory}

以前の sf.net の web 機能は、異なるプロジェクトの人にも重要なファイルを盗み見されてしまうというかなり痛い問題があった（このことは sf.net のドキュメントにも明記されていた）。しかしこれで shell アクセスができなくなるなら、その問題はなくなるかもしれない。ただ、シェルにアクセスできないなら結構普通に困りますが……

Beta of Tacker2

2008-09-20T12:33:00.004+09:00

一週間遅れですが "SourceForge.net Service Operations bulletin 2008-09-12" をじっくり読んでみました。まず、プロジェクトが使用できるアプリケーションが追加された件にについて:

Hosted Apps として、フォーラムに phpBB、wiki に MediaWiki、サーベイツールに LimeSurvey が使えるようになる。
これらのアプリケーションは、プロジェクト Web ホスティングとは異なる領域で用意されるため、プロジェクトのほうでファイルやパーミッションなどを管理する必要はない。
これらのアプリケーションのログインアカウントは sourceforge.net アカウントと同じものを使用することができる。ただしパーミッションはこの限りではない。
詳しくはこのページを読んでね、とのことです。

それから、トラッカーシステムのバージョン２が開発中のようです。そのβに関する案内がありました。トラッカーシステムにアクセスするとページの冒頭に "A new Tracker is available" と表示されます。そこで Try it out をクリックすると Tracker2 Beta を使用することができ、また元に戻ることも可能です。

いつでも安定版に戻すことができます。また、フィードバックは右上のリンクから送ることができます。
βのスクリーンショットはこんな感じです（↓）

このβに関する詳細はこちらのトピックに出ています。

The Feature Requests for 2.2.0

2008-09-18T00:07:00.006+09:00

Feature Requests:Legacy へ "2.2.0 Enhancement" という新しいカテゴリを追加しました。

未のところ XOOPS Cube Legacy 2.2.0 で実際に何を実装するのかは全く決まっていません。なにかアイデアがあればトラッカーに投稿して、それぞれのアイテム上で議論を行いましょう。トラッカーシステムはアイテム単位のコメント機能を持っていますので、それを使って 2.2.0 に関する各リクエスト毎の議論が可能です。

2.2.0 は gigamaster さんを中心としたメンバーで開発を進めていきます。 2.1.0 の頃も開発、パッチ、テストなど、国際色豊かなメンバーでわいわい進めてましたが、頭数的にはともかく、作業量的には日本人も相当なウェイトで活動していたのである意味日本語OKみたいなところもありました。が、 2.2.0 は今のところ日本のコミットメントは小さいので、現段階では英語ガチ大事です！

ということで、ローカルコミュニティで 2.2.0 の改修案などをネタにして、あとでまとめてコミュのモデレーションを通じて英訳してトラッカーに書き込んでもらう、といったやり方で参加していくのが楽しいと思います。今のところ XUGJ が日本語コミュ側とトラッカーの橋渡し活動を行っています。 XUGJ に出入りしてないよ！という方は、お好みのコミュの管理人とかモデレータさんとか常連さんとかの間で、どう扱うかとかちょっとネタにしてみてください。

海外の有志パワーとうまく開発を進めながら、言葉の壁を低くして日本人も色々意見を出すうまい方法があればそれも募集です！

Carp vs Swallows Round 19

2008-09-17T23:48:00.003+09:00

どんだけ石川と相性悪いんですか……

せっかくドラが負けてくれたので、勝っておきたい試合でしたが、打てず守れずの一方的展開……この際、ドラが負けてくれたのだから負けていい日、中継ぎを休ませた試合と見てもいいと思います。上げたばかりの牧野と上村をさっそく使ったのも賛成。しかし牧野は何か持ってますね。彼が出てきてからいきなり守備が乱れ始めました。自身もフィールディングむちゃくちゃだし……暴投とかフィールディングミスの人というイメージ持ってます。投ゴロ取りにいって転倒したのも驚いた……でもあれはガッツありました。

たった一晩で、東出、石原、ブラウワーがいなくなりましたし……フルスペックでドラとの直接対決をやれないのは正直劣勢ですが、何とか頑張りたいです。というか基本的には台風が広島に（被害出ない程度に）直撃することを祈っています。日数稼がせてくれ〜〜

ところで、
一昨日、昨日と、明らかにレフトのほうが多かった神宮。今夜に至っては開始一時間の時点で、外野入り口の前で係員が「広島側、外野自由は立ち見です！」と連呼してました。友達と行ったので外野自由３枚買いましたけど、もうポール際しか選択肢がなくて、それも３０分しないうちに売り切れてました。凄い熱さです！　平日のビジターとは思えない！

交流再開後に平日ナイター行った頃なんか４席独占して横になれそうでしたけど……

The reason why video games use Flash

2008-09-06T13:48:00.006+09:00

前回 flash.ocx を直接ダイナミックリンクする形で FLASH データを OGRE3D で活用できるアドオン Hikari を紹介しましたが、ゲームだけでなく、モバイルの性能向上にあわせて最近ではデジカメや携帯電話のメニューにも FLASH が使われ始めているようです。ゲームにおける活用も進んでいて、来週開催の国内最大級のゲーム開発者カンファレンス CEDEC においても、FLASH を使ってゲーム UI を構築するというセッションが開催されます。

ゲームでは、 RPG 、格闘ゲーム、シューティングゲーム、アクションゲームなどのジャンルによらず、必ず何らかの形でメニューなどの UI を提供することになります。ゲームで提供するメニューでは、銀行の ATM の画面のような、ボタンの押下を待つだけの、ただのボタン表示の並び……のような画面はまず絶対に許されません。メニューは登場からして必ずアニメーションし、気持ちよく、かつ、ユニークに動き、背景もアニメーションし、カーソルが当たっているだけでもレスポンスしなければいけません。ゲーム開発ではあまりスポットの当たらない部分ですが、ユーザーの心証とゲームの操作性を左右する非常に重要な部分です。

RPG ならメニューがそれにあたるでしょう。 FPS なら武器選択を FLASH に。シューティングゲームですら、自分が乗り込む宇宙戦闘機を選択する画面をきっちり作らなくてはいけない時代です。そしてゲーム開発にかかわるビジュアルスタッフにはそういったメニューを作り込む能力があります。また、プログラマからしてみれば、オーサリングデータさえあればそれを動かすことは決して難しくはありません。

ツールとしての FLASH 製作環境

問題は UI を担当するビジュアルスタッフにどうやってオーサリングデータを作ってもらうかです。 UI ですからユーザーの入力に対するレスポンスを作る必要があり、単体のアニメーションの集合体というわけにもいかず、また作り込みプレビュー環境も必要でしょう。求められるのは、ツールとプレビューを（できればPC上でそのまま）シームレスに実行することができ、実機でも簡単に確認できるような製作環境です。内製ともなれば当然ツールにも再生エンジンにもバグが出るでしょう。そういったバグを速やかに修正できれば、よりいっそうクオリティの高い製作に打ち込むことができます。

ところが、現実的にはゲームプログラマの大半は、ゲームルールの実装や、ゲームの描画、演出、アクション、物理演算や群集制御、メモリやロード周りなどのゲームやライブラリに駆り出されているのが実情です。また、ゲームの実装のバグは比較的速攻で叩き潰しますが、ツールのバグ修正はそれに比べれば後手に回りがちです。ミドルウェア開発部門のある会社（ゲームの開発とツールの開発が分離している会社）でも、必ずしも理想的な対応ができるとは限りません。

解決策は二つあります。ひとつはあくまで内製を貫き、現代で求められるレベルにスタッフ（＝人件費）が一丸となって応えようという製作体制を敷くことです。これは、オーサリングを含む UI 関係の作業を 3D やサウンド、AIに並ぶプライオリティまで引き上げ、PS1→PS2→PS3→PS4などのマシンの進化にあわせてきちんと強化して保守していくことを意味します。もうひとつの解決策は、同様の主旨のツールが吐き出すデータを読めるようにしたり、 FLASH などのミドルウェアを導入して組み込むなどして、他のメーカーがコストをかけて開発し完成度を高めているツールを導入（流用）することです。

第５世代(PS1)までのゲーム開発では前者の選択肢しかありませんでした。第６世代(PS2)あたりから、そういう話が出るようになったのではないかと思います。

以下のビデオは FLASH 対応 UI 専用ミドルウェア ScaleForm GFx を使用してメニューを実装したゲームのメニューの様子です。

描画は独自

フリーソフトウェアの環境で使用できる例としての Hikari は未知数ですが、実際に製品レベルで使用できる ScaleForm GFx などの組込 FLASH の場合は、描画は独自に実装できるようです（というより、各ゲームには各ゲームのコアプログラムやレンダーシーケンスがありますから、勝手に描画されては困ります）。

たとえば、ベクターデータを描画するとなれば、精細な描画には限界がありますが、テクスチャを動かす場合などには、ゲーム用ハードウェアのビデオ能力を使いやすいので、半透明にするなり光らせるなりすることができます。また、 FLASH で動きをつけた動きの情報を取り出して、 3D 空間上のスポットライトにバインドするという活用方法もあります。メニューのバックグラウンドに抽象的な３D映像を用いている場合、この方法でメニュー操作とバックグラウンドを同一のオーサリングデータからコントロールさせることも考えられます。

今後は MS の Sliverlight なども選択肢に入ってくるかもしれませんし、 FLASH などの機能がバージョンアップしてくれば、他のことに使えるかもしれません。なんにせよ、ゲームの世界では「動かない一枚絵」を貼付けることはもはやあり得ないので、描画に載せればビジュアルスタッフの意図どおり適切にアニメして、最後まで調整が利くという点で FLASH は強力な選択肢として今後もゲーム開発に深く関わってくると思います。３Dのオーサリングデータなら作る方法はいくらでもあるけど、２Dに関しては決定打がなかったので、そこにここ数年で FLASH が食い込んできた……という状況ではないかと感じています。

Hikari

2008-09-05T02:00:00.008+09:00

Hikari は、 OGRE3D で Flash を扱えるようにするためのアドオンです。flash.ocx アクティブXコンポーネントが必要なため Windows 専用ということになります。単に Flash を再生するのではなく、最近ゲーム業界でトレンドになりつつある「 UI や 2D を Flash でデザインして、ゲームプログラムにバインドする」という実装が可能になる、きちんとした作りのアドオンです。

（今のところオーバーレイ限定で、テクスチャレンダリングには対応していないっぽいですが、普通に十分でしょう）

デモではスライダやカラー選択の値をビューポートの値に反映させています。また FPS 値を Flash 側に送って Flash の機能で値を表示しています。つまり Flash 側の値を取れるし、 Flash 側に値を送ることもできるということです。

アドオンの組み込みも非常に容易で、プログラムもしっかり作られています。きちんと日本語で紹介したいという気持ちはありますが、まずは第一報まで。
（フォーラムではだいぶ前から話題になってましたけど）

Shoggoth から SceneNode::getWorldPosition() と getWorldOrientation() がなくなった

2008-09-03T23:43:00.001+09:00

リリース候補版として検証が続いている Ogre 1.6.0 RC1 ですが、 SceneNode クラスからワールド空間における座標と姿勢を取得する getWorldPosition() と getWorldOrientation() が取り除かれ、 1.6.0 に乗り換えた開発者がコンパイルエラーを起こすというトピックが立っています。

'getWorldOrientation' : is not a member of 'Ogre::SceneNode'

Changelog によると Renderable インターフェイスからこの２つのメソッドが削除された（Renderable はエンジン側ではフルトランスフォームマトリクスでしかやりとりしていなかった）のに併せて SceneNode からも削ったとのこと。_getDerivedPosition() と _getDerivedOrientation() を代わりに使うようにということです。

1.4 系はまったく追えていなかったので知らなかったのですが元々 Eihort で deprecated 扱いになっていたそうです。 getWorld* は _getDerived* の完全なエイリアスということで、使用にあたり問題はありません。ただ、 SceneNode を NULL ノードとみなして計算結果を抜き取る用途を多用するスタイルの自分にとっては getWorld* メソッドがなくなったことで、別のやり方をとれと言われてるようで、ちょっと気になるところではあります。

専用のノードクラスを作成する？　タグポイントだけのボーンをアタッチしてそこから情報を取得する？　……パフォーマンス的にはおとなしく _getDerived* ですね。(^^;

とはいえ getWorld* はこれまでも _getDerived* が畳み込まれていたはずなので、自前で付け足すだけでも大丈夫です。 prebuild SDK でも .h の変更だけで済みます。

OGRE 1.6.0RC1 ('Shoggoth') Released!

2008-08-31T11:03:00.006+09:00

OGRE 1.6.0 RC1 （コード名 'Shoggoth'）がリリースされました。主たる追加機能はこちらです:

新しいよりパワフルなスクリプトコンパイラ
OpenGL のジオメトリシェーダー
Windowsと同等のレンダーテクスチャにおけるアンチエイリアシング
sRGB ガンマコレクション
アルファの適用範囲をサポート
シーンマネージャの新しい 'ポータルコネクトゾーン'
シャドウマップの並列分割をサポート
タンジェント生成を強化
骨格ブレンドのマスク
背景ロードの新しいオプション
カスタムメモリアロケーターのサポート

数日後にビルド済み SDK も出るようです。

マテリアル定義やパーティクルエフェクトの定義に使っていたスクリプトに新しいフィーチャーが加わりました。この機能に関する調整（使用の有無）は OgreConfig.h の OGRE_USE_NEW_COMPILERS で選択できます。マテリアル管理まわりはかなり強化されていて、GPUに送れるシェーダパラメータもかなり増えました。

もうひとつの興味深いパワーアップは "ポータルコネクトゾーン" のサポートで、視野クリッピングの情報をレベルに埋められるようになりました。屋外から屋内への切り替えなどが楽になります。プラグインの説明に使われていた動画はこちら:

逆に驚いたのがメモリアロケーターの変更がこれまでできなかったという点です。知らなかった……
これで日本人が大好きな自前ヒープが作れます。

引っ越しでフリーソフトにかけることができる時間が大幅にアップしました。これまで各フリーソフトの活動に復活する復活するといいいながら、マッハの勢いで遠ざかっていましたが、今度こそ復活しようと思います。

"Education & Help" 初稿が（ほぼ naao さんと kilica さんだけで）完成

2008-08-23T19:04:00.007+09:00

以前こちらのブログでも案内しました Education & Help 計画が、（ほぼ naao さんと kilica さんの手で）ロンチしました。
（お二人 + jidaikobo さんたちの死闘のログはこちら）

集めるだけでも半端ないですが、整理して草稿に入力される作業も半端なかったと思います。;;
お疲れさまでした。

お前は何やってたんだと言われそうですが、すみません、今日は kilica さんが整理されておられる間、用件があって外出しておりました…… orz

ということで、もう少し他のセクションと合わせて整理したり順番を入れ替えたりして、ファーストリリースに備えたいと思います。
ご感想は是非ディスカッションボードまで！

The first release of the official website?

2008-08-22T08:40:00.002+09:00

開発のページの構成もblender.orgをモデルにしたいなと思っていましたが、そういえばWiki整備のときも似たようなことを言っていて、作成が途中段階でした。今回はWiki版のダイジェストでいいでしょう。(^^;

とりあえず暫定でも何でもいいので、全ページを埋めて"オフィシャル"ウェブサイト設置の告知を出して、とっとと開発に戻りたいと思います。トラッカーにもレポートとパッチが山積みですし……

しかし引っ越しで、睡眠時間削らなくても２時間フリータイムが確保できるようになったんですが、妻子持ちだとこれでもアウトですよね。

みんなどうやって活動時間確保してるんでしょうか……

追伸.
ホダ塾ディストリ新版リリースされましたね。

GameDeveloperTooks.com

2008-08-21T00:36:00.002+09:00

またひとつ海外のゲーム開発コミュニティに新しいサイトが加わったとのニュースが……

GameDeveloperTools.com ……「ゲーム開発リソースの広範囲なライブラリ」ということで、ゲーム開発に関係するツール、ライブラリ（ミドルウェア）、エンジン、書籍を集めたサイトだそうです。特に書籍は1800冊ぶんのデータがすでに登録済みだそうです！

この手の情報サイトとしては、これまでは DevMaster.net の 3D Engines Database がありました。 3D Engines Database は細かい検索条件を設定できるほか、実際に使用した開発者のレビューを読むことができる優れものですが、統合型エンジンやレンダリングエンジンしか扱っておらず、 AI や物理演算、スクリプトエンジン、ファイルシステムなどのミドルウェアを検索することはできませんでした。
（そういったキーフィーチャーを搭載しているかどうかをエンジンの検索条件に設定することはできました）

僕は、こういった情報を探すときは OGRE Wiki の Libraries のページを見ていました。このページも相変わらずお勧めなのですが、今後は GDT.com も要チェックになりそうです。

Tools のところの Middleware に File Management などが入っているのが渋いですね。今後は 3D Graphics のところに CrazyBump とかが入ったりするのかな……

エンジンも 3D Engines Database にほふり尽くされていると思っていましたが、 GDT.com に登録されている 3D Adventure Studio とか知らないっすよ。こういうのは RPG ツクール同様特定ジャンルのコンストラクションツールになるので 3D Engines Database には登録されていないのかもしれないです。 3D Game Maker とかもありますね。コンストラクションツールオタクとしてはちょっとたまらないです。

チュートリアル等URL収集作戦にきゅブクマ君が参戦

2008-08-13T11:43:00.010+09:00

オンライン自習リソース収集計画（通称 Education & Help 計画）のために、 kilica さんがソーシャルブックマークを準備して下さいました。

これがもっと簡単なオフィシャルウェブサイト（β） URL しこしこ収集作業への参加手段かもしれません。参加するには、

まず kilica さんのサイト「氷川 XOOPS 研究室」でアカウントを作成しログインします。
ブックマークレットのリンクをブックマークバーにドラッグするか、普通にブックマークするかして、使用可能にします。
ネットサーフィンして、「これはブックマークによさそう！」というサイトがあったら、すかさずブックマークレットをクリックします。
タイトルと URL が自動的に取得された状態で投稿画面へ進むので、タグに「チュートリアル」を指定して投稿します。

（ブックマークレットの正式な使い方は、ログイン後このページの一番下を見ると表示されます）

ブックマークレットを使用しない場合でも、「ブックマークを追加」をクリックしてフォーラムを埋めるだけ！

僕もこっちを使わせていただこうかと…… (^^;
Wiki 編集で URL を追加するもよし、ディスカッションボードに書き込むもよし、コメント欄に書き込むもよし、XUGJのフォーラムに書くのもよし、そしてソーシャルブックマークに URL を投稿するもよし。すべては自由です。一番気が楽な方法で参加して下さい。

なお、今件に関する経緯はXUGJのフォーラムを参考にして下さい。

次のBASEは様々なブラウザに対応（予定）

2008-08-13T08:24:00.006+09:00

私達が開発を行っている次の BASE は携帯を含む様々なブラウザに対応するでしょう。そして、それは XCL より軽く動作します。プロジェクトはホビーライフのために XOOPS Cube を開発しています。したがって、携帯電話、 Wii の Opera、PLAYSTATION3 のブラウザ、 iPod touch/iPhone の safari に対応するのはホビーライフをとことん堪能するためには必須事項といっても過言ではありません。当たり前ですが、 Wii を使う時には、 Wii リモコンのボタンを使ってコントロールパネルを操作できるべきです。そして、私達は、より多くの人がハンディキャップなしで一緒に XOOPS Cube のもたらす趣味の生活を楽しめるように（米国リハビリテーション法などの）アクセシビリティのルールに対応しなければならないでしょう。

XCL は"レガシー"なアプリケーションですので、わずかな XCL の開発者が直接モバイル対応するために多くの時を費やすのは賢明ではありませんでした。しかし、次の段階（次の BASE）ではこの課題に挑戦します。

しかしながら、 BASE の開発者がすべきことは多くはありません。もし BASE がフレキシブルなテンプレートシステムとフレキシブルなメインシーケンスを備えていれば、マルチブラウザへの対応は可能です。焦点はテンプレートリソースの供給方法にあります。

すべての開発者がすべてのブラウザを持っているとは限りません。同様にすべてのデザイナーがすべてのブラウザを持っているとは限りません。PCのブラウザはダウンロードすれば簡単に揃えられますが、WiiやPLAYSTATION3のブラウザは本体を購入しなければ手に入りません。また、たとえ一人の開発者がすべてのブラウザを持っていたとしても、すべての対応実装を一人に求めるべきではないでしょう。私達にはテーマやテンプレートのために preload のようなユーザーの手元で結合してパッチするような仕組みが必要です。

言い換えれば、 XC はエンドユーザーが複数の成果物を合成することをサポートします。なぜなら、１〜２人で開発される単体のソリューションですべてのテンプレートとすべてのプログラムを実装することは困難だからです。

そのようなパッチファイルは開発者やデザイナーが作成するアーカイブに直接コントリビュートされるべきだと考えるかもしれません。しかし、彼らは市民でありサラリーマンであり家族があるため、しばしば忙しくなり、フリーソフトウェア活動を維持できなくなります。私はパッチメカニズムは私達の世界のために有益で、私達の世界を迅速なものにすると確信しています。

また、私は XCL の既存のモジュールを効率よく次の（他の） BASE へ移植するためのちょっとしたアイデア(?)を持っています。

プロジェクト管理の体制は回復しました。ですから、私は開発の再開に集中する予定です。引っ越したことが、私に自由時間を供給するはずです。

海外のゆっるいポリシーが生む"活動結果"

2008-08-12T00:52:00.005+09:00

先の話の与太話というところですが、 blender.org の Education & Help では、掲示板の書き込みへのリンクを見かけることがあります。チュートリアルへのリンクが、掲示板の書き込みへのリンクってどういうこと？と思われるかもしれませんが、海外のアーティストのフォーラムではときどき、ノウハウやチュートリアルを記事にまとめて書き込む人がいるのです。

XOOPS など、日本の IT 系の掲示板では、そういった書き込みは、嫌がられるとまではいかなくても何となくKY扱いされたり、きちんと形で記事にまとめないと情報価値が出ないという感覚でスルーされることがほとんどではないかと個人的には感じています。
（違っていたら、ゴメンナサイ……）

海外では、こういったことは評価されるアクションのひとつのようです。

そのカキコミの使われ方も、結構おもしろくて、
たとえば、ある個人のホームページにチュートリアルのコーナーがあったとします。日本人の個人のホームページだと、クリックすると、その個人ホームページの中のチュートリアルコーナーが開く……という作りがメジャーだと思います。仮に、そのチュートリアル自体は、元々どこかの掲示板などに書き込んだ記事だったとしても、清書してきちんと自分の記事として焼き直してから自分のホームページの１コーナーに収録する。そうして初めてビジターに提供する、というポリシーでホームページを作っている人が結構多いんじゃないかなと思います。

ところが、海外のホームページオーナーの中には、チュートリアル等をクリックすると、その人が書き込んだ掲示板のトピックにジャンプする……という作りにしている人が少なくないんです。ゲームレビューのリストだけ持って、クリックするとゲームレビューサイトの自分の書き込みにジャンプする！みたいなページ構造にしている人もよく見かけました。いわば自分のカキコミまとめサイトのようなものを自分のホームページとして持っているような形です。

あるいはひょっとしたら、「コミュニティにどうコントリビュートしたか」という足跡こそが、自分のホームページにふさわしい情報だ、という考え方なのかもしれません。

なんにしても blender.org はそういうカキコからきちんとしたチュートリアルコーナーに至るまで、貪欲にお役立ち URL リンク集を収集して Education & Help として提供しています。その blender.org は "Bigger than us!" という書き出しで、「インターネットの世界は blende.org より広大だ！だから有益な情報は blender.org の外にあるのは当たり前。どんどん活用しよう！」みたいなことを言ってます。このスタンスは結構好きです。

この考え方は日本人の強すぎる責任感（チュートリアルコーナーがある以上、ちゃんと清書したチュートリアルを持つのじゃ！さもなくば切腹じゃ！）とは相容れない部分もあるかもしれませんが、「きちんとしたものを作ろう」とか言ってる間に何もしないまま一年、二年と過ぎてしまうのもまた事実。ましてフリーソフトウェア活動なのですから、「ありものにどんどんリンクを張って最初の手間で提供 (^^)」というのは、書く方も読む方もハッピーになる選択だと思います。

ということで、こういうポリシーはぜひパクリ^H^H^H見習いたい！と、そう強く思う夏休み３日目でした。

チュートリアル（他）の URL 収集を始めました！

2008-08-12T00:06:00.007+09:00

結局 OSC2008 Nagoya までに内容の調整も含めて間に合わなかった Official Web Site (Beta) ですが、いま、最後の大項目としてオンラインのチュートリアルなどの URL の収集作業を行っていますので是非ご協力下さい。 m(__)m

なんじゃそりゃ？というこれは、 blender.org の Education & Help のパクリ^H^H^Hオマージュです。ネット上には、掲示板の書き込みから Wiki の１ページ、コミュニティサイトのマニュアルから個人ブログの１エンティティ、個人ホームページの１記事に至るまで、様々な形で XOOPS Cube の活用ガイドが公開されています。そういった URL を集めてリンク集を作り、情報を探す人の手助けをしようというものです。

例によって Wiki ページで URL を収集していますので、「このページは役に立つんだ！」「このページは是非ｘｘする人には覗いてもらいたい！」という URL がありましたら、どしどし書き込んで下さい。真ん中を少し過ぎた辺りにある、「ノウハウ＆ヘルプ」のところで URL を集めています。

自推/他推は問いません。タイトルと URL をセットにして（できれば解説文も込みで）、どんどん有益なドキュメントへの直リンクを張って下さい。今週末あたりからそれのカテゴリ分け作業を始めると思いますので、そしたらまたみんなでカテゴリ分類を考えましょう。
（カテゴリ分けに関しては、最初にディスカッション機能で話し合うつもりですのでそっちも要チェックで！）

またカテゴリ分類に関しては今のうちからディスカッションに書き込んでもらって構いません。たとえば「モジュールインストール」で１カテゴリをつくって、そこに URL を集めたほうがいい！といった分類アイデアは、一人の人間の感覚からは出てこないと思うので、アイデアがあったらどんどん書いて下さい。

ディスカッションにトピック立てづらい！とかであれば、ここのコメント欄への書き込みでも構いません！

# あと各コミュニティで集めて、あとでまとめるとかアリだと思います。僕はとりあえず XUGJ に投稿〜(^^)

Package_Legacy 2.1.5 リリース

2008-07-30T12:45:00.003+09:00

遅くなってすみません、 Package_Legacy 2.1.5 の stable edition を XOOPS Cube プロジェクトページのダウンロードセクションでリリースしました。本来のスケジュールでは先の日曜日にリリースしなければいけなかったのですが、引越しの準備中に iMac の電源ケーブルを失くすという失態で予定通りいきませんでした。orz

2.1.5 は一ヶ月を必要としました。 RC のテストにトライした皆様、お疲れ様でした！

すでに多くの報告と多くのパッチがプロジェクトに集まっています。 2.1.x 系の次バージョンのために作業を続けていくつもりです。

ところで、本格的なプロジェクトウェブページの初稿がもう少しでロンチする予定です。仕事やら、引越しの準備やら、フリーウェアプロジェクトやらでバタバタになっているため、このウェブページに関する全タスクをフォローできているわけではありませんが、ほとんどのタスクは完了済みです。 2.1.5 の作業は終わったので、引越しが終わった後にでもウェブページ関連の作業に復帰する予定です。

以下はリリースニュースの日本版です。

--------

XOOPS Cube Legacy (Package_Legacy) 2.1.5 は現在利用可能です。一ヶ月にわたり RC1, RC2 そして RC3 のテストをしてくださった多くのコントリビュータの皆様、お疲れ様でした。 2.1.5 は 2.1.4 からのマイナーアップグレードバージョンになります。このバージョンはひとつの重要なバグをフィックスし、他にも多くのバグを修正したうえで、いくつかのパッチやチェコ語の言語ファイルを新しく含んでいます。

前バージョンの 2.1.4 は URL の解析まわりでバグがあり、いくつかの AJAX モジュールの動作不良を引き起こしていました。そのため、 2.1.4 にホットフィックスを適用したユーザーの方もいらっしゃると思います。 2.1.5 ではこのフィックスを収録していますので、もし 2.1.4 にホットフィックスを適用した状態でサイトを運営していたとしても、特になんの追加手順もなく、 2.1.5 にそのまま上書きアップグレードできます。

このバージョンは当初 2.1.x 系の最終メンテナンスリリースを目指していたため、可能な限り多くのフィックスを格納しようと、かなり粘って作業をしました。そのため RC のテストスケジュールはかなり長引きましたが、けっこう安定しています。もし Package_Legacy 2.1.x 系を利用中であれば、 2.1.5 にアップグレードしない理由は特にありません（と、思います）。 Package_Legacy ベースのディストリビューションパッケージを利用中の場合は、おそらく近日中に 2.1.5 ベースの新しいリリースに関するアナウンスが行われると思いますので、それを待ってください。

プロジェクトはすでに新しいレポートやパッチをさらなる強化や修正のために受け取っています。引き続き HEAD において次バージョンへのリリースに向けて作業を行っていく予定です。

==2.1.4 から 2.1.5 へアップグレードする方法==
既存の環境を壊さないように、解凍したパッケージから mainfile.php と /install ディレクトリを取り除いてください。次に、サーバーへパッケージのファイルをアップロードしましょう。最後に、コントロールパネル（管理画面）のモジュール管理でアップデートを促す赤いアイコンのついているモジュールを片っ端からアップデートしてください。 Legacy の一般設定を使って、サイト閉鎖状態設定にして、アップグレード中の作業をユーザーさんから見えなくしてしまってもよいと思います。

==Upgrade from 2.1.5 RC, RC2 and RC3 to 2.1.5==
同様に、既存の環境を壊さないように、解凍したパッケージから mainfile.php と /install ディレクトリを取り除いてください。次に、サーバーへパッケージのファイルをアップロードしましょう。最後に、コントロールパネル（管理画面）のモジュール管理で、５つのモジュール --- legacy, user, legacyRender, stdCache と使っているなら pm を念のためにアップデートしてください。 Legacy の一般設定を使って、サイト閉鎖状態設定にして作業してもよいでしょう。

==スタッフ==
- aaki
- fugafuga
- GIJOE
- gusagi
- JardaR
- jidaikobo
- kilica
- marijuana
- MAT
- mikhail
- minahito
- nbuy (aka nobu)
- nobunobu
- okuhiki
- onokazu
- tohokuaiki
- Tom_G3x

==更新履歴（英語）==
[Bug Fix - From Bug Tracker]
- Fix Bug #1950018 - charset Problem in css.php
- Fix Bug #1950017 - PathDisclo in legacyRender/admin/css.php
- Fix Bug #1944713 - PATH Disclosure ? in Legacy_Controller::_parseUrl()
- Fix Bug #1939992 - Invalid xhtml templates in legacy module.
- Fix Bug #1938443 - ID is multiple defined in TplsetList
- Fix Bug #1924223 - The request which includes URL cannot be processed.
- Fix Bug #1971682 - Could not read PM from a removed user.
- Fix Bug #1971718 - cookie path always becomes '/'.
- Fix Bug #1987219 - Remove invalid files from the extra directory.
- Fix Bug #1989801 - cleanup to notice reference variable in class/tree.php.
- Fix Bug #1990481 - Invalid Regexp at User_AbstractUserEditForm class.
- Fix Bug #1992732 - $xoopsConfig doesn't referer mXoopsConfig in some cases.
- Fix Bug #2003440 - X_UACTLINK is missing used in some languages.
- Fix Bug #2008857 - user level empty when editing user whose level not in 0,1,5
- Fix Bug #2010090 - Missing Content-Type in MailHeader by #1729813.
- Fix Bug #2011775 - When a user deletes his account, principal is not created.
- Fix Bug #2017164 - Can't register new account by #2011775

[Other Changes/Enhancements]
- Patch #1868259 - add alt to smaily icons@legacy_xoopsform_opt_smileys.html
- Patch #1897607 - html/install/include/functions.php
- Patch #1961603 - portuguese translations: bug fix and enhancements.
- Patch #1992777 - xoopsmailerlocal.php for zh-tw.
- Patch #2011199 - Czech message catalog for XCL.
- Patch #2016023 - Package Legacy 215rc patch FR and PT typo.
- (Exception Patch) Improve LostPassAction.

引っ越し準備中

2008-07-26T09:38:00.006+09:00

忙しすぎて時間が全然ない……すみません、本当はもっとMLにたくさん（そしてすぐに）返信を書いて、いろんなブログにコメントを書いて、もらったメールに返信して、もらったコメントに返信して、なにより色んなフリーソフトウェアプロジェクトのプログラムを書いたりそのテストや検証に参加したいのですが……とにかく時間がない！

引っ越しを考えている事は前にも書きましたが、ここ１〜２ヶ月くらいはベストな選択肢（いい場所、いい家、いい生活）を探しているような状況で、特別な進展はありませんでした。満足がいくものが見つかるまではこの生活を続ける事ができるだろうという考えでした。今思えばこれは本当に楽観的な予測で、さっさと決めるべきだったと後悔しています。あの頃は選択肢がいっぱいありました。

翻って即決即断せざるをえなかったのは、ここ２週間の生活があまりにも酷かったからです。生活の中で睡眠をどういう位置づけに置けば良いのか分からないという感じで、 XOOPS Cube ひとつとっても、今日はオフィシャルを整備する日、今日は ML にレスポンスする日とテーマを絞り込んでも１日１時間半を確保するのが精一杯。

届くゲームはすべて即積みで、かろうじて SIREN の分割配信についていこうと思いましたが、先週末についていけなくなりました。あの１３エピソード配信は今後のためにも是非その感覚を体験しておきたかったのですが……先週末は世間的には三連休だったわけですけど、なぜそこで投げ出すことになるのか……休んだなぁという実感がありません。

まぁそんなこんなでこの２週間は、３時間眠れれば良い日という感じでした。ちょうど Legacy で一番忙しかった頃と同じような感じで、体調不良のサインも出始めていました。

僕は体力が限界に来ると、３時間くらいしか寝てないのに目覚めがだんだん良くなるんです。「よく寝た」とか「もっと寝たい」というような感覚がなくなってきて、自分の体温を感じない（外はすごく暑いはずなのに、駅で電車待ってても全然暑くない）……というのが、時間的に追いつめられたときに出る症状です。

２０代前半の頃は、これを「俺は体力がある」と勘違いして、ぶっ倒れるまでやってました。最近はさすがにこれが体から出ている赤信号だということは理解できていて、この症状が月曜日から出始めたとき、あぁもうダメだ、今の生活は続けられない、と思い、引っ越し先を一気に決めてきました。これから忙しくなることはあっても、暇になることは絶対にないですからね……

月末には引っ越しますので、この家もあと５日の付き合いです。準備はこれからです。 (^^;
引っ越しそばお待ちしております。 m(__)m

メールくださった方、レスポンスできなくてごめんなさい。読んでます。もそっと待ってください。

ということでほんとにただの「日記」でした。(^^;

Package_Legacy 2.1.5 RC3 Release!

2008-07-20T15:49:00.002+09:00

私たちはちょうどいま RC3 を追加のバグフィックスのテストのためにリリースしたところです。もしこれらのパッチがいかなるトラブルの原因にもならないのであれば、私たちは来週にも安定板をリリースするでしょう。

ところで、新しいフィックスや新しいレポートが 2.1.5 RC1 以降続々と投稿されています。私たちはそれをチェックし、コミットするようにしてきましたが、このままの活動を続けるのであれば近日中に "2.1.5" をリリースすることは不可能です。私たちが 2.1.5 をリリースしようと決心した理由は、 2.1.4 には緊急のホットフィックスが必要だったからです。しかし、私たちの RC スケジュールはすでに１ヶ月に及んでいます。私たちはこれ以上再延期をするべきではないでしょう。したがって、私たちは 2.1.6 をリリースするかもしれません。

LittleBigPlanet

2008-07-11T01:29:00.004+09:00

LittleBigPlanet (LBP) は PLAYSTATION 3 の新規タイトルです。それはパズルアクションゲームプラットフォームであり、ワールドクリエーション可能なビデオゲームです。ユーザーは LBP とともに "Mod" 的な楽しみを満喫することができます。キャラクターとステージを作成し、それをネットを通じて共有することが可能な作品になっています。以下のビデオを見ることが LBP を理解する近道でしょう。

ここにもうひとつのクリエーション型のゲームがあります。そのタイトルは、有名なゲームクリエイターのウィル・ライトが開発する SPORE です。 SPORE において、あなたはあなたのクリーチャーを、クリーチャークリエイターツールで作ることから始めることになります。興味深いことは、セーブデータのフォーマットが PNG ファイルであることです。そこで、クリーチャーデータをブログに画像としてペーストしたり、電子メールで送ったりして、世界中と共有することができます。

それらの２つのゲームは、あなたがキャラクタ、及び、ステージを作成することを可能とします。しかし、これらのゲームの提供機能を越えてに何かを作ることはできません。それは、非常に重要です。多くのユーザーは、その範囲内で、十分に喜びを見いだします。私が思うに、それは、クリエーションツールのお手本です。クリエーションツールは、万能である必要がありません。しかし、それは、サプライズとワンダーを提供しなければなりません。

Mod

2008-07-10T01:28:00.003+09:00

コンピュータゲームが好きであり、日本人でないなら、恐らく、あなたは "Mod" を知っ
ています。

MODを導入することによって、そのゲームソフトのグラフィックエンジン、物理エンジンなどの基本システムを用いて、本編とは別のシナリオやグラフィック、モデル、システムのゲームを楽しむことができる。ファーストパーソン・シューティングゲーム(FPS)やリアルタイムストラテジー(RTS)等のジャンルに存在する。もともとは、よりリアルな銃器・迷彩パターン・銃声・砲声を得ることを目的に、ファイルの差し替えから始まったが、現在ではゲーム側でも、最初からMODも適用できることを前提とした作りになってきている。

MODは有志（そのゲームのファン）ベースで制作され、メーカーが制作し主に商品として発売するものは「拡張パック」や「アドオン」、「トータルコンバージョン」と呼ばれることが多い。 [Wikipedia 日本語版]

"Mod" は開発者を育てます。多くの学生やホリデー開発者がゲームを完成させた経験を持っています。それは開発者の品質保証です。企業はそういったアマチュア開発者を採用します。彼らはプロの開発者と呼ばれない存在かもしれませんが、未経験者よりはるかにましです。

"Mod" はゲームデザイナー、レベルデザイナー、アーティスト（ビジュアル）、そして本格的なプログラミングをまだ始めていないプログラマにとって格好の学習材料です。ゲームデザイナーは彼のアイデアですぐさまゲームの開発に取り掛かることができます。なぜなら、必要なエンジン、必要なグラフィックス、必要なサウンドはすでにそこにあるからです。同様に、アーティストは建築物、地勢、兵隊、武器といったものをモデリングすることができます。それらのグラフィックは本物のゲームにすぐに登場させることが可能です。また、多くのビジュアルツールが無償で開放されています。

いくつかの Mod のためのゲームエンジンはスクリプトプログラミングが可能です。通常、レベルデザイナーがスクリプトを学習してそれを使用しますが、プロのプログラマを育てる第一歩であるかもしれません。そして、彼らが本格的なゲーム開発プログラミングを学ぶことを望むようになれば、使いやすいゲームエンジンや本格的なゲームミドルウェアを入手できる土壌が整っています。無償・有償のエンジンと学習のための入門書がそろっています。

私はそのようなパワーたっぷりの海外の状況をリスペクトしています。それはすべてのゲーム開発者にとっての天国です。

日本では、"Mod"はほとんど知られていません。 "Mod" に限らず、アマチュア開発のすべてのジャンルが、あまりホットではありません。一部の人々が海外からソフトウェアを入手して "Mod" 作りを楽しんでいますが、私はそれが就職に有利であるかどうかは知りません。そのため、日本のゲーム会社は優秀な学生を採用して、彼らを教育します。そういった会社は教育を得意としていると感じます。それは今のところ上手にいっていますが、そろそろ限界かもしれません。

日本人は、何かを作るのが好きです。しかし、テレビゲーム開発者はハードなことになっているかもしれません。あなたは日本にはアマチュアゲーム開発活動は無きに等しいと感じるかもしれません。確かに海外と比較して、このあまりにも非活発な状況は彼らの情熱を失わせるのに十分です。

日本のゲーム会社はこの状況に危機感を抱いています。 IGDA 日本の代表である新清士氏は、アマチュアビデオゲーム開発の熱狂の復活のために「ベーマガ 2.0」を提唱しています。ベーマガって何ですか？　それは日本のコンピュータヒストリにおける重要な項目のひとつです。私は近いうちにこの続きを書くでしょう。

SIREN: New Translation 先行販売

2008-07-09T02:10:00.002+09:00

これは新しい試みです。PLAYSTATION3 の期待の新作である SIREN はブルーレイ版に先行してダウンロード販売されることになりました。あなたはブルーレイ版を７月２４日に 5,980 円で購入することができますが、もしダウンロード版が欲しいならば、１４日に 5,500 円で購入することができます。言い換えれば、ダウンロード版はブルーレイ版より安く、早いのです。

しかしながら、あなたはブルーレイ版で遊ぶプレイヤーより早くこのゲームのエンディングを迎えることができるとは限りません。なぜなら、あなたが SIREN のダウンロード版を手に入れたとき、このゲームの大部分はロックされているのです。ロックは時間とともにアンロックされます。そして、ゲームの最後のパートは７月２４日にアンロックされます。あなたはブルーレイ版が発売されるときまで、このゲームをクリアすることはできません。

あなたはこのモデルについてどう思いますか？　私はこのモデルから自分がどういう感想を持つか体験してみたいと思っており、ブルーレイ版ではなくダウンロード版を購入してみるつもりです。しかし、このゲームは非常に恐ろしいです。私はこのゲームを買うでしょうが、恐怖でプレイできないかもしれません。 :D

汎用レンダーシーケンス (2)

2008-07-05T17:39:00.002+09:00

ここで XOOPS Cube コアのレンダリングについてもう一度みてみましょう。 XOOPS Cube コアでは、「CMSがテーマのフォーマットをデザイナーに強制しない」という前提条件で作られています。フォーマットを新作するためにはプログラムが必要ですが、交換できないよりずっとマシです。

XOOPS Cube コアは「描画機構:レンダーシステム」と「描画対象のバッファ:レンダーターゲット」を抽象化して扱っています。レンダーシステムとレンダーターゲットはメインシーケンスの統括的コントロールとは無関係に、独自に使用できる必要があります。

一方、レンダーオペレーションは、「レンダーシステムとレンダーターゲットをどう使うか」という、汎用レンダーシーケンス専用の指令データです。コアの汎用レンダーシーケンスがレンダーシステムとレンダーターゲットを自動的に使用するため、プログラム側でこれらの要素に直接アクセスする必要はなくなります。

ただしアクセスを禁じるわけではありません。汎用レンダーシーケンスは、上位の「シーケンス」の仕組みであり、レンダーシステムとレンダーターゲットは、下位の「レンダリング」の仕組みです。どちらも利用可能です。

XOOPS Cube Developers Group Japan のメーリングリストで onokazu さんが鋭く指摘したのは、「レンダーオペレーションと同主旨のメンバをレンダーターゲットが持っている」という点です。

対 Legacy 用の XOOPS Cube 0.9 にはレンダーオペレーションという仕組みはなく、レンダーターゲットがその役割を兼ねていました。

Legacy で重視したかったことに、アトリビュート（テンプレート変数）のリセットがあります。 XOOPS2 には先に登録されたテンプレート変数を、後のレンダリングが参照するというテクニックがありました。しかし、 Legacy は XOOPS Cube コアの交換式レンダーシステムに対応しているため、レンダーシステムＡで使われた変数にレンダーシステムＢがアクセスできないという問題(?)があります。 Legacy では同じレンダーシステムでも原則変数は引き継がないという仕様で操作感の統一を図りました。

もしこれが３Ｄプログラミングなら、そのような利用（パラメータの預けっぱなしを活かすことも、それでつまずくことも）はプログラマの責任です。しかし、私達は、XOOPS2 の経験を持つプログラマに対して、レンダリングが他のレンダリングのテンプレート変数にアクセスできないことを明示する必要があると考えました。そこで Legacy はレンダリング後にテンプレート変数を消去する仕様を持つに至りました。

この仕様の実装にあたり、Legacyでは、レンダーシステムを直接制御するのではなく、レンダーターゲットにリクエストを入れて送るという方式を取っています。レンダーシステムのアクセスは Legacy 側で行うことがほとんどでした。言い換えれば、「Legacy は非汎用のレンダーシーケンスを持っている」です。このとき、ターゲットが Legacy 非汎用レンダーシーケンスに対するレンダーオペレーションの一種として機能していたわけです。

Cube コア 1.0 では、レンダーオペレーションの導入とともに、この部分を正しく分離して仕上げる必要があるでしょう。結果として、システム、ターゲット、オペレーションでかなり明瞭なクラス分けができると思います。

汎用レンダーシーケンス (1)

2008-07-01T00:56:00.008+09:00

XOOPS Cube 1.0 コアには、汎用レンダー（描画）シーケンスが用意されており、1.0 の主要な検証項目の一つになっています。

私達は既に非汎用なレンダーシーケンスを知っています。 Legacy のレンダーシーケンスがそうです。 Legacy のレンダリングプロセスは XOOPS2 と同じステップを持たなければならず、以下のようになっています。

(1) モジュールの実行前に、ブロックを描画する
(2) モジュールの実行後、モジュールを描画する
(3) モジュールの描画後、最終出力としてテーマを描画する

このようなレンダリングの手順を汎用的にしたものが、 XOOPS Cube コア 1.0 の汎用レンダーシーケンスです。

XOOPS Cube コア 1.0 のレンダーシーケンスは、すべてのビジネスロジックの後に実行されます。そして BASE が交換可能というコアのフィーチャーに対応するために、コアはブロックやモジュールなどの特定のコンテンツ単位を認識しないようになっています。

レンダーシーケンスにとって、テーマ、モジュール、ブロックといった単位は必要ではありません。重要なことは、レンダリングの順序と、後ろのレンダリングプロセスが前のレンダリング結果（もしくは他のレンダーターゲット）にアクセスできることです。たとえばテーマは、ブロックやモジュールの描画結果を合成しなければいけません。

Legacy の非汎用的なレンダーシーケンスでは、最後にテーマを描画するために、最後にロジックが実行されていました。しかし、汎用レンダーシーケンスでは、一番最初に CMS のタスクがテーマのレンダリングを行うリクエストを出しても、実際のレンダリングは最後行うことが可能になっています。

つまりビジネスロジックの実行順と、描画の実行順を変えることができるのです。

メカニズムをチェックしてみましょう。例のPDFドキュメントも一緒に読んでみてください。

汎用レンダーシーケンスは、同じく汎用のメインシーケンスであるタスクシステムと同時に使うことを前提としています。これは非汎用のメインシーケンスは、 Legacy のような非汎用のレンダーシーケンスを持っているからです。

XCube_Root のメインシーケンスは、各タスクからレンダーオペレーションを収集します。レンダーオペレーションには、使用するレンダーシステムの名前や、描画の順序を示すシーケンス ID が収められています。

レンダーオペレーションは順不同（out-order）に収集されます。たいていの場合、最初のタスクは CMS のタスクであり、テーマの描画リクエストがオーダーされる可能性があります。

そのまま何もしなければ、いくつかのモジュールやブロックは、テーマの描画の後に描画が行われることになります。そのような順序は奇妙です。

そこで、 XOOPS Cube コアは、正しい順序（in-order）で描画シーケンスが行えるように、収集したレンダーオペレーションをソートしています。

ソートによって、正しい順序になりました。ソート後のこの状態は、一種のコマンドキューになっています。コアの汎用レンダーシーケンスは、先頭からひとつずつオペレーションを取り出して描画を行います。汎用レンダーシーケンスを使用する場合は、レンダーシステムとレンダーターゲットの取り扱いはコアに任せることができます。

最後のテーマを描画し終えると、画面が完成していることになります。その様子は、 XCube_PHP4 minahito_sandbox ブランチのサンプルでチェックすることができます。

なお、このエントリは Diff between XC and XCL(X2): Render Sequence の別バージョンになります。 XOOPS2 のレンダリングとの違いについて知りたいなら、 Diff between XC and XCL(X2): Render Sequence も読んでみてください。

2.1.5 RC のダウンロードが未だにゼロな件について

2008-06-25T06:54:00.005+09:00

こ、これは (^^;;

まぁ週末が本番ですよね。
それともカウンタが止まってるのか？

XOOPS Cube Legacy 2.1.5 RC release

2008-06-22T21:17:00.002+09:00

以下はxoopscube.orgに投稿されたニュースの翻訳案ですので、事実に反さない限り自由にコピーしたり翻訳の叩き台にしてもらってＯＫです！

---
リリースが遅れてすみません。

XCL 2.1.5 RC はテストのために利用可能です。 2.1.5 は 2.1.4 からのマイナーアップグレードバージョンであり、おそらくまず間違いなく 2.1.x 系の最後のリリースになります。このバージョンはひとつの重要なバグの修正、いくつかのバグフィックス、パッチを含みます。もしあなたが XCL を利用しているウェブマスターで、有志活動のために少し時間があるならば、 XCL 2.1.5 RC があなたにトラブルをもたらさないかどうかチェックをお願いします。

２週間後にプロジェクトは安定版をリリースする予定です。さあテストしましょう！

2.1.4 から 2.1.5 RC へのアップグレード
現況を破壊しないように、 mainfile.php 、そして、 /install ディレクトリをパッケージから取り除いてください。次に、パッケージのファイルをあなたのファイルにアップロードしてください。最後に、コントロールパネルの「モジュール管理」で赤いアイコンを表示するモジュールにアップデートをかけてください。アップグレードを隠すためにサイトクローズをかけておくとよいでしょう。

スタッフ

fugafuga
GIJOE
gusagi
kilica
marijuana
MAT
mikhail
minahito
nbuy (aka nobu)
nobunobu
okuhiki
tohokuaiki
Tom_G3x

xoopscube.jp will renewal

2008-06-21T02:00:00.012+09:00

「せめて既存のマニュアルへのリンクくらい貼ってぇ〜」
とお願いすること数ヶ月、 xoopscube.jp のリニューアルが決まりました。

うさでき、ひよこむ、 XUGJ へのマニュアルへのリンクがあるのかどうか分かりませんが、どうも独自っぽいです。いやもうユーザーがダウンロードから先のシーケンスに進めるならどうでもいいです！
XOOPS Cube プロジェクトへのリンクはある模様。なんらかの形で souceforge.net Wiki へのリンクもあると思われます。これでチーム体制やコントリビュート等の運営モデルへのドキュメントへの道も開かれることになりそうです。

ご存知の通り xoopscube.jp は一度コアチームの投票で閉鎖を決定して、フォーク後の方針に従ってユーザーコミュニティグループへの委譲を進めてきました。その流れの中で大本命と見なされていたのが「日本XOOPSユーザーズグループ」と「ひよこむ」でした。

しかし結果として閉鎖は覆され、 cube.jp はユーザーコミュニティグループのひとつとして維持され、 onokazu さんと tadashi さんが管理に残りました。その後の展開はご覧の通りです…… orz　いや、管理でみんな死んでたときに特に tadashi さんがハッスルしていた印象が無かったので、残ってどうするんだろうとは思っていたんですが……それ以上に当時は土壇場の転覆劇にむちゃくちゃ頭にきてたので、あまり考えてませんでしたが……

（当時の投票意思決定の仕組みでは特に閉鎖に反対はなかったので、いざ閉鎖実行段階で引っくり返されたときはさすがにドタマにきた）

以前から tadashi さんと xoopscube.jp に行き着くユーザーさんのためにも、リンクを充実させてはどうかという話をしてきました。しかし、オフラインで話をすると、快諾を貰うのですが、オンラインで話を確認すると、ポリシーを持ち出して見事に突っぱねられるのです。だったら最初からそう言ってよ！ (ToT)

既存のドキュメントへのリンクを充実させる事が XOOPS Cube ユーザーのためにならない、という tadashi さんの（オン限定）論調が理解不可能で、オフィシャルウェブページを立ち上げないとまずい、という結論に至ったのですが、結果として onokazu さんがリニューアルを実行に移してくれました。

これはかなり革新的な出来事だと思います。こんな日が来るとは……ありがとうございます！

噂レベルだった管理体制の強化も実行に移されるようです。お流れになったもんだと思っていましたが、ここは tadashi さんが地道に進めてくださったようです。m(__)m

ちなみに tadashi さんはオフラインではものすごい人です。

I'll move

2008-06-20T02:22:00.005+09:00

活動時間確保のために、引っ越します。
いま住んでいるところは長く住んでいて気に入っていて（市内で引っ越ししたこともある）、家賃も安くて、のどかで良いところですが、先週今週で心が折れました。 orz
なにがあったかはまた書きますが、 ToDo を紙に書き出してたら…… (ToT)

すでに家捜しに入っていますので、来月以降、物件が決まり次第引っ越して、生活サイクルを一新したいと思います。
でも今日は寝ます (^^;

なんでフリーウェア活動のために引っ越すんだ、そんなOSS思想家だったか俺はと、心の片隅でホントはちょっと思ってますが、
掛け持ちのプロジェクトも完全にリタイアしており、このまま何もできずに終わったら男が下がります。もう最安値ですけど。
暴走で引っ越します。(-_-;

ただ、暴走は結構ですが、プロジェクト運営モデルの認知度の低さや、 Doxygen 日本語ドキュメント計画のように完全無反応のトピックなどを考えるに、「言い出しっぺの法則」を貫く根性と同時に、諦めずに周知徹底を図っていくマメさなどを客観的に振り返る必要はあると思います。
なにげに tadashi さん級と言われる破滅的な日本語でまったく周囲とコミュニケーションが成立していない点も自分で自分のクビを締めています。 orz

なんか、あーせい、こーせい（こうしたほうがいい）というのがあったら、教えてください。

ということでとりあえず今夜はねます。明日も仕事ですし……

じゃあの。

A first draft of the official web site

2008-06-02T00:46:00.002+09:00

予告していました日本語版の XOOPS Cube オフィシャルウェブサイト草案バージョン１、コードネーム「これはひどい」をアップしておきました。 orz

肝心のインストールガイダンスなのですが、XOOPS Cube Legacyひとつを取り上げて説明を書くと、

Legacy はプロジェクトにおけるBASEのひとつでしかないという前提が崩れるイメージにならざるをえない
ダウンロードでホダ塾ディストリを入れる予定だったが、インストールはたぶん Wiki でなければフォローできない

というジレンマがあって、あれこれ考える前にまずは草案をあげてみようと思ったところ、他にも問題がぼろぼろと……

やはり開発モデルやチームモデルの説明のページを作ったほうがいいかなぁ……
あとディスカッションボードに書いてますが、開発のページは www.ogre3d.org の構成を拝借するより、 Wiki の GET INVOLVED などをコピーしたほうが適切ですね。

ということでディスカッションボードでの議論と Wiki の改変お待ちしております。

How to forward the official web site (beta)?

2008-05-29T23:54:00.001+09:00

オリジナルはこちらです。
原文の英語力のなさ（←言い回しなんかできん）と機械翻訳の精度があらぬことになっている気がしますが、今日も残業で時間ないし結果を恐れずガンガンいきますぜぃ！
（が、本当に必要なエントリ以外は時間取れるまで翻訳更新控えます）

なぜオフィシャルウェブサイトはベータなのですか？
なぜなら、今回は動的なウェブサイトを使わないからです。つまり、私達は、サーバ上で CMS を使いません。サーバ上の CMS の代りに、静的な CMS である RapidWeaver を使う予定です。Sourceforge.net ウェブサーバは、 XCL を動かすのに十分な軽さではありません。私は、オフィシャルウェブサイトのために XOOPS Cube の別の BASE を使うことを計画しています。しかし、その BASE は、未だ開発中です。従って、私達は、少なくとも 3 ヶ月くらい RapidWeaver を使うでしょう。更に、私達は、他の CMS を研究する必要がありますので、 RapidWeaver をよく使うことは有益です。

どうやって進めますか？
私は、公式のウェブサイトの草稿を日本語の sf.net Wiki の専用ページへ６月１日に投稿するでしょう。最初の草稿が日本語で書かれる理由は、私達は日本のトップページランクであり、そして、ユーザーのために十分な情報を準備できる状況ではない xoopscube.jp の代替として、不可欠の情報の準備をしなければならないからです。

最初の草稿が私の貧弱なドキュメントから第二段階の草稿に修正されるので、２週間は日本語から他の言語にページを翻訳しないでください。最初の草稿を翻訳するために時間を使う必要はありません。更に、日本版には、日本のウェブサイトとのリンクがあります。そのため、英語と日本語の両方を得意とするコントリビュータが第二段階の草稿を英語に翻訳してくれる予定になっています。それから、英語版を共に改良しましょう。

英語版と日本語版が少しの差異を持っていることは構いません。私のお粗末な英語は、ダメージをコミュニティに与えました。しかし、英語と、日本語の両方を得意とするコントリビュータは、バランスをとるでしょう。いずれにせよ、プロジェクトがアクティブメンバーとコントリビュータに満たされている現在、私達は古い方法と異なる新しい方法をとることができます。

オフィシャルウェブサイトはフォーラムを持ちますか？
いいえ。私達のフォーラムは既にプロジェクトページに存在します。そして、各言語版は、エンドユーザーに xoopscube.org のようなローカルコミュニティへのリンクを提供します。プロジェクトの役割がソフトウェア開発であるので、私達は、ウェブサイトを小さい状態に保つでしょう。しかし、次のウェブサイトは、静的な１枚のウェブページでありリンクしか持たない現在のページより、はるかにまともです。

どういうウェブサイトをゴールとして思い浮かべればいいですか？
それは、フォーラムを持たない www.ogre3d.org と若干の bleder.org です。ご存じのように、 XOOPS Cube は、基礎的アーキテクチャ、及び、プロジェクトモデルのために OGRE3D を参考にしてきました。私達のプロジェクトは、アナーキー方針であり、 OGRE3D とは異なります。しかし、それぞれのオフィシャルウェブサイトで提供するべきである情報は、同等です。

英語版は日本語版にフィードバックされますか？
はい、もちろんです。２つの版は、表現に関して多少の違いを持っていても構いませんが、それらの基礎的なものは、同等でなければなりません。

草稿の内容をどこで議論すればよいですか？
Sourceforge.net wiki は、コメント機能を私達に提供します。その機能は、良いディスカッションボードです。英語の草稿ページが作られた後で、我々は、コメント機能でそれについて論じることができる状態になるでしょう。

（追記）sf.net wiki のディスカッションボードはそのページの言語と英語を使ってOKです。日本語のページでは日本語を使ってガンガン意見交換してください。

英語から他の言語に翻訳してもいいですか？
はい。それは、自由です。私達のウェブサイトは、 GFDL 、もしくは、他のフリーライセンスの下にあるでしょう。従って、あなたは、あなたが望む場所 --- xoopscube.sourceforge.net か各ローカルコミュニティ --- へそれを翻訳できます。

しかし、ソフトウェア翻訳サービスによって翻訳元を読むことは、悪いアイデアです。英語版のみから翻訳してください。恐らく、英語版は、確実でしょう。他の言語版が言語圏内の各国や法律のために、特別な表現やリンクを保持しなければならないため、そのようなページは、翻訳ベースとして良くありません。

私達は、日本版からスタートしますが、最終的には、日本版は、日本独特の情況のために良い翻訳元にならないでしょう。

日本版追記:「公式」ですか、「オフィシャル」ですか？
「公式」と名のつくものに政府・地方自治体などの公的機関と同質の存在を求めたユーザーがいた（←マジ）過去のことを考えれば、オフィシャルサイトと書いたほうが無難かなと考えているヘタレです。しかし、公式はどこか？と尋ねられたり、全角２文字で表現したかったり、口頭で舌がもつれそうになった場合は公式と呼んでもらって構いません。

The Report of XOOPS Cube study session #1

2008-05-25T20:28:00.003+09:00

halt 氏（日本において最もポピュラーな PHP プログラマのうちの 1 人であり、クールガイ）は、 XOOPS Cube の概要を知ることを望む初心者のために第一回 XOOPS Cube 勉強会を主催しました。私と龍司さんは、彼のセッションを手伝うために、このイベントに行き、そして、初心者にとってのプロジェクトの問題点を知りました。

多くの日本のユーザーは、 xoopscube.jp が XOOPS Cube の公式サイトであると認識しています。
彼らは、 xoopscube.sourceforge.net 、 XUGJ 、及び、他のサイトを知りません。Google の検索結果でトップに来るものが、彼らにとっての公式サイトです。
入門書が不足しています。そのためユーザーはすべてをネットで調べるしかありませんが、彼らは xopscube.jp しか知らないのです。
彼らは、「うさぎにもできる XOOPS Cube 入門」や XUGJ のように、十分な情報を持ち、そしてサポートフォーラムをもつ他のサイトをまったく知りませんでした。 xoopscube.jp はどのようにインストールし、 XOOPS Cube を活用するかという情報がありません。ユーザーは道に迷います。
インストールウィザードは長いシーケンスであり、サーバー操作に関する高いスキルを要求します。私たちは doc ディレクトリ下のインストールマニュアルが読みやすいかどうか見直す必要があります。
初心者は、インストールマニュアルの存在を知らないかもしれません。私たちは、どのようにインストールするかのガイダンスの準備をするべきです。しかし、当面の入り口となる xoopscube.jp は、そのようなユーザーに有益なドキュメントを持ちたがらないでしょう。うーん。
初心者は、プロジェクトのスタンスや開発体制を知りません。私は、それらを直接ユーザーに説明する必要がありました。Sf.net Wiki は、それらに関するページを持っています。しかし、ユーザーには、そのページに到達する方法がないのです。

勉強会は、非常に重要な情報を私たちにくれました。私は、第二回の勉強会が開催されることを祈ります。

I'm weary

2008-05-24T01:44:00.006+09:00

ものすごく疲れた……なんだったんだ今週は……

ということで土曜日ですが、 halt さんの勉強会の手伝いにいってきて、そのあと別のグループと飲みにいく予定です。
日曜日は何も無いので、なんとか日曜日中に公式の素案を作り上げて最低でも sf.net の管理 ML に投げておきたい……
なにしろ API リファレンスの日本語版とかの作業もありますしね……

ところで、僕には疲れたときの大きな味方があります。
その味方が最新コンソールで復活するかもしれないという噂が！？

スウェーデン発『シェンムー』がWiiに移植される！かもしれない噂…

シェンムーは本当にいいゲームです、未だにドリームキャスト現役ですもん。
疲れたときはシェンムーIIを起動して香港に行って、怪しい店の売り子をやって楽しんでます。すごく気持ちがリフレッシュできます。
IIのショックは凄かったですね、前作のセーブデータを引き継いで所持金を香港ドルに換金する機能があるのに、ゲーム始めて１０分でかっぱらいに遭って有り金全部なくなるんですもん。あれには驚きました。
その状態で保存して、いつでもロードできるようにして、疲れたら香港に飛んでます。

シェンムーIもいいですけど、疲れたときはシェンムーIIですね。
アナログスティックで視点を変えて、ボタンを押して「お客さん遊んでいきませんか？」と声かけするのが楽しい。

これとファイナルファンタジーXIIは、世界を歩くだけで楽しいし、癒されます。
今日みたいにカープが勝つと最初から疲れも無いんですけどね (^^;

移植されれば嬉しいなぁ
でも描画系全替えでしょ？
Wiiに移植なんて半端じゃないと思いますが……

本当なら嬉しいです。そしてはやくシェンムーIIIを！（無理）

The Official Web Page

2008-05-23T07:51:00.002+09:00

xoopscube.jp は閉鎖する予定のサイトでしたが、現在、２人の管理者と数人の非常勤モデレータによって維持されています。そのためサイトの維持はタフな仕事になっており、ユーザーが XOOPS Cube を使うために必要な情報がない状態が続いています。

日本において、 xoopscube.jp は、 XOOPS Cube に関するトップページランクです。Google は、 XOOPS Cube を xoopscube.jp に使うことを望む初心者を導きます。しかし、彼らは、どのように xoopscube.jp で使用すればよいのか知ることができません

XOOPS Cube には、コミュニティサイトへのリンクがあり、そして、ユーザーをそれらのサイトに誘導します。それによって、 XOOPS Cube は、コミュニティ管理を持つことはなく、そして、コンパクトなプロジェクトを保っています。しかし、 xoopscube.jp は、ユーザーのために十分なコミュニティ機能を準備することができません。

十分なドキュメント、フレッシュなニュース、そして、充実したフォーラムを実現するために xoopscube.jp が（管理で精一杯であり）行動に出ることができない、という現状はプロジェクトの想定外です。 xoopscube.jp の現在の状態は、 xoopscube.jp がトップページランクのサイトであるがゆえに、プロジェクトとユーザーの両方に悪影響を与えます。私は xoopscube.jp が他サイトの既存ドキュメントにリンクを持てばよいのではないかと考えましたが、 xoopscube.jp には彼らのポリシーもあります。私は xoopscube.sourceforge.net のリニューアルが彼らを助けると願うばかりです。

プロジェクトの情熱と、xoopscube.jpの情熱が異なることは不幸かもしれません。しかし、そもそも１０人の管理者でも進展しえなかったものを２人の管理者で進めることは不可能な話です。プロジェクトは何も強制しませんし、彼らは彼らの望むことのみをすることができます。さらに、ユーザーが Google の検索結果から十分な情報を得られないことは、プロジェクトの宿題です。

そこで、私は、当面の間 XOOPS Cube コアの開発を停止することにしました。いずれにせよ、開発のための十分な自由時間をキープできない状況です。その代わりに、 xoopscube.sourceforge.net の公式ウェブページのリニューアル準備に集中するつもりです。プロジェクトは現在アクティブな開発者で満たされています。従ってこのことは 2.1.5 か 2.2.0 ブランチに全く悪影響を与えません。

詳細はプロジェクトのフォーラムをご覧ください。私たちのプロジェクトをコンパクトに保つために、 xoopscube.sourceforge.net は大量のコンテンツを持つことはしません。しかし xoopscube.sourceforge.net と sf.net Wiki をあわせてファーストステップに十分な情報を提供するつもりです。

xoopscube.jp のようなローカルコミュニティは他にもあります。これらのコミュニティは、有志の数が十分ではありません。従って、それらは、十分な情報の準備をし得ません。プロジェクトは、プロジェクトのタスクをこれらのコミュニティに強要したかもしれません。公式のウェブサイトのリニューアルは、コミュニティを助けるでしょう。

Revival of Free Software (4)

2008-05-22T07:55:00.001+09:00

最後に、私が常に XOOPS と XOOPS Cube からフリーソフトウェア精神を感じる理由を書きます。 XOOPS Cube が xoops.org からフォークしたとき、私達は、 XOOPS におけるフリーソフトウェア活動を復興させることを第一の目的としました。それは、フリーソフトウェアの復興であり、フリーソフトウェアの面白さの復興です。

なぜ？　その理由は、 XOOPS が純粋なフリーソフトウェアであったことです。XOOPS 財団は、それを粉砕し、スターリンが好きそうな恐怖の中央集権体制を作り、そして、XOOPS を好きな人のユーザーアカウントを（彼らの愛の形が財団の愛の形と一致しないという理由で）をアカバンします。しかし、 XOOPS が純粋なフリーソフトウェアであったことを忘れてはいけません。

onokazu さんが MyPhpNuke や XOOPS1 の開発に挑戦していたころ、ほとんどの人々はフリーソフトウェアのウェブアプリケーションが「利益の種」になるとは考えていませんでした。彼はあくまで彼の職業のためにプログラムを書く方法を学ぼうと MyPhpNuke と XOOPS を書きました。彼は技術翻訳の職業に就いており、技術要素をよりよく翻訳できるようになることを望んでいました。彼の職業に対する努力が XOOPS を生み出しました。

それは確かにフリーソフトウェアの行動です。

XOOPS は、純粋なフリーソフトウェア活動のうちの 1 つでした。その後、一部の人々はオープンソースウェブアプリケーションが利益をもたらすことに注目し始め、多くの新しい CMS が生まれました。そして、 XOOPS は XOOPS 財団によって傷つきました。現在、 XOOPS は、他の CMS としばしば比較されます。しかし、 XOOPS は、誰もビジネスとタイアップできると考えなかった創世期の CMS のうちの 1 つです。私は、 onokazu さんの偉業に尊敬の念を抱いています。

そして、私達のプロジェクトは、 XOOPS がかつて持っていたフリーソフトウェアの精神の復興です。XOOPS Cube は、スクラッチから書き起こされましたが、財団によって粉砕された XOOPS の精神を確かに引き継いでいます。

Revival of Free Software (3)

2008-05-21T07:52:00.001+09:00

前回のエントリに書いたように、この世のオープンソースプロジェクト全てが情報産業やウェブに関わるわけではありません。日本には、フリーソフトウェアとビジネスの間の関係について一般論を語ることを好む人がいます。しかし、彼らはそのようなプロジェクトを見向きもしません。恐らく、彼らは、そのようなプロジェクトが地球上に存在することを知りません。

各々の開発者は、各々の動機を持っています。誰にも特定のものとして定義できません。一部のジャンルにおける一部のオープンソースプロジェクトが何かを開発者に与えることは確かです。しかし、それは、開発者に対する唯一無二の動機ではありません。この世には次のようなプロジェクトもあるのです:

社会貢献性皆無
金が出ていくことはあっても金が入ることなんてありえない
キャリアプランにもライフプランにも一切影響しない

しかしながら、そのようなプロジェクトに加わる開発者はいます。あなたが心理学者でないならば、そのような開発者の心理を読み解いて解説する必要はどこにもありません。フリーソフトウェアプロジェクトに参加する開発者の動機を定義することは誰にもできません。動機もまた Free なのです。

一部の人々は私に私が XOOPS からどのような利益を得ているのか尋ねてきました。また XOOPS コミュニティのメンバーでさえ、得をすることがあるから XOOPS に関わっているのだろうと尋ねてきました。彼らは私を通じて自分自身を見ていたのだと思います。私の動機が利益だと彼らが感じた理由は、彼らの動機が利益だからです。

開発者は、損することがなければ、得がなくても行動します。

従って、 XOOPS Cube が IT/Web 産業だからといって、 XOOPS Cube の陰謀を邪推するのは無駄な時間です。あなたも私達もそんなことを考えるエネルギーがあるなら別の行動に使うべきです。

LinuxWorld Expo/Tokyo 2008

2008-05-20T23:50:00.002+09:00

LinuxWorld Expo/Tokyo 2008 という展示会が開催されます。このイベントでは最近、 .org パビリオンというコーナーが用意されることが恒例になっており、オープンソースコミュニティが出展できるようになっています。しかし開催日は……平日だっ！ orz

平日でも、ある程度のコミュニティなら何とか出展にあたるメンバーを集められるかも知れません。 XOOPS Cube では毎年 tadashi さんや龍司さんが出展してくださっています。ありがとうございます。 m(__)m

ということでセッションの紹介です（↓）

■5月29日　11:00「XOOPS Cube のイントラ応用事例」
講演者：株式会社RYUS 天野龍司

■5月30日 14:00「NetCommons XOOPS Cube 連携」
講演者：有限会社磯谷商店　長尾正

話によると、この展覧会は当日に行くと入場料が５０００円！！なのですが、事前に Web で予約しておけば無料になるそうです。ぜひ予約してから出かけましょう。

しかし、LinuxWorld というイベントに .org パビリオンというブースコーナーが設けられるのは非常にありがたいことですが、常識的に考えれば、一般的なオープンソース開発者が平日のイベントに出席することはなかなか難しいと言わざるを得ません。このあたり、感謝しつつも複雑な心境です。よくよく考えればこういう平日イベントにはビジネスユースのユーザーが集まりますので、僕ら開発者が行ってもできることは特にないんですが (^^;

そんな感じで、フリーソフトウェアの開発者はまだまだホリデープログラマが圧倒的に多いと思います。これに関して、平日のオープンソース関連のイベントに開発者が集まりにくいのは、開発者の勤務先の会社に問題があるからだとか、開発者の姿勢に問題があるからだ、という声をたまに聞くことがあります。開発者に理解のない会社がおかしいとか、ちゃんと休みを主張しない開発者の姿勢がよくないとか、そういう主旨の話だと思います。

しかし、開発者はおそらく仕事が忙しいから行けないわけではないと思います。個人的には、仕事が楽しいので、仕事とオープンソースのイベントを天秤にかけられないという人がほとんどじゃないかと思うんです。これまでＯＳＣとかでいろんな人と話した実感として。

休みなんて手続きすれば取れますけど、自分の中で仕事を休んでまで出かける動機が見つけられるかどうかです。会社に悪いとか、気が引けるとかではなくて。これは以前ＯＳＣなどで他の開発者とお話した時も同じようなことをおっしゃっていました。

「オープンソースに参加する人は会社の仕事に不満があるのだ」と一方的に決めつけて話しかけてくる人とか実は結構いて、たまにイベントなどで不愉快な思いをすることがあります。しかし、会社の不満をフリーソフトウェアにぶつけるタイプの人って本当にそんなにいるんでしょうか？　１２年やってますけど一人も見たことありません。

たとえば、社会や会社の不満をアルコールにぶつける人もいるにはいるでしょう。しかし、ほとんどの人は人生を豊かにするためにアルコールをおいしく楽しく飲んでいると思います。また、日々が充実していればいるほど、ビールもまたいっそうおいしくなりますよね。オープンソースというか、フリーソフトウェア活動って結構ネアカというかポジティブなものだと思うんすよね。だから、逆に平日との折り合いがつけづらい、ということなんじゃないかと思います。

まぁ確かにフリーソフトウェアの開発者って自分の仕事に対してツンデレな人が少なくない気がするので、誤解を招きやすいかもしれませんが……

そう考えると二日開催はきついとはいえ、平日と休日の両方で開催するＯＳＣはオープンソースプロジェクトにとってはありがたいですよね。

ということで行ける人は LinuxWorld Expo に行っちゃいましょう！

Shine has been banned

2008-05-19T07:28:00.005+09:00

少し前の話題ですが、 xoops.org と xoops.nl で７年間にわたるコミュニティメンバーであり、精力的な活動者だった Shine 氏が "プロジェクトの利用規約に同意しない発言がみられた" という理由で xoops.org からアカバンされました。発端はこれ。リンク集モジュールを探しているユーザーに Wflinks を薦めたのが運の尽きでした。すでに地獄のモデレーター Mamba 氏によって原文は編集されてしまい真実は闇の中ですが、どうやら Wflinks を薦めた際に親切に書き込んだ機能リストに XOOPS よりフォークした ImpressCMS という文字が含まれており（wflinksの最新版が ImpressCMS でしか稼働チェックされていなかった）、 Mamba 氏がこれを削除。投稿を編集されたことに怒った Shine 氏でしたが（当然）、 XOOPS を取り扱うサイトで ImpressCMS という単語を持ち出したうえに反省がみられないということで利用規約に反したことになり、アカウント無効・IP指定によるアクセス禁止処分となりました。

旧日本帝国も真っ青な利用規約の拡大解釈と適用っぷり。相変わらずすぐにアカウントを削除するサイト運営に「xoops.org のポリシーはおかしい」というトピックがあがったのですが、「特定の個人を攻撃する言葉がたくさん含まれている」ということからロック。

たぶんこの暗い話題でサイト全体のトーンが下がっていたこともあり、onokazuさんのXOOPS評議会？とやらの着任を「ジェダイの帰還」と大々的にアナウンスしたのではないかと思います。

そういえば財団が onokazu さんを追い出して Cube がフォークした際にも Cube という単語は「敵性語」として厳しく監視され、何人かアカバン食らっています。一応、その財団は ImpressCMS に去った、ということになっているのですが、正直違いが分かりません。金集めないだけましなのか。

XOOPS Cube study session #1

2008-05-18T13:09:00.005+09:00

な、なななな、なんと、RYUSのhaltさん主催で第1回XOOPSCube勉強会が開催されるそうです！

以下コピペで恐縮ですが:

2008年5月24日(土) 14:00〜17:00
会場: 株式会社ディノセミナールーム
(〒150-0002 東京都渋谷区渋谷3-13-11 渋谷TKビル9F)
募集人数: 20人

第1回XOOPSCube勉強会は「PHPはよくしらなかったり、あまり得意じゃないけどXoopsを使っていろんな事をしてみたい」という人を対象に、技術的な話よりも「何ができるのか」をXoops中心にして勉強する会です。参加費は無料です。

参加条件:

オープンソースに興味がある
Xoops等のオープンソースアプリを使って社内システムを構築してみたい
社内や部署内で使っているグループウェアや連絡ツールに不満をもっている
趣味プログラマや専業Webプログラマじゃない人
いっちょPHPでもはじめてみるか。の人。

不参加条件（このイベントは初心者向けなので以下の条件にあてはまる人は参加しないでください）:

XOOPSCubeの内部構造がしりたい
別に使う気はないけど技術的な興味で来る人

勉強会の進行概要は下記の通り
1. 挨拶 (5分)
- XOOPSCube勉強会の目的等について自己紹介(一人最大3分程度)

2.[発表]グループウェアにSNS。なんでも無料で作れる時代がやってきた
- 「無料で何ができるのか。無料でどこまでできるのか」を中心にグループウェア/SNS/ブログのような事を無料で実現する方法について紹介します

3.[発表]XOOPSCubeって？オープンソースって？
- 今回の勉強会のタイトルであるXOOPSCubeについて紹介

4.[発表]XOOPSCubeをインストールするには
- XOOPSCubeを利用する為に必要なPHPなどのインストール手順について紹介。

5. 雑談、交流など

……ということです。
参加はこちらから。

あの halt さんが XOOPS Cube （しかもLegacy BASEの）勉強会とは、最初ネタかと思いました。
どんな話が出てくるか、正直怖い(^^;
XOOPS Cube は褒められて伸びる子です！

しかし、もう本当に…… Legacy は動くものとしては使えるんですけど、これを持って技術者の人と話すときは本当に……本当に恥ずかしい！
早く次の BASE を形にしないと……

Revival of Free Software (2)

2008-05-17T23:43:00.001+09:00

日本 IT/Web 産業は、好景気です。私達が子供のころは、みんなプロ野球選手になりたがっていました。しかし、いま、若い人たちはウェブサービスのクリエイターになることを望み、努力を続けています。

この国において、 IT/Web オープンソースソフトウェアは、重要な意味を持っています。それは、開発者のキャリアを変化させ、開発者のチャンスを作り、そして開発者の人生に何かを与えます。

オープンソースの成果物は、ビジネス活動に積極的に使われます（ＩＴ産業では）。一部の人はオープンソースはビジネス活動とセットで語られなければならないと考えています。もちろん、この地球には IT/Web に関するものではない様々なオープンソースがあります。しかし、彼らはそんなものが地球上に存在するとは思っていないでしょう。少なくとも iPod で DOOM を動かすことに挑戦するようなプロジェクトは彼らの視界に入っていません。

いずれにせよ活動が活発なのはよいことです。しかし、 IT/Web OSS がビジネス活動に活発に使われたために、 XOOPS Cube は誤解に苦しまなければなりませんでした。

ご存じのように、 XOOPS Cube は、プリミティブなフリーソフトウェア活動のうちの 1 つです。しかし、人々は、そうは考えてくれません。なぜなら、 XOOPS Cube は、ビジネス活動のために使われることになっている IT/Web OSS だからです。

なぜか、最近の日本では、フリーソフトウェア活動は企業やビジネス活動と直接的にコラボレートするべきだという主張があります。

フリーソフトウェアとビジネスの関係は数十年前に結論が出ています。あなたはそれをフリーソフトウェア財団のウェブページで読むことができます。それについて改めて論じることは悪いことではありませんが、たくさんの人がその再定義に時間を浪費する必要はないでしょう。もし彼らが、そのような議論が OSS の発展のために必要だと考えているならば、ぜひ iPod で DOOM を動かすといったエクセレントなプロジェクトを含め OSS 全般に目を向けてもらいたいものです。結局のところ彼らは特定のものを発展させたいだけで、「OSS の発展」という言葉はオブラートとして使っているだけにすぎません。

XOOPS Cube プロジェクトは、だれからでもコントリビューションを受け取りますが、企業と直接的コラボレートは行いません。コラボレーションはフリーソフトウェアプロジェクトの義務ではありません。結果的にこの明瞭かつ昔ながらの方針が、フリーソフトウェアとビジネス活動とのバランスを自動的にとるでしょう。

Revival of Free Software (1)

2008-05-16T23:24:00.000+09:00

日本において、オープンソースはビジネスとともによく論じられます。それは、悪いことではありません。かつて、まだインターネットや「オープンソース」といった言葉が存在しなかったころ、私達は貧弱なモデムで草の根ネットに接続し、フリーソフトウェア活動に参加しました。当時、技術に興味がない人は私達の活動をまったく見向きもしていませんでした。「オープンソース」という言葉が作られてから、全ては変わりました。現在、非常にたくさんの人々がフリーソフトウェアに興味を持つようになり、そして、フリーソフトウェアで何かできないかと考えています。

フリーソフトウェアを通じてビジネス活動をすることは可能です。なぜなら、フリーソフトウェアは、自由なソフトウェアだからです。しかし、フリーソフトウェア活動自体は、ビジネス活動そのものではありません。XOOPS Cube は、プリミティブなフリーソフトウェア活動のうちの１つです。ですから、私は XOOPS Cube がビジネス活動に有益であることを願っていますが、ビジネス活動には一切タッチしたくありません。私達のプロジェクトがするべき唯一のことは、完全なる自由を維持することです。

XOOPS Cube は、パブリック・ドメインにあります。従って、だれでも、何かを XOOPS Cube にコントリビュートすることができます。 XOOPS Cube は、コントリビュータが何者であるかに関心はありません。コントリビュータは、学生、もしくは、企業かもしれません。しかし、それは、全く重要ではありません。プロジェクトは、企業とタイアップすることを考える必要はありません。プロジェクトは、あらゆる人からコントリビューションを受け取るスタンスさえ持っていればよいのです。

繰り返します。XOOPS Cube は、プリミティブなフリーソフトウェア活動です。既存のフリーソフトウェア活動が、私達が進むべき道を示しています。

フリーソフトウェア活動としての XOOPS は、XOOPS 財団のクソ野郎共によって傷を負いました。従って、私達はまずフリーソフトウェア活動としての XOOPS を復興させなければなりません。

Argon took a part in MY FAMICASE EXHIBITION

2008-05-15T23:26:00.000+09:00

わたしのファミカセ展とはなんですか？　これは、非常に非常に面白いイベントです。このイベントでは、NESと共に成長したいろいろなクリエイターが架空の NES ゲームタイトルのラベルをデザインしました。以下のビデオの前半は、「わたしのファミカセ展」が何であるかを英語の字幕で説明します。(あなたは私の貧しい英語を読む必要がないので、幸運です！)

実は、XOOPS Cubeコミュニティのメンバーであり、ホダ塾ディストリビューションのデザイナーである argon さんが、この展示に参加しています。彼は、テレビゲーム業界とアニメーション業界のキャリアを持っています。はい、彼の経歴は、私の経歴と類似しています。

彼の作品は、ウィザードリィに似た「NinthRune」です。チェックしてみましょう！

An ideal software design (2)

2008-05-14T23:27:00.000+09:00

大規模システム/アプリケーションの世界では、仕様書が事前に準備される。基本的に、それは、信頼できる。そのため、ソフトウェア設計者は、プログラムやプログラマのためにプログラムを設計することができる。しかし、大規模システム/アプリケーションは、どちらかというとプログラマではなくプログラムに指向する。なぜなら、そのようなシステム/アプリケーションは、長期間使われるからだ。従って、これらのシステム/アプリケーションは、小さな変更に対応するために柔軟で、そして、拡張性を持つべきである。これらの特徴を実装するために、ソフトウェア設計者は、プログラマの立場ではなくプログラムの立場でソフトウェアを設計する。ソフトウェアは合理的なモジュールに分割される。

それは、非常にエクセレントだ。しかし、それは、全ての場合に有効であるか？

大規模システム/アプリケーションは、ソフトウェアのひとつのカテゴリに過ぎない。この世のすべてのプロジェクトが同じシチュエーションであるわけではない。そこには、期間、目的、規模、サイクル、実行形態（リアルタイムかどうか等）、そして、専門性プログラマなどの要素がある。理想的なソフトウェア設計とは、それらの要素への最適解ではないだろうか。（そしてその設計が設計期間中に書かれること）

そのため、だれかが別の状況からその設計を眺める場合、その設計が良くないと感じるかもしれない。

一部の設計者は美しい設計を探求し、それを正義だと考えている。しかし、ソフトウェア設計は、設計者が彼の人生をささげる芸術ではないし、設計者が楽しむためのゲームでもない。しかしながら、大規模システム/アプリケーションを除き良いガイダンスがないのも事実だ。一部の設計者は、それらのガイダンスをクールと感じ、そして、それをプロジェクトに適用しようとする……

厳しい現実は、あなたの設計を（あなたの考える）理想から遠ざけるかもしれない。その一方で、厳しい現実は時折あなたを最適解へつれていくこともある。

OGRE 1.4.8 [Eihort] Released

2008-05-13T12:42:00.003+09:00

OGRE の新しいメンテナンスリリースが出ました。もうリポジトリが追えなくなってどれくらいになるんだろう…… orz

中を見ていないので翻訳も正しいものではないかもしれませんが、一応訳してみました。

---

コードネーム "Eihort" … 1.4.x ブランチ上では九分九厘最後のメンテナンスリリースになるであろうものが現在ダウンロードエリアで利用可能になったことをお知らせします。

ほんの少しのバグフィックスだけが、今回のレポートです。

ソースリリースと大半の SDK パッケージは既に更新されました。ほかのものは各メンテナが提供可能になった際に更新されます。

このリリースの後、私たちは待望のコードネーム"Shoggoth"こと 1.6.x ブランチ上の新しい安定版リリースに集中するつもりです。私たちは昨年のうちに、多くの新しいフィーチャーや改善されたフィーチャーを加えました。そして、相当な数の人々がそれを Subversion から既に使用中ですので、安定版リリースはそう遠い話ではありません。

v1.4.7 からの変更点:

Mac OS X:

古いマシン、特に初代iMacと古いPowerPCマシン上のわずかな GL ドライバが持つバグに対する回避方法
GLSL頂点アトリビュートエイリアシング問題に対する回避方法

Linux

非整合なGLXビジュアルの使用禁止
一部のLinux NVIDIA 169.xドライバーに関するFBO問題のためのワークアラウンド - このフィックスがあなたの手元で機能しない場合は、フォーラムスレッドにより根本的な当面の回避方法があります

Windows:

D3D9RenderSystem::__SetTextureStageState におけるセーフティチェックは７を上回るテクスチャーステージを無視しなければならない。D3D9デバッグモードで大量のテクスチャーを使用した場合のエラーの原因となりえた。
NOMINMAX宣言をWindowEventUtilitiesヘッダに加えた - windows.h をインクルードしていたため他の Ogre ヘッダの std::min/max と競合を起こしていた
GetModuleHandle呼び出しは、より正しくデバッグプラグインに対処するために修正された。

Terrain:

カメラやビューポートより先に地形を作成することを許可した
地形が見つからないときに assert するだけでなく例外を投げるようにした

Maya エクスポータの頂点カラーを修正 - float4 の代わりに Packged RGBA を使うように
Camera::setWindow() 修正
絶対パス指定における FileSystemArchive::exists のバグ修正
MayaExport の OSX ポートフォンマテリアルのサポート
すべての新しいGLSLカスタム頂点アトリビュート（一部のドライバ上で起こるエイリアシング問題を避けて全カスタムアトリビュートを使う必要がある場合にビルトインとリプレスする）をリストするためにマニュアルを更新

An ideal software design (1)

2008-05-12T23:31:00.001+09:00

通常、私達は、チームがプログラムに手をつけ始める前に、ソフトウェア設計を決めようとする。それは、簡単なブロック図であったり、 UML であったりするかもしれない。多くのプログラマが迅速な開発のためにあなたのチームに集まり始める。あなたがしなければならないことは、ソフトウェア設計である。それのために、あなたは、ソフトウェアをモジュールに分割する。それは、プログラムのための分割設計である。

しかし、あなたの任務は、各プログラマがプログラミングの一部を担当可能な状態を作り上げることである。あなたの設計は、それを実現し得るか？

プログラムの機構上妥当な分割設計と、プログラマに仕事を分けるために妥当な分割設計の間には、ちょっとした違いがある。もしあなたが自分でソフトウェアを設計してそのプログラムを書く場合は、恐らくあなたはこの事実に気づかない。

プログラム上の妥当性のために多くのモジュールに分割された理想的なソフトウェア設計は、しばしば、専門性のプログラマの仕事を妨害する。それは、生産的な開発を始めることを不可能にする。

多くのプログラムの専門的な要素がある --- makefile、メモリ管理、リソース管理、入力装置、ハードウェア制御、コンテンツパイプライン、並列処理、シェーダ、エフェクト、パーティクル、アニメーション、グラフィック、オーディオ、立体音響、人工知能、物理学、幾何学、プロシージャル技術、スクリプト、ネットワーク、デバッグシステム、サードパーティミドルウェア等など……。

これらの専門的な要素を系統的に組み合わせることでソフトウェアを設計し得るか？　ひょっとすれば、それは可能である。しかし、プログラムのために設計した理想的なソフトウェア設計は、プロジェクトに集まるプログラマにとっては悪いニュースである。ゲームシステムは、彼らの知識と彼らのコードの合成物を初期から要求する。そのため、プロジェクトは難航することになるだろう。

Is an Object-Oriented Game Engine necessary? (3)

2008-05-11T15:25:00.003+09:00

極限まで抽象化された概念であるところのゲームオブジェクトはおそらくもともとは画面への描画の最小単位として使われることで意義をもっていたのではなかろうか。要するに昔はオブジェクトがそれぞれ単純に自分自身を自分自身に基づいて描画するだけで画面が描画でき、単純明快な一部品として扱えていた。しかし、例えば最近のシャドウマッピングなどのマルチパスレンダリングが主流になってくると、自分自身を描画するときに自身や他のオブジェクトがすでに描かれたテクスチャがあることを前提としなくてはならない場合もある。描画するだけでも他のオブジェクトの描画結果に依存する必要がでてきてしまった。また、テクスチャを参照する必要がなかったり、透明度を無視してもよかったり、描画する内容も複数の描画指示のあいだで全く異なる。スーパークラスのポインタを渡してのんきに描画命令がとどくのを待つだけというわけにはいかない。描画処理の全体の流れの中のどこでなにを描画するか言及する必要がでてきてしまった。

描画処理の側面からみてももはやゲームオブジェクトはすべてが全く同じものだとはみなせない。

[描画でさえももはや構造化できない - 作業記録]

経緯としては指摘の通りなのですが、個人的にはゲームオブジェクト的なものと描画はかなり前の段階から切り離しが始まって、（今風に言うと）緩やかな結びつきで処理することがトレンドになってきているような気がします。それはつまりそれぞれ担当するプログラマが別人になったからとも言えるのですが、ゲーム上の処理は処理、描画系は描画系というノリが主流だと思います。
（といっても会社によって違うので何とも言えない）

昨日、「ゲーム・ビジネスロジック的ななにか」はタイトルに特化するので C++ の"再利用面"における有効活用はないんじゃないか、ということを書きました。しかし、僕は逆に描画系や３Ｄのシーン管理の部分は再利用性を生かして、なんとかミニライブラリに体系的にまとめられないものかと、ここ２〜３年くらい考え続けています。

たとえばシーンや、座標・座標と姿勢を持ち最終的にマトリクスに情報を出せる存在というものは３Ｄゲームなら必ず扱う概念です。ここに再利用性を持ち込む意図は、生産性のための再利用ではなく、フィーリング（あるいはモデルと言い換えてよい）の再利用です。ゲームの開発は「同じものを何度も書くのは馬鹿馬鹿しいからライブラリ化する」ほどスパンが短くありませんし、同じような物をタイトル毎に様子を見ながらコードをブッコ抜いて作る……という行為も高い効果を持つ一面があると思います。また、ハイエンドコンソールとそうでないコンソール、ポータブルマシンでは実装が変わってくることもありますから、どこかで手を動かす必要はあります。

ですから、あくまでフィーリングを揃えるための再利用というわけです。たとえば、 XML の DOM は C と C++ では使い方が全く異なりますが、フィーリングは一緒です。 C++ にも多くの種類の DOM がありますが、使い方が違うだけで根本にあるモデルは同じです。

少し極端な例えですが、そのような形で描画系やシーン管理、あるいはリソースマネジメントにはっきりと再利用のための C++ の活用を実践できないかと考えています。が、それも前述の方が書かれているように……どういう絵作りをするかでまったく手順が変わってくるので、やはりタイトル特化のアーキテクチャは避け難いですよね……これの単純な解法は、存在するんですが、パフォーマンスが……

そういう意味では（負け惜しみだけど）海外勢は似たようなものをよりゴージャスに作り替えていくことで次のタイトルを出す、という市場の形があるから、エンジン部分の再利用を促進できている部分があると思います。

たとえば、日本はＲＰＧでもタイトルごとに文法が違いますよね。ドラゴンクエストIIIを再利用してドラゴンクエストIVは作れそうですが、ファイナルファンタジーXIIを流用してドラゴンクエストVIIIを作るのは難しいでしょう。しかし、海外はＦＰＳといえばこうだ！という形がしっかりできあがっています。ここに一度作った物を広く再利用する市場があるんじゃないかと思います。

海外の方がゲームプログラムの設計が進歩的だから生産性が高いとよく言われますが、個人的には、ユーザーの厳密なジャンル認識の下、割りきりの基準ができつつあるのと、ＦＰＳのように明確な仕様のジャンルが大きな市場で存在しているため、日本よりそういったことがやりやすいからではないか……と考え初めています。

日本だろうと海外だろうと、タイトル or システムに対してその描画系は特化してしまう傾向。そして、抽象度を高めるとパフォーマンスが落ちてハイエンド部門の競争ではキツくなる……といったコンポーネント化へのジレンマは同じものを抱えているのではないかと考えています。

Is an Object-Oriented Game Engine necessary? (2)

2008-05-10T01:11:00.002+09:00

では、理想的なオブジェクト指向言語における理想的なゲームオブジェクト設計とは何だろう？　私は、良いゲームオブジェクト設計は、前時代に完成されたと考える。ビデオゲームプログラミングは、当時からオブジェクト指向設計の要素を実装してきた。

当時のビデオゲームプログラマがオブジェクト指向のプログラミングを実現することを望まなかったことは、重要である。彼らは、生産的な開発とエキサイティングなゲームを追求してきた。そこに我々が学ぶべきである何かがある。

現在、私達は、十分な仕様のオブジェクト指向プログラミング言語を用いることができる。私は、前のエントリで、それが私達のゲームオブジェクト設計を狂わせる原因であると書いた。しかし、当時のビデオゲームプログラマは、 C++ (Cも!) を使えなかった。従って、彼らは、マシン語を用いた。私が最初に加わったプロジェクトは、アセンブリで書かれていた。そのような条件下で、プログラマは、オブジェクト指向の設計を追求することはできない。従って、その設計は、自然とゲームのために良いバランスになる。

見てみよう。私達が使った技術は、タスクシステムである。もちろん、ビデオゲームプログラマは、 C++ と共に今この手法を使っている。しかし、当時のプログラマは、アセンブリでタスクシステムを書いた。従って、現在の手法と当時の手法には違いがある。

タスクシステムは、ポピュラーなビデオゲーム開発方法のうちの 1 つである。それは、データ格納とジャンプアドレス群から成る原始的なメモリブロックである。振る舞いを変更するには、ジャンプアドレスを書き直す。コールバックされたコードは、オフセットアクセスによってメンバーデータにアクセスすることができる。既にポリモーフィズムは実現していた。そこには「型」がない。しかし、それは、 C/C++ のコンパイルされた結果と類似している。現在、私達は、 C++ でこれを書く。C++ は、 vtable という概念を持っている。従って、もっとうまくポリモーフィズムを実現することができる。

一方、私達のプロジェクトは、タスクブロックが他のタスクブロックのジャンプアドレスにアクセスすることを禁じた。つまり、私達は、ゲームオブジェクトの間のメッセージ通信を禁じた。

タスクブロックが他のタスクブロックのジャンプアドレスにアクセスすることは、安全ではない、なぜなら、型がないからだ。C++ は、もう少しうまくそれを扱うことができる。なぜなら、私達は、 C++ でダウンキャストを比較的安全に書くことができるからだ。しかし、それは、同じくデバッグしにくい。私達がそれを禁じた別の理由は、私達はそのような方法からメリットを発見できなかったからである。

子供タスクは、自身のものをコントロールする。しかし、これらのタスクが他のタスクと仕事をする必要がある場合は、子供のマネージャ役である親タスクにまとめて仕事をさせた。私は、この方法が私達への最適解であるかどうかを知らない。しかし、それは、デバッグ、調整、調節に易く、そして、変更のために柔軟であった。

当時、私達の周りには「オブジェクト指向」という言葉がなかったので、私達は、それを追求しなかった。プログラマの自己満足が、ゲームオブジェクト設計の秩序を乱すこともなかった。

Is an Object-Oriented Game Engine necessary? (1)

2008-05-09T23:31:00.002+09:00

なぜわざわざゲームオブジェクトクラスなんてつくって下方へ特殊化するクラスヒエラルキーをつくるんだろう。オブジェクト同士の連絡では、オブジェクトリストを持つ方は信号を伝達するだけで、ダウンキャストなりの特殊化はオブジェクト群のそれぞれの内側で行われるような運用をされる。か、もっと無茶をやる。

(snip)

ゲームルールはゲームオブジェクト同士の交互のやりとりを全体として眺めた状態を完全に規定する。プラグイン系のようなゆるい統合ではやっていけない。完全な記述が求められる。新たな種類のゲームオブジェクトが追加されるとしたら、全ての既存のゲームオブジェクトに対する反応が完全に新たにおこされてなくてはならない。ひとつのピースが残りの全部のピースとの接合部をもっている多次元ジグソーパズルだ。無機的な構造物と比べてここが全く異なっている。

[ゲームオブジェクトを一般化して管理しないことの妥当性について - 作業記録]

私は、彼の葛藤を理解する。なぜなら、私もここ数年、ミドルウェア、エンジン、シーングラフを研究することによって、系統的にゲームエンジンやグラフィックスを扱うことに挑戦してきたからだ。しかし、会社の実際の仕事で、私はそれを実践できていない。リアルタイムアプリケーションであるビデオゲームプログラミングは、常にパフォーマンスを要求し、そして、多くのプログラマがプロジェクトに参加する。そのため、パフォーマンスとプロジェクトの初期期間の両方を犠牲にする体系的アーキテクチャは、有益ではない。

C++ のような高級言語は、我々のプログラミングスタイルを変えるよう誘惑する。アマゾンや書店は、オブジェクト指向のプログラミングを書く方法を教える本を陳列している。我々は、これらの本を読み、そして、オブジェクト指向のプログラミングによってゲームオブジェクトクラスを扱えないか考え始める。大規模システム設計におけるオブジェクト指向アーキテクチャについての十分な議論があることは確かである。しかし、（特に日本において）、ビデオゲームアプリケーション設計のための議論は十分とは言えない。

欧米では、開発者は、ゲームオブジェクト設計を議論する。しかし、彼らの大半は、 FPS 、及び、 RTS を開発する。これらのジャンルは、オブジェクト指向の設計と相性がよい。しかし、ゲーム全てが FPS/RTS であるわけではない。そのため、多くの日本の開発者は、ゲームオブジェクトクラス設計を議論しない。他のジャンルでは、ゲームコアが統括的にゲームをコントロールすることが必要である。そして、ビデオゲーム開発において最も重要なことは、調整と調節である。恐らく、我々の世界における理想的なアーキテクチャは、エンターテイメント制御装置を調整と調節が容易なように 1 つの場所に集めることだ。ビデオゲーム開発者は確定された仕様書より娯楽感覚を重要視しなければならない。

大規模システム設計を教える本にと一緒に我々がソースコードを書くならば、ゲームアプリケーションはプログラマの虚栄心を満たすだろう。しかし、そのアプリケーションは、ビデオゲームプログラムとして悪いものである。我々の理想的なプログラム設計は、大規模システムと異なるであろう。そして、ビデオゲームのオブジェクト指向設計は、大規模システムのオブジェクト指向設計と異なるだろう。従って、それらの本は、すべてのことを我々に教えてくれるわけではない。我々は、自分で答えを発見しなければならない。まだ日本もそして欧米もその答えを見つけてはいない。

Document of RapidWeaver

2008-05-08T06:34:00.000+09:00

昨日のエントリで書きました RapidWeaver ですが、日本代理店のアクトツーさんが、オンラインマニュアルを公開されているのを見つけました。これがあればまだトライアル版をダウンロードしていない方も、そもそも Windows/Linux ユーザーなので RapidWeaver のモデルが分からない！という方も概要をつかめるのではないでしょうか？

よく見てみると、スニペットもいくつかリスト化されていますね。

The Next Base

2008-05-07T07:23:00.004+09:00

以前、 XOOPS Cube 1.00 の仕様確認のために仕様検証以外の意味を持たない次世代テーマを募集した。しかし、最近、私は 1.00 の仕様を検証するには、 BASE そのものを開発する必要があると考え始めている。仮にこの BASE を "TEST BASE" と呼ぶことにしよう。

XOOPS Cube Legacy は XOOPS2 JP をエミュレートするために開発された。一方、 TEST BASE は RapidWeaver （日本語）を手本に開発するのがよいのではないかと考えている。 RapidWeaver のスタイルは Nuke の長所を取り入れることができるからだ。また、当面の間は個人用 CMS を開発することで開発期間を短くすることができる。もし開発期間が短ければ、 Windows や Linux ユーザーに、 TEST BASE を通じて RapidWeaver のスタイルを説明することが可能だ。決定されたスペックはテーマ開発を容易にする。それをコンセプトモデルとして公開しても、 XOOPS Cube が TEST BASE の仕様を絶対仕様として強制することがないという点が XOOPS Cube のアドバンテージだ。

RapidWeaver はメディア管理を iPhoto、 iMovie や iTunes に依存している。その設計は TEST BASE の検証においても有効である。 XOOPS2 のメディア機能のウィークポイントが指摘されており、 CMS コアとメディア管理を切り離すことは有効なアイデアになるだろう。

いくらかの仕様書を書かなければならない。我々が XCL を開発したとき、仕様書は XOOPS2 JP だった。そして、私は PDF ドキュメントと Doxygen ドキュメントで不足分を補足した。今回、たとえ我々が RapidWeaver を参考にするにしても、ネイティブアプリケーションとウェブアプリケーションの勝手の違いがある。同じゴールを維持するために、 XCL のときとは異なる方法をとる必要がある。

An Overview of Collision Detection in OGRE 3D

2008-05-06T07:35:00.005+09:00

OGRE 3D は、衝突検出(Collision Detection)に関して複数の方法を提供してくれる。我々、日本の開発者は、衝突検出を「ヒット」と呼ぶことがある。衝突検出を説明する前に、我々の認識を共有化するために、その要素を列挙する:

衝突検出のために、プリミティブ形状が多く定義されていれば便利である。 OGRE はレイ、境界球、軸平行境界ボックス(AABB)を定義している。
そのほか、トライアングルや平面の概念も扱うことが可能だ。
楕円、円柱などの形状は提供されない。
プリミティブなバウンディングボリューム同士のヒットだけでなく、メッシュに含まれるトライアングルとのヒットを取ることも体系化されている。
負荷の軽いヒットのために専用のローポリメッシュがよく使われる。さて、汎用エンジンたる OGRE3D はそういった手段を提供するだろうか？

私は、最後の項目「負荷の軽いヒットのためのローポリメッシュ」に少しの説明を加えたい。日本の開発者は、そのようなメッシュを「ヒットモデル」と呼ぶ。私は、英語でそれを何と呼ぶかを知らない。従って、私は、それをこのエントリではヒットモデルと記述する。

OGRE 3D は基本的なヒット機能はほとんどすべて提供する。また、境界ボリュームのインスタンスは自動的に生成される。たとえば、メッシュクラスは境界球や境界ボックスを自動的に生成してそれをキープする。ヒット用のデータを細かく作り込む必要がない点はプログラマにとっては魅力的で即席だが、開発上は問題になるかもしれない。

まず手初めに、あなたはレイと地形のヒットの取り方（いわゆる地形ヒット/床ヒット）を知りたがるかもしれない。もしあなたのゲームの地形ジオメトリが高さマップではなく静的なメッシュ（リジッドモデル）であれば、ヒットを取るのは簡単である。あなたはレイと地形ジオメトリ（のヒットモデル）に含まれるトライアングルとのヒットを取る必要があるわけだが、プリミティブクラスの組み合わせの代わりに RaySceneQuery クラスを使うことができる。これは非常に強力な考え方である。

RaySceneQuery は、要するにレイである。しかし、このクラスは衝突検出を扱うために存在する。 Ray クラスのほうを使う場合、あなたはレイと衝突の可能性のあるシーン内のジオメトリデータとの衝突を検出するためにプログラムをたっぷりと書かなければならない。加えて、あなたのプログラムは、八分木もしくは四分木を用いて分割された空間から、絶対にヒットしないジオメトリを取り除いて候補を絞り込み、さらに境界球からトライアングルまで段階的な検出を実装しなければならない。

RaySceneQuery はそのような標準的なヒット検出を実装済みのクラスとなっている。どこまでやっているかは後日読解する。なんにしても RaySceneQuery はヒット地点までの距離を返すので、Y アンジュレーションや押し出しを簡単に行うことができる。 SceneQuery サブクラスは、他のヒット関係のクラスのためにもいくらかの種類が定義されている。

さて、あなたは標準的なヒット検出プロセスに何が必要だと考えるか？　シーンは多くのジオメトリ/メッシュを持ち、メッシュは多くのトライアングルを持っている。我々がエンジンに求める機能は以下のようなものになるだろう:

1) レイと衝突する可能性がないジオメトリ（レイの方向の反対側の分割空間に属するジオメトリなど）を衝突候補から取り除く
2) マスクできること
3) 最初のヒットチェックには境界ボリュームを使う
4) 1) の絞り込みの過程をある程度保持しておいて、次回のチェックに再利用する。

RaySceneQuery はこのようなフィーチャーを提供するか？　まず初めに、 OGRE 3D が提供するヒット関係の機能すべてを把握したいところである。

Reciprocal help for security

2008-05-05T19:50:00.005+09:00

JP/CERT は、 X2/XCL のあるモジュールのセキュリティホールを指し示した。我々の課題は、コミュニティがいかにそのようなセキュリティホールを扱うかである。

全ての開発者がセキュリティホールのミスを避けることは、不可能である。開発者がセキュリティホールに何も感じないことは、悪い傾向だ。しかし、開発者がミスや開発を恐れることは、同じく悪い傾向だと言える。誰かが開発者を支えなければ、有志の開発者は、フリーウェア開発から去るかもしれない。

JP/CERT は、セキュリティホールを指摘すると同時に、修正方法も開発者に送る。従って、我々は、 JP/CERT が指摘するモジュールのセキュリティホールの取り扱いに関してはあまり心配しなくて構わない。我々の考える課題は、コミュニティではそれと同じことができない点である。

私は、可能な範囲内で、コミュニティがソースコードをチェックし、パッチを送るべきではないかと考える。XOOPS Cube は、開発者がお互いにサポートする"フリーウェアのよき風習"の復活を必要とする。それのために我々が乗り越えなければならない２つの問題がある。

1) 罵倒
セキュリティホールを作ってしまった開発者は、傷ついている。そのため、しばしば攻撃的になり、修正パッチを送ってくれた支持者に悪態をついたり、逆ギレすることがあった。これは、コミュニティが開発者の相互扶助を失った原因のうちの１つである。パッチを送ろうとする人は、強い心を持っていなければならない。そして、他の開発者は、アドバイスを送る人を（いろいろ耐えられるように）助けるべきだろう。

2) 義務
開発者がお互いに支え合うことは素晴らしいことだ。しかし、 XOOPS Cube は市民のプロジェクトなので、そのような支え合いもまた有志である。残念なことに、コミュニティはしばしば開発者の善意の相互扶助を、組織上の義務や制度に変えようと試みる。このことは、パッチを送る能力を持つ開発者たちを"ぐったり"させる原因のひとつとなった。開発者の精神的負担を軽減するためにも、プロジェクトはさらに「これは有志のプロジェクトだ」という「フィーリング」を一層プッシュするべきだろう。そしてもしコミュニティがこのフィーリングをポピュラーなものに押し上げてくれれば、それは大きい。

フリーソフトウェア活動は、楽しめるものでなければ、活動を続けることは難しい。セキュリティホール、上記のような罵倒、及び、義務は、苦痛でしかない。苦痛は、開発者にソフトウェア開発を中断する道を選択させるだろう。コミュニティは、しばしば大きく、そしてシステマティックな組織になることを望む。しかし、コミュニティは、そもそもフリーソフトウェア活動とは一体なんであるかをよく考える必要があるだろう。XOOPS Cube は、それをアナーキーと定義している。私は、我々がセキュリティホールのための相互扶助を復活させることができると思う。なぜなら、 XOOPS Cube は、アナーキーであるからだ。ここには少なくとも義務はない。

アナーキズムは秩序の強制こそ否定するが、自発的な秩序を否定するものではない。

I took a part in a maranic

2008-05-04T15:28:00.002+09:00

今年もやって参りました萩往環。今日はピッチからの更新であります。

この大会はマラニックといって、マラソンと山登りを組み合わせた競技？をウルトラマラソンの距離で開催してるもの。

270キロ、140キロ、70キロ、35キロがあり、僕の参加はもちろん35キロ(^^;

ずっと70キロを目指していましたがトレーニングの時間が取れず断念しました。特に２月以降の走り込み不足は深刻でしたが、それでも去年よりは若干ましな結果でした。

もちろんカープのユニフォームを着て走りましたが、140キロの部に、カープユニ+ピエロのメイク+赤アフロで参加している人がいてそのインパクトは凄すぎでした！

140キロの部は野宿しながら走るのですが、あの格好で野宿していたなんて凄すぎます。

それにしても改めて思いましたが、山陽の山口から山地越えて山陰の萩へ……このコースを往復するにはどんなトレーニングを積めばいいんでしょう。

やっぱ根性か？

OGRE 3D moves their source code repository from CVS to SVN

2008-05-03T10:16:00.001+09:00

XOOPS Cube プロジェクトが参照したプロジェクトモデルを持つ OGRE 3D は、 CVS から SVN へソースコードリポジトリを移動した。私達は、 CVS が各 CVS 上のモジュールを担当しているコミッターのアクセス権限範囲を管理できることから、現在 CVS のほうを利用している。私達は OGRE のプロジェクトモデルを見習って、そしてこの枠組みを導入した。しかし彼らは SVN を使い始めたわけだから、私達は OGRE 3D がどう SVN をプロジェクトモデルに当てはめていくかをチェックした方がいいだろう。

一部のプログラマは、 XOOPS Cube のリポジトリをチェックすることを望まない。なぜなら、彼らは、リポジトリに何が入っているかとは関係なく、 CVS を使うこと自体を恥ずかしく思っているからだ。私は、優秀なプログラマが持つそういったこだわりを理解することができるレベルにいないが、 SVN が我々のプロジェクトモデルを運営することができるならば、 XOOPS Cube が彼らのプライドをカバーできることは素晴らしいことだ。

Submit Test by mail

2008-05-02T08:48:00.001+09:00

メール投稿機能を実験

Virtual Consoles May 2008

2008-05-01T23:25:00.000+09:00

バーチャルコンソール、5月の配信予定が公開

重装機兵ヴァルケンを作ったチームが開発し、当時１万円以上してとても買えなかったフロントミッションシリーズガンハザードが 800 Wii ポイント（８００円）で登場！　何とも有り難い話です。

箱から出してもない（というかどのゲーム機もしばらく電源すら入れてない orz） SFC クラシックコントローラを引っ張りだして遊んでみようかなぁ……

Positive Thinking Service

2008-04-30T23:00:00.001+09:00

あの伝説のサービス「ポジティブシンキングサービス」が復活しました。

ポジティブシンキングサービスとは、

苦しいことが多い現代、辛い事実を明るくとらえるポジティブシンキングが重要です。これは、あなたのポジティブシンキングを助ける革新的なアプリケーションです。

という傍記とともに公開していたサービスで、ネガティブな文章を入力するとそれをポジティブな文章に変換してくれるというものです。 lablab.jp の閉鎖とともに、このサービスも幕を下ろしたのですが、このたび t_miyabi さんこと teraminato さんの手によって蘇りました！ありがとうございます！

アクセスはこちらから！
さっそく、最近頭の中を飛び回るネガティブな思考……

カープは１試合３得点以上取れないので、守り勝つしかない。
眼鏡をかけると老けて見える。
睡眠時間が短い。
スマブラＸの WiFi 対戦が繋がらない。

等等を入力すると……おおポジティブな思考に！

なんだか希望が見えてきました。いい意味で！

Square Enix's Murata Talks Crystal Tools, Unreal Engine Initiatives

2008-04-29T09:56:00.002+09:00

Square Enix's Murata Talks Crystal Tools, Unreal Engine Initiatives（邦訳はコチラ）

WhiteEngineは、GDCで公開されたSquareEnixのミドルウェアである。日本のテレビゲーム産業が従来上手に「エンジン」を使用してこなかったので、多くの開発者はMT FrameworkとWhiteEngineに注目している。

カプコンは DEAD RISING、LOST PLANET、DEVIL MAY CRY 4 そしてRESIDENT EVIL 5（バイオハザード５）のためにMT Frameworkを作った。これらのタイトルが各々のプラットホームのためによく最適化されていたので、多くの開発者はMT Frameworkが良質で、そして、日本の開発者が上手に「エンジン」を使用することができるようになったと考えた。

同様に、WhiteEngineはゲーム開発のためのマルチプラットホームエンジンである。MT Framework は、PC、Xbox 360とプレイステーション3に適用される。WhiteEngine は、PC、Xbox 360、プレイステーション3とWiiに適用される。フラッグシップタイトルは FinalFantasy XIII になるだろう。

そして、WhiteEngineはCrystalToolsに名前を変えられた。「Crystal」は、スクウェアエニックスにとって重要なワードである。「Tools」は、これが「エンジン」でないことを示す。おそらく、それはコンテンツパイプラインのためのツールセットとライブラリである。

ところで、私がこのニュースを聞いたとき、私はCrystalToolsの名前がCrystalSpaceと類似していると考えた。CrystalSpaceもまた、ゲーム開発のためのエンジンである。彼らはどう感じただろうか？

The future plan of XOOPS Cube (3)

2008-04-28T22:51:00.005+09:00

あなたが経験したものは、あなたがどのようなプログラミング言語を使うことができるかより重要である。私は、前のエントリにおいてそれを書いた。私は、 C/C++ を習得し、ゲームやアプリケーションの一部を書くことができる。しかし、デバイスドライバを書くことはできない。 C/C++ が万能でも、私は万能ではない。それが大部分のプログラマにとっての現実である。

このエントリでは、私がこのシリーズでプログラミング言語のことを環境と表現した理由について書くつもりだ。

私は、言語の違いはハードウェアの違いより差が小さいと考えている……とくにウェブアプリケーション開発はそうだ。我々がウェブアプリケーション開発のために使うことができる主要な言語は、 C# 、 Java 、 Perl 、 PHP 、 Python 、 Ruby 、及び、 VB がある。しかし、これらの言語は、大きな差異を持っていない。なぜなら、ウェブアプリケーションは、ウェブブラウザ上で動くからだ。どのような言語を選択しようとも、ウェブブラウザができないことは、我々にもできない。

たとえば、 PHP では AJAX が使えず、 Ruby では MySQL に接続できないといった実現機能上の明確な違いがあれば、私の考えはこれと異なるだろう。しかし、事実として、すべての言語はウェブアプケーションが提供する仕様にとって平等である。

Xbox 360 を見てみよう。そこには C++ と C# という二つの異なる言語がある。C++ は、 Xbox のハードウェア性能を 100% 引き出すためにベストの言語である。C# は、優れた言語ではあるが、パフォーマンスが悪く、 Xbox 360 のハードウェア特性を引き出すことができないため、マイクロソフトは C# では TCR ( Technical Certification Requirements: プラットフォームメーカーによる品質審査) を通過することは極めて困難と明言している。ここにはプログラミング言語を選択するための明確な違いがある。それが、私が考える現実的な言語間の差異である。

重要なのは実行環境としてのプラットフォームである。ウェブアプリケーション開発には、このようなプログラム言語上の違いがない。従って、パッケージソフトである XOOPS Cube がプログラミング言語を選択する理由は、ユーザーが我々のプログラムを実行するためのサーバ環境を使うことができるかどうかにある。スクウェアエニックスがドラゴンクエストのターゲットコンソールを選択する理由と同じ理由というわけだ。たとえ PlayStation 3 が DS より優れているとしても、スクウェアエニックスが PlayStation 3 でドラゴンクエストをリリースする動機にはならない。まして、ウェブアプリケーションの開発には PlayStation 3 と DS のような性能上の違いがないのである。

言語にこだわる必要がないから、今は PHP 環境に固執するのである。そして言語にこだわる必要がないから、将来 PHP 環境に固執しないのである。

繰り返すが、ブラウザができることが我々にできることである。もし Ruby でプログラムすればブラウザ上でプログラマブルシェーダが動くというのであれば、私はいますぐ Ruby に移るだろう。しかし、ブラウザにできないことは我々にできない。私達のプログラムはテキストをブラウザに送信しているだけに過ぎない。それだけである。だから、よりポピュラーな環境を選択するのである。

日本のウェブアプリケーション開発における言語論争からも、その証拠を見つけることができる。言語間に実現機能に関する違いがないため、言語論争は、「プログラミング言語論争の最終段階」からいきなり始まり、各言語を用いるプログラマの人格や人間性を主題とする。例えば、

PHP プログラマは、向上心がない。従って、 PHP は、良い言語ではない。
Ruby プログラマは、高慢である。従って、 Ruby は、良い言語ではない。
Java プログラマは、真の技術を知らない企業の大量生産品である。

おお、まるでフレームのように見える。これは、本当にプログラミング言語論争だろうか？　これは、先に書いたように主要な言語がウェブアプリケーション開発（ブラウザにテキストを送る）について違いを持っていないという証拠であるかもしれない。もちろん、こういったことも IT のプロフェッショナルなプログラマには重要な議論であると思われる。しかし、XOOPS Cube は市民プロジェクトとして、このような議論とは一線を引き、普及を終えた環境にどんどんアプローチすればよい。

私の考えをあなたに強制するつもりはない。しかし、どうぞ、私達が環境を変えたとしても、あなたの経験は決して失われないことを覚えておいてください。そして、我々は、環境を選択する側である。加えて、移植は、するにしても、はるかに将来の話である。

The future plan of XOOPS Cube (2)

2008-04-27T01:44:00.000+09:00

PHP プログラミング言語は、ウェブアプリケーション開発に特化している。それは、珍しい言語である。しかし、万能プログラミング言語があるとしても、それは、あなたが言語を選択する理由にはならない。なぜなら、プログラム言語が万能でも、それを用いるプログラマのほうは万能ではないからだ。

たとえば、あなたの会社が新製品の「ブルーレイ・レコーダー」を開発中であるとしよう。そして、製品紹介のウェブページが Java で、ファームウェアもまた Java で開発可能であると仮定する。それでは社の Java プログラマはウェブページの開発を終えた後で、続けて組み込みのファームウェア開発に取り掛かることができるだろうか？　つまり、一人でウェブページとファームウェアの両方を書けることが Java プログラマとして当たり前のことだろうか？　答えは、「 No. 」である。

プログラマはプログラミング言語ではなく、経験（ノウハウ）に所属する。組み込み系のプログラマには、ハードウェア制御に関する豊かな経験がある。ウェブプログラマには、ウェブサービスを実現するための豊かな経験がある。ウェブアプリの開発者が、同じウェブアプリの開発のために、他のプログラミング言語を習得することは上手くいく。しかし、ウェブアプリケーションの開発者が、ハードウェアのために組み込み系ソフトウェアを習得することは困難である……例え普段使っているプログラミング言語がそのまま使えたとしても。

万能プログラミング言語は多くのカテゴリのために非常によい。しかし、ほとんどのプログラマにとってそれは意味がない。それが大部分のプログラマにとっての現実である。一方で、あなたのウェブアプリケーション開発における経験は、どのようなプログラミング言語でも役に立つ。あなたがどんな言語が使えるかが重要なのではなく、あなたがどんな経験を積んだかが重要なのである。

興味深いのは、プログラミング言語がウェブアプリケーションの仕様に関して差異を持っていないことである。したがって、あなたの経験を生かすために、私達は、時代に合わせたベストな環境を選択するべきである。

The future plan of XOOPS Cube (1)

2008-04-26T19:28:00.000+09:00

以下のものは日本で最もポピュラーな RPG ドラゴンクエスト（あなたがドラゴンウォーリアとして知っている）の歴史である:

ドラゴンクエスト I 1986 ファミコン
ドラゴンクエスト II 1987 ファミコン
ドラゴンクエスト III 1988 ファミコン
ドラゴンクエスト IV 1990 ファミコン
ドラゴンクエスト V 1992 スーパーファミコン
ドラゴンクエスト VI 1995 スーパーファミコン
ドラゴンクエスト VII 2000 PlayStation
ドラゴンクエスト VIII 2004 PlayStation2
そしてドラゴンクエスト IX 2008 NintendoDS

PHP は、少なくとも日本において、レンタルサーバのための最もポピュラーな環境である。レンタルサーバが PHP 環境を提供してくれるので、 XOOPS Cube を始めることは難しくない。しかしながら、 PHP が将来マイナーな環境になったときは、私達は、他の環境に XOOPS Cube を移植したほうがいいだろう。 XOOPS Cube が PHP と運命を共にする必要はない。

スクウェアエニックス社が、ドラゴンクエストのターゲットコンソールを選択してきた動機は、ハードウェア性能やハードウェア設計思想を評価してのことではない。彼らは、常にもっとも家庭に普及した現役ゲームコンソールを選択してきただけだ。それはパッケージ開発者にとって正しい選択である。

恐らく、 OSS ウェブアプリケーションのための次の普及環境は、 Ruby になるだろう。私は、かつて .NET が普及すると考えていたが。 Ruby がレンタルサーバにとってポピュラーな環境になったら、私達は Ruby に XOOPS Cube を移植することになるだろう。PHP がメジャーのままならこのまま続ければよい。いずれにせよ、あなたのウェブプログラミング技術の発揮が、環境のシェアに妨害されることはよいことではない。

XOOPS Cube の活動内容は、アーキテクチャと、プログラムのフィーリングを整えることである。同じアーキテクチャ、同じフィーリング、及び、同じ構造の DB があるならば、コアといくつかのモジュールを移植することは難しくはない。

あなたは異なる意見を持っているかもしれない。そこで、私は、明日も、プログラミング言語についての私の考えを書くつもりだ。いずれにせよ、移植はするにしてもぜんぜん先の話である。

Supplement to "RapidWeaver gives hints to us"

2008-04-25T23:11:00.003+09:00

私の貧弱な英語は、昨日、あなたを誤解させたかもしれない。私は、次のBASEにはどんな構造がなければならないかについて言及するつもりだった。そのために、私はXOOPS2、eZpそしてRapidWeaverの3つのアプリケーションのアプローチを比較した。

XOOPS2/XCL

D3モジュールを複製して、水平にそれらを置くことは、可能である。たとえあなたが「静的な製品紹介ページ」の下に「サポートフォーラム」を配置したいとしても、それはデフォルトでは不可能である。

eZp

eZpは、ツリー構造である。そして、すべてのコンテンツはeZpが定める一種のオブジェクトであって、サイトツリーのノードになる。しかし、この設計によって、 eZp は重く、管理は癖があり、ブログやフォーラムと相性が悪い。

RapidWeaver

RapidWeaverはツリー構造であるが、すべてのコンテンツをサイトツリーのノードとして取り扱うというわけではない。たとえば、ブログはノードである。しかし、エントリはノードでなくて、管理機能をユーザーに提供するブログに格納される。

結論
RapidWeaverには、「プログラム主導」とツリースタイルの間の良い釣合いがある。従って、次世代BASE開発のためにRapidWeaverを研究することは良い考えである。

RapidWeaver gives hints to us

2008-04-24T23:01:00.000+09:00

私は多くの CMS を触ってきた…… XOOPS2 はもちろん、eZ pablish、TikiWikiそしてRapidWeaver。XOOPS2 は Nuke 主義を示している。 eZp は XOOPS2 の対極にあるページベースの主義。RapidWeaver は、バランスを示し、そして、大きなヒントを我々に与えてくれる。

X2 の問題点

XOOPS2 は、良いコアだ。なぜなら、モジュール開発者が、プログラミングに関して自由を約束されているからだ。この「自由」は、プログラマがコアとの接続性を考慮する必要がないことを意味する。コアは、モジュールの存在のみ管理する。コアは、コンテンツが何であるかを把握していない。そして、各モジュールが各コンテンツを定義している。

しかし、コアがコンテンツが何であるかを知らないことは、問題である。サイトオーナーはモジュールをサイトに配置することはできる。しかし、ページをサイトに配置することはできない。例えば、 pico の１ページの下に子供として pical を配置することは不可能である。それは、仕様であり制限である。

eZp のメリットとデメリット

個人的に、私は、 eZp のようなスタイルを「ツリースタイル」と呼んでいる。 eZp はまさに CMS である。サイトオーナーは、ルートノードの下のコンテンツとして新しいノードを作ることができる。同様に、サイトオーナーは現存するノードの下に新しいノードを追加していくことができる。加えることができる。これはファイルシステムに類似しており、直観的かつ柔軟な構造である。

ノードは、 eZp コアが定義するオブジェクトである。各ノードが、それぞれのテンプレート、総合的なアクセスコントロール、マルチ言語層、及び、汎用的な管理を利用することができる。汎用的な管理とは、サイトオーナーがノードを編集したり、移動させたり、削除できることを意味している。たとえ、そのノードが人間が直接コントロールするべきでない特別なノードであるとしても。

あらゆるコンテンツが、 eZp の定義するオブジェクトとしてコントロールされるべき、ということになっている。それは、メリットでありデメリットである。自由に静的ページを適用できることを知ったとき、あなたはツリースタイルの可能性に驚くだろう。しかし、あなたが XOOPS のようにフォーラムやブログをインストールしようとするとき、問題に遭遇する。

eZp は、オブジェクト（＝ノード）としてコンテンツを扱う。

- 静的なページは、オブジェクトでありノードである。
- フォーラムは、オブジェクト（ノード）である。
- トピックは、フォーラムノードの子供ノードである。
- そして、返信はトピックノードの子供ノードである。
- 同じくエントリは、ブログノードの子供ノードである。
- そして、コメントとトラックバックは、エントリノードの子供ノードである。

あなたのサイトがフォーラムの 344 個のメッセージと、 36 個のエントリおよび 2056 個の SPAM コメントを持つとするならば、あなたのサイトのツリーは非常に多くのノードで複雑な構造になる。私は、私のプロファイルページの粒度と、バイアグラを売り付ける SPAM コメントの粒度が等しいとは思わない。

あなたはすべてのコンテンツを eZp のノードおよびオブジェクトとして扱うことができるので、ブログのコメントノードをフォーラムに移動させたり、コメントノードをマルチ言語化することが可能だ。しかし、意味はない。ところがこの汎用管理を通じてしか、管理する方法はない。エントリやカキコミを削除する機能はなく、ノードを探し出して削除するのがデフォルトだ。静的ページやダイナミックな型管理は理想的だが、柔軟性と引き換えに、重さと定常作業の困難がある。

eZp は、非常に優れたプロフェッショナル用の CMS である。従って、それは、全ての XOOPS オーナーのためのベストではない。コアが定義するオブジェクトとしてコンテンツの全てを扱う「ツリースタイル」は、完璧なソリューションとはいえない。

RapidWeaver

RapidWeaver は、 Mac OS X のホームページ製作ツールである。基本的な方針は、RapidWaver は eZp に近い。あなたは兄弟ページや子供ページを現存するページに加えていく。 RapidWeaver は、 1 ページを認識する。従って、各ページを動かして、編集して、削除することは、可能である。

一方で、ブログ、アルバム、ダウンロードといったタイプのページ（eZp ではツリーが広がっていたケース）は、１ページとして扱われる。ブログは多くのエントリをもっている。しかし、これらのエントリはあくまでブログページが管理する内部的なデータである。 RapidWeaver は各エントリを１ページとしては認識しない。ブログページを他のページの下や兄弟としてドラッグで移動させることはできるが、ブログからエントリを取り出して、エントリだけを他の場所（たとえばコメントの下）にドラッグすることはできない。これは正しい。そんなことをしたい人はいないからだ。もちろん、あなたは、ブログ専用管理機能でエントリを編集し、削除することができる。

RapidWeaver は新型 BASE のための多くのヒントを我々に与える。もし Mac OS X を持っているなら、一度 30 日間のフリートライアルバージョンをチェックしてみてほしい。

Characters in XOOPS Cube

2008-04-23T22:42:00.008+09:00

リトル・チャロに負けるな！実は、 XOOPS Cube にも様々な魅力的なキャラクターが存在していることを、皆さんご存知でしょうか……

ずーぷくん

matchan がデザインした有名なキャラクター。ウェブサイトを真っ白にする悪の手先と戦うためにずーぷまんに変身することができる。

きゅーぶくん

インストール画面でおなじみきゅーぶくん。じっと見てるとだんだん「もじぴったん」がやりたくなってきます。あたまのエックスはプロペラだったことが最近判明しました。

ず〜こちゃん

場末のスナックのママにしか見えないキャラクターだったが cubson GForce ではちゃっかり王女に出世。つけまつげに見えますがボーンが入っていて風で揺れます。

グラッツェ・M・キュブソン

2006年頃、 CUBE TIMES にコラムの連載を持っていた某国のエージェント。キューバ危機から世界を救うために奔走した高名なエージェントを父に持ち、自身はキューブ危機のために戦っている。 Legacy 用コードジェネレータ cubson の名前の元になりました。

元はキューブのロゴ（公募をかける前）で「きゅぶってる感じのロゴがいい」というイメージを統一するためにメーリングリストや xoopscube.jp に投稿された走り書きにいた外国人。（↓）

MBストリンガー

matchan がデザインした「ずーぷくん危機一髪」などでの悪役で、平たく言えばバイキンマンのポジションです。 cubson GForce では、「このプログラムのメインルーティンさ」という分かる人にしか分からない台詞とともに登場してストーリーとチュートリアルの先導役として３D化されたまま僕のハードディスクで眠っています。orz

ロジャー・キュビット

sourceforge.net の Wiki の使い方を教えるために颯爽と現れたウサギ。本職はアクション映画やられ役。こんな投稿を cube.jp でしたらレス０で終了確実です。

キャッチ

cubson GForce に登場する法の番人。プログラミングも出来ないしドキュメントも書かないし掲示板にレスもつけられないが、その役目を人に強制して見張ることに使命感を持つ公務員。

cubson GForce の共同開発者に「メタナイトのキューブ版」と頼んだら１分３０秒でこれがあがってきたことが昨日のことのようです。

きゅ〜ぶた

理想的なモジューラブル設計がなされている理想郷ガンダーラを目指して旅する豚。１００歩進むたびにトラブルに遭う。

……誰か組み合わせてリトル・キュロとか作ってください。

Little Charo : Adventure in N.Y

2008-04-22T22:40:00.005+09:00

NHK 教育はときどきユニークな教育番組を作ります。以前は「新感覚・キーワードで英会話」という番組を放送していて、これがすごく面白かったのですが、今年はなんといってもこれ！リトル・チャロ！

リトル・チャロについて｜チャロ・オンラインリトル・チャロ公式サイト via kwout

日本に旅行に来ていた家族の飼い犬・チャロは、空港の荷物で取り違いがあり、ひとりニューヨークに取り残されてしまいます。日本にいる飼い主の少年・翔太にもう一度会うため、英語を学びながらニューヨークで生きていこうとします……というアニメーション作品を通じた英語教育番組がこれ。NHK 外国語教育番組の中でもとびぬけてユニークな番組です。アニメーション制作は Spooky Graphic 。

番組は、ストーリーの内容のこともあって、日常会話に軸足が置かれています。たとえば放送第二回で学習する日常英会話は、

「おまえ何様のつもりだ」

……使う機会がないことを祈ります。

番組を見ててびっくりしたのが、いろんなメディアで展開するコンテンツ。リトル・チャロにはテレビ版とラジオ版があり、それぞれにテキストがあるのですが、ストーリー表現も微妙に違います。ラジオ版ではミニストーリーを盛り込んでいるとのこと。そしてウェブサイトがすごい！

番組紹介のホームページというより、番組に関連した e-ラーニングのサイトになっており、アカウントを登録して、放送を見た後、テストや単語帳を使ってより効果的な学習ができるようにプログラムが用意されています。このサイトは出演者も利用していて、グラフ化されたデータを、出演者と比較することもできます。

こうした多角展開をテレビでは無理なく取り入れていて、たとえばある回ではラジオ版のテキストを使ってクイズをしたり、ある回ではインターネットのサービスのひとつである単語帳を使ってクイズをしたり。民放だとウザイことになりそうなシチュエーションですが、リトル・チャロのそれはゲーム並にチュートリアルデザインがしっかりしていると思いました。

別に NHK の回し者じゃないのですが、非常によく出来ていて、ストーリーも気になる良番組なのでちょいと紹介してみました。本放送の月曜日は知り合いが作っているテレビ番組が裏番組にあるので、火曜日の再放送のほうを見てください！

Learn English, and talk at xoopscube.org! （←正しいのかどうかはしらん）

Ten dollars books

2008-04-21T21:04:00.005+09:00

アメリカの出版社 apress では、購入した書籍の the Companion eBook 電子手引書を $10 で購入することができます。検索や掲載コードのコピー＆ペーストが楽になるよ！とのこと。その購入方法ですが、

(1) まず www.apress.com/promo/tendollars/ にアクセス
(2) eBook が欲しい本の ISBN を入力します。本が手元にある前提なので、カバーの ISBN を入力。
(3) ランダムで生成される質問「第xページのどこどこに出ている言葉を入力しろ」などに、昔のPCゲームプロテクションを思い出しながら（あるいはメタルギアソリッド１を思い出しながら）回答します。

(4) 正解すると eBook をショッピングカートに入れられるようになります。

(5) 清算して eBook をゲット

A randomly generated question of the title には時間制限があり、時間内に答えらなかったり、一度でも間違うとアウト。次はまた新しい問題が生成されます。マニュアルプロテクトというやつですね。結構楽しんでやりました。支払いはクレジットカードか PayPal のいずれか。って、どっちも結局クレジットカードのような気が……

Wii classic controller SNES edition

2008-04-20T23:16:00.002+09:00

任天堂からプラチナメンバーシップ（昨年 Wii や DS のソフトをたくさん購入したユーザー）のプレゼントをいただいた。

ご存知のように、これは私たち日本人が "スーパーファミコン" と呼ぶコンソールのゲームパッドのレプリカだ。あなたがたは SNES としてスーパーファミコンのことをご存知だと思う。

これは Wii クラシックコントローラの一種でもある。

したがって、これを Wii コントローラに接続して、バーチャルコンソールのゲームで遊ぶことができる。

ありがとう任天堂！

CEGui Mesh Viewer (1)

2008-04-19T15:50:00.004+09:00

OGRE3Dにおける実機ビューワに相当する CEGui Mesh Viewer 。これがあれば、プログラマの方は、デザイナーのためにゲームアプリケーション専用ビューワを開発する手間を軽減できます。よほど特殊なことをやらない限り、開発の序盤から終盤まで全面的に活躍するビューワーになるでしょう。

CEGui とは、 OGRE3D コミュニティを中心に活用されているアプリケーション内の GUI システムで、この Mesh Viewer は CEGui を使って優れた操作性を確保したビューワです。ダウンロードはこちらから。

起動すると下のような画面になります。

アプリケーションの中にメニューが？と思うかもしれませんが、「これは実機ビューワ」と１０回ほど頭の中で唱えれば気にならなくなると思います。 Mac OS X や Linux でも動くアプリケーションにするためにも、こういった CEGui のようなウィジェットは必須です。 OGRE で独自のツールやデバッグメニューを組み込んでいく際にも CEGui を使っていくことになると思いますので、ここは慣れていきましょう。といっても CEGui は非常に本格的な GUI ですので、何の心配も要りません。

とりあえずメッシュを読み込んで表示してみましょう。アプリケーションの特性上本格的なファイラーは積んでおらず、あくまで OGRE のリソースマネジメント機構を通じてデータを読み込むことになります。任意のデータの読み込み方法はまた次の機会で説明するとして、まずはサンプルを読んで使ってみましょう。

左上の Select Group のリストボックスをクリックすると、リソースグループの選択ができます。
リソースグループとは何なのか？ということはさておき、まず General を選択してみます。

次に左から２番目のリストボックスをクリックします。ここに表示されるのは General に所属するリソースです。
robot.mesh を選択してみます。

robot.mesh が表示されます。マウスの左ボタンを押しながら動かすと注視点を中心とした回転、右ボタンを押すとドリーになります。
メッシュデータがアニメーションデータを持っていれば、そのままアニメーションを表示することができます。
（プログラマからしてみれば、大助かりですね）

メッシュのウィンドウから Anims のタブを押すと、 Animation State の欄にモーションの一覧が表示されます。
ここで表示したいモーションを選ぶと、アニメーションが始まります。

もちろん CEGui Mesh Viewer はソースが公開されていますので、何か追加の機能が必要な場合はこれをベースに改良を進めていけばいいと思います。

Will XOOPS change its license?

2008-04-18T23:38:00.005+09:00

XOOPS Cubeプロジェクトはスクラッチから新しいコアを書き、修正BSDでライセンスを行った。それによって、XCは様々な種類のライブラリとリンク可能になった。同様に、 xoops.org もライセンスの変更を選択するのかもしれない。なぜなら、 XOOPS3 は JpGraph の格納を計画しているからだ。 JpGraph のフリーウェア版は QPL でライセンスされている。QPL は GPL と矛盾するため、 GPL のソフトウェアは JpGraph のような QPL のコードとリンクすることはできない。これが私が XOOPS3 が GPL とは異なるライセンスを採用すると考える理由だ。

現在、私たちが SVN でチェック可能な XOOPS3 のコードは XoopsSphere であり、 GPL でライセンスされている。 XOOPS3 は北京で開発されていると聞いているので、異なる XOOPS3 が北京に存在し、 GPL と異なるライセンスを持っていると思われる。

XOOPS3 の選択は理解できる。 FSF の活動に賛同できるか否かに関わらず、 GPL は PHP 界でよい選択ではなくなってきている。

GPLは偉大なライセンスだが、 PHP の世界では GPL と矛盾するライセンスを採用したライブラリが多すぎる。 PHP フリーウェア活動を行う開発者にとって GPL は扱いづらい。

Prevent the unexpected distortion at setDirection()

2008-04-17T22:16:00.002+09:00

SceneNode や Camera のクラスについている setDirection() や lookAt() は、指定した座標の方向にノードやカメラの正面を向けることができる非常に便利なメソッドです。ただし、デフォルトの設定では特に回転軸を考えずに、最短距離で回転するため、カメラのオートトラックや lookAt() を扱おうとすると、ありがたくない Z-ROLL が頻発します。

Z-ROLL をロックするには、 setFixedYawAxis() メソッドで固定のヨー回転軸を設定します。これは本来 yaw() メソッドの回転軸をデフォルトの Vector3::UNIT_Y から変更するためのメソッドですが、 setDirection() 内のクォータニオン計算が切り替わり、 Z-ROLL を抑制する効果があります。
（実際、そのための機能です）

pNode->setFixedYawAxis(true, Vector3::UNIT_Y);

第二パラメータ Vector3::UNIT_Y はデフォルト値なので、省略してしまって構いません。これを指定すると、おおむね意図したとおりの回転が得られると思います。

Get pitch, yaw, roll from Quaternion

2008-04-16T01:00:00.004+09:00

クォータニオンからオイラー角を取り出す場合、

Z-ROLLを無視することにして、向きのベクトルを与えてピッチ角とヨー角を計算して取り出す
向きのベクトルと、それに直行するベクトルを与えて、ロール角も取り出す

という２つの計算方法がまず考えられます。この方法はクォータニオンを元にベクトルを回転させて、その２つのベクトルのなす角度を計算しています。

他方、クォータニオンの４元数 x, y, z, w から直接計算する式もあります。


float Quaternion::getPitch()
{
  return atan2(2*(y*z + w*x), w*w - x*x - y*y + z*z);
}

float Quaternion::getYaw()
{
  return asin(-2*(x*z - w*y));
}

float Quaternion::getRoll()
{
  return atan2(2*(x*y + w*z), w*w + x*x - y*y - z*z);
}

計算される角度は最短距離の角度であり、ベクトルを使って射影し、なす角度を測る場合に比べると、クォータニオンらしい値が出てくることになります。たとえば真後ろへの振り向きがヨー180°ではなく、ロール180°ピッチ-180°だったり……この値は再計算や保存値に使うには心もとないですが、単独で計算できるため、画面出力やダンプに向いています。

Ogre Application Wizard for VC++

2008-04-15T07:45:00.002+09:00

VisualStudio で Ogre プログラミングを楽しむなら The Conglomerate Project が作成、公開している Ogre Application Wizard をセットアップしておくと何かと便利です。

このアプリケーションウィザードは、ほかのアプリケーションウィザードと同様、いくつかの質問に答えるだけでプログラムの雛形を作成し、 DLL などの必要なファイルをプロジェクトのディレクトリにコピーして、ビルドが通るところまでをやってくれます。

アーカイブを解凍し、それなりのディレクトリにコピーしてから、VC8_Setup.js もしくは VC8_Express_Setup をダブルクリックするとインストールしてくれます。アプリケーションウィザードは解凍先のディレクトリから必要なファイルをコピーしようとしますので、このディレクトリはインストールが終わった後も動かしたり消したりしてはいけません。 SDK の近くに解凍するとか、自分がいつもプロジェクトを作っているディレクトリに入れるなどして、不意に削除されることがないようにしておきましょう。

添付されている js ではうまくインストールができない場合があります。その場合は手動でインストールします。まず、 Files の中にある OgreSDKAppWizard80.vsz をエディタで開き、 ABSOLUTE_PATH に解凍先のディレクトリの Files のパスを書き込みます。

自分の場合は以下のようになりました。

Param="ABSOLUTE_PATH = C:\projects\ogresdkwizard80_Eihort_v1_4_2\Files"

次に、 OgreSDKAppWizard80 という名前を持つ３つのファイルを VisualStudio のインストールディレクトリの VC/vcprojects にコピーします。 VC++ Express の場合は VC/Express/VCProjects にコピーです。

これらの手順は README ファイルの受け売りなので (^^;
行き詰ったら一度 README を確認してみてください。

Parallel programming for multi-core CPU

2008-04-14T07:52:00.004+09:00

「マルチコアCPUのための並列プログラミング」を読みました。執筆は CELL 関係ではおなじみの FIXSTARS。

内容は初心者向けで、マルチコア時代の背景の話から始まり、 pthread & Win32 API の基本的な使い方から、徐々に高速化のための並列化へステップアップしていく形になっています。厚みはありませんが、データ並列、タスク並列、パイプライン並列などを説明しながら実践しており、はるか昔にスレッドを弄って以降、このあたりの基本が記憶の彼方にぶっ飛んでしまっている人 orz でも安心！な感じでした。巻末には発展編として OpenMP と、ヘテロジニアスの代表格として CELL にページが割かれています。

開発環境は Windows 版しか解説されませんが、 pthread 版に機種依存コードはなく、 Linux や Mac OS X でも実践できます。ただし、（僕も初めて知ったのですが） Mac OS X は sem_init() を実装していないらしく、これを利用したセマフォ関係のコードは Mac では実践できません！　とはいえ、最近はセマフォは使わず、条件変数によるクリティカルセッション侵入制限が一般的なやり方になっているようなので、実害はないと思います。文中でも問題になるのは一例のみでした。

しかしちと高い…… orz

Switch site-close

2008-04-13T01:37:00.005+09:00

XUGJ にあがっていたアイデア、

たとえば，
社内からアクセスするとＸＯＯＰＳにアクセスできて，
社外からアクセスするとサイト閉鎖（ＸＯＯＰＳ）に
アクセスするようにしたいです．

を、例によって site preload で作ってみました。
SiteClose4OutSide.class.php として preload に保存すれば OK です。念のため、 site_default.ini.php の [Legacy.PrimaryPreloads] チャンクから Legacy_SiteClose の一行を削って置いてください。
ダウンロードする場合はこちらをどうぞ。


<?php
if (!defined('XOOPS_ROOT_PATH')) exit();

/// 許可するIPを正規表現でここに書いてね
define("SPECIFIC_IP", "/^127.0.0.\d+$/");

require_once XOOPS_ROOT_PATH . "/modules/legacy/preload/Primary/SiteClose.class.php";

class SiteClose4OutSide extends Legacy_SiteClose
{
 function preBlockFilter()
 {
  if (!preg_match(SPECIFIC_IP, $_SERVER['REMOTE_ADDR']) ||
      $this->mRoot->mContext->getXoopsConfig('closesite') == 1)
  {
   $this->mController->mSetupUser->add("Legacy_SiteClose::callbackSetupUser", XCUBE_DELEGATE_PRIORITY_FINAL);
   $this->mRoot->mDelegateManager->add("Site.CheckLogin.Success", array(&$this, "callbackCheckLoginSuccess"));
  }
 }
}
?>

簡単に説明をしておきますと、 SiteClose はもともとがプリロードで実装されており、サイトクローズ設定が有効なときのみ、それ関係の処理を行うメソッドをデリゲートに登録して働きます。この判定を行っている部分を隠蔽オーバーライドし、 if 文に IP 関係の判定を加えただけのものです。したがって動作にはオリジナルの SiteClose.class.php が必要です。

短いプリロードなら、コードをコピーしてしまったほうがいいと思いますが、もし長ぁいコードで、システムやモジュールにあわせて改変される可能性があるものなら、差分プログラミングに持ち込んだほうが若干プリロードの寿命が延ばせるかもしれません。

preload はモジュール同様、頒布単位となるものですが、もともとモジュールなどの組み合わせだけではこなせない仕事をするための箇所ですので、汎用性を求めるのではなく、色々なものに依存べったりでいいのでさっさと書いてしまって、使う人がいたらラッキーくらいの感覚で掲示板にガンガン貼っちゃうのがいいと思います。
（みんなで弄りやすいと思いますし）

The free lunch is over

2008-04-11T00:29:00.002+09:00

近年、並列処理設計の重要性が叫ばれ、多くのプログラマが生き残りをかけてその技術を獲得しようと努力している。この潮流にはターニングポイントがあった。マイクロソフトの Software Architect である Herb Sutter 氏は、従来のプログラマの仕事を「タダ飯を食べていた」と表現し、来るマルチコア時代におけるプログラマの仕事の重要性を説いた。彼のメッセージの衝撃は、この記事の中で簡潔に説明されている:

これは「the free lunch is over(フリーランチは終わった)」という、昨年(2005年)米国で有名になった言葉に集約されている。これは、Microsoftの Software ArchitectであるHerb Sutter氏がコラムなどで言い始めた言葉だ。フリーランチはタダ飯のことで、タダ飯食いは、もうできないという意味だ。

これまで、CPUはシングルコアの性能を高める方向で来た。そのことは、ソフトウェアにとってはタダ飯食いと同じことだったという。つまり、ソフトウェア側は何もしなくても、CPUが進化するにつれて同じコードがより速く走るようになったからだ。ソフトウェアは、増えるパフォーマンスをどんどん食べればよいだけだった。

ところが、CPUベンダーがマルチコアにターンしたため、状況が変わってしまった。汎用CPUコアのシングルスレッド性能は、現状ではもはや急激には伸びてゆかない。その代わり、マルチコア化によりマルチスレッド性能が急激に上がって行く。そのため、ソフトウェア開発者はCPUのパフォーマンスを活かそうとすると、ソフトウェア側を根底から切り替えて行かなければならない。

「Free Lunch Is Over」は、多くのエンジニアに新しい道を提示した。CPU の性能が上がっている間は、プログラマはパフォーマンスを高級言語で消費することができたため、仕事は年々に簡単になっていた。シングルコアの高性能化が見込まれている間、プログラマはパフォーマンスのために特別に何かをする必要はなかった。しかし、現在シングルコアの高性能化は頭打ちになり、プログラマはマルチコアプログラミングを獲得するための努力を始めなければならなくなった。タダ飯の時代は去り、新時代が到来したというわけである。

しかし、パフォーマンスのためのプログラムといっても、昔のようなフル/インラインアセンブリを想像する必要はない。現代のCPUに対してアセンブリは効果的ではないためだ。これらのCPUは非常に長いパイプラインを備えているため、人間がアセンブリを手で書いてプログラムを最適化することがまず不可能になっている。Ｃ言語でプログラムを書き、コンパイルオプションを調節してパフォーマンスチューニングを行う必要があるだろう。この状況は、若干気を楽にさせてくれる。

Ｃ言語は当面の間、マルチコアプログラミングに対する最適な言語としての地位を保つだろう。また、 C++ はゲームを生産的に開発するための良い言語として使われ続けるだろう。 C# はゲーム開発のシチュエーションから若干遠ざかったように思える。

Cube Night

2008-04-09T00:40:00.006+09:00

磯谷商店ＩＴ事業部 - ＩＴ事業部にようこそ via kwout

tadashi さん主導で XOOPS Cube の勉強会が開かれる模様です。日時は 4/16（水）19:00～、勉強会への参加は無料で、懇親会は割り勘じゃ2000円、ということのようです。仕事が忙しいのでとても行けないですが、どうも飲みだけでも来いやということの模様。なぜなら……

懇親会のほうが定員が多い！
時間があれば押しかけてコントリビュータを拉致りたいんですが……

XAMPP supports SSL

2008-04-08T23:40:00.005+09:00

恥です。環境があって初めてコードが書けるホリデープログラマには手も足も出ないと思っていた SSL ですが、 xampp がローカルに立ててくれていることが発覚。しかも何の設定もいらないときました。

テスト証明書を使ったOpenSSLをhttps://127.0.0.1、もしくはhttps://localhostがサポートしています。

おおお……orz

さっそく shumida さんと nobunobu さんが修正中の #1709886 のチェックをしてみます。

Important Test at 2.1.4 RC

2008-04-08T12:48:00.004+09:00

2.1.4RCのリリースでリストしていた重点テスト項目のうち、 Request #1914552 は取り下げがあったのですが、残りは特にレポートがありませんでした。
時間をとって見なきゃいけないと思っていたら #1709886 に関しては未完の報告が cube.jp にあがっているのを教えてもらいました。これを含めて、

#1779754 は報告なし
#1912990 は海外から何件か報告がありましたが、「きゅぶくま君」や「たぐめも」のブックマークレットが動作しないとの報告を発見……「悪魔の証明」にはボランティアも時間も不足だったかも
#1729813 報告なし

という状況です。他のは逐次報告で大丈夫だと思いますが……
cube.jp のカキコで SSL は叩けそうなので、土日にきちんと時間をとって #1779754 も見てみようと思います。といっても SSL の環境がないからずっとテストできなくて周りにお願いしてきたのが #1709886 なんですけど、誰かローカルで SSL のテスト環境を作る方法を教えてください。 m(__)m

CrazyBump

2008-04-05T01:22:00.005+09:00

CrazyBump は写真から凹凸にアタリをつけ、法線マップを生成してくれるツールです。パラメータを色々いじって、リアルタイムプレビューを見ながら調整することができます。

現在、ベータ版を３０日間、無料で使うことができます。正式版では有償化されるそうなんですが、なんとか200ドルくらいに収まってくれたらいいですよね！　なんかGDCでも話に出たらしくて、現場でも注目されているツールですが、プログラマが自宅で法線マップデータを手軽に作れる点でも嬉しいツールではないかと思います。法線マップはなんか何かツールがないと作れないですしね……僕は height map 作って誤魔化してましたが (^^;

ちょっと試してみました。

Turbo Squid からそれっぽいテスト向きのテクスチャをダウンロードしてきます。

CrazyBump をスタートさせ、 "Open photograph from file" をクリック。

うーん、まぁこれなら僕は右が適切だと思います。

できたっ！

法線マップは次世代機表現の代表格のひとつになってきていますが、非常に工夫の甲斐のある表現技法のようです。そして、その「工夫」にはツールのバックアップが絶対不可欠になりますので（手じゃ作れませんから）、たいてい法線マップの利用案はツールとセットで提案されています。

たとえば、法線マップと光源に合わせて、影などをテクスチャベイクし、凹凸感の出る視野角を広げる、という表現技法(*)が最近注目を浴びているらしいのですが、法線マッピングを使用したポリゴンリダクションのついでに影の位置を計算するのか、遮蔽物を法線マップから計算するのか、詳細は忘れましたが（確か後者だったような……）、いずれのせよ作成だけでなく計算も完全に機械に任せるしかないですよね。ということで、それ専用の新しいツール、アドオンが開発されてるそうなんです。

こういった技術革新ネタは３Ｄツールのベンダーにとってはチャンスのようで、色んな新製品と一緒に新しい技法や方法論を見ることができそうです。アドオンだけではなく、市場の３番手、４番手に甘んじていたツールが逆襲するチャンスであったり、ルーキーツールにとっても存在意義を確立するチャンスになっているみたいですね。

たとえば ZBrush などはルーキーの３Ｄツールで、「吉井さんが zbrush.jp で推している」くらいの印象でしかありませんでした。(^^;　ところが、強力な法線マップとディスプレートメントマップの生成機能で一気に現場に食い込んで、今ではメジャーツールのひとつになってます。

統合ツールの Maya や XSI も次世代機上の生産性、特化機能でシェアを削りあっていますが、こういった技術の転換がなければ、なかなか ZBrush や XSI のようなツールが Maya 相手に善戦するような機会もなかったんじゃないでしょうか。そして皆さん時々でいいから Shade のことを思い出してあげてください……
（PS2の序盤はShadeもミドルウェア戦線に名乗りをあげて、trueSpaceと戦っていたような...）

(*) 光源が移動するケースでは使えませんが、ライトマップを使っているゲームならどっちにしろ光源の移動は厳しいわけですから、そう大きな問題にはならないとは思います。

Multi-language Document

2008-03-29T10:57:00.004+09:00

XOOPS Cube には英語の Doxygen ドキュメントが用意されています。

minahito_sandbox ブランチでは、このドキュメントの多言語対応の実験を行っています。といっても、当然翻訳ドキュメントを準備しなければなりませんが……

仕組みとしては非常に単純です。(-_-;
元々 Doxygen は、ソースコードとドキュメントコメントを別々の場所に書くことができます。具体的には、以下のようなコメントを持つファイルをプログラムと別の場所に持つことができます。


/**
 * @class XCube_Root
 * @brief ....
 *
 * @function getRenderSystem
 * @brief ...
 * @param ...
 */

ただし、これだけでは関数のシグニチャなどが分かりませんから、その情報はソースコードから取ってきます。普通 Doxygen ではドキュメントコメントはソースコード内に埋め込みます。

今回の多言語対応ではこの仕組みを利用して、ソースコードに埋め込んだ英語を取り除きながら、日本語のコメントのみのファイルを読み込んで Doxygen にドキュメントを生成させています。お手元では make 一発で生成できるようにしてあります。

make doxygen
make doxygen_ja

英語以外のドキュメントを生成するには bash 環境が必要です。 Win な方は cygwin を使ってください。僕の方は Mac OS X で確認しています。Doxygen をパスに通すことをお忘れなく！

Intel Threading Building Block

2008-03-23T01:53:00.003+09:00

インテルスレッディングビルディングブロックは並列処理のための C++ テンプレートライブラリです。それは PC アプリケーションのために作られましたが、インテルはこれについて GDC でスピーチを持ったそうです。つまり、インテルは TBB がゲームプログラミングに有効だと考えているのかも知れません。調べてみる価値はあります。

私は GDC における TBB のセッションの一部を伝え聞きましたが、そのときはインテルスレッディングビルディングブロックは SPURS のインテル版ともいうべきもので、 Intel CPU でしか使用できないため主要なゲームコンソールでは利用できないのではないかと想像しました。しかし、 TBB は独立したライブラリであり、 pthread や boost のスレッドと結びづけられ、 MacOS X のような PowerPC アーキテクチャでも利用可能ということです。

TBB は論理タスクを並列処理に展開することを可能としており、その点は大変興味深いです。しかし、これを PS3 のようなヘテロジニアスマルチコアで使うことはできません。 Xbox360 での活用にわずかな可能性があるというところではないでしょうか。

TBB はデュアルライセンスですので、あなたは TBB を GPL ライセンスで自由に利用できます。私は O'Reily から出版された本を購入し、さしあたっては、まずそれを熟読するつもりです。

XOOPS Cube Legacy 2.1.4 released!

2008-03-22T23:55:00.003+09:00

↓↓↓例によって下記の邦訳は切るなり貼るなり自由にしてください↓↓↓

XCL 2.1.4 は利用可能です。 2.1.4 は 2.1.3 からのマイナーアップグレードバージョンであり、バグ修正と、小さいフィーチャーリクエストの実装を行っています。2.1.4RCのテストに参加したすべての今トリビュータにお礼申し上げます！

ダウンロードはこちらからどうぞ。

2.1.3 から 2.1.4 RC へのアップグレード方法
あなたの既存の環境を破壊しないように mainfile.php と /install ディレクトリを取り除きます。次に、あなたのサーバーにパッケージのファイルをアップロードしてください。最後に、管理画面のモジュールマネジメントで赤いアイコンを表示させているモジュールをすべてアップデートしてください。アップグレード作業のために管理画面からサイトを閉鎖するのがよいかもしれません。

2.1.4RC から 2.1.4 へのアップグレード方法
わずかな変更にとどまっていますので、あなたは多くのファイルをアップロード（or 上書き）する必要はありません。あなたがアップデートする必要があるモジュールは'legacy'だけです。 2.1.4 の legacy のファイルを、あなたのサイトの legacy のディレクトリにアップロードしてください。もし、より小さな作業がよければ、テンプレートのディレクトリのみを更新すればOKです。また、include/version.php もアップロードしなければなりません。そのあとで、コントロールパネルのモジュール管理へ行って、 legacy モジュールをアップデートしてください。

Request #1914552 について
2.1.4 RCはこのパッチを実装しましたが、このパッチには本来解決しようとしていた問題を解決する効果がないとみなされ、いったん取り下げられました。したがって、CJK(中国、日本、および韓国)の翻訳者は 2.1.4 RC でアナウンスされたこのパッチの内容に従う必要はありません。

新規インストールの場合
2.1.4 RC のインストーラは、モジュールが tw_big5 を持っていたにもかかわらず、 tw_big5 を収録していませんでした。 2.1.4 インストーラは tw_big5 を収録しましたので、あなたは今回 tw_big5 で XCL をインストールできます。

スタッフ
- Gigamaster (xoopserver)
- GIJOE
- gusagi
- hiro1173
- jidaikobo
- kilica
- Mikhail
- minahito
- mumincacao
- nbuy (aka nobu)
- nobunobu
- okuhiki
- onokazu
- tohokuaiki
- tokitam
- tom_g3x
- wanderer

PowerPC Personal Computer

2008-03-22T02:13:00.002+09:00

全ての主要ゲームコンソールは、 PowerPC 系を採用しています。 PowerPC の性能を引き出すコードを書くために、多くの特別なテクニックが存在しています。私達は、休日でも、 Appe の PC でそれを試してみることができました。しかし、それはもはや過去の話になっています。 ApplePC が PowerPC からインテルに変更した今、自宅で PowerPC プログラミングを実践する妥当な PC はありません。どうすれば、自宅で PowerPC やマルチコアプログラミングを試みることができるでしょうか？

自宅には古い mac mini、最新の iMac そして PLAYSTATION3 があります。

私の古い mac mini は、マルチコアではありません。しかし、それは、私のために役に立ちます。なぜなら、 mac mini は、小さく、軽く、PowerPC プログラミングを楽しむには良いからです。

現在の私の PC、 iMac は、デュアルコアであり、そして、マルチ‐コアプログラミングを実践するには良い環境です。しかしながら、 intel core duo は、主要なゲームコンソールに採用されていません。従って、純粋なマルチコアプログラミングの実践に使うことはできますが、ただちに仕事に直結するわけではありません。

PLAYSTATION3 は、有益であるかもしれません。 Linux をインストールし、ヘテロジニアス（非対称）マルチコアプログラミングを実践することが可能です。もちろん、この重たい linux 環境は PS3 SDK よりプログラムは面倒ですが、通常の PC はヘテロジニアスマルチコアを搭載していませんから、そこに選択肢はありません。幸いにも、私達は、 SPURS のような特殊なライブラリを除けば、全てのツールチェーンを得ることができます。

今にして思えば、Power Mac G5 のような PowerPC マルチコアは、非常に価値があります。

マルチコアプログラミングを探求するには、労働時間だけでは不十分です。私は、研究開発段階でもっともっと研究しておくべきでした。今、私達のチームは、研究開発段階を終了し、製品の開発に入っています。それは、良いですが、私自身は、もっとトライ＆エラーのための時間を必要としています。自宅の PC はそういったことのために多少役に立つでしょう。

多くのエキスパート開発者は、ゲームにおけるマルチコア並列処理の道を見いだしています。しかし、私はまだ、そのような段階に至っていません。

Let's test 2.1.4 RC

2008-03-20T12:15:00.002+09:00

2.1.4RCがリリースされました。RCとはリリース候補版のことで、有り体に言えば「アーカイブしたのでテストしてください」バージョンということになります。「テスト」は品質のカギを握っていますが、市民活動ベースの OSS である XOOPS Cube ではコーディングと同様にテストも有志の手に委ねられています。

市民生活を営みながらの有志活動は、どうやって自由時間を調達するのかが大きな問題になります。いまどき９時～１７時の仕事をしている人はほとんどいないと思います。一日３０分～１時間ほど確保できればかなり上々ですが、なかなかそうはいかないでしょう。

個人的に月３０時間確保できれば相当だと思いますが、その程度の時間では、コーディングやドキュメントで手一杯というのが実情です。月３０～４０時間では足らないくらいで、全環境・全ケースでテストを行う時間は残りません。

商用ソフトウェアならデバッグ部署やデバッグ会社にテストを依頼するのですが、 OSS では無理な相談です。こういった話は XOOPS Cube に限ったことではなく、市民活動ベースのオープンソースはすべて同じ事情を抱えています。しかし、コーダーが有志で集まるように、テスターも有志が集まりますので、多くのプロジェクトはそうやってテストを行い、最低限の品質を確保しようとしています。

（テスターが集まらないプロジェクトでは、二ヶ月かけて開発し、二ヶ月かけてテストして、ようやくリリース……という運営を行っているところもあります。幸い XOOPS Cube はユーザー数はむちゃくちゃいますので、効率よく開発を回転していけるようになっています）

XOOPS Cube は、最近では RC を出したあとは時間で区切って本リリースを行うというやり方をとっています。そして問題が出れば次のリリースで修正します。これはテスターの頭数に限界がある以上、２週間も３週間も待っても仕方がないので、特に大きなレポートがなければ問題なしと割り切っているためです。

万が一、 RC 期間中にテストを行った人がゼロ人だった場合は、ノーテストに等しい品質になります。幸い、海外の皆さんがテストに対して非常に積極的なため、これまでノーテストだったことはありません。しかし、日本で人気のモジュールや使用法は必ずしも海外のテスターがテストするとは限らないので、日本は日本で積極的に行っていく必要があります。

（このようなプロジェクトでは）テストは量ですので、頭数がいればいるほど助かります。とはいえ、忙しい毎日で、一日３０分調達できたとしても、自分の環境や自分のモジュールで問題が起きないことを確認するには時間がぎりぎりだと思います。フォーラムやローカルコミュニティを上手に利用して、「この環境では問題がなかった」「使用中のこのモジュールは問題がなかった」と報告しあえば、効率よくテストを進められると思います。

こんな感じ（↓）

> 問題ありませんでした。使用中のモジュールは正常に動作してるようです。
>
> Apache : xxx.xx.xxx.
> MySQL : xxx.xxx.xxx
> PHP : 5.1.2
> Module : Protector, Pico and...

（正常、バグに関係なく）報告があればレポーターのお名前はスタッフリストに加えます。ローカルコミュニティのレポーターはどなたかまとめてフォーラムに報告いただけると助かります。

（フォーラムにあげておけば僕が忙しくていろいろできないときでも他のコミッターがやってくれますので）

The Unknown Feature of Installer

2008-03-18T23:56:00.003+09:00

意外と知られていないインストーラの機能編。passwd.php に ID とパスワードを書いておくと、インストーラの領域に BASIC 認証をかけることができます。
これで放置も安心！……って、これ推奨した方がいいかも。

ちなみに僕はこの機能ぜんぜん知りませんでした。 extra_languages の絡みでインストーラ覗いたときにたまたま見つけた。 Legacy 2.1 の開発ステータスのころにインストーラの保護って話題が出ていたような気がするのですが、この機能の話はぜんぜん出てなかったような……(--;.

XOOPS Cube Legcy 2.1.4 RC has been released!

2008-03-15T18:47:00.002+09:00

↓↓↓例によって下記の邦訳は切るなり貼るなり自由にしてください↓↓↓

XCL 2.1.4 RC はテストおよび検証のために利用可能です。 2.1.4 は 2.1.3 からのマイナーアップグレードバージョンであり、バグ修正と、小さいフィーチャーリクエストの実装を行っています。ご存知のとおり、テストはクオリティのために重要であり、とにかく人手を必要としています。どうか 2.1.4 RC のテストに参加してください。

もしあなたが XCL を使用しているサイトのウェブマスターであり、有志活動のための若干の自由時間があるなら、 XCL 2.1.4 RC の更新内容があなたにトラブルをもたらさないかチェックしてください。

ダウンロードはこちらからどうぞ。

おそらく、来週にプロジェクトは stable 版をリリースするでしょう。 RC をテストしてください！

重要な更新トピック
これらのフィックスがあなたの環境に影響を与えないかどうかチェックしてみましょう。

===Request #1914552===
これは CJK （中日韓）に代表されるようなマルチバイト言語にとって非常に重要な追加パッチです。インストーラーは従来、 my.cnf などで指定される default-character-set を用いてデータベースを作成しようとしていましたが、これは CJK において文字化けの原因になる恐れがありました。このパッチは日本語のためにこの問題を解決する日本人によって提供されたパッチです。しかし、それはほかのマルチバイト言語のためのサンプルでもあります。あなたの母国語は以下のルールに従うことで文字化けを回避しやすくなるかもしれません:

1. /html/install/language/{lang}/createdatabase_mysql.php を作成する
2. コードをそこに書きます。以下は日本の例です:


<?php
$result = $this->db->query("CREATE DATABASE ".XOOPS_DB_NAME." DEFAULT CHARACTER SET ujis");
if ($result == false) {
$result = $this->db->query("CREATE DATABASE ".XOOPS_DB_NAME);
}
?>

これは 'latin1' (?) の代わりに ujis を使ってデータベースを作成しようとします。このファイルをあなたの母国語のディレクトリにコピーし、 ujis の部分をあなたの言語コードで置き換えてみましょう。

===Fix Bug #1779754===
コメントパラメータである extraParams を持つモジュールでコメント機能が正しく動作していなかったバグの修正です。この修正はさまざまなモジュールの下で検証される必要があります。

===Fix Bug #1912990===
XCL はいくつかの環境で正しく動作していなかったため、 PHP_SELF を使用することをやめて、かわりに REQUEST_URI を使い始めました。私たちは既存の環境にトラブルを起こさないかどうかを確認しなくてはいけません。あなたの環境は大丈夫ですか？

===Fix Bug #1729813===
(これは日本の XoopsMultiMailerLocal の修正です)
これは古いフィックスですが、 RC はこれに関連する追加パッチが行われています。これらのパッチは NOTICE を押さえ、メールを正しく送信することに寄与しますが、多くの確認が必要です。

===Fix Bug #1833146===
テーママニフェストにおいて、あなたは "licence" 項目を使うことができました。しかし実はこれは TYPO であり正しくは "License" です。そこで XCube_Theme は 'license' と 'licence' の両方から情報をロードしてメンバプロパティ $mLicense と $mLicence にセットするようになりました。しかし、 XCube_Theme::mLicence は非推奨メンバプロパティになります。今後マニフェストを書く場合は、 'license' と書くようにしてください。

===Fix Bug #1738936===
XOOPS Cube の Validator は一部の国の事情のために RFC に厳密に準拠していませんが、 RFC 準拠のメールアドレスを受け入れることができないのはバグです。いずれにせよ、XCube_EmailValidator はこのポリシーに基づき修正されました。プログラマの皆さんに XCube_EmailValidator::isValid() の正規表現をチェックしていただければ幸いです。

要・確認

===Bug #1709886===
このバグは古いバージョンにおいて修正されましたが、誰もこれを確認していません。このトラッカーアイテムを閉じるために、誰かが extra プログラムを使用して SSL 経由のログインが問題ないかどうか確認することが望ましいです（たとえ、 SSL ログインのために古い extra プログラムを使うことが最早なかったとしても）

===Bug #1801317===
「検索オプション」を変更したあと接続が切れる……このバグのレゾリューションステータスは "Works For Me （こちらでは動いています）" です。このバグが以前のバージョンのフィックスで修正されているかどうか判断するために更なる情報が必要です。もしこの問題に関して心当たりがある方は、どうか教えてください。

2.1.3 から 2.1.4 RC へのアップグレード方法

あなたの既存の環境を破壊しないように mainfile.php と /install ディレクトリを取り除きます。次に、あなたのサーバーにパッケージのファイルをアップロードしてください。最後に、管理画面のモジュールマネジメントで赤いアイコンを表示させているモジュールをすべてアップデートしてください。アップグレード作業のために管理画面からサイトを閉鎖するのがよいかもしれません。

更新履歴

[Bug Fix - From Bug Tracker]
- Fix Bug #1779754 - cannot POST extraParams on XOOPS Comment integration
- Fix Bug #1833191 - [lang] lisense message of installer
- Fix Bug #1867504 - showall anchor text must be urlencoded (Search Func)
- Fix Bug #1868269 - Notice[PHP] at japanese/xoopsmailerlocal.php
- Fix Bug #1880410 - Too strict checking for block's weight
- Fix Bug #1887557 - XoopsObjectGenericHandler::getCount has doesn't use variable
- Fix Bug #1888226 - Bio in users table doesn't use Validator
- Fix Bug #1895776 - Installer settingmanager.php
- Fix Bug #1897588 - Language misrecognition on Install
- Fix Bug #1899424 - Could not work sort perfectly in image manager
- Fix Bug #1899947 - 2nd Installer never activate blocks
- Fix Bug #1908649 - missing file_exists arg in helpimage modifiers
- Fix Bug #1901153 - tell a friend doesn't work
- Fix Bug #1901334 - Wrong module version display in the module list
- Fix Bug #1904092 - redirect_header failed keep session
- Fix Bug #1908539 - Smarty "regex_replace" Modifier Template Security Bypass
- Fix Bug #1885392 - Cannot get cookiePath rightly
- Fix Bug #1897588 - Language misrecognition on Install
- Fix Bug #1897089 - xoops_redirect argument too match escape
- Fix Bug #1804621 - admin.php + mainfile writeable = path disclosure vulnerabili
- Fix Bug #1900435 - ClickableConvert miss email address
- Fix Bug #1911181 - The danger where session ID leaks exists
- Fix Bug #1911191 - $GLOBALS['xoopsTpl'] is overwritten
- Fix Bug #1912990 - Use REQUEST_URI instead of PHP_SELF
- Fix Bug #1914480 - default_charset in the installer
- Fix Bug #1914552 - Adding DEFAULT CHARACTER SET into installer
- Fix Bug #1905910 - Wrong dependencies in templates for 2nd Installer

[Bug Fix - From "XCube" Bug Tracker]
- Fix Bug #1833146 - Typo : "Lisence" on Xcube_Theme.Class.php
- Fix Bug #1835831 - Locale namespace
- Fix Bug #1902823 - Controller cannot set extra root path at site config?
- Fix Bug #1738936 - Mail address which conforms to RFC2822 is refused Validation

[Patches - From Feature Request Tracker]
- Request #1905593 - Needs IsReverseProxy in site_default.ini.php
- Request #1898144 - Modifying 2nd Installer

[Other Changes/Enhancements]
- Added Traditional Chinese Message Catalogs (language pack).
- Patch #1875606 - Added Portuguese Message Catalogs (language pack by Mikhail Miguel)
- Patch #1897498 - Password charactor check

スタッフ

Gigamaster (xoopserver)
GIJOE
gusagi
hiro1173
jidaikobo
kilica
Mikhail
minahito
mumincacao
nbuy (aka nobu)
nobunobu
okuhiki
tohokuaiki
tokitam
tom_g3x
wanderer

GET INVOLVED!!

2008-03-15T02:39:00.008+09:00

XOOPS Cube というモノは、プログラム、デザイン、ドキュメント、デバッグ、テストいずれも有志によってまかなわれています。開発の進行スピードや安定度は有志の頭数に左右されるといっていいでしょう。 "GET INVOLVED" とは「参加しよう！」という英熟語で（お前ら巻き込まれろ！ではありません）、オープンソースのプロジェクトではよくみられる合言葉です。

XOOPS Cube はアナーキズム（権威を可能な限り廃した自由）を念頭に置いていますが、これはセントラリズム体制をとっていたXOOPS財団へのカウンターとして用意した言葉であり、 XOOPS Cube がやっていることは他のオープンソースと大きな違いはありません。

ただ、最近、（特にＩＴ関係では）財団や企業がきっちりソフトウェアを仕上げてリリースするケースが少なくないため、完全な市民レベルの活動である XOOPS Cube の運営がピンと来ないユーザーさんも多いかもしれません。大枠はプロジェクト Wiki の GET INVOLVED にまとめられていますが、これは英文の翻訳の枠を出ないため、このエントリでは日本の習慣やこれまでの XOOPS の経緯を踏まえた上で知っておいて損はないことをまとめておきたいと思います。

開発者には誰でもいつでもなれる

日本の XOOPS 周辺では開発者＝プログラマという感覚がかなり強いようですが、デザイナはもちろん、ドキュメント、テスト、バグレポートなどに関与するすべての人が開発者になります。もともと「開発者(Devloper)」はモノを作り上げたり発展させていくすべての職分を含んでいます。

たとえば、ゲームのビジュアルさんはゲーム"開発者"ですし、ゲームの企画さんもゲーム開発者ですし、デバッガーさんもゲーム開発者です。対外的にはゲーム開発者で、そのくくりの中に職責や職分があると考えてよいでしょう。

開発者とは特定の集団や管理者の承認によって取得する「資格」ではありません。できそうなことをやってしまえば、誰でも開発者になることができます。

ボランティア活動≠奉仕活動

XOOPS Cube はボランティア活動によって維持されていますが、 XOOPS Cube のボランティア感は、邦訳として使われがちな「奉仕活動」とはニュアンスが異なっています。私達は別に利他的な目的でユーザーやコミュニティに宮仕えしているわけではなく、ビールを飲みたい時にビールを飲むように、好きなことをやっているだけです。感謝されることもなければ、別に何か義務を背負わされることもありません。

XOOPS Cube の日本語では「有志」という言葉をボランティアの対訳にあてています。

スタッフはリリースごとに

XOOPS Cube プロジェクト自体はチーム制度をとっていないので、固定スタッフはいません。リリース毎に開発に関与した人の名前をリスト化して ABC 順にまとめて発表しています。このリストは、長いためか xoopscube.jp のニュース文には含まれていませんが、 xoopscube.org のリリース文や、 sourceforget.net でのリリース文で確認できます。

また、 XCL 2.1.4 からはチェンジログに含まれることになりました。

チーム制度がないことはスピーディなチーム制度と同じ

チーム制度がないというのは、単に対外的なチーム制度をとってないという意味で、やっていることは他のオープンソースとまったく一緒です。

チーム制度の場合、セミリタイア（非常勤化）した人はチームから抜け、手が動かせる人に新たに入ってもらう形で運営すると思います（えてして人間関係がそうそう事務的な展開を許さず、こじれますが）。下の図のように、セミリタイアした人には何らかの規則か事務手続きか、あるいは投票か、あるいは直接交渉するのか、幽霊メンバーとして留まらせるのか、ケースバイケースでしょうが、チームから抜けます。そして必要な人数分は、またどういう基準でやるかはプロジェクト次第でしょうが、志願者からチョイスしてチームに入ってもらいます。

XOOPS Cube の場合は、セミリタイアした人は自動的に作業に参加しませんし、手が動かせる人にはいつでも参加してもらうというスタンスです。それを図にすると下のようになります。単に枠組みが無い（チーム制度が無い）だけで、やっていることは同じですが、こちらのほうがスピーディです。セミリタイアした場合、自動的に作業に参加せず、復帰した場合も特になにもなく自動的に作業に復帰できます。

もちろんこれは XOOPS Cube の特殊なやり方というわけではありません。むしろ星の数ほどあるＯＳＳでは、 XOOPS のようにプロジェクトやチームに関してフォーマルな感覚を演出しようとする運営体制の方が少数派といえます。

Legacy

Legacy は XOOPS2 の互換を可能な限り担保するための Base で、独自の発展は基本的に行いません。専門チームは上記の通りなく、担当メンバーの概念もありません。独自の発展は、有志がこの Base から交換可能な派生 Base を作成し、担当者としてチャージして進めるという進め方を前提としています。 Legacy は派生の作成に影響しそうな点やバグの修正を積極的に行っています。

開発への参加

XOOPS Cube に限らず、ほとんどのオープンソースでは、有志というものは「増やす」ものではなく、「増える」ものだと考えています。市民が市民を拘束して、活動に加わることを強制することはできませんからね。 (^^;
開発は全面的にオープンになっていますので、いつでも参加してください。ほとんどの作業はすぐに始められると思いますが、システム上の権限が必要であればコミット権を「手続き用トラッカー」から申請します。コミット権取得に関する情報も GET INVOLVED に書かれています。

プロジェクト

XOOPS の本家では、XOOPS にまつわる存在は基本的に中央の管理下に入らなければいけませんでした。 XOOPS のコントローラに反したものは、公式サポートサイトの看板を取り上げたり、情報サイトを独自に立ち上げると、 *.xoops.org への集約を乱すものとしてフォーラムで問題視されるなど、かなり官僚的な体制になっていました。個人的によく覚えているのが、 xoops.org へ批判的だったという理由から、ブラジルの公式サイトを別のサイトと交換したうえで、公式アナウンスで"旧"ブラジル公式サイトをさんざんなじったことでした。
e-XOOPS ブランチのときもまともではなかったと聞いていますが、ともかく海外のプロジェクトとしては珍しく、体面上の一体感を強要してくるプロジェクトです。

他方、 XOOPS Cube のほうは、当たり前のことですが、XOOPS Cube プロジェクトの範囲内に加わるかどうかということと、 XOOPS Cube の有志活動者であるかどうかということは、別の話です。プロジェクト自体、全体の活動の一部でしかなく、プロジェクトのフォーラムで活動することも、ローカルコミュニティで活動することも意味するところは同じです。

旧 XOOPS は完全に逆の考え方を持っていたため、 sf.net Wiki などではいろんな場所でこのポリシーを説明しています。そういった要素を分かりやすくアナーキズムと総括しているのですが、そもそも sf.net プロジェクト単位を勢力とみなして陣取り合戦をする人たちのほうが珍しいですから、別に XOOPS Cube が何か特殊なことをやっているわけではありません。 XOOPS との対比のために、 Third party や official といった言葉を無くして、みんなでリハビリを行っているのです。

なんにしても、みんな9時-17時の仕事をしているわけではありませんので、開発が主目的の人でも一日30分〜１時間、月累計２０〜３０時間程度調達できれば御の字でしょう。フルタイム２〜３営業日ぶんくらいです。ひとりひとりはその程度の動きしかできないわけですから、多くの人が参加して全体としての作業時間を大きなものにできるかどうかです。

もちろんサイト管理者の方は、まず自分のサイトをしっかり運営することが第一で、余裕がある時にテスト版を自分のサイトで試したり、バグをレポートしていただければ十分です。それができれば XOOPS Cube 以外のオープンソースプロジェクトにもどんどん参加できるでしょう。

Diff between XC and XCL(X2): Render Sequence

2008-03-13T00:31:00.004+09:00

XOOPS Cube 次案の新フィーチャーである汎用レンダーシーケンスを解説するドキュメントがいくつかあります。 Wiki、スナップショットについていたPDF、サンプルやビデオをご覧ください。このエントリでは XC と X2 のレンダリング周りのやり方の違いについて簡単に説明します。これは XOOPS Cube が XCL や X2 抜きで説明されなくてはいけない都合上、今のところ "公式" Wiki に収録が難しいものです。（将来的にはなにかの Wiki のドキュメントとマージします）

下の図を見てください:

これは XOOPS2 のテーマフォーマットです。ブロック配列のための５つのプレースホルダと、１つのモジュール用プレースホルダで構成されています。このテーマを描画するためには、テーマより先にこの６つのプレースホルダの描画が終えて、テーマからその描画結果を引き込む（引用する）必要があります。 XOOPS2 は６つのプレースホルダの存在をハードコードされており、拡張は困難でした。ユーザーは管理画面から、ブロックを５つのプレースホルダに割り当てることができましたね:

XOOPS Cube では、 CMS は特定のテーマフォーマットに対して交換不可能なハードコードを用いて直接的な関係を結ぶべきではない、ということになっています。これは多くのユーザーが望んだ仕様です。

ともかく、 XOOPS Cube は固定フォーマットを持たず、柔軟性を追求しようということになっています。しかし、技術的にどういう仕組みでそれを実装するのか？　汎用レンダーシーケンスは、「左カラム」「右カラム」といったハードコードされた固定カラムの代わりに、シーケンスIDという概念を用います。

シーケンスIDを理解することは大切です。

通常、描画の実行順とプログラムの実行順は異なっています。たとえば、テーマは CMS コアによって準備され使われますが、描画の順番でいえば一番最後になります。対して、 CMS コアというプログラムは一番最初に実行されなくてはいけません。シーケンスIDは、描画の順番とプログラムの順番を別々に扱うためのメカニズムです。

XOOPS Cube の次案では、それぞれのプログラムは直接描画を行うことはできず、シーケンスIDを持つレンダーオペレーション（描画命令）を発行することになっています。

Root のコレクタは、タスクリストを巡回してレンダーオペレーションを集めます。集めた後、描画順にソートしてからレンダリングを開始します。このとき、後ろのレンダリングはそれより前のレンダリングの結果を引用できます。テーマはこの汎用の機構を利用して各プレースホルダの描画結果にアクセスします:

もちろん、この基本的な仕組みはどんな合成にも有効です。

もう一度見てみましょう。最初、コレクタは空っぽです:

もし、コレクタが単純にオペレーションを集めてしまうと、オペレーションの集合体は以下のように順不同（アウトオーダー）になります:

しかし、コレクタはオペレーションを収集する際に同時にソートをかけていきますので、最終的には順番どおりに整えられます（インオーダー）:

それから、それぞれのレンダーオペレーションに指名された各レンダーシステムを使って順番に描画を実行します。「後ろのレンダリングは前のレンダリングの結果を引用できる」ので、最終的にはテーマが正しく描画されます:

ちなみに、このテーマのオペレーションはスクリーンバッファ役の特別なレンダーターゲットに紐づけされています。それが最終出力の結果がブラウザに出力されるカラクリです。

しかし、これはあくまでプログラマにとって有効な仕掛けであって、エンドユーザーに対しては隠蔽されていなければなりません。たとえこのメカニズムが XOOPS Cube の目的のためにパワフルであっても、 CMS (Base) はユーザーがコンテンツをプレースホルダに割り当てるために XCL や X2 のように管理機能を提供する必要があるでしょう。XOOPS Cube では、マニフェストを読み込むことで、プレースホルダの数や種類を取得し、管理画面に反映させます:

プレースホルダ情報は [Theme] チャンクに書くことになると思います。しかし、マニフェストは拡張可能でさまざまな情報を格納できますので、 Base の名前でチャンクを作って、特定の Base のために特定の情報を格納してもよいかもしれません。

ところで、プログラムはレンダーオペレーションにタグをつけておくことができます。後ろのレンダリングはタグを使って前のレンダリングの結果を引用することができます。これはパンくずリストやバナーに有効です。

汎用レンダーシーケンスはコアの固定パイプラインで、 BASE レベルで交換ができないものです。描画仕様が厳格化されたため、Legacy 以外の全 BASE の描画ロジックが確定でき、プログラムの作成や共有が容易になります。一方で、非常に柔軟性の高い仕組みなので、完全に理解すれば本当に色々なことができます。

Distributions show up and go next

2008-03-06T01:14:00.007+09:00

HDディストリビューションはリリースされました。おめでとうございます! このリリースは私たちにとって、重要なポイントです。 XOOPS Cubeはエキスパートのカスタマイジング、ディストリビューション、そして新しい BASE のためのベースモデルとして設計されました。しかし誰もそれを証明できなかったため、多くのユーザーが Package_Legacy が XOOPS2 の "公式" パッケージと同様に唯一無二のパッケージであると考え、本来の目的であるコアの開発を止めてでも Legacy の開発を行うようプロジェクトに要望してきました。

ここに、もうひとつの重要なことがあります。プロジェクトはプロジェクトの方向性について話し続けていましたが、それは長い間理解されていませんでした。原因は私が説明が上手でないということです。

しかし、今日、HDディストリビューションはプロジェクトの方向性を実践しています。私は何回も同じことについて説明する必要がなくなりました。 HDディストリビューションは日本人のユーザによって好かれますが、他のディストリビューションも登場予定です（海外）。いい感じです。

唯一無二のパッケージは、リクエストの衝突のために政治力を必要とします。Aさんが好きなモジュールをBさんが嫌いな場合。Aさんが何のモジュールも入っていないシンプルなパッケージを欲しがっているが、 B さんは便利なモジュール（Aさんが嫌いなモジュールを含む）を集めたパッケージを欲しがっている場合。ここに２つの解決策があります。プロジェクトが神となって全てに裁定を下すこと(*)。もしくはすべてを自由にすることです。

ご承知のとおり、プロジェクトは「アナーキー（無政府主義）」を採用しました。「神スタイル」が欲しいなら、xoops.orgを訪れるとよいでしょう。

しかしながら、ディストリビューションの開発が簡単ではなかった事は、改善すべき点です。たとえ、 Legacy が古すぎる設計を抱えており、プロジェクトの理想ではないとしても。プロジェクトは「マニフェスト」の検証を進めて、サンプルのダウンローダー/アップローダーをリリースしなければなりません。私は、これが最も重要な仕様の1つであると言いました。しかし、数少ない開発者がLegacyのような多くのToDoに接しなければならなかったため、これまで開発は進みませんでした。

自動メンテナンスツールが存在するならば、ディストリビューションを開発する事は簡単になるでしょう。シンプルなディスリビューションは、ただ推奨モジュールのリストが書かれているだけの１枚の「マニフェスト」ファイルかもしれません。マニフェストやアップ/ダウンロードメカニズムのような足回りを整備する事がこのプロジェクトのタスクです。

いずれにせよ、いくつかのディストリビューションのおかげで、私はコア開発に集中できるようになりました。あとは早く帰宅できるようになりたいです……

(*) XOOPS では、大して活動しない者が神になる。

Mikhail uploaded the slide to YouTube

2008-02-29T09:13:00.004+09:00

Mikhail さんが "The reasons why you should touch XC" をYouTubeに投稿してくれました。

Thanks Mikhail!

さて今日から OSC ですね。
２つほど聞きたいセッションがあったので、いきなり午後早退もなんなので、今日はもう休みを取っちゃいました。
OSC 自体久々な気がします。ぼちぼち出発します。