• 2020年6月10日水曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/search?updated-max=2020-06-11T07:05:00-07:00&max-results=7&reverse-paginate=true

仮実装

ひとまず、僕の理解で仮実装を進行中。

「仮実装」って何なのかと言うと、例えば、DBのその項目が一意キーかどうか分かんないんだよね。(; ・`д・´)

そういう時は周囲の雰囲気で推し量る。


(´・ω・`)「知らんけど、ネーミングセンスが『管理ID』なんだから、一意キーとして使われるイメージとちゃうんか?」


くらいの僕の感覚でとりあえず進めていく。
これが「仮実装」だ。

その間にマネージャー率いる仕様策定チームで細かいことを調査して貰って、


( ゚Д゚)「いや、管理IDだけでは一意にならん。『ステータスが有効であること』を付け加えて一意になる」


ということが判明したら、その部分を修正する。
仕様策定チームの調査が間に合った範囲で終わらせるのが6月20日という目標である。

だから、修正する時に修正し易いよう実装しなきゃいけないんだよね。
どこを修正することになるかは分からんけど。

分からんけど、機能を部品化するとか、パラメータを外部定義するとか、そういうのを念入れてやっておけば、大体はカバー出来るんとちゃうか?
みたいな。

まあ、嗅覚として、このシステムは「えっ? そんな仕様があるの!?」みたいな部分は少なそうに見えるから、たぶんそれなりに着地可能なんじゃないかって感じ。
そんな感じで進行。

何だかんだでエンジニアにはってものがあって、「見えてないけど、自分達の勘は概ね正しそうだ」みたいな感覚はチームの総意としてあるのよ。

この勘が成り立つのは、結局は小規模だからだな。
僕と若い衆の2人しかプログラマーがおらん。

ITプロジェクトの難易度って、結局は規模で決まっちゃう所があって、小規模だったらこんな進行でも何とかなるのよ。
マネージメントだの開発モデルだの、そういうのは大きいプロジェクトを何とか纏めようと苦心する話であって、小規模プロジェクトは小手先のマネージメントよりもプログラマーゴリ押しの方が圧倒的に強い。

泥仕合に強いヤツが強いのが現実

勘で冒険してバッタバタで解決。
IT業界のインディ=ジョーンズ。(; ・`д・´)
  • 2020年6月9日火曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/search?updated-max=2020-06-11T07:05:00-07:00&max-results=7&reverse-paginate=true

とんでもナス

しかし、聞けば聞くほど、このプロジェクトはとんでもねぇなぁ。

何か、6月20日までに実装を終わらせて欲しいって言われているんだけど、現時点で仕様未確定。
ドキュメントも打ち合わせで使った資料が転がっている程度。
残る期間はあと10日。
無理やろ。(;´・ω・`)

たぶん、締め切りである6月20日の時点でもまだ要件定まってない。

まあ、その辺は皆まで言わずとも汲んでやるのがエンジニアの人情っつーもので、要件も決まって無ければ資料も足らんのは承知の上で、分かる範囲で作っておいてくれ、と。

例えば、「ファイルのFTP送信バッチが必要」というキーワードさえ聞いていれば、


  • その送信先サーバはどこにあるのか?
  • サーバ内のどのパスにファイルを置いて欲しいのか?
  • 送る際のファイルの命名規則は?


みたいなものは分からなくても送信機構自体は作れるし、分からない部分も判明した際に修正し易いように実装しておいて欲しい。

csvファイル処理も、csvファイルフォーマットがどこまで正しいか怪しいんだけど、少なくとも主キーとなる項目だけは分かれば、作れる部分も多いだろう。

そんなくらいの温度感で「6月20日までに実装を終わらせて欲しい」という話だ。

「何を以て完了と定義するのか?」は敢えてハッキリ決めず、マネージャーと僕の阿吽の呼吸を上手く合わせて乗り切っていく、というニュアンスで暗に合意して進行。

とんでもねぇなぁ。(;´・ω・`)

まあ、どこまでとんでもなくても、所詮は小規模プロジェクトだから、凸凹していても最終的には押し込める見通しなんだよね。

やったるっきゃないな。(´・ω・`)
  • 2020年6月8日月曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/search?updated-max=2020-06-11T07:05:00-07:00&max-results=7&reverse-paginate=true

Webデザイナー募集

この現場、Webデザインまで僕の双肩に掛ってきておるぞ。(;´・ω・`)

僕はBootStrapを忠実に使っているだけでしかなく、BootStrapの範囲を超えたものは専門外なのだが。(;´・ω・`)

何とかやってみるが、一般ユーザにウケるかどうかは知らん。(;´・ω・`)
  • 2020年6月7日日曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/search?updated-max=2020-06-11T07:05:00-07:00&max-results=7&reverse-paginate=true

休息徹底

今週は平日が突貫工事、休日も家事で激忙しだったな。(;´・ω・`)

