<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__40fd77b2e2e67" src="https://embed.zenn.studio/card#zenn-embedded__40fd77b2e2e67" 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__34eac0aed33e8" src="https://embed.zenn.studio/card#zenn-embedded__34eac0aed33e8" 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__971affc61ae5b" src="https://embed.zenn.studio/card#zenn-embedded__971affc61ae5b" 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__6e0ff19bff3e5" src="https://embed.zenn.studio/card#zenn-embedded__6e0ff19bff3e5" 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__e425123a60c1e" src="https://embed.zenn.studio/card#zenn-embedded__e425123a60c1e" 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__bbed98638e7dd" src="https://embed.zenn.studio/card#zenn-embedded__bbed98638e7dd" 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__74cbac5606138" src="https://embed.zenn.studio/card#zenn-embedded__74cbac5606138" 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__3061fffe8f588" src="https://embed.zenn.studio/card#zenn-embedded__3061fffe8f588" 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__b68157e4564c2" src="https://embed.zenn.studio/card#zenn-embedded__b68157e4564c2" 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__92ce5a285d62d" src="https://embed.zenn.studio/card#zenn-embedded__92ce5a285d62d" 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__3aedb03d455fe" src="https://embed.zenn.studio/card#zenn-embedded__3aedb03d455fe" 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__afd2940fe254" src="https://embed.zenn.studio/card#zenn-embedded__afd2940fe254" 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__b1d89849cfed9" src="https://embed.zenn.studio/card#zenn-embedded__b1d89849cfed9" 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__a324577a5ca82" src="https://embed.zenn.studio/card#zenn-embedded__a324577a5ca82" 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__9dff371e07e2f" src="https://embed.zenn.studio/card#zenn-embedded__9dff371e07e2f" 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__bc08b705a7905" src="https://embed.zenn.studio/card#zenn-embedded__bc08b705a7905" 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__735ecca552b8d" src="https://embed.zenn.studio/card#zenn-embedded__735ecca552b8d" 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__cb855409a6903" src="https://embed.zenn.studio/card#zenn-embedded__cb855409a6903" 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__c503c6fbb0041" src="https://embed.zenn.studio/card#zenn-embedded__c503c6fbb0041" 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__a9c1c74e8ea59" src="https://embed.zenn.studio/card#zenn-embedded__a9c1c74e8ea59" 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__4ecf20441a2f7" src="https://embed.zenn.studio/card#zenn-embedded__4ecf20441a2f7" 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__dbb69279700dc" src="https://embed.zenn.studio/card#zenn-embedded__dbb69279700dc" 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__a881967bf0dd9" src="https://embed.zenn.studio/card#zenn-embedded__a881967bf0dd9" 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__bf118b984d6c5" src="https://embed.zenn.studio/card#zenn-embedded__bf118b984d6c5" 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__518bbe8c37511" src="https://embed.zenn.studio/card#zenn-embedded__518bbe8c37511" 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__d6603871f4f47" src="https://embed.zenn.studio/card#zenn-embedded__d6603871f4f47" 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__734adfe94235a" src="https://embed.zenn.studio/card#zenn-embedded__734adfe94235a" 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__80e50a4b9f7eb" src="https://embed.zenn.studio/card#zenn-embedded__80e50a4b9f7eb" 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__1ce67dde93a31" src="https://embed.zenn.studio/card#zenn-embedded__1ce67dde93a31" 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) の好きなもの

データセンターが迷惑施設かどうかを決めるのはX民でもエンジニアでもなく住民

## 問題

iOSアプリにGoogle Analyticsを入れるとき、以下のように実装すると思う。

```
class AppDelegate: NSObject, UIApplicationDelegate {
    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil
    ) -> Bool {
        FirebaseApp.configure()
        Analytics.setAnalyticsCollectionEnabled(true)
        return true
    }
}
```

Xcode 15.4でこれを愚直に入れたところPreviewがクラッシュするようになった。

## 解決策

以下のようにDEBUGではGoogle Analyticsを無効化することで解決した。

```
class AppDelegate: NSObject, UIApplicationDelegate {
    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey : Any]? = nil
    ) -> Bool {
        FirebaseApp.configure()
        #if DEBUG
          // テストやプレビュー環境では Google Analytics を無効にする
        #else
          Analytics.setAnalyticsCollectionEnabled(true)
        #endif
        return true
    }
}
```

