The Way to Nowhere

あるITエンジニアの雑文。

2011年08月

「スカイギター予約受付中」

Fair Warning つながりで見てたら、こんなものが。

「ウリジョンロート限定モデル SKY Guitar 先行予約受付中」。



6弦モデルが1,134千円、7弦モデルが1,230千円。

高ぇ、、、

これって限定50台で1年くらい前から受付始まったっぽいけど、今でも受付しているんだな。
という事はさすがにこの値段でそんなには売れてないって事なのか?

まあ、そもそもすごく高音まで出せるって以外の特徴とか全く把握してなくて、どこに拘りがあるのかとかさっぱりわかっていません。
そんな感じなので、私ごときには使いこなせないでしょうから、あんまり欲しくはないかな。

ゼロが一つ少なければね。ま、それじゃ並のギターと同じになってしまいますが。

それより普通にVとかの方が欲しいかも。

Burning Heart - Fair Warning Live

ヘルゲ・エンゲルケとトミー・ハートの見た目の劣化に唖然としてしまった。。。
10年くらいしか経ってないのにな。まあトミーの方は「劣化」とはちょっと違うか。

でも演奏はいいですね、アンディのソロもヘルゲがかなり忠実に弾いてる。

Fair Warning - Live in Tokio - 2010 - 10 - Burning Heart - YouTube



ちなみに全盛期はこんなだった。
まあ、当時で既にトミー・ハート以外は結構な歳だった気もしますが。

Fair Warning - Burning Heart - YouTube


懐かしいが、ソロのフレーズとか結構指が覚えてたりする。

しかし、大量にアップされている2010年のライブ映像はやっぱりこれなんだろうか?

Talking Ain't Enough ~ Fair Warning Live In Tokyo [DVD]


Oracle E-Business Suite の技術情報

正確にいつからかは知りませんで、この2~3ヶ月の間にという所だと思いますが、Oracle E-Business Suiteのマニュアル等のドキュメントが日本語版も含めて、OTNでサインインなしで参照できるようになっていますね。

Oracle Applications Releases 11i and 12


全部が日本語化されたわけでは全然ないので、数は少ないですが。

英語版はかなり前からUSのサイトで誰でもアクセスできる状態になっていたのは知ってましたが、ついに日本語マニュアルも公開するようになったか~とちょっと感慨深かった。以前は日本語翻訳版はOiSCにログインしないと参照できなかったので、OiSCのサイトが閉鎖されたのと関係があるのかもしれませんね。

でまあ、本題としては日本語マニュアル自体はどうでもよくて、英語マニュアルまで含めたら、Oracle EBSの技術情報もそれなりに公開されてはいるんだよな~とは思いつつ、この辺の技術情報は日本語blogでは書いてる人ってほとんどいないよね、と思うわけですね。

OracleでもDBA関係はそれなりに層も厚くて、非公式なサイトでのTIPSもそれなりにあるんだけど、EBS絡みだとググってもたいていの日本語記事はオラクルのマーケティング系の記事で、それらが過ぎると英語記事になっていく感じだったりするわけなんで。

なので、公開されているマニュアルに載ってるレベルの技術情報を自分の経験を踏まえて纏めたらそれなりに見る人いるんじゃないかな、とか思ったりするわけです。
もちろん案件特定できないように一般化する必要があったりで、それなりに面倒ではあるとは思うが、まあそれは他の技術系のネタでも同じことだよね。

勝手な推測ですが、そういう事が書けるレベルの人というのは、実プロジェクト等が忙しくてblogに纏めている暇なんてないか、blogでまでそんな事に関わりたくないかのどちらかなんだろうね。だからそういう技術情報の記事は増えないのではないかと。

また、実際にPJ現場のトラブル解決するには、ネットをググっているよりはサポートサイトMy Oracle Supportのナレッジ検索するのが一番でしょう。バグとかパッチの情報はそこでしか得られないと思いますので。

そうは言っても、実際Oracleはかなりいろんなマニュアル類は公開するようになってきているので、
それらの情報だけでも結構イケますよって所を示せると面白いと思うんですけどね。