日曜日の今日も午前中は市場に大量買い出しに行ってきたが、午後は余暇と言える時間になった。

さて、余暇の時間を使って仕事を少しでも前倒し……とも思ったが、自分の体調を考えると明らかに疲れていた。
その為、午後は睡眠として、物理的な体力回復に努めた。

お陰で随分楽になった。
平日に高い集中力と反射神経を出せるよう、体調管理も重要な仕事だからな。

本当はイラストの練習もしたかったんだけど、あれも非常に集中力を消費してしまうからな。
プロジェクトの前半のうちに頑張っておけば、後半は時間が余るだろうから、その時間でイラストの練習も出来るだろう。

とにかく、前半である今は電撃戦が第一。
スピーディーに行動することの価値がモノを言うタイミングだ。

とは言え、流石に次の一週間で落ち着くだろう。
どうせ他の人間がボトルネックになるに決まっているんだから。

ボトルネックという名の罪を他人に擦り付ける為にも、今ここで頑張らなアカンのや。
世の中は先行している人間が正義や。(´・ω・`)
  • 2020年6月6日土曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/search?updated-max=2020-06-11T07:05:00-07:00&max-results=7&reverse-paginate=true

総菜製造

明日は業務用スーパーに買い出しに行く予定でのう。
今日のうちに冷蔵庫内に残っている食材を総菜化して綺麗にした方が良いから頑張ったわい。(´・ω・`)

日持ちがするようなメニューにしなければならんな。

  • 2020年6月5日金曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/search?updated-max=2020-06-11T07:05:00-07:00&max-results=7&reverse-paginate=true

ビルドアップ崩し

やれやれ。今週ず~っと突貫工事を頑張ったおかげて、何とかプロジェクトが形になったわい。一段落や。(´・ω・`)

これで若い衆の動員が可能となる。
やっぱりソースの品質って初動で決まるよね。

最初のソースが「サンプル」みたいな状態で若い衆を動員するとグジャグジャになってしまう。
最初にバシッと「これしかない!!」という万全の状態にすれば、後から若い衆が来ても右に倣えで自然と良い感じになってくれるものなのよ。

難しいのは、


  • ソースを共有するべきもの
  • 同じ処理でもコピペで増殖しておいた方が良いもの


と、敢えて崩しを入れる温度感だな。

全域が原理原則主義だと、ソース管理が凄く煩雑になってしまう。
小規模プロジェクトであることを踏まえると、原理原則を少し崩した方が生産性が上がる局面もあるから、そういうのを僕が見極めてデザイン。

実装は美的センスみたいなものも大きいからね。
作り込みが大変だったが、出来上がったこれは中々美しいと思う。

さて、これで一段落着いたし、土日はゆっくりと休みたい……んだけど、雇い主の社長は土日も働いていることが多いからなぁ。
偶にチャット見て新情報があって対応することがあれば土日もやるか。

臨機応変と荒業の極地。(´・ω・`)

まあ、とにかくプロジェクトは立ち上がりが勝負だからな。
もし余裕が生まれるようであれば、プロジェクト終盤に休みを取れるように頑張りたい。(´・ω・`)
  • 2020年6月3日水曜日
ウズマスターの日々
ウズマスターの日々 https://blog.uzumax.org/search?updated-max=2020-06-11T07:05:00-07:00&max-results=7&reverse-paginate=true

突貫工事

プロジェクトソースの土台部分の構築を急いでいる。(;´・ω・`)
どんなプロジェクトでもここだけは完璧を期さないと。

正直、DBに「1」って入って欲しいところに「0」って入っちゃってるとか、そういうのは最後までバタバタしていると思う。(;´^ω^`)

しかし、土台が腐ってるとバグを直すことも碌に出来なくなっちまうからな。


  • API通信する処理はクラスを切り離す、とか。
  • ファイル読み込み処理はクラスを切り離す、とか。


「処理階層」という概念を持ってないヤツが最初に実装を始めてしまうと、


(´・ω・`)「このソースって、ローカルDBとAPI通信先の整合性と取らないと動かせないんですよ」
(´・ω・`)「だからバグを調査するにも、まずAPI通信先をバグが再現する条件を満たして貰った状態にしてからじゃないと、ローカル環境をバグが再現する状態にできない」
(´・ω・`)「1コしか無い検証環境のAPI通信先をバグらせるので、一端みんなに作業を止めて貰うよう時間調整を……」


とか、こんなことになったらマジ何ともならんからな!!
今、僕がやっているのは、そういう切り分けだな。


  • この処理はクラスを別にする。
  • この処理は役割をパッケージに移動。
  • こういう処理はJavaで頑張り、こういう処理はSQLで頑張る。


みたいなデザインを頑張っている。

ここだけは技術力がモノを言うから、何としても今、ここで僕が頑張らねば。
ここさえ乗り切ってしまえば、後は物量戦や人海戦術の世界に倒せる。

頑張り時や。(´・ω・`)