お気に入りにしてくださっている皆様へ。メッセージその2。

お気に入りにしてくださっている皆様へ。メッセージその1

会社の歯科検診で虫歯が見つかって早3ヶ月
大して痛くもないので放置しておりました

今日　虫歯君たちの掘削工事が本格化し始めました

すげー痛い・・・歯じゃなくて頭が痛くなるぐらい

明日嫌いな歯医者に行くだけでブルーです
会社で徹夜のほうがまだマシ

唯一の救いは
こういう時になると過剰に反応する嫁が
（風邪でダウンした程度で「死なないで」と泣き出す）
会社の忘年会で実家泊まりだったこと

思う存分痛がってみました

高校生以来の歯医者へ行ってきます

新人君との会話で思ったこと。

PreparedStatementインターフェースは、よくStatementインターフェースと比較され、繰り返し処理に強いと言われる。
PreparedStatementは、そのインスタンスの生成時に、あらかじめデータベースで実行されるべきSQL文が与えられ、渡されたSQL文は、データベースで直接即実行が可能だからというのが理由にある。

ただし、そんなに沢山のSQLを繰り返すWebアプリケーション等あまりない。例えば1回のSQLを発行して、入力データをINSERTする程度のもので、その後のConnectionはclose処理されるのが常でもある。

その時に直接のメリットとして考えうるのは以下の点だと思う。

?オブジェクトの生成コスト
何でもnewすればいいというのが、Java習いたての人の常道だが、newはその分、インスタンス分のメモリ領域を確保し割り当てるという、非常に重い処理をしている事を忘れがちである。

?通信コスト
SQLを発行する際に、DB側に毎回送信する必要がない。APサーバーのキャッシュを使用するためだ。

?解析コスト
プリコンパイルされたSQLを毎回発行するのと、コンパイル後に発行されるのでは、解析が既に行われているという点で大きく異なる。

?はAPサーバのCPU使用率、?はDBサーバのCPU使用率、?は両方を削減することが可能で、結果として性能向上が可能になると推測される。
実際APサーバをnmon analizerでトラッキングした所、一部分の重い処理をPreparedStatementにリファクタリングしただけで、約27％のスループット向上が見られた。

小さな積み重ねは大きな一歩に繋がるのだと学んだ。

敬愛する結城先生が困ったさんにヒントをくれた。

Thread-Specific Strage
http://www.hyuki.com/dp/dpinfo_ThreadSpecificStorage.html

java.lang.ThreadLocalは、現在のスレッドに固有な領域(threadに対してspecificな領域)を確保するクラス。という事は、例えばJ2EEアプリケーションにおいてRequest単位のThreadで、固有オブジェクトを参照しつつ処理が行えるという事。

java.spl.Connection等DataSourceを使うとプーリングされて共用されてしまうようなオブジェクトの場合、これをnewしてオブジェクトをセットすれば、とりあえず競合は避けられそう。

-----------------------------------------------------------
後日談

スーパーロボットKさんにこの話をすると

「それはWebsphere 4.0から実装されているねー」

と言われた。Middlewareの既保有機能を作りこんでしまった俺って・・・。
でも格別問題はないし、WASとアプリケーションに2重フォローなんだから、Over Specっぽいけど問題はないでしょう、等と言われてみたり。Middlewareの知識のなさを痛感（だってマニュアル多すぎなんだもん）。早速Redbookを借りてきて勉強してみた。

日々是進歩の糧

今後は仕事上のメモも載せることにしました。

