役に立ったらぽちっとよろしく。

今日も相変わらず、Toplinkのバグは手強い…。普通にフィールドにアクセスしただけでInvocationTargetExceptionやらjava.lang.NoSuchMethodErrorが発生した。…で、毎度の事だけどバグ対策のサイトは英語…うーんFetchTypeを統一すると治るとか…。たぶんToplink内部の動的ウィービングが関係しているんだろうけど…そんな事を知らんユーザだとこれは面食らうと思う…。ぶっちゃけ、ホコ天で車にはねられたようなものだ…。で、結果論なんだけど…ここしばらくToplinkと付き合ってきて思ったのは、バイトコード変換はやっぱりバグの温床になってる気がする。

以前Javaのバイトコード変換についての議論があって、で危険だからやめよう→どこがそんなに危険なんだ？→こんな素晴らしい機能なのに→あーだこーだ…っていう議論があった。

おいらが思うにバイトコード変換は何も危険でないし、それが出来るのはJavaの実行環境がうまく出来ててその上きちんと仕様化されてるJavaの長所の証明みたいなもんだと思う。そして、何より応用範囲が広くて素晴らしい技術だと思う。

…けども、やっぱし問題もある。最大の問題は初心者と上級者の隔たりを大きくしてしまう所。実現したい事は動的ウィービングとかそんなシンプルな事なのに、それが可能なのは技術的、時間的に見てフレームワークの開発者だけってのは何かおかしな気がする。で、その上級者にとってもやっぱり茨の道であるのは変わりない。おかげでToplinkはバグだらけなわけで…。同じ事がもしJavaの言語機能としてあれば…きっとここまでバグは出ないはず…。

思うにJavaの言語としての性能の方が、VMの性能に追っつけてないからバイトコード変換って技術が生まれたのだと思う。で、きっと同じ理由でJRubyとかも作られてるのかな…。うーんだとするとJavaの将来は…って将来考えてる場合じゃない。将来より今…どーするよこのToplinkのバグ…全部LAZYか全部EAGERかって、何そのAll or Nothingみたいなの…。

役に立ったらぽちっとよろしく。

続きを読む »

最近とかくモテナイ奴がいる！・・・・・・それオイラ…ふえーん！…あの子が恋しいよー！

…て話じゃなく"プログラミング言語"でモテナイ君がいる。・・・それはJava！おいらが思うに理由は幾つかある。まず、恋敵である軟派ボーイのRubyやイケメン.Netの台頭。特にアイドル？ん？アジャイルだっけか？に夢中の若い娘達はRubyの甘い言葉にいちころのよう…。で、あげく比較されJavaおやじくさい…とか堅苦しい…とか。昔はあんなモテモテだったのに！！これじゃまるで危険な香りのチョイ悪おやじC/C++が捨てられた時と同じ！

ま、でもこれは仕方ない。…世代交代ってやつや。それより今のJavaが肝心なのは、昔のC/C++と同じでそれでも自分を必要としてくれる人達といかに生きてくかって事だろう。…が、しかしJavaは諦めが悪い…Ease of Developmentとかなんとかいいだした。おいらは英語が苦手なので意味がよく分からないが、これはきっと"わしはまだまだ現役じゃーっ！"て意味なんだと思う。

男女を問わず言えるけど、生き様がきちんと示せん人はなかなかモテない。硬派一筋だろうがチャラオだろうが、必ず好いてくれる人はいる。けども、硬派で通してきたのが流行に合わせていきなり「Heyオッパッピー」とかいいだすと、一時は人気が出るかもしれんけど、結局はそれで往年のファンまで去ってしまう。

最近のJavaは、もともとの厳格な構造を後回しにして、Rubyとかの効率の高さに浮気してる気がする。なので、おいら的にはJavaはもっと厳格に型システムを強化するとかしてほしかったなぁ…。ま、そんなおいらも最近はJPAとかアノテーションで楽しようと目論んでるので大きな事は言えませんが…。

役に立ったらぽちっとよろしく。

続きを読む »

