スポンサーサイト

上記の広告は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タグを使わなければ、開発自体楽だったと思う。だいたい、こんなことではまって無駄な時間が流れて行く。

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


スポンサーサイト

日商簿記2級

3級に続けて2級を受験。

手ごたえとしては、そんなに難しい感じはしなかったが、やはり知らないと解けない問題が多い。工業簿記の仕訳は全滅。貸借を逆にすれば何問か合っていたが。仕訳問題の配点は大きすぎる。
帰ってから解答速報を見たが、合格点には届かず、よくても60点。ほとんど何も勉強しない状態で受けて、結構頑張ったほうかな。

あともうちょっとだが、次確実に受かろうとしたら、やっぱりかなり勉強する必要がある。果たしてそこに時間を投資するかどうか。全く手をつけていない過去問集もある。ただ単に勉強がてら受けただけなので、受かったところでどうというわけでもないし。

複式簿記や貸借対照表・損益計算書の基本を身につけるのであれば3級で十分だと思う。ただ、3級の内容は小売店向けで、科目も事業主貸・借が引出金になっていたりとか実際とは違う。サービス業では3級の内容は使えるのか。ソフト開発では、仕入はないが、外注や原価計算が必要になるので、2級の内容が必要になってくるような気がする。資格を取るより、実務でどうしているのか勉強した方がいいかもしれないと思ったりする。

第114回日商簿記試験3級

先ほど、簿記の試験を受けてきた。

全経3級合格後、過去問だけをやってきた。
98-112回の過去問が載っている問題集を買って、最初は全部やるつもりだったが、そこまでやる時間がもったいなかったので、101-112回の12回分やった。一度も合格点を下回ることなく、慎重にやった場合は満点が取れていたので大丈夫だろうと思っていた。

今日受けてみて。
最初の第1問がこれまでの過去問よりちょっと厄介な感じがした。第2問は全経ではよく出たが、日商の過去問ではあまりお目にかからない小口現金の問題、これは簡単。第3問は残高試算表で標準的だが、合計試算表から取引を加算して残高試算表を出すのが厄介。第4問は伝票でこれは簡単、第5問は精算表。1,2,4,5,3の順で行った。5は内容は簡単だが過去問よりも計算量が多く、最初計算が合わなかった。ここは後にして4をやったが、これまた計算が合わない。かなり焦った。
とりあえず確実に取れるものからと、1,2,3をチェックして、解答を問題用紙に書き写しておいた。ついで4。一つ一つ見直したら、計算間違えが発覚し、貸借合計金額が合ってOK。ついで5も一つ一つ見直したら、これまた桁を間違えて計算。よくある間違えのパターン。これで合計もOK。問題用紙や白紙に解答を書き写して、見直し。時間は十分に余った。

当然満点取れていると思ったが、外で大原が解答速報を配っていて、見たらいきなり第1問で2問間違っている。目の前が真っ暗になった。3問以降の解答速報はない。気が気でなかったので、かえってどこかに速報を出しているところはないかと探したが、夕方のが多い。その中で、大栄というところですぐに出していた。とりあえず、第1問めの2つを除いて間違いがないことを確認して一安心。

間違えたのは、1-2「店主の生命保険料」というのを見落としていて、資本金から差し引くのを忘れていた。「ただし、火災保険料のうち30%分は店主個人...」というほうに気を取られ、問題文をちゃんと読んでいなかった。見直したときもそこに気づかなかった...orz。甘いな。
あと1-5。当座借越勘定を使うのを忘れていた。「なお、...」以下はよくある但し書きだと思い、注意を払わなかった。

これから2級だが、全く勉強していないので、受験料が無駄になるだけ。4000円は結構高い。ちょっとだけ勉強時間を取って、受かったら儲けものぐらいに思っていたが、全く勉強時間が取れなかった。惨敗は目に見えているが、試験を受けるのも勉強時間のうちと考えて受けに行こう。

3級の過去問で間違えたところはまとめておいて、試験直前にもう一度確認した。

----------------------------------------

