_ Sony's Idei - Part 3 from AlwaysOn (20:18)

• Sony's Idei - Part 3 - http://www.alwayson-network.com/comments.php?id=258_0_2_0_C

Sony's Idei - Part 2 from AlwaysOnとSony's Idei - Part 2 from AlwaysOnの続き。最終回。

今回は主にソニーの家庭用エンターテインメント戦略一般の話。全体としてはそれなりに面白いけれども、まあ普通の状況確認って感じのネタが多いかな。一番面白かったのは、スティーブ・ジョブス（Apple）の話の流れで、

>Although he is a genius, he doesn't share everything with you. This is a difficult person to work with if you are a big company. We started working with them, but it is a nightmare. We have the exact type of guy like Steve within Sony. His name is Ken Kutaragi.

ってあたりか。

_ 眠れなかった (20:18)

多分花粉症のせいだと思うけれども、もしかしたら風邪なのかもしれない。この時期はいつも自分の健康状態の把握が難しい。昨日の夜は寒かったためか、早朝から鼻水と頭痛が激しくなって眠れず、朝から体調激悪な感じなのです。が、そろそろ今週納品のブツは仕上げておきたいから休みたくないしなー。ひとまず鼻炎薬を飲んで一眠りしてみよう。

_ 個人Webサイトのジャンル分けとそれを表す言葉の変遷 (20:18)

最近では（主に文章中心の）個人Webサイトのジャンルを表す言葉が増えたけれども、4、5年前には「テキストサイト」とか「個人ニュースサイト」などというジャンル名は存在しなかったように思う。個人が頻繁に（ほぼ毎日）更新するようなサイトのことは基本的に「Web日記」と呼んでいた。そして、更新頻度がそれほど多くない代わりに文章がより練られているサイトは「雑文サイト」と呼んだ（しかしその二つの差はあまり明確ではなかった）。

アメリカでは、日本でかつて「Web日記」と呼んでいたものをblogと呼んだのだろう。結局それは、そのような個人Webサイトの形式に対して、日本では既存の言葉の意味を拡張して当てはめたけれども、アメリカでは新しい言葉を造って当てはめた、というだけの違いにすぎない。新しい言葉を造って当てはめた方が「何か新しいもののように感じる度合いが大きい」という違いはあるが。

ただし日本ではWeb日記という言葉の意味が変わりつつある。かつてWeb日記と呼ばれたジャンルの中から、さらに「テキストサイト（ネタ系文章中心。かつての雑文サイトに近いものも含む）」、「個人ニュースサイト（時事ネタ中心羅列型）」などという枝ジャンルが発生したことによって、かつては広い意味で使われていたWeb日記という言葉が、その字義通りの意味（日常雑記）に縮小して捉えられる場合が多い。

しかし、そのような枝ジャンルが発生したところで、古くからのWeb日記書きは自らのスタイルを、新しく狭いジャンルを表す言葉に当てはめることはない。かつての広い意味を持つ「Web日記」という言葉で表現するだろう。そして、すでに枝ジャンルが確立した後にサイトを作った人は、枝ジャンルという枠組みの中で自らを表現するだろう。すでに人口は後者の方が多い。

古いWeb日記書きが「blogはWeb日記である」というとき、その「Web日記」はかつて広い意味を含んでいた言葉としての「Web日記」を差している。それは、現在の再び狭い意味に押し込められつつある「Web日記」とは異なる。しかしそのような意識はすでに多数派ではない。

ところで、最近はかつて「雑文サイト」と呼ばれていた類のサイトがやけに少なくなっている気がするのだが、気のせいだろうか？　私の視野が偏りすぎているだけか？　あと枝ジャンルとしての「VNI（バーチャルネットアイドル）」や「コジャレ系」はまだちゃんと生き残っているのだろうか？　存在していることは知っているが、生き残っているかどうかの判断がつかない。まさかテキッ娘。が最終進化形なんじゃないだろうな。

_ xreaのアカウント (20:18)

