いつもどこかでデスマーチ♪

遅刻しました。 そして、もうやる気なっしーんぐ！！！！ 帰りたいよぉ～～～ どうしてこうなったっ！！！！

さぁ、あと1日でGWに突入ですっ！ 皆さんは、5月2日、6日を休んで、10連休？の人も居るでしょうっ！！！ で、GWって美味しいのですか？皆さん… 私は、2～6日のカレンダーは白いですよ？ 赤い色は何処にも無いのですが…？ 以前書いた、プロジェクトは何とか終わり、本日(明日28日)に納品は 問題なく出来そうです。 がっ！！！！！！ 5月13日納品分のスケジュールがそのまま遅れになってます。 え？なぜって？別のプロジェクトばかり手伝ってたからじゃ無いですか。 5月予定の部下の査定が4月末厳守に急遽変わったからじゃないですか。 …当たり前ですよ♪ 結合テスト仕様書、データ作成丸6日遅れ… どないすんねんｗｗｗｗｗｗｗｗｗｗｗｗ はぁ、GWって食べれるの？美味しいの？ P.S. この時期の「GW」を「ゲートウェイ」って何の日だっけ？ 　　　と思った人…色々と終ってます。(うちの会社にも居ましたが…)

システムは某パッケージのカスタマイズだった。 1回目は3月末納品だった。 あの時も、結合テストがほぼ完了し、残業も月20時間程度と安定したプロジェクトだった。 なのに、納品1週間前に「パッケージのバージョンを変える必要があるっ！」とか言い出しやがった… まぁ、金くれるならやるけど… というわけで、今日(4月19日)が納品日になったのだ… 今回も、単体テスト後にSQLの考慮漏れが発覚したぐらいで、そんなに問題も無く、 今日を迎えたのだが…………………………… 4月19日 午後4時半…納品準備も終って、後は連絡するだけか～と思った所に 1通のメールが… 「パッケージのバージョンが上がりました。 マージをお願いします。」 は？ 見た瞬間、目が点になりました。 今日納品…準備万端…後はメールを書いて送信するのみ… 「あいつら馬鹿じゃないのかっ！？」 と叫んでしまいました。 私はメールは15分受信に設定しているため、見つけた時にはもう担当者と相手で電話中… 要求内容： １．明日(20日)の午前中には納品してくれ ２．これに関するテストはしなくて良い ３．お客への納期は守らねばならん ４．修正は簡単だから大丈夫 とノタマッタラシイ… いや、簡単とか難しいとかそういう話じゃなくて、今日納品日だぞ…？ 修正量、金うんぬんの話ではなく、今日のこの時間でそんな事をしろと…？ お前らの時計はどんな構造してるねんっ！！ 大体、パッケージのバージョンアップなんざ事前に解ってんだろうがっ！！！ 先に教えろよ！！！！！！ とか考えつつ、俺が電話に出てるわけじゃないので文句も言えず… 悶々としてます。(今も) ま、実際修正量は少なく、1時間程度の作業だったのだが、無性に腹が立つ… パッケージのバージョンアップは、不具合とか便利機能だからしょうがない。 でもな… 1日でも半日でも1時間でも良いから先に教えろよ。 てか、その可能性が生まれた時点で教えろよっ！ 今日納品だぞっ！当たり前だろっ！！常識だろっ！！！ これだから某企業はムカつく。 自分らの依頼は通るべきだと思ってやがる。 人の感情を一切考えねぇ。 事前連絡が１本有るか無いかで、相手の感情は天と地ほどの違い...

今日、1つのプロジェクトで問題発生… それはまぁあまり気にせず、対処対処… でも、別プロジェクトで訳の分からん事を言い出した人が… 元々DBに1つのスキーマ(旧スキーマ)があり、その中で処理を行ってたんだけど、 新規機能を追加する事になり、スキーマを2つにして、新しい機能を新スキーマ(新スキーマ)に追加、または旧スキーマから移動する事になった。 そこで、質問してみた。 俺：どのファンクションを移動するの？どのテーブルにシノニム貼るの？ 奴：これとこれと…(2・3個上げてきた)の予定です。 俺：え？このファンクションも移動しないと動かないんじゃない？ だって、こっちのテーブル見ないと…シノニム貼るの？無駄じゃない？ 奴：あ…え…？ん～～～～～～～～～～ 悩みだしてしまった… プロジェクトが始まって1ヶ月も過ぎたというのに… 仕方なく、ファンクションを見て、参照テーブル見て、 EXCELで「使用・未使用ファンクション、移動するしない」表を作った。 表にして1つ1つ確認していけば、おのずと答えが見えてきた… 俺が手を出してからたった4時間… はぁ、この業界4年目(丸3年終了)した人がこんな事も出来ないのか… 納期は5月2週目だぞ… ……………………あれ？…………………… ある意味可愛そうなのか？？？ 上司に恵まれなかったのか… センスが無かったのか… ただ単にやる気が無かったのか…

Oracle10g で、良く解らない動作をしているので、残しておく。 「和暦 → 西暦」の変換するためのファンクションを、下記SQLを元に作成した。 SELECT TO_CHAR( TO_DATE( 'H230505', 'EYYMMDD', 'nls_calendar = ' 'Japanese Imperial''' ), 'YYYYMMDD' ) FROM DUAL もちろん"H230505"の部分は引数だよね。 和暦部分(H230505)が正しい日付の場合は、問題無く変換できるのだが、 この部分が(H230558 や H05234a)等変換できない文字列の場合、例外が発生する。 おぉ、順調じゃんっ！ とか考えてテストを進めて居ると、問題が発生っ！ 例外が発生した後に、 SELECT TO_CHAR(SYSDATE, 'YYYYMMDD') FROM DUAL 数字が変になる… 例：2011年04月12日の場合 TO_CHAR( SYSDATE, 'YYYYMMDD' ) → 00230412 何だこりゃ…？デフォルトは西暦だよな…なぜ？？？ とか思い、良く見てみると、「23」和暦じゃんっ！！！ SYSDATEだけじゃなく、TO_DATEを使うなどしても" 全て和暦表示 "になってしまう。 セッションを閉じるまで永遠と……意味が解らん…… (セッションを切って繋ぎ直すと、デフォルト(西暦)に戻る) これは、SQLを連続実行では発生しない。 あくまでも、西暦変換処理を PL/SQL(ファンクション) 化し、呼び出す事により発生するようだ。 実験結果： 和暦変換('H2305AA') → 和暦表示になる 和暦変換('H2305AA') → 和暦変換('H230505') → 西暦表示になる 1回でも正常形を通せば戻るようだ… すごく謎なので、メモとして残しておく。 ハァ…どうしよう。