<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__e865a69f3661d" src="https://embed.zenn.studio/card#zenn-embedded__e865a69f3661d" 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__0a0ac51fadbb2" src="https://embed.zenn.studio/card#zenn-embedded__0a0ac51fadbb2" 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__e4060a0cd2317" src="https://embed.zenn.studio/card#zenn-embedded__e4060a0cd2317" 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__48abb74d4e1ec" src="https://embed.zenn.studio/card#zenn-embedded__48abb74d4e1ec" 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__1ea78b6414c0c" src="https://embed.zenn.studio/card#zenn-embedded__1ea78b6414c0c" 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__eb39c37a6ba8a" src="https://embed.zenn.studio/card#zenn-embedded__eb39c37a6ba8a" 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__db03445d3aed6" src="https://embed.zenn.studio/card#zenn-embedded__db03445d3aed6" 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__1a449654fc12b" src="https://embed.zenn.studio/card#zenn-embedded__1a449654fc12b" 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__94c6f4ab028c" src="https://embed.zenn.studio/card#zenn-embedded__94c6f4ab028c" 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__ddb612a6686e7" src="https://embed.zenn.studio/card#zenn-embedded__ddb612a6686e7" 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__f3fd51751b27e" src="https://embed.zenn.studio/card#zenn-embedded__f3fd51751b27e" 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__7da2a8a7d3f8d" src="https://embed.zenn.studio/card#zenn-embedded__7da2a8a7d3f8d" 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__f7b9fcf3cc842" src="https://embed.zenn.studio/card#zenn-embedded__f7b9fcf3cc842" 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__460e09982a31f" src="https://embed.zenn.studio/card#zenn-embedded__460e09982a31f" 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__b8601e13af676" src="https://embed.zenn.studio/card#zenn-embedded__b8601e13af676" 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__a404a4b4d5984" src="https://embed.zenn.studio/card#zenn-embedded__a404a4b4d5984" 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__473830b6b9081" src="https://embed.zenn.studio/card#zenn-embedded__473830b6b9081" 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__82c608c3f5da9" src="https://embed.zenn.studio/card#zenn-embedded__82c608c3f5da9" 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__e4f718421285d" src="https://embed.zenn.studio/card#zenn-embedded__e4f718421285d" 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__e82f071c3c497" src="https://embed.zenn.studio/card#zenn-embedded__e82f071c3c497" 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__b8b19bf36cc5a" src="https://embed.zenn.studio/card#zenn-embedded__b8b19bf36cc5a" 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__c804154071944" src="https://embed.zenn.studio/card#zenn-embedded__c804154071944" 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__4abf6a7415b95" src="https://embed.zenn.studio/card#zenn-embedded__4abf6a7415b95" 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__379b9b6a414a2" src="https://embed.zenn.studio/card#zenn-embedded__379b9b6a414a2" 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__eeb325272fd54" src="https://embed.zenn.studio/card#zenn-embedded__eeb325272fd54" 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__749c815b68a77" src="https://embed.zenn.studio/card#zenn-embedded__749c815b68a77" 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__69d2dde7fa692" src="https://embed.zenn.studio/card#zenn-embedded__69d2dde7fa692" 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__6e6feee64379c" src="https://embed.zenn.studio/card#zenn-embedded__6e6feee64379c" 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__27a434403209" src="https://embed.zenn.studio/card#zenn-embedded__27a434403209" 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

## 概要

技術書典にいい加減参加したく、こんなものを作った。

https://github.com/miketako3/teckbook-template

TechBoosterのRe:VIEWテンプレートを改変したものになる。Webエンジニア目線では使いやすいかもしれない。

## 技術スタック

- Re:VIEW
  - 誤解を恐れずにいえばLaTexのラッパー
  - 技術書を描きやすいらしい
  - markdownっぽい形式の.reファイルを書いてPDFに変換できる
- VSCode
  - Re:VIEWの補完ができる拡張機能がある
  - 本当はIntelliJが良かったが…流石にプラグインを作りたくは無い
  - devcontainerは便利ではある
- Dev Containers
  - VSCodeの機能
  - Dockerを使って開発環境を構築する
  - Re:VIEWのDockerイメージが公式に配布されているのでそれをベースにすれば楽ちん
  - ということで元々のテンプレートからそのまま持ってきた
