トーク

自分はわかっていませんでした。
HTTPクライアントでJSONレスポンスを扱う際、型変換の冗長な実装をジェネリクス使って書いたぐらい。
その時もコンパイルエラーと戦って試行錯誤してなんとか乗り切っていました。

本セッションでは、Kotlinの機能である inline + reified 型パラメータを使った関数がどのように振る舞うか、何が理解できたらコンパイルエラーに勝てるかを考えていきます。

話す内容

• クラス情報の受け渡しが不要な、型推論を活かしたAPI設計
• List<User> のようなジェネリック型も正しく扱える型安全性
• inline + reified を使う最も適したケースは?
• HTTPクライアント実装における reified の実践的な活用パターン

大規模なKotlinプロジェクトでは、数百から数千の依存ライブラリが存在し、それらの管理は容易ではありません。 また、昨今のサプライチェーン攻撃の高度化により、依存ライブラリ管理の重要性も増しています。

そこで、本セッションでは、開発者目線の、Gradle/Trivy/GitHub Actionsを用いた依存ライブラリ管理の自動化パイプラインの構築例を紹介します。

本セッションのポイント

• Gradleのdependency関連機能について
• 既存のSBOMツールの課題とLockfile & Trivyによる解決
• GitHub Actionsによる自動パイプラインの構築
• OSSスキャナを用いた定期的な脆弱性スキャンの導入

Kotlin ScriptによるGradle Taskの実装例も交えつつ、明日からでもすぐに試せる、段階的に導入できる実践的なテクニックを紹介します。

アプリを開発していると「SNSでシェア」や「レポートを出力」という処理を実装することがあります。
その際、表示されている画面をそのままキャプチャする場合は問題ないのですが、そうではないケースも存在します。
例えば、シェア用にロゴを追加したい場合や、縦向き画面を横向きで画像生成したい場合です。

この際に役立つのが、画面に表示していないUI要素から画像を生成する技術です。
alpha=0FやViewCompositionStrategy、NoTouchFrameLayoutを組み合わせることで、
画面表示とは独立したシェア専用UI要素のキャプチャが実現できます。
実際のプロダクトでの実装例と共に、この実用的な技術をお伝えします。

CMPのiOS版がStableとなり、UIを一つのコードで表現できるようになりました。しかし、iOS側のUIがマテリアルデザインになってしまうというデザイン制約から、CMPではなくKMPを選択することも多いのではないでしょうか。

本セッションでは、大部分のUIをComposeで共通化し、iOS特有のこだわりがあるUIをSwiftUIで記述するハイブリッドCMP開発の手法についてご紹介します。この手法はiosAppモジュールに配置したSwiftUIをKoinでsharedモジュールに提供し、画面単位またはUIパーツ単位でSwiftUIをComposeの画面に埋め込むことで実現できます。これによりCMPの利点であるUIのコード共通化を行いつつ、デザイン自由度の制約を最小限にできます。

このセッションを通じ、iOSのUIにも妥協したくない人がCMPという選択肢を選べることを願っています。

Claude CodeやGitHub Copilot, Cline, Junie等のコーディングエージェントはもはやソフトウェア開発に欠かせないツールと言えるでしょう。

しかし、これらのツールをKotlin開発で効果的に活用するには、Kotlin特有の言語機能や慣習を理解した上での使い方が重要です。
本セッションでは、コーディングエージェントとの協働でKotlinらしいコードを生成するための実践的なテクニックを紹介します。
また、具体的なプロンプトの書き方やKotlin固有の機能を正しく生成させる方法、MCPサーバ等のツールの使い所などについて触れていきます。

本セッションでは以下の内容を含みます。

• コーディングエージェントを使っていて辛いところ
• 辛さをのりこえるために工夫していること
• 人間がやったほうが良いこと

Kotlinではイミュータブルなプログラミングスタイルが推奨され、kotlin.collectionsではListのようなイミュータブルなデータ構造が好まれます。
しかし、これらはミュータブルなコレクションへのダウンキャストが可能であったり、結合時に線形時間がかかったりといった欠点も存在します。

本セッションでは、この課題に対する選択肢として、kotlinx.collections.immutableで提供されるPersistentCollectionを紹介します。
PersistentCollectionは関数型プログラミングで頻繁に用いられるデータ構造であり、上記のイミュータブルコレクションが抱える欠点を克服しています。

本セッションが、PersistentCollectionの理解を深め、最適なコレクションライブラリを選択する一助となれば幸いです。

