ハンズ・プロダクツ

昨年夏から年末までの期間に、イントラ環境下でtomcat建ててwebアプリ環境を構築させてもらいましたが、今更ながら良い勉強であり経験になりました。（ありがたヤ・ありがたヤ）

さほど複雑ではない内容でしたが、データテーブルはシンプルでわかりやすくした上で、Ｏ／Ｒマッピングを考慮しながら、どのようなクラスで構成すれば良いのか？・・・。このあたりで良いアイデアがヒラメキ、作り手としての満足感は充分に得られました。そう、動作すれば良いってモノではなく、エレガントなクラス設計とソースコーディングこそ「冥利に尽きる」ってコトです。

まだ、ホットなうちにリリース期間に感じたことを・・・

1. 改めてＩＥがどれほどワガママなブラウザであるかを思い知った
2. URL告知だけではアクセスできない利用者もいる
3. 即時反映・即時解除（apple的処理）は慣れない。（セットして「OK」ボタン押下（microsoft的処理）
4. 運用側に依存する処理には、意外と人間らしいイイカゲンサがあったりする

特にカーソル制御や状況（状態）把握に関して改良・改善を施して、現在のところ問題もなく動作してくれているようです。

今回は、クライアントがイントラ内のwindowsPCと、限定されていたので、デバッグはIE問題がメインでしたが、基本的にスクリーンはワイドであろうが3:4であろうが、おおよそ13inchからいいトコ22inch程度の大きさでした。

で、思うに利用者エントリー側ではスマートフォンやタブレットなど、機動的な端末機であったり、逆にコントロールルームでは大きなスクリーンに多くの情報を表示したり・・・とか、アリですよね。そこで現在はライフワークとしてサクラダ・ファミリア的に構築しているmightyシステムに、流行りのResponsiveDesignの手法を取り入れて、改築してみました。・・・ら、これが効果てきめん。header,nav,footer,aside要素や主となる表示内容の配置を、小型端末表示・通常ディスプレイ・大型ディスプレイの３段階にわけて、レイアウト変更したら、すごい使いやすくなりました。

さらに、コリャ使える・・・と思ったアイデアが、各段階によってリストアップされた項目を制御（増減）するってヤリクチです。つまり人物の検索結果をリスト表示するのに、Sサイズでは名前と読み仮名・性別くらいしか出しません（その分表示行数をかせぎます）。Mサイズではさらに年齢や生存情報が追加され、Lサイズでは、これに誕生日や死亡日が追加される。これって、狭い画面に情報ギッチギチだったり、広い画面にチョビッと表示・・・とかの「何だかなぁ〜」感が、キレーに改善されました。

久々に「オイシイ」手法に夢中になりながら、サクラダ・ファミリアはゴールのない理想に向けて、ゆっくり・コツコツと作られております。ここでのノウハウが依頼されたシゴトに反映されるのですから、ある意味、市販車にフィードバックされるワークスレーシングチームみたいなモノですかね。ダカールも現在進行中ですが、来週からはWRCも始まります。いつかはPOLOに乗りたいですね。

お客さんのXPマシンがHDD障害により起動しなくなり、そのHDD換装でのOS再インストールのドタバタの覚書です。

まずは「効果絶大」を実証できたポイント。

何年か前に、このお客さんはＰＣを買い換えられて、アプリの操作サポートを行った際に、マイドキュメントをD:ドライブに変更しておきました。これは持論であるC:をヤラれて全滅しないように、データは極力D:へ・・・といった発想からです。モチロン素人さんにありがちなC:パンク寸前でD:はカラッポ・・・って状況も想定のウエで。

今回は、CDブートのlinuxで覗いても、HDD抜いて別マシンから覗いても、C：ドラは開けず、D:ドラが「ヒクヒク状態」で見えてる状態でした。モチロン、見えているうちにD:ドラのマイドキュメントやら、メンテナンスさせてもらっているアプリのバックアップディレクトリを退避させることで、D:ドラのデータはすべて戻すことが出来ました。（パチパチパチ）

やはり、別パーテーションのマイドキュメントは「アリなワザ」です。C:ドラが活きていれば、HDD換装なしにC:ドラのみのOS再インストールもアリですからね。

で、苦労した２つのポイント

まず、OS再インストールで、このマシンはレスキュー領域はなく、添付のDVDで再インストールのですが、その最中に「application error 19235」というエラーが出現。ちょいと調べれば、インストールを行うGhostのイメージファイルが壊れている・・・と。で、結局何が悪かったかとイウと、封も開けられていない新品のリカバリーディスクの汚れで、読めない・・・。なので、あらゆるクリーナーを使ってディスクを磨き上げ、別のちゃんとしたマシンでメディアのコピー作りにハゲみ、ダビ重なる読み取りエラーにもメゲズに、「拭いては→読み込み」を繰り返し、ラッキーにも読み取りに成功！。で、このコピー版で再インストールを実現したのであります。ネット調査の際に、「教えてhogehoge」的なサイトには、このメーカー(?)のこのあたりの機種(?)に質問が集中しているので、どうも媒体の品質の問題のようですね。そういえば袋から出すときに粘ってナカナカ出てきませんでした。

