logbackは今後の選択肢に上がってくるだろうから、日本語情報ありがたいです。

log設計をきちんとやると有効そう。けど、今のところlog設計はかなり適当なケースが多い（レベルですら充分に使えてるんだか）ので、「理想的なのはこれだなぁ」に留まりそうな予感。

で、filterについてだけどlog4jにも一応あるよね。立体的（？）なログ設計をしようとしたら大変だけど。
Log4J徹底解説〜フィルター機能

前に泣く泣くhibernateのdebugログを出さなきゃならんことがあって、けどあまりに膨大だったからこのfilterでホゲホゲしたことがある。非常に微妙な対応で憂鬱だったのは秘密です。

メモ

ひがさんか小林さんがこのエントリに対するエントリを書いてくれることを期待。
そろそろ〜について一言、キボン。

ひっさしぶり。

明日までにやれと言われた作業を片づけるべく。

余所の部署が作ってるシステムの障害対応を短期間でやれってのは大変なことであるよ。

なんとなく。

妖怪アンテナがビシビシ反応してる。学ばないといけないフラグ。

ついでに。会社の中の人より。

ちと古いな、と思ってググったけど最近の動きはわからない。

納得できる流れだけどなぁ、seasar2は保守期でslim3は開発期。

企業で使うことを考えればできるだけプロダクトはできるだけfixさせたほうがいい（バグ修正とかサポートはやる）。
が、一方「もっと便利に」という方向だって残したい。そこで安定しているやつは残しつつ、新しいものを開発。

いちユーザの自分は案件に応じてseasar2とslim3を使いわけるんだろうなぁと想像する。
（seasar使えない案件もあるだろう）

プロダクトが多くて何がなんだかわからないってのは少し同意。
でも、そこは使う人を選んでしまってもいいような。
どうせ開発始まったらそれなりの敷居はあるわけだし、銀の弾丸じゃないしね。

仕事

ここ最近は社内の別プロジェクトのヘルプということで.Netを触ってたりする。
そこのプロジェクトは多分に漏れず悲惨な設計をしていて、.NET嫌いになりそうな今日この頃。

で、そんなのは切ないのでザラザラと.NETの情報を見たりしてる。
Javaと.NETを比較してるサイトとかちらほら見るものの、いまいちわからん。

ちょっとだけ触ってみた感覚だと.NETのほうが簡単なシステムを兵隊使って作るには向いてる様な気がする。
ブラックボックスな部分が多いけど、そこに疑いを持たずに目をつぶれるなら.NETの高機能なところに惹かれるような。

美しく書かれた.NETのWebアプリが見たいなぁ。
どんな感じに設計するんだろう。