- GitHub Actions
  - 元々のテンプレートではCircleCIで校閲、Github ActionsでPDF作成としていたが、慣れや使い勝手もあり全てGitHub Actionsに変更した
  - Github前提となるので、GitLabなど用のファイルは全て削除した
- textlint
  - 文章の校閲ツール
  - スタンダードな技術だと思っているので採用した
  - PR時に自動的に実行される
- reviewdog
  - textlintの結果をPRコメントに表示してくれる
  - さすがにコメントが無いと使いづらいので採用した

## 感想

これでやっと書けるわけだが、書くまでに手間がかかりすぎる……。

もっと楽に書ける環境があると参入障壁が下がるのになーとなる。

自動校閲とか自動バージョニングとかをいい感じに入れたSaaSがあって、技術書典とか印刷会社とかとシームレスに連携できたら最強な気がする。

## 参考

https://reviewml.org/ja/

https://review-knowledge-ja.readthedocs.io/ja/latest/

https://github.com/TechBooster/ReVIEW-Template

https://zenn.dev/karaage0703/articles/52be7d25f7d76b

https://zenn.dev/b0b/articles/reviewdog_textlint_ga_tested

技術書典に向けて執筆環境を整えた

ヘルスケアデータをGrafanaで見たくない…？〜健康 Reliability Engineering〜

【第2回】生成AIなんでもLT会 主催振り返り (@miketako3)

## 概要

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

## はじめに

昨年10月に[ドメイン管理サービスをお名前.comからGoogle Domainsに移行した](/posts/domain-service-change)ばかりだったが、なんとGoogle Domainsが事業売却されるとのこと……

https://www.itmedia.co.jp/pcuser/articles/2306/16/news083.html

仕方ないので、今回はCloudflareに移ることにした。ちょうどWorkers等も話題になっていたし。

## 移行時のTips

### 移行作業

特に何も言うことはない。Cloudflare側のサイトとしてドメインを登録しておけば、後は案内に従ってネームサーバーの変更、移管を進めるだけで良い。

あまりにも簡単だった。本当にこういうのは嬉しい。

### ERR_TOO_MANY_REDIRECTS

移管後、ブラウザでドメインにアクセスすると、ERR_TOO_MANY_REDIRECTSというエラーが発生した。

オリジンがhttpsであるにも関わらず、CloudflareのSSL設定がFlexibleになっていたことが原因だった。オリジンにはhttpでアクセスして戻されてを繰り返していたらしい。

Fullにすることでオリジンまでhttpsで通信するように設定できるので、それで解決した。

![Cloudflareの設定画面](/domain-service-change-2/img.png)

## 移行後の感想

Google Domainsと比べると以下の不満はある。

- Google Cloudとの連携がない
- ドメイン管理以外の機能が多い

まあ前者は仕方ないし、後者はそれはそれでメリットもあるので良しとした。

## まとめ

ドメインをGoogle DomainsからCloudflareに移行した。

正直Google Domainsが事業売却されるのは寝耳に水で、今後何を信じてサービスを選べば良いかわからなくなる……。

上手くいかなかったサービスを手放すのはGoogleのお家芸ではあるが、そんなに採算取れてなかったんでしょうかね？

Cloudflareも今は波に乗っているが、いつかはGoogleと同じ道を辿るのかもしれない。そういう意味では日本企業のサービスを使う方が安定性は高いのかも。

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

ドメイン管理サービスをGoogle DomainsからCloudflareに移行した

## 概要

オライリーから出ている 「ソフトウェアアーキテクチャ・ハードパーツ」

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

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

と言いたいところだが、重要な部分が多すぎるのでこの記事では書きやすい部分だけを抜き出している。

書籍の内容を拾いきれているとは到底言えないので、是非読んでもらいたい。

ある程度システム設計に明るく、アーキテクチャに課題を抱えている人にはぴったりな内容になっていると感じた。

## 1章 「ベストプラクティス」がないとどうなる？

全ての解決策はトレードオフである。

> アーキテクトは、自分の問題に対する「銀の弾丸」を探し求めてはならない。

アーキテクトの問題はそれぞれユニークなため、ベストプラクティスが存在しない。

だからこそ「ハード」パーツである。

