トーク

Jetpack ComposeのMultiplatform対応が安定版でリリースされ、1つのコードベースからAndroid/iOS/デスクトップなど複数のプラットフォームにネイティブUIを提供できるようになりました。
本セッションでは、Compose Multiplatformを用いてAndroid/iOSのアプリケーションを開発する流れを自身の経験を交えて初学者の方にもわかりやすく解説します。
あなたが既にKotlinに興味があったり触れたことがあるなら、Compose Multiplatformフレームワークを用いることで効率的にマルチプラットフォームアプリを構築できます。
マルチプラットフォームに興味はあるものの、何から始めたら良いか不安を感じている方も、本セッションを通してCompose Multiplatformへの第一歩を踏み出して頂けたら幸いです。

クリエイティブコーディングを行うソフトウェアにおいてはProcessingが広く知られています。 OPENRNDR ( https://openrndr.org/ ) はKotlinで書かれたクリエイティブコーディングのライブラリです。
私はこれまでに、中高生や大学生にプログラミングの講義をする機会に恵まれてきましたが、その経験からKotlinとOPENRNDRがたのしくコーディングするために優れたものであると感じています。

本セッションのトークでは、皆さんが今すぐOPENRNDRを使ってクリエイティブコーディングを始めたくなるような紹介を試みたいと思います。

Linter導入していますか？
Linterはコーディング規約を遵守しているかを検査したり、潜在的なバグのにおいを検知してくれたりと開発をするうえでとても頼りになる存在です。
また非常に多くのルールが標準で用意されているためこれらを利用するだけでも有用ですが、自分たちで適用するルールを選択したりカスタムルールを作成することもでき、柔軟な設定をすることができます。
一方でその柔軟さのあまり、使いこなせていないと感じたり、実は形骸化してしまっていてるといったケースもあるのではないでしょうか。

本セッションでは、ktlintやdetekt、Release1.0間近のKonsistといったKotlin向けのLinterの特徴や活用シーンなどを再履修し、「なんとなく」から「意識的に選択・活用できる」ようになることを目指したいと思います。

OkioはSquareが開発しているjava.ioとjava.nioの取り回しを楽にしてくれるラッパーライブラリです。言わずと知れたOkHttpやMoshiのベースにも使用されているライブラリです。
Kotlinで書き直された2.0.0よりMPP（KMP）対応が行われ、3.0.0でファイルシステム周りの機能が追加されました。
KMP（android, iOS)プロジェクトで実際に使用した私がありがたいと感じた部分についてお話しします。

本セッションでは下記のことを取り扱います。

・標準ライブラリが強力なKotlinでなぜOkioを見直すのか
・KMP実装にIO周辺実装での諸課題
・KMP実装においてもOkioがもたらすメリット
・Okioを使用する際の注意するべき前提

Kotlin Coroutinesを使えば非同期処理を比較的簡単に書けますが、それでも複数のコルーチンから共有リソースにアクセスするときには最大限の注意を払う必要があります。

例えば、あるコルーチンで変数を読み込み、その値を元になにか操作を行い、結果をもとにその変数を上書きするとします。
その間に他のコルーチンによって値が書き換わることはないでしょうか？
その結果、予期せぬ不具合を引き起こしたりしないでしょうか？

正しく共有リソースを扱うためには、MutexやStateFlowのupdate関数など、それが考慮されたAPIをうまく組み合わせる必要があります。
また、1スレッドを使い回すディスパッチャと複数スレッドを使うディスパッチャがありますが、気をつけるべき点は異なります。
このセッションではどのようなコードで注意が必要なのか、また期待通りに動作させるための方法について紹介します。　

Kotlin Multiplatform (KMP)は新しいKotlin開発のトレンドとなり、日々AndroidやKotlin/JVM専用だったKotlinライブラリがKMPに移行しています。Kotlin生態系を発展させていくには、われわれがKMPに対応したライブラリを公開していく必要があります。

