function updateUserName($userName){
    Log::log('updateUserName: ' . $userName); // ログなどのaspect
    parent::updateUserName($userName);
}

function updateUserAge($userAge){
    Log::log('updateUserAge: ' . $userAge);
    parent::updateUserAge($userAge);
}

// update*()の中のupdate*()に対して
function updateUserAllData($userData){
    Log::log('updateUserAllData : updateUserName : ' . $userData->userName);
    parent::updateUserName($userData->userName);

    Log::log('updateUserAllData : updateUserAge : ' . $userData->userAge);
    parent::updateUserAge($userData->userAge);
}

などと出来るなーと考えてたんだけど・・・ソースの生成は面倒だしトラブルが全然予測できないなぁ。

XPの「将来使われるだろうと予測される機能は実装しないこと。何故ならいつになっても使われることはないからだ。」というものを頭に入れつつ考えていこう。

2005-08-19

日付感覚ない人

雑記

リンクをさくっと回ってたんだけど、8月18日って昨日のことだったんね。
勝手に数ヶ月前の記事だと思い込んでしまってた。

だから何だって言うわけでもないんだけど・・。

2005-08-19

バイトのお話

雑記

結構大きめの仕事が入りそうな感じ。
規模が大きいんじゃなくて価格が。一般企業にとっては普通だろうけど（っていうか安いけど）一学生にとっては大きいのです。一人で作ってるし・・。（報酬貰えないかなぁ

そこの現状のシステムはHTMLにPHPを付け加えた感じで、DBもほとんど使っていない。
DBは従業員の頭の中に構築されている感じだ（それも凄いが
問題は、頭の中のDBで作業をするのがその人にとってやりやすいのか、DBを使ったシステムを作って使い方を覚えてもらった方がやりやすいのか、だ。
いや、もちろんDBで管理はするけども、現状のやり方を変えてもらうのはよろしくない気がする。
作業を変えるのではなくて作業を減らすだけに徹する。
結構難しそうだな。

前の担当者は客の要求をのみすぎて「あの部分のソースを見るのはもう嫌だ。」って言っていたので、そうならないようにしないとなぁ。

ユーザに優しいシステムを短期間で、しかも意見を聞きながら変更しながら作ってたらプログラムがどうしても見にくくなる。

自分フレームワークは最初は社内で使うために作ろうとしてるから多少時間がかかったり修正が入ったりしてもいいんだけど、製品として客先に納める場合は現時点では使えない。

ということで既存のフレームワークなんですが・・。
ちゃんとした考察じゃなくてほとんど直感でいくと。
Mapleの考え方はいいけどフレームワークの規模が大きすぎる。
Ethnaは面倒くさいことが色々減りそうだけど設定の記述方法がどうも合わない感じ。うまく言えないけど継承の概念が嫌なんだよなぁ。ビジネスロジックは継承するけど、フレームワークを継承したくない。細かいかな・・。
guessworkはページ毎にURLが変わってしまう？あと共通設定の方法がやりにくそう。
そして、一番の不安はどれも発展途上というか何というか・・。少々枯れてるくらいがいい。

Mojaviは・・・・なんかJavaっぽいのが嫌だよ。
setAttributeとかgetParameterとか。もっとPHPっぽくさっくりいきたい。

あーーー。非常に困った。
機能の追加は一時中断して自分フレームワークの簡易版でいくか・・。

そもそもソースコードが全体で1万行いかない程度なんだから既存フレームワークを使うまでもないのかなぁ。

既存のものを使わずに自分で作ろうとしてしまう、後から規模が大きくなることを予測できていない、失敗の典型になったりして。

まだはっきり案件が決まったわけじゃないからそれまでは今まで通り自分の使いやすいものを作るとしますか。。

2005-08-19

ソース書き換えメモ

PHP

PHP5なら比較的簡単にaspect用ソース書き換えができるんじゃないだろうか。
http://www.thinkit.co.jp/free/marugoto/1/1/3/1.html

2005-08-19

インジェクション

PHP フレームワーク

DBの接続文字列を自動設定したかっただけなんだけど、プロパティの自動設定と設定ファイルからのメソッド実行機能をつけてみた。
今思えばコンストラクタ引数で指定した方が良かったのかな。
でも一応DB名、ユーザ名、パスワードを分けて記述しててコンストラクタ引数が盛り沢山になるのが嫌だったからいいか。

これが世に言う何とかインジェクションってやつなんだろうか。
guessworkがバージョン上がるのを待ってそっち使った方が良かったんじゃないかっていう疑問が。

まぁこれで前にどこかで書いたDBの接続処理はどこで行うのがいいのか、とかhttp://d.hatena.ne.jp/katase_n/20050712#1121188319とかが解決。

全ページでDB接続を行うならグローバル設定でDBコンポーネントを読み込めばいいし、それぞれ必要なときに読み込んでもいいし。
アクションでもフィルタでもコンポーネントでもメンバ変数をコンポーネント名にすれば自動でインスタンスが設定されてDB接続も行われるし。

これでやっとプログラムを書く時に少しは楽になりそう。

2005-08-19

未設定のときのデフォルト値

PHP PostgreSQL

php-usersより

$conn->query("insert into sample(id) values($id)");

このとき$idが設定されていないと空白（というか空白も無いけど）になってしまうけど値がnullならnullを設定したい。
http://ns1.php.gr.jp/pipermail/php-users/2005-August/027020.html
色々な対処法があってちょっと目から鱗。
どうせ抽象レイヤ使うなら意味無いっていうのは置いといて。。

2005-08-19

もうちょい考察

PHP フレームワーク

改めてguessworkのデモムービーを見てみる。
あの自動設定はどうやってるんだろう。
set*()を見てクラスを探すのかな。

今自分のコンポーネントの設定ファイルを見てみると

component = Sample
class     = Sample
path      = Sample.class.php

ってなってる。

こりゃ確かに面倒なだけだわな・・。

無くても上のような場合に限り自動生成するようにしてみようか。

そんでふと思ったけどPHP4なら

// singleton
$component = & $container->getComponent('Component');

// copy
$component = $container->getComponent('Component');

って使い分けられるんだよなぁ。
これはコンポーネントの登録時じゃなくて取得時に判断するから、また意味が違ってくるのか。

やらない方が吉か。