WikiLikeの実験もずいぶん進んできて、Web日記もしくはblogツールとしてはそれなりに使えるようになってきたんで、ここのバージョンのサブセットを、よりWeb日記ツール的にして、一般配布バージョンとして再構成してみようかなーと思ったんだけど、これだけいろいろな軸での検索に依存した作りのものを今さらファイルベースで作り直したくないから、MySQLが使えるサーバーという最低環境は維持しないなーとなると、MySQLが使えるサーバーの一般的な最低ラインとはなんじゃらほいということになって、国内ではxreaを基準にするのが無難かなーと思い、ひとまずxreaのアカウントを取ってみようかと思ったけれども、xreaのアカウント取得ってなんだか結構面倒くさそうな感じで、結局アカウントが取れないままにやる気だけが失われたのでした。募集フォームは載っているのに、POSTすると定員オーバーのメッセージが出るのは、本当に定員オーバーだからなのか、なんらかの拒否条件に引っかかってしまっているのか、どっちなのかよく分からないなー。

半分あきらめつつもサーバー状況ページを見ながら朝登録してみたら、登録できちゃったみたいだ。ダメだと思ってすでに頭はマルチユーザーバージョン方面に向かっていたんだけど、こうなったら配布用のサブセットの方を中心に考えることにするか。

_ NTT Com、iモード網を利用した携帯電話向け情報流通プラットフォームを発表 from ASCII24 (20:18)

• NTT Com、iモード網を利用した携帯電話向け情報流通プラットフォームを発表 - http://k-tai.ascii24.com/k-tai/news/2003/03/10/642367-000.html
• 携帯電話が遠隔操作のリモコンに〜NTTコムの「MOBILEWING」 - http://www.zdnet.co.jp/mobile/0303/10/n_bee.html

そうだよなー。携帯電話インターネットは課金処理付き個人情報と結びついたIDをネットワーク越しに渡せるところが、PC系インターネットとは違うんだよなー。そう考えると、ノートPC（もしくはPDA）＋ハードウェアキーってのも悪くないのかも。そういやPalladiumって言葉を最近聞かなくなった気が。

_ 国立情報学研、“純国産”の情報共有支援システムを無償提供 from ZDNet (20:18)

• 国立情報学研、“純国産”の情報共有支援システムを無償提供 - http://www.zdnet.co.jp/news/0303/10/nj00_netcommons.html

NetCommonsねー。なんか微妙なしろものが出てきたなー。そんなクローズドなシステムをひも付きで開発するくらいだったら、国産のオープンソースポータルアプリ開発を支援したりした方が良かったりしないかなー。あるいは既存のオープンソースポータルアプリの日本語化を支援したりとか。っつーか、そのNetCommonsをオープンソース化できないのかな？　金儲けのために開発したものじゃないんでしょ？　オープンじゃないシステムだと、もしできが良かったとしても、利用例が増えないままにそのうちなくなってしまいそうだ。

_ Office 2003 β2登場、その真価を試すには from ZDNet (20:18)

• Office 2003 β2登場、その真価を試すには - http://www.zdnet.co.jp/news/0303/10/cead_coursey.html

>この技術は、プロジェクトや文書、ミーティング情報の共有のための小さな臨時Webサイトを構築するもの。用意されたオンライン作業スペースで、文書、予定表、アナウンスメントを共有でき、アンケートの実施など、グループが欲しがりそうな機能を実現する。

>このためSharePointは、電子メールを使ってメンバーに新しいデータが掲載されたことや変更が加えられたことを通知する。つまりインターネット上のメーリングリストとニュースグループ、およびWebサイトが提供する柔軟性と機能が合体されている。

設計思想や機能としてはとても良さそうだなー。問題はマイクロソフトOfficeファミリーの一員であるということから想像される、応答速度の遅さやセキュリティ的な甘さあたりか。でもきちんと日本語化されたら試しに使ってみたい気もするな。MSDNで配布されないかなー。

_ はてなダイアリーTrackBackシステム (20:18)

• はてなダイアリーTrackBackシステム - http://d.hatena.ne.jp/ishinao/keyword/%a4%cf%a4%c6%a4%ca%a5%c0%a5%a4%a5%a2%a5%ea%a1%bcTrackBack%a5%b7%a5%b9%a5%c6%a5%e0

はてなダイアリーがはてなダイアリーTrackBackシステムってのを実装してますね。はてなダイアリーの方（http://d.hatena.ne.jp/ishinao/20030311）に書いたように、ちょっと本来のTrackBackとは違っている部分があるけれども、こうやって新しい技術を取り入れていく姿勢はすばらしい。あとははてなが企業じゃなくて、オープンソース作者だったら完璧だったのに（わらひ）。

