元記事：http://www.kbmj.co.jp/tech/index.php?itemid=9
「発想の転換」レベルの話ではありますが、
このアイディアはいただきですね。やるなー。
もう少し洗練化させてみよう。
DAOの実装クラス（＋エンティティクラス）は、
私は大体の場合SQL文などを元に自動生成するツールをプロジェクトごとに用意しているのですが、
さすがに毎回それだと大変なので、、、、
ベースになるDAOの部分を汎用化できると、楽になりそう。
とりあえず備忘録かわりに貼り付けておきます。
http://www-06.ibm.com/jp/developerworks/java/051104/j_j-jtp09275.shtml#resources
JVMのアロケーションは、mallocなどよりも速いですよ、というお話。
参考になります。
経験則的にも、
処理のリアルタイム性を求められないシステムであれば
(ex. Webサイトとか）
FullGCを頻発させない限り、そこそこのシステムパフォーマンスは維持できますしね。
ECナビ 、という価格比較サイトで、ラボをやっているらしい。（Googleやサイボウズみたいですね）
その中の一つが、「ECナビリスト」
アマゾンのウィッシュリストのパワーアップ版みたいな感じですね。
自分が持っていたり、欲しいと思っていたりする本に対して
タギングしたり、レビューを書いたりして、情報を共有する。
その本に対する皆の関心度や人気度が見えてきたり、
タグの内容にを見ることで、その人がどんな観点で本を読んでいるのかが分かったりして、
個人的には面白いです。
非同期通信だったり、Yellow Fadeであったり、
Ajaxをふんだんに多用したインターフェースも、Web2.0っぽくて良いですね。
↓ちなみに、私のリストも作ってみました↓
http://list.ecnavi.jp/user/moaikids
耳の痛いハナシです。。。
http://www.drk7.jp/MT/archives/000959.html
ウチの会社も、似たようなものですねー。
（私が今関わっているプロジェクトは、全部自前で作っているのでちょっと例外ですが）
ものづくりにおいて、一番偉いのは、ものを形にできる人たちだと思います。
Webサイトであれば、
デザインを作るデザイナーであったり、
システムを構築していくプログラマーであったり、サーバエンジニアであったり、、、
もちろん、全体を俯瞰して、あるべき方向にチームをナビゲートしていく
プロデューサや、プロジェクトマネージャーや、
より現場サイドでいえばディレクターやシステムアーキテクト（←私はここ）といった人たちも、
ものづくりをするために欠かせ無い。
こういった人たちがいないと、Webサイトは出来上がらないのですから、当然一番偉い。
（いくら営業が声高にサイトを喧伝しても、Webサイトは出来上がらないわけですしね）
であれば、ものづくりをする人たちを尊重し、働きやすい環境をもっと作っていく努力が必要なはずなんですが、、、、
コストとか、システムに対しての不理解から、外注に丸投げして、品質に対しては知らん振り、、、
ということが多すぎる気がします。
今はビジネス書などでは『現場力を鍛える』がベストセラーになったり、
現場の持つ力が見直されてきているのに、
ことIT業界では、実際にものを形にする人たちに対するリスペクトが足りないような気がします。。。
理由は、
ソフトウェアの中身は技術者以外には見えづらいので、
どれだけ一つのシステムを作り上げるのが大変なことなのか、理解をさせることが難しいことと、、、
あとは技術者の人たちのプライドの無さも、あるかもしれませんね。
（受身で、言われた通りに「すら」ものを作れず、バグが出るのが当たり前だと思っていて、
「良いもの」を作り上げていこうという気概を感じさせる人が少ない）
JavaのExceptionについてです。
http://www.javaworld.jp/technology_and_programming/-/10249-1.html
なかなか勉強になりますね。
わかってはいるんですが、ついつい条件判定に例外機構を使用してしまいます。
(1)処理コストが高くなる
(2)コードの可読性が悪くなる
というのが、例外機構を多用することのデメリット、ということです。
これは良く使う手ですね。
私が今作っているシステムでは、
設定ファイルが読み込めなかったり、データベースなど外部システムとの接続が確立できなかったりと、
システムとして続行不可能な例外が発生したときは、独自のRuntimeExceptionをthrowするように
プログラムを書いています。
開発規約として、プログラマーにソース中への記述をお願いしたり、
フレームワークにSeasar を使っているので、
Exceptionハンドリング用のInterceptor クラスを用意して対象クラスにAspectしたりして組み込んでいます。
■例外処理を一括して行う
これも、良く使う手ですね。
ExceptionHandlerか。大体みんな同じような名前付けますね(笑)
私は今はStrutsベースのWebアプリ開発がほとんどなので、
すべてのページで共通に使用するActionクラス（ex.BaseAction)にエラーハンドリングを集約させています。
Tomcat(Struts)に対して例外をthrowすると画面にStackTraceが出てしまい、
ユーザ向けサービスとしてはありえない姿になるので、、、、
すべてのExceptionはBaseActionでハンドリングします。
個々の画面単位で制御すべきExeptionについてはBaseActionを継承した各Actionでハンドリングし、
RuntimeException系の例外は、BaseActionに処理を委譲するためにthrowします。
BaseActionに例外が投げられたときは、内容にしたがって振り分けをして、
共通のエラー画面を表示させる、という感じですね。