以前おいらがいた会社の営業は最強だった…。およそ売れると思えんものを売ってくる。バカバカ売るのでシステム部門はどんどん忙しくなり場当たり的に人員が投入される。で、きちんと勉強する時間が無くなり、よけい技術力が鈍る。ぶっちゃけ売れなければ、まだちゃんと自分達を省みる時間があるんだけど…。つまり、営業が上手すぎるのも会社全体としてみると他の部門を堕落させかねない…。

え…自分が堕落した理由を営業のせいにするなって…？大丈夫！おいらは自分の部がどんなに忙しくても、業務そっちのけで技術を磨くKYだから(爆)。…さてさて、そんなKYなおいらがお送りするブログももうすぐ十回目…今回はそんな腕のいい営業にもまかせちゃいけない、プログラマが顧客にヒアリングすべき事について。(…毎度前フリが長いけど本題はここから。)

残念な事に現在のプログラミング言語や開発手法は完璧じゃない。どこかを柔軟にすれば、どこかが固定化される場合が多い。例えば、サブクラス化一つみても、サブクラスの追加は楽だが、そのインタフェース部分の変更は、サブクラス全体に変更が及びコストが高くつく。これはサブクラス化を伴うデザインパターンにも同じ事が言える。特にパターン化されている場合、どこの変更が楽でどこが難しいかが研究しつくされている。例えばVisitorパターン[Gof]の場合、Visitorの種類はどんどん増やせるが、それをacceptする側の種類を増やすのはコストがかかる。(間違って種類が増える要素をacceptする側に持ってくると、悲劇が待ち構えている。)

つまり、ヒアリング時点で業務モデルのどこが増える可能性があり、どこが固定的かを知る必要がある。もちろん、営業がプログラミングにおけるそうした事情を把握してヒアリングしてくれればいいわけだけど、あまりあてにしてはいけない。なぜなら、ここを間違った時の痛さを一番知っているのは営業でなくプログラマなわけで、営業の人はあまりリアリティを持ってくれていない場合が多い。で結局、組織内でリアルさに差があると後々トラブルになる事が多いので、「なんでこんな時間がかかるんだ」「あんたらがちゃんと聞くべき所を聞かんからよ！」という争いになる。

そんな事にならんためにも、プログラマにとって重要な事はプログラマ自身で！って事ですな。…ん？そうすると話ベタのおいらは…プログラマとして失格ってオチですか…泣笑。

役に立ったらぽちっとよろしく。

O/Rマッピングシリーズ第三回の今日は、前回おいらが閃いた方法を実際に実装して、より深くO/Rマッピングの泥沼へとはまります。…え？シリーズだったのって？…単に泥沼から出れないだけです…爆。

なお今回のパートナーも前回と変わらずToplink。おいらは面倒くさがりなので、Hibernateが少しいい位じゃ、glassfish同梱のToplinkにしがみつく。…そして、はまる度にToplinkどうよ…とぶーたれる。おぃ！無料で使ってるくせに悪質クレーマーかよ！って話は置いといて。(/^_^)/

さて、前回、担当者の本体情報を抜き出してそこに社員とアルバイトからOneToOne関連を張った。実装にあたって社員とアルバイトそれぞれから本体情報にアクセスするのは面倒なので、やっぱり抽象クラスを作った。

…もちろんこの抽象クラスはDBのテーブルと直接関係は無い。なので@Entityは不要。JavaSEではEEと違ってpersistence.xmlにエンティティクラスを書く必要があるけど、それも不要…と思ってJUnit(JavaSE環境)でテストした…いつのまにか起動しなくなってる…。吐いたエラーは

java.lang.LinkageError: loader constraint violation: loader (instance of sun/misc/Launcher$AppClassLoader) previously initiated loading for a different type with name "entity/Albite"

で、よく調べたらtoplinkのバグ。glassfishのサイトで対策があって英語で意味不明なんだけど、persistence.xmlに基底クラスを書き足すと治るとか…そんな事が書いてる…ような…気がする…。嘘ぉ〜ん…と思いつつ半信半疑やってみると…げっ本当だ！実際にうまく動いてびっくり、自分の英語が当ってびっくり！二重にびっくりだよまったく…

