Kotlin Fest 2018に一般参加してきた

 日本で初めてのKotlinの大型カンファレンス、「Kotlin Fest 2018」に参加してきました。Kotlinを愛でるエンジニアの1人として、開催告知がされた時からめちゃくちゃ楽しみにしていました! この記事では、僕が聴講したセッションの資料と軽い感想をイベントレポートとしてまとめようと思います。

オープニングセッション

Speaker: 長澤太郎さん(@ngsw_taro)、藤原聖さん(@satorufujiwara)

Summary

  • 今日のテーマは「Kotlinを愛でる」
    • 開発者がみんな「書いていて楽しい」と言いたくなる言語
    • 「かわいい」と形容される言語はあまりないのでは?
       - 2012年から様々な活動を通してKotlinを広めてきた
  • Kotlin今昔物語
    • 2011年7月発表、2012年2月に実装公開
    • 最初はdata classやlateinit等が存在しなかった
    • 2016年2月、v1.0リリース
    • 2017年3月、v1.1(コルーチン、JS)
    • 2017年5月、Android正式サポート発表
    • v1.3でコルーチンの正式版が出る等
  • Kotlin Conf 2017
    • サーバーサイド30%、Android24%、Native18%
    • サーバーサイドやNativeを盛り上げようとしている
  • Kotlin in Actionの翻訳の話
    • 第二部タイトル「Embracing Kotlin」どう訳す?
    • Embracing: 愛情をもって、より深く知る
    • 「Kotlinを愛でる」と訳そう!
  • Kotlinの哲学
    • 実用主義: Javaの考えがそのまま使える、学習容易性
    • 簡潔: 読みやすさ重視でボイラープレートを減らす
    • 安全: 静的型付け、Null安全、Smart Cast
    • 相互運用性: Javaと相互に行き来、ライブラリ資産の流用
  • Kotlinを知るリソース
  • Kotlinを正しく知って、Kotlinを愛でよう

感想

 最早誰もが認めるKotlinエバンジェリストの長澤さんと、Kotlin in Actionの訳者の1人である藤原さんの基調公演。Androidでの正式サポート発表以来、一気に注目されだしたKotlinですが、「書いていて楽しくなる言語」というのは本当にその通りだなと感じます。JavaからKotlinへの転換は、多くのエンジニアの生産性を劇的に向上させたと言っても過言ではないと思います。
 Kotlinの哲学として挙げられた4つの要素はどれも高いレベルで実現されていますし、Androidの正式サポート発表から一気に情報も増えたので、素晴らしい言語に出会えたとみなさん共通して思っているのではないでしょうか。まぁとにかく、長澤さんの語り口から溢れ出るKotlin愛がすごかったですw

ランチ

 今日のスピーカーでもあるしらじさんが前日にこんな募集をかけていたので、思いっきり乗っからせていただきました! ありがとうございました🙏
 「良いと思ったOSSにコントリビュートしたい」モチベーションが元からあり、Kotlinへのコントリビュートもそのうちの1つという話。そして「中の人からPRをレビューしてもらうことで大きな学びが得られる」という言葉を生の声として聞けたのが、行動指針としてすごく学びになりました。
 集まった5人全体では、サーバーサイドKotlinとktsの話が盛り上がりました。しかし僕は、恥ずかしながらAndroid一辺倒でどちらもキャッチアップできていない…😣 もっと精進しようと思いました。全力で。

発表

Kotlinで改善するAndroidアプリの品質

Summary

  • JavaからKotlinへの乗り換え
    • サービス運用しながらの移行難しいのでは?
    • 書き直しコストやデグレの危険性を上回る効果はあるの?
  • サービスの品質の要素 by オブジェクト指向入門原則コンセプト
    • 外的品質要因: 性質があるかないかをユーザーが認識できる性質
    • 内的品質要因: モジュール性、読みやすさ等
    • どちらも表裏一体、片方おざなりになるとつらい
    • Kotlinはどちらも達成可能
  • 外的品質要因の特に重要な4項目
    • 正確さ(correctness): 仕様通り動くか
    • 頑丈さ(robustness): 仕様外の動作した時どうなるか
    • 拡張性(extendibility): 仕様変更に対する適用のしやすさ
    • 再利用性(reusability): モジュール性=拡張性+再利用性
  • Javaと品質
    • 長年第一線で使われ続けている→知見がたくさん
  • Effective Javaにある規則がAndroidではどう適用される?
    • (山ほどあるので略)
  • Effective Javaの多くの項目にKotlinでは言語仕様レベルで対応されている
  • Kotlinに書き換えると品質の高いコードのエッセンスが自然と入る
  • 今まで長く生きてきたアプリはこれからも長く行き続ける→Kotlin置き換えしよう!

