tmty.jp

その後、berylの調子が悪いので、結局フルで入れ直した。「デスクトップ効果」メニューで十分ぐりぐりできるし、確かに前よりサクサク動く。

で、開発(というかテスト)環境も久々に再構築。
僕の場合、パッケージに頼った方が無難とは分かっていながらも、

• 自分流にアプリケーション配置したい
• 更新に即対応できるようにしておきたい
• いろんな条件のサーバに触ることになっても無難に対応できるようにしたい

とかの理由で、せめて開発にわりと直結するげなアプリについては、ソースからインストールすることが多い。パッケージによってはオリジナルと比較して全然違うファイル構成になってたりして、設定方法もわけわかんなくなっちゃってることあるし。なんかあったときに、動作を追うのが大変だから、入れるときに一通り確認するようにしてる。(でもmysqlはいつもビルド済みのバイナリを拾ってきてた。)

ということで、ubuntu 7.04 に apache-2.2.4, mysql-5.0.37 入れて、php-5.2.2 の設定に
進んだら、configure でエラー。

とか出ちゃう。いろいろログを追っていくと、どうも glibc 周りがクサい。で、glibc のバージョンを確認。

うお、2.5 だ。etch も 2.5 って聞いてたけど、$ cat /etc/debian_version したら 4.0 だし、なるほど、これは見逃していた。

ということで、今回インストールしてたのが mysql-5.0.37-linux-i686-icc-glibc23.tar.gz だったから、これをソースからインストールすることに決定。mysql-5.0.37.tar.gz を拾ってきて、configure する。mysql ソースインストールは初めてだ。

ところが、この configure も通らない。

ぬー、なんか足りないらしい。あまり深いライブラリ群まで一個一個用意するのはさすがに手間なので、このあたりからパッケージに頼ることにした。$ apt-get source mysql-server-5.0 でパッケージのソース一式を取得し、 *.dsc の中の Build-Depends を確認。libncurses5-dev が足りなかったらしい。

ここまでのまとめ

• ソースインストールとパッケージインストールを中途半端に混在させると、バージョン合わせとか超大変。ソースでやるなら覚悟を決めて、着実にやる
• 新しげな環境へのソフトウェアインストールは、ちゃんとマニュアルを読んで一歩一歩進める
• READMEとINSTALLちゃんと読んでいけば、大体インストールできる
• apt-get source で取得したファイル中でパッケージの依存関係がわかるので、糸口掴むのに使える

とりあえず、php-5.2.2 の configure までは通った。
でも、make test でまだコケる。なんでー？

(2007/05/30追記) その後、システム開発の備忘録 さんのエントリを発見。うちもFAILEDが6個だったから一緒かな。(クリーンインストールなので設置済みの php.ini があったわけではない。)
テストの内容、fixされたバグ的に、あまり重くない内容のようだったので、レポートだけ送って、オフィシャルの対応を待つことにした。そのまま make install できたし、いまのところ特に問題なく使えてる。うーん、ちと気持ち悪い。

前回書いてからずいぶん経ってしまったが、業務利用のマスタメンテナンスツールをQcodoで開発していく手順について職場のJさんにまとめてもらったので、いろいろ晒してみます。業務システムに限らず、旧来のwebサイトに適用して、なんちゃってCMS/カンタン管理ツールみたいなモノを作って、サイトの運用をラクにする、というような使いかたもできるとおもいます。Jさんにはあらかじめ許可をいただきました。感謝。

実際のところ、Qcodoを使えば、最低限のメンテナンスツールは、

1. codegen_setting.xml で対象テーブルと関連を定義する
2. codegen.php で全部自動生成する

の2ステップだけで開発完了してしまう。カラムの日本語化やページレイアウト変更の多少の手間は残るが、それが我慢できるなら、難しいことを考える必要は無い。

業務利用しているデータメンテナンスツールとなると、そうもいかない。認証機能や、登録編集時の確認画面、検索機能、各種ビジネスロジックなどの追加要件は、どうしても発生してしまう。

つーことで、うちの場合は、Qcodo利用の勘所(ココを使うのが便利!!ってとこ)を、次の２つに絞った。

1. モデル(entity+dao)が自動生成できること
2. UIを作るためのライブラリが充実していること

上にも書いた通り、自動生成機能は entity+dao だけのコード(data)生成に留まらず、フロント(formbase/panelbase) の生成までもサポートしてくれてるんだけど… 仮に好きなようにロジックを追加したいのであれば、モデル部分は自動生成したものに任せ、フロントの部分は formbase を拡張する形で作るのが自然なアプローチになりそうだ。

ということで、今回の開発手順は、次のような感じでまとまった。

1. 認証とセッション管理、編集確認、検索、ロギングの機能は共通機能として自動生成時のベースに含める。これらを適用した基本的なUI(*.tpl.phpなテンプレートファイル)も自動生成する
2. 各テーブルを編集する際のビジネスロジックはFormBaseやPanelBaseをベースに、これらを拡張(継承)する
3. テンプレートを書き換えたい場合、生成後の *.tpl.php を書き換える。使いたければQcodoの各種UIライブラリも使う(テンプレとロジックの結合度がわりと強いので、UIライブラリを使う場合は↑のロジック側にもいろいろ手を入れてやる必要がある)
4. 自動生成された entity+dao と、任意に書き換えたFormBase, PanelBase, *.tpl.php をサーバに配置する

