サーバサイド Kotlin
•Transferir como PPTX, PDF•
12 gostaram•28,012 visualizações
JJUG CCC 2017 Fallでの発表資料
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (20)
サーバサイド Kotlin
- 9. サーバのインフラ構成 PostgreSQL App Server (BeansTalk) Cognito 認証 AWS SNS ・・・ Lambda cron (Cloud Watch) schedule manager (Lambda) Kotlin Kotlin Kotlin
- 10. Kotlinの利用箇所 ● Webアプリケーションサーバ ● Lambdaの処理 ➔ サーバ側でコードを書くところは全てKotlin ➔ クライアント側はKotlinはまだ使っていない
- 11. なぜ、Kotlinを採用したか?
- 12. Javaの言語について ● 1996年 JDK1.0から20年以上 ○ 記述が冗長である ■ 関数を書く時、常にclassの中に入れないといけない。 ■ 関数ポインタがない ■ getter/setterはめんどくさい ○ 検査例外は本当に効率的なのか? ■ streamと相性が悪くない? ○ ヌルポからは解放されるのだろうか? ➔ Java7ぐらいまでは書いていて楽しくない!!!
- 13. classの中にメッソドを書くのはめんどい public class StaticClass { static LocalDate today() { return LocalDate.now(); } } ‣ パッケージが名前空間を定義しているので、わざわざclassで囲まなくても いいよね。 ‣ Kotlinならこれだけ fun today(): LocalDate = LocalDate.now()
- 14. getter/setter public class Sample { private String s1 = ""; public String getS1() { return s1; } public void setS1(String s1) { this.s1 = s1; } } ‣ IDEが自動生成してくれるけど、めんどい
- 15. 検査例外、しんどい public void doSomething() throws OtherException { try { // do something } catch (SomeException e) { throw new OtherException(e); } } ‣ 例外は結局はフレームワークなり、呼び出し元で処理され るだけ ‣ Kotlinなら検査例外がない
- 16. LombokはJavaでの開発をどう変えたか ● Javaの冗長性からある程度解放 ○ Getter/Setterの自動生成 ○ val/var による型推論 (純粋なJavaにもそのうちくるよね) ○ Builderパターンなどの自動生成
- 17. lombokでなら @AllArgConstructor public class LombokSample { @Getter @Setter private String s1 = ""; } ‣ かなりスッキリ。 ‣ でも、まだ、余分な装飾がある ‣ Kotlinならより簡潔に class Test(val s1: String="")
- 18. LombokはJavaでの開発をどう変えたか ➔ Javaでもある程度はハッピーになれたかも ◆ 関数がファーストクラスオブジェクトになれない ◆ 関数がオブジェクトではない ◆ 荒ぶるlombok ● なぜかコンパイルが通らないことがあった ● eclipseがいうことを聞いてくれないことがあった
- 19. 不満はあってもJVM自体は悪くない ● API / バイトコードの互換性の安心感 ○ 例: pythonの2 -> 3の互換性問題は悲しい ● Javaの豊富なライブラリ・ミドルウェア ● ビルド環境やディプロイなどの周辺環境 ➔ JVM言語で、Better Javaを探している
- 20. JVM言語 ● Jython ● JRuby ● Scala ● Kotlin ● Clojure ● Rhino ● … ➔ JVM言語はたくさんあるけど、ほしいものはBetter Java
- 21. Better Javaとは ● 僕の不満を解消してくれてJavaからの学習コストが低いこと ○ 関数・メソッドがオブジェクトである ○ val/varがあること ○ null安全性 ○ lombokのように荒ぶらない ○ 一つのファイルの中に複数のクラスを定義できる ○ いい意味でJavaっぽさも出せる
- 23. Scalaは悪くない、でも、難しい… ● Python使いなので、implicitは好きになれない ● 言語が複雑 ○ Better JavaとしてJavaっぽくはできる ○ それは、プログラマの規約で言語が強制できない ○ 学習が容易ではない ● 型合わせゲームが好きになれない ➔ 僕が言語をちゃんと理解した気分になれない
- 24. そこでKotlinですよ ● 言語自体はJavaとScalaの中間の子(私見) ○ Scalaプログラマなら数時間で学習できる ○ 普通のJavaプログラマでも一週間ぐらいで学習できる ● Javaでの不満をある程度解消 ● Scalaほど複雑ではない
- 25. Kotlin ● 2011年JetBrain社からKotlin登場 ● 2016年2月バージョン1がリリース ● 2017年GoogleがAndroidの開発言語に正式に採用 ○ 言語自体の良さとは別にAndroidの正式採用が選択の理由 ○ 開発者の母集団が増える = 教育コストの低減 ○ 言語自体の安定性の担保
- 28. 開発環境(IDE) ● Eclipse ○ 僕は2005年ぐらいからEclipseユーザ ○ 時々、壊れる ● JetBrainの製品(IntelliJ, Android Studio) ○ ちゃんと動く ○ ネットに落ちているJavaのコードをコピペすると、Kotlinのコードに自動で変換される ○ デバッグでシームレスにJavaの世界と行き来できる
- 29. Webフレームワーク ● Kotlin製 ○ Ktor → JetBrain社製。 ■ 個人での開発ならOK ■ チームでの開発は未知数 ○ wasabi → Ktorに取り込まれた ○ Kara → JetBrainの人が開発。でも開発は続いているの? ● Java製 ○ JavaEE (Jerseyなど) ○ Spring Boot ■ Javaのフレームワークは実績や開発体制など安定感があって◎
- 30. ● Kotlin製 ○ Exposed → JetBrain製 ○ Kwery → 個人で開発 ○ kotoliquery → 個人で開発 ● Java製 ○ Hibernateなど色々 ➔ Exposedを使ってみた OR Mapper
- 31. Exposedを使ってみた結果 ● spring-transactionで@transactionalアノテーションが使える ● kotlinっぽく書ける ● バグが多い ○ データベースに書き込む時のスケジューラに問題 ● ドキュメントが不十分 ○ ソース読め ● 機能不足 ○ Array型がないなど ➔ 割といばらの道なので、Java製のORMを使った方がいい
- 32. ビルド環境など ● maven ● gradle + Kotlin plugin ○ 既存のJavaのエコシステムに乗ります ○ + AllOpen plugin ■ SpringはDIの時に既存のクラスを自動で継承して拡張する ■ kotlinのクラスはデフォルトでfinal ■ pluginでkotlinのクラスをopen(継承可能)にする
- 33. ここまでのまとめ ● フレームワークやライブラリはサーバサイドで利用するには未成熟か開発体 制が不十分 ● 無理をせずにJavaのエコシステムにのって広く利用されているものを利用す るのがよい ● 人柱になりたい人は、ぜひKotlin製のものを使うか、作ってください
- 34. Kotlinを実際に使ってみて
- 35. Kotlinのstream的なもの ● KotlinにはJava 8のStream APIのようなメソッドがiterbleに定義 ○ mapやfilterなど名前や機能が似ている = かなり混乱する ○ kotlinのiterableのmapやfilterでは戻り値がList型になる ■ 常にListが生成されている。 ■ mapやフィルタのたびに、iterableの要素数だけループが回る ● それじゃ、StreamとKotlinのmapなど速度差はどれくれい?
- 36. ベンチマークのテスト Stream list.stream() .map { it + 1 } .map { it - 1 } .map { it + 1 } .map { it - 1} .map { it + 1 } .map { it + 1 } .map { it - 1 } .map { it + 1 } .map { it - 1} .map { it + 1 } .collect(Collectors.toList()) Kotlin list .map { it + 1 } .map { it - 1 } .map { it + 1 } .map { it - 1} .map { it + 1 } .map { it + 1 } .map { it - 1 } .map { it + 1 } .map { it - 1} .map { it + 1 } listは0から10,000,000のIntの配列
- 37. ベンチマークの結果 ← 縦軸はmsec ● チェーンをたくさん繋げるとやっぱり kotlinは遅くなる ● 少なければ誤差の範囲内 ● kotlinはstream()とtoList()は書かなくても よいので、少し楽 ● 速度を求めるならstream() ● コレクションの大きさとチェーンの数に よって使い分けるべき
- 38. KotlinのItearable.map/filterなどは遅いが… ● Iterableではなく、Sequenceとして扱うこ とでJavaのStreamと同等の速度になる ○ Sequenceにすることで、mapのたびにい リストを作らずに、ループの回数がリスト のサイズと同等になる。 list.asSequence() .map { it + 1 } .map { it - 1 } .map { it + 1 } .map { it - 1} .map { it + 1 } .map { it + 1 } .map { it - 1 } .map { it + 1 } .map { it - 1} .map { it + 1 } .toList()
- 39. annotationの違い ● scalaも基本は同じ ● コンストラクタ、メンバー変数のval/varはフィールド定義・getter/setterにな る ● アノテーションをつける時にどこに対してアノテーションをつけるか明示し ないといけない
- 40. アノテーションの例 class Example(@field:Hoge val foo, // field @get:Hoge val bar, // getter @param:Hoge val buzz) // パラメータ ケースによっては @get:Hoge @param:Hoge val foo のように同じアノテーションを複数つけなければならない
- 41. letの使いすぎ ● if文でnull判定するのを悪だと感じてしまう ● 複数の変数を?.let (JavaのOptional.ifPresent的なもの)で判定して入れ子にす る
- 42. こんな感じ return someBar?.let { bar1 -> otherBar?.let { bar2 -> bar1 + bar2 } ?: 0 } ?: 0 return if (someBar != null && otherBar != null) { someBar + otherBar } else { 0 } if文を使っても負けじゃない!
- 43. デフォルト引数とDI ● DIはKotlinで書いたクラスのオブジェクトを自動生成する ● コンストラクタにデフォルト引数を設定すると、自動生成できない ○ Javaの世界からKotlinのデフォルト引数が扱えない ● @JvmOverloadsをつけてあげる
- 46. おしまい