<p></p>
<h1 id="miketakoxy"><a class="header-anchor-link" href="#miketakoxy" aria-hidden="true"></a> miketakoxy</h1>
<h2 id="likes"><a class="header-anchor-link" href="#likes" aria-hidden="true"></a> Likes</h2>
<h3 id="character"><a class="header-anchor-link" href="#character" aria-hidden="true"></a> Character</h3>
<p>Look <a href="/posts/chara">Characters</a>.</p>
<h3 id="academic"><a class="header-anchor-link" href="#academic" aria-hidden="true"></a> Academic</h3>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__0153066ec75c7" src="https://embed.zenn.studio/card#zenn-embedded__0153066ec75c7" data-content="https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FGraph_theory" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://en.wikipedia.org/wiki/Graph_theory" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://en.wikipedia.org/wiki/Graph_theory</a></p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__ae7c2a54b0911" src="https://embed.zenn.studio/card#zenn-embedded__ae7c2a54b0911" data-content="https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FGraph_coloring" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://en.wikipedia.org/wiki/Graph_coloring" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://en.wikipedia.org/wiki/Graph_coloring</a></p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__5bdfb9e9e184d" src="https://embed.zenn.studio/card#zenn-embedded__5bdfb9e9e184d" data-content="https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FComputational_complexity_theory" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://en.wikipedia.org/wiki/Computational_complexity_theory" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://en.wikipedia.org/wiki/Computational_complexity_theory</a></p>
<h3 id="engineering"><a class="header-anchor-link" href="#engineering" aria-hidden="true"></a> Engineering</h3>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__ef844a344f469" src="https://embed.zenn.studio/card#zenn-embedded__ef844a344f469" data-content="https%3A%2F%2Fspring.io%2F" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://spring.io/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://spring.io/</a></p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__1160b34a7635" src="https://embed.zenn.studio/card#zenn-embedded__1160b34a7635" data-content="https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FDistributed_database" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://en.wikipedia.org/wiki/Distributed_database" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://en.wikipedia.org/wiki/Distributed_database</a></p>
<h3 id="outdoor"><a class="header-anchor-link" href="#outdoor" aria-hidden="true"></a> Outdoor</h3>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__2de1aba60a5b5" src="https://embed.zenn.studio/card#zenn-embedded__2de1aba60a5b5" data-content="https%3A%2F%2Fwww.honda.co.jp%2FFit%2F" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://www.honda.co.jp/Fit/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://www.honda.co.jp/Fit/</a></p>
<h3 id="dramas"><a class="header-anchor-link" href="#dramas" aria-hidden="true"></a> Dramas</h3>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__b22a6d1d56d77" src="https://embed.zenn.studio/card#zenn-embedded__b22a6d1d56d77" data-content="https%3A%2F%2Fwww.fujitv.co.jp%2Fb_hp%2Flegal-high_2013%2F" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://www.fujitv.co.jp/b_hp/legal-high_2013/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://www.fujitv.co.jp/b_hp/legal-high_2013/</a></p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__bf3e9e41ea2e6" src="https://embed.zenn.studio/card#zenn-embedded__bf3e9e41ea2e6" data-content="https%3A%2F%2Fwww.tbs.co.jp%2FVIVANT_tbs%2F" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://www.tbs.co.jp/VIVANT_tbs/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://www.tbs.co.jp/VIVANT_tbs/</a></p>
<h3 id="comedian"><a class="header-anchor-link" href="#comedian" aria-hidden="true"></a> Comedian</h3>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__702e64fa7522" src="https://embed.zenn.studio/card#zenn-embedded__702e64fa7522" data-content="https%3A%2F%2Fgrapecom.jp%2Ftalent_writer%2Fsandwichman%2F" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://grapecom.jp/talent_writer/sandwichman/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://grapecom.jp/talent_writer/sandwichman/</a></p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__f4589c769002b" src="https://embed.zenn.studio/card#zenn-embedded__f4589c769002b" data-content="https%3A%2F%2Fwww.p-jinriki.com%2Ftalent%2Fun-jash%2F" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://www.p-jinriki.com/talent/un-jash/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://www.p-jinriki.com/talent/un-jash/</a></p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__7e9b9bf5da42f" src="https://embed.zenn.studio/card#zenn-embedded__7e9b9bf5da42f" data-content="https%3A%2F%2Fwww.kdashstage.jp%2Fprofile%2Farchives%2F39" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://www.kdashstage.jp/profile/archives/39" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://www.kdashstage.jp/profile/archives/39</a></p>
<h3 id="anime"><a class="header-anchor-link" href="#anime" aria-hidden="true"></a> Anime</h3>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__f19c2ef6bed81" src="https://embed.zenn.studio/card#zenn-embedded__f19c2ef6bed81" data-content="https%3A%2F%2Fkaguya.love" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://kaguya.love" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://kaguya.love</a></p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__1b0b152819cf2" src="https://embed.zenn.studio/card#zenn-embedded__1b0b152819cf2" data-content="http%3A%2F%2Fwww.gundam00.net%2F" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="http://www.gundam00.net/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">http://www.gundam00.net/</a></p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__462cc359771b9" src="https://embed.zenn.studio/card#zenn-embedded__462cc359771b9" data-content="https%3A%2F%2Fmacross.jp%2F" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://macross.jp/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://macross.jp/</a></p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__5d24b600069de" src="https://embed.zenn.studio/card#zenn-embedded__5d24b600069de" data-content="https%3A%2F%2Fgeass.jp%2F" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://geass.jp/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://geass.jp/</a></p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__c246dfb29d4ef" src="https://embed.zenn.studio/card#zenn-embedded__c246dfb29d4ef" data-content="https%3A%2F%2Fssss-movie.net%2F" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://ssss-movie.net/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://ssss-movie.net/</a></p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__db2b9888937d7" src="https://embed.zenn.studio/card#zenn-embedded__db2b9888937d7" data-content="https%3A%2F%2Fconcreterevolutio.com%2F" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://concreterevolutio.com/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://concreterevolutio.com/</a></p>
<h3 id="games"><a class="header-anchor-link" href="#games" aria-hidden="true"></a> Games</h3>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__e17c0ff022889" src="https://embed.zenn.studio/card#zenn-embedded__e17c0ff022889" data-content="https%3A%2F%2F13sar.jp%2F" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://13sar.jp/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://13sar.jp/</a></p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__ed5cebae16c38" src="https://embed.zenn.studio/card#zenn-embedded__ed5cebae16c38" data-content="https%3A%2F%2Fwww.capcom-games.com%2Fmegaman%2Fexe" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://www.capcom-games.com/megaman/exe" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://www.capcom-games.com/megaman/exe</a></p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__e9be87cb3ccb7" src="https://embed.zenn.studio/card#zenn-embedded__e9be87cb3ccb7" data-content="https%3A%2F%2F2236.chloro.space%2F" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://2236.chloro.space/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://2236.chloro.space/</a></p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__9cb6f130a93e3" src="https://embed.zenn.studio/card#zenn-embedded__9cb6f130a93e3" data-content="https%3A%2F%2Fwww.spike-chunsoft.co.jp%2Fai%2F" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://www.spike-chunsoft.co.jp/ai/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://www.spike-chunsoft.co.jp/ai/</a></p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__09fbfef9e7654" src="https://embed.zenn.studio/card#zenn-embedded__09fbfef9e7654" data-content="https%3A%2F%2Fwww.1101.com%2Fmother_project%2Fabout.html" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://www.1101.com/mother_project/about.html" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://www.1101.com/mother_project/about.html</a></p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__a1890c698892" src="https://embed.zenn.studio/card#zenn-embedded__a1890c698892" data-content="https%3A%2F%2Fwww.jp.square-enix.com%2Fparanormasight%2F" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://www.jp.square-enix.com/paranormasight/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://www.jp.square-enix.com/paranormasight/</a></p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__d72a1cfeb174f" src="https://embed.zenn.studio/card#zenn-embedded__d72a1cfeb174f" data-content="https%3A%2F%2Fryu-ga-gotoku.com" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://ryu-ga-gotoku.com" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://ryu-ga-gotoku.com</a></p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__91d2e7cee3987" src="https://embed.zenn.studio/card#zenn-embedded__91d2e7cee3987" data-content="https%3A%2F%2Fwww.jp.square-enix.com%2Fshinsubarashiki%2F" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://www.jp.square-enix.com/shinsubarashiki/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://www.jp.square-enix.com/shinsubarashiki/</a></p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__264aa8c164e15" src="https://embed.zenn.studio/card#zenn-embedded__264aa8c164e15" data-content="https%3A%2F%2Fgundam-vs.jp%2F" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://gundam-vs.jp/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://gundam-vs.jp/</a></p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__57228fc175361" src="https://embed.zenn.studio/card#zenn-embedded__57228fc175361" data-content="https%3A%2F%2Fwikipedia.org%2Fwiki%2FPower_Pro_Kun_Pocket" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://wikipedia.org/wiki/Power_Pro_Kun_Pocket" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://wikipedia.org/wiki/Power_Pro_Kun_Pocket</a></p>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__4dbf5fbd1f1a" src="https://embed.zenn.studio/card#zenn-embedded__4dbf5fbd1f1a" data-content="https%3A%2F%2Fwww.nintendo.co.jp%2Fngc%2Fg8mj" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://www.nintendo.co.jp/ngc/g8mj" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://www.nintendo.co.jp/ngc/g8mj</a></p>
<h3 id="virtual-youtuber"><a class="header-anchor-link" href="#virtual-youtuber" aria-hidden="true"></a> Virtual YouTuber</h3>
<p><span class="embed-block zenn-embedded zenn-embedded-card"><iframe id="zenn-embedded__c92ea4afd8e41" src="https://embed.zenn.studio/card#zenn-embedded__c92ea4afd8e41" data-content="https%3A%2F%2Fwww.nijisanji.jp%2F" frameborder="0" scrolling="no" loading="lazy"></iframe></span><a href="https://www.nijisanji.jp/" style="display:none" target="_blank" rel="nofollow noopener noreferrer">https://www.nijisanji.jp/</a></p>


