)やんざむさんが受けたのはコルーチンのコース。一通り触ってみる感じの内容。デスクトップアプリといくつかの小さいデモコードがある。メインのデスクトップアプリ非同期で処理していくに当たって、非常によく考えられている構成だった。今までのやり方だとどうなるか、それがコルーチンだとどうなるか、という感じ。単純にコルーチンを使うだけでなく、repositoryごとにデータを取ってくるのを並列化してみるとか。UIが止まっても良いから取ってくるというもの複数のリポジトリにコントリビュートしてる人はUserIdが重複しているが、同じIDがあったら足していって、という処理をする。それに対して、はいやってみて、と始まったので、なかなか難易度高いワークショップだった。これの答えとして、講師はgroupingByというのを使っていた。Groupingというクラスがある。いうところも勉強になる。Retrofitのenqueueを利用。callbackはaggregateをするのが大変。1個目取ってきたリポジトリのcallbackを呼んで、そのリポジトリのcallbackを呼んで〜、とcallabckだと大変。それがcoroutineだとこう書けるから良いよね、という紹介。Gather...詳細は先ほどのどことは言わなかったリポジトリを見てください。(リポジトリのコードにあるデスクトップアプリの方ではなく、小さいデモコードの方をまず動かしてみるのが良いのでは、と懇親会で教えて頂いたので、そうしてみようと思います。面白いですね、コルーチン。2018のAndroid開発に関わるセッションをまとめてお伝えいたします。LIVEのエンジニアの方。Javaに出くわしたらKotlinに変えていく勢いでやっている。サポートライブラリ作っている人で有名。全部cancel書いてたら辛い!→parentのjobを指定すればまとめてcancel出来るから安心!が、まだ辛いのがある。parentのjobがない時。終わるまで生き続けてしまう。CoroutineScopeを使う必要がある構成になった?何かがdeprecatedになった。(理解が追いつかなかったので、資料公開され次第そちらをご覧ください。)これによってJobがcancelされるようになる。Rxを置き換えられるのかという心配ありますよね。→ほぼ全部に使おう!APIどうやって使うの?Resultで包むのを推奨していた(ioschedであったな🤔)コルーチンすごい!でもJava残ってるんだけど!Javaから使うとコルーチン入れるの辛い...→Callbackに入れてしまおう、という良い妥協。インラインクラスを使うことで生成されまくることがなくなる。UseCaseは一つの責任しか持ってはいけないはずだから、publicな関数は1つにすべき。invokeオペレータを実装してしまえば良い。命名相談してUseCaseつけなければ完全に関数名になるし。完全にサーバーサイドのエンジニアの方。IoTサービスのバックエンドをKotlinで書いている。思ったよりサーバーサイドのセッションもあった。何かをやってみたの話が多かった。言語としてはKotlinを使ったよ、みたいな感じの。サーバーサイド側でも非同期をちゃんとしないと大変なので、コルーチンが熱い。アメリカよりヨーロッパでカンファレンスやって欲しい。(ここで日高さんがわかる〜と仰ってたのが面白かった😂)(スライドの情報量が濃かったので、スライド上がったら是非そちらご覧ください。業務として使うとなるとまだKtorだと足りないが、コルーチン使いたい場合はKtor。KotlinNativeを使うにもKtorが可能性ありそう。業務としてはSwaggerとか使えないと厳しいから、Ktorの今後に期待。Ktorだとかなりファンクショナルにサーバーが立てられる。アノテーションとか使わなくて良い。KoFu(ここら辺理解が追いつかなかった。APIそろそろオワコンじゃない?という話を良く聞いた。gRPCどこのサーバーを辿っているかを見るのすごく辛い?→分散Tracing:色々なサーバー立ち上げて、APIたタックという時に必要になっていくのでは。