役に立ったらぽちっとよろしく。

続きを読む »

O/Rマッピングで表したいモデルがあるのだけども、うまくいくのだろうか…という話。

そのモデルと言うのは、結構ありがちなパターン。まず、テーブルとして顧客、担当者、アルバイト、社員がある。で、クラスの関係は、顧客から担当者がManyToOneで担当者はアルバイトと社員の基底になる。たぶんJPAならInheritanceType.JOINEDを選ぶ事になる。

で、疑問に思うのはアルバイトの人が社員になる場合。Java等ほとんどの言語は、動的継承をサポートしないわけで、アルバイトクラスのインスタンスが直接に社員クラスのインスタンスには変われない。必要ならば、インスタンス自体を作り変えるか、Stateパターン[GoF]を使う必要がある。これはO/RのOの部分の制約になる。

で、アルバイトインスタンスを社員インスタンスに作り変えるために、一旦アルバイトインスタンスを削除しようとする。この時、O/RのRの部分は担当者テーブル内の行まで消してしまうのだろうか？だとすると、担当者テーブルに外部キーを張っている顧客は…。このRの部分の制約でインスタンスを削除する事が出来ない。

仕方ないので、Stateパターン的な方法にしようか思うと担当者クラスにStateとして社員やアルバイトを切り替えられるようなJPAの機能がない…。

で、なんとか考えた解決策…担当者に社員とアルバイトそれぞれへのOneToOneフィールドを持たせて、FetchType.LAZYにしておく。ゲッタで担当者の切替フィールドを見て、どちらからStateを取得するか決める。LAZYが気に入らないなら@PostLoadでその操作をすぐに実行する。取得以外の動作はJPAのカスケードで担当者から各State(社員かアルバイト)へ伝播させれば楽かも。…他も色々考えたけど…どうもうまくいかない…。

ていうか、、、JPAが手強いせいで、全部技術ネタになってしまった…。どこにもオチが無い！
え？技術ブログで毎回オチ入れる必要はないだろうって？…だって関西人だもん。

役に立ったらぽちっとよろしく。

昔、見た映画での台詞にこんなのがあった。悪者のボスが、部下に後何分かかる？と聞いて、10分…と答えたのに対し「５分でできるはずだよ…〜君」と切り返す。かっくよすぎ…。

事プログラミングに関しても、新しいライブラリやらフレームワークの機能を全て調べなくても、過去の経験からこの位は出来るはず…と予測できる事はとても重要だと思う。けどもその予測が外れる時もある。そういう場合、おいらのような自己中野郎は、自分の予測が外れた原因も考えず、その製品に対してブログで文句を書く…なんて嫌な奴なんだ…！

毎度前フリが長いが、ここからが本題。実はOracleのToplink + MySqlで当然できると思っていたら実はできなくてはまった…という話…。Toplinkを始めとするJPA製品には設定した方針(GenerationType)で連番を自動生成してくれる嬉しい機能がある。そしてMySqlにもAUTO_INCREMENTなる機能がある。なのでToplink側からこのAUTO_INCREMENTを使って連番をふる場合、先程のGenerationTypeとしてIDENTITYを指定する。で、おいらは、この連番機能によって生成されたキーを永続化直後のオブジェクトのプロパティから取得しようとした。

…が取得できない…。最初はToplinkのバグだと思った。けどもToplinkのサイトを見ると…

There is a difference between using IDENTITY and other id generation strategies: the identifier will not be accessible until after the insert has occurred–it is the action of inserting that caused the identifier generation. Due to the fact that insertion of entities is most often deferred until the commit time, the identifier would not be available until after the transaction has been committed.

英語が苦手なので正確には分からないけども…たぶんコミットするまでは生成した連番を取得出来ないって事らしい…。SQLの実行をコミットまで遅延させてパフォーマンスをって機能の副作用のようだ…でも、せめて連番を取得しようとしたら、取り合えずINSERTまでは実行するとか…せめてEntityManagerのflushの時点では取得出来るようにするとかできるはずだよOracle君！

