Kotlin Fest 2022 参加記

【完走賞】MxShun ひとりマラソン 🏃 Advent Calendar 2022 毎週金曜日は Kotlin の記事を書こう！4記事目、最後の記事です。

https://twitter.com/MxShun/status/1599572098313498625?s=20&t=G7LsG-ggOcBBVVFs5PDQKw

2022年12月10日、Kotlin Fest 2022 参加してきました！３年ぶりの開催おめでとうございます！🎉
今回は、Kotlin Fest 2022 にて参加したセッションで学んだことや感想を書いていきます。

※記載内容に誤りがありましたらご指摘いただけますと幸いです。:bow: 

# Gradle Kotlin DSL と Gradle Plugin 開発
by Jumpei Matsudaさん

https://fortee.jp/kotlin-fest-2022/proposal/c1ad3a63-2a50-4f79-99a3-b58a8042babf

Koslin DSL と Gradle Plugin の開発に関するセッションです。
私自身、Kotlin プロジェクトでは Groovy ではなく Kotlin DSL の採択が多いこともあり拝聴しました。

### Kotlin DSL はどう実現されるのか

- Kotlin DSL は後発だが Groovy DSL の wrapper ではなく直接 Gradle API を叩いている
- （現在は）Precompiled Script Plugin の仕組みで実現される；先にプラグインをなめて Kotlin 用のアクセサを生成している

### Kotlin DSL の Kotlin バージョンは曲者

- Kotlin DSL では言語バージョンと実行バージョンが異なる
- API レベルの変更は Gradle メジャーアップデートのときのみ

### 所感
Kotlin DSL は（Gradle リロードなどのタイミングでなのかな？）裏側でプリコンパイルしてプラグインクラスをなめていたり、Kotlin DSL の言語バージョンと API バージョンにギャップがあることは意識したことがなかったので勉強になりました。📝
（DSL は "いつか" 勉強したいと思いつつも重い腰が上がっていなかったので）プラグインごとの Usage を読んで dependency を追加していくぐらいしかやってこなかったので。
ただ、Gradle Plugin を自前で作る機会はまだなかったので、正直メインの Gradle Plugin 開発の領域は理解が及ばない部分が多かったです。。。

# Kotlin Symbol Processing APIを使ってKotlinアプリケーションの開発を効率化する
by takuji31さん

https://fortee.jp/kotlin-fest-2022/proposal/4ab3a384-8852-4ff8-91a9-250ea0fb8174

KSP ってなんだろう？の気持ちで見に行きました。すると冒頭で一蹴、「みなさん、KSP 使ってると思います。」と KSP 利用者を対象としていたので「KSP とは」の部分だけ拝聴し退散しました。。。勉強し直してきます。:pray:

### KSP（Kotlin Symbol Processing）とは

- Kotlin でシンボルを処理するための軽量コンパイラプラグイン
- Java で言う Pluggable Annotation Processing API と同様にアノテーションを使う

https://github.com/google/ksp

### 所感
（所感ではないですが）もう少し初歩的に掘ってみす。
KSP の本質理解は、Pluggable Annotation Processing API の理解から出発するのが早そうでした。

https://dk521123.hatenablog.com/entry/37774601

そして、コンパイル時にアノテーションをスキャンしてコードを生成してくれるものと理解をしました。どういうユースケースがあるのかと言うと、ボイラープレートを排除したり、自前で作っていた型をコード生成でカバーしたり、に利用するそうです。これは実際のプロダクトコードレベルで利用例を見てみたいものです！:eyes:

https://speakerdeck.com/takuji31/kotlin-symbol-processing-api-ksp-woshi-tute-kotlin-a-purikesiyonnokai-fa-woxiao-lu-hua-suru?slide=11

# うわっ…もしかして私のコード、遅すぎ…？
by RyuNen344さん

https://fortee.jp/kotlin-fest-2022/proposal/c2f90120-95b9-4688-8834-2f92a7cf7406

パフォーマンスチューニングの旅は終わることがないですね。「軽率に計測しましょう」がキラーワードでした。

### kotlinx-benchmarks

- JetBrains が開発するベンチマークライブラリ
- Java 向けベンチマーク計測ライブラリ JMH（Java Microbenchmark Harness）のインタフェースを踏襲
- JUnit に似た書きっぷりのベンチマークコードで軽率に計測が可能

### Why In Benchmark Code
ベンチマークコードのサンプル（kotlinx-benchmarks v0.4.6）

https://github.com/Kotlin/kotlinx-benchmark/blob/v0.4.6/examples/kotlin-multiplatform/src/commonMain/kotlin/CommonBenchmark.kt

- 変数が `var` 宣言されているのはなぜ？：`val` で宣言されるような固定値は、コンパイル時に省略される可能性があるため
- 計測対象の戻り値を `Blackhole` で吸い取っているのはなぜ？：戻り値がないと、同上

### Trailrec Optimization
おまけとして tailrec を利用したベンチマークの比較をされていました。結果や計測・比較方法は資料をご覧ください。

https://speakerdeck.com/ryunen344/uwatu-dot-dot-dot-mosikasitesi-noko-do-chi-sugi-dot-dot-dot

### 所感
kotlinx-benchmarks を利用すると軽率にベンチマークの計測ができ、その結果も任意のファイルに吐き出せるので GitHub Actions 等を利用して継続的に検査できそうだなと思いました。💡
Web 業界にいるとトランザクション単位でパフォーマンスチューニングすることが多いですが、ネイティブのような環境ではそのチューニング方法も異なり、またマルチプラットフォームも意識しなければいけないという点で大変そうだなと思いました。

# もう迷わないCoroutines〜suspend funとChannelとFlow〜
by nyafunta9858さん

いまどき Coroutine による非同期処理は避けては通れないと思います。Coroutine の利用は初歩的に suspend fun を利用することが多かったので、どのような理由で Flow や Channel を使うのかという目的で拝聴しました。

### suspend fun

- 単一の値を返却
- 値を返却せずに中断し続けることも可能
- CoroutineScope 内でのみ呼び出し可能

### Flow

- 複数の値を受信
- 種類
    - Flow：cold stream
    - SharedFlow / StateFlow：hot stream
- 

個人的には、値を collect する際のショートハンドに `launchIn` が用意されているというのが、Kotlin っぽくてよいなとなりました。

### Channel

- 複数の値を送受信可能
- Flow 以前より存在
- 種類
    - SendChannel
    - ReceiveChannel

### 所感
大きく、単一の値を受取りたいのか？複数の値を継続的に待ち受けて受け取りたいのか？という目的で suspend fun と Flow / Channel を使い分ければよいと解釈をしました。また、エラーレベルの非推奨になる予定であることや置き換え可能な点で Channel より後発の Flow callbackFlow / channelFlow を（一部例外はありますが）利用するべきと理解しました。

初歩的には suspend fun を利用することが多いので、Flow　の利用はユースケースに応じて今後採用していきたいと思います。

https://speakerdeck.com/nyafunta9858/moumi-wanaicoroutines-suspend-funtochanneltoflow

# 総評
「Kotlin を愛でる」がテーマとなっていた今回の Kotlin Fest 2022 でしたが、私自身より一層 Kotlin に対する愛が深まったと思います。Kotlin 特有の記法だったり、命名だったり、ショートハンドだったり、Java では手が届かなかったところに手が届いていたりと。

他方、自分の Kotlin に対する理解の浅さも認識しました。無知の知です。今回参加しきれなかったセッションを含め、もう少し掘って内容を咀嚼していきたいと思います。