Kotlin Fest 2018 に行ってきました

f:id:m1zyuk1:20180829172121j:plain

皆さんお久しぶりです. 先日開催されたKotlin Fest 2018に行ってきたので備忘録を兼ねてまとめます. バタバタしてかけなくなる前に急いで書くのです...!

目次

  • 参加した理由
  • 会場の雰囲気
  • オープニングセッション
  • ブースでの出来事
  • 聞いたセッション
  • 懇親会
  • まとめ

参加した理由

そもそもKotlin Fest 2018に参加しようと思った経緯は2つあります. 最近よくAndroidのアプリケーション作成に関わるのですが, JavaよりもKotlinが増えてきているという状況でした.バイトやインターンなどでAndroidに関わるとそのほとんどがKotlin(もしくはコンバート中)となってきたこともあり，自分で作成するものなどでもKotlinを採用するなど, 自分のKotlin使用率も上がってくる中,もっとKotlinのことを知りたいなと思うようになってきました. そんな中8月中インターンとしてお世話になっているMercariさんに招待していただけるということで参加が決まったわけです. チケットを頂いたMercariさんには圧倒的感謝しかありません. インターンについてはまた後日終了後にまとめようと思います.

会場の雰囲気

会場である東京コンファレンスセンターは品川にあり, 駅から徒歩一分の好立地にあります.　非常に豪華そうな会場に到着するともうすでにブースが賑わっていました.

f:id:m1zyuk1:20180829172127j:plain

受付をすませ, ノベルティのトートバックをゲット.

各ブースではスポンサー様が様々な展示を行っていました.

オープニングセッション

開会後最初のセッションはオープニングセッションということでkotlinエヴァンジェリストの長澤太郎さん(@ngsw_taro)藤原聖さん(@satorufujiwara)のお話でした.

要約

感想

Kotlinの勉強会に参加するのは初めてだったのですが, 新参にも非常に入りやすいコミュニティの空気を感じました. そして何よりもみんなKotlinを愛でたくてたまらない！という感じが非常によかったです. もともと私はC#はいいぞと言い続けていた人間なのですが,Kotlinも愛でていきたいなと思わせてくれるようなオープニングセッションでした. また，なんとなくチュートリアルはやったのですが,KoansやGuidesの存在は知らなかったのでKotlinの2歩目3歩目をあるき出そうとしている人にも非常に有益な情報が詰まっていたのではないでしょうか.

ブースでの出来事

セッションの合間にはスポンサーのブースで様々な展示がされていました. 特徴的だったのはKotlin Codeの問題を出してるブースが多かったことです. どれも非常に難しくKotlinのことを愛でていないと解けないような愛に溢れた問題でした.

問題に挑戦したり, 抽選したりと色々しているうちにあっという間に時間はセッションの時間になってしまいました.

f:id:m1zyuk1:20180829172138j:plain

聞いてきたセッション

会場では大きな部屋を2つに仕切って同時に2つのセッションが並行されていました. なので自分が聞くことができたセッションとその内容・感想を簡単にまとめようと思います.

Kotlinで改善するAndroidアプリの品質@yanzmさん

要約

  • 品質の話をする理由
    • 動いているアプリの移行は難しい
    • コストやリスクを上回る効果はあるのか
  • アプリの品質とは
    • 外的品質要因 : アプリにその性質があるかないかユーザが認識できる
      • 正確さ
      • 頑丈さ
      • 拡張性
      • 再利用性
    • 内的品質要因 : モジュール性や読みやすさなどデベロッパー側から見たときに大事な品質
      • 読みやすさ
  • KotlinにJavaの規則を適用してみる
    • 非常にいろんな事例がある
    • 色々なパターンにおいてJavaの規則を言語仕様で対応している
  • 長く生き延びているアプリはこの先も生き延びる確率が高いのできちんとKotlinに乗り換えていきましょう

感想

