エンターテイメント!!

遊戯王好きのJavaエンジニアのブログ。バーニングソウルを会得する特訓中。

JJUG CCC 2020 Fall 参加報告

各種リンク

doorkeeper

【オンライン】 JJUG CCC 2020 Fall - 日本Javaユーザーグループ/Japan Java User Group | Doorkeeper

感想・まとメモ

jq を使いこなして、開発効率アップ

まとメモ

  • フロントとバックエンド推移

    • 前まで→サーバーで動的にHTML作成
    • 今→UIとサーバー処理で役割分担。両者の更新サイクルが違う
      1. データの受け渡しにJsonが普及
      2. jsonを読むツールが必要になった
  • jqのメリット

感想

  • 動画は、すでに撮影済みのやつを流してる?
  • 途中から、ゆっくり実況みたいな感じのやつが流れてたな。。。
  • データのアクセスは、javascriptチックでできる
    • jqが描かれてる言語は、javascriptなのかな?
  • フィルター周りから、ややこしくい。。。
    • 実際に使わないと、所見で理解は難しい。
    • あとで、調査
  • コメントがつけられる活用事例は、ちょっと厳しいな。。。
  • jsonの編集やスクリプトによる生成は、jqに慣れてからじゃないと難しそうな気がする。
  • 見るツールとして利用することしか頭になかったが、シェルで編集に使ったりもできるのが、新しい発見だった。

雑記

たまに、jsonビュアーとして使っていたけど、深い階層を読むためのツールが、まだ見つけられてない。
階層が分からなくなることが多い。vscodeで見てたりしてたけど、キツかった。jq使っても解決はしてない。使い方の問題かも知れないが。。。
jsonの深い層でも、迷わずに見れるやつはないだろうか?
音認結果や字句解析結果がjsonで帰ってくるのだが、似たような結果がいくつもあるので、階層を見間違えると、間違った方向でプログラミングしちゃって、手戻りあったりするのが辛かった。

結果整合性ができない開発者のドメインイベント活用例

感想

ドメイン駆動の話は、小難しい感じがどうしてもしてしまう。
個人的な理解としては、コードにストーリーをもたせる認識でいる。
やることに視点を置くのではなく、話の流れができるようにコーディングするのが、ドメイン駆動だと思ってる。
イベントは、タラレバのケースを書くだけの認識。

途中離脱

パフォーマンスのトラブルシュート入門

途中参加

まとメモ

  • 計測結果の分析
    • 結果の可視化
    • 正常と異常時の比較
    • 情報が足りなかったら、再計測

感想

再計測の判断が難しい気がする。
情報が足りないかどうかは、自分では判断できなかった。
パフォーマンス分析は、何回かしたことがあるが、可視化が面倒なイメージ。
だから、そういう可視化のツールが流行ってるんだと思う。

分析方法は、ログを正規表現で集計してやるってのが、今も変わらず主流か。
進化したのは、集計したものの表現方法かな?
どうやって見せて分析を楽にするかが焦点になるのだろうな。

分析するために、統計の知識とかあったほうが良いのだろうか?

Project Reactor でノン・ブロッキング、非同期処理を実装してみよう !!

まとメモ

  • mono→リソース1つに対して使う
  • flux→複数リソースを扱う場合に使う

感想

Mono?Flux?聞いたことあるけど、よくわかってない。

Reactive Streamsは実装じゃなくて仕様ね。

publisherは、デザインパターンのobserverみたいなやつだっけ?
前にreactiveについて調査したとき、そんな感じがした。
reactiveは、処理の方式を語ってるものが多い気がする。
最初、実装のことだと思っていたが、概念の話って理解するのに、時間がかかった記憶がある。

やってることは、効率的にリソース使いましょうねって感じかな?
ノンブロッキング処理は、リソースの専有期間を極力少なくしましょうって理解でいる。
クラウドでリソース共有することが多くなったから、こういうのが出てきたと思う。

pub/subは、pythonとかJSとかで、よく見かけるワードだね。

Java開発で感じたコードレビューと単体テストの体験談

ツール紹介はスルー

