プログラムのチェックをしていて起こったレアなケースなんですが、珍しいものなのでメモ。

IEの６とか７で（他は会社にないので未確認ですが）フォームにテキストボックスが１つしかない場合で、プログラム内でサブミットボタンのnameやvalueで何かを制御しようとしているとき

テキストボックスにフォーカスが当たっている状態で　Enter　によるサブミットを起こした場合

「サブミットボタンのnameもvalueも渡ってこない」

という現象が起きました…

大変レアなケースですが、しかしテキストボックスが２つあったりサブミットボタンのnameやvalueは通常参照しないので今日まで気づきませんでしたが、、しかしレアケースですね。と自分にメモ。

前回、XOOPSが普及した理由として、次の3つの理由をあげました。

1．パッケージング
2．日本語対応
3．日本語情報の多さ

今回は、XOOPS CubeとNetCommonsで、この3つがどのぐらい満たされているのか検討しようと思います。

(続き…)

gusagiです。
Protectorモジュールの拒否IPに登録されてしまった場合について、書かせて頂きます。

GIJOEさんが公開しているProtectorは、全てのXOOPS Cubeユーザに導入をお勧めしたい重要なモジュールです。
しかし、モジュールの性質上、管理画面でどのように設定すれば良いのか判らない人や、Protectorで拒否リストに載ってしまった場合の対応方法が判らない方も多いのではないかと思います。

今日のタイトル「You are registered as BAD_IP by Protector.」は、拒否リストに載ってしまった場合に画面に表示される文字列です。
こうなると、最低でも管理画面で設定した時間(デフォルトだと3日間)は同じIPアドレスからアクセスが出来なくなります。
また、無期限で拒否リストに載ってしまった場合は、いくら待ってもアクセス出来ません。

こうなると、Protectorのバージョンが2の場合は復旧が面倒だったのですが、現在配布されているバージョン3の場合は、かなり楽になっています。
{XOOPS_TRUST_PATH}/modules/protector/configs/ の下に、badips******（******は任意の文字列）というファイルがあるので、これを消すことで復旧出来ます。

ただし、レンタルサーバを利用している場合、badips******はApacheが作成しているために、ファイルを削除出来ない場合があります。
こう言った場合、一番簡単な方法は、mainfile.phpに当てたパッチを一時的に解除して、管理画面で拒否IPから解除することでしょう。
(続き…)

毎日新聞の愛読者広場「まいまいクラブ」がXOOPSでできているという記事をXOOPS日本サイトで見ました。

さすが、お金がかかっているだけあってデザインが目立たないけどこざっぱりとすっきりできあがっているし、完成度高いですね〜。MyAlbumなど普通みんなが使いたがるようなモジュールがさらっと使われていて親しみを感じました。

毎日俳句や読者の投稿した写真などのコンテンツも大量にあり、多くの会員を抱えるサイトでのXOOPS活用事例としてみなさんも是非ご覧ください♪

先日、開催されたNetCommons勉強会で、何故XOOPSが普及したのか？そしてその理由とNetCommonsの共通項についても主催のtadashiさんがお話されていたので、その内容と私自身が思っていることをミックスして少し紹介したいと思います。

■何故XOOPSは普及したのか？
○理由1．パッケージング
XOOPSの配布パッケージには、サイトを構築するときに欲しいなと思える機能（モジュール）がそろっていました。
ニュース、フォーラム、リンク集、問い合わせなどのモジュールが最初からパッケージになっていたのです。
個人的に特に気に入っていたのが、フォーラムモジュールがパッケージに含まれている点でした。
2002年当時、私が使っていたPostNukeのパッケージにはフォーラムが含まれておらず、フォーラムを使おうとおもうと、自力でモジュールを探す必要があったのです。
その点、XOOPSにはオフィシャルにサポートされているフォーラムがあるというのが魅力的でした。

○理由2．日本語対応
英語圏で開発されたシステムを使う際に、自分一人が使うのなら英語のままでもガマンして使うことも可能です。
しかし、ホームページのように、他の人に使ってもらうシステムでは、英語メッセージのままでは使いにくいので、日本語化する必要がでてきます。