○過去問で間違えたところ
・買掛金と未払金、売掛金と未収金を混同しないこと。
・借方・貸方の記入箇所を間違えないこと。未収・未払の位置を間違えないこと。
・残高試算表と合計試算表を間違えないこと。合計試算表では借方総額と貸方総額をそれぞれ書き、差引しない。
・合計試算表では、返品はまとめて差し引かず、相方に書く。
・計算を間違えないこと(桁を間違えないこと)
・現金預金:現金と当座預金を合わせたもの
・備品減価償却累計額⇒減価償却累計額
・備品売却益⇒固定資産売却益
・当期利益⇒当期純利益
・込み入った問題はきちんと仕訳してから
・科目は間違えないように
・見越計上をする際、今期分と来期分を逆にしないこと
・手形記入帳⇒受取手形記入帳、支払手形記入帳
 支払手形記入帳:摘要欄が買掛金・仕入、受取人欄と振出人欄
 受取手形記入帳:摘要欄が売掛金・売上、支払人欄と振出人、裏書人欄
・下3桁を忘れないこと
・貸倒引当金と減価償却の率を間違えない
・月割計算を忘れずに
・売掛金が前期か当期か明記されていないとき、前期として扱う
・2で控除した売掛金は除く⇒差し引くということ
・得意先引受けの為替手形=売掛金減少
・訂正仕訳は、前のを訂正するのではなく、訂正仕訳のみ書く

○迷ったところ
・引落日が未来の場合は、未払金で記帳。経費の未払金は「未払金」で記帳。仕入・売上以外は、「未払金」「未収金」
・切放法:有価証券の処理? 評価差額を売却益等で処理?
・解答する上で関係のない内容に注意
・3伝票制では、仕入取引を現金で行った部分と掛で行った部分とに単純分解する。5伝票制では仕入伝票を使って一旦全部掛で仕入れたことにして、出金伝票で買掛金を控除する。
・登記料・仲介手数料は土地代金に含める
・為替手形で、売掛金・買掛金を相殺する仕組みは理解すること。
・当店振出他店宛の約束手形を受け取った場合、支払手形の減少として処理(手形が巡りめぐってきた)。
・仕入先元帳=買掛金元帳
・得意先元帳=売掛金元帳
・実績法
・商品有高帳の摘要は、商店名(+返品)を書く(全経と違う?)
・同じ取引は重複しないように

○テクニック
・下3桁は計算せず、0でない場合は、小数点を使う。
⇒ただし、今回の第5問みたいな、下3桁が多いと厄介になる。こういう癖をつけてしまうのも一長一短だ。

・試算表の問題では、白紙に総勘定元帳(現金、当座、売掛金、買掛金、受取手形、支払手形、売上、仕入、その他)のT字を作り、仕訳は頭の中でやって日付or通番とともに金額を記入。その他のところは科目も一緒に書く。反対科目は書かない。

・買掛金・売掛金の残高を各商店ごとに求める問題では、○△□を問題中の商店につけて、計算したら/を引いていく。買掛金と売掛金を別々に行えば、2度○△□を別々に使える。

・精算表では、貸借対照表・損益計算書、借方・貸方が換わるところで、あらかじめ区切り印を入れておく。こうすると、間違えて記入してしまうのを防げる。

アート・オブ・プロジェクトマネジメント

オレンジニュースからのリンク。
「アート・オブ・プロジェクトマネジメント」読書感想文【まとめ】

非常に参考になる。本を読む時間がないのでこうやって要点をまとめてくれるとありがたい。
時間があれば原書もじっくり読みたい。

最初に目に留まったのは、見積もりのところ。

「見積もり作業に時間をかけるよりも、着手した方が良い見積もりが得られる」
「1回だけ見積もりでスケジューリングするのは危険」

