Kotlin Fest 2019に行ってきた!

はじめに

2019年8月24日(土)に開催されたKotlin Fest 2019に参加してきました!
この記事はその感想記事になります。

詳細はこちら。

kotlin.connpass.com

当日の様子はハッシュタグからどうぞ!

twitter.com

参加目的

• いま書いてる入門実践サーバーサイドKotlinという技術系同人誌に活かしたい
• Kotlin初心者なので基礎も学びたい
• だいぶKotlin好きになってきたのでもっと好きになりたい

なので、基礎、サーバーサイド系を中心に聞きました。

目次

開始前

会場についたのが10時20分ぐらいでした。

Ktolinのロゴかわいい。かわいくない？

#kotlinfest pic.twitter.com/DGeDUxQhnJ

— FORTE@技術書典7【い03C】入門!実践!サーバーサイドKotlin (@FORTEgp05) August 24, 2019

個人的にはバズったと言ってよいほどの反応w
ありがたや〜。
ちなみにトートバッグはかなりしっかりした厚みで実用に十分耐える感じ。
176cmの私でも方にかけて余裕があるので、これは良いものだ感がすごい。
かわいいし。

トイレとホワイエに行こうと外に出る時さっそく知り合いとバッタリ。
aozora.fmにもゲスト出演して頂いた長岡さんとすれ違い、
技術同人誌繋がりの、なのなのさんともお会いできました!

ホワイエでコーヒーとか軽食が配られており、
バナナとかあったのでパレオダイエット中のみとしてはありがたい。
(朝ごはん食べたのでコーヒーだけいただきました)

なのなのさんにお聞きするとKotlin festは去年から始まったとのこと。
Android多めかと思っていましたが、意外とサーバーサイドもいるっぽい。
8〜9割はAndroidかと思ってました。

オープニング・セッション

オープニングは日本Kotlinユーザグループ代表の長澤太郎さんから。
キーワードは「Kotlinを愛でる」

個人的にはいままでこの言語や技術が好き!というものがあまりなかったので、
Kotlinをもっとに好きになりたい。

カンファレンスの紹介やスポンサー紹介などが続き、
懇親会でのパックマンルールについて。
輪の隙間をあけておくことで他の人間が会話に入りやすくするル取り組み。

パックマンルールいいよね(名前も好き)

基調講演

JetBrains社でKotl;inの開発を行っているSvetlana Isakovaさん。
Kotlin in actionの著者さんだそうで。
(読んでない…w)

テーマはKotlinの最新情報について。

Kotlinは全世界で200万人以上に使われている。
6年でAndroidの公式言語に。
開発当初からすると随分成熟した。

でも完成ではない。
新しい仕組みがたくさんある。
今日はそれを紹介したい。

Kotlinは実用的な進化を目指している。
例えるなら柔らかい石。

ベースはあるけれど、追加の変更を恐れない。

様々なやりかたでより良くしていきたい。
言語そのものをモダンな形に良くしていきたい。
コミュニティと会話しながらやっていく。

後方互換を保ちつつ進化していく。

KEEP(Kotlin Evolution and Enhancement Process)がある。
これはKotlinという言語にたいするプロポーザルを管理するGithubリポジトリ。
これによりコミュニティと対話しながら改善を図っている。

github.com

バージョンアップするときはMigrationする。
非互換になる関数はツールで置き換えるなど、ツールでの対応を目指している。

Kotlinはコミュニティが好き。
そしてコミュニティはKotlinが好き
両思い。

全世界にコントリビューターがいる
例えばと表示されたのはこの方「磯貝佳典さん」

試すことができる新しい仕組み

なぜ試せるのか?
早くフィードバックを得て問題を潰し、素早く安定版を出したいため。
実験したい。

この実験というキーワードはRSGTでもHunter Industiesのエンジニアが言ってました。
やはり実験は大事、変化していくことを恐れてはいけないと思います。

実験機能は明示的に使用する必要があるので本番に紛れ込まない。
アノテーションで使用することを宣言する。

具体的な実験機能の紹介

コード例がいろいろ出てましたがメモれず。
写真取れば良方かもですが、OKと言われなかったので断念…。
公式サイトか、資料が公開されたらぜひそらちも。

公式サイト

kotlinlang.org

インラインクラス

インラインクラスは値に対するラッパーとなる。

例えばLong型のミリ秒を引数にとるとき、間違えて秒を渡したりintで渡してしまうバグが起こりうる。
オーバーロードはたくさん書く必要がありめんどう。

Durationクラスはオブジェクトが生成され計算も走ってしまう…。