この点もPostNukeでは、オフィシャルなパッケージには日本語ファイルが含まれておらず、別途日本語ファイルを別サイトからダウンロードしてインストールする必要がありました。

一方XOOPSは、パッケージに日本語ファイルも含まれた状態でした。また、別途公開されている非日本語圏のモジュールも、積極的に日本語化をすすめているサイトがあり、システムメッセージの日本語化作業はほとんど行わずに済みました。

システムから送信されるメールも他の英語圏のシステムに比べると文字化けが少なく、使ってみようという気にさせる質でした。

○理由3．日本語情報の多さ。
私がPostNukeからXOOPSへの乗り換えを決めたのは、XOOPSの方が圧倒的に日本語情報が多いという点でした。
また、国内に利用ユーザが多く、情報交換が活発だったというのも大きな乗り換え理由になりました。

PostNukeを使っているうちに、PHPの読み書きが多少できるようになってきて、バグを自力で修正したり、ちょっとした改造もできるようにはなってきたのですが、それを英語でフィードバックすることが私にはできませんでした。
そのため、新しいバージョンがリリースされるたびに、また同じバグ修正をしたり、改造を適用したりしていました。これ、積み重なるとかなり手間です。
その点、XOOPSなら日本語でバグとその修正方法を報告できる。また、開発方向がどうなっているのか、日本語で開発者とやりとりもできる。この点は非常に魅力的でした。

以上3点が、XOOPSの普及した大きな理由だろうと私は思っています。

これを読んで、「おや？」と思われた方もいると思います。「技術的な優位性はなかったのか？」「モジュールが作りやすい構造になってたからじゃないのか？」そう思われる方もいると思います。そのような理由よりも上記3点の方が普及理由としては大きかったんじゃないかと私は思います。

# もちろん理由4以降もあげると、Smartyの採用（テンプレートの分離）とか、PostNukeより動作が軽快だったかもありますが。。

さて、これを元にXOOPS CubeとNetCommonsがどの程度普及要因を満たしているか検討してみようと思うのですが、長くなってしまったので次回（木曜日）に掲載します。

とあるサイトで、GIJOEさんのお手軽高速化Hackを使ってみて便利だったので、より導入しやすいようにSmartyプラグイン化してみました。
ついでにちょっとオプションを追加してあります。

・function.redirect_message.zip

■使い方

○STEP1プラグイン配置
解凍してできたファイルfunction.redirect_message.phpをSmartyのプラグインディレクトリにアップロードします。

デフォルトでは、XOOPS_ROOT_PATH/class/smarty/plugins/ です。

Smarty プラグインディレクトリの拡張 preload “ryusSmartyPluginsEx” か GIJOEさんのHdXoopsTplHook.class.phpをお使いの場合は、XOOPS_TRUST_PATH/libs/smartyplugins/ になります。

○STEP2theme.html編集
ブロックで表示させたい場合は、theme.htmlの冒頭に次のようなコードを挿入してください。

<{redirect_message target_block=cc title="メッセージ"}>

target_blockには表示させたい位置を指定します。
b:左ブロック
r:右ブロック
cc:中央−中央ブロック
cl:中央−左ブロック
cr:中央−右ブロック

titleで、ブロックタイトルを指定します。

ブロックで表示せずに、theme.html上で表示させたい箇所でプラグインを使うという使い方もできます。
その場合は下記のようにtarget_blockもtitleも無指定で使います。

<{if $smarty.session.redirect_message}>
<div id="redirect_message">
<{redirect_message}>
</div>
<{/if}>

○STEP3legacy_redirect.htmlの編集
管理画面の互換レンダーシステム→テンプレートファイル管理で、legacy_redirect.htmlを次のように編集します。

<{php}>
  if( ! headers_sent() ) {
    $_SESSION["redirect_message"] = $this->get_template_vars("message");
    header("Location: ".html_entity_decode($this->get_template_vars("url"),ENT_QUOTES));
    exit;
  }
<{/php}>

※XOOPS2の場合は、GIJOEさんが書かれたお手軽高速化!:-) updatedを参考にinclude/functions.phpをかきかえてください。

