読書メモ

1.この記事を書こうと思った背景 ぼくはリモートワークで仕事をすることがほとんどだ。リモートワーク下において仕事でのコミュニケーションの大半は テキストベース だが、文章で自分の考えを伝える ことのむずかしさを感じることが多々あった。そうした背景がありつつ、以前読んで読みやすいと感じた『プログラマの数学第2版』や数学ガールシリーズの著者が 『数学文章作法 基礎編 （ちくま学芸文庫）』(以下、本書)を出版しているということで手に取った。本書から学んだことを、ここに書き留めておく。 2.目次 第1章　読者 第2章　基本 第3章　順序と階層 第4章　数式と命題 第5章　例 第6章　問いと答え 第7章　目次と索引 第8章　たったひとつの伝えたいこと 3.本書を通しての学び よい文章を書くことはむずかしいと改めて感じる一方で、じゃあ、どうすればいいか？そのヒントを得ることが出来た。そのヒントを章ごとに挙げていく。 「第1章　読者」より 読みやすい文章を書く 著者は読みやすい文章を書く原則とは、読者のことを考える ことだという たしかに文章を読もうと手にとってもらわなければどんなにいい文章でも意味がない では、読者のことを考える とは何について考えればよいのか？というと、著者は以下の3点を挙げている 読者の知識 読者の意欲 読者の目的 書こうとしている文章は読者の知識レベルに配慮して書かれているか。文章を読み進めようという意欲を掻き立てるものか。読むことで自分の目的は満たされると思ってもらえるか。どれも抜け落ちていた視点だったので、本書を読み進めようという強いモチベーションに駆られた。（しばらく読み進めて、なるほど。これが読みやすい文章かとなった。） また、本書では述べられていなかったが、会社やコミュニティなど書き手と読み手が共通のコンテキストを有する場合には、過去に積み上げられてきたドキュメントから文章の書き方や、そこで使われているローカルルールを押さえておくと、読者にとって読みやすい文章を書く助けとなるだろうとも感じた。 「第2章　基本」より 文は短く これは、何を主張している文か と自問自答 逆説ではない「が」を使い、冗長的になっていないか？ 「ちなみに」と、本筋からはずれているとはいえ、理解の助けとなる話題を提示しているか？ 「第3章　順序と階層」より 書き直しの重要性 書き直しをすることを想定して書き始めるべき 接続詞は使わず、箇条書きで書くことはせずとも、キーフレーズを書き並べるところから始めるだけでもいいかもしれない 「第4章　数式と命題」より あいまいさをなくす ひとつの文章ではひとつのことを伝える 「第5章　例」より 例のファーストチョイスは、典型的なもの その次に極端な例や、あてはまらない例、一般的な例などが続く 例を挙げる際にも、読者の知識レベルやバッググラウンドに配慮すること OSS やクラウドベンダーのドキュメントでよく出てくる Getting Started は典型的な例にあてはまるのだろう。...