インラインクラスはDurationをバイナリコードレベルでいい感じにしてくれる。

また、明示的に単位を指定できる。
2.secondsみたいな。

コントラクト

次のようなnull、空チェックについて、
1.3でコンストラクタがついて複雑になった。
なぜか?

public inline fun <T> Collection<T>?.isNullOrEmpty():
Boolean {
    contract {
        returns(false) implies (this@isNullOrEmpty != null)
    }
    
    return this == null || this.isEmpty()
}

以下のように使用するとスマートキャストできないず、エラーとなる。

if (!obj.isNullOrEmpty(s)) {
 return obj.length
}

コントラクトとは関数の振る舞いをコンパイラーと共有する。

なぜ必要なのか?
implicitly(暗黙的)に変えてしまう危険性がある。
コンパイラーが断定できないことらしい。
それを明示的に意図を宣言する。

イミュータブルコレクション

Listは読み取り専用。
追加すると新しいListが返されるようになる。
(今もそう?)

ここはよくわかりませんでした・・・。
勉強不足!

Flows(フロー)

いつ使うのか?などコルーチンのユースケースが難しい。

そこでコルーチンにリアクティブストリームを追加しようとしている。
バックプレッシャーに対応している。

RX Javaとの相互変換とかができるようになる?的なことを言っていた気が・・・。
ここもよく分からず・・・。

マルチプラットフォームプロジェクト(MPP)

expect、actualが追加されている。

Kotlinではアプリの共通部分の共有を目指している。
全てではなく一部だけ、例えばビジネスロジックだけなど。

共通のコードをexpect宣言する。
プラットフォーム向けのコードで実態(actual)を書く。

既にプロダクトでマルチプラットフォームを使用している例もある。

もっと知りたい方は?

Kotlin In Actionがおすすめ!
Java書いてない人向けの新しい本も書いているみたいです。

さいごに・・・
Have a nice Kotlin!

Kotlinの型実践入門　佐藤 隼さん

Javaにはない型がある。
初学者向けの発表。

スマートキャストで判定すると型指定を省略できる。
動的言語のダックタイピングに近い書き心地。

if (obj is String) {
    print((obj as String).length)
    // ↓ 以降は型指定不要
    print(obj.length)
}

• コントラクト

関数呼び出しの結果を元にスマートキャストが走る。
スマートキャストの拡張をしてくれる。

以下のisNullOrEmptyではfalseを返すときはnullではないとコンパイラに伝える。

public inline fun <T> Collection<T>?.isNullOrEmpty():
Boolean {
    contract {
        returns(false) implies (this@isNullOrEmpty != null)
    }
    
    return this == null || this.isEmpty()
}

そうすると、isNullOrEmptyを実行したあとはnullではないとコンパイラが認識できる。

ちなみにコントラクト自体はまだ正式仕様ではないため、@UseExperimentalアノテーションがいる。

• Any型

JavaのObjectみたいなもの。
Waitやnotifyが無いなど違いはある。

キャストすれば使用することが可能。

• Unit型

Javaのvoid型みたいなもの。
明示的に変数として受け取れる(voidは無理)

• Nothing型

すべてのクラスのサブクラス。
値が存在しないことを示す。

reutrn;みたいな使い方をする。

fun getName(): String {
    return "name"
}

fun fail() {
    throw RuntimeException()
}

だと、Anyになってしまう。

val name: Any = if (isFriend()) {
    getName()
} else {
    fail()
}

failの戻り値をnothingにするとAnyではなくStringにできる。

ちなみにNothing?もある。
nullのみ許可する。

• ジェネリクス

分散アノテーション

共変、反変、不変

独自のインターフェースを定義したときに他のクラスと関係を持たせる

Listは共変、MutableListは不変
PECS原則
Producerはread
Consumerはwrite

スライド108で質問。

Q: anysにaddしてもstrsはそのままでは?
A: 代入しなおしたlistも同じオブジェクトになるので、
追加すると元のリストにも追加される

そう言われてみればJavaもそうだった気がする。

• ふたつ以上の上界を持つ型変数

whereで実現できる
正直ここはよく分からなかった…w

• reified

型引数Tにアクセスできる

• 拡張関数+ジェネリクス

拡張関数とジェネリクスで工夫できる。
例えば特定の関数を呼ばせたくないなど。

• sealed class

whereのelseが不要になる

interfaceには存在しない
用意に継承できてしまうため。

• 関数型

引数として関数型を受け取れる

• SAM変換

ラムダ式で簡単にかける。
むずい。のでスライドをw

登壇者への質問

登壇者にListの件のついででいま書いてるコードについて質問してみた。