メンバー編の感想

実装者一人の時点で危険な香りが。。。
あぁ、数字だけみて、現状が理解できてないパターンだな。
人月は、増員したら解決というわけではない。増員したときのコストを度外視するのは、炎上でよくあるパターンだと思う。
増員した全員が、同じスキルで同じ知識だったら、通用するかも知れないが、無理だろ。。。
遅延が発生したときの責任が、どこに行くんだろうな。。。
こういう場合、だいたい現場の人が過剰に責任感じると思うんだよね。。。

これは、ビッグバンテストになる流れだな。。。

最終的に、訴訟問題になってそう。。。

リーダー編の感想

これは、メンバーのときで感じたことを、リーダーでもやりそうだな。。。

嫌われる勇気が足りなかったわけか。。。
断る勇気は、この業界では重要。

規約は、リーダーが作らないとダメなのでは?
レビューする人が作らないと厳しい気がする。
やっぱり、規約作った人がレビューするよね。

レビュー軽減は、findbugscheckstyle使うことが多い気がする。
マクロで対応は、そうとう正規表現に詳しくないとできない気がする。

自分は、メソッド名を付ける場合、codicを参考にすることが多い。
自分がいいと思うものより、一般的な命名を優先する。
最優先は、プロジェクトの語録だけど、それ以外ならcodic。
codicになければ、自分の経験則を信じるようにしている。
今の現場、外部とネットワークがつながらないから調べられないのがキツイんだよね。。。
ここでは、その話が出てこないな。。。
さすがに、ネット使って調査できる環境か?

フォーマットにこだわるのは、自動生成が目的だと思うけど、フォーマットを守ることが目的化していることがたまにある。
一番きついのは、フォーマットすらない記述箇所。
緩いくせに、レビューでフォーマットのことを指摘しだしてくる現場だったら、最悪だと思う。

規約は、なるべく無くしたほうがいい。
できれば、規約外になる実装は動かないようなFWならなお良い。
規約違反は、気づくタイミングをなるべく早くする処置が必要だと思う。

問題の先送りしないには、共感する。
プラスで、問題を早期発見する仕組みが必要だと思う。
問題に気づいた頃には、対処方法が限定されてることが多々あると思うんだよね。
時間の余裕があるときに気づける工夫が必要だと思う。

Head toward Java 15 and Java 16

まとメモ

  • Incubator→試験モジュール
  • Preview→試験機能
  • Standard→標準機能

Incubatorは、知らんかった。
だいたい、見るのは、PreviewかStandard

Java15

自分が調べた結果のリンク張っておく

suzaku-tec.hatenadiary.jp

JEP375

バインディングしてる値は、書き換え不可か。
調査したときは、概要把握だけだったから、そこまで見てなかったな。。。
よくよく考えたら、書き換えできたら不味いよね。

過去の調査リンクを張っておく

suzaku-tec.hatenadiary.jp

JEP384

DTOとかに利用するのが多いかもね。 Reflectionでも変更不可か。。。
jUnitとかで自動テストする際は、作りを工夫しないと苦労しそうな気がする。

JEP360

なるほどね、網羅性の確認がコンパイル時点でわかるわけか。
実装のメリットばかり気にしていたから、気づけなかったわ。。。

Java16

JEP381

ベクトル演算向けっぽいから、内容はよく分からなかったな。。。
科学計算とかで使うのだろうか?

Java 開発者のためのバイナリ管理入門

まとメモ

  • BinOps→バイナリ中心のCI/CDの自動化

感想

バイナリ管理は、バイナリ用のVCSを立てれば良いのではなかろうか?
プレーンテキストと混ぜるからややこしくなる気がする。

ブランチ管理をやってくれるって理解でいい?
使ってみないと、自分の知識レベルだと、理解が厳しい。。。

マイクロサービスアーキテクチャをあきらめないための、モノリスで始めるアーキテクチャテスト

感想

初期からマイクロサービスは無理だと思う。
いきなりマイクロで作ると、工数が多くなり、破綻のリスクがあると思う。
まずは、リリースを安定させることが重要な気がする。

