ウィリアムのいたずらの、まちあるき、たべあるき

ウィリアムのいたずらが、街歩き、食べ物、音楽等の個人的見解を主に書くブログです(たま~にコンピューター関係も)

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

2005-05-17 17:49:28 | Weblog
 「YAHOO ニュース」で見ました。ここです

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

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



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

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

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

  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

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

2005-05-17 14:40:24 | 開発ネタ
 Excelのテーブル仕様書から、create tableのDDLを自動生成する、Javaのプログラムを、
 この前、このブログで書いたJExcelApiを使って、作りました
(とりあえず、今回はJExcelApiを使いました。POIは、将来、やってみたいと思います)。

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





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


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

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で、おんなじようなことができるか、試してみたいと思います。

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


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする

バッチプログラムのパターン化について、COBOLとJAVAの共通点・相違点

2005-05-17 12:26:59 | 開発ネタ
 パターンのお話をしているブログをみて、ふと思いました。
 プログラムのパターンについて、画面があるものは(表示方法が違うから)もちろんなんだけど、バッチ系でも、COBOLのパターンと、JAVAのパターンって違うよな。。

 と思いつつ、考えてみると、
 COBOLのバッチパターンって、
 そろそろなくなるかも!と思い、

 おおおお、これは、
 COBOL文化財保護協会 会員ナンバー3番(うそ!)の
 ウィリアムのいたずらとしては、書き残しておかねば!
 と思ったので、

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





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


■■ 目的


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

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

 っていうのも。。。

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

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

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

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

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

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


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


■■ 主な流れ


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

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

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

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

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

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




 COBOLとJAVAバッチのパターンの共通点

■■ 実装方法

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

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

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

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

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




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

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

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


  • X
  • Facebookでシェアする
  • はてなブックマークに追加する
  • LINEでシェアする