まあよく考えると実際の所は「マニュアルに書いてあるレベル」に抑えるのが結構難しいのかもとか想像したりもしますね。下手にSQLとか書くと内部構造の解釈を晒す事になるのでそれはそれで「マニュアルに書いてあるレベル」を超えててまずいかな、とか思ったり。

ともかく、本格的なまとめは当然無理なんで、気になる事があって気が向いた時には、という感じでしょうかね。

User-Defined Exception - PL/SQL

PL/SQLで書かれたプログラムがエラーでコケた場合などで、 時々ログとかにこんな風に出力されているのを見ることがあります。
User-Defined Exception
こういうのを見るととても残念な気持ちになりますね。
いや、たぶんコーディングした人は「例外処理はとりあえずOTHERSでSQLERRM出力しとけばいっか」とか いう感じで、
EXCEPTION
  WHEN OTHERS THEN
    dbms_output.put_line(SQLERRM);
END;
とか書いて満足しているんでしょうか。

 でもこれって要はこういう感じで、自分で例外定義して、自分の書いたビジネスロジックで例外発生させているのに、その例外を明示的に拾う事なくOTHERS で処理してしまっているということなんですね。
DECLARE
  user_expt exception;
BEGIN
  /* ... */
  IF ... != 0 THEN
    RAISE user_expt;  /*<- raise the exception you defined in your business procedure. */
  END IF;
  /* ... */
EXCEPTION
  /* not defined exception block for your own exceptions  */
  WHEN OTHERS THEN
    dbms_output.put_line(SQLERRM);
END;
/
自分のロジックで発生させているわけなんで、SQLERRMとか出力してみた所で、"User-Defined Exception"くらいの事しか出せないのは、普通に考えれば理解できると思います。

自分のビジネスロジックで発生させる例外はちゃんと明示的に拾って、メッセージも然るべきものを出力するのが最低限の礼儀作法ではないでしょうか。

DECLARE
  l_msg VARCHAR2(240);
  user_expt exception;
BEGIN
  /* ... */
 
  IF ... != 0 THEN
    l_msg := 'your own message for your procedure.';
    RAISE user_expt;  /*<- raise the exception you defined in your business procedure. */
  END IF;
  /* ... */
EXCEPTION
  WHEN user_expt THEN
    dbms_output.put_line( l_msg);
  WHEN OTHERS THEN
    dbms_output.put_line(dbms_utility.format_error_stack);
    dbms_output.put_line(dbms_utility.format_error_backtrace);
END;
/
ビジネスロジックで起きうるケース分例外定義するのは面倒な場合もあると思いますが、そういう場合は例の通りのユーザ定義例外を一つだけ定義して、RAISE する直前に出力させるメッセージを処理しておくのが良いと思います。ログ等にメッセージを出力したりする処理はどれもほとんど同じになるでしょうから、ユーザ定義例外をたくさん定義してそれごとに同じような処理を書くのはやってられなくなるでしょう。

"rase_application_error"を使うでもいいかもしれませんが、その辺はもっとファンクションを共通化したりとか、もう少し複雑な事が必要になった時に考えればよい所かな、と個人的には思います。

OTHERS例外は大部分は想定外なものでOracleが勝手に発生させてくる例外を処理するのに使う。
便宜的に SQLERRM を出力しておく、とかでもいいんですけど、最近のバージョンだったら DBMS_UTILITY の FORMAT_ERROR_STACK とか FORMAT_ERROR_BACKTRACE とかを使えば、どのプロシージャの何行目でエラーが発生したかまでわかるので、こっちの方がよいでしょう、きっと。

さらに、ループ回して何かしているのであれば、ループ中のどのデータでエラーが起きたかがわかるようにキー項目をどこかに保持しておいて、エラー処理の中で一緒に出力してあげれば、まあOHTERS例外の処理としては大体OKなんではないでしょうか。

あと、もう少し複雑なプログラム構造になった時の話として、本当に想定外なんで処理終了してしまえばいいという意味でのOTHERS例外はコールスタックの最上位で定義しておけばよくて、サブプロシージャやサブファンクションごとに OTHERS例外記述してリターンとかOUTでエラー返して、コール元がエラーかどうか判定してユーザ定義例外起こしてエラー終了みたいなまどろっこしい事はやめましょう。また、OTHERS で拾っておいて何もせずに"RAISE;" とかいうのは最悪なのでやめて欲しい。FORMAT_ERROR_BACKTRACE とかでエラーの発生位置が正確にわからなくなったりする事があると思います。