Kotlin 2.0に向けて、wasmJsターゲットが追加されたKotlin本体も、Gradleプラグインやプロジェクト構成も、大きく変わってきていますが、KMPの本格的なライブラリ生態系には不可欠であろうネイティブライブラリの呼び出しや、それらを踏まえたMavenパッケージのビルドや配布など、未整備の部分も多いです。

このセッションでは、2024年にKMPでライブラリを構築して公開するまで、どんな課題をどうやって乗り越える必要があるのかを、自作ライブラリの経験をもとに皆さんに共有します。

kotest は、 Kotlin ネイティブなテストフレームワークで、Kotlin で書かれたコードをテストするための強力で便利な機能が多く含まれています。
Kotlin/JVM では、テストに JUnit を使っている方が多いと思いますが、アサーションライブラリが Java しか考えていなかったり、coroutines, 非同期処理への対応が弱かったりと、もっと Kotlin の機能を最大限に活用して快適にテストを書きたいと思われる場面も多い事でしょう。
kotest は、アサーションライブラリだけを JUnit と組み合わせて使うこともできるし、テストフレームワーク全体を kotest へ置き換えることも可能です。
このセッションでは、主に今 JUnit を使ってテストを書いている方を対象に、kotest へ移行するとどんな良いことがあるのか、移行のやり方や具体的な実例を紹介します。

KotlinではCoroutineを用いることで、非同期処理を手続き的に記述できます。
Coroutineの利用例として「ネットワークアクセスをwithContext(Dispatchers.IO)でラップすることでIOスレッドで行う」という例が紹介されることが多いです。
そのため、「withContextはスレッド切り替え時に使う」という理解をされている方は多いと思います。
しかし、実際にはwithContextはCoroutineContextを切り替えるために利用するものであり、スレッド切り替え以外にもさまざまな活用法があります。
本セッションでは、CoroutineContextについて触れたうえで、筆者のチームがwithContextをどのような場面で活用しているかを紹介したいと思います。

Jetpack Compose（以下、Compose）の登場により、AndroidにおけるUIの記述はView/XMLの時代から大きく変化しました。
Composeのような宣言的UIでは、与えられた入力値を元にUIの全てが決定するため、コンポーネントが何のパラメーターをどのように持つのか、といったAPI設計が品質に大きく影響します。
また、Composeは関数をベースにした記述方法であり、Kotlinの言語機能も上手く活用したAPI設計が必要になってきます。

本セッションでは、State hoistsingやState holder class、Slot API、Relaxed APIといったComposable関数のAPI設計にまつわるベストプラクティスについて軽く触れたのち、
それを、いつ、どのように適用していくべきか、是非を含めて実例を元に実践的な議論をしていきます。

サービスの体験をパーソナライズし、興味のあるコンテンツを楽しんで貰うためには、
各種クリエイティブ（バナー・ポップアップ等）のターゲティング（by 年代、性別、OS、etc）が欠かせません。

最初は個別に実装する事が多いですが、露出面nとターゲティング条件mが増えた場合、O(n x m) の実装・メンテナンスコストがかかってしまい、共通化が必要となります。

今回の発表は、新規作成された共通化Platform上における課題：『マーケターを初めとする全社員が、ユーザーの条件やその AND/OR/NOT の任意の組み合わせによるターゲティングを可能とする』を、
Kotlin で実装した YAML ベースのユーザーターゲティングDSL（独自言語）とその処理系によって解決した事例の紹介となります。

安定的な拡張を行うためにKotlinの型が果たす役割についても取り上げます。

現代では広く使われているKotlin言語ですが、2011年に公開されて以降、さまざまな発展を遂げてきました。

ソフトウェアは、利用者のニーズや開発環境の変化により日に日に「進化」します。ソフトウェア工学の研究分野においても、特に1990年代後半からソフトウェア進化は活発に議論され始め、今では研究手法、研究対象物、目的はさまざまです。中でも、SEV(Software Evolution Visualization)は、可視化を用いて対象とするソフトウェアの進化を分析するアプローチです。

このセッションでは、SEVの手法を用いてKotlinの進化を紐解きます。Kotlin開発当初の思想や目的、他の言語との関係についても触れつつ、可視化結果とその解釈を発表します。