みけたこ (miketakoxy) の好きなもの

JetBrains IDEのAI機能の無料枠で爆速で欲しいツールを作ってみる Advent Calendar 2025

Magic: The Gatheringのカードを検索するMCPサーバーを建ててみた

Agent2Agent プロトコルを試して見えてきたGoogleの戦略

## 概要

オライリーの「プロダクションレディマイクロサービス」

https://www.oreilly.co.jp/books/9784873118154/

を読んだので、内容やノウハウをメモする。

## 全体感

UberのSREがプロダクションレディなマイクロサービスはどのようなものかについてチェックリスト的にまとめた書籍。

全体としては書籍の体は保っているものの、本当にチェックリストのようだった。

付録には本当にチェックリストという名目で箇条書きで掲載されており、確かにこれが網羅できていればプロダクションレディと言えそう。

一方で、これを全てやるのは至難の業。少なくとも日本国内だとこんなしっかりとしている企業は無いのではないかというレベル。

総じてイデア的に使うものであり、必要十分条件ではないと感じた。

(この書籍の内容が出来ていればプロダクションレディかもしれないが、プロダクションレディなサービスがこの書籍の内容を満たすとは限らない。)

## ノウハウ

本番対応の原則は以下の8つの項目である。

1. 安定性
2. 信頼性
3. スケーラビリティ
4. 耐障害性
5. 大惨事対応
6. パフォーマンス
7. 監視
8. ドキュメント

### 安定性

安定して動く、バグがない、のようなものではない。

CI/CDが整っているか、開発プロセスはわかりやすいか、など開発者目線での安定感が要点。

### 信頼性

テストは十分か、完璧なステージング環境があるか、カナリアリリースが行われているか、など。

### スケーラビリティとパフォーマンス

その名の通り。これらはまとめて語られていた。ボトルネックの明確化やキャパシティプランニングが適切に行われているかなど。

### 耐障害性と大惨事対応

これらもまとめて語られていた。単一障害点が無いこと、起こりうる大惨事が明確になっていること、障害対応手順の標準化など。

### 監視

ロギング、アラーティング、オンコールなどが適切に行われていること。ダッシュボードが整備されていること。

面白かったのは以下。

> オンコールランブックは、半分寝ている開発者でも難なくたどれるように書かれていなければなりません。

Susan J. Fowler. プロダクションレディマイクロサービス (p.233). Kindle 版. 

確かにその通りなのだが、「半分寝ている」という表現がちょっと面白かった。そんなランブックを書くことが果たしてできるのかという疑問は残るものの、やはり理想としては間違いない。

### ドキュメント

> 本番対応のよいドキュメントの目標は、サービスについての知識を一元的に管理するリポジトリを作って、メンテナンスすることです。共有すべき知識は、サービスについてのありのままの事実と、サービスが何を行い、組織全体でどのような位置を占めるかについての組織的な理解の両方です。そのため、ドキュメントが貧弱だという問題は、ドキュメント（事実）の欠如と理解の欠如の2つの下位問題に分けることができます。これら2つの下位問題を解決するには、すべてのマイクロサービスを通じてドキュメントを標準化するとともに、マイクロサービスについての理解を共有するための組織的な構造を用意する必要があります。

Susan J. Fowler. プロダクションレディマイクロサービス (p.224). Kindle 版. 

