スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

家計簿アプリ

長らくいじっていなかった自作のWebアプリに手を加えた。
自分で作成して、使い始めてから1年以上経ち、その間に見つかった不具合や不便なところにようやく手をつけた。

構成は、Tomcat5.5 + Java1.4.2 + Struts1.2.4 + 独自フレームワーク + DbUtil + MySQL4.1(or Oracle9i) + JUnitといった、今となってはやや古めの構成。途中SeasarでDI+AOPやHibernateなどを組み込んで試したりしたが、結局この構成のままにしている。AOPは非常に便利でコードがかなりすっきりしたが、DIはこれに組み入れたとしても特に利点は感じない。
DI,POJOにするとテストで便利だというが、この発言はEJBの出身者か、ガチガチに密結合でアプリケーションを組んでいた人のものだと思う。
StrutsTestではRequestやResponseのMockObjectを使えば、アプリケーションサーバの起動なしにロジックの確認はできる。あと、サービス層やDAO層でMockを使ってのテストは作成してない。というか不要。DBが中心のアプリで、コントローラもサービス層も大したことはせず、SQLが重要な位置づけにある場合、最初から結合テストでテストケースを作ってしまう方がよかったりする。

もともとこれを素材にいろいろと展開する予定だったが、時間もなく、また放置しておくと使っている技術がどんどん古くなって誰も興味を持たなくなるので、また空き時間を見ながらいろいろな技術を適用していくのは無理ということで頓挫。

まあ、アプリ自体はできているので、試したい人がいたら、無償で提供します。単に自分が欲しいと思った機能をつけていっているだけですが。

家計簿を管理するWebアプリケーションで、1つのアプリで複数の家計を管理できます(こんな個人情報をASP上に置く人はいないでしょうが)。自宅サーバが置ける人であればWindowsでもLinux上でも動き、自分の家で管理できます。携帯からもアクセス可能です。

http://hoge.gotdns.com/acctbook/
ユーザID:user1
パスワード:user1
管理者用ID:admin

デザインセンスのなさを露呈しているだけの気もする。。。

ですます調に変わってしまったが、アプリを改良するとき、JUnitはしばしば厄介になる。GUIからだとすぐに確認できるものが、JUnitでテストケースを作ろうとすると、テストデータを組み立ててと時間がかかる。テストを組みにくい場合もある。またソースであれば一箇所修正すればいいものの、それをテストケースに反映する場合、何十パターンあるテストすべてに反映させる必要も出てくる。

なので結構億劫になるが、今回やはりいいなあと実感した。簡単な修正なので、大した影響はないと思って直接関連するテストケースはパスしたのでOKだと思っていた。後で全体のテストを走らせると引っかかり、一部考慮漏れが発覚した。こういうときはありがたさを感じる。

ただ、しばしばテストファーストをせずに、最初にアプリで実行した結果を正しいものとしてテストに組み込んでしまうときがある。テストファーストという観点からするとご法度だが、いちいち手動で計算などしていられない。すぐに妥当で正しいと思える場合、GUIをいじって出た結果をテストに組み込んだとしても、レグレッションテストという目的であればこれもありだと思う。

木曜日から手を加えていて、最初にMySQLの文字化けでつまづいた。最初にJUnitのテストケースがすべて通ることを確認してから始めようとしたが、なぜかいきなり文字化け。もともと開発は別のNotePCでしていたものの、NotePCを返却したので、デスクトップに開発環境をコピーしたのだが、事情があって完全には移せなかったらしい。

現在稼動しているmysqldには特にオプションをつけてないはずなのだが。結局開発環境のDBを作り直した。

create database bokeboke default character set sjis collate sjis_japanese_ci;

これでうまく行ったのだが、また突然おかしくなった。
show variables like '%char%';

で見ると、latin1が並んでいる。そこで、

mysqld --default-character-set=sjis --character-set-client-handshake=sjis

とやって、文字化けの問題は解消。

次は、PropertyUtilsの問題。
No getter method for property list of bean XXX

以前、

< logic:iterate id="item" name="XXXX" property="list" indexId="idx" >
としたとき、
public List getList() {
return list;
}
だとエラーになる。
listに対するゲッターメソッドがありません。と出てきてしまう。
public Object[] getList() {
return list.toArray();
}
とする必要があった。


と書いたが、逆のことが発生。linuxのサーバ上では動作している。前NotePCで開発していたときも動作したはず。struts, beanutils, tomcat, javaのバージョンを合わせたが駄目。LinuxのTomcat以下をそのまま持ってきて、javaのリヴィジョンも合わせ、java_1.4.2_10を使ったが駄目。PropertyUtilsを調べたが、PropertyDescriptorに値が正しくセットされていない。不可解。前のと逆に、getListでlistを返すとうまく行く。
ネットで調べたら、getterは一つでないといけないようだ。またJavaのリヴィジョンの違いで動作が変わってしまうようだ(しかし、かなり古い話だ)。

http://mail-archives.apache.org/mod_mbox/struts-dev/200012.mbox/%3C02b601c0711c$01082d70$0100a8c0@ghar.expressotech.com%3E
http://www.ne.jp/asahi/hishidama/home/tech/struts/JspException.html
http://memorandum.cocolog-nifty.com/hoge/2005/01/javabeans.html

MySQLとStrutsタグを使わなければ、開発自体楽だったと思う。だいたい、こんなことではまって無駄な時間が流れて行く。

思うのだが、フレームワークというものは開発楽にするとか、形式を統一するとかいうのではなく、それ以上に、仕様を制約する、ここが一番重要な点ではないかと思う。実装の記述の強制ではなく、仕様の制約だ。つまり、決まりきった使い方しかできないということ。ちょっと変わったことをすれば、途端に対応できなくなり、開発を楽にするどころかひどく困難にする。そのことを言えば、俺様フレームワークの開発者とその信者が、軽く受け流し弁護し、時にはそんな変な仕様にするのがおかしいなどと言う。ある製品を使うときは、単純な使い方以外はやってはいけないのだ。


関連記事
スポンサーサイト

コメント

非公開コメント

プロフィール

dayan

Author:dayan
小職は、SE(システムエンジニア)を専門としておりますが、技術的な情報を中心に、それ以外に経済関連の日記、たわいもない日記も載せていきます。
[公式HPもよろしく!]

天気予報

-天気予報コム- -FC2-
リンク
ブロとも申請フォーム

この人とブロともになる

カテゴリー
最近の記事
ブログ内検索
最近のコメント
最近のトラックバック
RSSフィード
月別アーカイブ


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。