参考まで。


大企業で働くのがどーとか

あんまり元記事と関係ないかもしれないけど、仕事上でいわゆる大企業の方々と関わることはよくあって、ちょうどこの記事が出る少し前くらいから、もやもやと思い始めたことがあったんで書いておこうかなと思いました。

まあ、今の若者がどうすべきかとか別にどーでもいいんですけどね。
自分が何をやりたいのか自分でよく考えて決めればいいと思いますけど。

将来有望な若者の将来価値を毀損する、大きなワナ - Chikirinの日記
というわけで今日のお話は、「やった!頑張った甲斐があって、就活もうまく乗り切れた!」とか、「まあ、オレのスペックならちゃんと大企業&大組織に入れ るのも当然だけどね。」とか言ってる人は、実は「完全に周回遅れです」みたいな場所で人生最初の「働く訓練」を受けることがどれだけ自分の将来価値を毀損 する可能性があるか、よーく考えてみたほうがいいんじゃないか、ってことなのでした。
大企業で働くと毀損されるいくつかのコトについて - GoTheDistance

このように、大企業という所は人が立ち替わり入れ替わりしてもいいように、もっと言えば誰が辞めてもいいように作られたレールの上にお仕事の流れが 存在しますので、そのレールに5年も疑問を覚えず乗りっぱなしでいると世間知らずのおバカさんになってしまい、高確率で自分の頭で仕事を作り出せない市場 価値ゼロの人間になるかもしれないよって、指摘する必要もないのにわざわざちきりんさんは指摘していらっしゃるのです。上から目線とDISってる程度の方 にはわからない、ありがたい人生の先輩ですね。

もちろん大企業でしかできない仕事というのも存在しますし、市場価値の高い仕事は大企業に多く転がっているの事実です。ただ、大企業にあぐらを掻いてはダメだってこと。この10年で、どんだけの日本の大企業がくたばりましたか?



いわゆる大企業の人って、物事を理解するのが早く、どんな仕事でもそれなりに平均点以上にこなせる、みたいな所があって、なんだかんだ言ってもベースの能力は優れているというか、ベタな表現で言えば「アタマいい」人が多いな、というのは以前から思っていました。一見するとオチャラケた感じの人でも押さえるべきところはちゃんと押さえるというかね。

で、私の場合、いわゆる大企業の中でもやはり情報システムとか経理とかの人達と接することが仕事柄どうしても多くなるわけです。皆さん能力もそれなりに高く、接すれば人間的には「いい人」が多いと思いますが、新卒から生え抜きでずっとこういうバックオフィスな仕事をしているとか聞くと、こういう人は何を思って今のポジションにいるのかな?と不思議になる事はよくあります。
ITとか経理とかやりたくてその会社に入ったわけではないのだろうになあ、もっとその会社の「本業」に関わる部分に注目して選んだはずだろうに、とか。そうするといまだにその会社でその仕事をやり続けている理由ってなんだろう、とか勝手に思って切なくなったりするわけです。

まあアサインされて関わってからそういう仕事の意義とかもわかって続けているっていうのもわからなくはないですけどね。実際、きちんと本業の部分をよりよくする為にバックオフィスの部門として何ができるかをちゃんと考えて動いている人もいますからね。
特に私みたいなIT系の出入り業者が関わる時は、だいたいシステム再構築とかしている場合が多いわけで、そういう風に新しい仕事の仕組みとかルールを作るところに関われるのは大企業ならではなのかもしれません。

ちなみに元記事はそーとーな大企業を想定しているみたいではありますが、たとえ名もなき会社であっても100人超えてきたら、程度の差はいろいろあってもセクショナリズムとか勘違いした人が出てきたりして、注意してないとダメなんじゃないかねというのが、実感としてはあります。


記事検索
livedoor プロフィール
Twitter
AdSense
Amazon


  • ライブドアブログ