特にひっかかるのはIDENTITYの場合だけ！って事！MySqlやMSSqlServer等の他のデータベース製品と違い、OracleはAUTO_INCREMENT的な機能でなく、SEQUENCEなる機能を使ってGenerationTypeもSEQUENCEを使う…。つまり、Oracleのデータベースを使う場合は、IDENTITYは必要ないわけで…多少陰謀めいたものを感じるのは、やはりおいらが性悪だからか…。ま、今度Hibernateの動作を調べてみるとしよう。

役に立ったらぽちっとよろしく。

「私だけかね？まだ勝てると思っているのは。あきらめる？あきらめたらそこで試合終了ですよ？」

スポーツの世界ではまさにその通りなんだろうと思う。プログラミングの世界では、以下のようになる。

「本人だけかね？まだ読めると思っているのは。読めない？読めなくなったらそこで開発終了ですよ？」

今日はそんな事にならないようリファクタリングのコツみたいな話。

自分のコードをしばらくしてから読み返すと、悲劇！さっぱり意味が分からない。しかも、書いた時はう〜ん我ながら上出来と思っていたのに！社内だと、誰か勝手に書き換えたのか!?と疑いバージョン管理システムを見てしまう事すらある(おいらだけ?だとすると性格悪ッ!!)…誰も何もしていない！

あの時は上出来と思ったのに！…でもソースが独りでに汚くなるわけはない。そんな時、頭の中から悪魔の声が「そうだ…最初から汚かったのさ…駄目な奴め…自分の実力を十分認識し今後一切キーボードに触れない事だな…けけけけけ」。

しかし、ここで悪魔の声に負けては真のプログラマにはなれません！耳を澄ましてください！きっと天使の声も聞こえてくるはずです「神はあなたに若かりし頃の過ちを正す機会を与えたのです…さぁ立ち上がってキーボードを」と！そうです！真に戦うべき敵は汚いソースコードではなく、成長をためらう自分自身の心なのです！

……今回もスラムダンクから宗教へと毎度まとまりがありませんが、つまり、まとめると、わざと間をあけて読み返すと返って汚い部分を発見できるよ…って話…だったような………気がする…。

役に立ったらぽちっとよろしく。

直前の記事でDIとSLそれぞれの利点欠点について書いた。…で！！自己流DIな方法を考え付いた。…同じような物を二度作る車輪の再発明、いやいや、私の車輪はちょっと違う！！何しろ天才だから…と空騒ぎし…だいたい数日で同じ物が見つかったり完全な勘違いに気付く…これがおいらの開発…いや人生のお決まりのパターン…笑。今回もなんとなくそんな気はするが取り敢えず天狗になって書いてみる。

• まず、クラス<C>とそのオブジェクトを作るファクトリFactory<C>のペアをコレクションで管理するクラスContainerを作る。
• ファクトリは適宜サブクラス化され、オブジェクト生成メソッドがオーバライドされているものとする。
• Containerは指定されたクラスのオブジェクトを要求されると対応するFactoryを探し出して、引数として自分自身を渡しFactoryのオブジェクト生成メソッドを実行する。
• Factoryは引数として受け取ったContainerから再帰的に必要なクラスのオブジェクトを得ていく。
• そしてそれらのオブジェクトを組み合せて自身の要求されたクラスのオブジェクトを生成する。

問題となるのはFactoryの実装コストだけども、これは予めSetterAutoWireFactoryとかを作っておけば、少なくとも普通のDIと同じ事はできる。加えてオブジェクトを要求された際の動作はSL的に柔軟になる。で、Factory側からその生成したオブジェクトに依存性を注入する方向で処理が進みDIと同じだから、SLの場合に問題となる各クラスが特定のSLに依存する問題もなくなる。

ふ〜ん今の所アイディアだけで組んでない…ていうのも実はDIとかについて散々書いてるけど実はあまりそれ関連のフレームワークを詳しく調べて無かったり…。なので似たようなのがあったりする気もするし…勘違いかもしれないし…しばらく寝かす事にする。なこんなで備忘録でした。

役に立ったらぽちっとよろしく。