ドキュメントに関する項目があるのが非常に意外だった。他の項目は当たり前な部分が多いが、この項目に関しては新たな示唆が得られた気がする。

他にも引用しておくと以下のようにも書かれていた。

> 多くの開発者は、リポジトリ内にREADMEファイルを置くかコードにコメントをばらまいておけば、ドキュメントとして十分だと思っています。READMEファイルは必要不可欠であり、すべてのマイクロサービスのコードには適切なコメントが含まれていなければなりませんが、READMEは本番対応のドキュメントではなく、コメントはチェックアウトしてコード中を探し回らなければならなければ役に立ちません。

Susan J. Fowler. プロダクションレディマイクロサービス (p.226). Kindle 版. 

ドキュメントの有無は本当に大きい。「コードを読めばわかる」なんて表現は、個人的には場当たり的にコードを書く能力、時間しかありませんと言っているようなものだと思う。

例えばマイクロサービスとして利用している他チームのAPIを呼ぶ際に適切なタイムアウト値が知りたいとする。そんなとき「コードを読んでください」なんて言えない。API仕様書などの明示できるドキュメントが無ければ、利用者全員に対して個別に回答しなければいけないかもしれない。

全体として大規模なサービスになればなるほどマイクロサービスの利用者も増えるので、大手ほどこの問題が発生する可能性が高いはず。この書籍は全体的にそういう対象について議論しているように見える。

## まとめ

「プロダクションレディマイクロサービス」について感想やノウハウをまとめた。

誰かの参考になれば幸いです。

「プロダクションレディマイクロサービス」を読んだ


## 概要

中村昇著の「ウィトゲンシュタイン『哲学探究』入門」をAudibleで読んだので感想をまとめる。

https://www.audible.co.jp/pd/%E3%82%A6%E3%82%A3%E3%83%88%E3%82%B2%E3%83%B3%E3%82%B7%E3%83%A5%E3%82%BF%E3%82%A4%E3%83%B3%E3%80%8E%E5%93%B2%E5%AD%A6%E6%8E%A2%E7%A9%B6%E3%80%8F%E5%85%A5%E9%96%80-%E3%82%AA%E3%83%BC%E3%83%87%E3%82%A3%E3%82%AA%E3%83%96%E3%83%83%E3%82%AF/B0BTLR8BNQ

## 感想

### ウィトゲンシュタインの思想

ウィトゲンシュタインというと、

> 語り得ぬものについては沈黙せねばならない

とか、

> 語の意味とはその使用である

とかが有名だが、全体的に「答えが出ない問題を考えても仕方なくね？ワロタ」みたいな感じがあって、それは考え方が似ていて共感があった。

### 自分との比較

ただ「語り得ぬもの」とか「語の意味」とかそういうものへの諦観が強いように見えた。

自分は広義の意味では決定論者で、所詮有限なこの世の全要素を記述すれば全てを記述可能なはず、という立場。

したがって、この世のatomicな要素を全て物理的に記述すれば確率的に「語り得ぬもの」は無くなるはず、と思っている。この点では少し見解が違った。

まあその上での有限なステートマシン的なものとして人間を見ている自分の方が、諦観が強い可能性もあるが……。

### 書籍自体の感想

また、解説者の思想が（入門書なので当然だが）出過ぎていたので、原著を読みたくなった。

自分の思想とウィトゲンシュタインの思想が似ていたのか、ウィトゲンシュタインから引用された文は全て非常にしっくり来たので、こういう変なやつはきっと入門書のターゲットではないんだろう。

そのせいで、途中で聴く気が無くなってきてしまった。

とはいえ解説自体はとても良いもので、英語とドイツ語の違いについての解説などの補足情報が非常に丁寧だった。

普段そういうことを考えてない人にはとても良い。 

自分も非常に参考になったことは明記しておく。

### Audibleについて

散歩中に本を読みたくてAudibleを使ってみたが、非常に良かった。

まず画面を目の前に持っていなくても良い。これだけで要件としては満たされていた。

倍速にできるのも個人的には非常にマッチしていたし、読み手の声も聞き取りやすい。

ラインナップが変な自己啓発本やビジネス書ばかりなのが残念で、もう少しちゃんとした本が増えるともっと使いやすいのにもったいないサービス。

## まとめ

総じてもう少しウィトゲンシュタインに踏み込みたくはなった。

厨二病のまま大真面目に成長してしまった自分としては、似た思想の人間を常に探している節があって、ウィトゲンシュタインは比較的近いかもしれない。

次は哲学論考かな。

「ウィトゲンシュタイン『哲学探究』入門」を読んだ

## 概要

このブログのドメインを含む2つのドメインをお名前.comからGoogle Domainsに移行した。

## 移行理由

### お名前.comのUI/UXが悪い

異論がある方はいないと思う。それくらいお名前.comの使い勝手は悪い。

どのメニューがどこにあるのかが一見してわからないし、ログインするたびにドメイン期限を更新しろとうるさい。

あまりにも体験が悪く、サーバー等を一緒に借りるのでなければお名前.comでドメインを取るのはおすすめできない。

### メールが有料

お名前.comではメール転送やメールサーバのレンタルは有料となっている。後者については別に良いのだが、前者についてはあまり好ましくは無い。

この点、Google Domainsならばメールの転送が無料で行える。以下の記事が非常に参考になった。

https://www.value-domain.com/media/domain-usage-mail/

お名前.comでもメールは年間1000円/ドメイン程度ではあるが、それでも無駄なコストはカットしておきたいだろう。

## 移行後の感想

非常に快適である。まず不要なメニューが存在しないため、UIがシンプルになっている。

さらに、天下のGoogleのサービスである。日本の一企業であるGMOに比べれば信頼性は非常に高まっているだろう。

自分がドメインに対してそこまでリッチなサービスを求めていないかもしれないが、現状でも必要十分な機能が存在しており、Google Domainsで不足を感じる人はまずいないと思っている。

## まとめ

ドメインをお名前.comからGoogle Domainに移行した感想を述べた。

今後ドメインを取得する際はGoogle Domainsを使っていきたいし、他者にもおすすめできるサービスだと感じている。

皆さんのドメイン管理サービス選びの参考になれば幸いである。

ドメイン管理サービスをお名前.comからGoogle Domainsに移行した

## 概要

「ソフトウェアテストをカイゼンする50のアイデア」

http://www.eijipress.co.jp/book/book.php?epcode=2085

という本を読んだので感想についてメモする。

なお、かなり斜め読みしてしまったので内容が気になる方は自分で読んでみるのをおすすめします。テストに詳しく無いのであれば読む価値はあると思います。

## 得られたノウハウ

