多分聞き間違えたりしているところがあると思いますが、面白かったり驚いたところを太字にしたりして、共有します。
Kotlinを愛でようというコンセプト。
KotlinConf 2024 を後から256倍楽しむためのヒント
@ masaruhr さん
キーノートは？
K2:
コンパイル時間、ハイライトまでの時間が短くなる。文法的な変更は最小限に。"K2のKotlin IDEプラグインの中を覗いてみよう♪"で聞けそう。
Multiplatform:
Fleetという多言語対応のIDEを出している。Swiftとかも触れる。
IDEの生成AIの機能など
どうやって見るか？
タイトルとChatGPTのサマリーを見て、良さそうだったら動画を見るというのがおすすめ。以下にまとまっている。
JetBrainsはコミュニティ支援を色々やっているという話。イベント開くとライセンスがもらえるなど。
今こそ始めたい！Compose Multiplatform
Kotlin Multiplatform Wizardで始めるのがダウンロードして始めるのが簡単でおすすめ
Previewできない問題。
androidMainにPreview置くか、commonMainにPreviewをおいてFleetを使う。
(以下のような方法もある。)
iOSではBackHandlerやDeeplinkは未サポート。
以下のようなツイートもあった。
iOSのUIAlertControllerをComposeから表示したりもKotlinで書いて実装できる。
DIはinterfaceをcommonMainにおいて、プラットフォームで実体を入れたりして行う。
サーバーサイドKotlin
最近のサーバーサイドKotlinで使えるフレームワーク
Ktor
軽量。プラグイン機能により、柔軟な機能追加ができる。
Micronaut
マイクロサービス、サーバーレスアプリケーションのためのJavaフレームワーク。Ktor構文もサポート。
gRPC-Kotlin。
protobufからKotlinコードを作って、使うことができる。
gRPCを使わない場合はMicronautとか考えられる。
(Ktorを選択、軽量高速。アップデート追従など。発展途上ではある。)
DI
Daggerは複雑などがあり、Koinを選んだそう。
こんなツイートも。
O/Rマッパー
Exposed: JetBrainsのO/Rマッパー
SQLっぽくかけるDSLか、DAOか2つのアクセス方法がある
昔からあるが、今年中に1.0に
JOOQ: もともとJavaのフレームワーク。
テーブルスキーマからコード生成できる。Kotlinも生成可能。
R2DBCによるノンブロッキングI/O対応。
Ktorm
JDBCに基づいたKotlin用の軽量 O/Rマッパー
どれを選んだか？JOOQ。テーブルスキーマからコード生成できるのが大きい。成熟している。
Exposedは今後有力な選択肢になるかもしれない。
テストフレームワーク
Kotest
裏側はJUnit
データ駆動テストなど強力な機能がある。
DescribeSpecを使うと階層化して、テスト書ける。良さそう。
Spek
BDD形式で書ける
Spek 2.xではマルチプラットフォームも念頭において開発された。
ただ、最新リリースが2年前。
DescribeSpecと同じものが使える。
(技術選定をした理由を話しているいいセッションだったので、サーバーサイドの開発をKotlinでしている人は一回見ておくと参考になりそうです)
Kotlinの未来
サーバー開発において、一番人気ではない。
言語の利便性やクオリティが高い
やっていき
KotlinのLinterまなびなおし2024
detektはルールがKtLintの3倍ぐらいある。
detektのフォーマッターは拡張機能で、detektのformatはissueで議論されているので気をつけたほうが良さそう。
Composeのカスタムルールセット: Jetpack Compose Rulesというがある。KtLintでもDeteKtでも使える。(30種)。もともとのTwitter社のものはアップデートされていないので注意が必要。
大きな規模ではDetektでそれ以外はKtLintがいいのではということだった。
Konsistはアーキテクチャや宣言の検査。
例えばUseCaseのクラス名や、クラス内にメソッドは一つ。パッケージ間の依存関係など。
Konstは別でモジュールを作ってそこから参照して、管理するのがおすすめらしい。
Building Kotlin Multiplatform Libraries in 2024
なぜKotlin Multiplatformでライブラリを作るか？ ライブラリが、Android専用かーみたいになってしまう。
Library authors guidelineというKotlin公式のガイドが更新された。
APIの互換性。ビルド時のエラー。
ABIの互換性。実行時のエラー。
挙動の互換性。想定外の挙動。
ABIの互換性を担保するには、data classを使ってはいけなかったり、関数の引数を増やさないなど。
kotlin binary-compatibility-validator を入れて確認するのが良い。
Kotlin nativeのクロスコンパイルのissueはこれとその関連issue。現状はmacosビルドが必要でその対応が検討されている。(これ気になっている情報だったのでありがたい)
https://youtrack.jetbrains.com/issue/KT-52666/Kotlin-Multiplatform-libraries-without-platform-specific-code-a.k.a.-Pure-Kotlin-libraries-Universal-libraries
新規ユーザーはpublish方法が変わって、サードパーティのpublishのGradleを入れないといけない。このスピーカーの方が作った方法もあるそう。
ライブラリを作ったら以下で宣伝できる。
https://libs.kmp.icerock.dev/
Kotlin Foundation Grantsなどのお金がもらえるプログラムもある。
K2時代のKotlin Compiler Plugin開発
コンパイラで行われるフェーズの説明があった。
色々メモを書いたんですが、まとめると、FrontendとBackendのフェーズがあって、Extensionというのを使うとCompiler Pluginでそのフェーズの拡張ができる。例えばgreet関数を増やしたければ、functionを追加するExtensionを使うとFrontendのフェーズで関数定義を追加し、別のExternsionを使ってBackendでその関数の実装の追加を行ったりする。
おすすめのセッションです。
Compiler PluginはFontendもBackendも介入できる。
FirSupertypeGenerationExtensionを使うとスーパータイプの追加ができたりなど。
FrontendのSuperTypeフェーズに介入したりする。
FirDeclarationGenerationExtensionだと複数のフェーズに介入し、独自のコードをいれるなど。
FirExtensionが上のExtensionたちの基底クラス。FirSessionComponentがFir拡張の実装に必要な情報を提供する。
Predicateを基軸に実装されている。Predicate = シンボルのマッチングパターン。アノテーションベースに処理対象を特定する。
2種類のPredicate、LookupPredicateマッチするシンボルを返却。
DeclarationPredicateは宣言がマッチするかを判定 (true false)
Predicateの利用パターン。@ Markerというのを使っていたら、annotated(FqName("Maker"))で取り出せたり、parentAnnotated(FqName("Maker"))でメソッドをとりだしたりできる
Predicateはアノテーションベースで動くので、アノテーションはTYPESフェーズで動くので、COMPILER_PREQUIRED_ANNOTATIONSで先にアノテーションを登録しておく必要がある。
バックエンドに関してはIrGenerationExtensionを使って介入できる。IRノードの変換などができる。IRの改変はIrElementTransformerを使ったりする。
Pluginのアーキテクチャ。SubpluginOptionがKotlinが受け取って、CompilerでCompilerConfigurationにマッピングする。
例
@ Greetableをつけるとgreetメソッドが生えて挨拶してくれるPluginを例に話す。
モジュールはアノテーションとコンパイラープラグインとテストを作る。
テストのモジュールででkotlinCompilerPluginClasspPathでコンパイラープラグインのモジュールを指定する。
Frontend拡張の実装では、GreetablePredicateを定義して、DeclarationPredicate.createでアノテーションのpredicateを作る。FirDeclarationGenerationExtensionを継承して、getCallableNamesForClassを実装し、そこでpredicateをみて、アノテーションがついていればマッチするように返して、genreateFuctionも実装して、createMemberFunctionという関数で関数を生やす。
その追加した関数の中身を実装はバックエンドでやる。IrGenerationExtensionのgenerateを実装し、Transformerを渡す。Transformerの実装ではIrElementTransformerVoidを実装し、pluginContext.referenceFunctionsでprintlnのsymbolを作成し、それをvisitSimpleFunctionで、処理対象をフィルタリングして、plluginKeyっていうので、フロントエンドで生成したものを特定できたりする。
symbolにIrBuilderでirBuilder.irBlockBody {}内でprintlnを実装する。printlnの関数呼び出しはirCallを行う。
これらのExtensionをCompilerPluginRegistrarで登録する。
活用例
Composeなど
Time Travel Debuggingプラグインというのを作った、過去の状態をキャプチャして、再現できる。
これをWeb Soketで実現している。
Ask the speaker
(ここでAsk the speakerでセッションから離脱)
どうやってこのフェーズの情報得たの？
そういうコメントがたくさん書いてあるファイルが有った。
Time Travel DebuggingのあのUIのツーリングどうしている？
Flipperプラグインを使っている。つなげる仕組みが使える。依存してしまうのはややこしいがiOSでも使えそう。今はそのあたりの開発をしている。
Compiler Pluginって今IDEに読み込まれるの？
今実はgreeting関数はIDE上では赤くなったりする。
JetBrainsの方: Alphaのやつでいけるようになると思う。
(ここから"K2のKotlin IDEプラグインの中を覗いてみよう♪"の発表をしたJetBrainsの方がいらしたのでその方とのメモ)
Kotlinで公式フォーマッター作らないの？
とりあえずインスペクターだとQodanaあるので見てみて。
(スクショテストのライブラリ作ってるんだけど、)Kotlinコンパイラって割とコードダンプベースのテストだけど辛くない？
PRを小さくすることと、割と再生成することで大丈夫だよ。
K2ってmainブランチで開発したの。？
フラグ + フォルダ分けで開発されてた。
Amberって結局拡張したくなるんじゃない？？
そういうのも考えてる。
K2のKotlin IDEプラグインの中を覗いてみよう♪
以前のIDEプラグインは解析エンジンを共有するのは決まっていたが、どうやって共有するのかが決まっていなかった。キャッシュして、Lazyにしてやっていた。スレッドでロックしてしまっていたりして、そのロックが外せなかったのを、解決しようとした。
フェーズ分けして、並列化できるようにした。今はlockがない。パフォーマンスが良くなった。また今までできないことができるようになった。今まではfind usageを解析している間は、ハイライトされなかったが、ちゃんとされるようになった。
今までは何かを消したときに、すべてのモジュールのグラフの情報を消して作り直していた。それが改善されたりした。ソースコードだけでなくライブラリも。
Metadataにprotobufにデータ入れて、IDEなどから受け取っていたが、それが今まではLazyで受け取っていた。ただ、Classの情報でStubだけにした。今まではメモリモリモリで開発していたが、2GBで割と動くようになった。
one more thing
Kotlin Analytics API。おそらく初めての発表。Kotlinコードを解析するライブラリ。ドキュメントがあり、マイグレーションガイドもある。 CLIでコマンドラインでも使えるようになる。KSP, Dokkaなどでもう利用されている？そう
Kotlinの歴史を可視化する
分析の原則ととして以下がある
Overview first, zoom and filter, then details-on-demand
分析手法を学べるセッション。
いつ頃からSwift対応が始まったかなどがわかる。
感想
会場での印象として、スポンサーでもかなりいたりして、意外とサーバーサイドでKotlin使っている人の割合が意外と多いのではと思いました。
Compose Multiplatformなども話題に上がっていて、Kotlinの今後の可能性に期待したいですね。