• 外部システムからの送信テストをしていなかったので試しに送信。http://d.hatena.ne.jp/hatenadiary/TrackBackにTrackBackを送ればいいんだよな。http://d.hatena.ne.jp/hatenadiary/20030311#1047386175/TrackBack

ってのはダメなんだろうか？　試しに後者からテストしてみよう。文字コードはEUC-JPにしておいた方が無難かな？

• やっぱり後者はダメか。せめて日付指定のところまでは見て欲しいんだけどなー。続いて前者のURLでテスト。
• あれ？　大文字小文字を見ているんだろうか？　http://d.hatena.ne.jp/hatenadiary/trackbackで送ってみよう。
• おお、うまくいったっぽい。よく考えたらはてなはURLしか受け取らないんだから、文字コードは何にしても関係ないよね。

_ ベイジアンなRSS Aggregator from blog.bulknews.net (13:51)

• ベイジアンなRSS Aggregator - http://blog.bulknews.net/mt/archives/000836.html

この間似たようなことをやってみようとCPANからベイジアン関連のモジュールを落として試してみたんだけど、メール形式以外に対して手軽に使えるベイジアンなライブラリが見つからなかった（←探し方がよくない）んで、あきらめていたんだよな。Algorithm::NaiveBayesってやつを使えば何とかなるのか。

goo blog（http://blog.goo.ne.jp/）が提供している「Pingを送ると、その記事をリアルタイムで検索エンジンのクローリング対象に追加する」という仕組みとかと組み合わせると、いろいろ面白いことができそうだ。

というか、blogmapにもなにかその系統（記事中に含まれる特徴的なキーワードを利用する）の機能をつけてみようかなー。どうせデータをクローリングしているんだから、そのデータを捨ててしまうのはもったいない。といって使わないデータをため込みすぎて、この間DBを壊してしまったんだけど。

_ ファンタジースポーツ (13:51)

おや、日本版のファンタジースポーツってYahoo!が買い取った（http://soccer.yahoo.co.jp/fantasy/jleague/）のか。と思ってファンタジースポーツJAPAN（http://www.fsjsports.com/）の方を見てみたら、日本版のサッカーが準備中になっていた。ここだけYahoo!でやるってことになったのか。ちぇっ。ファンタジースポーツの日本プロ野球がYahoo!で無料でできるようになったらやりたかったのに。

_ TrackBack文字欠けの原因 (13:51)

2004/3/12

うが、MySQLのcharsetを変更したらなんかindexがおかしくなった模様。マニュアルを見ると、「myisamchk -r -q」すればいいっぽく書いてあるんだけど、実際には「doesn't have a correct index definition.You need to recreate it before you can do a repair」とかでて、まともにindexが引けていないっぽい。具体的には、varcharとかのindexがちゃんと作れなくなってしまう（index自体はできるけど、中身ができない）。

仕方ないからrecreateするかと、いったんdrop indexしてからalterしても同じ状態。というか、同じ構造のtableを新規に生成しても、そのtableでも同じエラーがでる。frmファイルに記述されたindex関連の設定がおかしいとか言われるんだけど、新規にfrmファイルを作っても同じエラーがでるってことは、何か根本的におかしくなっているのか。

ググってみたら、同じエラーがでて困っているという話はあるけれども、根本的な解決策は見あたらず。唯一対症療法的な解決策が、http://www.geocrawler.com/archives/3/108/2002/10/0/9937919/にあったんでひとまずそれを適用。

myisamchk --keys-used=0 -rq [/path/to/data]
mysqladmin flush-tables
myisamchk -rqSa [/path/to/data]
mysqladmin flush-tables

ってすると、一応varcharなcolumnに張ったindexもちゃんと作られる（中身ができる。ちゃんと使われているか試してないけど、まあきっと使ってくれてるよね）。ただし、myisamchkすると同じエラーは出続けているんで、indexの設定が腐った状態のままなのは変わらず。

2004/3/11

うちからのTrackBackとかがときどき文字化け（欠け）している原因がわかった。元々は自前（mylogのコード）でTrackBackを送っていたんで、excerptをPHP上で（mb_substrで）切りつめていたんだけど、最近はずっとPingProxyを使っていて、PingProxy側ではexcerptをノーチェックでMySQLのvarchar(255)につっこんでしまっていて、しかも今までMySQLのcharsetがちゃんと（ujisに）設定されていなかったんで、varchar(255)への切りつめ時に最後の文字が1/2の確率で化けて（欠けて）いたってことなのか。というわけで、my.cnfの[mysqld]にdefault-character-set=ujisを追加しつつ、PingProxyで投稿を受け付ける際にもきちんとexcerptをmb_substrで切るように変更。