感想

 Kotlinの良さについてのロジカルな解説、またはよりKotlinらしいコードにするにはどうすべきか? という点にフォーカスしたセッションでした。今まで感覚でしか理解していなかったKotlinの書きやすさ・使いやすさについて、Javaとの比較を中心に腹落ちする説明を得られてすごくスッキリした気持ちになりました。このセッションを聴いておけば、慣れないうちにKotlinでJavaを書いてしまうありがちな失敗をかなり防止できるのではないか、という気がします。Kotlin書き始めた時に、この内容を誰かに教えて欲しかった(切実)

Kotlinアプリのリファクタリングポイント

  • HotPepper Beautyのリファクタした時のTips
  • Gradle Kotlin DSL
    • GradleのビルドスクリプトをKotlinで書ける
    • 「Groovyを雰囲気でやっている」から脱却
    • 補完やコードジャンプが使える
    • 新規なら使ってみよう
    • 既存のモノは補助タスクを別ファイルで追加するのが○
    • 例: 未使用drawableの削除タスク
  • 処理の共通化
    • 修正箇所の増加、修正し忘れを防ぐ
    • abstract class: クラス外から呼ばれたくない、子クラスで継承したくない
    • interfaceへのデフォルト関数実装: base classの肥大化防止、多重継承可
    • class delegation: interfaceの特性を活かしつつ状態も持てる、interfaceを分割してdelegationすると更に柔軟に
    • property delegation: IntentのextraやFragmentのarguments、値として使えるモノ
    • 拡張関数、トップレベル関数: 強力だけど濫用すると地雷に、interface内に実装するとスコープ限定できる
  • Mutableを避ける
    • valとvar、MutableListとListの使い分け
    • Mutable→どんな値が入っているか常に考慮する必要アリ、スマートキャスト不可
    • 値が不変なのか、どの時点で値が確定するのかで変わる
    • val/lazy/lateinit/nullable
    • 非同期通信後に値確定する値はlateinitにするとクラッシュしがち→nullable
  • KotlinにおけるCollection
    • zip/map/filter等
    • 豊富なコレクション操作関数を使いこなせると○
    • all/any/noneを使い分けて否定の条件式を減らせると○
  • DSL拡張
    • レシーバを受け取って委譲で実現
    • レシーバがinterfaceならclass delegation
  • Nullability
    • nullableをやたらと使うとチェックが増える
    • 意味のないデータで初期化してもチェックが面倒
    • 「null」の意味を考える
    • めったに起きないエラーケース: Exception投げる
    • 任意項目であり、存在しないを表していることが自明: UI層まで渡して、代替文字表示や条件分岐
    • 自明じゃない何かを表す: sealed class(名前ある→ログインユーザー、ない→ゲストユーザー)
  • スコープ関数
    • let/run/also/apply/with
    • 処理をまとめる、条件判定後の処理
    • let elvisとif elseは等価じゃない
  • データ構造と状態数
    • data class肥大しがち問題
    • 状態数を先に数え、ありえない条件を除外する
    • 状態数に応じて適切な型でプロパティを用意する
    • Nothing: 0、Unit: 1、Boolean: 2、nullable: +1 …
    • sealed classやdata classは「状態の意味付け」として使う

感想

 このセッションも非常に共感ポイントが多かったです。拡張関数をやたら作りすぎてつらいことになったり、BooleanをNullable宣言してかなしいことになったり、スコープ関数を自由奔放に使いすぎてカオスになったり。これらのトラップに幾度となく引っかかり、その都度試行錯誤を繰り返してKotlinの良さを最大限引き出せる書き方を少しずつ会得した方がこれまでは多かったと思うのですが、大きなカンファでこうしてTipsとして共有されると同じ過ちを繰り返す人が減ってみんな幸せになれますよね。

Kotlin Linter