ルールは、作るより保つほうが難しい。
ここは、やはり、同じか。。。

依存関係のテストって、どうやってやるんだ?
何を見てテストしてるんだろう?

ArchUnitは、気になった。

テストが失敗したときは、どうするんだろう?
テスト失敗=違反or設計が間違ってたのどちらかだと思うが、開発者レベルだと難しい気がするが、誰かにアラート上げるのかな?

FW作ってるところは、ArchUnit提供して欲しいなと思った。

TODO

  • ArchUnit試す

全体感想

昼休憩なしでぶっ続けなんだな。。。
ちゃんとタイムテーブル見ておけば良かった。
昼飯を事前に買ってくれば良かった。。。

オンラインになって、人数制限がないから、人気のセッションがちゃんと見れるのは良かった。
オフラインだと、どうしても部屋の制約がかかってしまうからな。。。
今回は、見たいものがちゃんと見れた。 あと、複数セッションを同時に見れるのは、新鮮だった。
僕は、聖徳太子ではないので、複数を同時に見るのは無理だったが。。。
あとは、他人の目がないので、飲食しながら見れたり、ながら見ができるのは気楽だった。
あと、セッションを途中で抜けたりできるのも良かった。
オフラインだと、無言の圧力で抜けにくいんだよね。。
セッションを拝聴して、なんか思ってたのと違った場合に、気軽に抜けられるのは良かった。

音声が乱れるときがたまにあった。
字幕付きの映像だとなお良かった気がする。

そういえば、IoTとかに関するセッションがなくなったな。
流行期は去ったのだろう。
今は、なんだろう?
パフォーマンス系が多かった印象がある。
今年は、インフラ周りが多いなって思った。
役割分担が進んだ結果なのかも知れない。

2020/10/19週 気づきと振り返り 文字見て頭痛が起きるのは初めて

業務こなしての問題・気づき

設計書関連

項番

案件対応で修正する際、項番ズレるの、どうしたらいいの?

すごい見落とすのがつらい。。。
視力落とす訓練をしているようだ。

ID管理

極力やめたほうがいい。
ID管理しだすと、ドキュメント量が増えるし、採番管理とかの必要性が出てきたり、簡易ミスが発生しやすかったりする。

意味のない文字や数字は、ものすごい間違いやすい。
現在進行系で痛感してるけど、大量に見てると、頭が痛くなるレベルで脳に負荷がかかってると思うんだよね。

ID管理のコストは、高いことを認識するべきだと思う。

その他

なぜなぜ分析

問題を発生した当人へのヒアリングは、しないほうがいいのではないかと感じる。
普通に考えたら、詰問してるようにしか見えないんだよね。。。
「責めてるんじゃない」って言われても、外部から見ると、詰問しているようにしか見えない。

当人も、問題を起こしたくて起こしたわけではないと思うんだよね。
実体験だが、なぜ失敗したか聞かれても、「分からねぇよ」ぐらいしか回答がない。
それを正直に言うとキレられるし、どうしろって言うのだろうか。。。
今のところ、適当にそれらしい理由つけて回答するようにしている。

トヨタのモノマネを安直にしようとした結果、当人を追い詰めてるような気がしてならない。
組織文化は、簡単に根付くものではないので、安易に他社でやっていることを真似るのは、ダメだと思う。

まずは、実態を正しく把握するほうが優先な気がする。
それができていないのに、他社の施策を真似ても、失敗するでしょうね。。。

はじめての動画投稿

ゲームのゆっくり実況を作ったのだが、なかなか面白いね。
Youtuber目指す子どもが一定数いるのが分かる気がする。

編集、構成を考えるのが、個人的に楽しかった。
現実が上手くいかないから、こういうので表現するのが楽しいと感じたのかも知れない。

自分で作った動画見て、自分で笑っているのを自覚したのだが、結構なナルシストではないかと思い、恐怖を覚えた。。。