ちゃんと書いていきたいけど、眠くなったので寝る。続きは今度かく。
ところで、qcodoと前のエントリで書いていたが、Qcodoが正しいみたい。

タイトルわかりにくいけど、検索されそうなキーワードを並べてみた。

またEthnaでADOdbするときのTIPS。カラムがいっぱいあるテーブルへのinsertは、

よりか、

みたくautoExecuteにした方が見ためにもメンテ的にもよい。でも、これだと

みたく、タイムスタンプが拾えない。というか、now() とかしちゃうと MySQL 固定になっちゃう。autoExecute しながら DB タイムスタンプ(現在日時)をさくっと突っ込みたい。

解決法。

などと、$db->db->Time() で拾ってやればよい。

ここに至った経緯。
ADOdb邦訳マニュアルによれば、

ADOConnectionフィールド

-中略-

sysTimeStamp:現在のタイムスタンプ/日付時刻の値を取得するため呼び出すデータベース関数名を保持する文字列。

ということで、$db->db->sysTimeStamp で MySQL 接続時に NOW() が取得できていることを確認。この結果をうまく使ってるところは無いかと、ADOdbのPHP実装をgrep。adodb.inc.php中で発見。

<br /> function Time()<br /> {<br /> $rs =& $this->_Execute(“select $this->sysTimeStamp”);<br /> if ($rs && !$rs->EOF) return $this->UnixTimeStamp(reset($rs->fields));<br /> return false;<br /> }<br />

取得できるのはUnixTimeStampなんだが、MySQLに突っ込んだらそのまま受け取ってくれた。

自社案件のライブラリ化にようやく目処が付いた。20日弱かかった。

開発時にちょっと強引な環境構築をしたので、そのメモ。他の人が読んでも参考になるところはほとんどないと思うが、実開発利用の一例として。

今回作ったのは、ドメインモデル。ライブラリを作るのにEthnaが提供してるbackend機構やらUnitTest環境が便利だったので、活用させてもらった。各種ビジネスロジックはAppManagerをextendsして実装。

Ethna自体は、今どきのPHPフレームワークほど高機能では無いが、シンプルでわかりやすく、取り回し(好きなような使いかた)がしやすい印象。いかにもPHPといったかんじ。正直、かっちりしたフレームワークをちゃんと使いたいのであれば、PHPじゃないほうがよっぽど書きやすいし、今回のライブラリ化でそれを痛感した(PHP4/5(自社環境的にそうなる)で、自社要件の範囲内でちゃんと機能するObject#equalsをゴリゴリ書くとか、泣きそうだった)。が、特にうちのような業務要件においては、思い付いたことをさくっと試してみたいことが多いし、そういうのにPHPは向いていると思う。

一方、本来であれば、ビジネスロジックの部分は独立実装しておいた方がよかった。フレームワーク依存してしまうので。ここは追々利用状況をみながら依存性排除していこう。インタフェースを合わせておけば問題ないし。

最終的なライブラリは、以前PHP勉強会でご紹介いただいたsakamotoさん作成のPEAR_PackageProjectorを使わせていただき、PEARパッケージング。問題なく使えました。

で、このパッケージは自社用共通ライブラリ置場(PEAR置場含む)を定義して(今回は/usr/local/lib/pear/foo)、そこに展開。

パッケージ内に各種テストケースをEthna_UnitTestCaseをextendsする形で作成。

開発時の動作確認はドメインモデル開発用のプロジェクトhogeをadd-projectし、app以下にPEAR以下の開発中ライブラリをsymlink。これで、PEAR以下で開発しながら、そのUnitTestをhoge以下app/hoge_UnitTestManager.phpで実行。できたものはPackageProjectorで逐次固めていく。動作確認用のプロジェクトfugaをadd-projectしておいて、そこでライブラリ利用コードを逐次書く。

全体の構成はこんなかんじ。これで、ライブラリを作りつつ、テストもやりつつ、利用プログラムを書きつつ、のサイクルが手元で全部回せる。

上記構成で、/usr/local/lib/pear/foo 以下のライブラリを更新しつつ、unittest.phpで逐次動作確認し、うまくいっているようならPEARパッケージングしたり、プロジェクトを想定したfugaからの利用を試行してみたり、というかんじ。

うまくビジネスロジックをライブラリに閉じ込めることができたので、今後の自社サイトはこれを利用してEthnaのプロジェクト単位で作っていけるようになるはず。業務ロジック/ルールを意識することなく、Actionからライブラリ上の各種Managerをコールするだけで済めば、もっといろんなサイトがごりごりぼこぼこ作れるとおもう。

業務分析をいろいろやったので、その経緯は、また今度書く。

EthnaのADOdbが良いらしい。使ってみたら、PEAR::DBと同じ感じで使えるけど、結果キャッシュもできてわりと高速。

したら、

みたいな感じで使える。arrayを外で作っておいてprepared statementとしてもOK(というか、そのための機構だ)。

insert_idを取得するメソッドはEthna_ADOdbにラップ実装が無いので、ADOdbのメソッドを直接叩く。

こんだけ。