全然続かない恐れもあった日記的な記事だが、とりあえず3日は続いた。テーマを決めない気楽さがよかったらしい。ブログって、テーマ決めるのと前文書くのが一番時間かかるからねほんとに。ある程度同じテーマの話がたまってきたら、それを記事にできたらいいな。
- 若手の教育
- AWS、Firebase
- 失敗の本質
- みずほ銀行
仕事
教育
若手の教育をどうしたものか悩んでいる。世の中には業務時間外の学習を忌避する向きがあることは知っているが、技術者というのは知識労働者であり、必要な専門知識を業務時間内だけで得られるはずはない。業務時間外の学習が嫌なら知識労働者なぞはなから志すべきではない。
と思うものの、現実的に業務時間外の活動を直接期待するわけにもいかない。なるべく身になるように考えてはいるものの、どこまでいっても、業務時間内に得られる知識だけでできる仕事は、その程度の仕事である。
まぁ本人がそれでよければ、それでいいのかもしれないのだが……。しかしチームとしては、どうしてももっと期待してしまう。やる気が出る、うまい仕組みはないものだろうか……。
Webサイトの脆弱性
若手の知識不足を埋めるため、とりあえずいわゆる徳丸本を読ませている。ようやくクロスサイトスクリプティングとSQLインジェクションの概要を見た程度だ。
どちらも入力あるいは出力に仕込まれる、意図しない不正な命令だという点で本質的に同質のものなんだよ、という話を今動いているシステムなど例にしながら話したが、果たしてどこまで伝わっているだろうか。
API GatewayのIP制限
社内からのみリクエストできるAPIをAWS上に構築したいのだが、まぁ手っ取り早いのはIP制限だろうと。WAF使う必要があるかなと思っていたのだが、普通にAPI Gatewayのリソースポリシーで設定できるらしい。しかもSAMが使える。
AWS SAMでAPI Gatewayのリソースポリシーを設定してみた | DevelopersIO
たださすがに、Eventsで簡易的な書き方はできないようだ。そういえば、PUTとかDELETEでCORSの設定やらなんやらちゃんとするには、わけて書く必要があって昔ハマった記憶がある。テンプレートファイルが凄まじい長さになったなぁ。
まぁなんにせよ、SAMでできるのは有り難い。
個人開発
Firebaseでトランザクション処理
今日も開発。
どうやら、カードの番号が重複することによるバグが発生しているらしい。複数ユーザーが同時にカードを作成すると、クライアントが番号をつけているために重複してしまうのである。
だいぶダサいが、まぁ支障ないしいいかと放置していたのだが、最近入れたキーボードによるカードのフォーカス移動機能のバグの原因になっているらしく、さすがにそろそろ対応するか、と。
色々考えたが、データベースのドキュメントに番号をもたせて、それをFirebaseの機能でインクリメントして、インクリメントした番号をカード番号としてやれば良いのではないか、と。エラーが発生すると番号が飛ぶが、まぁ別に厳密に番号付けしたいわけではないし、それらしい番号で重複しなければよいのである。本質的には、Firestoreのインクリメント機能を使って楽にトランザクション処理をするような感じだ。
読書・動画
失敗の本質
以前読みきれなかった失敗の本質、Audibleなら聞けるだろうとポチった。Amazon Audibleは今月末から聴き放題になる(というか戻る)ので、コインを何に使うか悩ましかったが、失敗の本質、キミにきめた、と。この本は何度も聴かないとわからないからね。
ということで最初のノモンハン事件を聞いたが、関東軍はいったい何がしたかったのか。近所の高校に舐められたくないチンピラにしか思えなかったんだが。そして当時の軍の総括が多分に精神論で泣いた。
個人の想いみたいなもので動いているような印象だが、全体として無責任体質なのは本当に大いなる矛盾だ。結局、誰も本当の意味で本気じゃなかったんじゃないのか……。
みずほ銀行
失敗の本質現代版。
基本的なところから知らなかったけれど、そうか、元々3つの巨大な銀行が合併したのがすべての始まりなのだね。この動画は報告書編も面白かった。
組織構成がアーキテクチャに反映される、コンウェイの法則の最悪な見本。政治の段階で技術は始まる。最初に入った個人事業みたいな会社の社長は、「発注以上のものはできない」と言っていたが、その意味は働き始めて年々わかってきた。
不毛な政治闘争をするお偉方を支えるのは、他ならぬ従業員である。動画でも触れられているが、これはもはや組織全体の問題なのだが、当の従業員にその意識がない。結局みずほはこの後も障害を起こしているし、これからも起こし続けるだろう。
THE MODEL
かなり大規模な企業の経営者向けと思われ、正直読んでも身になるところはあまりないのだが、なるほどこういう世界もあるか、といったことのない土地のガイドブックを眺めるような気分で読んでいる。
顧客を分析していく流れは、システムのリソースの分析のようで、共通しているところもあるのかもしれない。課題を一覧にして毎日眺めるのは、システム開発においても良い習慣といえそうだ。
カスタマーサクセスなどは開発ではあまり聞き慣れない言葉ではあるけれど、この概念にユーザーエクスペリエンスは包含されるのかもしれない。
関連記事
雑記 の記事
- [2022年1月25日] 2022年1月25日 社内情報の取得が一番の関門
- [2022年1月25日] 2022年1月24日 k8s・Docker・Flask初学者奮闘、YouTube Premium 年間プラン
- [2022年1月23日] 2022年1月23日 いつかあの光景を再現したい
- [2022年1月23日] 「仕事をする」ということの体得
- [2022年1月22日] 2022年1月22日 失敗の本質
- ---本記事---
- [2022年1月20日] 2022年1月20日 Coinhiveの逆転無罪
- [2022年1月19日] 2022年1月19日 マイナスをゼロに戻す仕事の憂鬱
- [2022年1月18日] 2022年1月18日 DyanmoDB、メタバース、アキネータ
- [2022年1月8日] 2022年もよろしくお願いします
- [2021年11月3日] ノートPCだけでいいのかもしれない
スポンサーリンク