Kotlinにstaticが無いのなんで？(Why doesn't Kotlin have static members inside a class?)

って前に聞かれたけど、スッと答えられなかったのでここに記します。

※このあたり（https://speakerdeck.com/ntaro/kotlinwoshi-meyouhanzuon-number-droidkaigi-number-droidkaigi6?slide=41）

Kotlinハンズオンのお手伝いしました＆DroidKaigi2017の2日目に参加してきました #droidkaigi

DroidKaigi2017の2日目に参加してきました！
ハンズオンのお手伝いもしました！

#DroidKaigi6 みんなモクモクしてる！　#kotlin pic.twitter.com/awlwcsoYg7

— DroidKaigi(Official) (@DroidKaigi) 2017年3月10日

謝辞

DroidKaigi2017、運営面とても快適でした。
発表者、参加者、スタッフでうまく成り立っているかなぁという風に思い色々感謝です。

僕個人としては快く休ませてもらえた会社にも感謝です。
あ、でも会社の宣伝全然出来てないや。すんません。
（ていうか皆さん平日2daysで休み取れるなんて良い会社ですね？僕は自分の判断で1日参加でした）


あと、チューターとして誘えてもらったたろうさんにも感謝。

オレオレ実装で良いと思う

一人で書くときは。


個人で書くときとチームで書くときは良いコードの意味が違う。

第5回 マイクロサービスアーキテクチャ読書会 #MSA読書会 に参加してきました

オライリーが出版しているマイクロサービスアーキテクチャの読書会に参加してきました。

第5回 マイクロサービスアーキテクチャ読書会 #MSA読書会

今回は6章です。

前提

この読書会は「本の内容をなぞって担当者が発表」→「ディスカッション」という形式をとっています。

6章の危険な匂い

6章のテーマは「マイクロサービスにおける」”デプロイ”に関してです。
が、まぁ本の内容をなぞって説明をしてもらって、話を聞いている間に6章を初見で読んで、これは嫌な予感がするなーと思いました。

その時の感想がこちら。

6章自体内容に対してページ数すくなすぎる感ある(本が)#MSA読書会

— やんくです (@yy_yank) 2017年2月18日

ドメインの境界がハッキリしていない時っていつ？とかそれは開発の度のタイミングからハッキリしてきてCIビルドとか分割できるの？とか
それ5章に書いてあるのかな#MSA読書会

— やんくです (@yy_yank) 2017年2月18日

他の章をきっちり読めてないっていうアレな状態なんですが、とにかくこの章はCI/CDというテーマに対して文書量が少ない。かつ、マイクロサービスアーキテクチャについてのCI/CDって意味での深掘りが無いです。

したがって、これはCI/CDの話に内容がすり替わってしまってマイクロサービスの文脈からは離れてしまうのではないかという懸念がありました。

グループディスカッション

結果的にやはり「マイクロサービス」の文脈というよりはCI/CDのディスカッションという意味あいが強くなってしまったんじゃないかなぁと思います。6章を語る上でおそらく、CI/CDというのは「前提」であって「本論」ではないんですが、どうしても自動化とかそっちの方にディスカッションの話題が行ってしまいがちでした。
本来ならマイクロサービスの文脈でCI/CDとはどうあるのが良いかというディスカッションになれば良かったんですが。

どっちかというと、CI/CDやってますよね？ やってます or やってませんみたいなレベルになってしまって少しもったい無かったかなと思います。

だって、自動化とか別に出来てても出来てなくても良いですけど。この本の主題は、マイクロサービスですから、マイクロサービスにおいて自動化はどうあるべきかに注力出来た方がホントは良いのです。

グループディスカッションで面白かったところ

結構座席的には面白い人が集まっている島だったんですが、マイクロサービスと組織論的な話が面白かったです。SIの文脈においてはマイクロサービスのサービス単位でチームが出来て縦割りになる。その際の政治的な問題とか。
はたまた「過剰なマイクロサービス」の話も面白かったです。CRUDでサービスが分かれるとか。Spring系のマイクロサービスの本とかであるんですって。まぁサンプルとしてはCRUDとかでサービス分けると分かりやすいんでしょうけど。実際やりすぎなんですよね。
でも技術書とかのサンプルがそうなっちゃってるから偉い人が「それが正しいんだ！こういう風にしよう！」みたいなことになったりするらしいです。

マイクロサービスの文脈でのデプロイ

マイクロサービスで考えてた時、本にも書いてありますが、CIとCDはあって当たり前かつ、必要不可欠な存在です。かつ、筆者の主張に従うと、1サービス、1リポジトリ、１ビルド(CI)という比率であるべきと言っています。

加えてローカルでの再現が難しい。「バランスを考えてローカルでも環境を作るべき」、と。
また低速のテスト、高速のテスト、UAT、本番などで環境を変える場合はそれぞれの環境の違いを考慮する必要がある、など。

正直このあたりはもっと本の中で掘り下げて欲しいところで、もっと色々ケーススタディがあると思うんですよね。
でもきっと筆者的にはこの章はこのページ数で収めないと、、、とかあるわけです。（はしょりたくないけど）その大事なことをはしょっているんだろうなと言う感じを僕としては強く受けました。

結果的にはツールに発散する

Docker、Ansible、Vagrant、Vaultなど結果的にCI/CDツールの詳解で終わってしまったような章でした。
うーん、ちょっともう少し説明する必要あるだろうみたいな気持ちでしたが。で、そういうツール郡を熟知していればそっちにとらわれなくて済んだんでしょうけど。。。。
なかなか読書会の皆がそんなの当たり前に知っているというわけではないんですよね。

学んだこと

という感じで、なんだかモヤモヤしてしまう章ではあってのですが、学ぶこともたくさんありました。

• 1サービスは1リポジトリであるべき
• 1サービスは1ビルドであるべき
• ブランチだけでなくマスターへのコントリビューションが常にあるべき
• 1ホストに対して1サービスであるべき

みたいな話です。このあたりはマイクロサービス的に大事な内容なんじゃないかなと思います。

といっても、全てがこれに当てはまるわけではないですが、理想的にはこの体系にしていくのが良いのかなという感じです。

例えば、1リポジトリに複数のサービスがある場合は、サービスの境界を意識せず、複数のサービスに対してコミットしてしまいがちとか。つまりリポジトリが同じであるためコーディングをしていると無意識にモノリシックになりやすいということを言っています。（本の中だとあっさり書いてますけど）

まとめ

ということで、（初参加で言うのもなんですが）ディスカッションとしては今回はもったい無かったのではないかと思います。CI/CDの話になっちゃったから。その話をするのであれば、CiICDの勉強会をやれば良いと思うわけです。
ただ、そうは言ってもマイクロサービスやCI/CDの周辺のメリットデメリットなどの再確認にもなったので良かったのかなと思います。

Kotlinのkaptの話

Pushing the limits of Kotlin annotation processingを読んだ。
よくまとまっている。

ちょっとこの記事をなぞって感想文を書きます。