タイトル/名前 | 更新者 | 更新日 |
---|---|---|
日記/2010/10/29/デスクトップPCが壊れた・・・ | msakamoto-sf | 2010-10-29 14:12:25 |
日記/2010/10/28/「Unix/Linuxプログラミング理論と実践」読み終わった | msakamoto-sf | 2010-10-29 00:11:09 |
日記/2010/10/23/嘘予告ネタ「できる夫がテスト駆動開発を学ぶようです」 | msakamoto-sf | 2010-10-23 11:53:40 |
Java/サービス化, Daemon化メモ | msakamoto-sf | 2010-10-22 12:10:37 |
日記/2010/10/20/Good-Bye Adobe Reader, Hello Foit Reader!! | msakamoto-sf | 2010-10-20 20:50:23 |
日記/2010/10/17/HttpCoreが便利っちゃー便利。 | msakamoto-sf | 2010-10-18 00:15:38 |
日記/2010/10/17/Mavenが手放せなくなった。 | msakamoto-sf | 2010-10-17 17:02:38 |
日記/2010/10/15/Echoes.Act9 | msakamoto-sf | 2010-10-15 12:17:52 |
日記/2010/10/14/Mockito + PowerMock、かなりオススメ | msakamoto-sf | 2010-10-14 23:37:11 |
日記/2010/10/14/PowerMockでManagementFactory.getPlatformMBeanServer()→敗北 | msakamoto-sf | 2010-10-14 19:51:16 |
2-3ヶ月ほど前から、何の前触れもなく突然勝手に再起動したり、シャットダウンしたのに何故か再起動したりと怪しげな挙動を見せていた、2004年購入のNEC水冷デスクトップPCが、ついに壊れた。
リカバリしても、リカバリ終了後に再起動をかけると一瞬ブルースクリーンが表示されて、すぐに再起動してしまう。
というわけで、これから秋葉原に出かけて新しいデスクトップPCどれにしようか物色してきます。
WinXPへのダウングレード権は・・・確か、新規PCのプレインストールモデルでの入手が、10月22日を境に不可能になってるはず。出荷が止まるという意味で。
いよいよWin7か・・・。あ、自分のVMwareってバージョン5だからWin7使えない。こっちもVMware7に上げないと駄目だった。
2007年7月頃に購入していて、ず~っと本棚に眠っていたのを、ようやく読み終えることが出来ました。
実際に読んだのは、粋がって買ってしまった洋書版の方ですが。
2010.10.28時点では日本語訳の方が安価です。amazonレビューにも特に日本語訳についてのつっこみはないので、素直に日本語訳の方を購入しても問題ないと思います。
では簡単な感想を。
スパゲッティソースコードは、下手なソースコードは、人を間接的に殺すことが出来る。
例え、ミッションクリティカルな分野でなくとも。
カスタム業務アプリのソースコードだろうと、ソーシャルWebサイトのソースコードだろうと。
テストの無いレガシーコード、つまるところモジュール分割が下手くそなソースコード。500行/1000行を越えるメソッド日常的なプロジェクト。マジックナンバーだらけの基本すら守れていないソースコード。
今ここに、大切な人の命をスパゲッティソースコードで奪われたエンジニアが集結し、屑(Junk)プログラマに反旗を翻す。
JavaをWindowsNTサービスとして登録、あるいはUnix系でdaemon化するにはの参考リンク集メモ。
・UNIX系でdaemon化するには?
"-Xrs"オプションも重要。
・実際にNTサービスとして登録 or daemon化するためのツール:
・"graceful" shutdownを実装する為のヒント集:
どういう風に便利なのかというと、外部WebAPIを叩くコードをテストする時、StubとなるWebサーバをわりかし簡単にでっち上げることが出来る。
WebサーバだからといってServletコンテナか、というわけではなく、もうちょい原始的でソケット入出力を薄くラップしてる。
逆に言えば、WebAPIのstubを用意したいが為にわざわざServlet組んだりServletコンテナ動かす為にあれやこれや調整する必要がない。
UnitTest中に使うので頻繁にup-downを繰り返すが、ポートの再利用を有効にする&graceful-shutdownを作り込んでおけばOK。
バイナリアーカイブDLすると付いてくるexampleの、BlockingモードのServerサンプルを適当に弄れば、あとは別のProjectとかでも使い回し出来る。
TomcatやらJettyやらWinstoneやらを上手くJUnitテストケース実行中に何度もup-downさせたりstub用のServletコンテナをどうやってdeployするかなどを調べて調整して検証して実装して流れに乗せるよりかは、大分手間が減ると思われる。
まぁそもそもプロジェクト専用のWebアプリ領域とかが組織内にちゃんと用意されてれば、その上にStub用のアプリをdeployしておけるのだけれど、そこまで大仰なアプリじゃなかったり、そういう環境を用意する予算・時間・人的リソースが無い場合はこれでお茶を濁す手も有りなのではないかと。
久しぶりにJavaの開発にどっぷりつかってるんだけど、ライブラリの依存関係を手動で解決するのが大変で、Mavenにお任せしないとやってられない。
もうAntには戻れないな~。JUnit/Apache/Commons/Loggingとか、jarファイルを自前でDLして揃えるよりはMavenにdependency書いて依存関係更新してくれた方が、漏れてるのとか自動で取ってきてくれるので非常に楽。
Apache MINA を使った"echo"サーバ/クライアントを"Act9"としてcodereposにUPしました。
http://coderepos.org/share/browser/lang/java/echo_samples/act9
Maven化, JUnit+Mockito+PowerMock, graceful shutdown, JMX, NT Serviceへの登録など、開発環境や実行環境周りを整えました。好き勝手コピペしてOKです。
なんだかんだで、「アレが出来ない、コレが大変」と書いてきてしまったけど、static/final/private系絡みを回避していれば、かなり使いやすいのでオススメと言える。
インターフェイスのmockがサクサク作れるので、依存性注入な構造のコードであれば嵌りどころも少ない。
static/final/private系を完全に回避出来ているならMockitoのみで平気。
多少でもこれらがまざってくるなら、PowerMockを組み合わせましょう。
Apache MINAで簡単なEchoサーバのサンプルのテストコードを昨日・今日と書いていたのだけれど、IoHandlerやProtocolDecoder/Encoderなど、インターフェイス(or Adapter)を実装したシンプルなPOJOの部分は、あれほどstaticやMBeanServerで苦労したのが嘘だったかのように「さっくり」と書けてしまった。
"System.exit()をmockする"のと"ManagementFactory.getPlatformMBeanServer()"で嵌った時間を合わせて丁度、IoHandlerやProtocolDecoder/Encoder周りのテストコードに費やした時間とイーブンくらい。
嵌りどころを回避出来ていれば、かなり使いやすい。
近日中に今回でっち上げたEchoサーバのコードをcodereposにUPします。echoes.act9になります。
只のEchoサーバの割には気合い入れてます。まぁその分、元は取れたと思います。Maven/JMX/Mockito系/Commons Daemonなど、一通り体に通しておきたかったテクニックでした。
題名の通り。
PowerMock + Mockito で、
import java.lang.management.ManagementFactory; import javax.management.MBeanServer; import javax.management.ObjectName; ... ObjectName name = ObjectName.getInstance("my.pkg:type=xxyy,name=wwzz"); MBeanServer mbs = ManagementFactory.getPlatformMBeanServer(); mbs.invoke(name, "fooMethod", null, null);
この辺のコードをstubにしようとしたのだけれど、
ManagementFactory.getPlatformMBeanServer()
これをMockできない。
PowerMockito.mockStatic(ManagementFactory.class); MBeanServer mockMbs = Mockito.mock(MBeanServer.class); Mockito.when(ManagementFactory.getPlatformMBeanServer()).thenReturn(mockMbs);
コンパイルは通る。しかし、実行時に以下の例外が発生する。
org.mockito.exceptions.misusing.WrongTypeOfReturnValue: MBeanServer$$EnhancerByMockitoWithCGLIB$$911c39e9 cannot be returned by getPlatformMBeanServer() getPlatformMBeanServer() should return MBeanServer
MBeanServer周りなど独自のClassLoaderを使っているらしい。そのため、コンパイルは通ったとしても実行時にClassLoaderが分断されてしまい、クラス定義が見えなくなったり食い違ってしまうのが原因らしい。
参考:
古い話題ではなく、上記スレッドなど今年(2010)の5月頃。対処された様子も無い。
自分の技術力や、コピペだけでの回避が明らかに無理なので、今回は潔く敗北を認めた。しゃーない、
ManagementFactory.getPlatformBeanServer()を外に出して、MBeanServerをコンストラクタ経由で注入することで対処した。
今日一日で、随分とMockito + PowerMockでの地雷源を走った気がする。
いやね、ホントね、こう地雷ばっか踏んでると、紹介記事とかで「こんなに簡単にMockが作れちゃう!staticメソッドだってほら簡単!」とかね、ウソかと、コードが単純すぎないかと。
JMX周りのコードなんて、ちょっと込み入ったサービスやデーモン的なコード書こうと思えば出てくるのは確実なわけで。
で、ちょろっとそういう「現実の」ライブラリを使っただけでもう手に負えなくなるなんて、地雷原に嵌って何時間も英語含めてドキュメントだのGoogle検索だのして。
こんな面倒くさいのが「TDD」の「現実」だとすりゃ、そりゃ流行らねーわな。