- 難しい問題
- 堅い、システムの土台となる部分

> 決して最善のアーキテクチャを狙ってはいけない。むしろ、少なくとも最悪でないトレードオフの組み合わせを狙おう。

多くのアーキテクチャにおいて、データこそが全てである。

アーキテクチャデシジョンレコード（Architecture Decision Records：ADR）（https://adr.github.io）を記入せよ。

アーキテクチャ統制のため、アーキテクチャ適応度関数を設計、運用せよ。

## 2章 ソフトウェアアーキテクチャにおける結合の見分け方

結合の定義

> 一方の変更が他方の変更を引き起こす可能性がある場合、ソフトウェアシステムの2つの部分は結合している。

結合を発見、分析し、トレードオフを評価せよ。

アーキテクチャ量子の定義

> アーキテクチャ量子とは、高度な機能的凝集、高度な静的結合、同期／非同期による動的結合を持つ、独立してデプロイが可能なアーティファクトを指す。アーキテクチャ量子の一般的な例には、あるワークフロー内の整ったマイクロサービスなどがある。

これはすなわち、データベースを共有しているアプリケーションは全て1つのアーキテクチャ量子である。

## 4章 アーキテクチャの分解

モノリスからサービスベースアーキテクチャを経てマイクロサービスへ移行していく上で、2つのアプローチが紹介されている。

- コンポーネントベース分解
  - まずはリファクタリングし、モジュールを分けていく。
  - 分けられたモジュールをサービスに切り出す。
- 戦術的フォーク
  - まるっと別アプリケーションとしてコピーして立て、それぞれ1部の機能しか使っていない状態にする。
  - その後、不要な機能をリファクタリングによって削除していく。
  - コンポーネントベース分解と比べて
    - メリット
      - 事前の分析が不要なので作業開始が早い
      - コードは抽出するより消す方が簡単 (と書かれていたが本当か？)
    - デメリット
      - 不要なコードを消す努力が必要
      - ロジックは汚いまま

## 6章 業務データの分解

データベースを分けるか？分けないか？もトレードオフである。

データを分解する要因として以下のようなものがある。

- 変更制御
  - カラムの変更等の影響が多岐にわたる
- コネクション管理
  - 1つのデータベースだけを使うとコネクション数の管理が難しい
- スケーラビリティ
  - コネクション数
  - 容量
  - スループット
  - パフォーマンス
- 耐障害性
  - 1つのデータベースだけを使うとデータベースが単一障害点となってしまう
- アーキテクチャ量子
  - 1つのデータベースだけを使うと1つのアーキテクチャ量子となってしまう (つまり独立してデプロイできない、等)
- データベース種別の最適化
  - 1つのデータベースだけを使うと1つの保存方法だけしか使えない (つまりデータ特性ごとに最適な選択肢が取れない)

逆に、データを統合する要因としては以下のようなものがある。

- データ関係
  - 密結合な外部キー等があるか？
- トランザクション
  - 単一のトランザクション単位が必要か？

モノリスなデータベースを分解するには5段階のプロセスを踏むと良い。

1. 分析し、ドメインを特定する
2. ドメインごとにテーブルを割り当て、移動する
3. コネクションをドメインごとに分離する
4. スキーマをそれぞれのデータベースに移動する
5. コネクションを切り替える

## 7章 サービスの粒度

マイクロサービスの粒度を大きくするか？小さくするか？もトレードオフである。

粒度を小さくする要因としては以下のようなものがある。

- サービスの範囲と機能
  - 凝集性が高い状態になっているか？
- コード変動率
  - 一部のコードだけ変更頻度が高くないか？
- スケーラビリティとスループット
  - 一部だけスケールする必要があるか？
- 耐障害性
  - 一部の故障で全体が故障してしまわないか？
- セキュリティ
  - 一部だけ高いセキュリティが必要か？
- 拡張性
  - どの程度拡張されるか？

粒度を大きくする要因としては以下のようなものがある。

- トランザクション
  - サービスをまたいだトランザクションが必要か？
- ワークフローとコレオグラフィ
  - サービス同士がやりとりする必要はあるか？
- 共有コード
  - サービス同士がコード共有の必要はあるか？
- データ関係
  - データは分解できるか？

## 9章 データの所有権と分散トランザクション

