こんにちは、 @kz_morita です。 今回は、 『プログラマー脳』 を読んだので感想を書きます。 書籍について 書籍名は、 『プログラマー脳 ～優れたプログラマーになるための認知科学に基づくアプローチ』 で秀和システムから出版されています。 以下のような内容となっています。 Part 1 コードをよりよく読むために Chapter 1 コーディング中の混乱を紐解く 1.1 コードにおけるさまざまな種類の混乱 1.2 コーディングに影響を与えるさまざまな認知プロセス 1.3 それぞれの認知プロセスが協調的に動作する仕組み 本章のまとめ Chapter 2 コードを速読する 2.1 コードの速読法 2.2 記憶のサイズ制限を克服する 2.3 読めるコードよりも見えるコードのほうが多い 本章のまとめ Chapter 3 プログラミング言語の文法を素早く習得する方法 3.1 文法を覚えるためのテクニック 3.2 フラッシュカードを使って文法を素早く覚える 3.3 物忘れを防ぐには 3.4 文法を長く記憶に留めるには 本章のまとめ Chapter 4 複雑なコードの読み方 4.1 複雑なコードを理解するのが難しい理由 4.2 認知的負荷を軽減するテクニック 4.3 ワーキングメモリに負荷がかかっているときに使える記憶補助ツール 本章のまとめ Part 2 コードについて考える Chapter 5 コードの深い理解に到達する 5.1 「変数の役割」フレームワーク 5.2 役割とパラダイム 5.3 プログラムに関する知識を深める 5.4 文章を読むこととコードを読むことは似ている 5.

こんにちは、 @kz_morita です。 今回は 『エンジニアリング組織論への招待』 を読んだので感想を書きます。 書籍について 書籍名は、 『エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング』 で、技術評論社さんの方から発売されています。 以下のような内容になっています。 Chapter 1　思考のリファクタリング 1-1　すべてのバグは，思考の中にある 1-2　不確実性とエンジニアリング 1-3　情報を生み出す考え方 1-4　論理的思考の盲点 1-5　経験主義と仮説思考 1-6　全体論とシステム思考 1-7　人間の不完全さを受け入れる Chapter 2　メンタリングの技術 2-1　メンタリングで相手の思考をリファクタリング 2-2　傾聴・可視化・リフレーミング 2-3　心理的安全性の作り方 2-4　内心でなく行動に注目する Chapter 3　アジャイルなチームの原理 3-1　アジャイルはチームをメンタリングする技術 3-2　アジャイルの歴史 3-3　アジャイルをめぐる誤解 3-4　アジャイルの格率 Chapter 4　学習するチームと不確実性マネジメント 4-1　いかにして不確実性を管理するか 4-2　スケジュール予測と不確実性 4-3　要求の作り方とマーケット不安 4-4　スクラムと不安に向き合う振り返り Chapter 5　技術組織の力学とアーキテクチャ 5-1　何が技術組織の“生産性”を下げるのか 5-2　権限委譲とアカウンタビリティ 5-3　技術的負債の正体 5-4　取引コストと技術組織 5-5　目標管理と透明性 5-6　組織設計とアーキテクチャ 感想など この本を読もうと思ったきっかけは、普段エンジニアリングをしている中で組織についてやメンタリングについて興味を持ったことです。 本自体は以前から気になっていたしかなり有名な本であるので読んでみようと思いました。

こんにちは、 @kz_morita です。 今回は，O’Reilly から発売されている 『入門 監視』 という本を読んだのでそのまとめです． https://www.oreilly.co.jp/books/9784873118642/ 目次としては以下のようなものになります． はじめに 第Ⅰ部 監視の原則 1章 監視のアンチパターン 2章　監視のデザインパターン 3章　アラート、オンコール、インシデント管理 4章　統計入門 第Ⅱ部　監視戦略 5章　ビジネスを監視する 6章　フロントエンド監視 7章　アプリケーション監視 8章　サーバ監視 9章　ネットワーク監視 10章　セキュリティ監視 11章　監視アセスメントの実行 付録A　手順書の例：Demo.App 付録B　可用性表 付録C　実践.監視SaaS 訳者あとがき 索引 読んだモチベーション 日頃から，システムを運用しているため，システムやアプリケーションの監視も行っています． 監視をするなかで，以下のような課題感があります． アラートの量が多く対応すべきものが見えにくい 出たアラートは自動でチケット化しているが，対応可否を判断するための作業に一定時間がかかる システムの一時的な不調により出るエラーだが対応が不要なものが多い アラートの数が多いとそれだけで，システムの重要な兆候を見逃す可能性もありできるだけ減らしたい． 一方で，数が少ないとはいえエラーがでているため誰も気づけない状態は避けたいため，アラートを減らせていないという状況にあります． これらの課題をうまく取り扱い，システムをより監視しやすくしたいというモチベーションで本を読みました． 読んだ感想 読んだ感想としては，監視というものについて体系的にどう考えるべきかという話からすぐに取り組めそうなプラクティスまであったのが個人的にはとても良かったです． たとえば，アラートを いますぐに対応すべきアラート 参考情報としてのアラート の２つに分けるという話があったのですが，これは自分の課題であったアラートが多すぎるというものの解決策として取り入れたいと思いました． 普段 Alert を Slack に通知しているのですが，参考情報としてのアラートについては Slack に通知せずに Ticket 化するだけというのがよさそうかなと思います．