- 抜け漏れを防ぐために他者とテストについて考えよ
- 定量化に努めよう
- Given-When-Thenの順序は必ず守ろう
- BDDでは以下の3つが重要となる
  - 仕様
  - 受け入れテスト
  - ドキュメント
- そのために、以下の3つを均衡させなければならない
  - 仕様の簡潔さ
  - カバレッジの完全性
  - ドキュメントの統一性
- テストの優先順位をつけるにはAttribute Component Capabilityマトリクスが便利
  - 理想的なACCマトリクスは「時間とお金があればどんな人でもテストできる」程度で抽象化する
- テストコードは書くためではなく読むために最適化せよ


## 感想

正直抽象的なことが多くて読むのが苦痛だった。良い内容は書いてあると思うが、当たり前というか既知の内容も多く、それが抽象度高く書かれているという印象。なかなか実行可能で具体的なノウハウまでもっていくのは難しかった。

ただし、テストで思い悩むことがあった際にこの本に立ち返ると答えが書いてあるかもしれないので、薄く内容を覚えておいて読み返せるようにするのも手かもしれない。

「ソフトウェアテストをカイゼンする50のアイデア」を読んだ

## 概要

「SOFT SKILLS ソフトウェア開発者の人生マニュアル」

https://www.amazon.co.jp/SOFT-SKILLS-E3-82-BD-E3-83-95-E3-83-88-E3-82-A6-E3-82-A7-E3-82-A2-E9-96-8B-E7-99-BA-E8-80-85-E3-81/dp/4296000500/

という自己啓発本を読んだので、感想とノウハウをメモする。

## ノウハウ

- エンジニアもセルフプロデュースをせよ。
- セルフプロデュースに最も良いのはブログである。ブログをやれ。
- 給与は全て投資し、帰ってくるお金のみで生活せよ。そうすれば投資が終わった時にはリタイアできる。

## 感想
YouTubeやブログで著名になり不動産投資でも成功したソフトウェアエンジニアである著者の体験が元になった本。

正直あまり参考になる部分はなかった。セルフプロデュースが重要なのは初めからわかっていたし、それ以外についてもよくある自己啓発本の域を出ない。

例えば「お金に働かせてFIREしよう」といった内容で不動産投資を勧めている章もあった。ソフトウェア開発者に向けた本としては珍しいトピックだし間違ってはないのかもしれないが、そんなことを言われても行動に移せるノウハウとしてはほぼ無いに等しかった。

この本で得られたのはセルフプロデュースが重要ということのセカンドオピニオンを得たことくらいである。

「SOFT SKILLS ソフトウェア開発者の人生マニュアル」を読んだ

## 概要

技術書展13で公開されていた「Nuxt3 + Firebase 捨てられるWebアプリケーション設計」

https://techbookfest.org/product/m4KEUzinvmSZhPSaWYHetH?productVariantID=jC3wRJsbgwuJJQ05JtumXe

を読んだので、感想をまとめる。

以前こちらの記事を読んで著者に興味を持ったというのと

https://shiodaifuku.io/articles/17638219-f1ef-406c-b20c-7f426d61b2af

設計部分を読みたいという動機で購入しており、メインパートと思しきNuxt3およびFirebaseの部分は大胆に斜め読みしたので、意図と違う解釈をしているかもしれない。

## 第1部
### 第1章 SOLID
よく言われているSOLID原則についてまとめられていた。わかりやすくまとまっていたし、Vueとの関連も述べられていたので使いやすいかもしれない。

https://ja.wikipedia.org/wiki/SOLID

### 第2章 結合度と凝集度
こちらもよく言われている結合度と凝集度についてまとめられていた。同様にVue (特にComposition API) との関連も述べられていた。

https://ja.wikipedia.org/wiki/%E5%87%9D%E9%9B%86%E5%BA%A6

https://ja.wikipedia.org/wiki/%E7%B5%90%E5%90%88%E5%BA%A6

Vue3.0のComposition APIの威力についてはReact hooksと似たようなもんだろうくらいで深く気にしていなかったが、旨味についての理解が深まった気がする。 

私はVue2.0の経験があり、そのときは経験が浅いのもあってスパゲッティコードと化してしまっていた。Composition APIの影響で書きやすくなっているというのもあり、機会があれば使ってみたいと思った。

### 第3章 契約による設計: Design by Contract

契約プログラミングについてまとまっていた。

https://ja.wikipedia.org/wiki/%E5%A5%91%E7%B4%84%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0

Nuxtのどこで契約を意識する必要があるのか等もまとまっており、後々おそらく実例もあるのだろう。

## 第2部, 第3部
コンポーネント分割の基準等についても書かれていたが、 VueおよびNuxt, Firebaseの割合が大きいので割愛。序盤の設計原則に従ってNuxtアプリを作成するという内容となっていたようである。

## まとめ
個人的には設計部分で既知の内容が多く得られる物が少なかった。 ただ、これは私が不純な目的で本書を購入したからで、Vue, Nuxt, Firebaseというスタックで何かを作りたい人には良い本だと思う。

また、技術書展の本は他にも1,2冊購入したがどれもレイアウトや構成が凄くちゃんとした本になっていて驚いた。私もそのうちなんか書いて出してみたいと思っていたがハードルが上がってしまった。

「Nuxt3 + Firebase 捨てられるWebアプリケーション設計」を読んだ

## 概要

「ソフトウェア見積もり 人月の暗黙知を解き明かす」

https://www.amazon.co.jp/%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E8%A6%8B%E7%A9%8D%E3%82%8A-%E4%BA%BA%E6%9C%88%E3%81%AE%E6%9A%97%E9%BB%99%E7%9F%A5%E3%82%92%E8%A7%A3%E3%81%8D%E6%98%8E%E3%81%8B%E3%81%99-%E3%82%B9%E3%83%86%E3%82%A3%E3%83%BC%E3%83%96-%E3%83%9E%E3%82%B3%E3%83%8D%E3%83%AB-ebook/dp/B00KR96M6K

を半分程度読んだのでノウハウについて章ごとにメモする。

残り半分を読んだ段階で記事を更新する予定。

## 第1部 見積もりの考え方
### 第1章 見積もりとは

- 「見積もり」「ターゲット」「コミットメント」の違いを意識する
  - 見積もり：そのままの意味
    - 「この機能の実装は何人日」
  - ターゲット：実現したいビジネス上の目標
    - 「何日までにこの機能を提供したい」
  - コミットメント：機能を一定のレベルで期日までに納品するという約束
    - 「何日までにこの機能を提供します」
- 見積もりと計画の違いを意識する
  - 見積もりは正確性が重要
  - 計画は結果が重要
  - 偉い人にターゲットを達成するための計画を聞かれているのに見積もりを単に答えてはいけない
    - 「このプロジェクトは何人月？期限は３ヶ月なんだ」
    - 「見積もってみたところ５ヶ月かかります」
    - 「ふざけるな！」
  - 開発と期日どちらが優先かどうか尋ねる