これで、リダイレクト画面無しで、次の画面に遷移してから、リダイレクトメッセージが表示されるようになります。

■応用編
script.aculo.usと組み合わせて、

	<{if $smarty.session.redirect_message}>
	<div id="redirect_message">
	<{redirect_message}>
	</div>
	<script>new Effect.Fade('redirect_message',{duration:3});</script>
	<{/if}>

こんな感じにして、徐々にリダイレクトメッセージが消えるようにするのもいいかもです。このサイトは、このようにしてあります。

■2007-11-22 20:50 追記
動作の雰囲気は下記を参照してください。
redirect_sample動作イメージ

gusagiです。
今日は、特定IPだけPHPデバッグを有効にするpreloadについて書かせて頂きます。

XOOPS Cubeに限らず、プログラムによる動的なサイトを運営していて障害が発生した場合、デバッグ情報が必要となることがあります。
XOOPS Cubeの場合、デバッグ設定は管理画面から設定出来ますが、公開中のサイトでデバッグ情報を公開する場合、セキュリティ的には宜しくありません。
かと言って、「画面が真っ白 」な状態では、デバッグ情報がないと原因追及も困難となってしまいます。

XOOPS Cubeの場合、以下のプリロードを利用することで、特定のIPアドレスだけPHPデバッグを有効とすることが出来ます。

下記は、「192.168.1.XXX」からのアクセスだけ、PHPデバッグを有効とする場合です。

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

	
if ( ! class_exists('AdminDebug') ) {
    class AdminDebug extends XCube_ActionFilter
    {
    	function preFilter()
    	{
    	    $remoteAddr = $_SERVER['REMOTE_ADDR'];
            // PHPデバッグを有効とするIPアドレスをシングルクォートで囲った上で、カンマ区切りで記入。
    	    $allowIps = array( '192.168.1.' );
    	    foreach ( $allowIps as $key => $allowIp ) {
    	        if ( strstr($remoteAddr, $allowIp) !== false ) {
    	            define( 'OH_MY_GOD_HELP_ME', 1 );
    	            break;
    	        }
    	    }
    	}
    }
}

このコードを、「AdminDebug.class.php」という名前で保存して、サーバのXOOPS_URL/preloadにアップロードするだけでOKです。
※「192.168.1.」の箇所は、環境に合わせて書き換えて下さい。

ちょっとしたプリロードですが、皆さんの参考になれば幸いです。

先週に引き続き　Ruby on Railsの研究をしています。

ローカル環境で動くようになっているので色々試し始めました。とっかりにと思ってAmazonで一番評判が良かった本を買ったのですががちょっと今の時点ではわからないかもと感じてきました。急遽昨日追加で本を買ってきました。自分としては最初の１冊はこれをお勧めします。

1日目、2日目と進んでいき10日目にはサーバーでの公開、ができるようです。プログラムの種類も一通りの作り方が身につくのではないかと思います。本の中味ですが最初はとりあえず書いてあるとおりにコーディングして実際に動かしてみる。そのあと各コードについて詳細な説明があるという流れになっていて、これが自分にフィットしていてわかりやすいです。

今のところ2日かかって2日目がようやく終わるというところで結構がんばらないと日にち通りには進みそうにないです。

まだ2日目というところなので語るのもあれですが、Ruby on Railsってなかなかいいです。勘ですが、ものすごく合理的で無駄がない、かつデータベース設計の世代管理やプログラムの本番用、テスト用、開発用まで標準で考えてあるあたりがいいです。またコードもすっきりとしていて見やすいです。

また、ちょっとでも動くものができると「公開したい！」という虫が騒ぎ始めました。調べたところ今使っているサーバーで動かすのは難しそう（あるいは危険そう？）なのでrorが使える共有サーバーを申し込みました。

ワイズノットさんがやられている
共有Railsレンタルサーバ
http://www.wiseknot.co.jp/network/index19.html

です。まだ開通していないのですが、こちらで公開されたWEBでrorを見せられる日が楽しみです〜。

当社スタッフgusagiのプライベートサイト「ぐさぎ どっと こむ」が復活したので、ご紹介します。

