かばだんなさんかく語りぬ

CakePHP ＋ DebugKit でApache子プロセスダウン

Fri, 18 Sep 2009 18:32:44 +0900

めっきりアーキテクト兼SE兼PGのかばだんなさんです。

CakePHPで開発していて、最近開発効率を上げようとDebugKitを使っているのですが、ある画面を表示するとApache子プロセスがダウン・・・ Orz

原因はともかく対処方法だけは分かったので、メモします。

とりあえず分かった事。

【環境】

PHP：5.2

Apache：2.2

CakePHP：1.2.3

DebugKit：1.1

【下記の条件に１つでも当てはまらない場合には発生しない】

core.phpでDEBUGモードに設定されている。（「Configure::write('debug', 2);」）
DebugKitを使っている。
コントローラでコンポーネントを使用している。（例：「var $components = array('Tel');」）
画面(xx.ctp)でコンポーネントを使用しようと、画面にコンポーネントのインスタンスを引き渡している。（例：「$this->set('tel', $this->Tel);」）
画面(xx.ctp)でコンポーネントのメソッドを呼び出している。（例：「echo $tel->visibleTelNo();」）

自分で気づいてないだけで他にも条件があるかもしれないので、「発生条件」とはしていません。ただここに書いた条件を外した場合には子プロがダウンしない事は確認しています。

よくよく考えてみると、（CakePHP1.2の設計思想を考えると）上記４のようにコンポーネントごと画面に引き渡すのは手を抜き過ぎですね（＾＾；

大人しくコントローラでコンポーネントメソッドの返り値を取得して、普通に連想配列の形にして画面に引き継いだらうまく動きました。

いや～しかしこのDebugKit、便利なのは認めるけど・・・遅いよ（苦笑。私の貧弱な環境だと、ちょっとした画面でもレスポンスが１～1.5秒ぐらい遅くなります。たった１秒とはいえ、開発中に１秒思考が切れるのは問題です。使い所に検討が必要かも・・・。

タグ： cakephp

CakePHPのプラグインで画像ファイルを使う

Sat, 12 Sep 2009 19:58:49 +0900

CakePHP1.2.3でプラグインを作っているのですが、自作プラグインの画像をどうやって呼び出したらいいのかずっと分かりませんでしたが、ようやく分かったのでメモしておきます。

例えば仮にプラグイン名を「aaa」とします。で、各種ファイルを格納するディレクトリを下記のような構成で配置します。

(ディレクトリ構成。必要な物しか書いてないです。)

で、このような構成でimgの下に画像ファイルを置きます。ヘルパを利用して画面表示する場合には、