Q: 以下の場合にidをnullで初期化したくないが、良い方法はあるか?

data class User (
    var id: Int
)

A: 0とかで埋めた上で中間クラス作ってマッパーとか使うと良いかも。

具体的なコードがイメージできなかったので、
後日調べてみる。

Coroutinesから紐解くKtorの仕組み 小谷野 雄史さん

KtorはKotlinをフル活用している。
今回は特にCoroutinesについて話す。

Kotlinの特徴のひとつUnopinionated
直訳は「自説をもたない」。
フレームワークで強制せず、実装者に委ねる。

ktorは薄いフレームワークが特徴。
例えばデフォルトではロギング、JSONマッパー、テンプレートも実装されてない。

ケースバイケースでフルスタックフレームワークより適した場面で使う感じ。

Featureによるプラグイン機能。
認証、ルーティング、ロギングなどもすべてFeature。

installメソッドで追加できる。

• パイプライン機構

計算パイプライン機構。

httpリクエストを受け取ると計算パイプラインを実行していく。
パイプラインはフェーズによって別れており、
それぞれ設定することで独自のパイプラインを定義できる。

これはinstallや、Routing定義によって行われる。

フェーズ間ではApplicationCallというmutableな共有オブジェクトに保存される。
これにレスポンス情報なども保存する。

各フェーズごとにコルーチンが呼び出されて実行される。
リクエストを受け取ったスレッドが別スレッドでコルーチンを起動し、
これ以降のフェーズはすべて同一スレッドで実行される。

• ktorの仕組み詳細

盛りだくさんだったのでメモとれず・・・。
スレッド(リソース)を効率的に使えるように設計されている。

ktorの仕組みはコルーチンを使い倒している。
正直難しかった・・・w

サーバサイドKotlinでGraphQLをやってみよう 磯貝佳典さん

GraphQLとは?
定義されたスキーマに則ったクエリを実行してデータを取得する

• GraphQLのスキーマ

type User {
    id: ID!
    name: String!
    account: String
}

!はnon null、nullable

• クエリとミューテーション

クエリは参照。

type Query {
    user(id: ID!) : User
}

ミューテーションは更新。

type Mutation {
    createUser(name: String!)
}

スキーマを書いてクエリで必要な情報を取る仕組み。
クライアントで必要な情報を定義し取得できる。

そのため、例えばAndroid、iOS、PCで取得したい情報が違う場合も、
クライアント側でクエリ(ミューテーション)を書いてもらえば、API側は一つで済む。

• GraphQLのつかいどころ

以下のうち、複数人はマスト。

• バック、フロント複数人で開発
• リモートで対面対応できない
• バックとフロントにタイムラグが有る場合

サンプルのリポジトリがある
Kotlin + GraphQLのサンプル

github.com

Kotlinではスキーマをdata class、
QueryResolverを継承したクラスでQueryを表現する

ミューテーションも同様

joinしたデータを作成するときは
GraphQLResolverを使うと吉。

型があうクラス、メソッドをマッピングしてくれる。

• 認証 Data Fetching Environment
  マッピングできなくなる欠点がある?
  

Contextが使える
各Resolverで使えるので認証に役立てられる。
user_idを入れて認証するなど

• GraphQLのツール Altair
  GraphiQL
  GUIでGraphQLの操作ができる
  クエリ書いて結果を確認できる
  
  

おまけ
apollo-android
スキーマからJavaコードを自動生成してくれる
Springだったらそんなに必要ないかも

もっと Kotlin × Spring 木原 快さん

Kotlin Fest 2019 「もっと Spring × Kotlin」 from Hayato Kihara

www.slideshare.net

KotlinらしくSpringを書きたい方。
Kotlin ✕ Springを書きたい方向け。

Spring 5からKotlinサポートが入った。

実はプラグインでKotlinでSpringが使いやすいような変更が入っている。
Kotlinはデフォルトでクローズであり、クラスを継承するには明示的に修飾子が必要。
しかし、Springで使うにはこの仕様が邪魔であるためプラグインで特定のアノテーションについては修飾子を追加している。

知らないと要らぬバグを仕込むので説明した。
(知らなかった…)

• JUnit5を使う gradleでexcludeしてimplementsする
  スライドに例がある
  
  

spring mockkライブラリ
JUnit5 + mockkでもMockitoのような書き方ができる

• Router Functions

従来のアノテーションによるルーティングに加え、
ラムダベースのルーティングが書ける。

• Spring 5.2での最新情報

Kotlin 1.3、Coroutinesなどがサポート。

Kotlin/Nativeはなぜ動くのか？ 荻野陽太さん