Kotlinという言語が持つ仕様によってJavaで実装されていたコードで気をつけるべき点がより安易に達成されるのでKotlinをどんどん使っていきましょうというお話でした. Kotlin初学者の私としてはこんな仕様があったのか！という驚きや, なぜこんな書き方をしているのか腑に落ちたりと色々な発見がありました. 具体的な事例を取り上げてくれているため,JavaとKotlinの比較が目に見えるようなスライドになっていたので非常わかりやすかったです.事例は盛りだくさんだったのでもう一度スライドを見て復習しようと思います!

Kotlinアプリのリファクタリングポイント@Naoto Nakazatoさん

要約

  • より良いKotlinコードにリファクタリングをする場合のTips
  • Cradle Kotlin DSL
    • build.gradleã‚’ build.gradle.ktsに
    • 雰囲気groovyがKotlinできっちり書ける
    • 導入タイミング
      • 新規は最初から
      • 既存は時間があれば
      • 補助的なタスクを別ファイルで追加するのが良い
  • 処理の共通化
    • 処理重複は修正ミスを誘発
    • 処理を共通化するときの方法
      • Abstract class
        • 継承部分で処理を共通したい
        • クラス外から呼ばれたくない
      • Interface default
        • ベースクラスの肥大化を防ぎたい
        • 多重継承をしたい
      • Class delegation
        • Byで実装を別クラスに委譲できる
      • Property delegation
        • ゲッターセッターを外に
        • 値のように扱えるようなものに向いてる
      • 拡張関数
        • クラスに関数を追加しているように見せることができる
        • 公式でありそうな名前にして雑な実装をすると危ない
        • 汎用性が低いものに適用するのもよろしくない
          • インターフェースのデフォルト実装にするとスコープが限定される
      • トップレベル関数
        • どこからでも呼べるので注意
        • 乱用に気をつけて
  • Mutableを避ける
    • なぜ避けるか
      • 値を考える必要が常に出てくる
      • 暗黙の前提が増えバグの温床に
      • smart castが効かない
    • varは本当にvarである必要があるか
    • 値の切り分け
      • 値は不変であるか
      • 値はnullableか
      • const, val, lazy, lateinit, varの使い分け
      • どの時点で値が初期化できるかどうかと可変かどうかに着目せよ
    • varとmutableはどちらか回避できるはず
  • Collection
    • Listはread onlyであって immutableではない
    • Listは共変　Mutableは不変
    • 生成は適切なクラスを用いること
    • Collectionを活かしたリファクタリング : 2つのリストを同時に扱う
    • 対応関係のあるデータのリスト
      • zip
      • 2つをいい感じに使える
    • 変換と除外
      • map
      • filter
      • mapNotNull
    • リストを分割
      • withIndex
      • groupBy
      • values
    • allとanyとnone
      • 相互変換可能
      • 否定がないように書くのが一番良い
    • Collectionのメソッドは積極的に使うと良さそう
  • DSL
    • 構造的なデータの宣言など
    • DSLでクラス拡張するためには
      • 状態を持たない場合
        • レシーバに拡張関数
      • 状態を保つ場合
        • レシーバを委譲によって拡張
    • DSLは移譲で拡張
  • Nullablility
    • どこでnullableを変換するか
      • nullableのまま使う -> 至る所でnull check
      • 無効なデータを入れてnon null -> データチェックが増える
    • nullが何を表しているかを考える
      • 滅多に起きないエラーケース
        • infraでexceptionに
      • 任意項目
        • UIまでnullableで
        • UIで文字列変換 or チェック
      • 自明じゃない何か
        • sealedクラスで意味付け
    • Nullが表すものを考えよう
  • スコープ関数
    • キャプチャする
    • 処理をまとめる
      • ex) Intentに対しての関数をまとめる
      • ローカル変数が優先なので注意
    • Let/elvisはif/elseと等価ではないので注意
    • スコープ外呼び出し気をつけて
  • データ構造と状態数
    • 肥大しがち
    • ありえない状態を避ける
      • バグの温床
      • 考慮は不毛
    • クラス化するほど関連がある
      • Sealed class
      • Data classで状態を
      • EitherとPair
    • Arrow : 関数型っぽい書き方ができるようになるライブラリ
    • 一般化すると
      • 状態数を考えてから実装に
      • 状態数の分析する
        • Kotlinを数式に変換
        • 数式を展開
        • アリエナイ行を削除
        • 残った項を戻す
        • 適宜sealed,dataを使って意味づけをする