作っていた思ったが、マシンパワーが足りない気がする。。。
Core i5だからだろうか?動画の作成に結構、時間がかかった。
7・8年前くらいに買ったやつで、メモリは増強したのだが、CPUは変えてないんだよね。
SSDも着けたいし、USBのポート数増やしたいとかもある。
冬のボーナスで、少し改造してみようかな?

インポスター症候群

インポスター症候群という自覚はしたのだが、なかなか立ち直るのが難しい。。。

どうしても、小さな失敗を過剰に後悔してしまう。
分かっていても、なかなか変えられない。
心の持ちようだけで変えるのは、無理があるのかもな。。。
やっぱり、環境を変えるしかないのだろうか?
今の御時世、なかなか現場は変えられないんだよね。。。
今年いっぱいで一区切り付くから、それまで持つかだな。。。

調べてまとめた内容のページへのリンクを載せておく。
同じ悩みを抱えてる人の手助けができればいいなと思う。

suzaku-tec.hatenadiary.jp

インポスター症候群の調査とまとめ

きっかけ

自分がインポスター症候群の可能性が高そうだと気づいたので、いろいろ調べたようと思った。

インポスター症候群とは

wiki引用

インポスター症候群(インポスターしょうこうぐん、英: Impostor syndrome、インポスター・シンドローム)は、自分の達成を内面的に肯定できず、自分は詐欺師であると感じる傾向であり、一般的には、社会的に成功した人たちの中に多く見られる。ペテン師症候群(ペテンししょうこうぐん)、もしくはインポスター体験(インポスターたいけん、impostor experience)、詐欺師症候群(さぎししょうこうぐん、fraud syndrome)とも呼ばれる。

個人的解釈

他のサイトの内容を見て、統合的に察すると、「自分の能力や実績を認められない傾向、成功ではなく失敗の方に関心が向かう」もののようだ。
詐欺師症候群って和名は、その症状がある人に追い打ちをかけるような感じがするのだが、直訳しただけなのかな?
この和名を考えた人は、センス無いと思いました。

日本人が陥りやすいのかと思ったが、研究の発症はアメリカらしい。
日本人だと、チーム戦として仕事を考えた際に、他人の成果でも自分のせいかとして考える思考があるから、研究対象にならなかったのだと予想。
最近は、個人主義が強くなってきたら、この症状になる人が増えたのではないかと思われる。

インポスター症候群の特徴

  1. 自信がない
  2. 周りの評価の過大評価に恐れる(自信の能力を過小評価している)
  3. 自分の実力が無いと思っている
  4. 実績を受け入れられない

ヤバい。。。
ほとんど思い当たる節がある。。。
自信なんてない。逆に、どうやったら自信がつくのか教えて欲しいくらい。
過大評価というか、他人の評価を素直に受け入れられないんだよね。。。
褒められても、それは俺を煽てて操るつもりでは?って思ってしまう。
実績を受け入れられないのも、分かる。誰でもできるだろって思ってしまうのよね。。。

対策方法

サイトを横断的に見ての対策方法のサマリ

聡明な人々の近くにいる

知恵があるだけでなく、人格者であるってのがポイント。
知識不足を補うことに対して、劣等感が生まれにくいはず。

全知全能などいない

すごい開発者に見える人は、実はそんなにすごくないことはザラにある。
実績があるのは、実績を重ねられるような環境が作られているからかも知れない。

非の打ちどころのない人であろうと努力することで、生産性を低下させ、創造性も低下することもある。
完璧を求めすぎて完璧から遠ざかることはよくあるので、あまり気負いすぎてはいけない。

実績を記録に残す

日記をつけたりして、客観的に実績が見えるようにする。
そうすることで、実績を受け入れられないことをなくし、自信を取り戻す。

一流から学ぶ

一流の人のルーチンを真似る。
結果が出ているのだから、真似れば何らかの効果があるはず。

俺が考えた対策方法

何かを作るしかない。
ちゃんと目に見えるものが出来てしまえば、自然と自信に繋がり、他社の評価を受け入れられるのではないかと思う。
エンジニアであれば、特に、ね。
芸術家とか、クリエイターなら、モノを作るしか解消方法がないと思う。

何かを作りきるまで辛抱強くいられるかが、克服の難関な気がする。

