フレームワークの性格

 ここ数か月、筆者はとあるシステムベンダーが構築したWebアプリケーションのフレームワークで作成された既存システムのソースを流用して、新規のWebサービスを作ってました。この既存システムは、新規開発から既に10年近く経過し、その間いろいろと変更・追加があったようです。フレームワーク自体はstruts1+Spring+ibatisという構成の上にさらにベンダー独自の実装で構成されたものです。そのベンダーさんに使用許諾を頂きましたが、特にリファレンスとかは無いのでソースを読みながらフレームワークを理解しながらの開発となりました。
 結果、3か月近く開発し、作ったアプリは現在ビジネス要件を満たし動く状態になってきましたが、こういう経験の無い枠組みの中で作るのは思ったよりも結構時間が掛かってしまうものだなあという印象です。一から作れと言われたらそりゃもっともっと時間が掛かるでしょうが。。
 最初、やはり時間の経過でしょうか、今さらこの構成?という感じでしたが、現在は良くできてるなあという思いもあります。ベンダーが作ったフレームワークって知ってる人からすると、結構時間が掛かる調べものの時間がないので、慣れてる人からすれば、ホントに工数を節減できたり、正確な工数を見積もったりできているんだとは思います。ただ、気持ち的には今さらstruts1系?とかここでの経験は他では使えないなどいろいろな感情が絡んでしまい、また、ソースの切り貼りみたいな作業も多く、モチベーションが低下してしまったのは否定できません。Javaの場合は流行り廃りがあるとはいえ、このようなフレームワークは、利用している方からするとシステム更新しない限りずっと使い続けるしかないのはしょうがない事ですが。
 時間の経過と言えば、最大なのはメインフレーム、いわゆるホストと呼んでいるものも一種のフレームワークと呼んでいいと思います。筆者の場合、最初がオープン系畑だったので、前職の時にホスト(zOS)と関わった時は、最初は違和感ありましたが、しばらくして良くできているなあと感じてきました。主にCobolソースとJCLの整然としたリソース構成は、雑然としたオープン系と比較するときれいに見えてきます。80桁×24行しかない画面もむしろ潔いよいです。。
 とはいえ、ホストのような自由度の無いガチガチなタイプがいいか、ちょっとぐちゃぐちゃ感はあるけど自由度のあるタイプがいいのかというと、もちろん筆者は後者の方が断然好きです。

TeraTermマクロでプロセスをKILL

UNIXサーバ作業の自動化として、特定のプロセスをKILLするマクロを書きました。
前提として
・停止対象のプロセスはJavaの常駐JOBが3つ
・プロセス停止前にチェック処理が必要
このチェック処理が複雑なので、マクロにしました。
下記は、サーバにログオンされた状態以降の抜粋です。チェック処理と最後のログオフは省略してます。
実際のツールはHTAで作業メニュー画面があり、画面操作でマクロを起動する構成にしました。

strdim OUTPUTBUF 500

; KILLする対象のプロセスがPSコマンドで表示される名前
strdim CHK_PROCESS_NAMES 3
CHK_PROCESS_NAMES[0] = 'jp.aaa.bbb.jobA'
CHK_PROCESS_NAMES[1] = 'jp.aaa.bbb.jobB'
CHK_PROCESS_NAMES[2] = 'jp.aaa.bbb.jobC'

; プロセスIDをゲットできたかのフラグ
CHK_PROCESS_RES = 0

timeout = 5

for iii 0 2
   
   CHK_PROCESS_NAME = CHK_PROCESS_NAMES[iii]
   ;; プロセスID取得subコール
   call GET_PROCESSID
   if CHK_PROCESS_RES <> 1 then
      messagebox '停止対象のプロセスが起動していません。'#13'状態を確認してくだい(OKで次プロセスの停止に進みます)' CHK_PROCESS_NAME
   else
      strlen CHK_PROCESS_ID
      if result = 0 then
         messagebox '停止対象のプロセスIDが取得出来ませんでした。'#13'状態を確認してくだい(OKで続行します)' CHK_PROCESS_NAME
      else
         ;; KILL前のチェック処理(省略・・)

         ;; プロセスKILL
         CMD = 'kill -9 '
         strconcat CMD CHK_PROCESS_ID
         sendln CMD
         wait '#' '$'

         ;; プロセスID取得subコール(Killしたのに残っていたら警告)
         call GET_PROCESSID
         if CHK_PROCESS_RES <> 2 then
            messagebox 'プロセスが停止できていません。'#13'状態を確認してくだい(OKで続行します)' CHK_PROCESS_NAME
         endif
      endif
   endif
next

;;マクロ終了
end

;;; sub プロセス状態確認 start
:GET_PROCESSID
CHK_PROCESS_RES = 2
OUTPUTCNT = 0
flushrecv

setsync 1
CMD = 'ps -ef | grep '
strconcat CMD CHK_PROCESS_NAME
sendln CMD

recvln
while result = 1
   recvln
   if result = 0 then
      break
   endif
   OUTPUTBUF[OUTPUTCNT] = inputstr
   OUTPUTCNT = OUTPUTCNT + 1
endwhile
setsync 0

if OUTPUTCNT > 0 then
   ;; Javaプロセスか確認(Grepでない)
   CHKSTR = '/bin/java'
   for i 0 OUTPUTCNT - 1
      strscan OUTPUTBUF[i] CHKSTR
      if result > 0 then
         ;; プロセスIDセット
         strcopy OUTPUTBUF[i] 10 8 CHK_PROCESS_ID
         CHK_PROCESS_RES = 1
         break
      endif
   next
endif

return
;;; sub プロセス状態確認 end

問題は発見するまでの方が時間がかかる

最近あまり読まなくなりましたが、以前はよくソフトウェア関連書を読んでいました。
関連書と言っても、テクニカルなものでなく、トム・デマルコとかワインバーグといった、辛口でウイットに富んだエッセイみたいなタイプの方です。
特にワインバーグの「ライト、ついてますか」がすごく好きです。これはソフトウェア関連書に分類されているので、大きい本屋のコンピューター関連書の陳列棚に置いていたりいなかったりですが、中身はまったくコンピューターと関係なく、サブタイトル「問題発見の人間学」の通り、真の問題を発見する事の重要性について面白い寓話で説明してくれている内容です。どっちかというとビジネス書とか自己啓発本の方に置いておけば、既に30年近く前の本とはいえ、結構売れるんじゃないかなと思うんですが、その手の本と比べるとちょっと値段が高いかな。。
仕事の打合せに出ていて、たまに問題が行ったり来たり跳ねたり飛んだりしてるなと感じる時によく思い出す本です。