サービス間で共有するデータが存在するとき、どちらのサービスが所有権を持つのか、どのように共有データを管理するのかをトレードオフによって決めなければならない。

分散トランザクションはACID特性をサポートしないため、代わりに結果整合性を検討せよ。

## 10章 分散データアクセス

所有していないデータにサービスが読み取りアクセスするためには様々な方法があり、その間にもトレードオフがある。

- サービス間通信パターン
  - サービス間がWEB API等で通信してDBを隠蔽する
- 列スキーマレプリケーションパターン
  - 非正規化する
- レプリケーションキャッシュパターン
  - 分散キャッシュする
- データドメインパターン
  - 愚直に一緒にDBを見てしまう

## 11章 分散ワークフローの管理

分散システムどうしを調整する方法については基本的には2種類あり、トレードオフがある。

- オーケストレーション
  - 調整役を別途立てる
- コレオグラフィ
  - 最初のサービスが調整役となる

## 12章 トランザクショナルサーガ

通信、整合性、調整についてそれぞれ2パターンあり、組み合わせると合計8パターンのサーガ (アーキテクチャの大別) がある。

| パターン名       | 通信  | 整合性   | 調整         | 結合度   | 複雑さ   | 応答性/可用性 | スケーラビリティ |
|-------------|-----|-------|------------|-------|-------|---------|----------|
| エピックサーガ     | 同期  | アトミック | オーケストレーション | とても高い | 低い    | 低い      | とても低い    |
| 伝言ゲームサーガ    | 同期  | アトミック | コレオグラフィ    | 高い    | 高い    | 低い      | 低い       |
| おとぎ話サーガ     | 同期  | 結果整合性 | オーケストレーション | 高い    | とても低い | 中程度     | 高い       |
| 時間旅行サーガ     | 同期  | 結果整合性 | コレオグラフィ    | 中程度   | 低い    | 中程度     | 低い       |
| ファンタジーサーガ   | 非同期 | アトミック | オーケストレーション | 高い    | 高い    | 低い      | 低い       |
| ホラーストーリーサーガ | 非同期 | アトミック | コレオグラフィ    | 中程度   | とても高い | 低い      | 中程度      |
| パラレルサーガ     | 非同期 | 結果整合性 | オーケストレーション | 低い    | 低い    | 高い      | 高い       |
| アンソロジーサーガ   | 非同期 | 結果整合性 | コレオグラフィ    | とても低い | 高い    | 高い      | とても高い    |

## 13章 コントラクト

ハードパーツとしてのコントラクトの定義は以下である。

> アーキテクチャの部品が情報や依存関係を伝えるために使用するフォーマット。

コントラクトとして例えば以下の様なものがあり、トレードオフがある。

- 堅い
  - 例
    - gRPC
  - メリット
    - 型
    - バージョニング
    - 検証が用意
    - ドキュメント
  - デメリット
    - 密結合
- 緩い
  - 例
    - JSON
  - メリット
    - 疎結合
    - 進化しやすさ
  - デメリット
    - 型がない
    - コンシューマ駆動契約等の適応度関数が必要

帯域幅は無限だと思うな。

## 15章 独自のトレードオフ分析を構築する

MECEに分析せよ。

技術の過度な売り込みを避けよ。

> 何かを伝道する立場をとってはいけない。トレードオフに立ち返ろう。

> 銀の弾丸を追い求めるのではなく、トレードオフを分析するスキルに磨きをかけることで、アーキテクトは組織に真の価値を提供できるのだ。

## まとめ

アーキテクトというふわっとした分野において地に足ついた良い本だった様に感じた。

全てはトレードオフである、というのは自分も読む前から感じていたことではあったため、裏付けが取れて嬉しい気持ちになった。

そして、そのトレードオフをこれでもかと投げつけてくる本書は実際にアーキテクチャを考える上で非常に参考になるだろう。

最近「マイクロサービスって間違いだったんじゃね？」等が話題になったりもしたが、そういうことに振り回されず淡々とトレードオフを分析できるエンジニアになりたい。

「ソフトウェアアーキテクチャ・ハードパーツ」を読んだ

## 概要

「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 ソフトウェア開発者の人生マニュアル」を読んだ

