KotlinConf 2018 報告会に参加してきた #JKUG
kotlin.connpass.com
LINEに初めて足を踏み入れました。カフェお洒落。
HAVE A NICE KOTLIN! , Don't have a IC Card!
が今回の鉄則です。
linedevday.linecorp.com
LINEの技術カンファレンス。技術の話聞けて参加費無料！
気になりますね👀行ける様に調整しよう。
以下セッションの内容のメモです。あまり追いついてない上に自分が気になるところ程度のメモなので悪しからず。（）は自分の心の声です。
「KotlinConf 2018 カンファレンス概要とトピックOverview」
www.slideshare.net
オランダ／アムステルダムで開催された KotlinConfにかかわるセッション以外の空気感、カンファレンスの概要 およびイベントを通して感じたトピックをギュッと圧縮してお届けします。
発表者：mhidaka (@mhidaka) | Twitter
カンファレンスと本の編集でお馴染みのエンジニアの日高さん。
空気感や基調講演などをメインとした発表。
今回からはオランダのアムステルダムになった。遠い。12時間くらい掛かる。
街は歴史ある感じ。（行きたい。非常に行きたい。ヨーロッパ行ってみたい。）
東京も寒かったけど、あちらではダウンがいるくらい寒い。
マリファナが合法なのでよく吸ってる人がいるらしく、臭いが強い。（タバコ苦手だから辛そうだなぁ🤔）
元証券取引所。（まじか、ステンドグラス無かったっけ？👀）
1日目はワークショップで、2, 3日目はセッション。
参加者数は1200+で、セッションルームは5つ。
テーマはモバイル・サーバー・学術など偏らず、難易度的にも偏らない様に注意されている印象。
皆ネットワーキングを目的に参加しているので、常にコミュニケーション取れる場所が提供されている。
良かったと思うセッション3つ
セッション自体は50くらいあるので、その中の厳選3つをご紹介。
Keynote by Andrey Breslav
www.youtube.com 一通りわかる優れもの
Shaping Your App's Architecture with Kotlin and Architecture Components by Florina
www.youtube.com
会社の人と一緒に観て欲しい、とうい一本。
Rxをcoroutineでこう変えられるよねなど、今書くならこう書けるよね！というのが分かりやすくて一押し！
Kotlin Coroutines in Practice by Roman Elizarov
www.youtube.com 分かりやすく話してくれている良いセッション。 ダメな書き方をまず教えてくれてから良くしていくという流れで、ステップを踏ませてくれる。
上記3つは英語があまり分からなくても、スライドが良くまとまっているので、見るだけでもある程度分かるものになっているのが推しポイントの一つ。
（どれもすごく気になる内容なので、ちゃんと観てチームで共有しようと思います。）
告知
droidkaigi.jp
初心者だけど、こう学んだよ、というのでも是非。
（と仰っていたので、そんな感じの内容のプロポーザルもさっき追加で出してきました👍）
「KotlinConf 2018 のワークショップに参加してきました」
今年の KotlinConf は初日が Workshop Day でした。 丸一日のワークショップに参加してきたのでその内容と様子についてお伝えします。
発表者：Yuki Anzai (@yanzm) | Twitter
ワークショップは今年から始まった。
649ユーロ = 8万以上！！9:00-17:00で結構ハード！受付は8時。
（受付から会場までの写真良いですね。追体験してるみたいで面白い。）
コースは5つ用意されていて、講師が豪華！Kotlin in Actionの著者の方だったり。JetBrainの方やGooglerの方々など。
github.com
github.com
ここら辺にスライドや使っていたコードに似た様なものが、どことは言わないけど上がっていそうな感じ。Workshopという名前のね。どことは言わないけど。
注意点として、ヨーロッパのカンファレンスに行く人はくぼみに入る変換アダプタを持ってきた方が良い。
（これ最大の罠感ある。危ない。覚えておこう。）
やんざむさんが受けたのはコルーチンのコース。
一通り触ってみる感じの内容。デスクトップアプリといくつかの小さいデモコードがある。
メインのデスクトップアプリ
非同期で処理していくに当たって、非常によく考えられている構成だった。
今までのやり方だとどうなるか、それがコルーチンだとどうなるか、という感じ。 単純にコルーチンを使うだけでなく、repositoryごとにデータを取ってくるのを並列化してみるとか。
blocking = UIが止まっても良いから取ってくるというもの
複数のリポジトリにコントリビュートしてる人はUserIdが重複しているが、同じIDがあったら足していって、という処理をする。それに対して、はいやってみて、と始まったので、なかなか難易度高いワークショップだった。
これの答えとして、講師はgroupingByというのを使っていた。
Groupingというクラスがある。こういうところも勉強になる。
Retrofitのenqueueを利用。callbackはaggregateをするのが大変。
1個目取ってきたリポジトリのcallbackを呼んで、そのリポジトリのcallbackを呼んで〜、とcallabckだと大変。
それがcoroutineだとこう書けるから良いよね、という紹介。
Cancelable, Concurrent, Future, ChannelとActor, Gather...
詳細は先ほどのどことは言わなかったリポジトリを見てください。
（リポジトリのコードにあるデスクトップアプリの方ではなく、小さいデモコードの方をまず動かしてみるのが良いのでは、と懇親会で教えて頂いたので、そうしてみようと思います。面白いですね、コルーチン。）
「KotlinConf 2018 Android編」
KotlinConf 2018のAndroid開発に関わるセッションをまとめてお伝えいたします。 Coroutine, KTXなどなどです。
発表者：akira108 (@hoshi_gaki) | Twitter
Androidのセッション3つを15分で伝える取り組みに挑戦！
LINE LIVEのエンジニアの方。Javaに出くわしたらKotlinに変えていく勢いでやっている。
Android Suspenders by Chris Banes
youtu.be サポートライブラリ作っている人で有名。
なぜコルーチン？
→I/O処理に良い, 限られたハードウェアの中で使いやすい, Rxより簡単
全部cancel書いてたら辛い！
→parentのjobを指定すればまとめてcancel出来るから安心！
が、まだ辛いのがある。parentのjobがない時。終わるまで生き続けてしまう。
CoroutineScopeを使う必要がある構成になった？何かがdeprecatedになった。（理解が追いつかなかったので、資料公開され次第そちらをご覧ください。）
これによってJobがcancelされるようになる。
Rxを置き換えられるのかという心配ありますよね。大丈夫！できます！
Retrofitではawaitを書く必要もなくなるらしい？soon.
Shaping Your App's Architecture with Kotlin and Architecture Components by Florina
youtu.be
コルーチンなぜ使う？ → 学ぶの簡単ほか
コルーチンどこで使うの？ →ほぼ全部に使おう！
APIどうやって使うの？
Resultで包むのを推奨していた（ioschedであったな🤔）
コルーチンすごい！でもJava残ってるんだけど！Javaから使うとコルーチン入れるの辛い...
→Callbackに入れてしまおう、という良い妥協。
インラインクラスを使うことで生成されまくることがなくなる。
UseCaseは一つの責任しか持ってはいけないはずだから、publicな関数は1つにすべき。
だからinvokeオペレータを実装してしまえば良い。
命名相談してUseCaseつけなければ完全に関数名になるし。
Android KTX: A Dash of Kotlin Makes All the Difference! by Dan Kim
youtu.be
KTXの1.0出た！alpha取れたよ！（betaの時とどこが変わったのか調べておくか...）
AOSPにも入ってるから、コントリビュートしてね！やり方教えるね！（これは気になりますなぁ👀）
すごく駆け足だから後でこのセッションの動画観てみてね！
「KotlinConf から見る、最近の Kotlin サーバーサイド事情」
発表者：Hirotaka Kawata /てくの (@hktechno) | Twitter
完全にサーバーサイドのエンジニアの方。
IoTサービスのバックエンドをKotlinで書いている。
思ったよりサーバーサイドのセッションもあった。
何かをやってみたの話が多かった。言語としてはKotlinを使ったよ、みたいな感じの。
サーバーサイド側でも非同期をちゃんとしないと大変なので、コルーチンが熱い。
アメリカよりヨーロッパでカンファレンスやって欲しい。（ここで日高さんがわかる〜と仰ってたのが面白かった😂）
（スライドの情報量が濃かったので、スライド上がったら是非そちらご覧ください。）
良く使われているWebフレームワークは3つ？
- Ktor
- http4k
- Spring Boot
全部入りがほしければSpring
Webフレームワーク比較
業務として使うとなるとまだKtorだと足りないが、コルーチン使いたい場合はKtor。
KotlinNativeを使うにもKtorが可能性ありそう。
業務としてはSwaggerとか使えないと厳しいから、Ktorの今後に期待。
Ktorだとかなりファンクショナルにサーバーが立てられる。アノテーションとか使わなくて良い。
SpringFu, KoFu
（ここら辺理解が追いつかなかった。）
REST APIそろそろオワコンじゃない？という話を良く聞いた。
型がないの辛い、Jsonはパースが重い →GraphQL, gRPC
どこのサーバーを辿っているかを見るのすごく辛い？
→分散Tracing：色々なサーバー立ち上げて、APIたタックという時に必要になっていくのでは。
Kotlin/Nativeの可能性 →まだ辛そう。今後に期待。
JVMは起動が遅いから、Kkotlin/NativeよりはGraalVMの方に期待した方が良さそう？
「Kotlinのユニットテスト ベストプラクティス」
発表者：たろう (@ngsw_taro) | Twitter
「最後に、KotlinConfに行かれなかった太郎さんお願いします。」
お留守番枠だったから一生懸命ビデオを観て発表！
LINEスタンプ売っている。（先ほどTwitterでツイートされていましたね。）
JUnit4
companion objectやJavaに寄せるためのアノテーション、var、従来のモックライブラリだと工夫が必要、whenをバッククォートで囲む必要性、あまり情報を得られないエラーメッセージ...
テストクラスは毎回インスタンスが生成される。
インスタンスに紐づくのではなく、クラスに紐づくstaticが欲しくなる。
JUnit5
上記の様なことがあるから、JUnit5を使おう！という話。
共通のものをstaticにおく必要もなくなる。
ライフサイクルのデフォルト設定が出来る。
@Nestedでグルーピングして読みやすいメソッド名に出来るし、関数名にバッククォートを使うことでスペース入れられたりと人間に読みやすい名前もつけられる。
セッションの人は、JUnit5 + MockK + AssertJという組み合わせを使うそう。
モック生成は高コスト。テストで時間がかかってしまう。clearMocksを使うことで都度リセットする方法を使おう、という注意。
今まで話したものを含めてKotlinで書くとこうなる。
（まとめのメモ忘れた...。資料楽しみにしましょう。）
「build.gradle.kts」
speakerdeck.com 発表者：Panini (@callipan) | Twitter
最後に
いやー面白かったー。久しぶりにブログに書くかーと思うくらいには楽しみだったので、参加できて良かったです。こういう内容共有会本当にありがたいですね。
太郎さんみたくお留守番枠でも動画一生懸命観て何か自分も発表する！みたいな気持ちでやるのも良さそうだなぁ、などの刺激もしっかり受けましたし、良かった。
懇親会も良かったですね。ご飯美味しかった。LINEありがとう。やんざむさんに講義してもらうという贅沢もした。いや、いつも質問しまくって時間頂いてるんですけど。本当にいつもありがたいです🙏
追伸：参加してきた記事が何本か既に出てて、すごいなぁと思いました。
HAVE A NICE KOTLIN!
Firebase Remote ConfigをAndroidに入れようとした時にエラーが出た
現象
https://firebase.google.com/support/release-notes/android
Release Notesを見た感じ、Remote Configはcom.google.firebase:firebase-config:16.0.1
そこでimplementationをしてみたら、
Error:Failed to notify dependency resolution listener. The library com.google.android.gms:play-services-basement is being requested by various other libraries at [[15.0.1,15.0.1]], but resolves to 16.0.1. Disable the plugin and check your dependencies tree using ./gradlew :app:dependencies.
と、gradle buildで失敗しました。
解決した方法
play-services-analytics = 16.0.3
firebase-config = 16.0.0
にしたら実行できるようになりました。
過程
stackoverflow.com
stackoverflowのスレッドを見た感じだとPlayService系のものと今回追加したFirebase Remote Configのバージョンが合っていなさそうなので、修正。
PlayService系はGoogleAnalyticsのものしか入れておらず。バージョンは16.0.3（最新は16.0.4）
RemoteConfigは最新が上記の通り16.0.1。
試しにどちらも最新の状態、PlayServiceのものを16.0.4＋RemoteConfigを16.0.1にしてみましたが、結果は同じく転けたので、解決した方法のバージョンに落ち着きました。
3Dプログラミングの小話：ポリゴン
毎日ブログ書こうキャンペーン中ですが、日付が変わりそう...。
という訳で、パッと書けるネタがなかったので過去の知識を記事にします。
(追記: 結局日付変わってしまったので開き直って書いてます。)
ポリゴンとは
最近VTuberなどが流行っているのでよく3Dモデルを見掛けますね。
そんな3Dモデルの最小描画単位が三角形なのはご存知ですか？
ポリゴンと呼ばれるものです。
描画するには
三角形なので、1つのポリゴンを描画するのには3頂点が必要で、頂点は座標とインデックスを持っています。
例えば、
[index] (x, y, z) [0] (1, 1, 0) [1] (2, 0, 0) [2] (0, 0, 0)
といった具合です。
このインデックスの指定順に三角形を作ります。
これの場合時計回りの三角形になるはず。
この際、右手座標系(右手の親指、人差し指、中指をそれぞれ90度にして、付け根を原点、親指をX軸、人差し指をY軸、中指をZ軸と見立てた時の座標系：Z軸が手前向き)の場合は反時計周りだと表、左手座標系(左手に置き換えた座標系：Z軸が奥向き)の場合は時計回りだと表です。
(OpenGLは右手座標系、DirectXは左手座標系)
設定で変えられますが、基本的に表示される必要のない無駄なレンダリングを減らすために、表のポリゴンしか描画されません。
これは確実に図を描いた方が親切な気がする。
終わりに
最小の描画としてはこれで大丈夫だったはず。たしか。
実際の3Dモデルにする時はもちろんこれだけでは足りず、色とか面ごとに法線持たせるとか様々必要ですが、一番最初に3Dプログラミングで取り組むポリゴンの描画はこれだけで出来るはず。
久しぶりに記憶を辿った気がする。全然覚えてなくて勿体ないからちゃんと復習したいなぁ。
というかこの内容、そんなん常識っしょ、という感じなのだろうか。
