プロポーザル

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

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

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

日々のコーディングで誰もが向き合う「文字列操作」。その面倒な作業が、いかにKotlinで楽しく、効率的になるか紹介します。

どのプログラミング言語でもある文字列というオブジェクトにフォーカスをあてて、Kotlinでは基本となる文字列操作から、あまり知られていない拡張関数まで、Kotlinで使える便利な文字列操作の世界へみなさまをご案内します。

KotlinPlaygroundはブラウザ上で編集・実行・共有が完結する、JetBrainsによって提供されているウェブサイトです。
Kotlinのバージョンや実行環境を簡単に変更して、ウェブ上で実行結果まで確認できるため、手軽に動作を確認できるサンプルコードを共有するツールとして活用されています。

直近では、Compose MultiplatformやSwift export、Canvas等の様々な実行環境のサポートが行われており、動くUIのサンプルを書いて共有することもできるようになっています。このセッションでは機能紹介からはじめ、ショートカットや、できることの限界といった点まで触れて効果的なコード共有を実現するためのベストプラクティスを含む内容を紹介します。

「動く」コードサンプルでチームのコミュニケーションをよりスムーズにしてみませんか？

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

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

このセッションでは、

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

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

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

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

KotlinによるServer Side Web FrameworkといえばSpringあるいはKtorかと思います。
Springを採用している組織がやや多い印象を受けますが、やはりPure KotlinなKtorも人気があります。
そんな昨今の状況において、Ktorを紹介する記事やセッションはちらほらと見かけますが「Ktorでしておくべき設定」にフォーカスした記事やセッションはあまり見た覚えがありません(主観)。

そこでこのセッションではよりKtorを深堀し、Ktorでぜひ設定しておきたい以下の機能についてお話ししようと思います。

• Auto Reload
• Tracing requests
• Type-Safe Routing
• Application structure

またこれらの機能を設定することで、「実際にどのような恩恵を受けられるか？」までお話しします。

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

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

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

このセッションでは、

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

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