多くのプロジェクトで見積もりはざっくりやって、着手したあとに再見積もりをすることなく、最初に設定した期限を死守しようとして力技で何とかしようとする。期限は客に公表しているので今さら変更できないからだ。
しかし見積もりの精度を上げるには着手してみる、あるいは少なくとも着手してみようとすることが大切なのだと思う。経験豊富な先達方は、着手しないとわからないというと、レベルが低い、経験が浅い、見積もりが甘い、などの評価を下す。しかし、現実はそうはいかない。未知の分野だと、どうしても精度がぶれる。
やるべきタスクをすべて挙げられない限り、正確な見積もりなどできない。ところがすべてのタスクが挙がるのは詳細設計の段階であり、最初の要件定義の段階では無理なのだ。可能なのは、類似プロジェクトを行った場合だが、もし類似プロジェクトをやっているなら、一度経験している分、同一メンバーが行った場合、過去の作業時間よりも短くて済む。なので、実績はそのまま適用はできない。

できれば見積もりの前に少しでも着手してみてより正確な見積もりを出すか、仮にざっくり出したあとでも、着手後に精度の高い見積もりを出すのはスケジュール管理上重要だろう。

友達の結婚式二次会で

昨日は友達の結婚式の二次会へ参加。
昔通っていた英会話学校のつながりで、そのときの同窓生も結構来ていた。何しろ5年前なので、同窓生のことを果たして思い出せるか、あるいは覚えていてもらっているか、心配だったが、かろうじて記憶に残っていて、ああ、あのときのといった感じで、なんとなく見覚えのある人なんかもいた。5年も経つと人も変わるし、記憶も薄れる。こういう機会はサイクルが短い方がいいのかもしれない。昔話やら今のフィニックスのことなどで盛り上がった。

Mixiの話も出て、結構みんなMixiで交流している模様。最近たまに見るだけになってしまったが、再度Mixi通になろうかと思う。ただMixiで不満なのが、日記と外部ブログのどちらかしか選べないところ。他のSNSにも入っているが、そこでは日記と外部ブログ両方表示できる。このブログは技術的なネタの備忘録にして、日記はSNSに書くというスタイルにしている。Mixiも上場してサービスを充実させたいなら、それもやって欲しいなと思う。

二次会は、運動会ありの楽しいイベントだったが、腕立て伏せをやったせいか、腕が筋肉痛。なぜか腹筋も痛い。

日商簿記3級対策

今度、試験を受けることになるのだが、少し不安なのが、試算表を記入する問題。
解答する前に大量の仕訳をしなければならず、一箇所の間違いが数問の間違いにつながりかねないので厄介だ。

他の人がどうやっているのか知りたかったのだが、Webで簿記の検索をしても業者サイトばかりがヒットする。
2chで見てみると、参考になることが書いてあった。
仕訳は頭の中でやって、T字を使って、
「現金」「当座」「仕入」「買掛金」「売上」
「売掛金」「受取手形」「支払手形」「その他」
の計9つのTフォームをつくる。

例えば、第113回・問3の場合、
問題文の番号(「1a」とか「4c」)と金額のみをTフォームに書く。
相手勘定科目は書かなくて良し。

ただし「その他」フォームだけ相手勘定科目を書く。

だそうだ。これまで、全部仕訳を外の紙に書いて、各科目の値を引っ張ってきて、加算したものにはチェックをしておいて、解答用紙に書いていたのだが、これだと間違ったときに、かなり大変だった。
そうするよりも、仕訳は頭の中でやって、T字に書いた方がよさそうだ。実際それで試してみたらかなりよくなった。ただ、ここに引用したのと違い、「その他」では、相手勘定科目ではなく、自身の科目を書いておく。

こういうテクニックは学校に行っていれば教えてもらえるのだろうが、独学だとその辺の情報がつらい。
それにしても、やはり電卓を打つのは苦手だ。その手の人たちは、電卓打ちのプロフェッショナルだそうで、試験のとき、周りがすごい速さで打っていたら、結構焦るだろうなあ。

表計算ソフトがあるのに、電卓の訓練をしなければならないというのは、ちょっと時代遅れの気がする。プログラミングで言えば、IDE(統合開発環境)があるのに、エディタとコンパイラーでがりがりやっているというのに似ている気がする。

プロフィール

dayan

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

天気予報

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

この人とブロともになる

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


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