帰りが遅いついにバッティングが明らかになってこちら立てればあちらが立たずで帰りが遅くなる日がこれで2日目。明日を乗り切ればおしまいだと勝手に決めているので、まあ良いか。...}教訓というほどのことでも無いのだが久々にこれで1時間潰した。これがまた、あまりにもどうでも良い処理だったため(デバッグフラグの設定)にJUnitで検証していなかったという罠。デバッグしようという時にこのバグのためにとても困ったのであった今日の教訓の2。bar.close();だったりすると、切り出したメソッドfoofooのbarに対する対称性が著しく欠けることになる。して、B_brotherでは見事にbar.open();を呼び忘れてはまること約10分(汎化作業に時間がかかった分だけすごくうんざり)。#これの教訓は、後付けの汎化だと容易に対称性が悪いテンプレートメソッドが生まれるということ。常に切り出すメソッドはリソースの確保(open、newなど)と解放(closeやdestroyなど)を両方含むか、両方外すかでなければならない。cvarのcをconstantのcだと誤解釈したとは言え(本当はclassのcなわけなのか)、varはvariableのvarだというのは見りゃわかりますな。宣伝るいもさんとのJava本です。SEshop(こっちはちょっぴりだけど内容紹介文もある)。ほう)に分けて、簡単なことから複雑なことまで、いろいろなノウハウやチップス(や必要に応じて原則論も)を詰め込めるだけ詰め込んでみました。原則論もあるが、オルターネイティブについても書いてあったりするので、右も左もわからない初心者用ではありません。初心者が脱初心者を目指して実装設計=実装(を、ついに等号で結んだな)を考えるための良きガイドにはなることは意識しているわけですが、位置的には中級本といった感じかな。この日記の3月から4月あたり(に執筆してた)にメモしたりしているようなことをまとめていたりもするので、大体の雰囲気や考えていることはわかるかも知れません。個人的にはるいもさんのマルチスレッドバナナの叩き売りがお気に入り。Askに繋げているやつが結構気に入ってます(追記:が、まさにこのパートにポカがあって正誤が入ったりしてるのがシオシオなんだな......)。ソフトウェア技術者を考えると言う愚痴から生まれたメモ。若手→プログラム書く。じじい→設計(実装設計ではなくビジネスモデリングやデータフロー設計やコンポーネント配置とか)やる。全体像を掴む練習とか散々にやった後で全体を俯瞰してホットスポットを攻めるとかのほうが順番としては良いのではなかろうか。工程でいくと最初のうちは上流をやって、慣れてきたら下流へ進むというわけだ。軍隊モデルというのがあって、尉官から佐官、元帥と進むに連れて統率する隊の規模がでかくなるとともに、戦術から戦略のほうに進むわけだが(で、そのうち現場を離れてバカをすると)、戦争にうまくやっていたころは元帥自ら船に乗り双眼鏡で眺めながら指揮していたりしたわけでまさに戦術をやっていたのであった(とは言え事例はたった1つに過ぎないのだが)。だいたい自分が何のためにこれやってるんだということが曖昧だと目的を見失いかねないし、目的がわからなければ迷走してもそれほどおかしくはない。目的(戦略)は上流工程で明らかになり、それをドリルダウンして個々のプログラム(戦術)まで落っこちてくる。いうのはわかっているから情報の共有というようなお題目がことさら唱えられるんだろうが、お題目を唱えるよりも、上流の現場に若手を投入することこそ重要なんじゃなかろうか。そんなもんだ勝手に決めてもそうは問屋がおろさずに今帰ってきたという罠。OS-X上流クラスは際立たなくても良いからさっさとStartOnFirstThreadの使い方を教えて欲しい。三段論法Left-Labelから1.人懐こい可愛い犬がいる2.この町の人たちは良い人だ3.許したるソドムやゴモラの人々も犬を飼っていたらどうだっただろうか、とか。XXXXキャッシュのほうを見なければわからないからこれ結構ガックリする。JavaOne雑感(単に感想をだらだらと並べてみる)ここ2〜3週間ほど本業の負荷が高くてあまり物事を見ることができなかったが、久々にいろいろ情報を掻き集めていろいろ想起させてみる。すれば、EJBによる分散オブジェクトから、SOAによる分散サービスどうでも良いが、どっちも「コンポーネント」なんだよね。例によってDCOM→SOAPに対する後追い感をなんとなく感じるが。2.プログラムから記述言語(うまい言い方がわからない)JSF(というかELということになるのか)にしろBPELにしろ、脱プログラム言語(というか脱プログラマーと言うか)。いうのは今まで絶対的には勝利できなかったわけだが。#っていうか、ELがキーワードみたいだから記述言語で良いのかも。#ホワイトホースもからんでくるな。#追記:Groovyもここだな。※1+2=EJB3.0?今後3年で予測されるバジーなビッグウェーブは?ずばり、非同期プロセッシング(のキャッチーな言い換え)でしょう。MSのIndigo、IBMのESB(のどっかにあるサブシステム)。思い出すのはRambus(綴りは例によっていい加減)の圧倒的な先進的なイメージで、システムバス上をメモリーコントローラとメモリーがパケットをバカバカ投げあうやつだ。消えてなくなってしまったわけだが。少なくても見てくれ上は。どっかに生きているとは思うが。コンセプトの先進性に対して、実装コストが追いつかなかったのだろうか。非同期プロセッシングとはなんだろうか?基幹系置き換えにマストな機能だ。(この+は正規表現の+)を並べていくことだ。ファイル→プログラム→ファイル[A-Z]ファイルA→プログラムA→帳票AファイルB→プログラムB→ファイルbファイルC→プログラムC→帳票C...ファイルZ+ファイルb→プログラムZ→帳票Zというようにファイルの入出力でプロセスを繋ぐことだ。ここで帳票の代わりにWebベースのオンデマンド出力に置き換え可能なものはありうるわけだが、日計のようなものは、オンデマンドすることが本当に良いかどうか微妙になる。あと、レポートそのもののイミュータビリティ(なんて言葉はあるのかなぁ)が重要なものでは、印字しなければならなかったり(CD-RへのPDFでのファイル出力とかでも良いかも)。この時、機能を単純にたとえばJ2EEで置換していく場合、既に存在する機能そのものをリストラクチャリングすることは移行負荷が高くなるため、単にテクノロジアーキテクチャのみの置換とすることは十分にありうる(もちろん、クリティカルな領域についてはビジネスアーキテクチャの見直し変更もありうる)。ここでプログラムとプログラムの接続をファイルではなくオブジェクト(あるいはメッセージ)で結合していく(そのほうがアプリケーションアーキテクチャからは設計しやすい)ためには、プログラムZのように待ち合わせを行うプログラムが存在する以上非同期メッセージングが必須となる。極論していくと、各プログラムを意味単位にまとめてサービスとして構成していくことが可能となる。この場合、トリガーとなる行為(JOBの投入に相当)から見た場合、同期プロセッシングされてはむしろ困る。追記:J2EEバッチプロセッシングという方法も選択枝としてはあり得るから、必ずしもメッセージングで繋ぐ必要は無い。配備個所が複数になると運用障害の発生要因となり得ること、POJOをうまく使えばオンデマンド処理と基幹系更新処理でクラスの共用が可能なこと、クライアントが極少数なためDBサーバー=アプリケーションサーバーとすることによるメリットが多いこと(特にハードウェア障害に対し)、メモリーは複数JVMの実行より1JVMおよびDBへのキャッシュに振り向けたほうが有効なこと、モニタリング対象のの集中、オンライン更新(移行する以上これは目玉となり得るわけだから外しようがない)、特に最後の点から、サービスはバッチから切り離してやる必要がある。そのためには非同期プロセッシングがうまくできなければならない。本来は、MDBの役割のはずだが。なんか、EJBでMDBって人気が無いように見える。まともな非同期プロセッシングの本の少なさが1つの証左かも。ハードウェアで起きたことはソフトウェアでも起きうる。その場合未来はどうなんのかなぁ、とか考えながら、おいらは非同期プロセッシングが大好物なんでにやりにやりしてれば良いのだが。ここまでまとまりが無いとメモ未満だな。SOAと考えていけば、(このジャンルに関して言えば)SOAがバズワードなんていうのはとんでもない話だ。30年かけて構築したメインフレーム上の基幹系をオープンシステム(オープンソースじゃない。マクネーリの言葉の意味でのオープンだ)で再構築するためには、必須となる。30年かけて作られたマニエリスティックなゴシック建築をモダーン建築に置き換えることに相当するんだから、一朝一夕にできるわけがない(と思う)。途中で、システムをバラバラに分割して繋げていく必要が出てくる。この再構築自体に5年かかると想定した場合、5年間有効で移行負荷が軽く設計がしやすく設計が単純で負荷予測が簡単で障害対応がそこそこ簡単でマルチベンダーでも問題が起きにくくフロントエンドコントローラの設計実装保守がしやすく誰でもノウハウがそれなりにあり安く買い叩ける......と考えていけばSOA(HTTPベースのメッセージング)の現実性は明らかだ。誰もこの領域にMQ(IBM)やMSMQやRPCやORPCを想定する気にはならないだろう。なんとなくアパートメントモデルという言葉を考えつく。各フロアを繋ぐのは階段とエレベータ、各部屋を繋ぐのは廊下。すべて枯れきってお釣りが来るような技術ですな。ある日、誰も旧館には足を踏み入れていないことに気付く。そこで渡り廊下を叩っ切って旧館を取り壊す。Theory)は遠くになりにけりと思った。反もいるわけで(Googleのトップ。トップにふさわしいかも知れない。概観できかつ主張も明白)、当然のように反あるところに正がある。僕が生まれるちょっと前からある。それも声高にある(あった?)。それが、そんな言い方は無いとか言われるとさすがにビックリしてしまう。追記:「そんなもんだ」というのは便利なもんだ。[どうせだから1冊くらい読んでおこうかなぁ。(ちなみにケージのやつは気に入ってます。題のかっこ良さならジェイルバードかなぁ。ローズウォーターさんを読んでみます。いうのを作ってみたくなる。その一方で車輪を再発明するのはくだりませんな、と思うジャンル(ということなんだろう)もある。そのためにもしかしたら作ったほうが早いかも知れないのに検証したりしてみたり。文句言いながら実戦投入してみたり。スキーマコンパイラとか。ユニットテスト用のツールの類とか。ビルドツールもそうだな(これは早くないのは明らかか)。自分の好みのジャンルまたは自分のジャンルと考えているものについては自分でやってみたくなるようだ(って言うかあたりまえか)。自分でやってしまうところが1.まさにプロ:自分の道具で自分で作る、正しい考え。完全に制御下においてこそ信頼できる。コストを考えているんですか?ふむ。作りたいものを作れないことこそ避けるべきだ。作ることができるなら。