すごく素直にいって、「クラス図からスケルトンコードを生成!」とか、その類のツールが役に立ったことは一度もない。少なくともわたしにとっては。
ただそれには理由があって。大きな会社とかだとずっとひとつのフレームワークとかを使いつづけることもできるけど、小さな会社の仕事はいろいろなのでひとつのツールに習熟することができない、という面がある。
一回限りの環境なら、じっさいのところ、ツールの使いかたを憶えるよりはじめから知っているプログラミング言語でコーディングをはじめてしまったほうが早いのだ。
というわけで本当のところがわからないんだけど。世間的にはああいうの使ってるんだろうか。
とはいえ、世の中がそういう高級な自動化のほうに流れていくだろうことはまあ、普通に考えれば確実だ。なにしろ、そういう機能は広告として強い。わたし自身はああいうものの有用性について懐疑的だけど、必然の流れと思う。
ところでわたしはEXCELが嫌い、というか憎んでいるのだけど、世間には「EXCELの設計書からコードを自動生成!」とか「テーブル定義書からスキーマを生成!」とかそんなツールがたくさんある。
自動化はしかたないけど、EXCELが主流になるのだけはイヤだなあ。でもそうなっちゃうかな……。
#あー、あと思うんだけど。EXCELから自動生成したあと、逆にコードからEXCELに反映ができないツールばっかりなのはなんとかしてほしいなあ。できるようになればずいぶん違うがなあ。
[2008.02.22 08:56]中田 :
自動生成したあとコードをいじらなきゃいけないようなら既に自動生成の価値は失われてると思うんだけど。そういうときは定義書をいじって再生成するべきで、それじゃ対応できないなら、もうそのコードは自動生成するべきじゃないんだよ、たぶん。
(そこで自動生成ツールを改造するという選択肢もあるけどね)
[2008.02.23 04:30]てらしま :
たしかに、そう考えるべきなのか。ジェネレーションギャップパターンだかなんだかを使って親クラスだけ生成とか、そういうポリシーを徹底できて再生成が可能ならそうすべきなんでしょうね。
それでいうと、スケルトンしか生成しないのはやっぱり無意味ですかw
というわけで、主にsourceforgeを使ってみたかったので先週作ったDaomancyのプロジェクトを作ってみた。
ソースフォージ便利じゃん。すごいじゃん。いろんな設定がわかってみればだけど。
むしろ作るべきはボドゲ専用ライブラリとかだろーという気がするので、そのうちやりはじめるかも。
ここ2ヶ月弱ほどJAVAに苦しめられてるわけですが、ようやく意味がなんとなくわかってきたら、なにが大変なのか見えてきた気がする。
しょうじき、どれがstrutsでどれがspringでどれがこの案件独自なのかもわからない状態で作業してたんです。これはわたしだけじゃなくて、今回の仕事やってる人の大多数がそんな状態で。炎上してる仕事ってのはそんなものなんでしょう。
で、ようやくなんとなくわかってきたこと。
このめちゃめちゃ大量にあるXMLはspringのせいか!
今日ちょっと調べてたら、DIだのアスペクト指向だのって、たしかにまあおもしろいことをしてる。しかし、そのためにこのクソ長いXMLを全部書かなきゃならないのかー。
これはつまり、一箇所でも間違えてると動かないわけです。
なにかこう……アスペクト指向って新しい思想らしいけど、結局全部設定するっていうのはどうも、どこかいままでのオブジェクト指向とは逆行する考えかたという気がするんだけどどうなんだろう。けっきょく記述増えてない?
せっかくEcropseなのに、XML書いてるときはろくにコードサポートしないし。
まあ、今回はさすがにわからなすぎの状態だったから、もう少しわかってればもっとなんとかなるんだろうけど。
仕事のグチはおいておいて、じっさいおもしろそうなので暇なときに調べようと思った。
S2Container.PHP5なんてものもあるらしい。
以前某人の日記で見たS2Jdbcがなにやらかっこよさげだったので、PHPで似たものを作ってみてます。けっこう違っちゃったし、PHPらしくもっといいかげんだけど。
でせっかくなので公開してみる。バージョン0.1.0.
はたしてPHPでこんなものまで使う人はいるのか? とか思わないでもないけど、まあおもしろそうなので。
どういうものかというと、つまり↓のようなことができます。
本家S2Jdbcとは微妙に違ってたり。
$page = Daomancy::_($dbh) ->from('PageDAO' , 'p') ->join('CategoryDAO' , 'c') ->on('p.category_id = c.category_id') ->where('p.name LIKE ?' , 'Daomancy%') ->and_('c.category_id = ?' , '1') ->and_( Wheremancy::in('category_kbn' , array(0 , 1 , 9)) ) ->orderBy('p.category_id ASC , p.page_id ASC') ->limit(10) ->offset(0) ->fetch();
やりたいことはだいたい見ればわかると思います。
PageDAOというクラスとCategoryDAOというクラスを結合してDBに問い合わせしてるわけです。
基本的にはテーブル単位のアクティブレコードを作っておけば、あとはDaomancyが結合してオブジェクトを生成してきてくれます。
とってきたものは、↓のように使えます。
$pageContents = $page->p->contents;
$categoryName = $page->c->name;
カラム名と同じ名前のpublicフィールドを持ってるのです。
ようするにアクティブレコードなんだけど、更新は↓のように。
$page->p->contents = 'ほげほげ';
$page->p->update();
複数テーブルまとめて更新とか。
$page->p->name = 'page新しい名前';
$page->c->name = 'category新しい名前';
$page->update();
インタフェースはこれでいいのか?とか、テストが不充分だったりとかするのでバージョン0.1ということで。
それにしても、andとorが予約語だったせいでメソッド名にアンダーライン_がついちゃってるあたりがちょっとかっこ悪い。
まず根本的な話として、PHPはセキュリティに強い。もちろんいろいろ問題はあるが(ていうかけっこうあるが)、html専用のエスケープする基本関数がある言語なんてあんまりないわけだし。
問題がよく起こるのは技術者のレベルが低いことと、つまりPHPアプリに金を払っていないことが原因だ。と思う。
あとそれ以上に、業務系のJAVAのアプリとかだと、外の人が見ないからセキュリティホールがあっても気づかないのです。ていうか本当はきっとあるのです。
別に、問題なんて普通起こらないわけですよ。表示するものはすべて例外なく、表示の直前にhtmlspecialchars、SQLにはすべて例外なくプリペアドステートメントを使う、それだけのこと。
……で防げない場合ももちろんあるけど。ほんとにこれだけではないのでアレです。信じないで。
でも、よくおきるインジェクションの問題は、もちろん、上の基本以前のところで起きているわけで。
別にそれほど変な記事じゃないのに、というかどちらかといえばまあいいほうの記事という気もするのになんでわざわざ反論してるかというと、イヤなことが書いてあったから。
入力文字列は厳格にバリデーション
これが。他にもあるけど特にこれ。
完全に作る側の理屈なんですよこれ。
そういうことをいっていると、わたしの嫌いな「住所の全角チェック」が生まれてきてしまうわけです。住所には数字も英語も入るんだから、全角チェックをしていいはずがないのに。
問題を防ぐために厳格にやるという方法は間違いだ。そのために使い物にならなくなってるシステムがどれだけあるか。
それになにより、手順が増えればそれだけミスも増える。バリデーションがセキュリティホールを生み出すときもある。厳しいバリデーションは問題の先送りにすぎない気がする。
結論は、エラーメッセージ表示するのが面倒だなあという話。でこのサイトのセキュリティがどうかというと(ry