・ぐさぎ どっと こむ
　http://www.gusagi.com/

先日、書いた「FCKeditor on XOOPS をカスタムブロック編集画面に組み込む。」をハック無しで実現する方法についても早速触れられてます。

・カスタムブロック編集画面にFCKeditor on XOOPSを組み込む

# 管理画面のテンプレートもオーバライドできるとはしりませんでした(^^;

おそらく、今後もXOOPSネタをガシガシBLOGに書いてくれると思うので、皆さんも期待してRSSリーダに登録しましょう！
私も早速RSSリーダに登録しました。

今日は金曜日なのでRYUS定例の「ふりかえり」をしました。一週間の間にあったいろんなことを振り返る貴重な時間です。

その中で天野が便利ツールをいくつか紹介したのですが、聞いてすぐに使って役立ったものがあったのでご紹介します。

ペースター
http://homepage2.nifty.com/autumn-soft/

フリーソフトだったりシェアウェアだったりした時期があったようですが今現在は1050円のシェアウェアとなっています。でも30日間試用ができるのですぐに使ってみることはできます。

ペースターとは編集中にコピー＋ペーストすることは多いですね。今コピーした一つ前をペーストしたいとかいくつか部分的にコピーしておいてあとでまとめてぺーストしたいってことが可能になるツール、それがペースターです（ほんとはもっとすばらしい機能がいっぱいあるようですがまだわかってません）。

すぐに役立ったという私の例でお話しします。今日は　うさぎにもできるXOOPS Cube入門♪　に懸案のモジュールを使う、という部分の説明を絶対にアップするのだ〜と気合いが入ってました。モジュールを説明するということだけでなく書いているうちにXOOPSの基本的な操作や、表示についても説明しないとわからない…、とコンテンツを作り続けていたらテキストページだけで７，８ページになってしまいました。

これを　うさぎにもできるXOOPS Cube入門♪　にコンテンツとして表示するにはマンガの顔とか画面のハードコピーをhtmlに組み直して貼り付けないとなりません。今まで相当数のページを作ってきたので絞りに絞り込んで4パターンの組み方でできるようになっています。けれど今まではこの方法を　あ、このセリフはパターン１　だからテンプレート用のテキストからパターン１をコピーしてきてペーストして、　でもって次のセリフはパターン２　だからコピーしてペーストして…、という繰り返しを延々としていました。

この場合困っちゃうのは１回コピーしても次に違うものをコピーしちゃえばもうコピーにはなくなってしまうのでコピーするところからやり直さなければいけないことです。

ところがペースターを使うと、あらかじめ４つのパターンを１回ずつコピーしておきます。そしてそれ以上は記憶しないようにペースターに命令しておきます。あとはテキスト文章のペーストしたいところでctrlキーを２回続けてクリックするとおぼえている４つのパターンがポップアップされるのでそのときに必要なコピーをクリックするだけでペーストが完了する、っていうことです。

このツールがあったおかげで、うさぎにもできるXOOPS Cube入門♪のコンテンツを作るのも飛躍的に速くできました。実感として半分ぐらいの時間でできたのではないかなーと感じています。

良い道具はソフトウェアでも大事ですねー。

「FCKeditor on XOOPS を試してみました。」 という記事へのコメントで、カスタムブロック編集画面への組み込みについてご質問いただいたので、さきほど実験してみました。

XOOPS Cube Legacy2.1.x なら、カスタムブロック編集画面のテンプレートを編集するだけで FCKEditor on XOOPS（以下 fckxoops） を組み込むことができます。

カスタムブロック編集画面のテンプレートファイルは、/modules/legacy/admin/templates/customblock_edit.html です。

このファイルの冒頭に以下を挿入します。

<script type="text/javascript" src="<{$xoops_url}>/common/fckeditor/fckeditor.js"></script>
<script type="text/javascript">
function fckeditor_exec(width, height, url) {
	var area_width = width;
	var area_height = height;
	var xoops_url = url;
	var oFCKeditor = new FCKeditor( "content", area_width, area_height, "Default" );
	oFCKeditor.BasePath = xoops_url + "/common/fckeditor/";
	oFCKeditor.ReplaceTextarea();
}
</script>