- 良い見積もりとは偉い人の意思決定に寄与する見積もりのこと

### 第2章 見積もり能力のチェック

- 直感で「90％確か」な見積もりは、実際には「30%確か」
  - なので直感で90%とか言ってはいけない
- 見積もりなんて幅があって当然。無理に狭めようとしない

### 第3章 正確な見積もりの価値

- 意図的に過小に見積もることはすべきではない
  - 過大見積もりよりも深刻な被害が起きる
  - では過大にすれば良いかというとそうでもなく、それなりに大きくしてあとは計画とコントロールで対処せよ

### 第4章 見積もり誤差はなぜ起きる？

- 見積もり期間を増やしても見積もりの不確実性は上がらない
  - プロジェクト自体があやふやなのではどんなに頑張っても上がらない
  - 見積もり期間を増やすのではなく、要件定義や設計を固めることでしか上がらない
- 休暇、病欠、トレーニング、ミーティング等は必ず発生する。そのためのゆとりをもたせる
- 開発者の見積もりはすでに必ず楽観的であるので削ってはいけない
- 見積もりに「コントロールノブ」を持たせてはいけない
  - コントロールノブとは見積もりに入れる主観的判断のこと
  - 見積もりの客観性と共に正確性も落ちる
- 即興の見積もりはしない
  - たった15分の見積もりでさえもっと正確になる

## 第2部 見積もりの技法の基礎

### 第7章 数えて、計算して、判断する

- できるときはまず何かを数える
- 数えられない場合にのみ計算する
- 計算すらしないのは最終手段

### 第9章 専門家の判断

- タスクで分解して見積もるときは長くても2日程度の粒度にする


## 感想

「技術者の見積もりは常に楽観的」というのはその通りだと思った。
幅がある見積もりの中で最小の部分を提出する傾向があるような気がしているし、
実際過小に見積もる圧力があるということも書かれていた。

一方で、数えるだけの方がよほど正確に見積もれるというのは不思議だった。さすがにコード行数で数えるのはどうかと思うが。

過去の開発にかかった工数と関連データの保存および可視化が出来ていないと不可能な手法ではあるので、これらの重要性はかなり高い。

生産性向上とか言っておいて生産性を測る指標を可視化していないなんてことがザラにある状態では正確な見積もりなんて望めないということかもしれない。

「ソフトウェア見積もり」を読んだ

## 概要

オライリーから出ている 「レガシーコードからの脱却」

https://www.oreilly.co.jp/books/9784873118864/

を読んだので、重要な章を抜き出してノウハウをメモする。

## 第1部
### 1章 何かが間違っている

ほとんどのソフトウェアは作り方や保守の仕方を間違えている。

ウォーターフォールは最後にまとめてリリースするため一か八かの博打。

### 3章 賢人による新しいアイデア

アジャイルはウォーターフォールよりは良い。

一方で、アジャイルをしているチームも技術プラクティスを上手く使えていないために期待した利益が得られないでいる。

## 第2部
### 4章 9つのプラクティス

1. やり方より先に目的、理由、誰のためかを伝える
2. 小さなバッチで作る
3. 継続的に統合する
4. 協力し合う
5. 「CLEAN」コードを作る
6. まずテストを書く
7. テストでふるまいを明示する
8. 設計は最後に行う
9. レガシーコードをリファクタリングする

### 9章 プラクティス5 「CLEAN」コードを作る
うまくカプセル化されたソフトウェアはアウトサイドインで設計することによって得られる。

- アウトサイドインプログラミング
  - コンシューマの観点で機能を設計する
  - サービスが何をやっているかを示す名前をつける
  - どう動くかは隠す
- インサイドアウトプログラミング
  - 問題を小さな塊に分解し、それらを縫い合わせる
  - 最初に実装してしまうと全体が見えなくなる

「知らぬが仏」という言葉はソフトウェアにおいては常に真である。

CLEANなコードを作る。

- C: Cohesive (凝集性)
- L: Loosely coupled (疎結合)
- E: Encapsulated (カプセル化)
- A: Assertive (断定的)
- N: Nonredundant (非冗長)

名前は説明的、能動的、肯定的なものにし、結果的にシステムがどう変化するのかを反映する。

### 10章 プラクティス6 まずテストを書く

多くのテストを書きすぎたり、実装依存のテストを書いたりするとTDDは上手く行かない。

ふるまいを表すのに必要なテストだけを書く。

「ユニットテスト」のユニットとはふるまいの単位であり、メソッド、クラス、モジュール等ではない。

### 12章 プラクティス8 設計は最後に行う

最初のアーキテクチャレベルの設計というよりはコードの詳細設計的な話。

テストを書いた後にリファクタリングで設計を変えていく方が良い。

### 13章 プラクティス9 レガシーコードをリファクタリングする

コードを変更する場合は一緒にレガシーコードをリファクタリングする。

## 感想
プラクティスの大半はテストが必要というのもあって、上手いテストを書くことが非常に重要だと感じた。

Google本でも書かれていたが、やはりユニットテストだからといってメソッド単位でテストしたり、ホワイトボックステストを書くのは良くない。

最後に設計せよというプラクティスがあったが、そのためにはホワイトボックステストがあってはならないはずである。

この辺りの考えに対する後押しが得られたのが良かった。

「レガシーコードからの脱却」を読んだ

## 概要

オライリーから出ている 「Googleのソフトウェアエンジニアリング」

https://www.oreilly.co.jp/books/9784873119656/

を読んだので以下のような内容について章ごとにメモする。

- 主張されている内容の概要、
- そこから得られたノウハウ、
- その他の感想。

なお、全て個人的な解釈に則って記事を書いており、ノウハウ抽出に不要な部分は大胆にカットしているので、本の内容の詳細は実際に読んで把握することをお勧めします。

## 個人的に印象に残った章

- 2章
- 7章
- 12章

## 第1部 主題

### 1章 ソフトウェアエンジニアリングとは何か

#### 概要

プログラミングとはコードを生産する行為、ソフトウェアエンジニアリングとはそのコードを保守することまでを含んだ時間的な広がりを持つ行為。

対象が違うのだから、プログラミングとソフトウェアエンジニアリングに同じベストプラクティスが通用すると一般に仮定するのは無理。

#### ノウハウ

以下の**Hyrumの法則**というものが紹介されている。

> あるAPIに十分な数のユーザーがいるとき、APIを作った者自身が契約仕様として何を約束しているかは重要ではない。
> 作られたシステムが持つあらゆる観察可能な挙動に関して、それに依存するユーザーが出てくるものである。

