OR検索
 日記

　ふと思ったけど。googleとか検索エンジンの影響で、スペース区切りのLIKE検索に対する需要はけっこうあるんではないか。と思う。たぶん、要件に「テキストボックスで検索」なんてあったら、きっとそういうものをイメージしてるんではないかなあ。

　しかしこれを普通にDBでやるには、

• LIKE句をANDでつなげてかっこでくくって、それを複数のカラムに適用するためにORで結合
  

　という、なんとも心配なSQLを書くことになる。
　まあ技術者としてはあまりやりたくないわけだけど、たぶん普通にイコール検索しか実装しなかったり、テキストボックスをカラムごとに分けちゃったりすると、ユーザは舌うちをしてるような気がする。どうしよう。

日本人の議論はすぐ喧嘩になる
 日記

• 外人の討論はおだやかなのに、日本人の討論は何ですぐに喧嘩になるの
  

　日本語は難しすぎて日本人にも使いこなせてないからじゃないかなあと思った。

　いやまずそもそもその命題の根拠はなんだとか、外国ってどこだとかって感じもするけど。

［2007.10.25 22:21］さかい :
単なる慣れの問題でしょ。
あと日本という国に移民が少ないという意味では、いわゆる外人よりも日本人は討論に慣れていない人が多いと思う。日本語不自由な人といっしょに地域生活送ってれば、必然的に討論もおだやかになるよ。がまんして人の話を聞くようになるから。

［2007.10.25 23:55］T-ruth :
日本語が難しいなぁ、というのは同意。書いててそう思うし（意味違w）。

日本が真に合議制のなあなあ社会であったならば、互いの落としどころを見つけるためのスキルが磨かれなかったとは思えないので、大衆的には「話し合い」より「殴り合い」の文化だったんでしょうね。
それで済んだのも、民族の単一性が高いからなんですかね？　引き際が暗黙の了解になってたりするとか。
仮定に仮定を重ねた議論で申し訳ないですが。

［2007.10.28 02:55］さかい :
民族の単一性などが原因というのは賛成です。そうでない異民族間では、「殴り合い」が「殺し合い」に発展しやすいですからね。それを防ぐために、欧米では「話し合い」の技術が発展したってとこでしょうか。

うーん -2011/01/16 15:55
でも、出口の見えない不景気に加え、海外との競争が激化にしている昨今
「野蛮人とは違うんだから、ゆっくり討論に慣れていきましょうね。」では済まされないと思います。

extended by句
 プログラム

　クラス作ってるとときどき「継承する」じゃなくて「継承される」を宣言したいことがあるじゃん。「extended by ○○」って思わず書きたくなったり。
　え？　ない？

　ってわけで作った。いつものrequire_onceのかわりにclassInclude() ｉｎｃｌｕｄｅＥｘｔｅｎｄｅｄＣｌａｓｓ（）と書くと、extended by句が使えます。

class hoge extended by piyo {

　って作っといてなんだけど、ぜんぜんうれしくねーなしかし。

<?php
function includeExtendedClass($file) {
    static $included;
    if(!is_array($included)) $included = array();
    if(in_array($file , $included)) {
        return;
    }
    $included[] = $file;
    $content = file_get_contents($file , true);
    $content = preg_replace(
        '/class\s+([a-zA-Z0-9_]+?)\s+extended\s+by\s+([a-zA-Z0-9_]+?)\s*\{/i'
        , 'class $1 extends $2{'
        , $content
    );
    $content = preg_replace(
        '/function\s+([a-zA-Z0-9_]+)\s*(\(.*?\))\s*\{/i'
        , 'function $1 $2{
            $args = func_get_args();
            $callback = array(\'parent\' , \'$1\');
            if(is_callable($callback)) {
                return call_user_func_array($callback , $args);
            }
        '
        , $content
    );
    eval('?>' . $content . '<?php ');
}
?>

　うーむいかん。本気で役にたたない(笑)

［2007.10.24 01:40］てらしま :
　お。普通のクラスにはぜんぜん使えないじゃんこれ（気づけ）。だめじゃん。
　ということでまぎらわしいから関数名を変更。

［2007.10.24 05:14］white :
仮に言語の構文として組み込めたとして、宣言したいタイミングが抽象クラス作るときぐらいしか思いつかないのだけれどどうなのよ。
要はコメントが書かれている状態に置いておきたいって話のように思うんだが。

［2007.10.24 20:20］てらしま :
　いまちょっと考えても思いつかないくらいだし（笑）使わなきゃならない場面はないんじゃないかとは思いますが。

体内時計と光
 日記

• 体内時計、真夜中の光はやっぱり禁物
  

　ともあれ、睡眠時間を減らすために電気をつけっぱなしにして寝るのは正しい方法なわけですな。

入力チェックってどこでやればいいんだろう
 日記

　いろんなフレームワークで、入力チェックが簡単に作れそうに見えるいろんなやりかたをしてるわけです。たとえば、定義ファイルになんか書いとけば勝手にやってくれるとか。
　でもそういうもので、まともに使えるものにお目にかかれたことは一度もないんである。

　最近やってる.NETでは、ビューにフォームと一緒に検証コントローラを配置しといたりするわけだけど、もちろん案件の要件は.NETのために作られたわけではないので、うまくいかないケースがあったりする。
　そりゃあプログラム書いてるんだから、できないことはない。やりようはいくらでもあるわけだけど、でもそれをやるならはじめから、.NET組みこみの検証コントローラなんかつかうなよって話になる。
　そんなわけで、ほとんどの場合は、というかまず確実に、フレームワークが用意した入力チェックを使わずに、はじめから自分で作ったほうがわかりやすかったりする。工数も確実に少ないし。
　もちろん、フレームワークの作者が本気で使いこなせばうまくやれるんだろうけど。残念ながら、フレームワークをつかった開発は一期一会だ。使いこなしたころには終わってしまう。少しでも難しかったりドキュメントが足りなかったりしたら、もう使ってもらえないと考えるべきだ。

　まあ、.NETの場合は特殊っていうか、問題がありすぎる気がするので(笑)他と同列に扱っちゃいけないようにも思うけど。あの場合はきっと、そもそも、ビューに検証コントローラを配置するという考えかたが問題だ。
　で他のフレームワークを考えてみると、コントローラに処理を渡す前に検証を終わらせておこうという方針で作られてるものが多いわけだけど、その考えかたにも問題ある気がする。

　理屈の上でレイヤ分けするなら、入力チェックはプレゼンテーション層にあればいいわけで、コントローラの上にもう一層作る必然性は別にない。と思う。
　というか実際の話としては、MVC的なあれでいうなら、ようするにモデルに処理を渡す直前にやりたい。そうするのが、層分けが明確になってわかりやすい。
　ってことはコントローラの中なのだ。
　しかも、よく思うんだが、そこはオブジェクト化したりフレームワークに組みこんだり、いろいろしないでほしい気がする。どうせ要件（と上流工程の人）はもっと非論理的だし。フレームワーク組みこみの方法ではどうせ対処できなくなるし。
　全部staticのユーティリティクラスでいいのだ。それを一つ一つ呼ぶ処理を、ずらずら書き並べればいいじゃないか。それでいいじゃないか。

　最近（職場の中で的には）オブジェクトの人になっちゃってるわたしですが。オブジェクトに反対したほうがいいこともある。
　っていうか.NETからは多くの反例を学べる気がしてるこのごろ。要は個人的に肌に合わないって話だけど。