つづいて、テキストエリア表示箇所を修正します。

<{xoops_dhtmltarea type=text name=content value=$actionForm->get('content') rows=20 cols=60}>

と書かれている行を

<textarea id="content" name="content"><{$actionForm->get('content')}></textarea><script>fckeditor_exec("100%", "350", "<{$xoops_url}>");</script><br />

に変更します。

これだけで、カスタムブロック編集に fckxoops を使えるようになります。
もちろん fckxoops は事前にインストールしておいてくださいね。

gusagiです。
今日は、XOOPS Cube Developers Group Japanを紹介させて頂きます。

XOOPS Cube Developers Group Japanは、10月28日(日)に開催された第一回XOOPS Cube Developers Meeting（以下、XCDM）で「日本人の開発者が活発に意見交換を出来る場所が必要ではないか？」という意見がきっかけで出来た、情報交換を行うための場です。
上記の情報交換は、XOOPS Cube日本サイトで行われていた「開発絡みの質問や意見を契機にした、アイデアの交換やその是非についてのディスカッション」と置き換えても良いかも知れません。
かつては、XOOPS Cube日本サイトが情報交換の場となっていたのですが、現在ではXOOPS Cube日本サイトを含めて、開発者向けの場は無くなっていました。そこで、XCDMをきっかけとしてnobunobuさんを始めとする有志がGoogle Groups上にXOOPS Cube Developers Group Japanが開かれたのです。

XOOPS Cube Developers Group Japanは、名称に「Group」とありますが、sf project、cube.jp、xugj.org に続く第4の「組織」ではありません。
ディスカッションを行うための場所であり、ディスカッションによって生まれたアイデアを形にし、それを公開するための場所です。
ここでは、かつてコアチームと呼ばれていた人たちも、モジュール開発者も、デザイナーも、全員がフラットな立場で意見を言うことが出来ます。

まだ開設されたばかりですが、今後は様々なディスカッションが行われると予想されますので、興味のある方は一度足を運んでみては如何でしょうか？

この業界に身を置いて早や…、四半世紀ぐらい？が過ぎようとしているんですが、ソフトハウスと呼ばれるいわゆるソフト専業会社の内情は意外とお給料が手計算だったりして（小さいところは、ですが）紺屋の白袴ということが多いです。

RYUSもXOOPS専門に開発やカスタマイズをしてきましたが、内部での連絡についてはXOOPSを使わないままで来てしまいました。とりあえずはてなグループやgoogleカレンダーを使ったりして間に合わせています。

しかし、こんなことではいけない！ということでRYUSの内部の連絡用にこっそりとXOOPS Cubeでグループウェアを作り始めました。とはいえまだ既存のモジュールをちょっとカスタマイズする程度ですが。やはり1つのサイト、1つのデザインで管理できるのはいいなぁ、と改めて感じています。

良いモジュールでも開発できればXOOPS Cube社内グループウェアディストリビューションなどできたらいいなという野望も持っております。

cubsonでコードを生成すると、XoopsSimpleObjectを継承した、{TableName}Object クラスが作成されます。

例えば次のようなコードです。

class Foo_FooObject extends XoopsSimpleObject
{
    function Foo_FooObject()
    {
        $this->initVar('foo_id', XOBJ_DTYPE_INT, 0, true);
        $this->initVar('title', XOBJ_DTYPE_STRING, "", true, 255);
        $this->initVar('note', XOBJ_DTYPE_TEXT, "", true);
    }
}

コンストラクタでは、テーブルの各カラムについてinitVarメソッドを呼び出してでデータ型や、デフォルト値などを設定しています。
設定内容は、$mVarsにカラム名をキーとした連想配列で保存されます。

ほとんどのケースでは、cubsonが自動的に生成したコードで使えますが、時にはちょっと変えたい場合もあります。

変更したいときに変更できるようにするために、cubsonでは、DB情報を毎回取得して設定する方式でなく、事前にDB情報を元にコードを吐き出す形になってます。