echo $html->image('/aaa/img/cake.icon.gif', array('alt'=>'画像です')

です。「あれ？vendorsは？」って感じですがこれも人生。

ちなみに注意が必要なのは、

ディレクトリ名は「img」。

通常CakePHPで「http://localhost/testアプリ/aaa/img/」にアクセスすると（aaaはプラグイン名なので）「imgはコントローラ名」とみなされますが、リクエストに「img」という魔法の言葉を見つけたらCakePHPは「これはコントローラ名じゃない！」と判断します。後述しますが「/css」「/js」も同様です。

従って、例えば画像ディレクトリを「image」にして、呼び出し側を「$html->image('/aaa/image/・・・」としても、画像はうまく読み込めません。

ん？じゃあimgというコントローラ名は使えないのかって？そうでもありません。その理由は次の注意点をご覧ください。

使える拡張子は限定される（多分）

多分、imgに置いて画像ファイルと認識してもらえるのは、ファイル拡張子が「jpg, gif, png」のファイルだけです。

ソースをじっくり読んだわけじゃないので明言できませんが、ちょこっと試した所では「.tif」「.ico」「.jpz」、どれもダメでした。そもそも「imgがコントローラ名じゃなく画像置場のディレクトリ名」という先程の判断も取り消されます。（おめでとう！ imgというコントローラ名は使用できます！）

従って「どうしても他の画像フォーマットを使用したい！」「どうしても画像ファイルの拡張子を変更したい！」という場合には、（独自の画像出力機能を実装して）ストリームとして画像レスポンスを吐き出してやる必要があります。

こんな感じで制限はあるのですが、プラグインでも画像を使えるのは助かります。

あ、ちなみに、imgディレクトリの下のサブディレクトリは自由に作れます。うむ、これは助かる。

ご参考：「JavaScript、CSSの場合」

理屈は一緒なので省きますが、例えば外部のCSS,Javascriptファイルを使いたい場合、それぞれヘルパを使った呼び出し例は下記の通りです。

echo $html->css('/aaa/css/kaba',null,null, false);echo $javascript->link('/aaa/js/kaba', false);

この例ではそれぞれ「<link href="/testアプリ/aaa/css/kaba.css" type="text/css" rel="stylesheet" />」「<script type="text/javascript" src="/testアプリ/aaa/js/kaba.js"></script>」というタグを出力します。ちなみにこの命令はどこに書いても、（最後のオプション「false」を設定してあるので）タグは<head>タグ内に出力されます。

お役にたてばいいのですが・・・。

タグ： cakephp

H2B打ち上げ成功

Fri, 11 Sep 2009 09:22:01 +0900

昨夜、H2Bロケットの打ち上げに成功しましたね。

インターネットで生中継をしていたので、私もリアルタイムで見てしまいました。いや～、宇宙に興味のない私が、色気もなんもないJAXA職員の淡々とした進行でもドキドキしながら発射の瞬間を待ってたぐらいですから、好きな人には堪らんイベントでしょうね～。

このリアルタイム中継、最初私はニコ動で見ていたのですが、途中で「有料会員が来たから出てけ！」と弾き出されたので、JAXAのサイトから見ました（苦笑。

うむ、それにしてもJAXAがこういう仕組みを自前で持っていたとは知りませんでした。そりゃあそれぐらい朝飯前の技術力を持っているのは分かりますが、こうも情報公開に積極的とは。すげぇよ、JAXA。聞く所によると最近の子供たちは技術離れが進んでるそうですが、こんなもん生中継すれば何よりの「動機づけ」の教材になりますよね。

これを契機に技術屋志望の子供たちが増えるといいなぁ～。

ちなみに私は「発射の瞬間」以上に「発射台への輸送シーン(15倍速)」の方がテンションが上がりました。えぇ、サンダーバード世代ですから（笑。

敗軍の将、兵を語らず・・・・って古い？

Mon, 31 Aug 2009 14:41:08 +0900

選挙、大きく動きましたね。

誰かが今回の動きを「シンドローム」と表現していましたが、まぁそんな気がしないでもありません。

日本人の基本行動パターンだと思っていた「土壇場の揺り戻し」も有りませんでしたしね。

何か今回は私の中での「日本人観」が大きく揺らいだ気がします。

何より気になったのが、敗因として「逆風逆風」言いまくる人の多さです。「まだ言うか」って感じです。

この気持ちは選挙前の土壇場まで「こんな大将じゃ戦争できん」と公の場で言うのを聞いて「それ言うか」って思ったのと似ています。

これって例えば普通の企業で、お客さんから「おたくのｘｘｘさん、対応悪いんじゃない～？」と言われて、「そうなんですよ～、僕も困ってるんですよ～」って言ってるようなもんですよ。例え普段からそう思っていても、公式の場で言っちゃいかんでしょ。普通公の場なら、「申し訳ありませんでした。持ち帰って皆で検証して、早急に改善したいと思いますので。」とか何とか言いません？

え？あれ？僕の感性、歪んでます？？

選挙の当落なんて単純な要因では決まらないはずなのに、じゅっぱひとからげに「逆風が激しくて・・・」って、大人のコメントじゃない気がします。少なくとも公式の場では。敗軍の将は兵を語ってはいかんのじゃないでしょうか。

ん？おや？私の発想、古いですか？？

いや、別に自民党嫌いってわけじゃないですよ？政権政党としては一定の評価はしていますし。（かばだんなさん、減点法ではなく加点＆減点法なのよ。）

もちろん総理大臣の肩持ってるわけじゃないですよ？いくらかばだんなさんの生まれた病院が麻生飯塚病院だからって。

（ところでこの病院、株式会社麻生の系列病院です。で、この会社の前社長、さっき記者会見やってた総理大臣です。）

・・・と、かばだんなさんの出生の秘密が明らかになった所で、本日はここまで（笑。

ん？出生の秘密ってほどでもないだろうって？だってそんな大層な秘密なんてないんだもん～（苦笑。

メールが送れなくなってました・・・

Sun, 23 Aug 2009 00:14:58 +0900

時々ですがこのブログを見てメールを下さる方がいます。本当にありがたい事です。

そういえば最近メール来ないな～更新してないからな～と思っていたら、このサイトから私宛にメールが送れなくなっていました Orz

という事で告知です。

ここ２週間ぐらいの間にかばだんなさんにメールを下さった方、申し訳ありませんがメールが送信されていません。お手数ですが再送頂けましたらシッポ振って喜びます！

しばらく更新さぼって久し振りの更新がこれかよって感じですね。

色々あったんですよ。仕事の中の事をほとんど書けないのはこれまで通りにしても、プライベートでも「モミアゲ事件」とか「ブルーマウンテン事件」とか「赤い木曜日事件」とか。

どれも時機を逸してまで書く程でもないような内容ですが（苦笑。

I 社長の事

Wed, 22 Jul 2009 16:20:52 +0900

先ほどFAXが来て、ある会社のＩ社長が亡くなったとの知らせを受けました。

Ｉ社長の知己を得て７年。協力会社の社長としてもお客さんとしても大変お世話になりました。

ちょうど１か月前に社長からお電話を頂いて、いつになく弱気な発言が多かった社長にかばだんなさんが「社長の所に回せる案件を一生懸命探しますから頑張って下さいよ」と申し上げたのが最後の会話でした。

そして昨日、ようやく仕事を見つけて社長にお電話を差し上げたのですが、病の進行の方が早く、間に合いませんでした。

豪胆にして温情家のＩ社長。客のはずの私もよく怒鳴られました。でも悪い事を悪いとして率直にお詫びすれば、「仕方ねぇなぁ」と言いながら温情をかけて下さいました。弊社設立後も何かにつけて「お前んとこどうだ？」と声をかけて下さいました。この業界の展望、お互いの会社の方向性、今もそのお声は耳に残っています。

社長、ありがとうございました。忘れません。

尚、社長御存命中にかばだんなさんが間に合わなかったのは痛恨の極みですが、社長が大切に大切に育て上げられた強者揃いの会社と私共の関係は何ら揺らぐ事はありません。これは弊社としての公式見解です。

衷心よりＩ社長の御冥福をお祈り申し上げます。

IISで携帯の振り分け

Fri, 17 Jul 2009 00:42:11 +0900

もう随分前ですが、IISで作ったサイトでPCと携帯を振り分けしようとして失敗した話はここに書きました。

あれから３カ月、寝る間も惜しんで原因を追求し続け（もちろんウソ）、このたびようやく解決しました。

一抹の徒労感を添えてここに方法をさらします。

例えばこんなディレクトリ構成だとします。

Apacheであればドキュメントルート（「/」）に下記3行のように書いた.htaccessファイルを置きます。

.htaccess

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (^DoCoMo|^KDDI|^Up.Browser|^SoftBank|iPhone|iPod|^vodafone|^J-PHONE|Y!J-SRD|Y!J-MBS|Googlebot-Mobile|-Mobile|_Mobile|^Nokia|^ASTEL|^DDIPOCKET|jigsbrowsersweb) [NC]
RewriteRule ^(.*)$ http://かばだんな.com/mobile/$1 [P,L]

この例ではHTTPリクエストのユーザーエージェントを見て、それが携帯の場合に「/mobile」以下のページを呼び出しています。赤文字の部分が携帯と判断する条件ですね。

で、同じ事をIISでやろうと、このファイルを「URL Rewrite Module」のインポート機能で喰わせます。（インポート手順は別サイトに書いておきました。）

・・・動きません。ここまでは前回と一緒。

ここでIISマネージャで見てみましょう。ちゃんとインポートされていれば下記のような画面が見えるはずです。

面倒なので結論を言いましょう。間違ってるのは「Rewrite URL」のところです。

ここにホスト名を入れてはいけません。この例でいくと正解は「/mobile/{R:1}」です。

(ホスト名の名前解決ができないだけかと「http://127.0.0.1/」も試してみましたがダメでした。)

この部分を修正したらこれまでの不義理がなかったように素直に振り分けてくれました。

・・・そうですか。

・・・そう来ましたか・・・。

ちょっとグッタリしてきましたが続きです。

上記のGUIの情報の正体はただのXMLファイルですので、インポートが面倒ならドキュメントルートに下記のファイルを置くだけでOKです。

web.config

<?xml version="1.0" encoding="UTF-8"?><configuration>  <system.webServer>    <rewrite>      <rules>        <rule name="Imported Rule 1" stopProcessing="true">          <match url="^(.*)$" ignoreCase="false" />          <conditions logicalGrouping="MatchAll">            <add input="{HTTP_USER_AGENT}" pattern="(^DoCoMo|^KDDI|^Up.Browser|^SoftBank|iPhone|iPod|^vodafone|^J-PHONE|Y!J-SRD|Y!J-MBS|Googlebot-Mobile|-Mobile|_Mobile|^Nokia|^ASTEL|^DDIPOCKET|jigsbrowsersweb)" />          </conditions>          <action type="Rewrite" url="/mobile/{R:1}" />        </rule>      </rules>    </rewrite>  </system.webServer></configuration>

今回の例ではリライトですが、<action type="">を修正すればリダイレクトにする事もできます。

以上、実は携帯との振り分けは簡単でした。というお話しでした。

タグ：携帯サイト htaccess iis

ブログへの怪しげなアクセスをはじく

Tue, 14 Jul 2009 22:55:07 +0900

最近・・・でもないのですが、このブログのアクセス数の上昇に比例して、「怪しげなリクエスト」が増えています。例えばログを見るとこんなアクセスが来ています。

http：//このサイト/xxxx.php?_SERVER[DOCUMENT_ROOT]=http://www.●●●●●.com/ua/pid.txt???

気持ち悪いですね～（苦笑。試しに●●●●●の部分を私の持ってる別サーバにして何かパケットが飛んでるか調べたのですが、何も飛んでません。でも怖いですよね。

今は問題ないのかもしれませんが、心配なのはGeeklogがバージョンアップしたタイミングです。こればかりは「絶対」という事はあり得ませんからね。という事で今回は、あからさまに怪しいリクエストはGeeklogに届く前に弾いてしまおう！という作業です。

注意！：この作業は「これで安心！」というものでは全然ありません。せいぜいリスクが数パーセント下がるぐらいです。

さて、ログを見ていて気になったのは「リクエストパラメータ（上記URLの「？」から後ろの部分です）に他サイトのURLが書かれている」という事です。普通にGeeklogを使ってもこういうURLにはなりません。ほとんどの場合。

ましてやリクエストパラメータのキーワードに「_SERVER[DOCUMENT_ROOT]」なんて使ってませんからね。で、同じように怪しげなパラメータキーワードを調べたら下記のようなものがありました。

_CONF[path]=http://・・・・_CONF[path_system]=http://・・・・_SERVER[DOCUMENT_ROOT]=http://・・・・glConf[path_system]=http://・・・・_MG_CONF[path_html]=http://・・・・_MG_CONF[path_libraries]=http://・・・・mosConfig_absolute_path=http://・・・・mosConfig_live_site=http://・・・・ntopic=http://・・・・topic=http://・・・・page=http://・・・・category=http://・・・・error=http://・・・・phpbb_root_path=http://・・・・dbconfig_path=http://・・・・

結構ありますね。ということで、このリクエストがGeeklogに届く前、Webサーバの中で弾いちゃいましょう。

１．WebサーバがApacheの場合

Apacheの場合は「mod_rewrite」を使います。下記のようなファイルを公開領域のトップディレクトリ(Geeklogの場合は「public_html」)配下に配置します。

.htaccess

RewriteEngine OnRewriteBase /# 不正アクセスくさいURLパラメータが送られてきたら、# HTTP レスポンスの「410 : Gone」を返すRewriteCond %{QUERY_STRING} (^|.*&)_CONF[(path|path_system)]=http:// [OR]RewriteCond %{QUERY_STRING} (^|.*&)_SERVER[DOCUMENT_ROOT]=http:// [OR]RewriteCond %{QUERY_STRING} (^|.*&)glConf[path_system]=http:// [OR]RewriteCond %{QUERY_STRING} (^|.*&)_MG_CONF[(path_html|path_libraries)]=http:// [OR]RewriteCond %{QUERY_STRING} (^|.*&)mosConfig_absolute_path=http:// [OR]RewriteCond %{QUERY_STRING} (^|.*&)mosConfig_live_site=http:// [OR]RewriteCond %{QUERY_STRING} (^|.*&)(ntopic|topic|page|category|error)=http:// [OR]RewriteCond %{QUERY_STRING} (^|.*&)phpbb_root_path=http:// [OR]RewriteCond %{QUERY_STRING} (^|.*&)dbconfig_path=http:// [NC]RewriteRule ^(.*)$  [G,L]

「RewriteCond」　：　URLを書き換える条件行である事を表します。
「%{QUERY_STRING}」　：　リクエストURLのうち、リクエストパラメータ（URLの「？」から後ろ）の部分で判断すると宣言してます。
「(^|.*&)・・・・・・=http://」　：　URLを書き換える条件を定義します。この場合ですと特定のリクエストパラメータ（先頭でも２番目以降でも）に他サイトのURLが入っている場合を表しています。
「RewriteRule ^(.*)$ [G,L]」　：　書き換え条件に一致した場合の動作。この場合は「410（Gone）」を返します。

これで上記のようなリクエストパラメータが送られて来た場合、４１０エラー（このページは無くなっちまいました）が出ます。

２．WebサーバがIISの場合

IISの場合は「URL Rewrite Module」を使います。（導入手順は別サイトに書いておきました）

下記のようなファイルを公開領域のトップディレクトリ(Geeklogの場合は「public_html」)配下に配置します。

web.config

<?xml version="1.0" encoding="UTF-8"?><configuration>  <system.webServer>    <rewrite>      <rules>        <rule name="Imported Rule 1" stopProcessing="true">          <match url="^(.*)$" ignoreCase="false" />          <conditions logicalGrouping="MatchAny">            <add input="{QUERY_STRING}" pattern="(^|.*&amp;)_CONF[(path|path_system)]" ignoreCase="false" />            <add input="{QUERY_STRING}" pattern="(^|.*&amp;)_CONF[(path|path_system)]" ignoreCase="false" />            <add input="{QUERY_STRING}" pattern="(^|.*&amp;)_SERVER[DOCUMENT_ROOT]" ignoreCase="false" />            <add input="{QUERY_STRING}" pattern="(^|.*&amp;)glConf[path_system]" ignoreCase="false" />            <add input="{QUERY_STRING}" pattern="(^|.*&amp;)_MG_CONF[(path_html|path_libraries)]" ignoreCase="false" />            <add input="{QUERY_STRING}" pattern="(^|.*&amp;)mosConfig_absolute_path" ignoreCase="false" />            <add input="{QUERY_STRING}" pattern="(^|.*&amp;)mosConfig_live_site" ignoreCase="false" />            <add input="{QUERY_STRING}" pattern="(^|.*&amp;)(ntopic|topic|page|category|error)" ignoreCase="false" />            <add input="{QUERY_STRING}" pattern="(^|.*&amp;)phpbb_root_path=" ignoreCase="false" />            <add input="{QUERY_STRING}" pattern="(^|.*&amp;)dbconfig_path" ignoreCase="false" />          </conditions>          <action type="CustomResponse" statusCode="410" />        </rule>      </rules>    </rewrite>  </system.webServer></configuration>

これでApache同様、４１０エラー（このページは無くなっちまいました）が出ます。

※ 全然関係ないですが、今回URL Rewrite Moduleのインポート機能を使って .htaccessを読み込ませました（インポート手順も別サイトに書いておきました）が、条件に一致した場合の挙動（Goneを返す）がうまく変換できませんでした。410なんてあんまり使わないのね。

ちなみにこの方式、Webサーバとのhttpコネクションは成立しますのでDoS攻撃に対しては無力ですが、その代わりWebサーバのアクセスログには410を返した事も含めて記録されます。

また、今回の例では410を返すだけですが、「RewriteRule」「action」を書き換える事で別のページにリダイレクトする事ももちろん可能です。例えば別の所に作った小さなPHPのアプリにリダイレクトして、ブラックリストに記録してから410を返す、なんて工夫も簡単にできます。

よろしければお試しください。

タグ：セキュリティ geeklog 情報保持 htaccess iis

内部的リクエストを発行してレスポンスHTMLを受け取る（CakePHP)

Fri, 03 Jul 2009 16:22:43 +0900

CakePHPの「コントローラの便利なメソッド」として「requestAction」というのが紹介されています。これは『内部的に別のコントローラにリクエストを発行して、レスポンスHTMLを受け取る』という機構です。複数のコントローラのレスポンスを１画面で表示させたい時なんかに便利です。例えば・・・下記のようなイメージでしょうか。

レンダリングまで個々のコントローラでやってくれます。まぁレスポンスが悪くなるだろうから限定的にしか使えませんが、ここぞという時には便利な機構です。

このリクエストを発行する時、リクエストパラメタを一緒に送りたい場合もあるでしょう。そんな場合のサンプルとしてrequestActionの説明ページには下記のように書かれています。

 echo $this->requestAction(array('controller' => 'articles', 'action' => 'featured', 'named' => array('limit' => 3)));

なるほど。「named」という名前の配列にパラメータを突っ込めばいいのね、と下記のように試してみました。

ポータル.ctp (修正前)

<div><?php   echo $this->requestAction(		array('controller' => '株価情報', 		      'action' => 'drawGlaph', 		      'named' => array('only上場' => '1')), 		array('return'));?></div>

これで「http://127.0.0.1/Cakeアプリ名/株価情報/drawGlaph?only上場=1」というリクエストを発行した時と同じようなレスポンスが得られるのね。

リクエストを受け取る株価情報Contorollerでは、パラメータを通常の「$this->params['url']['only上場']」ではなく「$this->params['named']['only上場']」で取得するように修正・・・。

・・・あれ？

 Notice (8): Array to string conversion [CORE\cake\libs\router.php, line 956]

配列の階層が深いですと！？

困ったなぁ～と思ってたら、同じような事で悩んでる人がいた。で、こっちに解決方法が書いてあった。

ポータル.ctp (修正後)

<div><?php   echo $this->requestAction(		array('controller' => '株価情報', 		      'action' => 'drawGlaph'), 		array('return',		      'named' => array('only上場' => '1'))	);?></div>

なるほど。パラメータはオプションとして渡すのね。

タグ： cakephp

ケアレスミス

Tue, 23 Jun 2009 19:09:48 +0900

この業界でメシを食うようになって１５年、久しぶりに「タイプミス」をしました。「$answer」を「$amswer」ですって（笑。

新人の頃の先輩のご指導のおかげでこのテのミスはあんまりしないかばだんなさん、しばらくどこが違うのか見つけられず、すごく深い理由を探ってウンウン唸ってました。そりゃ動かんわ（笑。

いや～、初心忘れるべからず（苦笑。

Windowsデスクトップアプリを作るライブラリ

Sun, 07 Jun 2009 16:22:52 +0900

最近知り合いから動画配信に関する相談を受けたので、色々調べてました。もちろんFlashベースが手っ取り早いのでしょうが、面白がってデスクトップアプリでの実装も調べていました。

そしたら本来の意図と若干異なるのですが、面白い物を見つけました。Lily C++ GUI Library という「Windowsアプリケーション専用のGUI構築 & 2D画像処理」に特化したフリーのライブラリです。

これ、解凍すると「*.lib」と「*.h」がドカドカ展開されます。（つまりオープンソースではありません）

なるほど。複数のアプリを作ってもバージョン非互換で悩まなくていいようにスタティックライブラリにしたのね。

ライブラリの機能をフル活用するには、VisualStudioが必要みたいです。

「Lily導入のメリット」のサンプルコードにもありますが、C++でGUIって結構面倒（サンプルで６９ステップ）なのですが、Lilyだと簡単（サンプルで１４ステップ）に実装できちゃいます。

いや～、まだ公開されたばかりのライブラリですが、面白いアプローチですね～（＾＾。画像処理系もそうですが、個人的にはカメラ操作のライブラリが楽しみです。

そういやこういうアプローチ、最近減りましたね。（まぁmsdnの日本語情報も格段に増えて必要性がなくなったのかもしれませんが・・・。）

なんて事を考えてたら昔、「wxWindows」というのを使っていた事を思い出しました。クロスプラットフォームのGUIライブラリです。

んで思い出しついでに調べてみたら、今は「wxWidgets」に名前が変わったようで、ドキュメント日本語化プロジェクトも健在のようです。こちらはここ何年かで機能が増えたというよりは実装言語を増やしていく方針で進んだようですね。（RubyでGUIアプリを作るためのwxRubyなんて面白そうです。）

いや～、ホント面白いですわ（笑。

Guidemanの設定はサーバー内に複数できます！

Mon, 25 May 2009 21:51:24 +0900

さて、暫く前に「普段Linux＋Apacheの人がIIS7.0をいじって思った事」なんて記事を書きました。その中でIIS上でApacheのmod_rewriteと同じような事をしてくれる「Guideman」というアプリに触れ、「やっぱりサーバーに１つしか設定が書けないアーキテクチャはちょっと不便な気がします」と書いたのですが、最近Guidemanを作ってる方からわざわざコメントを頂戴しました。表題のように。こりゃあ大変失礼な事を書いてしまったと、お詫びがてら記事名にしてみました（＾＾；

最初に率直にお詫びします。「Guidemanの設定はサーバー内に複数できます！」。

そうか～。確かに物はただのdllなんだから、ライブラリを複数配置しても全然問題ないよな～。これは私の想像力が足りてませんでした。

ただ、言い訳がましく私の書きたかった事を言い直しますと、「サーバーで１つの設定」ではなく「サイトで１つの設定」という意味で書いたんですよね。ちょうど１つのサブドメインの中に「http://shall.dip.jp/mediawiki/」「http://shall.dip.jp/wordpress/」という感じで複数のアプリをインストールしてたので。「Apacheの.htaccessならどこのディレクトリにでも書けるのに・・・」って思いを込めて。思いっきり言葉足らずですが。

しかしそうか～。するってぇとISAPを別名で複数入れたら１サイト内でも複数設定できるのかな～

てな事を考えながら半年振りにNaturalStyleさんのサイトを訪問。「Badge」ってのが出てる・・・。やっぱ素敵だよ、この会社（笑。

ちきしょ～、福井が浦安の隣にあれば、菓子折り持って~~遊びに~~お詫びに行くのにな～（苦笑。

タグ： iis

Bakeを使うためのパスを通すスクリプト

Mon, 25 May 2009 18:26:02 +0900

先月辺りからちょっと本腰を入れてCakePHPをいじり始めてます。現バージョンのCakePHP1.2.3は、フレームワークの思想としてはRailsに近いので違和感もありませんし、「やれる事」もRailsに近づいてます。PHPのお手軽さを考えれば、やっぱり触っておいて損はないだろうという腹です。

さて、CakePHPもRailsのようにコンソールから「Bake」でソース生成が出来るのですが、そのためにはパスを通さなくてはなりません。（「パスを通す」が意味不明な方は、「コンソールを使うための魔法の呪文が必要」と読み変えて下さい。）

かばだんなさんがRailsで開発をする時にはRadRailsを使っていますので、ソース生成もIDEのコンソールでそのままコマンドを叩けばいいのですが、Bakeの場合はまだコマンドラインからコマンドを叩く必要があるみたいです。しかし、毎回DOSプロンプトでパス張るのも面倒なので、スクリプトを書いてみました。

まずプロジェクトのディレクトリ直下（「app」とか「cake」とかあるディレクトリ）に下記のようなファイルを作成します。仮に「add_path.bat」としましょう。

echo OFFREM --------------------------------REM Bake を使用するためのPATH追加REM --------------------------------SET koko=%CD%REM PHPにパスが張ってない場合はPHPのあるディレクトリにパスを張る。SET php_path=%koko%/../../phpREM Bake用にプロジェクトのconsoleにパスを張るSET console_path=%koko%/cake/consoleset path=%path%;%php_path%;%console_path%

こんな感じですね。（かばだんなさんはPHPもXAMPP内の物を利用していますので、ついでにPHPにもパスを張っています。既にPHPの利用環境が出来上がっているなら「SET php_path・・・」の行を削除して下さい。）

たったこれだけ。

今度は利用する手順です。魔法の呪文の唱え方、ですね(^^。

AptanaStudioのプロジェクトの中から、あなたがコード生成をしたいCakeプロジェクトを選択して右クリックします。
「Command Line Shell」を選択します。コマンドラインの黒い画面が表示されます。
「add_path」と叩きます。

たったこれだけでBakeのコマンドが使えるようになります。（私はAptanaを使用していますので標準でコマンドプロンプトが表示できますが、Eclipseには確か標準ではそんな機能なかったような・・・と思ってたら同じようなプラグインを紹介してらっしゃる方を見つけました。みんな考える事は同じなのね（笑。）

ま、PATHを張るんだったらWindowsの環境変数を直接いじってもいいのですが、こうするのには２つの理由があります。

直接環境変数をいじるとなると、新しいプロジェクトを作るたびに環境変数をいじらなくてはいけない。
ファイルにしておくと、SVNなんかに載せてしまえばPCが変わっても違和感なく作業できる。（新プロジェクトを作った時もファイルコピーで済むし。）

ということでファイルにしました。

ん？毎回「add_path」と魔法の呪文を唱えるのは面倒？

そんな方は作成したバッチファイルのショートカットを作成して下さい。で、ショートカットファイルのプロパティを開いて下さい。「リンク先」に「ｃ：￥・・・￥add_path.bat」って書いてあるでしょうから、その先頭に「cmd.exe /Q /K 」って追加して下さい。（「/K」の後ろのスペースを忘れないように！）

これでショートカットをダブルクリックすれば、パスが通った状態でDOS窓が開きます。

以上、別にテクニックと言う程のもんでもないけど、何か書いてる人が少ない風だったので。

タグ： cakephp php dos

新DB2のPL/SQL対応で開発コスト削減！？

Sat, 23 May 2009 16:35:29 +0900

先日発売されたDB2 9.7で、PL/SQLが実装されましたね～。

ニュースリソースによると「OracleユーザーがDB2にスムーズに移行できる」としていますが、SI屋にとってメリットはそれだけじゃないと思うんですよね～。

ある程度大規模な開発プロジェクトとなると、ストアドプロシージャーは大抵使います。

これまでのDB2にもストアドプロシージャーはあり（「DB2Java」でしたっけ？）、結構軽快サクサクで良い奴なのですが、いかんせん有識者の数がPL/SQLに比べて少ないのが実情です。これが時々困った事になります。

例えばある程度大きな開発プロジェクトで社外メンバーを招聘する時、DB2ストアドプロシージャの有識者が余っている事はそうありません。で、なかなか見つからない場合、PMには次の選択肢が突き付けられます。

単価を上げる。→プロジェクトの開発費用総額もあがる。【金のロス】
未経験者を投入し、プロジェクトの中で習得してもらう。→ DB2のストアドはJavaなので難しくはないが、それでも習得まで時間がかかる。【時間のロス】
ストアドプロシージャは使わないよう方式設計を変更する。→DB内でやる方が効率的な処理をDB外でやると、下手な設計変更だとシステム負荷が増大する。【マシンリソースのロス】

これは実際にある話です（笑。

もちろんこれらの解決方法は、どれも正解だし、どれも正解じゃありません。あくまでケース・バイ・ケースで、上記３案の比率を組み合わせないといけません。だからＰＭの給料は高いんです（苦笑。

しかし、今回ＤＢ２がPL/SQLを受け入れた事によって、「PL/SQLならやった事あります！」っていう要員は割と多いですから、プロジェクトとしては助かります。さらにリスクもコストも下がるんですから、その恩恵は必ずエンドユーザーにも届くでしょう。

もちろん「PL/SQLの達人」までいかない「PL/SQL経験者」にも仕事が回ってくる可能性も増えます。（「達人」はどんな不景気だってソコソコ仕事があるもんですよ、大抵。）

と、いうことで、DB2がPL/SQLを受け入れた影響は、ユーザー企業だけでなく開発者にとっても意外と大きい気がします。

それにしてもIBMは大きな決断をしましたね～。まぁ言語仕様は譲っても、ストアドエンジンの性能ではOracleに負けない自信があるからこそなんでしょうが・・・。

今後が楽しみです。

タグ： db2 plsql

IISで動いてるサイトで、Railsアプリ (ちょっと補足）

Thu, 21 May 2009 16:25:01 +0900

前回、「IISで動いてるサイトで、Railsアプリ」を書いたら、意外と反響があったので驚いています。

で、ちょっと補足。

前回ミニマム構成として下記のような図を書きました。

で、ある方からご質問を頂きました。

「RubyForIISと同じような位置付けで『Ruby On Rails For IIS Fast-CGI』というのがありますがどうでしょう？」と。

う～ん。何度か顧客の開発言語選定のお手伝いをさせて頂いた立場としては、こういう質問が一番困ります。だって答えなんて無いのですから（苦笑。

でも、あくまで私の私見で言わせて頂ければ、「何故今更！？」の一言に尽きます。

その理由を挙げると・・・

最終版のリリースが２００７年６月と古い。（その間にRailsの仕様がどれだけ変わったことか！？）
サポートするＯＳが「ＸＰ」と「２００３」まで。（私は２００８の方が良いサーバーだと思っているので。）
作者自身が２００８年７月（サイトの最終更新時）に「このプロジェクトを引き取ってくれるボランティアを探しています・・・」と泣きを入れている。（いや、ここで作者本人を責めてはいけません。それがオープンソースですから。）

そんなわけで、やっぱり私はRailsは２台構成で稼働させる方がいいと思います。

ん？中身少ないって？　いや、ま、その・・・（笑。

タグ：rails iis windowsserver

IISで動いてるサイトで、Railsアプリ

Sun, 26 Apr 2009 19:09:53 +0900

社内システムなんかで、表題のような要望が出た事はありませんか？

まぁRails自体が下位非互換でまくりでビジネスユースが減ってしまった（少なくとも日本国内では）ので、需要はあまりないのかもしれません（苦笑。ですが公開されている情報も少ないですし、新たにDMZにApacheサーバーを立てるのは運用管理者的には抵抗があるでしょうから、ここにメモを公開します。

まず「Rails on IIS」の構成というと下図のようなイメージを持たれるのではないでしょうか？

これはFastCGI的には（確か）正確な図ではありません。あくまで概念的なイメージ図です。PHP + CakePHP の最小構成だとこうなりますよね。

でもRailsの場合これが最適とは私には思えません。少なくともビジネスユースでは。

今日はこんなお話し。

何で「最適とは思えません」なんて明言するかと言うと、いくつか理由があります。

（いや、繰り返しますけど「ビジネスユースの場合」ですよ？）

１．Ruby For IIS が行方不明。

Ruby For IIS がサイトごと無くなっているのは結構有名な話です。まぁ元から挙動も不安定という話でしたし、逃げた女を追いかけてもろくな事はありませんしね（苦笑。

少なくともIIS・Ruby・Railsが日々更新されている以上、更新されていないモジュールを採用するのは危険すぎるというものです。（構築だけして保守もバージョンアップもしないなら採用してもいいですけど、かばだんなさんのシャル・システムサービスはそういうスタンスで仕事しないので。）

２．システムの拡張性に乏しい

上記の構成は１台（DBサーバーを分離したとしても２台）のマシンで全処理を行う構成ですが、Railsのアプリってメモリを食いやすいので、どうしても構築時に将来のサーバー多重化を意識しておく必要があります。

もちろん上記の構成でも多重化は可能なんですけど、実導入の時にアプリケーションセッションの共有から全部テストしないといけません。このテスト工数はデカいです。どうせできるならシステムの構成物も「モジュール」と考え、「疎結合」を目指したいですよね。

（あ、クラウドコンピューティング的にリソース拡張はもっと下のレイヤで対処するっていうのはアリです。）

という事で、どうも私には最適な構成とは思えないのです。（ホントはさらに「DMZに業務アプリが乗ってる」っていうのが恐ろしいのですが、これは私の考え過ぎかもしれませんので大書きしません。）

じゃあDMZのWWWサーバとしてIISを使用している会社はRailsアプリを公開できないのか！？わざわざRailsアプリのためにApacheを立てなきゃいけないのか！？と言われると、そんな事はありません。

あくまでサンプルですが、いくつか例を挙げます。共通する設計思想は、「DMZに新たにサーバーを立てるのは危険なので、ファイアーウォールの内側に１つ立てましょう」というものです。

で、どの案を選択するかはその会社ごとに変わります。

プランＡ：内部セグメントにWindowsでサーバーを立てる

この場合、下記のようなイメージになります。

この場合、IISでは先日紹介した「URL Rewrite Module」を使ってリクエストを転送し、FireWallの内側に新たにRailsに特化したAPサーバーであるMongrelを導入します。mongrelにはWindowsサービスとして稼働する「mongrel_service」もありますので、管理も容易です。

あ、静的コンテンツをIIS上に残したのはただの私の趣味です（笑。少しでもMongrelの負荷が減るならそれに越したことはないな、と。

この構成と最初の構成を比較した時のメリット・デメリットは下記の通りです。

【メリット】

・DMZが膨らまないのでセキュリティ的にも（ちょっと）安心。

・DMZサーバーの処理内容を「httpセッションの管理」「SSLの暗号化・複合化」「静的コンテンツ（画像・CSS）の応答・キャッシュ済み（３０４）かの確認」に限定する事で、サーバーの負荷を大幅に軽減。

・DMZサーバーの負荷が軽減する事で、「Keep-Alive」のタイムアウト値等、レスポンス速度向上ための設定が可能になる。（IIS7.0のタイムアウトは120秒だけど、単独機だとリソース的にあまり大きな値を設定するとサイトによってはキツいかも。）

・ＡＰサーバーがメモリパンクなどでダウンしても、影響が局所的範囲に収まる。（例えばＤＭＺに置いてある会社のホームページなどは影響なし）

・APサーバのリソースを増強する際、動作確認がAPサーバー周りだけで済むので、テスト工数が小さくなる。

他にもたくさんありますが、いわゆるWeb３層構造のメリットばかりですね。３層構造というとJavaのアプリが一般的ですが、別にJavaである必要はありませんから、どんどんいいトコ取りです。

【デメリット】

・APサーバとしてもう１台サーバーを購入しなければならない。（でもDMZにIISを立てているような会社であれば、社内サーバとしてもWindowsサーバーを立てている所が多いでしょうから、アクセス数が少ない間はそのサーバーをAPサーバーにする事も考えられますね。）

・Mongrelの作者が１年ほど前にRubyコミュニティに愛想をつかして心の旅に出ている。（これも困った問題ですが、そのうち代わりが名乗りを上げるような気がします。あくまで予感ですが・・・。）

プランＢ：内部セグメントにLinuxでサーバーを立てる

この場合、下記のようなイメージになります。

このプランではDMZは変わりません。ただAPサーバーがLinux＋Apacheになっただけです。何でLinuxにするかというと、このPassengerというのがWindowsで稼働しないからです。なんか頑なに拒否しているようにさえ見えます。ま、他人の趣味はどうこう言いますまい（笑。

この構成のメリット・デメリットは、上記プランＡと比較しましょう。

【メリット】

・MongrelよりPassengerの方が１リクエストあたりの処理が早い。（これはPassengerがアプリケーションプールを作って、メモリ上で使い回しをするためのようです。確かに早い。）

ちなみにPassengerと一緒に「Ruby Enterprise Edition」というのも公開されています。Rubyの亜種みたいですが、半年ほど前にCentOSで試してみたけどあんまり速くなった気はしませんでしたので、私は採用を見送りました。うむ、スタンダードは美しい。

【デメリット】

・WindowsとLinuxの２種類のサーバーが混在するので、運用管理者の管理コストが増す。（特にセンター運用なら倍増です）

・Passengerは起動時にアプリケーションプールを作成するため、アクセスがない状態でも設定したプール数分だけメモリを消費する。

と、まぁ、こんな２プランを考えてみました。個人的には多少速度的に劣っても、複数OSを運用する手間を考えたらプランＡの方がいいような気がします。Mongrelの作者が旅に出たのは大ダメージですが、ほら、Mongrelサーバーをファイアーウォールの内側に置く事で、多少枯れても何とか騙し騙し動かせるかな、と（苦笑。

以上、本日はシステムのグランドデザイン的な話になってしまいました。ほら、春だし新人さんの季節だから（笑。

タグ：rails iis windowsserver

インストールマニアックス２００９

Sun, 26 Apr 2009 18:42:08 +0900

インストールマニアックス２００９、いよいよエントリ募集終了しましたね。

今回は参加者も５倍の５００人になりましたが、応募者はもっと増えたとか。激戦でしょうね～。

え？私ですか？今回は不参加です。前回以上の激戦が予想されて恐れをなしたと思われても仕方ありません（＾＾；

実はちょっとGWは腰を据えてやりたい事があったので、今回はパスさせて頂きました。

参加者みなさんの健闘をお祈りします。

・・・・決勝戦、見に行きたいな～

タグ：インストールマニアックス

IISの「URL Rewrite Module」で.htaccessをインポートしてみた

Wed, 22 Apr 2009 15:10:29 +0900

最近の私は「金勘定、提案書書き、酒」で１週間が過ぎて行ってます。昔の「会議、ネゴり、酒」と大して変わりませんね（笑。

さて、金勘定にうんざりしたかばだんなさん、昨日は現実逃避に先日の記事にも書きました「.htaccessでmod_rewriteを使用しているサイトをIISに移設」ってのをやってみました。えぇ、現実逃避です。金勘定も提案書も残ってます。分かっていますとも（笑。

mod_rewriteの代替としては「URL Rewrite Module」を使います。

まずはIISにURL Rewrite Moduleを導入します。導入手順は別サイトに書きましたのでそちらを参照下さい。

そういえば別サイトはDDNSを使っている関係でdipドメインを使用しているのですが、このドメイン、プロキシでブロックしてる企業さん多いみたいですね・・・。私のサイトは月～金曜の日中のアクセスが圧倒的に多いので、ちょっと引っ越しを考えなきゃ・・・。

で、続いてURL Rewrite Moduleに.htaccessのファイルを食わせます。インポート手順も別サイトに書いておきました。（よく見たら本家にインポート手順書いてましたね。ま、本家は英語な上にテスト環境の構築方法なんて蛇足が付いてますので、このまま自分のサイトを中心に語りましょう。）

で、実際に動作確認してみたのですが・・・・・動かん！！

それも「404.4 - Not Found　～検索中のリソースには、リソースに関連付けられたハンドラがありません。」ですって！？（ハンドラって「phpならこう動かす」とかそういう設定です）ただのHTMLなのに！？

サーバー機のブラウザで叩いてみたら下記のような画面が出てきました。

ちなみにインポートで作成されたweb.configを消すとちゃんと表示されますし、web.configの中を見てもハンドラマッピング関連の記述もないので、ハンドラの問題ではなさそうです。

エラーコードの「0x8007007b」でググる。よくわからん。

本家サイトの既知の不具合を見る。もっとわからん（苦笑。

現実逃避の片手間でやった実験なので、元々の.htaccessに誤りがあるんじゃないかとApacheで同じ環境を作ってみるが・・・動く（涙。

やりたい事はWebアプリも認証もCookieも関係ナシで、「HTTPリクエストヘッダを見て携帯とPCを振り分けたい」ってだけなんですが・・・。

てことで今回は解法ナシです。エラーコードで検索してここにたどり着いた方、ゴメンなさい。また近々腰を据えて再挑戦しますので、結論はその時に・・・。

しばらく間が空きましたが、IISでもPCと携帯の振分けが出来るようになりました。詳しくはコチラです。

タグ： iis httacess 携帯サイト

IISに乗り換える際の.htaccess

Tue, 14 Apr 2009 13:19:10 +0900

こんにちは。ちょ～忙しいのを言い訳にホントに間が開いてしまいました。

さて、先週インストールマニアックス優秀賞受賞者の第２回オフ会に出席してきました。やっぱり楽しいです。

主催のインプレスさんだけでなくマイクロソフトさんからも錚々たる顔ぶれが参加されていました。

なんか早くも第２回（２００９）の募集が始まっているようですが、オフ会の席上でも「商品何がいい？」って聞かれました。私は前回ここで余計な事を書いて失敗したので、「コメントは差し控えさせて頂きます」と逃げました（笑。でもね、このオフ会への参加権を得られるだけでもすごい商品だと思いますよ。ホント。だって普段MSのセミナーとかでスピーカーしてる方々と普通に卓を囲めるんですから。

さて、オフ会での内容については、どこまで書いていいのか分からないようなお話まで聞いたのでここではスルーしますが、オフ会メンバーのコミュニティに以前提言した事があります。それは

「IISには.htaccessがないので、Apacheから移植しても動かない場合があるのでは！？」

という至極当たり前の事です。当たり前なんだけど重要なテーマだと思っています。

特にアクセス制限系の用途で.htaccessを使っている場合は要注意です。

自分で作りこんだアプリなんかなら問題ないのですが、どっかのオープンソースのアプリを「どっこいしょ」と持ってきた場合にはしれっと.htaccessファイルでアクセス制限をやってたりするとそこがセキュリティホールになりかねないからです。

セキュリティホールになりかねない話をこういう公の場で書くのは良いのか悪いのか悩んでいたため、ここで書くのはずっと控えていましたが、今日みたらMicrosoftTechNetにIISのページができていました。（これができるって話もオフ会で聞いていたのですが、公開されるまで黙ってました）

ここ、IIS関連の記事が集約されていて便利なのですが、そこに「.htaccess コンテンツを IIS の web.config に書き換える」という記事があります。普段IISを使った事のない私にも分かるように書かれていますので、「.htaccessなら分かるんだけど・・・」という方には有効な記事ではないでしょうか。

ちなみに「IISが.htaccessを認識するようにすればいいじゃないか」という意見もあるのでしょうが、それではIISが多機能になり過ぎて本末転倒な気がします。IIS7は（IIS5の反省に基づいてか）「本体は極力スリムにする」というのが基本思想ですから、IISが自動で.htaccessを認識するというのは基本思想の逆を行く事になるからです。ま、.htaccessも認識できるようにするよりは、.htaccessを食わせるとweb.configを吐き出すシェルを提供するぐらいが無難な落とし所のような気がします。

しっかしこの前のオフ会で知った事、あんまり書けないのはつらいなぁ～。

じゃあ少しだけ。

IIS7.5はさらに使える物になると（MS贔屓じゃない私も）思ったぞ！

SI屋は今の内にIISを武器のひとつに加える検討をしてもいいかもしれないぞ！

・・・・え？漠然としてて全然分からないって？書けなくて苦しいのは私もいっしょよ～（笑。

タグ：iis インストールマニアックス htaccess

インストールマニアックス表彰式

Thu, 26 Feb 2009 16:11:14 +0900

男は、夜の新宿を駈けていた。約束の時間は１９：３０、奴には１９：４５には着くと電話を入れてある。だが１分でも早く着こうと男は走った。

１９：４３、エレベータを降りてオフィスに駆け込む。入り口には「マイクロソフト」のプレート。間違いない、ここだ。

単身乗り込むのが危険なのは分かっていた。相手はかつて人によっては「悪の枢軸」とまで呼んでいた巨大組織だ。ましてや男は日頃からブログで歯に衣着せぬ発言を繰り返し、提灯記事を無価値と公言して来た男だ。危険がないと考える方が無理というものだ。しかし危機を回避するより「そこで何が行われるのか」が知りたかった男は躊躇無く駈けこんだ。

屈強な警備員の前を抜けて部屋に通されると、３０人程の男女が名刺交換など談笑している。

おかしい、開始は１９：３０ではないのか！？さりげなく周りを見渡すと、さっきは気付かなかったがここにいる連中は皆凄腕だ。こいつはとんだ虎穴だったか、男はようやく悟った。

程なく、まるで男を待ち構えていたかのようにスクリーン前に男が立ち、「授賞式」の開会を告げた。

開会を告げた男はＩと名乗った。名前だけは知っている。これまで男の交渉の窓口となっていた奴だ。柔和な外見だがこれだけの会を仕切る奴だ、腹の内はどうだか・・・。

「優秀賞」３人がスクリーン前で賞状を受け取る。確かにスゴ腕のプロ達であり、自然と周囲の目もスクリーン前に集まる。「会」が予定調和のまま進むにつれて男の緊張が薄れていったのは甘いと言えば甘かった。一呼吸ついたところでＩがさも当然のように言った。

「それではドキュメント賞ですが、代表してかばだんなさん前へ・・・」

すぐにスクリーンに男のブログ、それも一番見られたくないページが映し出された。まるで予め決められた段取りであるかのように。

開会が遅れたのも、わざわざ出席確認の電話がかかってきたのも、全てこのためだったのか。薄れゆく意識の中で男は思った。

ハメられた～（笑！！！

長いイントロになってしまいました（苦笑。まともな経過は事務局のページに公開されてるし、久しぶりの新宿だったので初期の大沢在昌風な文章にしてみました。え？なんで大沢かって？新宿鮫・・・・（汗。

そんなわけで行って参りました。インストールマニアックスの授賞式。

要望かなってインプレスIT田中社長に握手して頂くかばだんなさん。無断転用（笑。

いや～、マジでアセりましたよ。事前に何も聞いてなかったんで。

カメラマンさんの腕が良いからかばだんなさんこんな笑顔してますけど、実際この時手が汗ばんでましたもん。ごめんなさい、田中社長（笑。

ちなみに昨日会場で公言した通り、ハメられた意趣返しで実名さらします。（我ながら大人気ない）

私をハメた上記「Ｉ」とはインプレスＩＴ社のIDEさんです。みんな気をつけろ！IDEさんは虫も殺さないような柔和な笑顔のまま、虫は殺さないけどかばだんなさんを殺すぞ（笑！

あ～、すっきりした（笑。

しかしまぁ、昨日は本当に楽しかったです。楽しくって深夜まで新宿のバーで飲んだくれてしまいました。ここだけは反省（笑。

で、ふと深夜に考えたんですよ。「何でこんなに楽しかったんだろう？」って。

田中社長がブログの顔写真よりもイケメンだったからか！？あるかもしれません。会場がＭＳ本社だったからか！？あるかもしれません。でもたぶん一番の理由は、出席者の面子が良かったからなんでしょうね。

・参加者: みんな叩き上げのプロ。プロだから１人でできる事の限界を知っていて変な壁を作らない。初対面とは思えないぐらい楽しく会話ができる。で、改めて思う。やっぱプロにはかなわねぇな～（笑。

・主催：インプレスITさん: 田中社長がすごい方なのは分かっていたんですが、昨日お話しさせて頂いて再認識しました。やっぱすげぇよ。昨日は社長のブログ記事を基に「個人のコネクションの連鎖の結果として出来上がるネットワークが素敵なローカルネットワーク」みたいなお話や「幸せ度合いの単位が『円』や『ドル』になりつつある現状」なんてお話しをさせて頂きました。大変勉強になると同時に、自分のやりたい事が間違っていないとちょっと背中を押して頂いた気がします。; で、社長が立派でそのカリスマ性でみんなを牽引して成立している会社は多々あるのですが、インプレスITの担当者の方は皆さん能動的なんですよね。これもすごく羨ましいと思いました。
・協賛：マイクロソフトさん: 私は決して特定企業のソリューション・サービスを盲信しません。だからデベロッパーさんが煙たがるのは当然（笑。ですが今回マイクロソフトの方はそういう意見を貴重と耳を傾けて下さいました。あるご担当の方なんかわざわざ個人的総括を英訳して本国に転送して下さったとか。相変わらず企業を盲信するつもりはありませんが、昨日のご担当の方達は素晴らしい。きっと素敵なものを作って下さるでしょう。; ある担当の方と「コミュニティを醸成させるためにどこまで手を出すべきか」という点で意見交換をさせて頂きました。確かに難しい課題だけど、あの方々ならやってのけそうな気がする。そんな感想を抱きました。

このとおり色々な立場の方が参加していらっしゃったのですが、共通しているのは皆さん「地に足をつけたうえで前を向いている」んですよ。こんな方々と同席できれば、楽しくないはずがないですよね。こういうネットワークが連携・増殖していくのが正しいネットワークの作り方だと、本当に勉強になりました。

さて、気になっていた賞品です（笑。たくさん頂きました。

DSも嬉しいのですが、雑誌がうれしい。カバンは羨ましい（経営者目線）。賞状も嬉しい。なんかとっても豪華でした。

会場では優秀賞のシアトル視察旅行のレジュメも紹介されてました。わざわざMSの担当者の方に「え～、かばだんなさんは余り興味がないと言っていた本社視察ですが・・・」と前置きされた上で（苦笑。

これだけは事務局の手落ちだと思うのですが、最初にあの賞品告知を見た時、私はフリーエリアを見て回るのに毛が生えた程度の「お土産の無い工場見学」程度だろうと受け止めたんですよ。おまけに冬のシアトルなんで寒いじゃないですか。だからかばだんなさんは「あんまりテンションが上がらん」と書いたのです。

が、レジュメ見て思いました。

こんなすごいの！？めちゃめちゃ羨ましい！俺も行きてぇ～！！

え？節操ありませんか？そうですか？いいんです。良いものは良いと言うのがかばだんなさん（笑。

そんなわけでとても楽しいひと時を過ごさせて頂いたかばだんなさんなのでした。会場は大盛り上がりでとてもじゃないけど時間が足りませんでしたので、先々少しずつこれをご縁に連携していけたらなぁと思っています。

今日は長くなりました。なんでこんなに詳しく書いたかというと、「次」が企画されていると聞いたからです。このブログ、独自ドメインだと言うのに「インストールマニアックス」でググると営業ブログよりも上に来るんですよ（笑。だから「次」の募集要項を見た人がググってここに来る可能性は大いにあるわけで、その人のためにも書きました。もしこれを読んであるあなたが未来の人で「次」の募集要項を見てここにたどり着いたのなら、応募をお勧めします。とんでもないチキンレースですがその甲斐はあります。で、もしこれを読んであるあなたが募集要項を見て来たのではないのなら・・・・羨ましがってください（笑。

タグ：インストールマニアックス