ガチでソース読んだ結果の話でした。
細かい内容はスライドにて。
(披露と眠気と内容のガチ加減であまりちゃんと聞けなかったw)

結論としてはCやC++を呼び出して、プラットフォーム側の実装にあわせているみたい。
もともとJavaからCを呼んだりはできるので可能っちゃ可能なんだろうけど、すごい。

クロージング

コミュニティの宣伝があったのが良いなぁと感じました。

一応ここにもぺたり。
LT会の方は埋まってた!
すごい人気だ・・・!

dena.connpass.com

kansai-kt.connpass.com

ホワイエで提供されていた甘いものたち

ダイエット中でどれひとつとして食べなかったので写真だけ載せときます。
美味そうすぎる…!

懇親会

懇親会では大量に美味しそうな料理が出されて参加したカンファレンスの中でも豪華な方でした。
あとで他の参加者と話していて言われて気づいたのですが、
昼食の配布がなかったので提供されるお菓子や料理が豪華気味になったのかなぁと思います。
品川であれば昼食の選択に困ることはないので、こういうのはありですね。
コミュニケーションの時間が減ってしまうデメリットもあるので、開催側の好みにも寄りそうですが…。

もっと色んな人と話せばよかったなーと思いつつ、
MP切れと酒のんでなかった(言い訳)で知り合いとだべってしまいました。
それでも何人か新しい方と会話できてよかったです。

こんな嬉しいお声がけもいただきました!

あと懇親会でPodcast聴いてます！って言われた！
ありがてぇありがてぇ…！

しがないラジオも聴いたという事で、自分のゲスト会の話もちょっとした。
その時にも話したけど、しがないラジオのお二人はホント楽しそうなんだよね。

行動している最中そうなので、
Podcastが少しでも力になるといいな。

— FORTE@技術書典7【い03C】入門!実践!サーバーサイドKotlin (@FORTEgp05) August 24, 2019

懇親会は端の方に居たのですが、全体的な雰囲気は非常に良かったと思います。
料理も多いし美味しいし、飲み物もビールの種類も多かったし(飲んでないけど)、
料理は手が込んだものが多かったですね。
野菜が多かったのもダイエット中の身としては嬉しかったです。
(からあげとポテトを少し食べてしまいましたが・・・w)

食べかけの写真しかなかったので、お肉だけw

美味そう…！ pic.twitter.com/PAzhVG04gp

— FORTE@技術書典7【い03C】入門!実践!サーバーサイドKotlin (@FORTEgp05) August 24, 2019

もっと本の宣伝と、実際にSpring Boot + Kotlinを書いてる方を探して話しを聞けばよかったなぁと後悔。
次回チャンスがあったらもっと貪欲に行こう。

見れなかったセッションのスライド

TwitterのTLでみつけたもののみ。

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

[日本語注釈つき] Deep Dive into Kotlin DSL

改めて学ぶContracts

Jetpack Compose ことはじめ / the beginning of Jetpack Compose

今からはじめる Android Kotlin

speakerdeck.com

LTのスライド

try-catchからrunCatchingに_移行した話.pdf

KotlinTest で始める Property-based Testing/kotlintest-property-based-testing

Kotlin/JS の仕組み

おわりに

もともと行く予定はなくてTLに流れてきたのをたまたま見たので参加しました!
カンファレンスなので当たり前なのですが、基礎的な内容は少ない感じでした。
しかし、内容の端々で自分が知らない話、勉強になる話が合ったので来てよかったです!

具体的にはKotlinの型の話やSpringでJUnit5を使う話、
Sprtingのプラグインの話などは勉強中の身には知らない話だったのでありがたい内容でした。

サーバーサイドKotlinの話もありましたがそちらも最新の話だったので、
単純に勉強になったなぁと言った感じ。

同時にもっと勉強しないと・・・という焦燥感も感じましたがw

参加した理由の一つに技術書典7で出す新刊「入門!実践!サーバーサイドKotlin」という本を書いているからと言うのがありました。
いくつか取り入れられそうなのと、刺激を受けたので頑張ってかきあげます!
カンファレンスに比べると入門も入門過ぎますが、
JavaエンジニアがKotlinやってみた!という感じの初心者向けの内容になってますのでご興味があればぜひ。

8/26(月)に技術書典7の一般向けページがオープンしますので、そちらでサークルチェックして頂けると嬉しいです!
それまではハッシュタグ「#入門実践サーバーサイドKotlin」で執筆の進捗を呟いてます!

#入門実践サーバーサイドKotlin - Twitter Search

というわけで、楽しかったです!