ただ、よーく考えたら、initVarの実行結果は$mVarsに入るので、DB情報を取得してinitVarするようにしても問題なさそうです。

そんなわけで、DB情報を取得して、initVarしてくれるようなDynaXoopsSimpleObjectをちょっと試しに作成してます。
使い方としては

class Foo_FooObject extends DynaXoopsSimpleObject
{
}

で、先ほどのcubsonコードと同じようにinitVar。
noteカラムだけinitVarを変更したくなったら、

class Foo_FooObject extends DynaXoopsSimpleObject
{
    function Foo_FooObject()
    {
        parent::DynaXoopsSimpleObject();
        $this->initVar('note', XOBJ_DTYPE_TEXT, "Fooooo!!", true);
    }
}

と書けばOK

というようなのを作りたいなと(^^;
えぇ、まだ作成途中です。。。。

ただ、オブジェクト生成のたびにDBから情報取得するんじゃムダなので、そこはキャッシュ必要だなぁとか、いろいろ考えてます。

これができたら、ActionFormやActionFilterでもできないかなぁと夢想しています

PS
# exFrameのDynaXXXXは、どうもなじめなかったんで、設定ファイルを使わないDynaXXXXをつくってみようかなと。そんなわけで「Dyna再チャレンジ」です(^^;

XOOPS CubeとNet Commonsは、どちらもXOOPS2から派生したCMSですが、それぞれ全く違うポリシーのもとに開発されています。

まず、XOOPS Cubeですが、こちらは「自分で自分好みに組みたてる」という使いた方が前提となっています。

XOOPS Cube Legacyのパッケージをダウンロードしても、掲示板も問い合わせフォームも、何もアプリケーションらしいものは何もついてきません。
自分で使いたい機能を持ったモジュールを探して、インストールして使います。
欲しい機能を持ったモジュールがなければ自分で作っちゃえ！作ったら公開して、みんなで使おうよ！という感じで、開発成果をオープンにする文化です。

一方Net Commonsは、「いろいろな機能がパッケージングされいて、完成品をそのまま使う」という使い方が前提になっているようです。
最初から、パッケージに掲示板やBLOGのモジュールがついていて、パッケージについているモジュールをそのまま使う。様々な機能をもったモジュールを最初から提供するので、その中から組み合わせてサイトを構築してくださいという感じです。
そのため、趣味でちょっとモジュールをつくってみようという開発者も今のところ居ないように思えます。

このような違いがあるので、趣味でいじってみるなら、断然XOOPS Cubeの方がおもしろいと、私は思っています。

では仕事で使うならどっちがいいのか？
まだまだXOOPS Cubeの方が良いと私は思います。
Net Commonsは、公開されている情報が少なすぎて、業務上カスタマイズが必要となっても、頼める業者を探すのにも苦労しますし、誰かにサポートを依頼しないと運用時に困ったときに自力で解決するのが非常に困難です。

一方XOOPS Cubeなら、公開されている情報が多いのため、困ったときに自力で解決できる可能性も比較的高く、情報がオープンになっているので、その情報を元にカスタマイズできるという技術者も多く存在します。

というわけで、現段階で私が感じているXOOPS CubeとNet Commonsの違いについてちょっと書かせていただきました。

毎年一回、母に頼まれて同窓会のお知らせ往復はがきを刷っています。毎年のことなのでデータベースはaccessでできているし、表面裏面のフォーマットも完璧です。

だからはがきさえ買ってきて、１年の間に引っ越しをした人の住所変更をし、あとは刷るだけ…のはずなのですが毎年何かの問題でひどく大変な思いをします。

今年は裏面は問題なくスムーズに刷れたのですが、表面に入ったとたんプリンタが「紙詰まり」の連続で2割ほどのはがきをだめにしました。おそらく一度刷ったとういことで往復はがきが反ってしまいそのために紙詰まりが起こってしまうようです。

何度かの紙詰まりを直している間にネットで往復はがきの印刷をしてくれるところを探したところ、はがき代の他に7000円ほどで刷ってくれるところもありました。

経費がないから、と頼まれて毎年刷っていますが用紙の準備、テスト印刷、印刷にかかる時間はおそらく7時間ほどかかってしまいます。それを考えると

・プロに頼んできれいな印刷をしてもらって7000円！

というのは大変効率的だし、経済的だと思いました。

こんなことから、私たちが業務としているXOOPSについてもそのようなことあるのではないかな〜、そういう方に効率的と思われるPRもしていきたいなと思いました。

gusagiです。
今日は、セッションテーブルが壊れてログイン出来ない場合の対処法を書かせて頂きます。

XOOPSでは、セッション情報を{prefix}_sessionというテーブルに保存しています。
(注){prefix}はインストール時に設定するもので、mainfile.php内の[XOOPS_DB_PREFIX]として記述されている値です。
このテーブルが何らかの理由で壊れてしまうことがあるのですが、そうなると管理者も含めて、全てのユーザがログイン出来なくなります。
自分でサーバ管理をしている人の場合は、上記のテーブルを修復すれば良いのですが、レンタルサーバなどでDBを直接弄ることが難しい人もいるかと思います。
そんな場合、XOOPS Cube Legacyをご利用の方でしたら、以下の方法を試してみて下さい
(続き…)

のことを書く予定はなかったのですが、ネタに詰まって書きます。

弊社天野よりなんとなくRuby on railsがいいらしい、と聞かされていてたまたま今日ちょっとだけ時間があまったのでインストールに挑戦しました。

会社にあったムックを頼りにRuby本体を入れ、ワンクリックでインストール。その後gemというものを入れてインストール…というところで詰まりました。ローカルのwindowsで試していたのですがムック本での説明は途中からunixのものになっていて一応やってみたのですがパスが通らないとか色々あって…しかしなんとかインストールするところまでは行けたようです。想像ではrubyのインストールをしたあとにする処理が一つ抜けていたのかもしれません。

というところまでしかできていないのでまだ何もわかってないんですが、イメージでは「テーブルがあれば基本的なソフトが簡単にできる。他にも色々いいことがありそう」という期待を持っています。

今後なにかお見せできるものができるといいんですが！

いたれりつくせりの重量級フレームワークが多い中、総ファイルサイズ38kバイトという超軽量のPHPフレームワークがあることを先日知りました。

・ちいたん

作成動機にすごく同意してしまいます。
引用：

cubsonでのモジュール開発に慣れてしまうと、ちょっとしたものでも、一から作る気にはなれない。
でも、XOOPS Cubeを入れるほどでも無い。

そんなときに、XOOPS Cubeのモジュールとして開発するのか？
それとも、一からコツコツと書くのか？

これ、けっこう悩みます。

そんな、どっちでいこうかなぁと悩むようなプログラムを作成するときに、自分が使い慣れているフレームワークの軽量版があれば確かに便利だと思います。

ただ、今度は、どこまでその軽量版で開発して、どっからメインのフレームワークで開発するのか、その使い分けに悩みそうな気もしますが(^^;

それでも、ちょっとしたことにサクッと使える軽量フレームワークという考え方はいいなぁと思います。

先日NetCommons研究会に参加させていただきました。

・Net Commons

研究会でいろいろな方からお話を聞くことができたのですが、その中で私が気になったのはXOOPSよりもNetCommonsの方が使い方に統一感があって、お客様に提案しやすいという声でした。

たしかに、NetCommonsは、国立情報学研究所一カ所のみで開発されているのに対して、XOOPSは多くの人がそれぞれ自由にモジュールを開発しているので、ユーザインターフェースが統一されているとは言い難い状況です。

ユーザインターフェースはバラバラよりも一定のポリシーでまとめられている方がわかりやすいのは確かです。

そのユーザインターフェースの統一以外に、どんな良さがNetCommonsにあるのか？
カスタマイズしたいときはどうしたらいいのか？
NetCommonsは、XOOPSをベースにして開発されたのですが、何を実現させようとして今の形になったのか？

気になることがいろいろ出てきたので、自分自身でいろいろさわってみようと思い、インストールしてみました。

・NetCommons実験室

いろいろ実験してみて、良さそうな点はXOOPSでも実現できないかを検討してみたいと思います。