1.この記事を書こうと思った背景 『プログラマの数学 第2版｜結城浩』(以下、本書)を読んだ。本書から学んだことを、ここに書き留めておく。 2.目次 はじめに 第1章 ゼロの物語 ―― 「ない」ものが「ある」ことの意味 第2章 論理 ―― trueとfalseの2分割 第3章 剰余 ―― 周期性とグループ分け 第4章 数学的帰納法 ―― 無数のドミノを倒すには 第5章 順列・組み合わせ ―― 数えないための法則 第6章 再帰 ―― 自分で自分を定義する 第7章 指数的な爆発 ―― 困難な問題との戦い 第8章 計算不可能な問題 ―― 数えられない数、プログラムできないプログラム 第9章 プログラマの数学とは ―― まとめにかえて 付録1：機械学習への第一歩 付録2：読書案内 3.本書全体を通しての学びや感想 ものごとの構造を見抜き、一般化する 本書は 「ものごとの構造を見抜き、一般化する」 ことについて、その大切さと方法論について事例を交えて紹介されている。 そのアプローチの一例としては、たとえばものごとを小さくみること、あるいは2分割や再帰性を見出すことなど。 読みやすい印象を抱いたこととそのワケを考える また、とても読みやすい印象を持った。 なぜ、このような印象を抱いたのか？ それは、独自の見解を提示する前に既知の話題や身近な関連事例を提示しているからではないか？と思う。本書は、話し手がもっとも言いたい独自の主張を読み手に伝えるためのエッセンス集であるともいえるかもしれない。 さて、章ごとの読書メモを書いていたのでそちらも共有しよう。(ただし、7章以降を除く。) 4.章ごとの読書メモ 「第1章 ゼロの物語 ―― 「ない」ものが「ある」ことの意味」 「ない」ことを表現する難しさと大切さ。 e.g. 位取り cf. 意外と知らない「ゼロ」の持つ意味と概念―あなたも「ゼロ」という数字から、知的探求、始めてみませんか？－　|ニッセイ基礎研究所 「第2章 論理 ―― trueとfalseの2分割」 物事の論理は、章の副題にも挙げられている 2分割 を意識すること。また、複雑な表現は論理式の考え方を使うとシンプルになることがあるということ。...