_ あーもう！ (14:06)

この大詰めだってのに目がかゆくてしょぼしょぼして、細かい字を延々と追っていく作業に耐えられませんよ！　こんなときに花粉症ばりばりにならなくてもいいのに。今週末を越えたら多少キてもいいから、今は勘弁してくれ。

_ 両用インターフェースと通信の表示 (14:22)

MM/blogmapで、画像等の表示・非表示を切り替える機能を、サイドバーに追加したんだけど、そのインターフェースとして、

• Ajax環境の場合
  • フォームのチェックボックスのオン/オフで動的に表示・非表示が変わる
  • さらに設定の変更が非同期で保存される（といっても現状はCookieだけど、わざわざサーバーサイドを介して保存している）
• 非Ajax環境の場合
  • フォームのチェックボックスで設定を変更し、[保存]ボタンをクリックして設定を保存する。
  • ページをロードする段階でのみ、現在の表示・非表示設定が反映される

といった感じにしてみた。多分こういうやり方がAjaxと非Ajaxで両用のインターフェースを使う場合の基本形になるんじゃなかろうか。機能を呼び出すインターフェースを従来のHTMLフォームと互換にしておいて、Ajax環境ではJavaScriptがいろいろ処理を行い、それ以外の場合はHTMLフォームからPOSTしてサーバーサイドで処理を行う感じ。

あと、裏で何を通信しているのがわからなくて気色悪い説がやはり強いらしいんで、Ajaxで通信をするときには、ブラウザのステータスバーに「Ajax connect to [URL]」みたいな通知を表示するようにしてみた。通知を表示する領域をドキュメント内に用意できる場合はそこに表示し、そうじゃない場合はこういう風にステータスバーに表示するのが手軽かなー。ただ、なぜかFireFoxだとステータスバーに何も表示されない。

本格的にライブラリを構築するんだったら、詳細通知モードをユーザーがオンにすると、別ウィンドウにAjaxの通信状態に関する詳細が表示されるようになったりするといいかもしれない。「if (!msgwin) {msgwin = window.open();} msgwin.document.write(msg);」ってする感じね。

ちなみに、現在blogmapとかMMでは更新日時を見てNot Modifiedとか返しているんで、スーパーリロードしないとうまく設定が反映されないかもしれません。そのうちその辺の整合性も調整します。

_ HTML_AjaxHandlerのサンプルその2

一番基本となる、Ajax.Requestを使うパターンを作ってなかったんで、そっちも作ってみた。

• 動作デモ
• ソース（sample2.php＋api.php）

デモの内容は、最小値と最大値を入力してフォームをsubmitする（Σボタンをクリック or ENTERキーを押す）と、最小値から最大値までを加算した式と結果を表示する。

HTMLは、

<form id="rangeform">
min: <input type="text" name="min" id="min" />
max: <input type="text" name="max" id="max" />
<input type="submit" value="Σ">
</form>
<span id="range"></span>

な感じで、HTML_AjaxHandlerでハンドラーを登録するPHPコードは、

require_once 'HTML/AjaxHandler.php';

$ajax =& new HTML_AjaxHandler();
$ajax->addHandler(
	'rangeform',
	'submit',
	array(
		'url' => 'api.php',
		'method' => 'get',
		'parameters' => 'command=range',
		'onSuccess' => 'rangeSuccess',
	)
);
echo $ajax->toJavaScript();

な感じになる。前のデモと違って、containerがセットされていないから、使われるAjax.*はAjax.Requestになる。で、onSuccessのコールバック関数はrangeSuccessね。

わざわざAjax.Requestを使う意味をだすために、サーバーサイド（api.php?command=range&min=[最小値]&max=[最大値]）では、

$min = intval($_GET['min']);
$max = intval($_GET['max']);
$range = range($min, $max);
$sum = 0; foreach ($range as $num) {$sum += $num;}
echo '{expression: "' . implode(' + ', $range) . '", sum: ' . $sum . ' }';

なんて感じでJSON形式で結果を返している。で、Ajax.RequestのonSuccessコールバックに登録されたrangeSuccess関数では、

