ベタープログラマを読みつつの何かメモ

まだ読んでる途中なんですが、書いていきます。
目についたところをバラバラに読んでます。
また、読み進めたら追記するかも（しないかも）

所感

ベタープログラマは良い本である。
内容に共感出来て、その瞬間何故かニヤける感じ。
それと同時に、自分自身を省みて申し訳なくなる。ああ、すんません。

読んでいると、irofさんとかが喋りそうな内容だなと思う。
俗っぽい言葉で言うとエモいのだが、
プログラマとしてかくあるべきと言うのを思い出させてくれるというか、
“プログラマとしての正しさ”とか”プログラマとしての向き合い方”とかを改めて思い直させてくれるという感じ。

初心にかえるにはもってこいであるし、正しい方向へ向かえる本だと思う。もちろん知らなかった知識の発見や、新しい方法も読者によっては含まれていると思う。

コードが中心になっている

この本はとことん、プロダクト、特にコードを中心にして物事を論じている。プログラマーたるものコードが中心だというのは全く正しい。
しかも、綺麗なコードを書く方法よりも、”今存在している問題をはらんだコードをどう解決するか”とか”いつリファクタリングをするか、どこまでリファクタリングすべきか”など「書き方」よりも「判断の仕方」が書いてあったりするのでよい。

個人的にいいなと思った章

全てを読んでいないし、飛び飛びで読んでいるのですがメモします。

• 6章航路を航行する
  ソフトウェア考古学、いい言葉

• 7章汚物の中で転げ回る
  大事

• 24章学びを愛して生きる
  これが出来なくなったら辛いし、逆にこれが出来て入ればなんとかできる気がする

• 27章停滞を避ける
  気をつけたい

• 28章倫理的なプログラマ
  気をつけたい

• 29章言語への愛
  わかる

• 30章プログラマの姿勢
  そっちか

• 33章今度こそ分かった
  ほんますんません

Java 10のvarのやーつで遊んでみる

はじめに

Javaでvarをとりあえず使って遊んで見ました。のザックリしたただのメモです。

Java 10がリリースされました！Java 9はほとんど触らなかった！
リリース日がちょうど祝日だったので少しだけ触りました。

一番遊んで見たくなるのが、
JEP286のvar のやつですよね。
これにより、ローカル変数でvarが使えるようになります。
JEP 286: Local-Variable Type Inference

KINESIS Freestyle 2 と HHKB Lite 2 を買った個人の感想

うっかりキーボードを衝動買いしてしまったので、メモがてら所感をブログに書いてみます。

魔が差してHHKBとKinesisをポチってしまった

— yank shaving (@yy_yank) 2018年2月5日

[Kotlin]関数型プログラミングライブラリの KΛTEGORY とfunKTionaleはArrowになります(funKTionale + KΛTEGORY = Arrow)

今回の記事は、ただのニューストピックです。

よくある1年の個人的な振り返り2017

毎年なんだかんだ、1年の振り返りを書いています。
今年もゆるりと。

MacBook Pro買ってとりあえずやったこと

15インチのpc買って気づいたんですが、今まで僕が15インチだと思って使ってたpcは13インチでした

— yank shaving (@yy_yank) 2017年12月9日

MacBook Pro買いました。
touch barすごい違和感ある。
毎回散らかすので、はじめにやったことをまとめておこうと思います。
本当はこういうのは1つのインストール用スクリプトみたいになってるのが理想だけど。。
備忘録です。

作業を効率上げたくてポモドーロをやってみているが

要約

みんなどうやって作業効率を上げてるのか教えて欲しいです！！！

はじめに

ポモドーロテクニックを使ってみての実感とかを書きます。
これに対して、「ポモドーロのやり方間違っている」とか
「もっと良い手法がある」など、何かあればやんわり教えていただけると幸いです。

JJUG CCC 2017 Fallに参加してきました

JJUG CCC 2017 Fallに参加してきました。
https://jjug.doorkeeper.jp/events/66307

CA.kt(Kotlin Conf報告会)に行ってきました

Kotlin Confが羨ましすぎてｳｫｰｯてなったので、
ca.kt(Kotlin Conf報告会)に行ってきました。
https://cyberagent.connpass.com/event/70423/

一応、レポートというかログというか思ったことというか。
残しておこうと思います。

Java SE 9/EE 8リリースイベント 兼 JavaOne 2017 報告会に行ってきました #jjug

はじめに