したがって、API仕様書に書かれていない変更をする際にも、ユーザーへの聞き取り調査の工数は含めておくのが望ましい。

#### 感想

他にも、スケールする仕組みをつくろう、手戻りを無くすよう早期に問題を発見しよう、とかそんなことが書かれていた。

## 第2部 文化

### 2章 チームでうまく仕事をするには

#### 概要

チームで仕事をするには謙虚と信頼が大事だ、等の一般的によく言われることが書かれていた。

#### ノウハウ

以下の標語が紹介されている。
> 早期に失敗し、高速に失敗し、頻繁に失敗せよ

これを実践するために、一人で黙々と作業するのは止める。誰かに頻繁にフィードバックを求める。

#### 感想

「バス係数」の概念も紹介されている。これは何人のメンバーがバスで轢かれたらプロジェクトが失敗するかという指標。

バス係数が低いと、真面目な人ほど他の人に迷惑がかかるからという理由で休みづらくなる気がする。
それで無理矢理プロジェクトを回すのは絶対によろしくないので、迷惑を顧みないほどの豪胆さが欲しい。
自分は休めるし、プロジェクトが回らなければ上にも人手の必要性が伝わるしで一石二鳥である (実行可能なノウハウかどうかは諸説あるので感想部分に書いた)。

### 3章 知識共有

#### 概要

心理的安全性は大事だとか、知識共有を率先してやることに報酬制度を設けよとかの一般論と、Google内でのレビューフローの事例等が書かれていた。

#### ノウハウ

特になし。

#### 感想

Googleの事例自体は参考になるが、銀の弾丸は無いとも書かれており、結局は自分の組織に合った方法論を構築する必要がある。
そういった意味ですぐに実行可能なノウハウは無かった。

### 4章 公正のためのエンジニアリング

#### 概要

バイアスは常にある、多様性が大事、といったことが書かれていた。
GoogleのAIが黒人とゴリラを間違えて問題になった件とか、その類の話。

#### ノウハウ

特になし

#### 感想

それはそう。くらいの感想だった。

### 5章 チームリーダー入門

#### 概要

リーダーとしてどんなことをするべきかが書かれていた。

#### ノウハウ

章自体がノウハウ集となっているので多すぎて書ききれない。
最も重要だと感じたのは「サーバントリーダーシップ」というキーワードで、可能な限りチームメンバーに仕事を移譲し、
自身はチームメンバーが円滑に仕事をすることができるように仕える、というもの。

#### 感想

リーダーになる機会がもしあれば読み直したいが、社内政治が混沌としていたりするとそう上手くは行かないんだろうなと感じた。

### 6章 スケールするリーダー

#### 概要

**スケールする**リーダー (リーダーのリーダー等) としてどんなことをするべきかが書かれていた。

#### ノウハウ

これも章自体がノウハウ集となっているので多すぎて書ききれない。
最も重要だと感じたのは「いつでも立ち去れ」という標語。結局リーダーがボトルネックになったら意味ないよねということで、
自分が立ち去っても問題なく動くチームにするべきで、具体例として1週間以上休暇を取っても問題なく機能するか等が挙げられていた。

#### 感想

5章と同じ。

### 7章 エンジニアリング生産性の計測

#### 概要

生産性を計測する際の注意点が書かれていた。

#### ノウハウ

ゴール、シグナル、メトリクスを明確に区別する (GSMフレームワーク)。

- ゴール: 達成するべき目標。
- シグナル: ゴールを達成したことを知る手段。必ずしも計測可能である必要はない。
- メトリクス: シグナルの計測可能な代替品。

メトリクスを計測する前に、それを計測した後どう行動するのかを考えるべき。

生産性のゴールにはトレードオフがあるため、一部だけを計測するのはよくない。
QuANTSのゴールを全て計測することで、網羅的に計測ができる。

| 頭文字 | 英語                           | 日本語      |
|-----|------------------------------|----------|
| Qu  | **Qu**ality of the code      | コード品質    |
| A   | **A**ttention from engineers | エンジニアの注意 |
| N   | I**n**tellectual complexity  | 知的複雑性    |
| T   | **T**empo and velocity       | テンポと速度   |
| S   | **S**atisfaction             | 満足       |

#### 感想

生産性向上はよくある組織目標だと思うが、ちゃんと考えたことは無かった。
特にGSMの区別はちゃんとしてみたい。

## 第3部 プロセス

### 8章 スタイルガイドとルール

#### 概要

コーディングスタイルガイドやコードフォーマッター大事だよねくらいのことが書かれていた。

#### ノウハウ

特になし。

#### 感想

そこまで新しい知見はなかったので感想も簡素。

### 9章 コードレビュー

#### 概要

コードレビューにおける恩恵や、Googleでの実施方法などが書かれていた。

#### ノウハウ

特になし。

#### 感想

よくあるプルリクエストのベストプラクティス (変更は小さくしろ、レビュアーのことを考えろ、できることは自動化しろ等) とほぼ変わらない印象だった。

### 10章 ドキュメンテーション

#### 概要

ドキュメントがいかに大事かということ、ドキュメントの管理について、Googleでの実例等について書かれていた。

#### ノウハウ

ドキュメントにはオーナーを付ける。
オーナーがドキュメントの変更をレビューして反映たり、最新化する責任を持つ。

ドキュメントはVCSで管理し、ソースコードと同じ管理方法にする。

#### 感想

Googleでもドキュメントについては改善途中であるらしい。ドキュメントが乱立して陳腐化するのはどこでもよくあることで、それを避けるためにオーナーを付けるのは必須だと感じた。

### 11章 テスト概観

#### 概要

テストは大事だくらいのことが書かれていた。

Googleでのテストは「単体」や「結合」等の文脈では区別されず、テスト規模のみにより大中小に分類されるとのこと。

| テスト規模 | 主な制約 | その他 |
|--|------------------------------|----------|
| 小 | 単一プロセス | sleep禁止、I/O操作禁止、ブロッキング禁止 |
| 中 | 単一マシン (複数プロセス) | localhost意外へのアクセスが禁止 |
| 大 | 複数マシン | 実質制約なし |

#### ノウハウ

破綻してほしくないものは全部テストすべき。
ビヨンセルールと呼ばれる標語に従っておく。

> 「そんなに好きならそいつにテスト付けときゃよかったのに」

#### 感想

概観というだけあってノウハウ的なところは薄かった。

### 12章 ユニットテスト

#### 概要

ユニットテストの範囲、保守性について、書き方についてが書かれていた。

脆いなテスト (無関係な要因でたびたび失敗してしまうテスト) を避けることや、テストにロジックを入れない等の一般的なことが多かった。

#### ノウハウ