メインコードにDEBUGかどうかの分岐は極力入れたくなかったが、これ以外の解決策は自分には見つけられなかった。

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

iOSアプリにGoogle Analyticsを入れるときはDEBUGではちゃんと無効にしよう

## トラペジウムを観た

トラペジウムは乃木坂46一期生の高山さん原作のアニメ映画。

https://trapezium-movie.com/

元々推しの子が好きだったりしたので、アイドルの黒い感情の話を自分は面白いと感じる節はあった。

その上で映画館で流れる宣伝や、

「賛否両論」「狂ってる」「サイコパス」

などの口コミを観て映画館に足を運んだ。

感想としては観て良かったと思う。以下ネタバレありです。

## 主人公の狂気と綱渡のような感覚

観て貰えば全員に納得してもらえると思うが、主人公も映画の構成もかなり狂っている。

そもそも主人公のサイコパス加減に共感できない視聴者も多く居たんじゃないだろうか。自分も10年前とかであれば全く共感できていなかったと思う。

しかし最近は「何者かになりたい」という欲求が本当にわかるようになってきた。仕事のやりがいとか、そういうくだらないと考えていた物に対する実感が今更ながら湧いてきて、例えば「宇宙よりも遠い場所」とかそういう話にとても共感するようになった。

また、ライブイベントに足を運ぶようになったのもあり、演者から感動を接種することも増えた。

だからただ「はじめてアイドルを見たとき思ったの。人間って光るんだって。」しか語られない主人公のモチベーションも自分は共感できた。それを踏まえても狂っているけれども。

そんな主人公がなんだかんだアイドルの夢を手にすることになるが、なんだかんだの部分が脆すぎていつ崩壊するのかとヒヤヒヤが止まらなかった。その時間が結構長く、こんなに狂った雰囲気をずっと出せるものかと感心した。

しかし崩壊は予定調和。その後どうまとめるのか予想しながら見ていたが、まさか普通に仲直りして普通に青春ものっぽくまとめるとは思わなかった。普通の感覚で言ったら青春時代を騙されてぶち壊されているわけで、そうはならんやろという感じ。最後まで狂っている。

それらの狂気にはこだわりを感じたし、それを味わえただけで観る価値はあった。

## 結局アイドルも営業マンも個人開発で一山当てたい人も同じ

鑑賞後に余韻に浸っているときに考えていたが、結局アイドルに必要な要素はこういうことなのではないか。

***青春ぶち壊されるほど騙されてもなんか許しちゃう***

つまり詐欺られようが金を搾り取られようがなんか許しちゃう。というのがアイドル性の重要な点なんじゃないかということ。スーパーチャットで稼いでいるVチューバーも同じ類。

これはとても聞こえが悪い。しかしこれはビジネスの本質でもあるんじゃないか？というのがこの記事で言いたいこと。

全て完全に原価 (人件費は含む) と等価交換でサービスを提供されるのであれば富を得ることはできない。そこに何らかの付加価値があることによって、ユーザーはその原価以上の金額を支払い、提供者は富を得るのだとする。

その付加価値の最たる例がアイドル性ではないか？

「なんか輝いて見える」「なんか応援したい」

そんなふわっとした印象が大きな付加価値となり、詐欺的とも言えるレベルの献金を可能にするのかもしれない。

そうなると例えば個人開発で売り上げを出したい開発者もどうしたら良いかの示唆が得られるんじゃないか。

自身やサービスそのものにアイドル性を付与できれば良い。そうすれば原価以上に高い金額でもユーザーは支払うかもしれない。逆に、アイドル性が無いサービスでは儲からない。

そしてそれはビジネスでは「差別化」とか「ブランディング」とか呼ばれている。

なんか繋がってしまった。

## まとめ

じゃあアイドル性って何なんだよって？自分は狂気だと思っている。

人生の貴重な時間を全て捧げて、人生が無価値になるリスクを追ってまで何かに熱中したときにのみ得られるなにかなんじゃないか。

一度きりの人生で失敗できないと思ってリスクヘッジに重点を置いている自分とは対照的で、だからこそ「トラペジウム」は面白く感じたのかもしれない

映画「トラペジウム」でなぜかビジネスの本質を得た気持ちになった

## 概要

XCodeのAssetにマルチバイト文字のファイル名のファイルを入れてはならない。

## 詳細

XCodeのAssetにマルチバイト文字のファイル名のファイル、つまりは日本語のファイル名のファイルを入れると、ビルド時にエラーが発生する。