タイトルの通り、JavaOne報告会に行ってきました。
僕はJJUGのイベントの中でも、毎年恒例のJavaOne報告会は結構好きです。
みんな海外帰りの余韻でちょっと浮かれた気分が抜けてない感じが良いんですよねー。

本当に個人的な話ですねw

https://jjug.doorkeeper.jp/events/66256

Java SE 9 を雑に見る

最近ブログを書いてないなと思い、慌てて書く次第です。

先日、2017/9/21に、Java SE 9とJava EE 8がリリースされたようです。
http://www.publickey1.jp/blog/17/java_ee_8java_9eclipse_foundationjava_ee.html

こんなにリリースって盛り上がらなかったっけw
僕の狭い観測範囲あまりワイワイしてる人が少ないです。

せっかくだしちょっとだけ触ってみようと思います。
ホントちょっとだけ。
Java EEは一旦忘れて、Java SEの方のみ。

夏のKotlin LT祭を行いました #jkug

久しぶりのコミュニティイベントを開催しました

夏のKotlin LT祭と題して、
日本Kotlinユーザーグループ(JKUG)主催でLTイベントを行いました。
会場を提供していただいたDeNAさん、ありがとうございました！！！！！！

https://kotlin.connpass.com/event/61427/

利き手のようにJava使うのやめたいなって

ってなんとなく思った。
いろんな言語を学びたいとか言いつつ、お前が真っ先に書こうとするのはJavaだろう、と。

「Javaが凄い出来ます！得意です！」とかなかなかそういうことを言う気にはならないんだけど、
パッと何かをしようとしたときには一番楽な言語となっている。それかKotlinなんだけど。
多分、Javaに関して言えば、開発環境がすでに目の前にあるから咄嗟に使いやすいというのは大きい。

利き手以外も使おうと

例えば普段鉛筆を持たない左手で字を書いてみる。
書いているうちに左手で字を書くことを覚える、みたいな作業は必ず必要である。少なくとも僕の場合。

ただ、忙しい時にtryすると、
「この忙しいのになに悠長なことしてんだ」ということになるので時間の捻出もある程度必要になりそう。仕事ならば。

家で趣味コードであればダラダラ書いても良いかもしれないが。
やっぱある程度家で素振りしてから実戦で個人で使ってみるという流れかな。
それでよっぽどチームで使ってメリットがあるならチームで導入という流れになるだろう。と思う。

向き不向きで手段が選べているか

ホントにそれってJavaでやる方が向いている作業？ってこともある。
もしかしたらPythonの方が良いかもしれないし、JavaScriptの方が良いかもしれないし、
RustとかGoの方が良いのかもしれないみたいなの。

それでも案外Javaで出来てしまったりするからタチが悪いというか。
極端な話Semicolonless Javaみたいなことになる。

まぁそもそもそんな難しいことを僕自身が書いていない。

利き手のように使うために

やっぱり素振りだなぁ。もっとコード書かないと

このブログをhttps化した(少しだけ)

一応世の中はそうなっていると聞いているのでそうした。


以前にたまたま見かけたJxckさんのこれに感銘を受けた、というと大げさだけど。ちゃんとしないとなぁという思いから。

HTTP2 時代の Web - web over http2




とりあえずhttpのものはhttpsに置換。
Bloggerの設定でhttpリダイレクトでhttpsになる仕組みがあったのでそれをオンにした。ブログの情報はhttpsで閲覧可能になった。
https対応していないっぽいブログパーツは捨てた。
ただ、まだ各ブログエントリ内でhttpでaタグとか使っちゃっているところもあるだろうからそこは暇なときに直していくしかない。一番骨が折れるかもしれない。

細々使っているAdsenseはhttpsか可能だったので、小遣い稼ぎがてら残しているけど収益なんか無いに等しいので飾り。
人間は欲深い。


ちょっと悲しいのは、はてぶがhttpの方にリンクされていて全然表示されなくなったこと。
だけど今までのはてブの数でドヤってするのも微妙だしな。
今後はhttpsではてブとかついていくだろうし大した問題では無い。

個人的な勉強会に行くと良いこと

最近、「勉強会に行く人が優秀うんぬん」とか流行ってたので、なんとなく書いています。

ただのプログラマーが書いている文章です。

Kotlinの演算子オーバーロードはnullableが絡むと少しめんどい

つまりこういうめんどくささがあります。

val f1 : () -> Unit = {}
f1() f.invoke() // OK
val f2 : (() -> Unit)? = null
f2() //コンパイルエラー 
f2?.invoke()  // OK

軽く解説

nullableをレシーバーに取りにくい