脆いテストを避けるために変化しないテストを目指す必要がある。
そのためには*公開API経由で*テストすることが重要である。
公開APIの定義とは、以下の通りである。

> 我々が文章の文脈で「公開API」と述べる場合に実際に言及している対象とは、
> ユニットコードのオーナーであるチームの外部にいるサードパーティに対し、そのユニットが公開しているAPIだ。

これに従えば、WEBのAPIをチーム外に公開している場合、そのAPI内部の実装をメソッド単位でテストする*べきではない*。
そのようなテストは外部との契約に関係がないリファクタリング等で失敗するようになる。つまりは脆いテストである。

#### 感想

メソッド単位でテストするなというのは衝撃があったが、納得感もあった。

これに関しては別記事にしたいと思っている。

### 13章 テストダブル

#### 概要

テストダブルとはテスト時に使われるモックやスタブのこと。

テストダブルの種類や利用法についてまとまっていた。

#### ノウハウ

テストではなるべくテストダブルは使わず、本物の実装を使う方が良い。
テストの実行時間高速化等のメリットと、テストダブルを使用した際のリスク等のデメリットをトレードオフし、適切な場合にのみテストダブルを利用するべきである。

#### 感想

メソッドやクラス単位でテストしようとするとどうしても依存が複雑な場合はモックだらけになってしまう気がする。
前章に従ってメソッド単位でテストせず公開API経由でテストする場合には有効なノウハウに感じた。

### 14章 大規模テスト

#### 概要

大規模テストを実施する場合の考え方について書かれている。

#### ノウハウ

> 優れた設計には、リスクならびにそのリスクの軽減のための大規模テストを見極めるテスト戦略が含まれている。

つまり、設計の時点で起こりうるリスクを考え、それに対する大規模テストについて考えを巡らせておくべきである。

#### 感想

大規模なテストは辛いことが多いが、それでもメリットと天秤に掛けるべきだよねという当たり前なことに気付かされた。

大規模テストを作成する際にもう一度読み返したい。

### 15章 廃止

#### 概要

ソフトウェアの廃止は構築よりも難しいことが多いが、それでも保守コストと天秤に掛けて実施すべきということと、
その際に注意すると良いことについて書かれていた。

#### ノウハウ

特になし。

#### 感想

廃止についてはGoogleだからといって特別良いノウハウがあるわけではなく、結局難しいままなんだなと感じた。

## 第4部 ツール

### 16章 バージョンコントロールとブランチ管理

#### 概要

バージョンコントロールの概説、ブランチ管理のバッドノウハウ (長寿命のdevブランチはNG) 、リポジトリ間の依存関係について書かれていた

#### ノウハウ

特になし。

#### 感想

Googleのモノレポについて少し書かれていたが、なかなか真似しづらいので、もしモノレポ環境になったら読み直そうと思った。

### 17章 Code Search

#### 概要

Googleのコード閲覧、検索のための社内ツールであるCode Searchについて書かれている。

#### ノウハウ

特になし。

#### 感想

社内ツールについては得られる物が少なそうだったので斜め読みした。

### 18章 ビルドシステムとビルド哲学

#### 概要

ビルドシステムの一般的な事柄について書かれていた。

#### ノウハウ

特になし。

#### 感想

一般人はよくあるビルドツールでビルドすることになると思うのでここも読み飛ばした。
ビルドツールを作る側になったら読み直したいと思う。

### 19章 GoogleのコードレビューツールCritique

#### 概要

Googleのコードレビューツールのための社内ツールであるCritiqueについて書かれていた。

#### ノウハウ

特になし。

#### 感想

ここも社内ツールの話なため読み飛ばした。

### 20章 静的解析

#### 概要

静的解析の概説とGoogleの社内ツールであるTricorderについて書かれていた。

#### ノウハウ

特になし。

#### 感想

ここも社内ツールのため省略した。
静的解析も既製品を使うことがほとんどだと思うので、作る側になったら読み直したい。

### 21章 依存関係管理

#### 概要

依存関係をいかにして管理するか、およびセマンティックバージョニングについて書かれていた。

#### ノウハウ

特になし。

#### 感想

これも依存関係管理ツールを作る側になったら読み直したいと思った。
セマンティックバージョニングの限界や最小バージョン更新戦略というものを使うと良いということも紹介されていたが、そこまで役に立つものでもなかったので感想欄に。

### 22章 大規模変更

#### 概要

Google全社で実施されるような大規模変更について書かれていた。

#### ノウハウ

特になし。

#### 感想

Google規模で大規模一斉変更を指揮するような機会は一生来ない可能性の方が高いので斜め読みした。

### 23章 継続的インテグレーション

#### 概要

CIについて、テスト実施のタイミング、GoogleにおけるCIについて書かれていた。

#### ノウハウ

マージ前に実施するべきテストとマージ後に実施するべきテストがある。

開発の高速化のために、マージ前は信頼性が高く高速なテストのみを実施し、マージ後は中大規模テストのような時間がかかり多少不安定でも許容されるテストを実施するべきである。

#### 感想

ノウハウには入れていないが以下のような文言があった。

> CIはアラートである。

アラートはSLOが健全であることを担保し、CIはビルドが健全であることを担保する。
この対比は新しく、まだ模索中のようだが、一理あるなという気はした。

### 24章 継続的デリバリー

#### 概要

CDやリリースに関するベストプラクティスが書かれていた。

#### ノウハウ

> 問題を早期に切り分けられるように、あらゆる機能をフラグで保護すべきだ。

> 各リリースのリスクを低減しつつ、市場に投入するまでの時間を最小化するために、早期かつ頻繁に小さなバッチでリリースすべきだ。

#### 感想

機能フラグに関してはサービス全体の観点では同意するが、分業しているとなかなか難しいような気もした。

一方でリリースを早期に小さなバッチで行う方がより安全であるというのは同意できる。

### 25章 サービスとしてのコンピュート

#### 概要

PaaSやCaaS、サーバーレス等のコンピュートリソースについて書かれていた。

#### ノウハウ

特になし。

#### 感想

組織のコンピュートリソースを選択するような立場に無いので流し読みしたが、特に目新しいことは書かれていなかったように思う。

## まとめ

Googleは世界トップの企業で、その内部について良くまとまっていました。

興味がある人は是非本を読んでみてください。

「Googleのソフトウェアエンジニアリング」を読んだ

# Blue Biscuit Privacy Policy

## 日本語

第三者に個人を特定できる情報を提供することはありません。
個人情報の管理には最新の注意を払い、以下に掲げた通りに扱います。

### サポート時

サポートメールに、問題解決のための端末種類、OSバージョン等が本文として記述されます。
個人を特定できる情報は一切送信されません。

### データ解析