関連リンク

インポスター症候群を克服する13の方法 | ライフハッカー[日本版]

インポスター症候群を克服する方法

エンジニアの混乱と成長について|Kamata Masahiro|note

Impostor Syndrome(詐欺師症候群)とQiitaについて - Qiita

もっと優れた開発者になりたければ、いますぐコーディングをやめなさい – WPJ

2020/10/05週 気づきと振り返り 初心に返る

業務こなしての問題・気づき

ドキュメント

ファイルサーバー管理はやめるべき

ファイルサーバーにファイルを直置きして編集するのはやめるべき。

やってて不便だと思ったことを列挙

  • 複数人同時編集した場合、ファイル破損のリスクが高い
    • Excelとかだと特に
    • VM環境からファイルサーバーアクセスしている場合は、更にその危険性が上がる
      • 意図しないファイルロックがかかったりして、作業が滞る
  • 読み取り専用とかにして意図しない編集を避けようとすると、今度は編集した内容を保存し忘れる。。。
    • 僕が何度かやらかして、酷く怒られましたわ。。。
  • 編集の競合で待ちが発生する。

打開方法

VCSでドキュメント管理する。
これ以上の方法は、今のところ、思いつかない。

ファイルサーバー管理で、リスクの順位は下記のとおりだと思ってる。 1. ファイル消失 2. ファイル破損 3. 更新忘れ 4. 競合による待ち

1, 2 は、VCS管理なら起きないはず。
起きたとしても、問題はローカル内に閉じているはずだから、影響範囲を小さくできると思う。
VCSリポジトリ格納しているサーバーが飛んだというのもあるけど、それはファイルサーバーでも同じ。
そもそも、そのケースは起きづらいと思う。
3, 4 リスクはあるが、回避可能なので、そこまで大きな問題はないと思う。
更新忘れは、VCSだとコミット忘れとかだと思うので、日常的に確認する作業に含まれるため、多発はしづらいと思う。

VCSとかで管理しない場合、やることが多かったり、注意することが増える気がするんだよね。
それで負荷かかって、いろいろ忘れて問題になると思う。
環境を変えることでなんとかできるものを、個人の責任になることが多いのが日本のIT現場の現状だと思う。
個人の責任にするのはいいけど、同時に環境を変えることで効率化できないか考えないとダメではなかろうかと思う。

雑記

最近、技術動向追えてないな。。。

あんまり関心のないシステム開発系のことばかり書いてしまう。。。

WEB-DBとかを購読してるから、たまには、雑誌の中から小ネタ探して調査してもいいかもね。
昔はそうしてた気がする。。。

なんか、最近、モヤモヤすることが続いてしまった。
精神的に弱っているせいか、尖ったことを書いてしまったこともあった気がする。
初心に返って、ちゃんとしたスキルを身につけるための行動をしていくように心がけよう。

2020/09/21週 気づきと振り返り デザインは偉大

業務こなしての問題・気づき

レビュー

指摘が多いからって罵倒していいわけじゃないよね?

今やっているドキュメントが、死ぬほど読みづらい上に、何か一つを修正すると連動して複数の箇所の修正が必要になる。
芋づる式に修正箇所が増えてて、レビュー時にも修正漏れとか大量に指摘されるのだが、だからって、「あほ」とか罵倒していいわけないと思うのだが、俺が違うのか?

海より広い俺の心も、ここらが我慢の限界だと思ったよ。。。
※これの元ネタ、知っている人とは仲良くなれそう。

こういうリーダーには成りたくないと思いましたわ。
それに、指摘事項の意味が分からないときに、すごく聴きに行きづらい。
すでに、俺はこの人と会話したいと思わない。
あと、あんたのレビューが通ったら、エンドユーザーのところに行くのだが、いいの?って感じた。
その指摘を設計書にコメントで書く神経が分からない。
消し忘れたりしたらどうするんだろうって思った。

尋常なないくらいハゲになりそうな予感がしました。

デザイン

最近、強く思うのだが、UI/UXって、むちゃくちゃ重要だなって思う。

