Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

サーバサイド Kotlin

7,757 views

Published on

JJUG CCC 2017 Fallでの発表資料

Published in: Software
  • Amazing Love Spell To Get Back With your Partner and Fix Your Broken Relationship This is a very joyful day of my life because of the help Dr.Trust has rendered to me by helping me get my ex husband back with his love spell. i was married for 6 years and it was so terrible because my husband was really cheating on me and was seeking for a divorce but when i came across Dr.Trust email address on the internet i explained my situation to him and then seek his help but to my greatest surprise he told me that he will help me with my case and here i am now celebrating because my Husband has change totally for good. He always want to be by me and can not do anything without my present. i am really enjoying my marriage, what a great celebration. i will keep on testifying on the internet because DR.trust is truly a real spell caster. DO YOU NEED HELP THEN CONTACT Dr.Trust NOW VIA EMAIL: Ultimatespellcast@yahoo.com or Ultimatespellcast@gmail.com Call him +1(317) 762-7416
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • These are good web hosting sites || http://ae.hostg.co/17807
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

サーバサイド Kotlin

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

×