function rangeSuccess(res)
{
	eval('var result = ' + res.responseText + ';');
	var html = result['expression'] + ' = ' + result['sum'];

	$('range').innerHTML = html;
}

なんて感じで、evalして計算式文字列と結果数値を取り出して、その内容から出力を組み立てている。

なんてのが、Ajax.Request＋自前のコールバック関数を使った場合の記述パターンになる。

_ AjaxHandlerにあった方がいい分岐パターン

実際にいくつもアプリケーションを作ってみないと本当のところは分からない*1気がするけど、さすがにテストのためにそれなりの規模のアプリケーションを書く気にもなれないから、ひとまず思考実験してみよう。

まず思いつくのはフォームからの投稿をAjaxで代替処理する際に、JavaScriptバリデータと連係し、バリデーションの結果がfalseだったら、XmlHttpRequestが発動する前に処理を停止する、という流れ。これは非常によく使いそう。

で、ポイントとなるのはJavaScriptバリデーションコードをどうやって書くのか、というところ。

もしも自前でバリデーションコードを書くのならば、AjaxHandlerが生成するJavaScriptコードで、XmlHttpRequestの実行前にリクエストを実行するかどうかを判断するためのコールバックを用意し、そこにバリデーションコードを書けばいい。

なんにしろこういうパターンは絶対にあるだろうから、Ajax.*を生成する直前に呼ぶcheckValidCallbackとかを作って、その結果がfalseだったら処理を中断する、というオプションを作った方がいいだろう。

ただ、バリデーションコードがライブラリ化されている場合、自分でその実行タイミングをハンドリングできない可能性もある。たとえば、AjaxHandlerと同じように、Event.observeでバリデーション処理をハンドリングするようなバリデーションライブラリだったら、その実行タイミングはイベントハンドラーの実行順序に依存する。

また、HTML_QuickFormみたいにform.onsubmitに直接関数が記述されるようなパターンの場合、同じformのsubmitにEvent.observeしたら、どういう処理が行われるのか、という問題がある。

「まずform.onsubmitに直接記述された関数が呼ばれ、その戻り値がfalseでなかった場合にのみEvent.observeした関数が呼ばれる」なんて感じだといいのだが、「Event.observeしたら、form.onsubmitに記述されていた関数呼び出しが無効になる」とか、「Event.observeした関数とform.onsubmitに記述された関数の実行順序は不定」とかだと、話はややこしくなる。

まずはその辺の挙動について調査してみるか。

_ form.onsubmitとEvent.observeに関する実験

<script type="text/javascript" src="prototype.js"></script>
<form id="test" onsubmit="return formOnSubmit();">
<input type="submit">
</form>
<script type="text/javascript">
function formOnSubmit()
{
	alert('formOnSubmit');
	return false; /* A */
}
Event.observe('test', 'submit', function() {alert('EventObserve'); return false; /* B */}, false);
</script>

上記のようなコードを、Firefox 1.5.0.1、IE 6.0.2900.2180、Opera 8.5でテスト。

イベントハンドラー実行順序はどれも、form.onSubmit→Event.observeの順序。ただし、form.onSubmitの戻り値がfalseであっても、必ずEvent.observeした関数も呼ばれてしまう。

つまり、もしform.onSubmitのコードがバリデーションロジックで、バリデーションでエラーがあったのでfalseを返したとしても、その後に続くEvent.observeした関数＝Ajaxリクエストコールは呼ばれてしまうし、Event.observeした関数には、バリデーションロジックの戻り値は伝わってこない。HTML_QuickFormみたいに、alertでエラーメッセージを表示するバリデーションロジックを出力する場合は、単純にEvent.observeしてAjaxリクエストコードを追加するパターンは使えない*2。

ちなみに、A、Bの戻り値をいろいろ変えて試してみたところ、そのあたりの処理にはブラウザ互換性がないことが分かった。

Firefoxはどちらかがfalseだったら、submit動作が止まる。IEは最後に実行されたイベントハンドラーがfalseを返したときのみ、submit動作が止まる。Operaはform.onsubmitでfalseを返したときのみ、submit動作が止まる。なんだか面倒くさいなー。

ちなみに、

Event.observe('test', 'submit', function(event) {alert('EventObserve'); Event.stop(event);}, false);