今、改修している画面が、項目をてんこ盛りしている画面で、ドキュメントは分かりづらい・画面が汚くて操作しづらくて、辛い。
なんと言えば伝わるだろうか。。。
なんか、プログラマーが考えた画面って感じの画面。
伝わるかな?
もう、隙間なく入力項目が配置されている感じ。

良いUI/UXは、読みやすいドキュメントを生み、メンテしやすい画面になると感じる。
今までシステム開発してきたけど、デザイン会社に画面デザインを依頼していたところは、比較的、残業は少なかった気がする。
逆に、システム会社(SIerとか)が作るような画面は、項目をてんこ盛りにするので、かなり辛い。
何か条件が変わると、画面のどこかが変わるとか、項目が多すぎて変化が分からないってことがある。
視力悪化のためのストレス試験を受けている感じすらする。

長期的に見て、デザイン会社にちゃんと発注するほうが、コスト安くなる気がする。
デザイン会社にもよるのだろうが、いままでの経験から考えると、そういう結論になる。

この考え、ユーザー側に理解してもらえるのか、かなり疑問。
目先のコストを安く済ませようとして、長期的に損をするパターンがありそう。

東証の会見

見てたけど、記者のレベル低すぎないか?
嫌味だけ言ってきたやつとか、頭おかしいんじゃねーの?って思った。
あと、すでに回答されている内容を引き出す質問をする意味が分からん。
その質問したら、前と同じこと言うよね?って思ったのだが、違うのだろうか?

質問してる記者は、システム開発とかに携わったことがない。。?
定時点の意味がわからないって感じの質問を聞いたときは、「まじかよ。。。」って思った。
東証の回答者は、かなり親切に対応していると感じた。

なんか、質問聞いてたら、そもそも株取引したことないんじゃないの?って感じの記者もいたな。。
最後の方は、もうシステム関係ないじゃんって思ったのだが、記者の人は何を聞きに来たのだろうか?
それ聞いてどうすんの?って感じの質問が多すぎ。

「ステータスが難しい言い方」ってのが、すごくジワる。
俺も、回答する側だと、そういうかも。
だって、記者の人たち、システムの考え方とか、全然分からなそうだったからな。

改めて確認が多すぎるな。。。
本当に記者なの?
同じような質問を何回するんだ?

「横文字使わず優しく教えて下さい」って言ってたのを聞いたときは、さすがに吹いたな。。。
それ、聞いたことをそのまま流すつもりだろ。。。
聞いた記者は、フェイルオーバーとか、ディスクとかも分からないのだろうな。
記者なら情報を咀嚼して、分かりやすく伝えるのが仕事だと思うのだが、それを放棄してる?
伝言ゲームでいいのなら、この会見に来なくて良かったのでは?って思った。
呆れると同時に、腹立たしさを感じる。
こんなのにも対応しなきゃいけないから、東証の会見をしていた人たちには同情するよ。

これは、もしかしたら、システム開発の上流工程で同じようなことが起こってる??
ユーザ側が不勉強すぎて、話がまとまらず、しわ寄せが俺たちのところに来ているとかないよね?
急に怖くなってきたわ。。。

雑記

もう、疲れたよ。。。
毎日かけられる会議の精神負荷、視力悪化のためのドキュメント、すべてがストレスを与えてくる。
ストレス社会でどうやって生き抜くか、なかなか答えがでない。
もう、クラゲになって、流れに身を任せて末永く生きたい気分。
このポエム、もしかして病んでる??

動物なら癒やしてくれるだろうか?

2020/09/21週 気づきと振り返り フォルダ構成は大切

業務こなしての問題・気づき

設計・ドキュメント

ファイルを無駄に増やすな!!怒!!

なんか無駄にファイルが分割されているせいで、レビュー時に指摘されてイラッとするのだが。。。
ファイルが少なくて、近くにあるのなら気づくけど、大量にある上に、場所が離れているという。。。
それに、各ファイルの説明もないし、気づけって言う方が無理だろ。。。

なんか、それでスゲー嫌味っぽく言われて、腹立たしい。