f1()という関数呼び出しは、実は演算子オーバーロードという機能によって実現しています。
f1()とコードを書いた時 f.invoke() が呼び出されるというものです。
f1は () -> Unit 、つまり引数なしでUnitを返す関数型をlambdaで表現したものですが
実体の型はFunction0<Unit> というインターフェースです。

Function0の実装はこうなっています。

// kotlin.jvm.functions
// Functions.kt 
public interface Function0 <out R > : Function<R> {
    /* Invokes the function. */     
    public operator fun invoke(): R
}

f1はFunction0自身であり、invokeが実行されます。
これがf2のようにnullableとなった場合にKotlinの演算子オーバーロードはそれを許しません。
f2?.invokeという風に厳密にかけとコンパイルエラーになります。

つまり、nullableな変数の関数呼び出し(nullableな型をレシーバーとする関数呼び出し)をしにくいということです。

演算子オーバーロードは?による特殊記法がない

前述したコードのf2を、f2?()とかって実行出来れば良いのではという感じもしますが、
Kotlinはそういった言語設計を行っていないようです。
f2?()という呼び出しをサポートする代わりに明示的にf2?.invoke()と書きなさい、としています。
これはnull安全的観点で言うと良いような気もしますが、
突然普段は演算子オーバーロードによって隠蔽されているinvokeという謎関数が出てきた感じになるので、実装者としては混乱するかもしれません。

推測ですが、f2?()とかという書き方をサポートしなかったのは
単純に?を使った記法を利用できる箇所を限定的にしたかったのと、
コンパイラの字句解析とかを簡単にしたい（めんどい）というのがあったのではないかと思います。

nullableなものでも演算子オーバーロードを利用する

nullableだと演算子オーバーロードが利用できないかというとそうではありません。
拡張関数を利用すれば良いのです。
たとえば次のように実装すればinvokeの呼び出しも演算子オーバーロードを介して利用可能です。

operator fun <R> Function0<R> ?.invoke() = this?.invoke()

val f2 : (() -> Unit)? = null 
f2() // コンパイル通る

ただし、Kotlinの標準ライブラリとしてわざわざこういった機能を提供せず
f2?.invoke()と書かせているのは、関数を実行したつもりで関数を実行していないなどのバグの元になるのを防ぐといった意図がありそうですしあまりお勧め出来るソリューションではありません。

nullableの場合の振る舞いは多分実装者が決めるもの

もう一つ、理由として考えるられるのは
nullableなものを実行した時の対処というのは大体においてコーディングしている側に委ねられるものだと思います。
たとえばBigDecimal + BigDecimal で返されるのは2つのインスタンスの値を加算したものであるのは自明という感じがしますが
BigDecimal? + BigDecimal
BigDecimal? + BigDecimal?
などは何を返すかはちょっと考える必要があります。
あと、単純に標準ライブラリが膨らみますね。

まとめ

• 演算子オーバーロードはnullableをレシーバーにとる時の挙動はあんまりサポートしていない
• どうしてもやりたいなら実装者側で拡張関数で追加していく必要がある

おまけ

悪ふざけコードです。

https://gist.github.com/yyYank/02d6c7f64532bb30cd0e63563d90feb2

Kotlin入門までの助走読本の個人的な裏話

Kotlin入門までの助走読本というfree bookを
僕も参加させてもらって、ちょっと書きました。
楽しかったなぁー。皆さんありがとうございました。

豪華執筆陣による「Kotlin入門までの助走読本」をリリースします！
話題のプログラミング言語の「味見」をぜひ！PDF注意https://t.co/LJJDReAzue

— 日本Kotlinユーザグループ (@kotlin_jp) 2017年5月29日

ぜひ読んだ方はアンケートも書いてみて下さい。ありがたく拝見します。

https://t.co/uaFHHfiLuh

あくまで個人的な感想＆意見という感じですが、裏話としてブログを書いてみます。

Kotlinという言語とNull Safety

何も考えずタイトルつけたのに胡散臭い。

どうも、趣味でKotlinの情報を集めてるだけの人です。

KotlinはAndroidで公式採用されることが決まりまして特需が出てきています。

こぞって企業がPRのために「Kotlin使ってますアピール」をしたり、
Kotlinとはなんぞや、みたいな話を書いたりとかしてますので、
この速さなら言える、ということで僕も便乗して久しぶりにKotlinの話を書こうと思います。

前提

プログラミング言語は簡単で、それを難しく語る人や難しく使う人がいるというだけな気がしています。