Summary

  • Linter: 疑わしい構造にフラグを立てるソースコード分析プログラム
  • ktlint/detekt/android-lintを紹介
  • ktlint
    • インストール: 公式のREADME、「ktlint-gradle」「kotlinter-gradle」がある
    • 使い方: コマンド、エラー箇所一覧が表示
    • 標準ルール: 17個
    • ルール設定: インデントサイズとファイル末尾改行だけEditor Configで変更可
    • その他: コードの自動フォーマッティングができる
  • detekt
    • インストール: Gradleに追加
    • 使い方: コマンド、エラー箇所一覧の他に修正目安時間や複雑度算出とかもされる
    • 標準ルール: 79個
    • ルール設定: それぞれに対し個別設定可、default-detekt-config.ymlを生成して編集
  • android-lint
    • インストール: Android Studioに入ってる
    • 使い方: コマンド
    • 標準ルール: いっぱい、XMLやJavaのLintも混在
    • ルール設定: configファイルを作成し、lintConfigに指定
    • その他: 返り値の値判別までできる
  • カスタムルールの作り方
    • コードをツリー構造で考える(AST)
    • PSI Viewerを使っていこう
    • 作成したカスタムルールはjarにしてGradleで指定

感想

 Lint導入の心理的障壁が殆どなくなったと言っても過言ではない気がします。思っていたより簡単ですし、CIにも組み込みやすそうという印象を受けました。カスタムルールの作成にも、PSI Viewerというイケてるツールのおかげで製作者以外メンテ不可能なルールができる事態もある程度防げそうなのがよいです。後は、標準ルールに対して有効/無効の設定を1つ1つ確認する膨大な時間の工数をしっかり確保することですかね…😇

Kotlin コルーチンを理解しよう

Summary

  • コルーチン: 対等の関係で処理を実行する仕組み
    • サブルーチン: 普通の関数、呼び出し元、呼び出し先が親子関係
  • 一時停止してまた再開できる
  • 値を返すモノ、返さないモノがある
  • 「停止」とどこかのスレッドで「再開」するという継続の状態を持つ
    • これらの要素を簡潔に書けるモノ→現代におけるコルーチン
  • Kotlin Coroutine=ステートマシン
    • 中断と再開を状態遷移と見る
    • 再開に必要な情報をステートマシン内にキャプチャ→内部情報を遷移させるという仕組み
  • suspend修飾子
    • 付与すると「中断」を表す
    • ラムダ式につける→コルーチン本体
    • 関数につける→中断する場所を表す
  • コルーチンビルダー
    • コルーチンを生成するモノ
  • 継続インターセプター
    • 実行スレッドの指定
  • launch関数
    • 結果を返さないコルーチンビルダー
    • 引数の最後にsuspendラムダがいる
    • デフォルトでCommonPool→スレッドプールを使う
  • async関数
    • 結果を返すコルーチンビルダー
    • asyncで「起動」
    • awaitで「値が返ってくるまで中断」
    • エラーハンドリングはtry catch
  • launch、asyncが返すJobのcancel関数でCancel
     - Exceptionが飛んでくるので注意

感想

 今日1番の目からウロコセッションでした。JSのasync/awaitを使ったことがあるので雰囲気だけ理解していたコルーチンですが、「中断と再開を状態として持ち、時間のかかる処理をステートマシンで表現する」モノだと解説をもらい、雷に打たれたような衝撃でした。僕はRxJavaのストリーム制御の概念が大好きで、APIリクエストのコールバックをはじめとして色んな処理をRxJavaでゴリゴリ実装しているのですが、仕組みがわかった今、コルーチンに置き換えていこうという流れが大きくなりつつある理由が理解できました。どこから入れるべきか、まずはandroid-coroutineからかな…?

How to Kontribute(v4 JP)

Speaker: 磯貝佳典さん(@shiraj_i)

