IBM、従業員に「慎重な」Blog 活動を呼びかけ

　「YAHOO ニュース」で見ました。ここです。

　IBM の公式 Blog サイトへの書き込みについては、「IBM の事業価値を高める」形での利用を奨励している。

　ほお・・・っていうことは、Blogにバグ情報とか、書いちゃいけないのかな？
　逆に、書いていいのかな？ようわからん。。



各自の良識に照らして配慮するとともに

　ウィリアムのいたずらに、「良識」。。。ない(^^;)

　まあ、ＩＢＭの社員でも、関係者でもないから、どーでもいいんだけどね。。

Excelの仕様書から、create tableを自動生成するJavaプログラム、作っときました

　Excelのテーブル仕様書から、create tableのＤＤＬを自動生成する、Javaのプログラムを、
　この前、このブログで書いたJExcelApiを使って、作りました
（とりあえず、今回はJExcelApiを使いました。POIは、将来、やってみたいと思います）。

　ここに公開してあります。
http://members.ld.infoseek.co.jp/mokano1/index_ExcelJava.htm

---

ちなみに、Excelのテーブル仕様書っていうのは、こんなかんじ。


それを、こんな感じのcreate tableのＤＤＬにします。

CREATE TABLE kaigi ( kaigishitsuID INTEGER NOT NULL , buildID INTEGER , kaisu INTEGER , heyaMeisho VARCHAR(20) , ninzu INTEGER , ookisa INTEGER , PRIMARY KEY(buildID,kaisu,kaigishitsuID) );

---

　こんどは、Excelの仕様書のよこに、テストデータを入れたものから、テストデータを登録するInsert文の自動生成なんかを書いて、
　そのあと、POIで、おんなじようなことができるか、試してみたいと思います。

。。。覚えていたら、気が向いたとき、やります。

バッチプログラムのパターン化について、ＣＯＢＯＬとＪＡＶＡの共通点・相違点

　パターンのお話をしているブログをみて、ふと思いました。
　プログラムのパターンについて、画面があるものは（表示方法が違うから）もちろんなんだけど、バッチ系でも、ＣＯＢＯＬのパターンと、ＪＡＶＡのパターンって違うよな。。

　と思いつつ、考えてみると、
　ＣＯＢＯＬのバッチパターンって、
　そろそろなくなるかも！と思い、

　おおおお、これは、
　ＣＯＢＯＬ文化財保護協会　会員ナンバー３番（うそ！）の
　ウィリアムのいたずらとしては、書き残しておかねば！
　と思ったので、

　独断と偏見による、
　ＪＡＶＡとＣＯＢＯＬのバッチプログラムのパターン、
　共通点と相違点
　を、今日はお送りします。

---

　バッチのパターンの共通点

■■　目的

・開発思想を統一する
　開発思想が異なったものが混在すると、その思想の矛盾によって、障害を招く可能性がある。
　特にアジャイル開発とかで、開発思想が途中で変わると、ひどいことが起こる。

　そうそう、ウィリアムのいたずら、このまえさあ、ＤＢアクセスでね、パターン作ってあるはずなのに、だれかの連絡ミス？かな？？途中から、変わっちゃてさあ、それでありえないひどい目にあったよ(@_@!)

　っていうのも。。。

　って、今日は、体験談を話す日ではなかった。省略します。わき道それてすみませんです。

・品質の担保
　パターンの前処理、主処理、後処理ごとに、決まったログが入ることによって、このパターンを守っていれば、そこを通過したことは、わかるといった感じ。

　品質の保証はテストでやることだけど、保証はしないけど、最低、このことだけは、守られるといったような担保（って、いわなかったっけかな？？）

　ＣＯＢＯＬの場合、printStackTraceという命令が無い。
　そのため、モジュールのなかのスタッカに、そのモジュールを通過した情報をいれ、エラー発生時に、そのスタッカの中身を吐き出させるといった感じで、printStackTraceと同じ効果が出せる。とかね！

・業務内容の位置付け
　どのパターンを使うか、パターンは使えないか、使えない場合、どこをどういう風に修正すれば良いかを考えることにより、その業務は、どのような位置付け（パターンに一致しているか、してないか、してないとき、どれくらい違うか）を明確にすることが出来る。

　これがなされてないと、人によりやり方が違い、本来、やさしい業務が複雑になっていたり、似たような業務が、まったく違う方法でかかれて、品質にばらつきが出る上、保守しにくい。


・プログラムの共通化・再利用
　これもあるけど、共通化するほど、バッチを作らない場合（数本しか作らないとか）、パターンも作らなくていいの？ということになるので、これが目的！とは、一概には言えない。

■■　主な流れ

パターンの主な流れは、以下のとおり

・前処理
共通部分：
　プログラムに入ったことをログに書き出させる
　共通の環境変数などあれば、取得
　入出力のオープン
　　　ＤＢ関係
　　　プリンタ出力関係
　　　ネットワークのコネクションとかもあれば

固有部分：
　引数の取得、チェック、
　そのほか、主処理を行うために必要なもの
　
・主処理
固有部分：
　やりたい処理を書く。
　レコード処理の場合は、ループすることも

・後処理
固有部分：
　主処理の後始末

共通部分：
　入出力のクローズ
　　　ＤＢ関係（ここで、コミットする場合は、コミットも）
　　　プリンタ出力関係
　　　ネットワークのクローズとかもあれば
　プログラムが終わったことをログに書き出させる
　正常ステータスでＥＸＩＴ

・エラー終了（かなないときも）
　プログラムがエラーしたことをログに書き出させる
　入出力の異常終了
　　　トランザクションのロールバックなど
　異常終了ステータスでＥＸＩＴ

---

　ＣＯＢＯＬとＪＡＶＡバッチのパターンの共通点

■■　実装方法

　ＪＡＶＡの場合は、パターンの基本的な部分をクラスにまとめ、
　個別のプログラムで、それを継承して使うこともある

　ＣＯＢＯＬの場合は、パターンをどっかにかいておいてCOPYでおこなったり、
　もともと、何も処理が書いてないパターンソースがあって、修正したり。。。

■■　実際のパターンの種類

　ＪＡＶＡの場合は、バッチパターンなら、
　　・前処理、主処理、後処理の１とおり
　または、
　　・主処理がぐるぐるまわる、
　　・主処理がぐるぐる回って、１回、回るごとにコミットする
　こんなかんじだけど
　（あと、プリンタ出力するときとか、ＤＢアクセス用とか、お好みで）、

　ＣＯＢＯＬの場合、業務処理をさらにパターン化しちゃって、
　　・リスティング用
　　・エディティング（アップデート・更新）用
　　・ソート
　　・マージ
　　・マッチング
　　・チェッキング
　など、いろんな種類のを作ってしまうこともある。
　ＣＯＢＯＬは、こう「しない」と、効率がわるい。
　ＪＡＶＡは、こう「する」と、効率がわるい。
　理由は、気が向いたとき、かきます。

---

　以上、あくまでもウィリアムのいたずらの独断と偏見で考えた、パターン化についてです。

　独断と偏見なので、外れてる部分とか、あるかとは、思いますが、大目にみてやってください。
　実は、なぜ、パターン化の話をしたかというと、他にも目的があるのですが、それは、機会があって、そのとき、覚えていたら、また書きます。

　ってことで、今日の「パターン化のお話」は、ここまで。