## はじめに
私は2月末ごろからうつ病で休職していました。現在も休職中ではありますが、だいぶ体調も回復し復職も近づいてきているので、このタイミングで記事を書こうと思います。

こうした内容を公言するかどうかは悩みました。周りの人にはうつ病になりそうに無い人と思われている感覚があって、それを破壊してしまうのが嫌だったというのもあります。

ただ、うつ病なんだよねと言うことの面倒臭さよりも言わないことによる不快感が大きかったというのもありますし、公開することで誰かの助けになるかもしれないというのもあってこの記事を書くことにしました。

## 周りの人に伝えたいこと

今まで公言していなかったので当然ですが、普段と変わらず接してもらえたのがとても良かったと思っています。

今後も配慮はいらないので特に変わらず接してください。うつ病に関することは聞かれたくないとかそういうことは特にないので、普通に話に上げてもらっても良いです。聞かれれば何でも答えます。

以下長文になるので気になる方だけ読んでください。

## 経緯
コロナ禍によるリモートワークや自粛の影響で体調を崩したりもしましたが、これまでなんとかやってきていました。

しかし、2021年後半くらいから徐々に無気力感や倦怠感、体の痛みが大きくなってきました。何をするにも入り込めていない感じというか、ストレスが発散できていない感覚がありました。

2022年1月末頃に産業医に相談しましたが、その時はまだ仕事が全くできないというほどでもなかったため相談のみで終わりました。

その直後、業務的にしんどい時期が続き、とどめを刺されたように体調が悪化していきました。そして産業医に二度目の相談をしたところ心療内科を勧められ、そのまま2月末には休職となりました。急に休職したのでいろんな人に迷惑をかけたと思います。

休職後１ヶ月はほぼ寝て過ごし、3ヶ月程度経ったときには、疲れやすさが残るものの日常生活をするだけなら問題ないレベルとなりました。

そこからさらに３ヶ月程度、仕事ができる集中力を取り戻すために使い、現在ではそれなりに仕事ができそうな体調まで回復しています。

## そもそもうつ病とは何なのか

情報ソースはほぼネットのみなので詳しくは専門のソースを見てほしいですが、ある程度は自分で調べて理解したつもりです。

### 概要

うつ病とは気分障害の一種で、うつ状態 (いわゆるうつ病っぽい状態) が2週間以上続いている場合につけられる診断です。原因はよくわかっていないようですが、脳内のセロトニン等が不足したことによって起きるという説がありますし、少なくとも脳に病的な何かが起きて発症したと考えられています。ただの精神的な問題ではないということです。

いわゆる新型うつ等と呼ばれることもある適応障害とは区別され、原因を切り離した時にうつ状態ではなくなるのが適応障害で、そもそも原因が定かではないのがうつ病という理解です。(なので、適応障害の場合は業務は無理でも休日は元気だったりするわけです)

### 症状

症状としては精神的なものとお肉体的なものがあり、例えば以下のようなものがあります。肉体的な症状があるということは知らない人には意外なんじゃないかなと思います。

- 精神的
  - 気分が落ち込む
  - 意欲が無くなる
  - 集中力が無くなる
  - 不安になる
- 肉体的
  - 頭痛
  - 腰痛
  - 肩こり
  - 睡眠障害
  - 食欲不振や過食

### 診断

うつ病や適応障害の診断は操作的診断というものによって行われます。わかりやすく言えば心理テストみたいなやつです。

いまのところそれらを正確に検査するのは難しく、症状によって診断するしかありません。そのため、医者によらない客観性のある診断をするために心理テストの規格を作っているみたいなことのようです。

以下の記事によれば、うつ病の9割弱がICDという診断基準、残りがDSMという診断基準で診断されています。

http://www.kokoronomori.jp/2014/05/21/post-53

つまり、ICDやDSMを覚えれば誰でもうつ病の診断を得られる可能性があるわけです。これは、本当にうつ病に悩む人にとってはあまり良いことではないと思います。自分の症状はただの甘えなんじゃないかという気持ちになってしまいます。まあ本当に患っている人はそんな勉強する余裕は無いわけですが、ライフハック的に使用する心無い人によって偏見に晒される可能性を考えると早く検査法が確立してほしいと願うばかりです。

### 治療

うつ病の治療で重要なのは以下の4つです。