つまり何が言いたいかというとKotlinは簡単です。あと、ラクです。

僕が今日書こうとしているのはよく分からないボヤキなので単純に学びたいというだけであれば、
Kotlin KoansとKotlinの公式サイトのリファレンスだけ見れば大体充分です。

他の情報はまぁ、あんまり読んでも読まなくても一緒です。(というとアレですね。。)

あ、でもKotlinスタートブックという本は良いです。

あと、僕のサイトも使ってみてね(宣伝)
逆引きKotlin

それだけで良いと思うのでココから先は読まなくても問題ないです。

参加と発表しました(JJUG CCC Spring 2017)

タイトルかぶりしそうなので変なタイトル。

VMの歩む道。とか言ってHotSpot VMとDalvikとARTの話をしました。
https://www.slideshare.net/yyyank/vm-dalvikartjava-vm

発表した内容のイイワケ

発表者の理解不足もかなりあって、資料見ていただくと簡潔でなかったり
情報として微妙だったりする箇所も多いと思います。
それでも勉強になったと言ってくれる人もいてありがたいです。
(
　　ホントはJVMS全部読んで
　　ARTとかOpenJDKの実装ももう少し読んだ上で発表したかった。
　　JVMSはJava SE8版でPDFだと600ページぐらいです
　　(注意:pdf) The Java® Virtual Machine Specification
)

ベスト尽くしてこんな感じです。すみません。

訴訟の問題、パフォーマンスチューニングを発表スコープから削ったことで
大分説明しやすいかと思ったんですけど、 それでも広いなとか思いました。

JITとかAOTとかめちゃくちゃ簡単に説明しましたが
プロファイリングした上でその情報に基づいてJITが走ったりするとか色々あるんですけど、
あー、どこまで調べよう＆説明しようかみたいな感じでした。

質疑応答について

今回はあまり質問なかったか、しにくかったのかもしれません。

後から話しかけに来てくれる人もいたのでその人からは色々意見聞くことが出来ました。

さくらばさんのJigsawセッションを拝聴して
sli.doという匿名質問サービスが良さそうなのでまた機会があれば使ってみたいなと思いました(さくらばさんがツッコまれる世界を初めて見たw)。

https://www.sli.do/

見たもの

• データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3

データモデル、勉強になりました。咄嗟に出てくるようにしたいなとか思います。いっつもデータモデルのこういうものがあると思いつつも、どのタイミングでそれを使うべきかとか適切に判断できずじまいということが多いです。

• Javaエンジニアに知って欲しいRDBアンチパターン

色々ためになる内容だったんですけど、アンチパターンはH2Oぐらいに思い出がいっぱいって感じなので素直に笑えなかったです。そーだいさんぐらい声が通る感じになりたい。

• Introduction of Project Jigsaw

さくらばさんのセッションはいつも安定感がすごいです。たしか、全然スライドとか見ずに全部覚えてて話してるとかいう噂を何処かで聞いた気がします。Jigsawに関してはモジュールがうんたらーで最近もめてるやつってぐらいしか把握できてなかったので、勉強になりました。
以下、なんかツイートしてたやつ

JSR 376(Jigsaw)に反対してSE9には賛成という投票が#ccc_g5

— yank shaving (@yy_yank) 2017年5月20日

ソースコードも変える必要がある、コンパイルもpackagingも変わる、実行も変わる、IDEの対応が必要になる(予定)
なるほど#ccc_g5

— yank shaving (@yy_yank) 2017年5月20日

Jigsaw非対応のjarは-cpで読んでくれなくなる
Automatic Moduleでjarをモジュールか出来るけどそのあたりがもめているらしい#ccc_g5

— yank shaving (@yy_yank) 2017年5月20日

automatic moduleはjarファイル名がそのままmodule名になる、、そしたら衝突するだろーという問題
MANIFESTにモジュール名書くようにしましょうに変更➡️これが通らないとJigsaw通らなそうとか
#ccc_g5

— yank shaving (@yy_yank) 2017年5月20日

ビルドツールが対応する必要もあるよな、たしかに…#ccc_g5

— yank shaving (@yy_yank) 2017年5月20日

• Java8 コーディング ベストプラクティス ＆ NetBeansのメモリ使用ログから 機械学習で きしだが働いてるかどうか判定する

きしださんぽいなぁと思いました。前半は難しいというか全然知らない分野で雰囲気で聞きました。コーディングのベストプラクティスの部分は納得出来る内容が多かったです。

感想とか

LINEさんの寿司ちょっと食べましたが美味しかったです。