java.lang.ExceptionInInitializerError
at sun.reflect.NativeConstructorAccessorImpl.newInstance0
(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance
(NativeConstructorAccessorImpl.java:39)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance
(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
（・・・以下省略）

TEST環境のWAS君がエラー吐きまくり。
恐らく何らかの影響で、org.apache.struts.action.ActionServletが正常にロードされてない可能性が大。

-----------------------------------------------------------
後日談

原因は以外に身近なところにありました。

WebSphere Application Server V5.0で外部ライブラリーを使用する際の考慮点
http://www-6.ibm.com/jp/software/websphere/developer/tecflash/10.html

前からチラチラと言われてはいましたが、まさか自分の身に降りかかろうとは…。要はWAS V5.0では、WAS V5.0自身が出力する各種ログのために、commons-loggingインターフェースに対応するTrLogというLoggerを予め保有しているのです。
この為、格段の指定が無いとユーザー・アプリケーションにおいてもTrLogが使用されてしまい、Log4J等のcommons-loggingに対応するLoggerを使用できないというわけです。
これによって、Servletがロードできずエラーを吐いていたのです。WASのLoggerはこんなところにあります。

ws-commons-logging.jar
　＋commons-logging.properties
　　＋com.ibm.ws.commons.logging
　　　＋TrLog.class
　　　　＋TrLogFactory.class

この場合は、[AS_ROOT]/classesか[AS_ROOT]/libを先にクラスロード時に読んでもらわないことにはにっちもさっちもいかない（古い？）ので、とりあえず、APサーバのクラスローダー設定を「PARENT_LAST」(親が最後に指定)し、パスが確実に通っている場所（WEB-INF/classes）で、

org.apache.commons.logging.LogFactory=org.apache.commons.logging.impl.Log4jFactory

ってな感じでプロパティファイルを指定したところ、すんなり動きました。要はLoggerのFactoryをLog4Jのありものに変えてしまったわけです。中身は一緒なんだからOKでしょってわけで。

かなりやられました。

同じプロジェクトで仕事していた外注さんが亡くなった
あまりに突然の事で僕は何も言えなくなった

胃癌の転移で亡くなった事に遺族が初めて気付いたそう

どんなに無理なお願いでも「大丈夫」
夜が遅くてキツイ日々にも「大丈夫」
その一言に安心しきって変化を見逃していた

痛くなかった筈が無い
辛くなかった筈が無い
「大丈夫」だった筈が無い

でも彼はいつも笑顔を絶やさなかった

僕はきっとこの日が来る度に自分を責めるだろう
そしてその度に彼の事を誰かに話すだろう

死んだら自分の事なんか誰も話してくれないから
僕はそうしてあげることしか報いる事が出来ない

ただ1つ彼に言いたかった事は全てが終わったら墓前で言おうと思う

「色々ありがとうございました　またあなたにお会いしたいです」

-05:30
担当アプリがオンライン開始2時間30分前に、上流からのインターフェースが終わらないし、ABENDすると言う事で運用に叩き起こされる。資産の棚卸関係情報が多すぎてB37。データセット2次割り当てが少なすぎた。最低な起こされ方をする。

-08:00
家でABENDフォロー後会社へ。

-10:00
プロジェクトの進捗ミーティング。上海チームは電話で参加。2つのプロジェクト、5つのチームがあるので、そのうち自分が掛け持っている3チーム分の部分のスケジュールと、統合テスト計画について進捗報告。PMが掛け持ち過ぎて、周りが見えなくなっていたがようやく状況を把握し始めた模様。

-10:30
自分担当分のコーディング開始。最大の難所、価格計算ロジックをコーディング。プログラムの神様が降りてこなかった為、20分程度は大苦戦。BigDecimalは面倒だ。

-12:00
いつもの定食屋で昼食。PMや同じ部署の人の会社の愚痴の聞き役

-12:45
お客様とミーティングの為、豊洲へ。前月までは川崎だったので行くのはかなり楽になった。メインフレームチームの外注さんのSE人生について聞く。アセンブラ時代からSEである大先輩。外注さんは軒並み、自分よりスキルもキャリアも年齢も上。いつも自分がリーダーやっていて恐れ多いが、「いやいや、AXISさんが開発も兼ねつつ、キチンと纏めてくれているからですよ」と初めて言われて嬉しかった。

-14:00
豊洲にてミーティング。出荷関係の要件変更と、データ移行・受け入れテストに関するミーティング。相変わらずのらりくらりのお客様に「出来るのか？出来ないのか？」攻撃。ハード関連のホスティング費用に関する宿題を持ち帰る羽目になる。

-17:00
帰社。早速チームメンバーのコーディングをレビュー。オンライン開発は経験少なめ（僕もそうだが）のメンバーの為、かなり細かく見る。やはり例外処理の甘さと、繰り返し処理の無駄が目立つ。細かく指示を出す。

-19:00
価格計算ロジックをコーディング。ここ1日、2日これにやられっぱなし。条件が多すぎるので、喫煙部屋に30分立てこもりロジックを整理する。これが一番いい。

-23:00
上流システムを開発しているU.S.チームとのミーティング。朝早かった上に、深夜に英語での会話は、多少自信があっても本当にきつい。しかし、未だに夜間ジョブ処理のスケジュールとOPCリンクすら決めていない事を聞かされ吼える。他のプロジェクトだと思って聞いていればいい気になりやがって。日本が属国ではないことを思い知らせる。対応窓口のKさんはちょっとひいていた。

-25:00
テスト計画を立てるドキュメント類を作り管理する側の仕事をするのは開発以上に頭を使う。テストケースの多さに少し眩暈を覚える。

-26:30
本日終了。別チームのリーダーと共に夕飯。二駅離れた中華料理屋（朝4：00までやっているのが嬉しい）へ行く。軽くラーメン等を食べる。この頃には疲れ切っているのであまり会話もない。

-27:00
別チームのリーダーを車で送り届け家路へ。

-27:30
家到着。嫁はぐっすり寝ている。軽くシャワーを浴びて、ベッドにもぐりこむ。寝ぼけた嫁が近寄ってきたので、頭を2，3回撫でておく。安心した顔をする嫁。寝ぼけても気遣ってくれている嫁に感謝しつつ眠りに付く。

こんな日々を送っています。

■早朝、前回のコンペで散々だった先輩に叩き起こされ、打ちっぱなしへ。2時間で約480球を打ち込む。この寒さつのり始めた時期に、滴る汗を抑えながら打ってるのは僕等のみ。でも、早起きの運動は気持ちがいい。

■友人の女の子がネイルアーティスト（っていうんですか？資格はあるけど、普通のバイトさんですけど）になったと連絡をもらっていたので、渋谷のショップを訪ねてみた。
「試しにどう？」とボリューム満点やや溢れ気味のまつげで見つめられて言われたので、両方の親指だけ。これぞ初体験。柄を決めろと言われたので「百合の紋章」（何故これを選んだかは前日の日記参照）を選択。
強烈な塗料の匂いにやられつつ、20分程度で完成。これあと6本やって1万4千円だっていうのだから、儲かるなー…。

■家に帰って嫁に見せると、「行ってみたい」と。その後マニキュア落しの匂いにやられる。ネイルアーティストって職業は「匂い」との戦いだと吐きそうになりながら思った。

■MTVを見ていると、去年のEurope Awardの再放送をやっていた。Beyonce強し。どちらかと言うとMary J Blige好きなだけにちょっと残念。Unpragedは平井堅が出演した時の再放送だった。

僕と一緒に仕事している、もしくは接する機会のある後輩の中で、最近結構「困ったさん」に会う事が多くなりました。個人的にこれだけは言いたい事（っていうか実際に言った事）、ちょっとメモしておきます。

?人に聞く前に一度考えてみよう
新入社員の研修に"Don’t give the fish， but tell how to catch the fish. "と言われた事があります。
これ、直訳すると「魚は与えるな、だが釣り方は教えてやれ」となります。要は「（知識を持つものは）答えを与えず、答えへ導いてあげなさい」という事です。

コーディングに答えはありません。但し、辿り着かなければならない答えは、「コーディングしたモジュールが正しく動く事」なのです。そこに到達する道は、自分で切り開くしかないのです。

自分で考える事、調べる事で答えに辿り着く過程は、教えてもらう事より遥かに身になる事が多いのです。まずは自分で考え、考え続け、悩み、ヘコみ、更に考え、そして初めて教えを求めましょう。

これを怠るとバカになります。

?時間・コスト感覚を身に着けよう
兎角忘れがちですが、会社やお客様は寄付で給料や料金を払っている訳ではありません。それ相応の対価を求めて払っているわけです。

ちょっと考えてみてください。

自分が1ヶ月掛かって作ったモジュールを、○○万円（ここには月給/自分のMonthly Charge（月単価）が入ります）で買いたいと思いますか？それは○○万円の価値を本当に認められるものなのですか？努力を買ってくれるような会社等ありません。

これは時間に関しても言える事です。

自分が7.5時間掛かって作ったモジュールは、本当に7.5時間掛かるものなのですか？もっと早くできる可能性があったのではないですか？仮にスケジュール遅れだとしたら、何処かで余分に頑張って、スケジュールを回復するべきじゃないんですか？

時間とお金の概念は学生の時は希薄ですが、すごく重要な事です。会社に居る間は、この2つのコストが常に付いて回る事を考えましょう。

?報告には簡潔さと気遣いを
さっきの話にも関連しますが、あなたが上司や先輩に話している時間は、あなたのコストだけでなく、上司や先輩のコストを割いている事になります。ましてや、上司や先輩はお客様に対するChargeが高い分、あなたの時間より割高です。そして何より、上司や先輩はあなたより多くの業務と責任を持っています。

この時間がもっと短ければお客様やそして上司や先輩の為になる時間が増えるとは考えられませんか？

報告一つとってもその意識は重要です。報告の目的は、問題報告なら「問題の概要」「解決しているか解決していないか」「（解決している場合は）再発防止策の提示」「（解決していない場合は）解決案の提示」で十分でしょう。

「…で？」「…要は？」と聞き返されないようにしましょう。

?メモは取りましょう
人間が集中して会話を記憶できる時間は、どんなに優秀な人でも20秒だと言われています。
上司や先輩のところに行った時色々言われる事でしょう。何が重要なのか優先順位が付かないうちは、メモを取る習慣をつけましょう。
優しい上司や先輩は、そのメモに気づいて、書くスピードで話してくれるかもしれません。書き取る事で自分の中でそれが反復され、正しい記憶になるのです。

…と書きましたが「何を偉そうに」と自分で思ったので、今日はここまで。

同じTeamで、「無停止メンフレ」（IBMのeServer zSeriesとかの無停止機能搭載のメインフレームの事。休みでもオンライン、しかも扱っている全てのミドルウェアに詳しい事から命名）の異名を持つKさんが、帰宅後パッタリと倒れ救急車で運ばれました。風邪＋過労だそうです。

そんなわけで、いよいよ今年も大詰め、プロジェクトも保守も佳境に入って参りました。年度末の決算処理は全世界のエリア上げてのお祭り騒ぎ。そこらかしこで、US相手にスピーカー音量大にして、英語で電話会議している光景で殺気立っております。
プロジェクトと保守が並行している同じ部署の3つのTeamのメンバーは続々とヤラレテオリマス。僕も深夜の喫煙部屋で気を失っておりました。

まだまだよわっちろいな、俺。

そんなわけで気合を入れるべく、先日更に髪を染めてみました。アッシュがかっているので、その辺の職無しのお兄ちゃんよりは真面目に見えますが、会社では十分不良です。周囲からは「グレた」と言われる日々でございます。
そんな感じの毎日ですが、恐ろしくスキルが付いてきた気はするのですね。HOSTとWEBを並行して開発・管理出来るのは暫定的に僕だけなので、ちょっと頑張る気が沸いてきます。

やっぱり小さな成功体験の積み重ねが、大いなる自信になると思うのですね。その為に今は死ぬ程頑張っております。でも救急車はイヤだな…。

纏まりのない文章ですが、今日はここまで！

先日、たまたまShanghaiの外注先のリーダーが来ていて雑談する機会があったのですが、彼が面白い話を紹介してくれました。それは"Bug"の由来でした（知ってる人はごめんなさい）。

"Bug"はプログラムの不具合を指す言葉で、有名なOSでも頻発していますし、システムに関わる方は「それはもういい」的な反応を示されるかと思います（苦笑）
"Bug"は英和辞書を紐解くと「虫」と訳されますが、これ、本当に虫が原因だったのです。

時は1940年代後半、米国ハーバード大学のコンピュータ開発センターでのこと。「MarkII」というリレー計算機（昔のコンピュータですね）の出荷前のテストで、どうも動作テスト結果が思わしくないという事がありました。
開発チームは、仕方なく本体の回路1つ1つをしらみつぶしに検査していきました。すると！何と本物の「蛾」がリレーの間に挟まっていたというのです。
蛾のためにリレーの接触が悪く、誤作動を起こしてしまったのですね。蛾を取り除くと正常に動作したことから、誤動作を起す原因を「バグ」、それを取り除くことを「デバッグ」と呼ぶようになったのです。
現在、誤動作を起こし、後世に「バグ」の名を残すことになった蛾は、保管元の米国海軍海面兵器センターから、スミソニアン博物館に寄贈され保管されているそうです。テスト時の操作を記録したノートにセロテープで貼り付けられている状態で。

ちなみにバグ改修に要した時間は7時間。この話をしてくれたリーダーは「なかなか優秀ですね」と笑って話してくれました。

僕自身2つのプロジェクトのリーダーを掛け持って死んでいるのに、うちのPMはもう1つプロジェクトを掛け持つ事になったようです。今開発しているシステムでインターフェースするある種のデータが、連携先のシステムでも欲しいらしくそれも受け持つ事になったと。外注さん探しと要員計画がまた始まるのかと凹んでいるウチのPMももう30歳（苦笑）

ちょっと忙しい合間を縫って、同じ事業所で仕事していて、アサイン先が変わる同じ会社の仲間の慰労会 in 八丁堀へ。諸事情あって八丁堀。何故か八丁堀。

同じ会社の仲間とはいっても同期は3人程度。あとは去年・今年の入社。若いなーと思ってしまう。合コンとか恋の話とか出来ませんもん、もう。というかその輪に入れませんもん。
「あの子カワイイよね」とか「付き合ってる人どうしたの？」とかの会話を聞いていると、「いいなー」と思ってしまう既婚者。

結婚したらしたで結構幸せなんですよ。でも、そういう話を懐かしいとか思ってしまう自分が、ものすごーく老衰しているような気がしてならなかったわけです。

何か遠くに来てしまったと思うのは僕だけでしょうか？

僕の日記をお気に入りにして頂いている方の中でも、SE・プログラマーと呼ばれる職種の方が多くいらっしゃいます。
その方々の日記でも垣間見えるとおり、システム開発にはその開発工程に応じて様々な方が携わる訳ですが、その役割同士は非常に軋轢が生じやすい構図が存在します。

特に営業・開発・運用という見方でそれを俯瞰するとその軋轢が顕著になります。

営業の意見
「開発のやつらはさー、2言目には『技術的に難しい』だの『工数が膨らむ』だの言いやがるじゃん。もっと大きな目線でお客様の成功を考えて欲しいよな。俺たちが仕事取って来てるんだから仕事できるって事を解ってないよなー。」

開発者の意見
「営業は（お客様に）夢見させすぎだよ。技術も知らないくせに無理いうなって。安定稼動するシステム作る為には、それなりに要件を満たす以上の工数がかかるっていうのに…。『出来るか？』じゃなくて、やれるだけの金を持って来いよな、値引きばっかりしてないでさ。」

運用者の意見
「開発は作りっぱなしでいいけどさ、メンテナンスする身にもなってみろよ。ろくに仕様書も作らないで、挙句にシステムはバグだらけかよ。それを始末するのは誰だと思ってんだよ。24時間稼動？俺らはロボットじゃねえんだよ。」

システムも車と同じようにProduct Lifecycleが存在します。当然その各ステージ毎に担当者が居て責務を全うする事で、システムが初めて安定稼動するのです。逆にこういう状態が起こるのは、
?責務の範囲が明確でない（業務の完了基準が明確でない）
?それぞれの立場での（成功と定義されたマイルストーン到達の）チェックポイントが明確でない
?コミュニケーションが上手く取れていない
という辺りが主要因となっているようです。

システムに携わる会社は大抵この担当者が別の部署に居る事が多く、?は非常に難しい問題といわざるを得ません。しかし、?・?に関して言えば、「共通言語」の確立と、明確な権限責務の定義は急務であるといえるでしょう。

うちの会社はおおむね、その辺に関しては良好な関係を保てる体制と方法論を備えているのですが、やはりこの構図から抜ける事の出来るレベルまでは至っていません。
しかし、それを最小化するべく、外部設計レベルから運用担当者を交えて定期レビューを実施する等、自分のレベルで出来る範囲の事を心がけています。

こんな人も居ますので、アプリ側の人をいぢめないでくださいね（笑）

今日は嫁と車を買いに行きました。我が足としてずっと動いてくれたスターレットも、気付けば100，000Kmまで秒読み段階。しかも車検が11月末。「これを車検に通すのはな…」と悩んでいた所、嫁の鶴の一声が「じゃあ、買ってしまおう！」

元々スターレットの車検が切れる事が解っていたので、車貯金を微妙にしていたのですが、まさかこんなに早々に買うことになるとは。
どんな車にしようか悩んでいたので、噂のカレスト幕張へ。カレストは日産自動車の中古車ショップ。でもその広さが半端じゃない。パーツショップも併設していて恐ろしいぐらいの広さ。

もともとちょっと大きめの車が欲しくて、尚且つカスタムしたいという僕のニーズと嫁のニーズ（乗り出し100万円以内）が合致した車を発見！

「R’nessa」
http://history.nissan.co.jp/RNESSA/N30/0001/

1997年10月〜2001年12月という短い期間しか販売されなかった車の何処がいいかというと、
?日産リバイバルプラン（ゴーン社長の再建計画）の初年度でイキナリ絶版にされた合理性・経済性の無さ（笑）
?無駄に車内がとにかく広い。コンセプトがリムジンだから。
?CVT（無段変速）で、ギアチェンジの「ガクッ」が無く静か。
そして、カスタムどころ満載ときたら言う事はありません。なにより誰も乗っていないというのが、嫁も僕もお気に入りで即購入しました。
こういうのは直感で行ったほうが（最初のインスピレーションに頼って）、いい結果が出るという信条は、嫁も僕も共通しているようです。
嫁は広い車内と広いラゲッジスペースに大満足していました。

車が来るのは今月末、かなり楽しみです。

南国から帰ってきた僕を待っていたのは大量の仕事の山といろいろな問題でした。

?本番環境の不具合
自分が作ったモジュールが不具合を起こしていてその対応に追われました。まさしく自分のまいた種、しょげている暇もありません。どうも入力ファイルデータのバイナリを復元する時のエラーから始まって、DBアクセスのエラーが頻発。半べそかきながら深夜の作業が続きました。

僕は会社では設計者・開発者ですが、プライベートでは使用者になるわけで。ユーザーの気持ちもわからなくは無いですけど、「そんなデータ入れるなよー」と思いたくもなる瞬間ではあります。っていうか、データ移行の要件と実際のデータ違うじゃん！

?プロジェクト難航
後期のプロジェクトの要件の1つが肥大化し、いつの間にか新規アプリケーション開発の流れに…。お客様とのミーティングに出つつ、「要員さんどうしよう？」「コスト計算しなきゃ」と頭はマルチプロセッシング（並列処理）。
しかも、同時並行で設計までやる始末。仕様書のドラフトに埋まっていると、周囲から「大丈夫？」的な声が…。笑顔で答えてはみるものの、要件を纏めて大枠の仕様詳細に落としながら、作業を進めていくと仕様書の数がさりげなく半端じゃない事に。
でも、ちょっと「俺なんでも出来てるみたいジャン」とか深夜の会社で思う辺りが重症です。
でもこのままでは本当にマズイ。というわけで、要員計画を見直す方向で見積もりを持っていくと、プロジェクトマネージャが一言。

PM「○○○○さん（外注さんの会社）のWEB開発要員切ったから」

僕「○＃＄％＆△■＄％＆△」

ええ、声になりませんでしたよ。まあ、この期間までに何人でいくらという契約をしていたのに、要員が確保できなかったという事もあり、契約違反で切られたのはしょうがないですけど…。
一から要員計画建て直しで、かつ僕の設計作業は何時まで続くのかも見通し立たず、目の前が真っ暗になる感覚を覚えました。

幸い僕の所属部署から（泣きついて）人を確保し、部署のリーダーも別の外注先を探してきてくれました。これで一安心…かな？

よく「悪い事は重なる」って言いますけど、本当に重なるものです。来週からもがんばっていきます。