感想

1つ前のセッションがJava -> Kotlinのお話だったのに対しこのセッションではKotlinコードのリファクタリングがテーマでした. 自分がなんとなく書いたコードに適応できそうなリファクタリングポイントを始めとして様々なTipsが紹介されています.最後の状態数に関する分析はKotlinはもちろんのことそれ以外の言語を用いたアプリケーション開発でも応用できそうです. 私はまだ自分の持っているKotlinコードがそこまで多くないので, リファクタリングをすぐに行うわけではありませんが, この知識はリファクタリングだけでなく普通にKotlinを書く際にも使えると思うのでよりスマートなコードを目指すのに非常に有益だと思いました.

Kotlin linter@kgmyshinさん

要約

  • セッションのゴール
    • Kotlin用のlinterの使い方・特徴を理解
    • 各種linterのカスタムルールを作れるように
    • Linterを技術選定する場合の材料になること
  • Linterとは
    • ソースコード分析
    • バグとか構文エラーとかそういうのを見つけてフラグを立てる
  • AST(Abstract Syntax Tree)を知る
    • コードがどのようなツリーになっているか
    • PsiViewerでわかる
  • 大体の流れ
    • installしたらコマンドから使う
    • Custom Ruleの作成
      • ある構造のときにどういう条件で警告を出すか
      • visitメソッドを実装していく
        • ノードがある度に呼ばれる
      • providerを作って登録する
  • Ktlint
    • 標準ルール : 20個弱
    • 個別設定 : できない
    • Custom Lint : 作れる
    • その他 : formatできる
  • detekt
    • 標準ルール : たくさん
    • 個別設定 : できる
    • Custom Lint : 作れる
    • その他 : 複雑度がわかる
  • android-lint
    • 標準ルール : たくさん
    • 個別設定 : できる
    • Custom Lint : 作れる
    • その他 : 型が見える(メソッドの返り値が見える)

感想

KotlinのLintに関する一風変わったセッションでした. よくLintに怒られている私ですがそもそもどのようにしてコードを解析し,警告を出しているのか気になっていたのでちょうどよかったです. ASTという概念やそれの見方, 自分でルールを作成する方法に現在あるLintそれぞれの特徴と非常に多くの知識が手に入りました. 後のセッションであるHow to KontributeでもPsiViewerがInspection Pluginの開発時に使われており,Kotlinでアプリを作るのではなくKotlinをより使いやすくするためのツールに触れることができたのがよかったと思います.

Kotlin コルーチンを理解しよう@sys1yagiさん