- 休養
- 環境調整
- 薬物治療
- 精神療法

そのため、精神科や心療内科でうつ病と診断されると、休職の診断書が出たり薬が処方されたりするわけです。

なお、精神科や心療内科、クリニックはほぼ同じ意味です。名付けが自由なのでばらつきがあるというだけです。

精神科で薬物治療と聞くとなんだか怖いイメージがありますが、最近は副作用が比較的少ない薬もありますし、イメージほどのヤバい薬が処方されることはあまり無いんじゃないかなと思います。

また、治療の効果は徐々に現れていきます。風邪等と一緒である瞬間からいきなり全快とはならないので、最初は寝たきりだとしても徐々に活動量が上がっていくと思います。そのため、うつ病だからといって何もできないわけではないです。これも世間一般のイメージと乖離があるんじゃないかなと思います。

### お金周り
休職中は一般的には傷病手当金というものが健康保険から支給されます。金額としては月給の2/3程度です。 また、企業によってはさらに所得保障がある場合があり、月給の2/9程度が追加で支給されます。ボーナスはありませんし、支給までにかなりタイムラグがあるとはいえ、この期間は働かずにお金がもらえるわけですね。

働かずにお金がもらえるなんて最高じゃないかと私も休職以前は思っていたのですが、やってみるとそんなに良いものではありません。

そもそも大半の期間は遊んだり出来る余裕が体調的にありませんし、精神的にも遊んでいられるような状態ではありませんでした。本来感じる必要は無いのですが、ズル休みをしているような感覚になります。

かなりの図太さがないと悠々自適に過ごすのは難しいでしょうし、そのような人はうつ病にならなそうです。

さらに、治療が進んでいないと思われれば不要に薬が増やされるわけで、副作用があることを考えればあまりやりたくはありません。

結局は真面目に治療に専念するのが一番良いわけで、そういう意味では安心して休める傷病手当金という制度は良いものだと思います。

## 自分の場合
### 症状

私の休職直前の症状は以下のようなものでした。

- 食欲不振
  - 朝昼はほぼ抜き、晩も少量のみが多かったです。
- 睡眠障害
  - 寝付くのに数時間かかり、夜中に目が覚めるような状態でした。
  - うつ病が原因かはわかりませんが寝汗がひどかったです。
- 倦怠感
  - 頭が重いという表現がこんなにも適切なのかと感動するくらいには頭が重かったです。
  - 業務後の倦怠感は酷く、ほぼ寝ていました。
- 集中力の欠如
  - 集中できるのはせいぜい1日1時間程度でした。
- 気分の落ち込み
  - 死んだ方がマシ的な考えもありました。
  - よくわからなくなり涙が出たことも一度だけですがありました。
  - 何をしても気分がよくなる感じがしませんでした。
- 体の痛み
  - 右上腹部の違和感や痛みが特にひどかったです。
    - これについては随分前からあって超音波検査もしましたが異常はありませんでした。
  - 右足の付け根の痛みもありました。
- 肩こり
  - これはデスクワークなら誰でも起こるのでうつ病によるものかどうかはわかりませんが、少なくとも現在はそこまで酷くはありません。

気分が悪くてやる気が出ないだけとかであれば個人的には休職するようなものではないのですが、集中したくてもできないという状態で流石に業務に支障がありました。

### 処方

私が処方された薬は主に抗うつ剤と睡眠導入剤です。

抗うつ剤はざっくり言えばセロトニンを増やすもので、長期間服用してじわじわ効果が出るものです。抗うつ剤は効果がない場合もあるようですが、私はそれなりには効いたような気がします。

睡眠導入剤はまあ睡眠薬です。これはかなり効果があり、寝つきもよくなり朝まで眠れるようになりました。酷かった寝汗もほぼなくなりました。

心療内科や精神科は話を聞いてもらう場所といったイメージを持っている方もいるかもしれませんが、実際にはほぼほぼ症状に応じた薬が処方されるだけです。

### 原因
少し上で書いたように原因を特定するのは難しいですが、これなんじゃないかというものはいくつかあります。詳細については書けない部分が多いですが以下に挙げます。