しかも、エラーメッセージがわかりにくい。私の環境ではローカルでは全く問題がなく、XCode Cloudでビルドした場合にのみ画像が一部だけ表示されないという問題が発生した。

XCodeのAssetのUI上で名前を変更するだけでは解決しない。ファイル名を変更してファイルを上書きしなければならない。

一見問題がないように見えるところが非常に厳しい。やはりマルチバイト文字を使うのは避けるべきだと感じた。

## まとめ

XCodeのAssetにマルチバイト文字のファイル名のファイルを入れてはならない。

XCodeのAssetにマルチバイト文字のファイル名のファイルを入れてはならない

## 概要

技術書典16にサークルとして初参加したので、感想やノウハウを備忘録としてまとめる。

https://techbookfest.org/product/t0gGBQLsrkizaw1en9skWJ

## 感想

### 本を作るのは大変

同人活動がそもそも初めてだったのだが、まず「本を作る環境」を作ることが大変だった。TechBoosterのReVIEW-Templateのコードを読み込み、

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

それを元に自分が使いやすいように整備した。それについての詳細はZennの記事にまとめた。

https://zenn.dev/miketako3/articles/d6407d5280d298

本のサイズは？余白は？ページの通し番号は？それらを適切に一から整備するのは非常に厳しい。よくわからない人はTechBoosterのReVIEW-Templateを使うのが一番だと思う。

ただし、それでも設定ファイルやReVIEWの仕様を理解する必要があり、ビルド設定やPDFの生成方法等もWebのエンジニアじゃないと馴染みがなくて辛いと思われる。

本文を書くだけである程度綺麗に出来上がるフォーマットが欲しいところ。

そして本文を書くのも当然大変で、自分の場合は目標としていたページ数まで到達しなかった。

初回ということでそこまで無理しないように作ったが、次回はもう少し構成を練ってページ数を増やすようにしたい。

### 本を売るのも大変

まず宣伝をしないといけない。マーケティングの一番最初は認知から始まる。

自分の場合はTwitterを使ってフォロワーを増やし、イベント当日にはそのフォロワーに宣伝を行なった。

また、お品書き画像を作ったり、当日の運用を考えたりと、本を売るためにはかなりの労力が必要だった。

### 得られるものは大きい

それでも、技術書典に参加して得られるものは大きい。

自分は今まで在庫を抱えるような商売をすることはリスクの大きさからなるべく避けてきた。

今回初めて同人活動とはいえそのような経験をして、かなり勉強になったと思う。

そんな大量に儲けが出たわけでは無いが、初めてで赤字ではないだけ御の字というところだろう。

オフラインも終了したら赤裸々に収支を公開したい。

## ノウハウ

### 入稿フォーマットや締め切りをなるべく早めに確認する

同人イベントに参加したことが無い場合、印刷所の入稿フォーマットや締め切り等の情報を特に早めに確認しておくべき。

日光企画においては以下で、表紙テンプレートはここからDLして編集した。

https://www.nikko-pc.com/offset/template/tonbo.html

本文の方は前述のテンプレートから生成すれば問題なかった。

印刷の専門用語が全くわからないばかりか、デザインの知識もないので、非常に時間がかかった。

表紙、本文共に入稿フォーマットは必ず最初に確認しよう。

### PhotoshopやIllustratorが無くてもなんとかなる

自分の場合は互換のAffinity Publisherを使ったが、簡易的な表紙デザインであれば無くてもなんとかなる。

他のデザインソフトでも同様だろう。ただし、最低限psd形式が読み込める方が良い。

とはいえ余裕があるならデザイナーに依頼するのが一番ではある。デザインは難しい。

今回はロゴとかヘッダーとか色々なクリエイティブも一緒に作成した。統一感を持たせるのはかなり大変だった。

![名刺表](/tech-book-fest-16/名刺表.png)
![名刺裏](/tech-book-fest-16/名刺裏.png)
![ロゴ](/tech-book-fest-16/ロゴ.png)

### 宣伝はなんだかんだX (Twitter)

現状最も認知が稼げるプラットフォームはXであるから、それをやらない手はない。

2ヶ月前あたりから意識して、1ヶ月前あたりからはフォロワーを増やす動きを意識的に行なった。

具体的にはツイート頻度を増やしたり、いいねやフォローを行なったり。