色々勉強できたし、色んな人と話せたし良かったです。
今回もありがとうございました！みなさんお疲れ様でした！

「イシューからはじめよ」はシステム開発、プレゼンで役立つ内容かもしれない

「イシューからはじめよ」を読んだ。結構良かった。


別にソフトウェア開発とかそっち系ではなく、
もっと仕事をする人全般に当てはまる内容の本。

だけど、自分として役立ちそうなのものとして

• システム開発
• トラブルシューティング
• 勉強会とかの発表

という場面が思い浮かんだ。
なのでシステム開発で「開発が終わらない」とか「バグの解析が苦手」とか、
勉強会で「プレゼンの資料が上手く作れない」とか悩んだりしてる人は読むといいのかもしれない。

経験積むほど守破離が出来なくなってきた

プログラミングをするお仕事をして数年経つけど(5年ちょいぐらい)、段々と守破離が出来なくなってきた気がする。

守破離とは

剣道や茶道などで、修業における段階を示したもの。「守」は、師や流派の教え、型、技を忠実に守り、確実に身につける段階。「破」は、他の師や流派の教えについても考え、良いものを取り入れ、心技を発展させる段階。「離」は、一つの流派から離れ、独自の新しいものを生み出し確立させる段階。

https://kotobank.jp/word/%E5%AE%88%E7%A0%B4%E9%9B%A2-689006より引用

出来なくなるとは何か

この守破離という言葉は、近い職業で言うといわゆるITエンジニアの意識高い系の人たちが使っている気がするのだけど考えとしては大事と思っている。

で、出来なくなってきてると思っているのは主に「守」の部分。

知識のショートカットと愚直のトレードオフ

トレードオフ的な。

例えば、新しい言語Aを学ぶとなったとする。
そうすると、プログラミングを初めたばかりであれば入門書から全て基本文法を覚えたりとか始める。
次に何かアプリとか作ってみようとする。そして仕事で使うとかする。

一方で、それが今の僕であれば基本文法は入門書を細かく見なくても◯◯言語のアレと同じだからやんなくても大体分かるな、となる。
A言語とB言語があった時に、AのXXXX ≒ BのXXXX とか判断出来る。
一見して便利なんだけど、全然手とか動かさなくて済んでしまう。もしくはそれで済まそうとする。記憶に残らないし身につかない。
性分として、元々あたまでっかちな方なので結構質が悪い。
言語の違いの部分だけ味見して分かった気になるとかそんな感じになってて中途半端だなぁ、、とかいうのが最近です。

守のない守破離

ということで、僕がやっているのは守のない守破離みたいな感じになっている。かもしれない。
帽子のないマリオ、バクダンを持ってないボンバーマン、具のないカレー、みたいになんか足りない感じ。

そもそも破も離も出来ないはずなので、完全にわかったフリということになる。厳しい。

初心にかえりたい

ここ最近思うのはもっと愚直にやりたいなということ。
もちろん、分かりきっていることをド初心者と同じように学ぶというのは効率が悪いのでやらないですが、もっと色んなことに真摯に向き合いたいなとか思う所存。

という自分の悩み？と自戒を書いた風のポエムでした。

うだうだ言ってないでコード書け的なやつだ。

そもそも守破離と言うほど物事を突き詰めているのか、どうなんだ。

僕の考えたさいきょーのJavaのプログラム初心者向け研修課題、の妄想

ござ先輩さんのアレを読んだ。

Javaで「はじめてのプログラミング」を教えるのはキツイと思った話

Javaに造詣が深い方だった気がするし、色々考えた上でそういう決断するのは確かになぁーと思った。

イマドキ、Servletさわんのかぁとか思いつつ、Servletそんなムズいんだっけと思いつつ。

で、脱線して僕ならJavaの研修課題どんなものを作るかなとか考えた。

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を読んだ。
よくまとまっている。

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

DDD、やるかどうかは置いといて「わかる！ドメイン駆動設計 」は読むと面白い

良い本なので感想とか僕の考えてることを書こうと思います！


「わかる！ ドメイン駆動設計～もちこちゃんの大冒険～」というTechBoosterさんが出している本です。
DDDだからページ数多いんだろうなというイメージだったんですが、60ページ。しかも1000円は安い。

買ってハズレでもちょっと1日御飯を控えめにするだけでなんとかなる（大体控えめにすることはない）。と思いPDF版を買いました。

こちらから買えますよ！まわしものじゃないけどｗ

https://techbooster.booth.pm/items/392260