あと、フォルダ構成も最悪だった。
大枠からだんだんと範囲が特定されるようなフォルダ構成が基本だと思うのだが、そうなってないんだよね。。。。
全然別のフォルダ下に全く同じフォルダ構成があるから、たまに分からなくなる。
これは、フォルダの迷路でも作っているのか?って思う。

フォルダ構成って、意外と大切だと思う。

雑記

最近、精神的に追い込まれてる気がする。。。
何やっても上手くいかないんじゃないか?って常に心の中で思ってしまうんだよね。。。

温泉街に旅行に行っていたが、精神的な疲れは取れなかったよ。。。
月曜から仕事だと思うと、結構、憂鬱。
これを解消する方法は、ないのだろうか?

2020/07/27週 気づきと振り返り 精神崩壊してない俺はカミーユ以上

業務こなしての問題・気づき

設計・ドキュメント

印刷時のヘッダー・フッターにこだわる

エクセルのヘッダー・フッターって、そんなに重要か?
レビュー出した際に、そこの部分のダメ出しをされたのだが、まさか、最終的に紙に出して管理しているのだろうか?

紙で管理するのはいいけど、情報の扱いが難しくなるから、絶対にやめたほうがいいと思う。
紙1枚でも紛失したら、情報漏えいだし、シュレッダーかけないのはNGになるだろうね。
こっそり持ち出しもしやすいってのもある。
無駄に労力かける割には、セキュリティリスクは減ってない。むしろ増えてる。
ペーパーレス化して欲しいのだが、力関係が面倒くさい。
日本の仕事場って、なんで政治的な要因が絡んでくるのが多いんだ?

仕様以外のところでビクビクしながらドキュメント直すの、正直しんどいのだが。。。

そこまで書く?

ウォータフォールで開発しているのだが、概要・要件フェーズで、詳細な処理内容の記述を求められているのだが、そこまでする必要あるんですかね?

むちゃくちゃ細かく書いているせいで、DB変更が甚大じゃないレベルで影響があるのだが。。。
概要だと、まだDB周りがブレるのだが、そのブレの影響をモロに食らって死にそう。。。

ケツは決まってて、やることがだるま式に増えるのは、マジで精神的にキツイ。
俺じゃなかったら、精神崩壊してると思うよ?

セルフチェック

5~6個くらいならわかるんだけど、20個以上をセルフチェックさせるのは、無理がある。

しかも、書いてあることは、基本的に仕様に関わらないことだし。

どうでもいいところにこだわるの、マジでやめて欲しいわ。。。
レビューで何か指摘しなきゃっていう強迫観念でも抱えているのだろうか?
あら捜しで、どうでもいいところが指摘され、それがセルフチェックに入り、開発者の負担をドンドン増やしている認識がないのだろうという理解を最近するようになった。
これは、どう考えても負の連鎖だろ。。。
いくらやっても、あら捜しがある以上、タスクが減ることはないという。。。
現代版の拷問ではなかろうかとすら思えてくる。

もう、終わりが見えなくて辛いわぁ。。。

総括

硬い現場ほど、どうでもいいところにこだわる印象がある。
「それって、必要なん?」って指摘されてて思ってるけど、いざ言うと、ルールだからの一点張りだからな。。。
そのルール見直せやって思う。

これで精神崩壊起こしてない俺は、カミーユより強いと思っていいだろうか?
今風だと、エミリアより強いと思っていいだろうか?

Java15

リリースされましたな。
9月のリリースは、俺の誕生日と近いから、否が応でも年齢を意識しちゃうんだよね。
そういうシビアなお年頃なの。

リリース前にまとめた記事を列挙しておく。

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

suzaku-tec.hatenadiary.jp

直近の目標

情報処理技術者試験でDBスペシャリストを受けるのだが、受かる気がしない。。。。
業務で精神ズタボロにされてるのに、試験の勉強なんかする気起きねぇよ。。。
現実逃避のために、だいたいポケモンのランクマやってる。
最近、安定して4桁台にいけるようになった。やる時間がとれてれば、たぶん3桁行けるんじゃなかろうか?