要約

  • コルーチンとは
    • 対等のルーチン
    • お互いを呼び出して制御できる
    • 現代のKotlinのコルーチン
      • 一時停止可能な計算インスタンス
      • スレッドのように実行するコードブロックを持つがスレッドには束縛されない
      • Futureã‚„promissのように値を返すこともある
      • 普段書いてる
        • コールバックを受け取る形にしてブロッキングしないようにしている
      • 継続状況が増えても問題なし
        • 並列にフラットにかける
  • コルーチンはどのように実現されているか
    • Awaitはどのように?
      • Javaで実装できる形になっている
      • Corutineã‚’javaでどのように実装しているのか
    • ステートマシンに変換してる
      • 中断と再開を状態遷移と見立てる
      • データやラベルをステートマシンで保持している
    • どのように変換しているのか
    • コルーチンビルダー
      • コルーチンを生成するビルダー
    • 継続インターセプター
      • 実行スレッドをコントロール
      • ex launch(intercepter){do something}
  • 基本的な使い方
    • Kotlin 1.1から登場
    • Corutineはライブラリで提供
      • 特定環境向けのライブラリも
    • experimentalæž 
    • 1.3でstable
    • 環境構築
      • gradleにimplementationを追加
    • 各種コルーチン
      • launch
        • 結果を持たないコルーチンを作成するコルーチンビルダー
        • 引数
          • context(実行のコンテキスト　共有したいデータやインターセプターなど)
            • Default dispatcherがデフォルト
            • commonpoolを使う
            • スレッドプールで動作する
          • start(いつ起動するのか)
            • デフォルトは即座に実行
          • Parent
            • 親のjob
            • 複数のコルーチンを一括でキャンセルできる
            • onCompletion
              • コルーチンの完了をコールバックで
          • suspendラムダ
        • 戻り値：job
          • コルーチンに関与できる
            • 待ち合わせ
            • キャンセル
        • 基本的にスレッドプールで動作
          • progressbarとかいじると落ちる
          • インターセプターでUIを指定すればUIスレッドで実行
      • async
        • ブロッキングする時に async {}.await()
        • launchの違い : 結果を返してくれる
          • Differedを返す
            • await()を持っていて値を返す
      • 大体launchとasync/awaitを組み合わせれば事足りる
        • Try,catchもできる
        • リクエストを直列で
          • 先にasyncで実行だけ
          • .await()のところで待つ
          • 待ち合わせのタイミングでawaitする
        • cancel
          • Try catchはexceptionã‚’
          • 起動時にjobを取っておけば任意タイミングでcancelできる
        • まとめてcancel
          • 親を持っておいて生成時に親を登録する
          • 親をcancelするとまとめてcancelされる
        • リトライ
          • Repeatを中に挟んでおく
          • 成功したらreturnでlaunchそのものをreturn
          • 失敗したらリトライすべきかハンドリング
          • リトライすべきでなかったらリピートを抜ける
    • 面白実装
      • Retrofitã‚’defferedにすることでawaitできる
      • EventBusとchannel
        • イベントが発生したときのみ再開される
      • onActivityResultã‚’suspecd
        • requestPermissionもかける
        • android-corutines

感想

名前は知っていたものの今までほとんど使ったこともなく，説明もうまくできなかったcoroutinesのセッションでした. 非同期処理を謎の技術でいい感じにかけるようにしてくれるもの　ぐらいの理解だったのが,Kotlinのコルーチンはステートマシンで非同期処理やスレッド指定をいい感じのブロックでかける技術じゃ！　ぐらいの理解になりました. まだまだ理解度は甘い気がする... coroutinesがほとんどわかっていなかった自分がこれぐらいに理解できる非常にわかりやすいセッションでした.自分のプロダクトで早速試してみています.coroutinesやべぇ

How to Kontribute (v4 JP)@shiraji_iさん

Slide

