SEとして学んだこと -毎日更新-

日々、SEとした学んだことを記録します。

サーブレットTomcatを停止してから実行する

2014年度版 Eclipse + Struts2 による Java Web アプリ開発入門 | CYOKODOG

ここを参考にサーブレットを実行するも、
Eclipseにてポートが使用中です、とのエラーが。

どうも、Tomcatを起動済みだったのに、
サーブレットTomcatを起動しようとした結果、
バッデイングしていた模様。

今の現場では逆にTomcatを起動していないとバッチは動かないので、
ついついやってしまいました。

まだまだ経験不足です。

まずは記録、次に見直し、そして再実行

何度も同じミスをする。
成果が上がらない。
仕事が遅い。

そんなときはまず、自分が30分単位で何をしているのか、記録する、
そして記録を見直して直せるところを探す。
どうしたら改善できるか考える。
思いついたらおもいついたことを羅列する。

そしたら、後はやりたいことから実行するだけ。

はまったら相談、それから紙に書き出す。


更新を怠ってしまいました。
私は仕事が正直早い方ではないです。
というより、局所に拘り過ぎます。

あ、自分はまってるなと思ったら今の方針でいいか、
そこに時間と労力をかけていいか必ず相談しましょう。
そして、いましていることと、まだしていない優先度の高いことを紙に書き出しましょう。

そうすれば後から時間がなくなることは少しずつなくなっていくはず。

とりあえずやってみればいい、無理しない、密度の上げ方、タバコとの付き合い方

中々、作業イメージ、これから何をすればいいかがつかめない時は、
とりあえず作業をやってみる。
そうしたら急にイメージが膨らみます。
30分やってみてそれでも何も思いつかないなら、
同僚か上司に相談すればよいのです。

無理しない

SEは残業が当たり前。
でも、8時から働いているなら20時以降は極めて生産性が低いです。
よっぽど追い込まれていない限り。
それよりも、できれば17時、遅くても19時半までと決めて、
密度を上げて仕事をして。
翌朝、いつもより1時間早く出社するほうがよっぽどいいです。

どうすれば密度が上がるか

最初はとりあえずのファーストアクションでいいけど、
20-30分したらどうやって作業を進めるか、
どうすれば同じ1時間でも正確にさらに量を多く、できればこだわりをもって
仕事をできるか考える。
1-2時間したらフィードバックする。
これ3を繰り返すしかないですね。
基本論ですけど。

SEは喫煙すべき?

煙草は火薬入りの紙巻タバコの巻紙が発する一酸化炭素を除けば、
その有害性は立証されていません。
喫煙室で携帯をいじらず仕事のことを考えてみると、
意外と解決策や新しい切り口がみつかるかも。
ただ、葉巻や煙管は恥ずかしいやかっらやっぱり紙巻か
コストの高いシガリロになってしまいそうですが。

分かるまで聞く、好きなら家でも仕事する。

今日は新人さんの態度にいい意味で驚かされました。
何回も何回も分かるまできいてくるのだ。

私はあまり分かって無くても、とりあえずやってみてうやりながら覚えるタイプなので、
あの姿勢にはびっくりした。
ただ、時間はめっちゃ奪われたけど。

あの姿勢をつつけて、あとはどうすれば理解が早まるか試行錯誤すれば、
私なんてすぐに抜かれるだろうと思いました。

仕事に熱中しているときは家に持ち帰る。

仕事が嫌いな時期は仕事は決めた時間内で終わらせる。
熱中しているときは家に持ち帰って夕食後にやる。
上司に相談すれば一部は持ち帰れたりします。
私は今夜はそれで資料の矛盾点を酒を飲みながらみつけました。

調査資料を納期より早くかつ、こだわりをもって終わらせるには

■調査資料としてすべきこと

・入力データの定義
・出力データの定義
・入力データの編集内容
(度の項目を編集して、出力データとなるか)

■外部設計書、基本設計ですべきこと
・入力データの定義
・出力データの定義
※調査資料がある場合はフォーマット修正だけになる
・お客様向け(業務より)の項目の編集方法の説明
星このとき、エンジニアがみればシステム的にはどう編集すればよいか、
ピンとくるようにすれば尚良い。

■内部設計、詳細設計ですべきこと
・データの編集内容
 システムレベルで記載する。
 これを見ればコーディングを「後はどう書くか」になるレベルまで
 分かるように書く。



私の場合はついつい、内部設計まで意識して詳細に書きすぎてしまう。
詳細設計を行う際はめちゃくちゃ楽になるが、
調査資料の段階で時間がかかってしまって、
プロジェクトの品質が疑われるし、
もし後から何か問題が発覚したときに時間の余裕が無くなる。

だから、調査の段階ではできるだけ時間をかけない方が良い。
だから、調査段階ですべきことは、
「入出力の定義と、項目の編集内容」
に絞る。

例えば、項目の編集が100箇所あったとして、
この100箇所の編集内容を書き上げて、
さらにそれを分かり易く書き換えて、
さらにそれを出力フォーマットに併せて整理したり、
分類ごとに整理したくなる。

この場合、「編集内容を書き上げて、それをSEなら分かるレベルで説明する」
でとめるべきだ。

それを分類したり出力フォーマットに併せるのは詳細設計でも十分間に合う。
そして、こだわりは「如何に短時間で分かりやすい説明にするか」
これができるようになったら調査段階で内部、詳細設計書の下書きまで済ませてしまえばいい。

ソースは三度読もう

長いソースは1回読んで分かった気になっても、
2回目に読めば頭の中でソースが動くぐらい理解できる。
3回読めば、覚える。

今日、VSAM2つとファイル5つからデータを読み込む、
二千行のソースを読んで実感しました。

[COBOL]FDと、データ定義と、COPY句

FD 入力ファイル
データ定義

で、内部のデータ部に入力ファイルの内容が入る。

000260******************************************************************
000270* 入力ファイル
000280******************************************************************
000290 FD IN01-F.
000300 01 IN01-R.
000310    03 NAME               PIC N(10).
000311    03 NAME-YOMI           PIC X(10).
000312    03 CLUB               PIC N(10).
000313    03 TEL                PIC X(12).
000314    03 NENREI              PIC 9(02).
000500    03 KIBOU-BI   OCCURS 3   TIMES.
000501      05 HINICHI            PIC 9(08).
http://homepage2.nifty.com/pu-relaxroom/pro/pro-cob3.htm

この場合、NAMEには、IN01-FのNAMEが代入される。

さらに、

300行以下を、別ファイル”F100”で作成すると、

FD IN01-F
COPY F100

で同じ処理ができる。