- 業務系
    - 慢性的なシステム障害の対応
        - [ファントムバイブレーションシンドローム](https://ja.wikipedia.org/wiki/%E5%B9%BB%E6%83%B3%E6%8C%AF%E5%8B%95%E7%97%87%E5%80%99%E7%BE%A4)
    - 深夜待機
    - 業務上のプレッシャー
    - [燃え尽き症候群](https://ja.wikipedia.org/wiki/%E7%87%83%E3%81%88%E5%B0%BD%E3%81%8D%E7%97%87%E5%80%99%E7%BE%A4)
- 生活系
    - リモートワークによる運動不足
    - 睡眠の質の低下

私に関して言えば人間関係で困ったりしたことはなく、業務自体が嫌というわけでもありませんでした。また、見かけ上の残業時間もかなり少ない方でした。

一方で、残業時間では見えない負荷もあり、特に常にシステム障害の連絡が携帯に来るというのはかなり負担が大きかったんじゃないかなと思っています。

主治医の説明でも「医学的に疲れが溜まっている状態でしょう」という旨を言われていたので、疲労が溜まっていたことは間違いないです。

### 回復するまでにしたこと

#### ~ 1ヶ月
休職後１ヶ月はほぼ寝ていました。抗うつ剤は効くまでに少なくとも2週間から１ヶ月はかかるということもあり、死んだような生活をしていました。食欲も最初は全く無かったのですが、薬が朝食後だったのでゼリーだけ何とか食べるといった食生活をしていました。

#### 1 ~ 3ヶ月
2週間から１ヶ月すると多少は活動ができるようになりました。初めは1~2時間家事をしてまた寝るという過ごし方でしたが、だんだん体調が戻っていきました。最大MPが日に日に上がっていくような感覚でした。

この頃は活動が出来るようになってくるのもあって焦りが出てくる時期でした。いっそのこと転職してやろうとか思って色々やってはみましたが、予定を積むと目に見えて体調が悪化しました。そこで転職は止めてやっぱり回復に専念することにしました。

仕事もそうですが転職なんてものはかなりのエネルギーを使うもので、それが出来るほど回復はしていなかったということです。

体力もかなり落ちていたので、回復のためにネットでオススメされていた散歩等をしたりしていました。

また、多少なら遊んだりできる余裕は生まれたので、ゲームしたりもしていました。転職のようなプレッシャーはないのでマシではありましたが、結局集中力を使うので長時間するのは難しかったですが。

#### 3ヶ月 ~ 現在
ある程度日常生活は遅れるようになったので、この時期は仕事に戻ることを想定してリハビリ的なことをしました。

個人開発してみたいものは何個かあったのでそれを作ってみたりして、徐々に活動量を上げていきました。 このブログもその一つです。本題と逸れるので詳細は割愛しますが、Next.jsとReactとTailwindでゴリっと書いています。

また、体力をつけるためにラジオ体操とかリングフィットアドベンチャーをしていたり、集中力をつける的な意味合いもあってポーカー (ノーリミットテキサスホールデム) にハマりました。誰かやりましょう。

最初は長時間活動するのは難しかったですが、現在ではフルタイムの定時くらいまではなんとか作業できるようになりました。

## まとめ
うつ病で休職したことや自分のうつ病に対する理解について書いてみました。

うつ病に関する情報は色々なところにありますが、信用に足る情報なのかがいまいちわかりづらいです。

この記事も同様ではありますが、それでも誰かの役に立つことを願っています。

また、冒頭にも書きましたが、私には普通に接してください。特にうつ病関連がタブーであるということもないです。

よろしくお願いします。

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

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

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

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

## 概要

「最高の脳で働く方法」

https://d21.co.jp/book/detail/978-4-7993-2470-7

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

## ノウハウ
- 演出家を育てる
  - 演出家とは、自分の脳内のタスクを管理するもう一人の自分のようなイメージ
  - そのためには自分のメンタルプロセスを自覚する力を高める必要がある
  - マインドフルネス的にこの瞬間に意識をじっと集中させることがトレーニングになる
- 自分の演出家を働かせる
  - 集中する必要があるときは他の物事を極力排除する
    - 携帯の電源を切る等
  - ひらめきが必要な場合は全てを舞台から排除し、脳の微弱な波長を感じられるようにする
  - 脳の情動は接近と回避の2種類がある
    - 接近は良い状態
    - 回避は悪い状態だが、野生本能的にこちらになりやすい
  - ストレスを感じている時は回避になるため演出家を働かせることは難しい
    - そのような状況では以下を行うと良い
      - ラベリング（端的な言葉への言い換え）
      - 再評価（プラス思考で考え直す）
  - 他者とうまく協調するためには他者に接近状態にさせると良い
    - 問題ではなく解決にフォーカスする
    - よくやられているフィードバックは効果が薄い
      - ステータスが上の人間にフィードバックをもらうというだけで脅威に感じる
    - 相手のメンタルプロセスに対して質問することで相手から閃きを引き出す

## 感想
脳のリソースを舞台と演出家というメタファーで伝えている本。

舞台とは脳のメモリを指し、舞台上の役者は脳が注意を向ける事柄を表す。

どの役者をどのように配置するかを管理するのが演出家で、演出家に素晴らしい働きをさせることが全てにおいて重要なことであるという主張がされている。

著者がコンサル出身らしくコンサル仕事術的な面があり、求めていた科学的アプローチとは違った。

一方で言わんとすることはわかるし、演出家というメタファーでイメージしやすくなっているのは良かった。

「最高の脳で働く方法」を読んだ

## 概要

オライリーから出ている 「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のソフトウェアエンジニアリング」を読んだ

# Puppy Buddy Term

## 日本語

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

### はじめに

本利用規約（以下「本規約」）は、Kaito Hirutaが提供するiOSアプリケーション「Puppy Buddy」（以下「本アプリ」）の利用条件を定めるものです。本アプリをダウンロード、インストール、または使用することにより、ユーザーは本規約に同意したものとみなされます。

### 責任の制限

Kaito Hirutaは、本アプリの動作に関して、いかなる保証も行いません。バグやエラーが発生する可能性があり、Kaito Hirutaはそれらに起因する損害について責任を負いません。

### プライバシーとデータの保護

ユーザーの個人情報とデータの取り扱いについては、別記したプライバシーポリシーに従います。

### 知的財産権

本アプリに関するすべての知的財産権はKaito Hirutaに帰属します。ユーザーは、個人的、非商業的な目的でのみ本アプリを使用することができます。

### 禁止事項

以下の行為を禁止します。

- 本アプリの不正な改変や複製
- 本アプリを通じて取得したデータの不正な使用や共有
- 本アプリの機能を妨害する行為

### 本規約の変更

Kaito Hirutaは、本規約を変更する権利を留保します。変更後の規約は、本アプリ内での通知もしくはアプリストアのリリースノートでの記載をもって効力を生じます。

### 準拠法と管轄裁判所

本規約は日本法に準拠し、日本の裁判所が第一審の専属的な管轄権を有します。

### お問い合わせ

本規約に関するお問い合わせは、以下のメールアドレスまでお願いいたします。

contact@miketako.xyz

## English

We will not provide personally identifiable information to third parties.
We take the utmost care in managing personal information and handle it as stated below.

### Introduction

These Terms of Service ("Terms") set forth the terms and conditions for the use of the iOS application "Puppy Buddy" ("App") provided by Kaito Hiruta. By downloading, installing, or using the App, users are deemed to have agreed to these Terms.

### Limitation of Liability

Kaito Hiruta makes no warranties regarding the operation of the App. Bugs or errors may occur, and Kaito Hiruta is not responsible for any damages resulting from them.

### Privacy and Data Protection

The handling of users' personal information and data is governed by the Privacy Policy stated separately.

### Intellectual Property Rights

All intellectual property rights related to the App belong to Kaito Hiruta. Users may use the App only for personal, non-commercial purposes.

### Prohibited Actions

The following actions are prohibited:

- Unauthorized modification or reproduction of the App
- Unauthorized use or sharing of data obtained through the App
- Actions that interfere with the functionality of the App

### Changes to These Terms

Kaito Hiruta reserves the right to change these Terms. The revised terms will take effect upon notification within the App or mention in the release notes on the app store.

### Governing Law and Jurisdiction

These Terms shall be governed by and construed in accordance with the laws of Japan, and the courts of Japan shall have exclusive jurisdiction of the first instance.

### Contact

For inquiries regarding these Terms, please contact us at the following email address:

contact@miketako.xyz

Puppy Buddy Term

# 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

# 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.