要約

  • kontributorを増やしていく
  • セットアップ
    • JDK 9が必要 or JDK10,JDK1.8,JDK1.7,JDK1.6
    • Repository
      • fork and clone
      • branchを作成
        • ユニークなのブランチ名で
      • マージコミットをなくすように
      • 追従のために
    • IDE
    • IDE plugins
      • Preference > build cradle runner check
      • Kotlin plugin latest release 1.2.x ☝︎
      • Tools > Kotlin > configure Kotlin plugin update > check for updates now (stable)
    • Module
      • Open Kotlin
      • Module from existing sources
      • build.gradle.ktsを選択
      • Use default grade wrapperをチェック
      • 色々見えるようになる
    • Run
      • IDE run
      • IDEが立ち上がる
        • ここに言語の機能がbundleされてる
  • 他の開発者コミュニケーション方法
    • Slack
      • slack.kotlinlang.org
      • #kontributors
        • ここでコントリビュートに関する質問
        • 夜に質問するのがおすすめ(時差の都合)
    • YoutTrack
      • Issueマネジメントツール
      • Kotlinのissue
        • youtrack.jetbrains.com/issues/KT
        • 何が何だかわからない -> Up-for-grabsタグをフィルターすると良い
        • 取り掛かる前にやりますアピールをコメントする
          • できないかもと怯える前にやってみて　だめならだめだったときちんと言えば良い
    • GitHub
      • PRのフィードバックのみ
      • Kotlinでの機能開発はYouTrackでissueを立てる必要あり
        • そもそも見えてない
        • youtrackでprのurlを投げれば見てくれる

  • 最初のおすすめコントリビュート

    • READMEの修正
      • 環境構築いらない
      • コード書くより簡単
    • ドキュメントやコメントの記入
      • Standart library docからドキュメントがない
      • kdocで記述
      • PRするだけ
    • サンプルコードの提供
      • ex) KT-20357
      • OSS初心者向けのissue
      • Kotlinでできる
      • 1つのサンプルのメソッドを書くだけでOK
      • どう書くのかわからない人向けのSTEP
        1. サンプルコードがないメソッドを探す
        2. サンプルコードを提供するぞってissueにコメント
        3. サンプルコード書く
          • Groupbyのサンプルを提供するのでgroupByという関数を
          • @Sampleで書く
          • assertXXとかを使って 動きを見せる
          • @sampleを書いて完全就職のメソッド名を書く
          • マージされると書かれるようになる
          • ReadMeがある
        4. PRを送る
        5. コメントを編集してPRのリンクを

  • 実際にプラグインを作って見ましょう

    • Inspectionの作成が多い
    • Inspectionとは
      • この書き方すれば幸せになれる
      • これいらんからこうしようぜ　って言って直してくれる奴
    • Inspectionの作成
      • 表現を判断する
      • PSI Viewerを使う
        • Lintの項にあったコードの構造を見れるやつ
        • Tools | View PSI Structure of Current file
          • 後で起動しているほうで
            • ハイライトすると構造が見える
              • ex) ktValueArgumentならそれに対してのコードを書く
      • abstructkotlininspectionを実装
        • Psielementvisitor
        • ktvisitorというのがvisitorクラス
        • visitArgument(argument: KtValueArgument)
          • ここに書いていけば良い
        • ktVisitorVoidを戻すコードを
        • visitArgumentでprintlenしてみる
        • plugin.xmlに自分のを入れる
          • Tagの追加
    • レポート対象を見つけて
      • 何をレポートするかを
    • descriptionをかく
      • inspectionはXXã‚’reportするぞ
    • テストデータを追加する
      • インスペクションフォルダーを作る
      • .inspectionファイルを作る
      • TestDataを作ることでケースはできる
      • .ktと.kt.after
        • 実行前と実行後のデータ
      • GenerateTestを選択してrun
      • inspectionLocalで今はやる
    • Document
      • AbstractInspectionTest/Kotlin
  • SendPR
    • Commit comment #KT-nnnnn Fixed
    • Send PR to master
    • issueに投げる
    • 辛抱強く待つ
      • 1週間とか反応なかったらslackで

感想

Kotlinという言語に対してkontributeをしていこう！というセッションでした. 環境構築からkontributeするまでのイロハが簡潔にまとまっていて非常にわかりやすかったです.何よりもすごかったのは,自分もこんなふうにkontributeしていきたいな...と思わせてくれるshirajiさんのプレゼン力だったと思います. ブログを書ききったら自分のPCにkontributeのための環境を作らなくては?

懇親会

美味しい料理をいっぱい食べながらパックマンルールを適用しながらお話しました.パックマンルールとはテーブルの1箇所に人が入りやすいような空きスペースを設けましょうというものです.(これも初めての経験でした)そのおかけもあってか,色々な形でKotlinと関わっている人たちと様々なお話をすることができました. 話しかけるところでのみコミュ障を発揮する私ですがなんとかなってよかったです. 仲良くお話していただいた皆さん本当にありがとうございます.

まとめ

すでに文が非常に長くなってしまっているのでまとめると

  • もっとKotlinを知りたいしもっとKotlinを使いたい
  • Kotlinという言語とそれを抱きしめている人達のコミュニティともっと関わっていきたい
  • Kotlinという言語に対しても何らかの貢献ができたらうれしい
  • Kotlinは可愛い

とこんな感じです.

次回のKotlin Fest 2019は未定だそうですがきっと開催されると思うので, もっと密接に関わっていけたら嬉しいですね.

そのための一歩としてkontributerになるための環境構築をしてきます!