今まで「大なり小なり」システムを構築し、稼働させて頂きましたが、それらは個別に設計・実装されたモノでした。
以前から構想していたシステムのCoreな部分である要素（組織・人物・住所・製品）の土台部分を理想的に充実させ、その上に各個別のカラクリを載せる・・・といった考えを進めるべく、ライフワークとして取り組んでいた「Mighty構想」が、ついに今回リリースした実稼働システムに採用されています。
で、個別部分の初回の機能の動作確認が終わり、ちょこっとした要望もシステムに反映し、では次の機能拡張を・・・と。
・・・・待てよ。次の機能も初回と同様にcsvファイルのアップロード処理が入るなぁ・・・・。初回ではブラウザ外からのドラッグ＆ドロップと、複数ファイルの同時処理を入れなかったケド、テスト時の動作確認では結構面倒だったなぁ。
よし、古いIEでは出来ないが、それは救済機能を入れてコイツらを実装しようじゃないか・・・・と。
クライアントのブラウザ側はjQueryをprototypeと住み分けながらAjaxとして実装。ところがサーバー側のspring君が、ファイル１つでは動作するが複数を放り込むとエラーで動作しない！！！
１日中調査をしたら英語のサイトで、同様のトラブル対処の仕方を解説してくれているっぽい感じである。つたない英語力でヒィーヒィー解読しながらも、昨日はタイムアップ。
で、家で一杯やったり、事務所への自転車往復などで頭を冷やして、本日・冷静に考えて、「これって最近のspringならOKじゃないの？」と、面倒なモノだからあえて目線を変えて、昨日も特に参考にしたサイト（日本語）を、飛ばさないでゆっくりジックリ読んだ。
エラーからもリゾルバが処理できていない感であったのだが、このサイトの説明では、今まで使っていた「org.springframework.web.multipart.commons.CommonsMultipartResolver」ではなく、「org.springframework.web.multipart.support.StandardServletMultipartResolver」ってのを使っていて、コイツで上手く動作するらしい。
で、springを2.5.6から3.2.9に上げて、上記のサイトの丁寧な説明に沿って設定を書き換えたら・・・・「あっさり動作した」。
心にトメよ
使い慣れた環境に甘んじずに、新しいバージョンを積極的に採用しよう！
（ではなぜ最新の４にしないのか？）・・なにやら大幅に変更があったらしく、色々と調整に手間がかかりそうである。ので、そこまでハマリたくない。ヨウは、「このようにシタイ」ことが「技術的にデキレば良いのである」。
とにかく、アキラメなくて良かった。・・・（← 最近のアキラメは方向キーで選択できるサジェスト機能であった。マウス選択での実装で妥協）とほほ。
RAID1のNASを使い始めて５～６年になりますかね。現在２台のNASがシッカリと働いてくれています。で、HDD交換です。雪の騒ぎが落ち着いた月曜日にコンビニに到着済みのHDDを受け取り、チャッチャっと換装し、現在再構築中です。っま、ランプも点滅しますし、ご丁寧にメールでも「１番のHDDヤバイよ」と通知してくれるので、毎回余裕を持っての交換作業です。
もうこの作業は容量アップも含めて３～４回やっているので、何も問題はありませんが、思うに、年に１回位はHDD障害が起こっているってコトで、RAID1導入以前にはいつもデータ保全を気にして、CDやDVDに焼いたり、別のHDDにバックアップしたり、ヒヤヒヤものだったのが、ほんに「アリガタヤ」です。
ちなみにデータを失いカケタ昨年末のお客さんにも導入してもらいました。
あと、amazonの「コンビニ受け取り」も、今回で３回目の利用ですが、今回もドンピシャでした。土日には事務所には居ないし、ましてこんな雪の日に宅配のタイミングがずれて、再配達してもらうには、コッチもソッチも大変な思いですが、コノ受取方法はコッチの都合でナントでもなるし、非常に便利！
さて、恒例の申告の会計処理もヒトマズ終わったことだし、エンジンかけて行きますかぃ？
昨年夏から年末までの期間に、イントラ環境下でtomcat建ててwebアプリ環境を構築させてもらいましたが、今更ながら良い勉強であり経験になりました。（ありがたヤ・ありがたヤ）
さほど複雑ではない内容でしたが、データテーブルはシンプルでわかりやすくした上で、Ｏ／Ｒマッピングを考慮しながら、どのようなクラスで構成すれば良いのか？・・・。このあたりで良いアイデアがヒラメキ、作り手としての満足感は充分に得られました。そう、動作すれば良いってモノではなく、エレガントなクラス設計とソースコーディングこそ「冥利に尽きる」ってコトです。
まだ、ホットなうちにリリース期間に感じたことを・・・
- 改めてＩＥがどれほどワガママなブラウザであるかを思い知った
- URL告知だけではアクセスできない利用者もいる
- 即時反映・即時解除（apple的処理）は慣れない。（セットして「OK」ボタン押下（microsoft的処理）
- 運用側に依存する処理には、意外と人間らしいイイカゲンサがあったりする
特にカーソル制御や状況（状態）把握に関して改良・改善を施して、現在のところ問題もなく動作してくれているようです。
今回は、クライアントがイントラ内のwindowsPCと、限定されていたので、デバッグはIE問題がメインでしたが、基本的にスクリーンはワイドであろうが3:4であろうが、おおよそ13inchからいいトコ22inch程度の大きさでした。
で、思うに利用者エントリー側ではスマートフォンやタブレットなど、機動的な端末機であったり、逆にコントロールルームでは大きなスクリーンに多くの情報を表示したり・・・とか、アリですよね。そこで現在はライフワークとしてサクラダ・ファミリア的に構築しているmightyシステムに、流行りのResponsiveDesignの手法を取り入れて、改築してみました。・・・ら、これが効果てきめん。header,nav,footer,aside要素や主となる表示内容の配置を、小型端末表示・通常ディスプレイ・大型ディスプレイの３段階にわけて、レイアウト変更したら、すごい使いやすくなりました。
さらに、コリャ使える・・・と思ったアイデアが、各段階によってリストアップされた項目を制御（増減）するってヤリクチです。つまり人物の検索結果をリスト表示するのに、Sサイズでは名前と読み仮名・性別くらいしか出しません（その分表示行数をかせぎます）。Mサイズではさらに年齢や生存情報が追加され、Lサイズでは、これに誕生日や死亡日が追加される。これって、狭い画面に情報ギッチギチだったり、広い画面にチョビッと表示・・・とかの「何だかなぁ〜」感が、キレーに改善されました。
久々に「オイシイ」手法に夢中になりながら、サクラダ・ファミリアはゴールのない理想に向けて、ゆっくり・コツコツと作られております。ここでのノウハウが依頼されたシゴトに反映されるのですから、ある意味、市販車にフィードバックされるワークスレーシングチームみたいなモノですかね。ダカールも現在進行中ですが、来週からはWRCも始まります。いつかはPOLOに乗りたいですね。