なんてしちゃえば、すべてのブラウザでsubmit動作が止まったんで、自分のコードで確実にsubmit動作を止めたければ、Event.stopを使えばいいのかな。

で、トータルでどうすればいいのかいろいろ試行錯誤して、

var currentHandler = $('test').onsubmit;
$('test').onsubmit = undefined;
Event.observe('test', 'submit', function(event) {
	if ((typeof currentHandler == 'function') && (!currentHandler())) {Event.stop(event);return;}
	alert('EventObserve'); 
	Event.stop(event);
}, false);

なんて感じで、デフォルトのonsubmitを強引に後から追加したイベントハンドラーの中で実行し、その結果によって後から追加したイベントハンドラーのメイン処理を実行するかどうか分岐できるようにしてみたんだけど、FirefoxとOperaではこの方法でいけるんだけど、IEでは思ったように動いてくれないなー。

でも、どうにかしたいんだったら、こういう方向のアプローチくらいしかない気がする。JavaScriptのイベントハンドラー周りの実装っていまいち理解できていないから、その辺をちょっとお勉強してから、もう一度チャレンジしてみるか。

_ バーレーンGP予選

今年の予選の第1、第2セッションは面白いな。ただ、今回みたいに赤旗とかのトラブルが出たときの影響がちょっと大きすぎる気がするから、その辺はもうちょっと何とかした方がいいかも。

で、それに対して第3セッションは、最初何をやっているのかさっぱり分からなかった。第3セッションには、燃料制限があるってことは知っていたけど、それがどういう意味なのかよく分かってなかったっつーか。

要するに、第3セッションは

• 第3セッション開始時に入れた燃料で、決勝（のスタート）を走らないといけない。だから、第3セッション開始時には決勝スタートのための燃料を入れておく。
• 予選中に使用した分の燃料は（周回タイムが極端に遅くなければ）周回数に応じて、決勝前に補給できる。
• 予選でタイムを出すためには、燃料が少ない方がいい。だから、第3セッションの序盤は、終盤のタイムアタックのために燃料を減らすことに費やされる。
• ある程度燃料が減った段階で、タイムアタックをはじめるチームが出てくる。ただし戦略によって、どの程度燃料が減った段階でタイムアタックをはじめるかの判断は異なるし、第3セッション中もタイヤ交換も可能なので、戦略の幅は非常に大きい。

って感じなのね。で、そういうことだって分かった上で、今回の予選の結果を考えると、フェラーリの1−2ってことの意味は、現状ではまだ何とも判断できない。少なくとも去年よりは速そうではあるけれども、ルノーやホンダとは戦略が全然違うんじゃん？って可能性がものすごく高そうだし。

なんて感じで、今年の予選の第3セッションは、単に見た目（序盤にみんなでだらだら走っている意味）がわかりにくいというだけでなく、その結果から決勝や各チームの実力が読みにくい、という意味でも分かりにくい。

ただ、このわかりにくさは、一応考えればそれなりのパターンに整理することは可能なので、ある程度情報がそろって、その解釈の仕方に慣れてくれば、F1の（見ての）面白さを増す効果があるかもしれない。

それにしても予想を外さなかったのはマクラーレンだな。今年も信頼性に問題がありそうと誰もが思っていたと思うけど、見事にその予想が当たっていることを示して見せた。しかも突然リアサスペンションが折れるって、去年のリアウイングが飛んだシーンとか思い出したな。ああいかん、今回も最初にリアウイングが外れて、それでリアサスペンションを壊したのか。サスペンションが折れた方が先かと思っていたよ。

一応レースに参加できているアグリチームは、ひとまず最初の数戦は走行距離を稼いでデータと（井出は）経験を蓄えつつ、他のチームの邪魔にならないように頑張りましょうって感じか。車が壊れないようならば、琢磨の方は2、3戦で下位チームの争いに参加できるようになるんじゃないかな。

_ Zend_Controller_Dispatcher_Standardのtrunk 247行目

           if (!$this->getParam('useDefaultControllerAlways') && !empty($controller)) {

は

           if (!$this->getParam('useDefaultControllerAlways') && empty($controller)) {

のような気がするんだけど、いい花粉が飛んでいて頭がぼーっとするせいで、いまいち自分の判断が信用できない。ここは、useDefaultControllerAlwaysが無効な場合は、コントローラ名が解決できない→例外を発生させる処理だよな。