Summary

  • 2016年から60 commitsくらい
  • Kotlinといっても、多数のプロジェクトが存在
    • 外部の人はKotlin Pluginにコントリビュートすることが多い
  • 環境構築: JDK9、1.8、1.7、1.6が必要(JDK10もOK)

  • それぞれ環境変数に
    • 大変なのでJDKコマンドでよしなに
  • OSSの時はmerge commitを入れないように
  • IDE
    • Intellij IDEA: v2017.3以上
    • CommunityでもUltimateでも
  • Kotlin plugin: latest release 1.2.x
  • module from existings sources
    • build gradle.kts選択
  • 修正してrunするともう1個IDEAが立ち上がる

    • 立ち上がったIDEAに修正したKotlinがバンドルされるのでここでdebug
  • コミュニケーション: KotlinlangのSlack
    • 日本時間夜に投げると返ってきやすい
  • YouTrackでissue見に行く
    -「up-for-grabs」→外部の人にやってもらうissueタグ
  • GithubはPRに対するレビューだけ
    • Githubに投げたらYouTrackにコメントする
    • JetBrainsの中の人達がこれで感知する
  • 最初のKontoribute

  • READMEの修正
    • 簡単
    • セットアップも不要
    • 作業があんまり残ってない
  • ドキュメント/コメントの追加
    • Kdocで英語のコメントを追加
    • 公式ドキュメントにドキュメント無いのが結構ある
    • JetBrainsめっちゃ欲してる
  • KT-20357

    • 初心者向けissueまとまっているところ
    • 1つのSampleメソッドを送るのもOK
    • サンプルメソッドと同じ名前で関数を作ることが多い
    • サンプルメソッドにコメント追加して書いた関数に飛べるようにする
  • Kotlin Plugin作るぞ
    • Inspectionオススメ
    • PSI Viewer使ってコード構成確認し、置き換え用のコードを書く

感想

 「言語へのコントリビュート」というとめちゃくちゃハードル高く感じてしまうところ、ドキュメントやコメント、サンプルコードの追加といったコントリビュートの入り口を教えてもらい、圧倒的知見でした。Inspectionの機能はたまに利用することがあるので、自作のモノが全世界で使われると想像するとワクワクしますし、JetBrainsのブログに名前が載るのも胸熱ですよね。それに、ローカルで言語の開発環境を整えられるとKotlinに対する理解が劇的に深まることは想像に難くないので、直近の空き時間でIDEAの導入と環境構築まではやってしまおうと心に誓いました。
 あとしらじさんの発表、今日の中では1番聞きやすく分かりやすかったです。

懇親会

 コルーチンの発表をした八木さん、主催者の長澤さんとお話してきました。八木さんに対しては、「当時の波に乗ってゴリっと書き換えたRxを、わざわざコルーチンに再度書き換えるモチベーションはどこにあるのか」という疑問をぶつけましたが、「1つのレスポンス・データが返ってくるだけの処理をストリーム制御にわざわざ乗せなくても良いのでは」「データ取得の処理は究極的に全てブロックで書くのが1番わかりやすい」といったニュアンスの返答があり、セッションで得られた知見が更に10倍くらいになった気がしました。
 また、コルーチンの導入議論から発展して攻撃的(=新しい・イケてる技術をとりあえずどんどん入れたい)な人と防御的(=リソースファイルの管理やコードの保守性維持をかっちりしたい)な人のバランスが大事だよねといった話も。本当に無限のわかり…🤔 すごく良い時間でした、ありがとうございました🙏

まとめ

 世間から見ると「Kotlin=Androidアプリの言語」という見方が強いですが、今回のカンファではサーバーサイドKotlinの温度感が予想以上に高く驚きました。導入事例なかなか多いですし、AndroidをJavaからKotlinに変えた時と同じようなポジティブな知見・感想がサーバーサイドKotinの事例でも数多く出てきているように感じました。JetBrains自身もAndroidだけで閉じたモノで留める意図は全く無く、マルチプラットフォームの世界にKotlinを広めていこうと全力を注いでいるようなので、今後もとても楽しみです。
 また、「Kotlinの良さを引き出す」知見が今日のセッションでも数多く共有されるようになり、Kotlinが「調査・キャッチアップの対象」から「ベストプラクティスの模索・共有」がされる言語に移っていることを改めて実感しました。Kotlinへの移行で得られる多くの利点が広く知れ渡り、多くの人がその利点を享受するためにどうしたら良いかを知りがっており、この変化は言語として大きな進化なのかなと思います。僕自身、たまたまv1.0リリース前からKotlinに触れ、無数の酷いコードを生み出した果てに見つけた様々なTipsや経験則が少なからずあるので、少しずつでもアウトプットして、Kotlinの世界の盛り上げに貢献できたらと思う次第です。

 こんなに素晴らしいイベントを準備してくださったスタッフ、スポンサーの方々、多くの知見・気付きを提供してくださったスピーカーの方々、懇親会でお話させていただいた一般参加者の方々、本当にありがとうございました。2019年のも絶対行きます!!!


久々にMacBookのステッカーが増えた✌️

Pocket

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です