アプリの利便性向上のため、匿名で個人を特定できない範囲で最新の注意を払い、アクセス解析をしております。
例えばアプリのクラッシュ時にどんな原因でクラッシュしたかを匿名で送信して、バグの素早い修正に役立たせております。

### 免責事項

利用上の不具合・不都合に対して可能な限りサポートを行っておりますが、利用者が本アプリを利用して生じた損害に関して、開発元は責任を負わないものとします。

## English
We do not provide information that can identify individuals to third parties. We pay the utmost attention to the management of personal information and handle it as described below.

### During Support
In support emails, details such as device type and OS version are described in the main text for problem resolution. No information that can identify an individual is transmitted.

### Data Analysis
To improve the convenience of the app, we conduct access analysis with the utmost care, ensuring it's within a range that cannot identify individuals. For instance, in the event of an app crash, we anonymously transmit information about the cause to aid in swift bug fixes.

### Disclaimer
While we provide support as much as possible for any issues or inconveniences during use, the developer will not be held responsible for any damages incurred by users while using this app.

Blue Biscuit Privacy Policy

# Puppy Buddy Privacy Policy

## 日本語

第三者に個人を特定できる情報を提供することはありません。
個人情報の管理には最新の注意を払い、以下に掲げた通りに扱います。

### サポート時

サポートメールに、問題解決のための端末種類、OSバージョン等が本文として記述されます。
個人を特定できる情報は一切送信されません。

### データ解析

アプリの利便性向上のため、匿名で個人を特定できない範囲で最新の注意を払い、アクセス解析をしております。
例えばアプリのクラッシュ時にどんな原因でクラッシュしたかを匿名で送信して、バグの素早い修正に役立たせております。

### 免責事項

利用上の不具合・不都合に対して可能な限りサポートを行っておりますが、利用者が本アプリを利用して生じた損害に関して、開発元は責任を負わないものとします。

## English
We do not provide information that can identify individuals to third parties. We pay the utmost attention to the management of personal information and handle it as described below.

### During Support
In support emails, details such as device type and OS version are described in the main text for problem resolution. No information that can identify an individual is transmitted.

### Data Analysis
To improve the convenience of the app, we conduct access analysis with the utmost care, ensuring it's within a range that cannot identify individuals. For instance, in the event of an app crash, we anonymously transmit information about the cause to aid in swift bug fixes.

### Disclaimer
While we provide support as much as possible for any issues or inconveniences during use, the developer will not be held responsible for any damages incurred by users while using this app.

Puppy Buddy Privacy Policy

## はじめに

自分でも忘れてしまうので好きなキャラをまとめておきます。

## 好きなキャラ

### 女性

#### 能美クドリャフカ

https://dic.pixiv.net/a/%E8%83%BD%E7%BE%8E%E3%82%AF%E3%83%89%E3%83%AA%E3%83%A3%E3%83%95%E3%82%AB

結局ナンバーワン

おかげでロシア語の読み書きができる

#### フレイア・ヴィオン

https://dic.pixiv.net/a/%E3%83%95%E3%83%AC%E3%82%A4%E3%82%A2%E3%83%BB%E3%83%B4%E3%82%A3%E3%82%AA%E3%83%B3

健気なところが好き

#### 石川梨子 (パワプロクンポケット)

https://dic.pixiv.net/a/%E7%9F%B3%E5%B7%9D%E6%A2%A8%E5%AD%90

緑髪は全員好きだが自分の中で起源にして頂点

#### イチゴ (ダーリン・イン・ザ・フランキス)

https://dic.pixiv.net/a/%E3%82%A4%E3%83%81%E3%82%B4%28%E3%83%80%E3%83%AA%E3%83%95%E3%83%A9%29

どこがいいのかわからないとよく言われる

#### 小鳥遊六花

https://dic.pixiv.net/a/%E5%B0%8F%E9%B3%A5%E9%81%8A%E5%85%AD%E8%8A%B1

アニメ後半の真面目展開がとても好きなんだがネット上だと評判が悪くて悲しい

#### ライザリン・シュタウト

https://dic.pixiv.net/a/%E3%83%A9%E3%82%A4%E3%82%B6%E3%83%AA%E3%83%B3%E3%83%BB%E3%82%B7%E3%83%A5%E3%82%BF%E3%82%A6%E3%83%88

見た目

#### 樋口円香

https://dic.pixiv.net/a/%E6%A8%8B%E5%8F%A3%E5%86%86%E9%A6%99

見た目

#### ユキ (龍が如く)

https://dic.pixiv.net/a/%E3%83%A6%E3%82%AD%28%E9%BE%8D%E3%81%8C%E5%A6%82%E3%81%8F%29

見た目

#### りんね (プリティーリズム)

https://dic.pixiv.net/a/%E3%82%8A%E3%82%93%E3%81%AD

giftの世界が開けていく感じがたまらなく好き

#### フリーナ (原神)

https://dic.pixiv.net/a/%E3%83%95%E3%83%AA%E3%83%BC%E3%83%8A

見た目

#### 天雨アコ (ブルーアーカイブ)

https://dic.pixiv.net/a/%E5%A4%A9%E9%9B%A8%E3%82%A2%E3%82%B3

見た目

#### 黒川あかね

https://dic.pixiv.net/a/%E9%BB%92%E5%B7%9D%E3%81%82%E3%81%8B%E3%81%AD

闇が見えるところが好き

#### 中野五月

https://dic.pixiv.net/a/%E4%B8%AD%E9%87%8E%E4%BA%94%E6%9C%88

メガネ

#### 伊井野ミコ

https://dic.pixiv.net/a/%E4%BC%8A%E4%BA%95%E9%87%8E%E3%83%9F%E3%82%B3

白銀会長をからかい始めるあたりから好き

### 男性

#### 直枝理樹

https://dic.pixiv.net/a/%E7%9B%B4%E6%9E%9D%E7%90%86%E6%A8%B9

声は原作派

#### 乾貞治

https://dic.pixiv.net/a/%E4%B9%BE%E8%B2%9E%E6%B2%BB

データだけじゃなくてパワーも手に入れるところが技術者的に好き

#### 先導アイチ

https://dic.pixiv.net/a/%E5%85%88%E5%B0%8E%E3%82%A2%E3%82%A4%E3%83%81

闇落ち含めて

#### アレルヤ・ハプティズム

https://dic.pixiv.net/a/%E3%82%A2%E3%83%AC%E3%83%AB%E3%83%A4%E3%83%BB%E3%83%8F%E3%83%97%E3%83%86%E3%82%A3%E3%82%BA%E3%83%A0

2期好きだったのでもっと活躍して欲しかった

#### 風見雄二

https://dic.pixiv.net/a/%E9%A2%A8%E8%A6%8B%E9%9B%84%E4%BA%8C

このゲームから得られるものが多すぎる