個人的にはプロ驚き屋には絶対なりたく無いという思いもありかなり辛かった部分だが、なんとか上手くバランスを取れたと思っている。

また、お品書き画像は必ず作るべき。SNSでの宣伝には欠かせないし、当日ポスター的に飾って宣伝するのにも使える。

https://x.com/miketakoxy/status/1794545296472711469

### 当日の設営

![設営](/tech-book-fest-16/設営.png)

今回は技術書典の手ぶらセットというものを申し込んだため、以下は用意されていた。

- テーブルクロス
- マッキー
- 決済QRコードが書かれた紙とスタンド
- ポスター的なもの
- マスキングテープ
- 色々なものを立てかけられる簡易スタンド
- デコレーションシール

それ以外にも色々と準備した。

まず何らかの形でお品書きポスターは用意しておくべき。こなれている感はかなり売り上げに関わるんじゃ無いかと思っている。

また、本は見本用に何冊か用意し、透明ブックカバーをつけておくと良い。見本だけ見て買わない人もいるが、そういう人は買っても満足してはくれないので、見てくれただけありがたいと思っておくべき。

あとは名刺を作って本と一緒に配ったり、ぬいぐるみを置いておいたり、モバイルディスプレイで画像をスライドショーしたりしてとにかく目に止まるようにした。

### 現金決済には対応しておくべき……は古いのかもしれない

現地の電波障害や、そもそも公式後払いに対応していない方のために、現金決済は可能な限り対応しておくべき……と思っていた。

私は先人に倣い、パスワード付きのZIPファイルを用意しておき、購入者にパスワードを記した紙を渡すことで対応できるようにした。

https://miketako3.booth.pm/items/5754237

しかし、実際は特に何の問題もなく全員が公式後払いでの決済をしてくれた。

1人だけ現金決済を希望された方がいたが、お願いしたら後払い決済にしてくれた。後払いはキャンペーンもやっていたので非常にありがたかった。

https://blog.techbookfest.org/2024/05/11/tbf16-event-print-order/

もはや現金は対応しなくても良いのかもしれない。

## おわりに

今回は技術書典16にサークルとして初参加して、得られたノウハウをまとめた。

次回はもう少しページ数を増やして、より多くの人に読んでもらえるような本を作りたい。

まだオフライン開催は続くが、オフラインも終了したら赤裸々に収支を公開したい。

この記事が誰かの参考になれば幸いです。

