業務を通しての気づきや学び
DTOにテストは必要？
ロジックを持たないクラスにJUnitのテストケース作ってたけど、必要なのだろうか？
個人的には不要だと思うが、なぜ書くのか理解できなかった。
たぶん、カバレッジを上げたいからだろう。。
AWSのCloudWatch
現場で使えるようになったから使い始めた。
まだ、なれてないけど、過去にログ調査してた経験が活きてきている。
時系列で、操作内容を追う力を若いときに身につけられたのは、大きい。
将来、どんな役に立つのかわからないけど、今の問題に全力で立ち向かって、スキルを磨くのは、重要な要素だと感じた。
ユーザーテストでユーザーが表現と開発者の表現が違う
バグレポートが、うまくできない人が多いって感じる。
ユーザーだから、しょうがないが。
あと、ユーザーの挙動の表現がなかなか独特だなと感じた。
おそらく、基礎知識が開発者と違うせいで、物事の捉え方がユーモアのある表現になるのだろうと感じた。
そこから、事象を特定して、原因を考えるのが、結構難しいと感じている日々を過ごしてる。
イベント処理
フロント側の処理を実装していたが、どこでどういうタイミングでイベント発火するのか完璧に把握できないせいで、修正内容の確認にかなり時間がかかった。
どういう処理にすればいいのか、考えなおすタイミングが必要なんだけど、それが出来てないのが心残り。
今のタイミングだと、対応できる工数が捻出できない。
その他雑記など
PowerMock
ローカルインスタンスの生成の箇所をモック化したかったので、いろいろ調査したが、現在のバージョンでは対応してないようだった。
基本的にmockitoで対応して、設計を見直すって対応が無難らしい。
そこまでインパクトのある修正ではなかったが、実際の業務の場合は、広範囲になる前に設計の指針を出すなど、考える必要があると感じた。
TypescriptにはCharがない
Typescriptで１文字の文字列が欲しかったので、調べても調べても何も出てこなかった。
調査方法を変えて調べたら、Charの概念がないということを知った。。。
全部stringを利用しているらしい。
もっと早く気づけていれば、時間を節約できたのに。。。。
なので、１文字だけの型を指定したい場合は、１文字の型定義を作る必要がある。
久々の神の試練
リモートワークの選択肢が出てきてから、あんまり試練が来なかったけど、久々に現場に行ったときに遭遇してキツかった。
今回は、かなりキツかった。
定期的に襲ってくる苦痛、誰にも伝えられない辛さ。
過去にも経験したはずだが、耐えられるのか、かなり不安だった。
ゴールは分かっているのに、そこまでの道のりが長いことが分かるのが余計につらい。
でも、乗り越えることができた。
こどものころから、神の試練を体験してきた賜物だな。
これがあるから、トイレが確実に確保できてるリモートワークが辞められんのよな。
ちなみに、神の試練とは、便意のことです。
リモートワークの長所を、通勤が楽になるからと言っているやつがいるけど、全然分かってない。
一番重要なのは、家でトイレが確実に確保できていること、待ち行列がほぼ発生しない点にある。
それを理解できない人は、きっと神の試練を受けたことがない人なのだろう。
