- 2025/11/1
- https://2025.kotlinfest.dev/
Kotlin言語仕様書への招待 〜コードの「なぜ」を読み解く〜
Honda Yusukeさん(LINE Digital Frontier)
https://docs.google.com/presentation/d/1ow0ofWuFuyz9BnSKNo27ZL_1NETMaQW3TJh7qC1x3jk/edit?slide=id.SLIDES_API1715203316_0#slide=id.SLIDES_API1715203316_0
- Kotlin言語仕様書
- Kotlin/kotlin-spec
- ドキュメントにも仕様はあるがより詳細なのはこっちで
- 自分が書いたコードがなぜ動いてるか
- 今はv1.9の内容だが細心はv2.2
- リソースが足りてなくて
- 対象はKotlin/Core
- プラットフォームを問わず共通なところ
- 文法の表現
- EBNFベース
- 文法の標準的な表記法
- 生成AIを使うと簡単にコードに落としてくれるので理解につながる
- 数学の記号も出てくるので慣れがいる
- EBNFベース
- 型システムと組み込み型
Ktorを使う時に設定しておきたいこと
Kanonさん
https://blog.inorinrinrin.com/entry/2025/11/01/140458
- Ktor
- 軽量でプラガブル
- JetBrains製
- デフォルトでは最低限しか動かない
- 入れておきたいPlugin
- Auto Reload
- Type-safe routing
- いろんなルートが入ってて乱雑になる
- 引数の型検証が必要になる
- プラグインを入れると型安全に扱えるようになる
- Call ID
- セッションIDなどをログに出してるときに2タブ開かれたりすると追いづらくなる
- リクエストごとにIDを発行して追跡できるようになる
- Status Pages
- Exceptionに対応したエラーページを返せるプラグイン
- error401.htmlとかerror402.htmlとか
- Request Validation
- 共通的にリクエストパラメータの検証を作れる
- Dependency Injection
- HSTS
- CORS
- Default Headers
- Rate limiting
デッドコード消せてますか？ - 構文解析とGradleプラグイン開発で始めるコードベース改善
Taskさん(マネーフォワード)
https://speakerdeck.com/t45k/detudokodoxiao-setemasuka-gou-wen-jie-xi-togradlepuraguinkai-fa-deshi-merukodobesugai-shan
- デッドコード
- たどり着くことのないコード
- コードベースが肥大化するだけ
- 誤った理解の誘発
- 解決法は消せばいいだけ
- フィーチャーフラグ
- 機能のリリースをフラグで制御する
- リリース後はデッドコードになる
- デッドコードの削除自動化
ネストしたdata classの面倒な更新にさようなら！Lensを作って理解するArrowのOpticsの世界
shiita0903さん(LINEヤフー)
https://speakerdeck.com/shiita0903/nesutositadata-classnomian-dao-nageng-xin-nisayounara-lenswozuo-tuteli-jie-suruarrownoopticsnoshi-jie
- 複雑なdata classの変更の辛さ
- 入れ子になってる深いところを更新したものを作る時
- xxx.xxx.xxxと何度も辿らないといけない
- Lensを使うとシンプルに書ける
- イミュータブルなデータの操作に使われるもの
- GetterとSetterのペアで構成される
- get/set/modify
- modifyを使うと深い階層をイミュータブルに書き換えられる
- Lensだけでは対応できないケース
- Mapを含む場合
- シールドクラスを使ってる場合
- Arrow-ktのOptics
- Traversal
- 複数個の値全て更新
- Optional
- コレクションの一部取得
- Lens
- sealed classの階層表現
- Prism
- Getter + Setter
- Iso
- 型間の相互変換
- Traversal
文字列操作の達人になる ~ Kotlinの文字列の便利な世界 ~
tomorrowkeyさん(STORES)
https://speakerdeck.com/tomorrowkey/wen-zi-lie-cao-zuo-noda-ren-ninaru-kotlinnowen-zi-lie-nobian-li-nashi-jie-kotlin-fest-2025
- Kotlinの文字列
- Stringクラスに定義されてるメソッドなどは少ない
- 拡張関数として多くのメソッドが用意されている
- Javaに変換して見てみると分かりやすい
- Kotlinらしい文字列
- 文字列を構築する
- JavaだとStringBuilder
- KotlinだとbuildStringを使うと便利
- buildMapやbuildListも似たようなのである
- デフォルト値を使う
- 地道に描くとif文でisBlankだったら値をセットと書くことになる
- isBlankメソッドを使うと簡潔に書ける
- isEmptyはlengthが0だけどisBlankはスペースっぽいものだけの時も含まれる
- 複数行の文字列
"""で囲うと書ける- 同じ数のインデントは自動で削除してくれる
trimMargin()を使うのも便利
- 複数行文字をシンタックスハイライトしたい
- 普通に書くと文字列にしか見えないから不正な内容を書いてしまってるかも
- コメントで
// language=JSONとか書くとIntelliJがハイライトしてくれる
- 複数行の文字列に$を入れたい
- $は式展開とみなされてしまう
${'$'}って書くことはできるが分かりづらい$$"""で囲うようにすると式典回の識別子を$$に変えられる
- 文字列を文字数ごとに区切って処理したい
- 地道にやるとループ書いてけっこう複雑になる
str.chunked(2)ってやると2文字ごとに分割できる
- 16進数文字列をパース
str.hexToByteArray()
- 文字列を行ごとに分割したい
str.split("\n")とかやれるが改行コードは環境によって違ったりstr.lines()でいい感じにやってくれる
- 正規表現で文字を取得
- 文字列を構築する
Kotlin + Power-Assert ： 言語組み込みならではの Assertion Library 採用と運用ベストプラクティス
松田一樹さん
https://speakerdeck.com/kazukima/gen-ax
- 単体テストが落ちた時に何がダメだったのかぱっとわからない
- PowerAssertを使うと途中でどういう評価をされたか見えて便利
- 中間値の可視化
- PowerAssertの系譜のテストライブラリはさまざまな言語である
- PowerAssertを使うと途中でどういう評価をされたか見えて便利
- PowerAssertの導入
- Gradle Pluginとして公式から配布されてる
- pluginsに一行入れればOK
- Soft Assertion
- 複数の検証を走らせて最後に失敗させたい
- PowerAssertの機能ではなくテストライブラリの機能を使うといい
- 例えばassertAll
- 全部のassertを実行したうえで失敗したもの全ての中間値を見れる
- 特定フィールドの無視比較
- タイムスタンプだけは比較したくないとか
- 地道に比較したいものを書いてると新しいフィールドが追加された時に漏れる
- タイムスタンプだけは比較したくないとか