Coroutine、FlowはKotlinの便利な機能ですが、うまくテストできているでしょうか？
テストをうまく制御できなかったり、うまくテストできず、修正まで時間がかかってしまうこと、ありがちだと思います。

本セッションでは、CoroutineやFlowのテストに絞って、ポイントやハマりどころを解説します。
Flowのテストでは、Turbineというライブラリもご紹介します。
さらにこれらのテストの可読性や保守性を高めるためのTipsもご紹介します。

内容
・Coroutine、Flow、suspend関数のテストの基本とポイント
・Turbineライブラリの紹介
・機能テストなど大きめのテストでCoroutine/Flowを制御する方法
・テストダブルでうまくCoroutine/Flowを制御する方法

Kotlinの言語機能ではないものの実際の開発で便利な機能がkotlinxライブラリとして提供されています。
馴染みの深いものだとcoroutiesやserializationなどは日常的に使っているのではないでしょうか。

そして、kotlinxには他にも多くの便利なライブラリが存在し、それらを適切に活用することで、よりよいコード、開発体験を得ることができます。
本セッションでは、よく知られたものからまだあまり知られていないものまで、kotlinxライブラリ群を紹介していきます。
また、各ライブラリがどのような課題を解決し、実際のプロジェクトでどう活用できるのか、具体的なユースケースとコード例を交えながら解説します。また、コミュニティライブラリとの使い分けや、言語公式のライブラリを利用するメリットについてもお話します。

Kotlinコミュニティ、特に地域Kotlinコミュニティは他のプログラミング言語と比べて意外に少ないのが現状です。
「ないなら作れば良い」という精神のもと、私は今年1月に京都でKyoto.ktを立ち上げました。
キックオフから現在まで計4回のイベントを開催し、徐々に参加者も増加しています。

本セッションでは、コミュニティを始めるモチベーションから初回開催までの具体的な道のり、継続運営のために心掛けていることなどを実体験ベースで発表します。
そのほか開催後に得たことや、学んだこと、地域ならではの特色などについてお話ししたいと思います。

このセッションをきっかけに「自分の地域でもKotlinコミュニティを作りたい！」と考えている方の後押しができればと考えております。少しでも何かの参考になれば幸いです。
あなたがお住まいのその地域で「ご当地Kotlinコミュニティ」を爆誕させてみませんか？

みなさんはZodというTypeScriptのライブラリをご存じでしょうか。例えばメールアドレスを文字列として渡すと、それをパースして正しいメールアドレスの形式か？を判定してくれたりします。

では iolite というKotlin版ZodなOSSライブラリをご存じでしょうか。おそらく知らないと思います。なぜなら私がこのプロポーザルを書く5分前に公開したライブラリだからです。このライブラリはGeneric Value Objectの集まりとでも呼ぶべきものです。

このセッションでは、

• ioliteはどのようなものか
• ioliteはどのように使えるのか
• ioliteはどのように実装されているのか
• 開発にあたって使ったツール
• リリースまで苦労したこと
  についてお話しできればと思います。

業務オブジェクトが複雑化すると、新しい状態を追加するたびに「既存ロジックが壊れないか」と不安になりませんか？

私たちのプロジェクトでも同様の課題に直面しました。機能追加とともに業務オブジェクトの責務が肥大化し、プロジェクトが進むにつれて、さまざまな状態や処理が1つのクラスに集約され、ビジネスロジックが複雑化していきました。多様な状態を1クラスに詰め込んだ結果、可読性と保守性が低下し、新しい状態を追加するたびに既存ロジックへ影響するリスクが高まっていました。

本セッションでは、この複雑化したクラスを状態ごとに分割し、sealed class による状態モデリングを導入することで、「不正状態をコンパイル時に検知し、実行時には型で安全にハンドリングする」までの過程をお話しします。型システムを活かして、保守性と開発速度を両立させるヒントをお持ち帰りください。

Kotlinでデータベース操作を行うことを考えると、第一候補にはExposedが上がってくるのではないでしょうか？
Exposedは確かに素晴らしいORMですが、やはりORMにありがちな以下のようなデメリットもあります。

• DSLでできることが限られている
• ORM独自のAPIを覚える必要があるため学習コストが高くなりがち
• ORMの抽象化が強い場合、複雑なクエリや最適化が困難なことがある

これらのトレードオフに対する別アプローチの選択肢として、私はSQLDelightをおすすめしたいです。

このセッションでは、

• SQLDelightとはなにか？
• どのように使うのか？
• SQLDelightとExposedそれぞれのメリット・デメリットの比較

についてお話ししたいと思います。