トーク

Kotlinが誕生してから11年が経過しました。たくさんの方に愛されているプログラミング言語なだけあって、多数のブログや勉強会にて最新情報をキャッチアップできます。しかし、ブログや勉強会で発表してる人のように自分からKotlinの情報を取りに行きたいですよね？

本セッションでは、Kotlinの１次ソースの活用方法を知って、あなたのお悩みを解決します！
・Kotlinの標準ライブラリを使いこなしたい
・Kotlin関連の最新情報をキャッチアップしたい
・ググって問題解決より突っ込んだ情報を得たい

セッション内容
・標準ライブラリの関数編
　・公式ドキュメントの歩き方
　・ソースコードの歩き方
・Kotlin+周辺ライブラリの最新情報編
　・Release notesの歩き方
　・PR/Issueの歩き方

Android のモダンな UI ツールキットである Jetpack Compose では、State の持つ値に Delegated properties でアクセスすることがよくあります。
このセッションでは Kotlin の Delegated properties について解説し、Android のライブラリでどのように利用されているかを紹介します。

Kotlin はその最初のリリースから Java との高い相互運用性を持ち Better Java としての地位を確立してきました。
2022年現時点では Kotlin も 1.7 がリリースされ Java も 19 がリリースされています。
これら進化の中で Java も多くの機能拡張がされ、現在の Kotlin の言語仕様では表現できない高度な機能も存在し始めています。

このセッションでは、Java に現在実装されているもしくは導入が検討されている機能の中で、現在の Kotlin では表現できない機能について、どのようにその機能差分を埋めていく想定なのかを KEEP を見ながら紹介し、Kotlin の未来について考えてみたいと思います。

自分の所属するマネーフォワード 名古屋開発拠点では、この1年間GraphQL Kotlin + Spring WebFluxを使ったGraphQLサーバーの実装に取り組んできました。

GraphQL KotlinはGraphQL Javaをラップし、KotlinでのGraphQLクライアントとサーバーの実行を簡素化してくれるライブラリです。
しかしGraphQL Kotlinに関する情報は少なく、実装例もほぼ皆無だったため、自分たちも初期の頃はもがき苦しみました…。

本セッションではGraphQL Kotlinのハマりどころや利用すべきライブラリの機能や使い方を、成功した・失敗し改善した経験をもとに知見を共有します。
今後、GraphQLサーバーの開発を予定している方の選択肢として、サーバーサイドKotlinひいてはGraphQL Kotlinを検討する際の一助となればと思います。

Kotlinでマルチプラットフォームのモバイルアプリケーション開発を行えるKotlin Multiplatfrom Mobileが2022年10月にBetaとなりました。
JetBrainsはKMM Betaに向けてさまざまな改善に取り組んできましたが、その中でもNew Memory Managerに注力していました。旧Memory ManagerのKotlin/NativeにおけるKotlin coroutinesや並列、非同期処理の課題がKotlin 1.7.20で改善され、新Memory ManagerはBetaステータスとなっています。
本セッションでは、旧Memory Managerの課題とこれまでの対処方法、新旧の比較(仕組み、実装方法、パフォーマンス)、マイグレーション方法、関連ライブラリ(Kotlin coroutines、Ktor)の変更点などをご紹介します。

今年の６月にリリースされたKotlin 1.7には、K2という丸ごと新しいKotlinコンパイラがプレビューされました。
これはJetBrainsの１０年以上のKotlin開発経験を活かし、改めて、発展性、安定性、そして何よりもパフォーマンスを上げるのを目標にしたプロジェクトの成果なのです。
本セッションでは、以前のコンパイラとの仕組みを比較をしながら、一般のユーザーにとって何が変わるのか、について発表します。
IntelliJ IDEAのKotlinプラグインの開発者として、プラグイン側の改善についても話したいと思います。
具体的な説明も多少入りますが、コンパイラ内部をあんまり触ったことがない人でも理解出来ると思いますので、是非お越しください。

Gradle Kotlin DSL の stable リリース(Gradle 5.0)からそろそろ丸4年が経ちます。しかし、Groovy による記述が Deprecated になったわけではありません。これは利用者側が2つの言語を理解できることを依然として要求しますし、Gradle Plugin を提供するなら2つの言語に対して頑強でストレスフリーなインターフェースを提供し続ける必要があります。

そこで本トークでは Gradle Kotlin DSL の仕組みを通して Groovy との対応といった具体例を紹介して理解を深めるとともに、Gradle Plugin を制作する上で Groovy/Kotlin DSL の相互運用性のポイントをいくつか紹介します。Kotlin DSL が絡まない Gradle Plugin 開発の Tips は特に紹介しません。

