umizoko hirame

はじめに 本屋の目立つところにおいてあり、気になり手に取りました。中身をざっくりみると、多くのサービスのシステム設計について記述されておりとても興味を惹かれました。内容も素晴らしく、前半ではスケールする設計や可用性、データ量などのざっくりとした見積もりや数字感覚、汎用的なミドルウェアのアルゴリズムについて紹介します。後半はチャットシステムや動画配信サービス、クラウドストレージサービスの設計について紹介しています。この本を読むことで各サービスの機能の裏側をイメージすることができ、大変面白かったです。かなりおすすめです！ システム設計の面接試験（アレックス・シュウ） | 書籍 | ソシムシステムの設計はシステムの機能や仕様、データのアクセスやセキュリティを左右するため、

はじめに ... AIとはシステムそのもではなくハイブリッドなシステムで、それはAIをつかうわたしたちによって構成されます。つまり新しい動物が出現しつつあるということです。これこそが正しくアニミズム的なコンセプトです。マシンそのものをひとつの生命体だと考えるのではなく、わたしたちとマシンとのインタラクションこそが新しい生命のかたちだと考えるのです。 「資本主義の行方、あるいはAIと哲学を巡って 」 THE REGENERATIVE COMPANY 未来をつくる会社『WIRED』はテクノロジーによって、生活や社会、カルチャーまでを包括したわたしたち自身の「未来がどうなるのか」についてのメディアです。最新のテクノロジーニュースから、

はじめに webサービスを高速化するためのアプローチを知るために本書を手に取りました。本書では「高速なwebサービス」の定義やなぜ必要なのかという掘り下げから、ISUCONの問題をテーマに計測、分析、改善のチューニングのアプローチを紹介します。本書では、データベース（MySQL）のインデックスやクエリのチューニング、Linuxのマシンリソースの分析やチューニング、リバースプロキシやキャッシュを使用した高速化手法などStep by Stepで紹介します。本書を読むことでパフォーマンスチューニングのためのベースラインを獲得できます。 どのChapterも学びがありおすすめです。特におすすめは「付録A

はじめに 日々の業務において課題を解決するためのドキュメントを作成したり、情報を整理してナレッジウェアツールにまとめたりすることがあります。そのドキュメントは目的を手助けするために作成しているのですが、読みにくいという課題がありました。その課題感を解決する手がかりを得るため - 読み手の目的を手助けするためのドキュメントライティングの知識を獲得するため、本書を手にとりました。 本書ではある会社のプロダクトの開発ドキュメントの作成を通して、読み手を助けるドキュメントライティングの方針やプラクティスを紹介します。この本を読むことで、フィードバックを得てドキュメントを改善していく方法やチームでの展開の仕方も学ぶことができます。またフィードバックのトリアージのガイドラインやドキュメント構成の情報アーキテクチャも紹介しているのですが、より汎用的で再利用可能な知見としてとても重宝します。何かドキュメントを作る必要があるときに手元にあると便利です！ エンジニアのためのドキュメントライティング ユーザーの問題解決とプロダクトの成功を導く開発者がいかにすばらしいプロダクトを作ろうが、ドキュメントの

はじめに システム運用のまとまった知見を獲得したいと本書を手に取りました。本書ではシステムを運用で直面する課題について原因を提示し、その解決方法のアプローチを提示しています。課題の領域はシステムそのものから開発、メンバー・チーム・組織とのコラボレーション、タスクの取り組み方まで多岐にわたります。 テストやデプロイワークフローを扱う５章・８章。開発者体験向上、ソフトスキルを扱う９章、１０章、１１章、１２章が面白く、知見を得ることができました。 システム運用アンチパターン上層部がDevOpsに理解のない組織で働き、

はじめに 「継続的デリバリー」という文言に興味を持ち、本書を手にしました。業務においてパイプラインエクゼキュータを用いてCI/CDパイプラインを構築するのですが、いまいちしっくりこなかったため何かヒントになるかみたいな感じで。 本書『継続的デリバリーのソフトウェア工学』ではソフトウェアが直面する課題について、経済・現実・実用的なアプローチの応用方法について紹介している書籍です。設計を良い方向性に向かせるためのTDD・DDDや凝縮度・カップリング、関心の分離とはなにか具体的に紹介しています。 継続的デリバリーのソフトウェア工学 もっと早く、もっと良いソフトウェアを作るための秘訣本書はソフトウェアに関する諸問題を、

はじめに 私はソフトウェアエンジニアとしてプロダクトの開発をしています。開発を進めるなかプロジェクトの完了とともにプロジェクトチームが新体制へ移行、同時にアジャイルプラクティスなどのチーム文化のナレッジがチームに留まらないことに課題を感じていました。参加したプロジェクトメンバーに知見が共有されることよいことですが！ texta.fmの「11. Favorite Technology Survey」でthoughtworks社が提供しているTechnology Radar Volume 27 を紹介していて、眺めていた時にチームの認知負荷として本書「チームトポロジー」が紹介されていました。 チームの相互作用は、

はじめに システムの不具合が発生したとき、直観で解決してきた。環境での斬新な原因を特定するときはインフラ・ネットワーク・アプリケーションログの断片をつなぎ合わせ解決してきたが限界があると認識、直観ではなく事実で解決できるアプローチはないかなと探していた。 モニタリング・オブザーバビリティとの哲学的な違いの説明や、ログ・メトリクス・トレースやプロファイルなどのテレメトリーデータの実装方法について学べます。 オブザーバビリティ・エンジニアリング本書は、近年のクラウドベースのソフトウェアシステム開発における設計プラクティスなどにおいて触れられる概念「オブザーバビリティ（可観測性）」に関する書籍です。オブザーバビリティとは何か、どのように役立てるのかなど、