1.この記事を書こうと思った背景 チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 (通称、ちいとぽ本）を読み進めていくうちに、以下の疑問を抱くようになった。 Amazon社のピザ２枚ルール、チーム間のコミュニケーションは、インターフェイスを通して行うことというルールは実際にどんなかんじにされているのか？ 気になる。 Teams must communicate with each other through these interfaces. 出所：AmazonのAPI設計方針 (The Bezos Mandate) - Qiita 明確な答えを導き出したわけではないけれども、考えを深めることができたターニングポイントとなったのが、タイトルで触れているインタビュー記事、A Conversation with Werner Vogels - ACM Queue を読んだことだった。また、先にお伝えしておくと新たな疑問も抱くようになったので、インタビュー記事を読んで学んだことと新たな疑問について書き留めておきたい。 インタビュー記事を知ったきっかけ 左記のインタビュー記事を知ったきっかけは、Team Topologies(by Manuel Pais)のキーポイント を読んだことである。この記事は書評記事ではないが、同書の趣旨を理解する上でも大きな助けとなった。“A Conversation with Werner Vogels"をご紹介いただき、ありがとうございました！ 2.“A Conversation with Werner Vogels - ACM Queue"を読んで学んだこと 各サービスの構成メンバーは 利用ユーザーの目的やニーズに応えることにフォーカス するべきだということ ↓の例だと、デベロッパーの関心事はアプリケーションを開発することであり、アプリケーションを開発するために内部的に生成されているURLがどうやって構成されるのか？には関心がないということ。責任共有モデルが各サービス間で徹底されているということ。 Do we see that customers who develop applications using AWS care about REST or SOAP?...

1.この記事で達成したいこと 以下の本を読んだので感想や学びを残す 走ることについて語るときに僕の語ること (文春文庫) | 村上 春樹 納めるために書ききれていないネタを昇華させるか、、 っ 【読書メモ】「走ることについて語るときに僕の語ること」 — gkzz / gakuji tamaki (@gkzvoice) December 30, 2021 2.本書の内容を三行で 優れた小説家には才能があるが、自分にはそういったものはなく、凡人といっていい では、凡人がどうやって小説を書き続けようか？（そもそもなぜ書くことになったのか？も触れている） それは小説を書き続ける集中力とそれを支える体力を養おうと考え、試行錯誤していく、、 3.感想 本書は、特に秀でたわけではないが続けなければならないこととの付き合い方 という普遍的な問いに対して示唆を与えてくれる。自分は先天的な才能を持ち合わせていないという境遇が分かったとしても、集中力や持続力は後天的に身につけることができる。また集中力や持続力は肉体的な衰えと抗うためにも必要だという。そういった集中力や持続力を獲得するためになんとかランニングを始め、トレーニングを続けているが、その難しさと続けるコツ、考え方のヒントが本書では散りばめられている。ぼくにとって胸に響いた箇所は以下の2箇所だ。 Pain is inevitable, Suffering is optional. それが彼のマントラだった。正確なニュアンスは日本語に訳しにくいのだが、あえてごく簡単に訳せば、「痛みは避けがたいが、苦しみはオプショナル（こちら次第）」ということになる。 たとえば走っていて「ああ、きつい、もう駄目だ」と思ったとして、「きつい」というのは避けようのない事実だが、「もう駄目」かどうかはあくまで本人の裁量に委ねられていることである。 走り続けるための理由はほんの少ししかないけれど、走るのをやめるための理由なら大型トラックいっぱいぶんはあるからだ。 僕らにできるのは、その「ほんの少しの理由」をひとつひとつ大事に磨き続けることだけだ。 また、本書は継続する勇気と活力を与えてくれる。文体はみずみずしく、景色が目に浮かぶよう。自己啓発書というより小説を読んでいるかのような気持ちになる。それで何かを続ける難しさと大切さを自身の経験談になぞらえて語られている。ぼくはいわゆるソフトウェア・エンジニアとしてお仕事しているのだけど、本書を読み進めていくうちに、走って、自分をシステムに見立ててパフォーマンスチューニングしたい気持ちに駆られる。（実際やったがなかなか続かない笑。） このようにぼくは本書から何かを続けること、とりわけ自分がそこまで得意ではないことを粘り強く続けることのエッセンスを学んだと思っている。とはいえ、これだけが本書から学ぶことができることではないはず。なんども読み返したい一冊である。

1.この記事で達成したいこと 以下の本を読んだので感想や学びを残す The DevOps ハンドブック 理論・原則・実践のすべて : ジーン・キム, ジェズ・ハンブル, パトリック・ボア, ジョン・ウィリス, 榊原 彰, 長尾 高弘: Japanese Books 2.前提 本題に入る前に、前提として僕のDevOps周りの背景知識について触れようと思う。 2-1.僕のDevOps周りの背景知識 これまで以下の経験をしており、多少なりともDevOpsとはなんぞやという点は抑えているつもりだった。。 toBのWebサービスの運用と開発 Gitlab RunnerとArgo CDを使ったGitOpsなパイプラインの設計と構築 Django制の社内システムの開発 以下のpodcastを聞いたことがあり、Circle CIはまさにDevOpsを体現していると思っている 7. CI/CDとか、CircleCI自体の設計・開発プロセスとか | fukabori.fm ※ 本書を読み進めるまでは、DevOpsとは開発と運用が手を取り合っておこなうこと、あるいは一手に引き受けることだと思っていた しかし、本書を読み進めていくうちに、DevOpsを推し進めるには、それだけで足りないと考えを改めることになる 3.目次 第1部 3つの道 第1章 アジャイル、継続的デリバリー、そして3つの道 第2章 第1の道:フローの原則　ほか 第2部 スタートのための糸口 第5章 最初に手を付けるバリューストリームの選択方法 第6章 バリューストリーム内の作業を理解し、それを可視化して、組織全体に広げる　ほか 第3部 第1の道:フロー改善の技術的実践 第9章 デプロイパイプラインの基礎の構築 第10章 高速で信頼性の高い自動テストの実現　ほか 第4部 第2の道:フィードバックの技術的実践 第14章 問題の可視化と解決のための基礎となる遠隔測定データを作り出す 第15章 遠隔測定データを分析して問題の予測と目標の達成に活かす　ほか 第5部 第3の道:継続的な学習と実験の技術的実践 第19章 日常業務での学習の実現と日常業務への学習の注入 第20章 一部門の発見を全社的な進歩につなげる　ほか 第6部 情報セキュリティ、変更管理、コンプライアンスを統合するための技術的実践 第22章 すべてのエンジニアの毎日の職務として情報セキュリティを位置づける 第23章 デプロイパイプラインを防御する 4....