次に、OS(XP）がらみのアップデート作業です。これまた「XP アップデートできない」・・・といったトピックスが目白押しでした。で、この水飴のプールで泳ぐような・・・苦しみから抜けられた経験則は・・・In my case ですケド。まず、あの忌々しい「インターネットエクスプローラー」を単独で７から８に上げて、そして[windows update]ではなく[microsoft update](サイトの上の方にリンクあります)を使う・・・って、コレでなんとか苦しみから抜け出せました。

何事も、スムーズに行くとは限りません。心得ておるツモリです。しかし、HDD換装ゴトキで、こんなにハマルとは・・・。ああ、恐ろしやwindows。

これは、トホホなことです。

っま、いつものようにwebアプリの開発環境は、tomcat/spring/hibernate的なモノを使っておりまして、 CRUDに関しては特に、

• hibernateTemplate.save(hoge);
• hibernateTemplate.get(hoge);
• hibernateTemplate.update(hoge);
• hibernateTemplate.delete(hoge);

を、ゴシゴシと書くわけですね。

で、マスタ系のデータ（CSVファイル）をアップロードして、テーブルに更新するのに、最初のハナシの仕様では「総取り替え」だったので、さらに・・・

• hibernateTemplate.deleteAll(hoge);

で、コト足りたのです。ザッと単純なフローは、

1. テーブルのデータ全削除
2. CSVデータをテーブルにinsert

ははは・・・とても簡単！パイロット版を作って「よっしゃ！」っと、順調でした。

しかし、実際に現場でのヒアリングから、この仕様ではイカンことが判明し、行データ（件数）はCSVを使い、サーバーのテーブルに別途独自に保持された項目はイジラナイ・・・との仕様に変更になりました。

っま、思いついたフローの変更は・・・テーブルに変更Flgを追加しておいて、

1. テーブルの全データの変更Flgをfalseに（念のため） ●
2. CSVデータを順に読み込んで、
3. 一致データがあれば、必要項目と変更Flgをtrueに更新
4. 一致データがなければ、必要項目と変更Flgをtrueにしたレコードを追加
5. テーブルの更新Flgがfalseのものを削除 ●
6. テーブルの全データの変更Flgをfalseに ●

っま、こんなもんでしょ。っで、赤丸君 ● の、1,5,6 の箇所で、使ったのが、

• this.getSession().createQuery(deleteやらupdateのSQL文).executeUpdate();

みたいなネ。ちょちょいと動作確認できましたよ。おお、順調・ジュンチョウ・・・・。そして、念のため、連続的にアップロード処理を続けてみると、３回目（特定な処理タイミング）で、処理が帰ってこない・・・ガーン！

ログを見ると、ConnectionManagerがJDBCコネクションを開いたところで止まっている。この先はモチロンテーブルに更新が入るハズなのに・・・。

色々調べたら、Hibernateのキャッシュの問題・同一トランザクション内の実更新の順序の問題、っぽいのが気になったので、

• session.flush();
• session.clear();

やらを、色々入れて見るもダメ。泣きながら

• this.getSession().connection().createStatement().executeUpdate(deleteやらupdateのSQL文);

とかに「どーかヒトツ」っと、変更してみても・・・やはりダメ。

ああ、こりゃエライ壁にブチ当たってしまった！！！！！

でも、私は「カシコイ卑怯者」なので、以下で誤魔化すコトにした。例えば全フラグをfalseは・・・

List<Hoge> hoges  = hibernateTemplate.find(ぜんぶ);
for (int i=0; i<hoges.size(); i++) {
     hoges.get(i).setFlg(false);
     hibernateTemplate.update(hoges..get(i));
}

ざまあ見やがれ、１００回アップロードしても止まらないぜぃ！！！！！

・・・・何十行の処理だからスムけど、これじゃ根本的に解決していない。

ああああ、カユイ。・・・いつかお前を「ヤッツけてやる」。

【だったらイイな】

本番環境で、サーバーやらフレームワークをセットアップしたら、問題なく動作するとか・・・ね。

【ひょっとして】

昨年の春に、解析の相談を受けた某システムが、同じような現象だったなぁ。これだったのカモですね。

【追記】

翌日にフッと気づきました。

• hibernateTemplate.find(flgがfalseを取り出すSQL);

• hibernateTemplate.deleteAll(上で取り出したList);

これでも実装できるじゃん。

あと、気になるのは

• hibernateTemplate.doExecute(hoge);

これをもうチョイ調べれば「解決」があるカモ！