contracts や genericsなど Kotlinは静的型付け言語トップレベルの型機能を有しています。
しかし我々はそれらのリッチな型機能を上手に使いこなせているのでしょうか？
本セッションではKotlinの型機能を使ってコンパイルで検出できる実装ミスを増やしアプリケーションの品質を高める方法を説明します。
Kotlinの機能紹介のみに終始せず、具体的な実装ミス・バグを例にとりながら具体的な実装パターンを紹介していきます。

以下目次

1. なぜ型を使いこなすことでバグが減るのか？
2. 型によってバグが減らせる3パターン
   1. 標準の型をラップする
   2. 認可処理などの特定の処理をパスしたことを型で示す
   3. 型でデータの不整合をなくす
3. まとめ
4. 最後に: タイプセーフなポストモーテム

普段Kotlinを使ったアプリケーション開発において、アノテーションプロセッサーを使ったコード生成は至るところで利用されています。
Kotlinでは近年KSPが登場し、メジャーなライブラリーの対応が進むなどkaptに代わって主流となりつつあります。
しかし、多くの方はアノテーションプロセッサーを使ってコードを生成することはあってもプロセッサーそのものを作って活用することはないのではないでしょうか。

このセッションではKSPのプロセッサーを作る方法や、実際に私がKSPのプロセッサーを実装して開発に活用した様子や困ったことの解決方法を紹介します。

• KSPを使う理由
• KSPのプロセッサーを作る
• マルチラウンドに対応する
• インクリメンタル処理に対応する
• マルチモジュールでプロセッサーを活用する
• プロセッサーをテストする

Compose MultiplatformではDesktopとAndroidのUIは共有できる部分が多く、コードも共通化することができます。しかしCompose for Webではそれができません。なぜなら通常のCompose UIと違い、web-coreモジュールによってDomでUIを作らないとならないためです。

10月にリリースされたCompose Multiplatform 1.2では、experimentalながらもDomではなく共通のUIをブラウザでも利用できます。

本セッションではSkia+WebAssemblyで実現されているこの機能が、現状どういったことができるのか紹介します。

Test Fixture と呼ばれる形で、テストで多用される前提条件やインスタンスの集合体を適切に管理していくと、ユニットテストが非常に書きやすくなります。

従来 Fixture を CAPITAL_CASE で定義して使い回していましたが、IDE による補完が効きにくいため再利用がしにくいという問題がありました。
そこで、クラスに対する拡張関数として Fixture を定義する事で、Production コードを汚染せずに、IDE による補完の恩恵を受けられる管理ができるようになりました。

セッションでは、具体的な記述方法や、IDE で補完される場合の体験を、デモを交えながら紹介させて頂こうと思っています。

（45分枠であれば、Gradle の TestFixturePlugin ついても、組み合わせた事例も交えつつご紹介します）

Kotlin製のモダンUIツールキットであるJetpack Composeには、デスクトップおよびWebアプリのUI開発に対応したCompose Multiplatformという拡張版が存在します。Kotlin Multiplatformの機能をフルに活用し実装されており、その豊富な表現力はKotlinエンジニアに多大な恩恵をもたらします。

本セッションでは、発表者が自身のポートフォリオサイトをリライトした経験から、特にWebアプリのUI開発に対応するCompose for Webを利用し、モダンなSPAを実装・リリースするための一貫した知見を紹介します。また、Kotlin/JS + Reactの構成で実装した複雑なWebアプリをCompose for Webでリライトしながら得た知識も踏まえ、KotlinによるWebフロントエンド開発の現在地について詳しく解説します。

株式会社ヘンリーではサーバサイドをKotlin（gRPC, Ktor, Koin etc.）で書いています。サービスの品質を高めるため、また拡大期にあるチームへのボーディングを簡単にするため、Detekt拡張を実装して利用しています。
このセッションではどのような課題を解決するためにDetektを利用したか、その結果どのようにコーディング体験が改善されたかをご紹介します。

書いているコードが処理に最適化されているか心配になったご経験がある方はいませんか？
そんな不安を解消できるライブラリが公式からkotlinx benchmarkとして発表されています
kotlinx benchmarkを使用して処理速度を計測し、無駄なマシンリソースを消費しないコードを書きましょう！

話すこと

• kotlinx benchmarkについて
• JVMとその他Platformでの違い
• 実際の計測
• tailrecなどの言語レベルの最適化が及ぼす影響