良かったらX ([Twitter](https://x.com/miketakoxy)) をフォローしてください！

技術書典16にサークルとして参加した

**2025/04/12 追記: 思ったより見られているようなので、最後に約1年の間仕事で使用した感想を追記しました。**

## 概要

![キーボードの写真](/make-keyboard2/img.png)

https://shop.yushakobo.jp/products/8961

Corne Cherry V4というキーボードを~~作った~~買ったので、感想と使い心地について語る。

## Corne Cherry V4

基本的なところは以前レビューしたV3と同じ。

https://miketako.xyz/posts/make-keyboard

主に違っているのは以下の点。

- 半田付け、ファームウェア導入済み
- ケース付き
- 中央に左右2キーずつが追加 (ロータリーエンコーダにも変更可能)

それぞれ詳細を書いていく

## 半田付け、ファームウェア導入済み

キースイッチどころかマイコン、端子、LEDに至るまで全て実装済みだった。

さらにファームウェアもすでにマイコンに入っていた。

これによりネジ止めとキースイッチ、キーキャップのはめ込みだけで完成するので、あとはRemapで好みのキー配置にすればすぐに使える。

もはや自作キーボードではなくスイッチなどが選べるだけで普通に市販キーボードだった。

自作キーボード界隈もここまで進化したか…という感じ。

## ケース付き

かなりすばらしい。これにより打鍵感や安定感が向上し、所有欲的な部分まで満たせるようになった。

V3では基盤剥き出しだったのでどうしてもチープな感じが抜けなかったが、ケースがついたことでそれが解消された。

## 中央に左右2キーずつが追加

V3ではProMicroが乗っていた部分にキーが追加された。

自分はロータリーエンコーダに変更することなくキーにしているが、現状使いたい機能がそこまでなく持て余している。

最初はマクロとかで活用しようと思っていたが……他のキーでできるショートカットはそのキーを押せば良いし、それ以外はAlfredで呼び出せば良い。 1ボタンでキーボードから呼び出したいものが現状思いついていないという状態。

Artisanキーキャップを使う絶好の場所なのでそういう用途としては今後使っていきたい。

## まとめ

半田付け不要でケースも付いているというところで、V3と比べると相当ハードルが下がり、かなり万人にオススメできる仕上がりだった。

40%キーボード、column staggered、というところに魅力を感じる人にはぜひ使ってみてほしい。

自分は巡り巡って結局ずっとV3を使い続けていたので、今後はV4を使い続けることになりそう。軽いキースイッチ ([遊舎工房軸](https://shop.yushakobo.jp/products/5659)) を使っているのも相まってかなり疲れにくくなった。

https://shop.yushakobo.jp/products/5659

製作者のfoostanさんに感謝。

## おまけ

私のキー配置は以下の通り。

私の知能ではレイヤーは2つが限界だったのでそれに絞り、右手だけで矢印キーを使えるようにしているのがこだわりポイント。

記号の配置は苦肉の策という感じだが、矢印キーの配置を維持しつつなるべく通常の配列から離れさせたくなかったのでこうなって安定している。

![キー配置](/make-keyboard2/img2.png)

## 追記

### 約1年の間仕事で使用した感想

私はフルリモートのエンジニアですが、自宅キーボードとしてV4を約1年間使用していました。V3と合わせると2年近くでしょうか。

V4はV3と比べて安定感が増し、打鍵感も良くなったので、非常に快適に使用できました。少し左右の接続が切れる不調がありましたが、おそらくケーブルの問題です。キーボードとしては非常に満足です。

この記事を見ている方は「自作キーボード」や「左右分割」に興味があるのかなと思います。結論から言ってしまうと非常に素晴らしいです。特に私の場合はホームポジションから外れずに矢印キーを押せることがとても大きく、通常のショートカットが馴染まなかった自分にとっては非常に快適でした。これで作業効率が間違いなく上がっています。

ただ、やはり40%キーボードは慣れが必要です。特に記号の配置は独特で、最初は戸惑うかもしれません。ですが人間は意外と慣れるものです。しかも通常のキーボードと問題なく使い分けられます。

気軽に始められますので皆さんもぜひご検討ください。

### SNS

Xが凍結されてしまいましたので、良ければnoteやZennの方をフォローしてください。技術記事などを書いています。

https://note.com/hirut

https://zenn.dev/miketako3

Corne Cherry V4を買った

## 概要

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

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に分析せよ。

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

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

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

## まとめ

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

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

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

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

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

「Googleのソフトウェアエンジニアリング」でわかるリファクタリングと自動テスト

## 概要

![キーボードの写真](/make-keyboard/img.jpg)

https://shop.yushakobo.jp/products/corne-cherry-v3

Corne Cherry V3というキーボードを作ったので、制作した感想と使い心地について語る。

なお、この記事も同キーボードで書いている。

## Corne Cherry V3

column staggeredで親指３キーの４０％キーボード。左右分割になっている。

何故このキーボードにしたかというと、実機を触った際のフィット感に加えて以下の要素が決め手だった。

- 遊舎工房のキャンペーンでキースイッチが無料だった
- 数字キーが遠いと感じていた

このキーの少なさは挑戦的だったが、すでに６０％を使っていたのでまあ慣れるだろうくらいの気持ちだった。

## 組み立て

１５年振りくらいに半田付けをした。なんとかうまくできたと思う。

キースイッチのピンがよく曲がってしまったのが辛かった。

組み立ては遊舎工房のレンタル作業場を利用させてもらった。

光らせる気はなかったのでキットについてくるLEDはつけなかったが、それでも3時間かかった。レンタル代だけで３０００円かかった。

## 使用感

すばらしい。何がすばらしいかというと、数字キーや矢印キー、記号キーのためにホームポジションが崩れることがなくなりそうということ。

また、左右分割というのもすばらしい。まったく窮屈感がなく快適にタイピングできている。

記号などを打つのに複数キーの入力が必要で配列に慣れるまでまだだいぶかかるとは思うが、慣れたら今まで以上の速度で疲れず入力できそう。

## まとめ

雑な記事になってしまったが取り急ぎこのキーボードの入力に慣れたかったので書いてみた。

自作キーボードは沼だとよく言われているが、1人でも沼に引き摺り込めたら幸いである。

Corne Cherry V3を組んだ

## 概要

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

## 概要

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

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のソフトウェアエンジニアリング」を読んだ

# 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

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