私は主にRailsでサーバーサイド、Reactでフロントエンドを実装する開発者でした。

しかしある日「Kotlinやらない？」の一言から初めてKotlinと出会い、新規プロダクトのサーバーサイド開発をKotlin、GraphQLで始めることになるのでした。(*ExpediaのGraphQL Kotlinを使用）

・初めてのサーバーサイドKotlinで苦労したこと
・なぜ、チームで誰もGraphQL、Kotlinを触れたことないにも関わらず新規プロダクトの開発がスムーズに進んだのか？
・Kotlin独自の機能がDDDとマッチしたこと

このセッションではKotlinもDDDも新規プロダクトも初めての私がKotlinでの開発で魅了された点、苦労した点、サーバーサイドKotlinを選択してよかった！と思えた体験をお伝えし、サーバーサイドKotlinへ踏み出す一歩を後押しできればと思います！

Kotlin1.3でstableになったCoroutinesは今では1.6となり、Androidアプリ開発においてはFirst Class Coroutines Supportとされてから3年が経過しました。私達のチームでも導入されており、もはやなくてはならない存在になったと感じています。
そんなCoroutinesですが、suspend function、Flow、Channel、使い分けられていますか?BroadcastChannelとMutableSharedFlowのどちらを使ったらいいか迷ったりしてませんか?

このセッションでは、kotlinx.coroutinesの最新バージョンをベースにCoroutinesの基本的な使い方を改めて抑えつつ、なんとなくで使っていたChannelやFlowなどをシーンに合わせて選択できるようになることを目指します。

NewsPicksはローンチから10年近く経っている大きなコードベースのwebアプリケーションです。
もともとはJava+Springで開発されていましたが、開発生産性を向上させる取り組みの一環として2021年末にKotlinを導入し、一年が経過しました。
いまでは新しいコミットはほぼKotlinで行われるようになっており、開発しやすさの体感は確実に向上しています。

この1年間で得られたJavaからKotlinへの移行を滑らかに行うためのノウハウ・役に立った言語機能などを紹介します。

• やりたいのは生産性向上であって移植ではない
• 動いてるコードに触らないままKotlin化するテクニック
  • JvmNameアノテーション、移譲、拡張メソッド
• kotestとJUnitを併存させる
• Optional、Streamを廃止しKotlinらしく書く

皆さんご存知の通り、Kotlin には便利で有用な言語機能が豊富にあります。拡張関数・スコープ関数・null許容型・sealed class・data class・コルーチンといった言語機能は、「もう手放せない」という人も多いでしょう。

しかし、有用なはずのこれらの言語機能も、むやみに使ってしまうと有用でなくなってしまうかもしれません。大切なのは、言語機能を使いたいから使うのではなく、「何を改善するのか」という目的を明確にして使うことです。

本セッションでは、我々のチームで共有している「可読性を下げてしまうような不適切な言語機能の使用例」と、「それを防ぐためのベストプラクティス」のいくつかを紹介します。特に、「何となく読みやすいから」ではなく、ベストプラクティスの理由を言語化することに焦点を当てます。

普段のコードレビューで、より建設的な議論を行う足がかりとしていただければ幸いです。

このセッションでは登壇者が自作しているOSS "kotlin-csv"（https://github.com/doyaaaaaken/kotlin-csv ）についてGithubのStar数450超になるまでどのようにして普及させたのかについて紹介します。

自作OSSというと『プライベートの時間を多く費やして』『自身の技術的ロマンを詰め込んだものを作る』イメージがあるかと思いますが、登壇者は『なるべく時間を使わずメンテでき』『技術的ロマンはなくてもいいので』『世界の人々から実際に使われる』ライブラリにすることを戦略的に目指して作りました。
なぜそういった目標を立てたのか、目標実現のために立てた戦略、開発中に直面したトラブル、開発後の運用で得た気づきなどについてなるべく具体的に共有することで、今後自作OSSを作る人・作りたい人の参考になる内容にしたいと思います。

Kotlin Coroutines は、もはやAndroidアプリ開発において必須の技術となりました。
私達のチームでも Kotlin Coroutines を本格的に導入して数年が経ち、既に多くのコードがコルーチンベースで書き換えられています。

Kotlin Coroutines を用いることで非同期処理などが簡潔に記述できるようになりますが、Androidアプリ上で利用する場合はライフサイクルやキャンセルの扱い方など注意すべき点がいくつか存在します。
今回は、我々のチーム内でのコードレビューから得られた数多くの知見を紹介し、Androidアプリ開発における Kotlin Coroutines のより良い使い方について発表します。