Kotlin大好きな人向けなCollectionのstdlibメソッドを掘り出してみた

これはQiita Kotlin Advent Calendar 10日目の記事です。

qiita.com

これマニアックなんじゃね?Kotlin大好きな人向けなんじゃね?ってstdlibにあるIterable/Collection/List/Set/Mapのメソッドを独断と偏見で挙げてみようと思います!

Collection - Kotlin Programming Language

想定読者

  • KotlinのCollectionのstdlibメソッドもっと知りたい人
  • 一旦はさすがです!って褒めてくれる人

環境

Kotlin 1.3.11で使えるメソッドにしています。全メソッドPlaygroundで動作確認済みです。

distinct

説明: 重複削除したListを作る

distinct - Kotlin Programming Language

サンプルコード:

https://pl.kotl.in/HJnYskugV

fun main() {
    val list = listOf(1,1,1,3,5)
    println("List: $list") // List: [1, 1, 1, 3, 5]
    println("Result: ${list.distinct()}") // Result: [1, 3, 5]
}

感想: かー毎回Setに詰め込んでたね。それでListが欲しい場合は、toListしてたね。さらに順番が必要なら色々頑張ってたね。便利😊

intersect

説明: 両方のCollectionに入っている要素をSetにして返す

intersect - Kotlin Programming Language

サンプルコード:

https://pl.kotl.in/SkQkak_eE

fun main() {
    val list1 = listOf(1,1,1,3,5)
    val list2 = listOf(3,4,1)
    println(list1.intersect(list2)) // [1, 3]
}

感想: 知らなかったら、filterとかcontainsメソッドなどで泣きながら書いてたと思う。

union

説明: Collectionをがっちゃんこする。戻り値はSet

union - Kotlin Programming Language

サンプルコード:

https://pl.kotl.in/rykBje_lV

fun main() {
    val list1 = listOf(1,1,1,3,5)
    val list2 = listOf(3,4,1)
    println(list1.union(list2)) // [1, 3, 5, 4]
}

感想: intersectと同じ感想

onEach

説明: 渡した引数のactionを全ての要素に実行し、レシーバーを返す

onEach - Kotlin Programming Language

サンプルコード:

https://pl.kotl.in/HyrGyxugE

fun main() {
    val list = listOf(1,1,1,3,5)
    list.onEach {
        println("Log: $it")
    }.filter {
        it > 3
    }.forEach {
        println("Result: $it")
    }
}

結果

Log: 1
Log: 1
Log: 1
Log: 3
Log: 5
Result: 5

感想: forEachして、そのまま何かしたい!って時にまたレシーバーを書いてたけど、これ使えば全部繋げられるじゃん。便利じゃん。onEachWithIndexとか欲しくなりそう。

partition

説明: Collectionの要素が引数の条件にマッチした要素をPairのfirstのListに。マッチしない要素をsecondのListに分割する

partition - Kotlin Programming Language

サンプルコード:

https://pl.kotl.in/HJgvexugN

fun main() {
    val list = listOf(1,1,1,3,5)
    println(list.partition { it >= 3 }) // ([3, 5], [1, 1, 1])
}

感想: 分割が必要な時、頑張らなくてもいいね!

requireNoNulls

説明: 要素にnullがないことを担保する。もし、nullがあればIllegalArgumentException

requireNoNulls - Kotlin Programming Language

サンプルコード:

https://pl.kotl.in/SJ3VMlul4

fun main() {
    val list: List<Int?> = listOf(1,2,4)
    val listNoNulls: List<Int> = list.requireNoNulls()
}

感想: requireNotNullのCollection版って感じ。nullがないことが前提条件のメソッドとかで利用できそう。(特に気にもせずに無心でfilterNotNullするかもだが。。。)

unzip

説明: PairのArrayに対し、firstの値だけのListとsecondの値だけのListをPairとして返す。

https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/unzip.html

サンプルコード:

https://pl.kotl.in/ryYFNedx4

fun main() {
    val array = arrayOf(1 to "foo", 2 to "bar", 3 to 5)
    println(array.unzip()) ([1, 2, 3], [foo, bar, 5])
}

感想: ちょっと限定的すぎる?🤔いや、こういうのいいですよねきっと!

windowed

説明: Collectionをsizeの要素数のListを作る。次のListはstep分ずれたものからスタートする。

ごめんなさい。どう英訳すれば一番わかりやすいのかすらわからない。以下が原文。

Returns a list of snapshots of the window of the given size sliding along this collection with the given step, where each snapshot is a list.

windowed - Kotlin Programming Language

サンプルコード:

https://pl.kotl.in/r13a_gdxN

fun main() {
    val list = listOf(0,1,2,3,4,5,6,7,8,9)
    println(list.windowed(size = 5, step = 3)) // [[0, 1, 2, 3, 4], [3, 4, 5, 6, 7]]
    println(list.windowed(size = 5, step = 3, partialWindows = true)) // [[0, 1, 2, 3, 4], [3, 4, 5, 6, 7], [6, 7, 8, 9], [9]]
}

partialWindowsがtrueだった場合、sizeに足りてないものも含む。

感想: ちょっと置いていかれたメソッド。これが便利なんだ!というくらいKotlinを使いこなしたい・・・

zipWithNext

説明: Listの隣り合った要素をListのPairとして返す

zipWithNext - Kotlin Programming Language

サンプルコード:

https://pl.kotl.in/r1cjdxOlE

fun main() {
    val list = listOf(0,1,2,3,4,5,6,7,8,9)
    println(list.zipWithNext()) // [(0, 1), (1, 2), (2, 3), (3, 4), (4, 5), (5, 6), (6, 7), (7, 8), (8, 9)]
    println(list.zipWithNext { a, b -> a + b }) // [1, 3, 5, 7, 9, 11, 13, 15, 17]
}

感想: transformを渡せば、数列とかで便利かも?あとは次の値を見て何かするような処理とかでもいいかも。

サーバサイドKotlin+GraphQLのアプリケーションをOSS化しました

これはQiita Kotlin Advent Calendar 2018 1日目の記事です。

qiita.com

ツイートしたら良い反応もらえたので、サーバサイドKotlinのアプリを以下で公開する事に決めました。

github.com

cloneして、docker-compose upしたら、GraphiQLが http://localhost:8090/graphiql 立ち上がって、サーバの動作確認が出来る。簡単!!!

f:id:shiraji:20181214165629p:plain
GraphiQL画面

Ubie内で絶賛開発中のシステムに少し手を加えていますが、基本的に実際に開発している環境と同じになっています。

公開目的

公開に至った理由はいくつかあります。

サーバサイドKotlinやりたいって人のハードルを下げたかった

やりたい!という声はいろんなところで聞くけど、「環境ないし・・・。」「経験無いし・・・。」という方も多いと思ってます。実際Ubie入社前の自分がそうでした。

このプロジェクトは、clone後すぐにローカルで動かす事が可能です。

そのため、このお手軽さを見てもらい、もっと多くの方にサーバサイドKotlinやってもらいたいなーと思いました。

Kotlin+SpringBoot+GraphQLの開発者にコードレビューしてもらいたかった。または仲良くなりたかった

今回、色々な事情があり、KotlinでGraphQLの採用をしています。自分にKotlin+GraphQLの実績がないため、コードを公開することにより、いろんな人に見てもらい、より良いものになったら良いなと思いました。さらに同じような環境の方ともっと仲良くなりたいです!

特に後述しますが、多対多のGraphQLResolverの処理が本当にこんな感じのコードで良いのかが不明です。Spring+GraphQLの情報が少なすぎる。。。もっと効率良く出来そうなんですが・・・

同じ構成のものをOSS化することにより、Ubieの入社即パフォーマンス発揮!をしてもらいたかった

今のところ、Ubieのサーバサイドに関わる人には入社前に1日インターンをしてもらい、チームに溶け込めるか?を見てもらう時間を取っています。しかし、時間が1日しかなく、環境構築に時間を取られてしまうのはもったいないです。そのため、同じ環境をOSS化することにより、先に環境構築出来る状況にしたいと考えました。

さらに将来的には1日インターン宗教上無理!って方にこのOSSプロダクト開発に携わってもらい、雰囲気をそこで味わってもらうのもいいかなと考えています。

技術スタック

このプロジェクトでは以下の技術スタックを利用しています。

今後テスト書くので、以下が追加予定

  • JUnit5
  • Mockk
  • WebTestClient

パッケージ構成

app.ubie.kotlingraphqlsample
├── domain
├── infrastructure
│   └── jdbc
├── presentation
│   ├── queryresolver
│   └── resolver
└── service

(Query)Resolver → Service → JDBCという呼び出し階層になってます。

DB

f:id:shiraji:20181214205606p:plain
E-R図

薬と傷病の関係性のサンプルテーブルになっています。医療業界で利用されているデータに合わせ、IDがなかったり、外部キーがUniqueじゃなかったり、全て多対多の仕様になっています。

DBアクセスはspringがデフォルトで提供しているJDBCを使い、SQLをコードに書いてDBアクセスしています。これは賛否両論あると思いますが、以下の理由から採用しています。

  • SQLのチューニングがしやすい
  • ラーニングコストが低い
  • 一目でどこでどのSQLを発行しているのかがわかる

Flywayを利用して自動マイグレーションが走る状態にしてあります。

GraphQL

GraphQLのスキーマ定義ファイルには薬情報と病気情報が定義されています。

type Query {
    # 薬を取得します
    drugs(yjCode: String!) : [Drug!]
    # 病気を取得します
    diseases(icd: String!) : [Disease!]
}

# 薬情報
type Drug {
    # 薬品名
    name: String!
    # YJ Code。だいたい薬を表すために使われるCode。一意ではないので注意
    yjCode: String!
    # 併用禁忌薬
    kinkiDrugs: [Drug!]
    # 処方してはいけない特定の病気
    kinkiDiseases: [Disease!]
} 

# 病気
type Disease {
    # 傷病に対してつくコード。一意ではないので注意
    icd: String!
    # 病名
    name: String!
    # 処方されてはいけない薬
    kinkiDrugs: [Drug!]
}

Queryブロックには公開APIが定義されています。graphql-javaではこの定義をGraphQLQueryResolverを実装したクラスで記述する必要があります。このプロジェクトではqueryresolverパッケージ内で定義されています。

@Component
class DiseaseQueryResolver(private val service: DiseaseService) : GraphQLQueryResolver {
    fun diseases(icd: String): List<Disease> = service.getDiseases(icd)
}
@Component
class DrugQueryResolver(val drugService: DrugService) : GraphQLQueryResolver {
    fun drugs(yjCode: String): List<Drug> = drugService.getDrugs(yjCode)
}

Drug/Diseaseブロック内にあるkinkiDrugsなどの外部キーを使った結合はgraphql-javaではGraphQLResolver<T>を実装する必要があります。resolverパッケージ内で定義されています。typeがDrugkinkiDrugsの取得時にはfun getKinkiDrugs(drug: Drug): List<Drug>が呼び出される。

@Component
class DiseaseResolver(private val service: DiseaseKinkiDrugService, private val drugService: DrugService) : GraphQLResolver<Disease> {

    fun getKinkiDrugs(disease: Disease): List<Drug> {
        val kinkiDrugs = service.findKinkiDrugsByIcd(disease.icd)
        return drugService.getDrugs(kinkiDrugs.map { it.yjCode })
    }
}
@Component
class DrugResolver(
    private val kinkiDrugService: KinkiDrugService,
    private val diseseKinkiDrugService: DiseaseKinkiDrugService,
    private val drugService: DrugService,
    private val diseaseService: DiseaseService
) : GraphQLResolver<Drug> {

    fun getKinkiDrugs(drug: Drug): List<Drug> {
        val kinkiDrugs = kinkiDrugService.findKinkiDrugsByYjCode(drug.yjCode)
        return drugService.getDrugs(kinkiDrugs.map { it.kinkiYjCode })
    }

    fun getKinkiDiseases(drug: Drug): List<Disease> {
        val kinkiDrugs = diseseKinkiDrugService.findKinkiDrugsByYjCode(drug.yjCode)
        return diseaseService.getDiseases(kinkiDrugs.map { it.icd })
    }
}

多対多な関係が多く、SQLの発行回数が若干多いなーという印象があります。この辺りどうしたらいいのか誰かと語りたい!!!

終わりに

このコード読んで、UbieでサーバサイドKotlinやってみたいと思った方は @shiraj_i に直接DMか以下のWantedlyさんのサイトから話を聞きにきて下さい!

www.wantedly.com

もっと気軽にUbieに遊びに来たい!という方は以下のBosyuさんからメッセージを送って下さい!

bosyu.me

Ubie, incに入社しました。

2018/08/20からUbieに入社しています。3ヶ月の試用期間も無事明けたので、色々書いておこうと思います。

キャリアを変えようとした動機

ちょくちょく話題になる35歳に今年なりました。

2018年4月の時点で自分の今後のキャリアについて悩んでいました。主な悩みはこのままAndroidアプリ開発者を続けるか?です。 Twitterさんや日経さんなど今や多くのWebサイトがブラウザ上での体験を圧倒的に良くするPWAを採用し始めています。PWAと比較してネイティブアプリを作る優位性が、低いレイヤーの処理を必要とするゲームくらいしかないのでは?という不安に陥っていました。このままこのキャリアを続けて5年後、Androidアプリ開発者の需要が万が一無くなってしまった場合、40代で(ゲームではない)Androidアプリ開発が得意です!としか言えなかったら、エンジニアとしてのニーズが無くなりそうだと。Androidアプリ開発者の需要がある今のうちに、新しいモノを試して、駄目だったり、さらにAndroid開発者の需要が増えたら、またカムバックすることが最善策ではないかと考えるようになりました。

Ubieを知る

さぁ次のキャリアどうするかー?といろんな会社にお話させてもらおうと考えていた時にたろうさんの転職のエントリーが出ました。

taro.hatenablog.jp

このエントリーで初めてUbieという会社があるんだなと知りました。当時このブログエントリーの感想は面白そうなことやってる会社だなー。RailsをKotlinに置き換えるとかスタートアップがそんな余裕なの!?でした。

Ubieと話す

たろうさんの記事の後1ヶ月くらい経ってから、Ubieがサーバサイドエンジニアを募集しているということを知りました。せっかくなのでとお話を聞かせてもらいました。

共同代表の久保と話すことが出来て、ざっくりまとめると

  • RailsからKotlinに切り替えるのはガチ
  • 論文を読み込んで、真剣に機械学習に取り組んでいる
  • 精度に関しては圧倒的な自信あり。他社はまず追いつけない
  • 創業して1年目(当時)だけど、日本だけではなく、世界をもう視野に入れてる

のような話をしてもらいました。思った以上にすごすぎて、ちょっとポカーンとしちゃいました。

Ubieに入る

その後、冷静に自分がUbieで働く場合を整理してみると

  • サーバサイドKotlinをやるチャンスがある
  • あのたろうさんと一緒に働ける
  • Data Scienceチームのサポート役の経験を積めそう
  • 組織がまだこれから整備される状況であり、自分の知見が活かせる余地がありそう
  • 事業的には伸び代かなりありそう
  • 創業1年目のベンチャーで、面白そうなフェーズ

自分の次のキャリアとしてこれ以上ないなと思い、入社をさせてもらうことにしました。今では本当にタイミングと運が良かったなと思っています。

入社の儀 f:id:shiraji:20181122235605p:plain

撮影してもらいました f:id:shiraji:20181107121402j:plain

Ubieの業務

入社前からサーバサイドKotlinをしたいと言い続けていたので、希望通り、主なタスクはサーバサイドKotlinをやらせてもらっています。Kotlin化の初期だったということもあり、たろうさんと1on1での開発をさせてもらいました。そのおかげもあり、サーバサイド開発のキャッチアップは結構すんなりいけました。

ライフサイクルが非常にシンプルということもあり、Kotlinのコーディングに集中出来、コード書く楽しさを実感してます。 テストもしっかり書く文化になっているのもお気に入りです。

Kotlinのタスク以外にもGitLabからGitHubへの移行、CircleCIの導入、OSSとしてライブラリの公開などなど色々やらせてもらっています。 毎日のようにテレレ テッテッテーとBGMが頭の中で流れています。

今後はこれらに加えGraphQL+Kotlinや機械学習との連携、SRE業務やPythonでの開発など様々なことに手を出していきます。

リモートRepository移行させたということもあり、正確なPR/issueの数とかわからない+自分の働き方上、多くのRepositoryに顔出しているので、分散しちゃっているのですが、一番コミット数が多いRepositoryはこんな感じでした。

f:id:shiraji:20181121012248p:plain

Ubieの制度 - リモートワークと有給休暇

Ubieは「週2のリモートワークが可能」です。オフィスの環境が良いこともあり、多くの人がオフィスに出社しています。今の事業フェーズではあまりうまく事が進むように整備し切れていないため、フルリモートは出来ないようになっています。今後可能になるように絶賛整備中です。

自分は奥さんと子供がいます。台風が来た週、子供が熱を出してしまったため、台風で一日、子供の看病で一日リモートしました。さらに子供の熱が下がらない可能性があり、有給休暇を取るかリモートするか悩んだため、Slackで投げかけてみました。

f:id:shiraji:20181121005053p:plain

リアクション見てもらえばわかる通り、看病であれば、週3日のリモートもOKでした。

ただ、さらに良くないことが続きました。自分の奥さんが入院することになってしまいました。自分たち家族は親族が新幹線乗らないと来れない距離にいるため、今までであれば、この状況に陥った場合は有給を使い看病することになります。入退院を繰り返すことになってしまったので、合計すると3ヶ月のうち、約1ヶ月はリモートしていました。最大2週間連続でした。でも同僚は自分がうまく働けるように工夫してくれました。

この件からUbieのリモートワークのルールは「週2のリモートワークが可能。ただし何かしら理由があり、恒久的でなければフルリモート可」が実態です。

ということで、この3ヶ月会社にいないことも多かったのですが、最終的に有給休暇の消化0です。子供が産まれてから子供の看病のため有給休暇を取得し、毎年有給消化率80%は越えていました。あんまり自分のための有給を取った覚えがなく、どういうタイミングで取ればいいのか悩んでいます。ちなみに有給は休みます!と宣言したら取れますし、週5のフルタイムであれば入社日に14日付与となります。

Ubieの制度 - 勤務時間

Ubieは裁量労働制です。

日本で初めて入った会社が裁量労働制で、朝9:30出社(1分でも遅刻NG)で帰りは残業などして夜10:00がザラでした(見込み残業が30時間だったので40-50時間くらいサービス残業してました)。そのため、裁量労働制に対して非常に嫌なイメージを持っていて、それ以降裁量労働制の会社を避けていました。

Ubieも裁量労働制だと聞いたので、若干の残業は覚悟の上で、プライベートは絶対死守しようと考えていました。しかし、実態はUbieはしっかり裁量労働をさせてくれています。遅刻という概念がほぼなく、業務中にお昼寝や映画を観にいく人もいます。自分は現在奥さんが病気になってしまったこともあり、朝息子を保育園に送り、夜迎えに行くことが必須となっています。そのため、出社が10:00頃になり、退社は17:30です。30分業務時間が足りてません!しかし自分の労働時間ではなくアウトプットを見てくれてますし、足りていない分、家で仕事して補填しています。トータルでは残業はほぼなしです。

自分があまりの早さで帰るため、Ubieの他の社員さんたちがどれだけ残業しているのかあまり把握していないですが、自分より早く来て早く帰る人もいますし、自分も今後も残業0時間を目安に働いていこうと考えています!

Ubieの制度 - KPT

Ubieでは週次でチーム内KPTをしています。リモートワークを始めたタイミングではたろうさんや自分が今何をやっているのか把握できない事態に陥ってしまったため、この課題がKPTのPとして挙がりました。解決策としては「Slackで始業時に今日のTODO共有する」としたところ、お互い何をやっているのかが把握でき、リモートでも非常にスムーズにタスクが進められるようになりました。

こんな感じで毎朝やってます。この日はリモートで9時から開始

f:id:shiraji:20181122215342p:plain

残業ほぼなし、リモートもしていて、パフォーマンスが下がらないか不安だったのですが、問題があれば、都度全員で解決策を考え、改善していく文化があり、色々手助けをしてもらい、特にパフォーマンスを落とさずにタスクがこなせています。

他にも良いと思ったものを取り入れたり、逆にこれは減らして良いだろうと判断したものは削減したりと試行錯誤していて、ガンガン変わっていく姿が見れて楽しいなーと感じています。

Ubieの社員構成

Ubieの中でかなり気に入っているのがこの社員構成です。

f:id:shiraji:20181121013528p:plain

特徴的なのがSaaSのスタートアップにデザイナーが2人揃っていること。しかも強い。この2人がUXのためなら公民館だろうが診察室だろうがガンガン入っていってより観察しまくります。動き方はUIデザイナーではなく、サービスのデザイナーです。医師が2人いるのも特徴的です。Ubieに入って初めて医師って全員が全員病院に勤務するわけでもないのだなという気づきがありました。弊社の医師だけなのかもしれませんが。全体を観て、バランスが非常に取れている組織だなーという印象を受けています。(業務委託の人がカウントされていないので、その人たちを含めるともう少しエンジニアの数が増えます。)

ちなみにこの社員構成ですが来月には数字がいくつか増えます。どんどん大きくなっていっていて、ワクワクします。

終わりに

ということで、3ヶ月しか働いていないこともあり、良いことにしか目がいっていない恋は盲目状態のブログエントリーでした。

半年くらい働けば、きっと悪いところももっと見えてくるはずなので、来年落ち着いたらまた続編を書いていきたいと思います。

これを見て、興味あるなーという方は @shiraj_i にDMしてもらうか、以下で応募して下さい。

https://www.careers.dr-ubie.com/www.careers.dr-ubie.com

一覧にはないのですが、SREやデータサイエンティストも募集してますのでぜひ!

直近ではこんなイベントもあるよ!

bosyu.me

bosyu.me

brave-ktをリリースしました

Ubieという会社に入社して、brave-ktというライブラリを公開しました。 Ubie入社ブログエントリーは試用期間明けたら書くとして、このライブラリについて書いていこうと思います。

想定読者

  • Ubieのシステムに興味ある人
  • サーバサイドKotlin興味ある人

前提

今自分が関わってるプロジェクトではSpring Boot2.1+Kotlin1.3+GCP(GKE, CloudSQL)を利用して、RESTfulのAPIを開発しています。 ざっくり図にするとこんな感じです。

f:id:shiraji:20181103114707p:plain

よくある構成だと思います。 ユーザがAPIを叩くと、最初にロードバランサーに到達し、アプリサーバを経由して、DBアクセスします。

ログ出力

この構成で問題になるのはログです。一つのリクエストを処理するのに複数のコンテナが関わっており、あるユーザのリクエストを追跡する場合、ログを一つ一つ確認していかなければなりません。

f:id:shiraji:20181103114819p:plain

この問題を解決するために出てきたのであろうものがStackDriver Traceです。 導入すると以下の公式ドキュメントのquickstartの画像のようにTimelineのところで複数のコンテナのログを一つのリクエストごとにまとめてくれます。

f:id:shiraji:20181103113249p:plain Quickstart  |  Stackdriver Trace Documentation  |  Google Cloud

StackDriver Traceの導入

StackDriver Traceの導入には、Google Cloud SDKが必要です。

Installing Google Cloud SDK  |  Cloud SDK Documentation  |  Google Cloud

gcloudにログインして、project名を設定します。

gcloud auth application-default login
gcloud config set project [PROJECT名]

Spring Bootでの導入には設定をいくつか追加します。Ubieではlogbackを利用しています。 ちなみに、spring-cloud-gcp-starter-traceの1.0.0.RELEASEは動かないので注意して下さい。

build.gradle

repositories {
    // for spring-cloud-gcp-starter
    // There is a bug on 1.0.0.RELEASE
    maven { url "http://repo.spring.io/libs-milestone" }
}

dependencies {
    compile 'io.sentry:sentry-logback:1.7.5'
    def springCloudGcpVersion = '1.0.0.RC1'
    compile("org.springframework.cloud:spring-cloud-gcp-starter-trace:$springCloudGcpVersion")
    compile("org.springframework.cloud:spring-cloud-gcp-starter-logging:$springCloudGcpVersion")
}

logback-spring.xml

<configuration>
    <springProfile name="production">
        <include resource="org/springframework/cloud/gcp/autoconfigure/logging/logback-appender.xml" />

        <root level="INFO">
            <appender-ref ref="STACKDRIVER" />
        </root>
    </springProfile>
</configuration>

application.yml

spring:
  cloud:
    gcp:
      trace:
        enabled: true
      logging:
        enabled: true
  sleuth:
    sampler:
      probability: 1.0

問題発生

さて、ここまでやってログを出してみたのですが、以下のようになってしまいました。

f:id:shiraji:20181103115315p:plain

queryのログなどがまとまっています。しかし以下の赤線の部分がquery実行中になるはずなのですが、queryの実行時間などを見ることが出来ません。

f:id:shiraji:20181103115520p:plain

これはCloudSQLがTraceなどに対応していないように見えます*1

つまり以下のような感じになっているようです。 f:id:shiraji:20181103115826p:plain

これを解決するためには、GCE上のSpring+Kotlin側で明示的にログを出力する以外手は無さそうです。

ようやく本題

この問題を解決するため、TraceのライブラリにあるScopedSpanを使います。

val span = Tracing.currentTracer().startScopedSpan("db access")
try {
    jdbcTemplate.query ( ... )
} finally {
    span.finish()
}

こんな感じに表示されるようになります。良さそう。 f:id:shiraji:20181103121824p:plain

それでこのコード見てて、Kotlinだしもうちょっと書きやすくできないかなーって思い、ライブラリを作りました。それがbrave-ktです。 これを導入すると以下のように書けるようになります。

val result = tracer.scopedSpan("db access") {
    jdbcTemplate.query ( ... )
}

以上!(二行しか紹介してない。。。)

宣伝

さて、Ubieでは、エンジニアを募集してます!

https://www.careers.dr-ubie.com/www.careers.dr-ubie.com

結構GCPにはヘビーに今後も依存していくので、その辺り関わりたいSREの方や、Spring+Kotlin書きたいサーバサイドKotlinやりたい人はぜひ応募して下さい! 雰囲気先に知りたいって方は以下のただ社員が遊ぶイベントがありますので、どんな感じか確認しにきてください。

bosyu.me

ちょっと怖いから何からすればいいかわからない。という方はTwitterでDMして下さい。

Kotlin Fest 2018に参加してきました

Kotlin Festの感想ブログを読んでいて、やっぱり自分も書きたくなっちゃった。だから書く。

登壇依頼

DroidKaigiの発表の時、CfPを出すものだと思っていたので、何を書こうかなー?って思ってたのですが、一向にCfP出せる場所がなく、本当に大丈夫なのかな?と心配していたら、@satorufujiwaraさんから依頼を直接受けました。日時が土曜日だったこともあり、家族に確認を取り、なんとか了承してもらって参加することに決めました。登壇内容はHow to Kontributeを日本語でやってほしいという話でした。

もともとはHow to KontirbuteはOSSの話であるし、日本人だけにやるものではないと思っていて、英語でやるものだというイメージがあったのですが、藤原さんがそういうならと日本語でやってみようと思い、快諾しました。

登壇準備

準備は英語のプレゼンを日本語にしていくだけなので、簡単だと思ってました。が、初めてリハをやったときは52分(セルフィーなし)という記録を出してしまいました。これはプレゼン最中にふと思ったことを口にしてしまえる母国語だからで、これ重要だ!とかここで笑いを取りにいけそう!と思ったら口に出してしまい、グダグダに伸びるという状態でした。さすがに5分以上超過はまずいと、スライドを何枚か削り、メモを英語で書いていたので、あまり考える余地を作らせないために、日本語に書き直すなどの対処をしました。

スケジュール確定

スケジュールを知ったのはconnpassでスケジュールが公開された時です。公開された+LTと同じというのを同僚の某主催者から聞かされました。 カンファレンスでは基本早めにトークさせて下さいって毎回お伝えしているのですが、Kotlin Festでは時間の指定しなかったです。ただまさか最後になると思ってなかった+LTとセッションを同時刻にやると思ってなかったので、決まった時の本音は「それはないわー!」でした。

前日

完全に見落としてたのですが、ランチがないことにconnpassを見て気づきました。 で、せっかくだし、色んな人と話したいと思ったので、こんなツイートしました。

これツイートする前に結構文章推敲してて、それを嫁ちゃんが横で見ていて、ツイートしたらぼそっと「これで誰も来なかったらウケるw」って言われてまじでこれで来なかったらどうしようと泣きそうになりましたが、結果4人も集まってくれました!

ちなみに夜にリハする予定だったのですが、気づいたら、寝てて、3時くらいに「あ、この登壇終わったわ・・・」と愕然としてました。

当日(午前中)

時間通りに到着しました。ビルの入り口がわからなくて迷子になったけど。

登壇者の控室がものすごく広くて快適でした。快適だったんですが、これなら3つの会場にしてもらって、もっと色々発表あったら!と思ったけど、あまりに快適だったからやっぱりそのままがいいです。控室にもセッションの音とスライドが見えていて、登壇準備や練習をしつつ、聴けるという最高の環境でした。

オープニングは会場の雰囲気を確認したく、2列目で聴いてました。そしたら、LTと時間がかぶったためなのか、二回も紹介してもらっちゃって、もうテンション上がりまくりでした。

「Kotlinを愛でる」をプッシュしまくっていたので、じゃあ、ということで、タイトルにEmbracing Kotlinを追記しました。

ランチ

前日に募集したのですが、何話すとか、何も決めずに向かいました。 お店は朝迷ったときにビルの1階に肉のお店を見つけて、暑かったし、そこでどうでしょう!って即決しました。 初めて会った人ばかりだったのですが、一時間Kotlinの濃い話が出来ました。もっと時間あったら良かったのですが、本当に楽しかったです。 また登壇とかする機会があれば、スピーカーということネタにランチ募集しようかなと思いました。

当日(午後)

参加者と交流することが目的だったので、セッション一つも聴いてないです。(そのためPSIViewerがこの日二回目の登場だったのを知らなかった)

Yahooさんのブースでモブプロやるって言っていたので、参加しました。 モブプロはあと一人か二人自分のチームに入ったら、たろうさん、自分含めやってみたいなーと思ってたので、どういう感じになるのかな?ということで参加しました。 RESTのAPIを作るプロジェクトでした。Springの知らない機能を使っての実装だったので、あんまり口が出せなかったのが残念だったのですが、気になっていた、意見が衝突する場合、どう解消するのか?を知りたく、それまでの話からドライバの方が想定していたであろうControllerのメソッド名(findById)ではないもの(show)にしませんか?と叫んでみました。 まぁRESTのControllerのメソッド名はあんまり影響ないためか、参加者から挙がったものだからか、特に議論もなく採用されてしまいました。 あー!やっちまった!ということで

さすがに時間が短かったなーという印象です。登壇前の30分でしたし、参加者は席を取りたいし。 個人的には実際に意見がぱっかり割れた時にどのように合意が形成されるのかが知りたかったです。 RESTのAPIを作ることが目的になってしまっていた感じで、うーん、じゃあSpringのライブコーディングという形にして、モブプロではなくても良いんでは?となってしまいました。 でもモブプロを疑似体験出来て良かったです。設計するタイミングとかでの採用もいいなーという感じでした。

他にもmixiさんやCAさんのブースのPuzzler参加しました。mixiさんの方では、何問か間違えましたが、なんとか良い結果だったと思います。CAさんの方はさっぱり過ぎて、手元にIDEAないと無理でしょこんなん!という感じでした。楽しかった! ただ、CAさんの方、これせっかくやるならエンジニア一人は常時ブースにおいてほしかったです。ブースにいる方がふたりともエンジニアじゃなくて、このコードに関してーとか話そうとしたのですが、エンジニアじゃないので、またあとで来て下さい!と言われてしまって、うおー聴きたい!と消化不良でした。もっと話したかった!

ブースを一通り回ってから、控室に戻り、スライドの手直しをはじめました。控室で他のスピーカーの話が聞こえるの非常に良いのですが、あまりに面白そうな内容で気になってしまって、控室前の椅子に座って準備してました。トイレ前だったこともあり、結構色んな人に話しかけてもらえて、これはこれで楽しかったです。登壇前の緊張がほぐれたし、色々また勉強することが出来ました。

登壇2時間前くらいに自分のスライドの特にInspectionの実装コードのスライドがちょっとこのカンファレンスの空気と合ってないなーと感じました。 そこで、登壇時間が懇親会前ってこともあり、急遽いらすとやさんの飲み物、食べ物の画像をペタペタ貼り、Twitterで盛り上げようぜ!というスライドを追加しました。

残り時間少しということもあり、最後のリハをしました。控室で外向きながら小声でブツブツ話していたので、傍目から見たら相当やばい感じだったと思います。

登壇

登壇前15分に会場に行きました。 アダプターが合わず、かなり焦ったのですが、スタッフ、会場の皆さんに探してもらい、ちょうど良いものを10分くらい前にそろえてもらいました。本当に感謝です。 さらに想像通り、結構な方がLTの会場に向かっていました。そこで登壇者の控室で近くにいた、m3の方たちに控室で聴けるにも関わらず、空いてるから会場に来て下さい!とお願いしたら本当に来てくれてしかもかなり前の席を確保してくれるという神対応をしてもらいました。

登壇前めっちゃ緊張してたのですが、@mhidakaさん、@shanonimさん、@chiiia12さんが色々話しかけてくれて、結構リラックスしてやることが出来ました。

登壇中、いくつかのスライドで頭真っ白になってしまい、あれ?何話すんだっけ?とめっちゃ頭がフル回転したのは覚えています。 会場に聴きにきてくれた人たちの反応が暖かく、自分が思った通りのところでしっかり反応してくれていて、やっぱりKotlin界隈暖かくていいなーと。 懇親会のための気分盛り上げのいやすとやさんも反応が良くて、してやったり!でした。

photos.app.goo.gl

終わった後気づいたのですが、LT会場でも結構自分のことを紹介してもらっていて、さらにスタッフの機転でLT後に自分の会場もつないでもらったようで、本当にごちそうさまでした。

懇親会

懇親会ではパックマンルールが採用されてました。本当にこのルールいいですね。 懇親会だと仲良い人と話すことになりがちなんですが、空いているので、入ってきやすいし、輪を作ってる人も周りを意識している感じでした。 でももっとはじめましてな方と話したかった!

最後に

ものすごく楽しかったです。Kotlin Fest 2019も登壇したい!!! Kotlinをもっともっと愛でたい!!!!!!

Google IO 2018に行ってきました

まとめ

AIとJetpackとConstraintLayout

前提条件

会場で起こったことをつらつらと書いていきます。技術的な話は一切ありません。苦手な人は戻るボタンで戻って下さい。

前日

SFにはGoogle IO前日に到着しました。 飛行機内がガラガラだったため、平らな場所で足を伸ばしてのんびり出来ました。

f:id:shiraji:20180507163758j:plain:w300

1時間ほど寝れたのが良かったのか時差ボケはなかったです。筋肉のおかげかもしれません。筋トレしてないですけど。

着いてすぐにSFで仕事があり、SFO->SFにBARTで行きました。 先方と会議をしてから、CaltrainでSF->Mountain Viewへ移動。 このまま会場でBadge Pickupしたかったのですが、スーツケースが飛行機で壊れされちゃったので、

f:id:shiraji:20180509232348j:plain:w300

一旦AirBnBの宿泊先に行きました。プール付きでした。

f:id:shiraji:20180509232225j:plain:w300

一日目(Keynote)

セッションの予約はこのセッションだけは聞かないと帰れない!というKotlinの2セッションだけ前日までにしていて、あとはKeynoteを確認してから予約しようと考えていました。 前から聞いていたけど、KeynoteはAI一色。何をするにもAIが入っていた気がします。他にはJetpack周りが大きいかな?という印象でした。 自分の現在のタスクがAndroid開発から離れ、R&D的な仕事をしているため、知識を広げることに重きを置き、聞くセッションを決めました。 それと一回はコミュニティのMeetupに行きたかったので、二日目のOSS Community Meetupに行くこととしました。

一日目(セッション)

と、Keynoteでは考えておきながら、いくつか会場を間違えて入ってしまったので、結果的にAndroid中心に聞きました。

The future of apps on Android and Google Play: modular, instant, and dynamic

印象的だったのが、間違って入ったセッションの一つのThe future of apps on Android and Google Playで Dynamic Featureです。ざっくり概要としてはDynamic Featureの話の前提としてアプリサイズは小さく抑えたいよね。 ほぼ使わない機能は使う人にだけ渡せば良いよね?という流れから出来たであろう機能です。 実際、アプリを開発していて、この機能90%以上のユーザ使わないな。って機能結構あるので、非常に良いなーという印象でした。 code pushみたいな名前なので、戸惑う可能性があると思いますが、apkをGoogle Play内で分割しているという印象なので、Dynamic featureだけを更新するとかは出来ないようです。

Modern Android development: Android Jetpack, Kotlin, and more

他のセッション聴いていてもそうなんですが、今後Android開発ではJetpackが台風の目になるのは確実だなという印象を受けました。 ただ若干勇み足な感じもしていますが。。。詳しいことはすごい人に任せます。

一日目(セッション後)

アメリカで働いている同僚と落ち合いました。そこにいた色んな人とお話が出来ました。 そこまでほぼ一人で行動していたので、楽しかったです。日本の初めてお会いする方ともお話が出来ました。 マジックショーがあったので、それを見て、AirBnBの方へ戻りました。

そこから日本のチームと仕事してたのですが、なぜか3時までやってました。

http://livedoor.blogimg.jp/jigokuno_misawa/imgs/4/0/403d15ec.gif

惚れさせ155 「実質」

二日目(セッション前)

朝8時前にAirBnBを出たのですが、Lyftの車が全然来なかったです。値段が跳ね上がってました。初めてシェアして乗りました。 道路も混んでおり、降りた時点で8:30過ぎてました。 一緒に乗車していたロシアの方と降りた後話が盛り上がり、入り口でものすごい並んだので、二人でデバイスピックアップにいきました。 Android Thingsはパズルやらないとあげないーとかわいく拒否されたので、前日終わらせていた彼にヒントもらいパズル解くことにしました。 会場入り出来たのが結局9時前だったので、朝ごはん食べつつ、掲示されているブースを色々回りました。

二日目(セッション)

  • What's new in Android Things
  • [Meetup] Open Source community
  • Build real consumer devices with Android Things
  • TensorFlow for JavaScript
  • Web Components and the Polymer Project: Polymer 3.0 and beyond
  • Android Jetpack: what’s new in Android Support Library
  • ML Kit: Machine Learning SDK for mobile developers
  • Integrating your content with the Google Assistant using AMP and markup
  • The power of Headless Chrome and browser automation
  • Machine learning models + IoT data = a smarter world

この日はトピックがうまくバラけました。

Open Source Community

初日に参加を決めたOpen Source CommunityではGooglerのOSSの人たちと話せるということで、GoogleOSSにも関わりたいなーと思っていたので、ぜひにと気合入れていきました。 そしたら、すんごいふんわりいつの間にか始まっていて、勝手に話して良いよ?と言われ、うまく輪の中に入れなかったので、一緒に輪に入れなかった人たち+後から来た人たちと話しまくってました。 結局40分ほどずっと同じ人達と話してGooglerと話さなかったwでも普段かかわらないnode.jsのコントリビューターやUS政府のプロジェクトに関わっている人たちと話せたのは良い機会でした。OSSをやりたいけど、やったことがないという人たちにアドバイスとかもしてました。 プロジェクトへの参画動機や最初のコミットどこから?などみんな同じような考えをしていたのが印象に残りました。

TensorFlow for JavaScript

特に印象に残ったセッションの一つのTensorflow for JavaScript。お昼ご飯食べつつ、片耳で聞いているかーと思い芝生から聞いていたのですが、途中から楽しくなっちゃって食べずに話ばっかり聞いてました。 tensorflowの結果をブラウザで見える化したらすごい良いレスポンスだったので、JSでtensorflow出来るようにしてみたらしいです。 ブラウザで出来るというのはすごく敷居が下がって良い。さらに過去サーバでpythonなどで生成したモデルもそこで再利用出来るのも既存の資源が無駄にならないのも良い。 高校生や大学生が利用しているとか。AIを高校生の時点で学べるなんてなんて贅沢なんだ。。。 さらにこの日サーバサイドでnode.jsが使えるようになったという発表されました。python一色だったtensorflowにJSの流れが来ているので、今後注目だなーという感じでした。

Web Components and the Polymer Project: Polymer 3.0 and beyond

Polymerの発表もすごかったです。Polymer界では有名な二人が登壇するとあって、登場しただけで拍手出てました。ニワカなので、すごさがわからなかった。 内容はもう怒涛な感じでした。前日の睡眠不足から、このあたりで眠気くるよなって思ったんですが、寝てる暇ないくらいどんどん新しい情報をinput出来ました。 Polymer3.0が使えるようになったことと今議論進んでいる内容も含めて色々話が聴けました。このセッションのメモ「情報ありすぎてウケる」で終わってました。 動画確認してみてください。本当に怒涛です。

Android Jetpack: what’s new in Android Support Library

昨日からちょくちょくJetpackのFragmentという言葉が出ていたので、あーヤバそうだなーって思い、これを聴いて、パッケージが変わるのが確定したので、issueあげておきました。 https://github.com/permissions-dispatcher/PermissionsDispatcher/issues/472

書いた後にFragmentだけじゃなくActivityもじゃね?別のsupport libのクラスもじゃね?って思ったんですが、後で考えることにします。

二日目(セッション後)

前日に続き、仕事がふってきていたので、コンサートも参加せず、AirBnBで仕事していました。自分頑張りすぎだと思う。

賞賛して下さい。

f:id:shiraji:20180509205058j:plain:w300

三日目(セッション前)

朝は結構空いていました。3日目ともなるとみんな体力なくなるのかな?

まず朝初っ端からPermissionsDispatcherの対応に関してOffice Hourに向かいました。 ただ、残念ながら、support libraryの人たちではわからないと言われ、Sandboxへ行くように言われ、 行ってみたら、わかる人がまだ来てないとのことでした。 もうこの時点で結構時間を取られていたので、セッション終わった後にまた来ると伝え、場所を離れました。 たらい回しになったのですが、みんな良い感じで接してくれたので、特に嫌な思いをしなかったのが良かったです。

最終的にこのコメントになりました。

https://github.com/permissions-dispatcher/PermissionsDispatcher/issues/472#issuecomment-388219243

三日目(セッション)

How to Kotlin - from the Lead Kotlin Language Designer

Kotlinの神が初心者向けのKotlinの説明をしてくれました。 どんどんコードが短くなっていくなーって眺めていたら、coroutineの説明が出てきて

あー最早coroutineは初心者向けの常識なのかと驚きました。

Android Jetpack: sweetening Kotlin development with Android KTX

Jakeさんのセッション。 ktxの説明よりKotlinのライブラリを作るにはどうしたら良いか?という説明の方を目的に聴きました。 ktxの方の説明、力抜いていたのですが、ライブラリの話になって、急に@ExtensionFunctionJavaコードにつけたら、Kotlinが勝手にExtension Functionと認識して呼べるようになる だからこれをつけよう!って話していて、このアノテーションを出された時点で混乱して、ググっても情報なんら出てこないし、 どういうことだ?って思ったら、この発表の1時間前にKEEPにJakeさんが上げた内容の説明だったようです。

github.com

あまりに驚いて。

What's new with ConstraintLayout and Android Studio design tools

すごい。やばい。

セッションを見てないAndroiderは最初のほうは流していいから、早めに観たほうが良いです。 三日間のセッションで一番拍手が凄かった。

三日目(セッション以外)

三日目で人も少なかったし、アグレッシブに動き周りました。

  • Android Assistant
  • Android Auto
  • Design & Accessibility
  • Codelab
  • 友達が出来た+会えた

Android Auto

Android Autoは前から楽しみにしています。 一緒に並んでいた4人と車の中で説明をしてもらいました。 車のエアコンのコントロールを声で出来たり、Google Assitantを利用して、メッセージのやり取りなどそ実践してもらいました。 大きなサイズのものなのか、タブレットサイズで、画面が非常に見やすかったです。

f:id:shiraji:20180510145040j:plain:w300f:id:shiraji:20180510145110j:plain:w300f:id:shiraji:20180510145306j:plain:w300

NY Timesなどがサポートしているようで、音でコンテンツを提供できるアプリなどは最高だなーという感じでした。

Codelab

Codelabは多くの問題があり、Googlerに聴きつつコードを書ける場所だったのですが、ChromeOS with Linuxが気になってしまい、 マシンスペック見たり、コマンド触ってみたり、全くCodelabとは関係ないことをしていました。

帰国便待っている時に@ymndさんから聴いたのですが、実機確認が直接出来ないとのことだったので、開発機としてはやっぱり厳しいのかなー?と思いつつ、curlsshなども出来たし、サーバサイドの開発などには可能性あるかもなーとぼんやり考えてます。

友達が出来た+会えた

OSSのCommunity Meetupだけではなく、偶然話しかけてくれた人と仲良くなったり出来ました。

また、普段会えない人たちともお会い出来ました。道ですれ違って挨拶だけしかしなかった人が何人かいて、時間が足りませんでした。。。突然だと「あ、あ、」ってなってしまう。。。

その中でも特に印象が残っているのが、以前Kotlin Night Koltakaでリモートで挨拶させてもらった@ravidsrkさんと偶然隣の席になり、お話出来たことです。

彼はKontributeの動画を観てKontributeし始めてくれた一人で、さらに自分の公開しているプラグインもガッツリ使ってくれているようでした。 会社の環境構築フローに自分のプラグインを数個入れてくれていて、Find Pull Requestなんてあるよ?と説明したら、めっちゃ喜んでくれました。 最近これ動かないけど、どうしたの?とか、この機能公式に取り込まれたね!とか作った本人よりプラグインのこと知っててくれて本当に嬉しかったです。

最後に

Android周りはスゴイ人たちがわかりやすく説明してくれるはずなので、新しい出会いを求めることに努めて非常に良かったなーという印象です。 このIOでAndroid関係ないTODOの優先度最高なものがいくつか出来たので、何かしら形にしたいなーと思っています。

DroidKaigi 2018で登壇した&参加した

技術的な話は相変わらず一切ありません。いつものヤツです。 そういうのが嫌いな人は「戻る」ボタンをクリックして下さい。

前日

プレパーティーに参加しました。

ウーロン茶を持って、色んな人と話しました。楽しかった。もっと時間欲しかったです。

名札をもらったのですが、その後のコミュニケーション取るためにQRコード貼り付けました。

でも話しかけてくれる人自分をフォローしてくれている人だったので、これをスキャンしてくれる人誰もいなかったです。 DroidKaigi2019では何かしら連絡方法をこれで交換できるようにしてくれたら嬉しいなーと思います。

初日の午前中

午前中はwelcomeトークを聴いてテンション上がりました。公式アプリのコントリビュートもなんとか出来たので、きっと自分のアイコンもあったと思いますが、スマホ探していて見逃しました。

Kotlin User Groupのたろうさんから以下のイベントが発表されました!

これは楽しみです。登壇できるのかどうかは不明ですが、絶対参加したいです。

その後、申し訳ないのですが、自分の用意のため、午前中のセッションを聴くのを諦めました。

いくつか聴きたいセッションがあったのですが、録画で絶対聴くことにします。

自分のトーク

登壇は思い出したくないくらい苦い思い出となりました。以前別のイベントで話した時と同じでした。

自分の想定していたタイミングで聴いてくれた方の反応がない
↓
なんとかしようとなんとかしようと頭の中がぐちゃぐちゃになる
↓
トークに集中出来ず、話すことがぐちゃぐちゃになる
↓
いくつかミスが出だす
↓
もうこれ以上ミスしたくない、さっさと終わらせたいとなる
↓
早口になる
↓
余計反応がなくなる
↓
以下ループ

実際、メモにこのページでは○分くらいといくつか重要なところで書いてあるのですが、最初のポイント(3分)の時点で1分アヘッドしてました。パニック状態でした。最終的には7,8分アヘッドしてました。 終わった時オフィスアワーがなかったらトイレとかにかけこんで泣いてたと思います。50分枠をもらったのに、40分で終わってしまった。。。

別途内容に関しては記述します。

でも、オフィスアワーで質問を頂けて、こんな無様な登壇をしたけど、しっかり聴いてくれていて、本当に感謝でした。ありがとうございました。

ちなみにオフィスアワーで隣の席に日高さんがいたので、同じ時間帯ではなした記念でチェキしてもらいました。

f:id:shiraji:20180208140607j:plain:w300 f:id:shiraji:20180208140611j:plain:w300

初日午後

結構登壇が心に来ていて、疲れもあり、ほぼほぼ覚えてないです。録画を見直すつもりです。

2/8 16:50~

最後のセッションの頃には落ち着いていましたので、フィードバックコメントします。

マルチモジュールのすヽめ

kgmyshin さんのセッション。droidconSFでマルチモジュール今後来るな!と感じていて、日本語でも聴いてみたく聴講しました。

内容としてはマルチモジュールのメリット・デメリット、実現方法、実際のアプリでの適応方法などなど非常に充実していました。 モジュールの切り方のオススメが機能ごとに切るで、自分もマルチモジュールやるならこれだと思っていたので、すごく参考になりました。 Kotlinのinternalの使い方とか最高じゃないですかこれ!という印象でした。 あと、セッションにはなかったですが、Javaのプロジェクトを部分的にKotlinにしていくというのにも活用できるのでは?とも思いました。 マルチモジュール日本でも流行るなこれ!という感じでした。本当に良かったです。

パーティ

風船がつけられる情報があったので、なんか恥ずかしいし、逃げられないかなーと思ったけど、会場に入るところで一瞬で捕捉され、つけられてしまいました。スタッフさんすごい。でもこれのおかげで色んな人に声かけられたので、天邪鬼なこと考えないほうが良いですね。

去年目の前で寿司が打ち切られたこともあり、最初から寿司狙いにいきました。うまかったです。色んな人と話してから、2皿目狙ったのですが、さすがに考えが甘かったです。さっさと行けば良かったです。サビ抜き注文にも対応してくれていたみたいなので、ワサビそこまで得意ではなかったしワガママ言えば良かったです。次回はそうします。

パーティでは、セッションを聴いてくれた人たちや自分のことを知っている人たちといっぱい話せました。Kontributeに関して質問がきたのですが、自分の言語能力が低くてうまく説明が出来ず、走ってMacをかばんから引っ張りだして説明させてもらいました。楽しかったー。

他にも去年のDroidKaigiからお会いしていなかった人たちにも会えたし、本当に楽しかったです。

二日目のセッション

スケジュールをガチガチに決めていなかったので、ふらふらーと気になるセッションに参加していきました。

2/9 10:30~

Moving Forward with JUnit 5

PermissionsDispatcherでコミッターとして仲良くさせてもらっているmarcelschnelleさんのトーク

始まる前に挨拶をさせてもらいました。

内容はJUnit5のプロジェクト構成からJUnit4との違い、そしてAndroidプロジェクトへの適応(UnitテストとInstrumentテスト)でした。JUnit5はまだまだ後で良いかなーとあんまり詳細を勉強しておらずふわっとした知識しかありませんでした。この発表を聞いてJUnit5のPlatform/Jupiter/Vintageの違いやその相互の関わり方などが明確になりました。

一番衝撃だったのがJUnit5はフルスクラッチで書いているそうなのですが、その理由のうちの一つのCoupling。JUnit4のプロパティ名を変更しただけでJUnit4が使い物にならない状況だったらしい。面白すぎる。もっとお話聞きたかったです。30分が一瞬で終わってしまいました。楽しかった。Thanks, Marcel!

2/9 11:20~

企業ブースにいて、セッション聞いてないです。聴講予定していたセッションがあったのですが、色んな人と話していて、いつの間にか開始時間を結構過ぎていました。参加者と話すの楽しいです。

2/9 12:50~

アプリを成長させるためのログ取りとログ解析に必要なこと

cattaka_netさんのセッション。 ログって本当に良い思い出が無くて、住友さんが関わっているアプリではどういう対処をしているのか知りたかったため聴講しました。 簡単にまとめるとログからユーザ全てのアクションが引っ張れるくらいにはしなさいという内容でした。 また、それを成すために全てのアクションなどにもログを出すようにしていました。正直衝撃的でした。 何かうまく無駄を減らしているのかな?と実は考えていたのですが、しっかりと丁寧に積み重ねているようで、何をするにもコツコツが重要だよね。と改めて教えてもらいました。

2/9 14:00~

ここの時間帯も聴きたいセッションが多かったのですが、Twitterで流れてきたAndroid Things codelabがどうしてもやりたくて、参加しました。 でも14:50~のGraphQLは絶対聞かないとまずいという認識だったので、途中で抜けるかーという軽い考えで参加しました。 が、実際はいつから参加しても良いし、特に座学がある訳でもないし、脇道それなければ、20分くらいで終わる簡単な内容でした。 でも、周りにGooglerがいっぱいいるのに、そんな即終わらせてももったいないことしたくないと、脇道に逸れまくって色々質問しまくりました。 結構無茶な質問してたのですが、真摯に対応してもらいました。終わった後に

これもらいました。Raspberry Pi 3持っていないので、どれ買おうかなーと画策してます。

2/9 14:50~

すばらしきGraphQLのSEKAIへようこそ

gfxさんのトーク。 GraphQLはあんまり前提知識がなく、どうやって書くのかなー?と疑問でした。 聴講している人たちもほぼみんなGraphQLを本番投入している人がいなかったようです。

内容としてはGraphQLのしっかりとした説明で、編集エディタとしてGraphiQLの説明があり、そのデモ映像で、おおおお!と思わず声が出ました。

聴講前はIntellijプラグインとかでもあるのかなー?と思ってたのですが、まさにこれ!というものだったので良かったです。 ちょうど次のタスクでサーバサイドのAPIとか作る予定なので、GraphQLまじでありだな。という印象です。 (残念ながら、クライアントサイド担当じゃないので、gfxさんのRejectKaigiでの発表の方利用します)

2/9 15:40~

gRPCとProtocol Buffersで作る、一味違う通信周り

RPCは以前から使っていて、(RESTにしようかー?って話があったのですが、なぜかずっとRPC+JSONだった)gRPCに興味があった。 Protocol Bufferは以前から把握していたので、その連携方法などなどを知りたく聴講しました。

RESTの向いているケース、RPCの向いているケースなどを実際に使われているサービスなどを踏まえて説明して頂きました。 あんまりAPIフルスクラッチから作る経験がなく、こういう比較で実は検討していなかったので、詳細を知ることが出来てよかったです。 結構新しい視点でAPI設計を考えられるようになりました。 また、RPC使っているものはアクションを中心に考えられていたので、案外筋が悪いものでもなかったなーと振り返ることが出来ました。

Protocol Bufferとの組み合わせの具体的な実装の説明があり、自分がまさに知りたい点の説明があったので、大満足でした。 一点しまったなーと思ったのが、GraphQLの話の後だったので、悩むネタが増える〜!(歓喜)という点でした。

2/9 16:50~

ARrrrg! The Google AR Android Demo Application deciphered.

ARCoreは今後関わる分野だなーと思ったので、聴講。 この辺りで結構体力が限界で、PCの電池も限界がきていて、後ろの方で聞いていました。 これが失敗で、コードの説明を丁寧にしてくれていたのですが、コードが読めない! Room6は縦長だったので、出来たら後ろの人にもスライドが見れるようにしてくれたら良かったなーと。

内容はスライドが読めなかったのでなんとも判断できませんでした。また録画で確認したいです。

2/9 17:40~

コードで見るFlutterアプリの実装 (セッションの説明ではQ社になってましたが、大丈夫なのだろうか?)

大ファンのkonifarさんのセッション。 Flutterのことはkonifarさんのつぶやきで知っていて、以前からちょこっと触ってました。iOSアプリがリリースされ、実際に触ってみて衝撃を受けたので、聴講しました。

自分で結構独自でWidget作ってへー動くねー程度だったので、ここまで手厚いGoogleからのサポートがあるのは激アツでは?という印象を受けました。 iOSアプリがあれほどしっかり作れるなら今後日本でKotlin Nativeより流行る可能性ありそうという印象でした。 このトークは初心者向けということもあり、Flutterとりあえず触ってみるかーという方はこのスライド読むだけでとりあえず形には出来そうでした。

あと、トークの最初のほうでがっつり聞いている人の心を掴んでいて、スピーカーとしても勉強させてもらいました。

2/9 18:30~

Gradleプラグインを作って開発効率を改善しよう

GradleプラグインOSSでのコントリビュートや実際にリリースまでしたことあったんですが、正直本当にこの開発手法で良いのか?とはっきり知りたかったので、DeployGateでGradleプラグインの開発知見が多いだろうtnjさんに色々聞いてみようと聴講しました。特に知りたかったのがdebugger周りでした。 最初いきなり、リリースしたのになんでいるの?と言われてしまい、あー間違ったかー?って思いました。実際、最初のほうGradleプラグインの初歩的な作り方で、あーあーって感じでした。

それで急にtnjさんがこれ""要らないですね。PRお待ちしております!とおっしゃって、

うし!せっかくだしやるかー!ってtnjさんのgithubのアカウント見つけて、repository一覧からたぶんこれだなーっていうrepositoryを見つけ、実際にコード検索してみたら、該当のコードがあったので、fork->clone->branch作成->commit->PR!とやりました。(しっかりと聴いてました)

ちなみに前回のDroidKaigiに引き続き、Kaigi中にPR投げる実績をこれにより解除しました。

で、PR投げるくらいのタイミングでデバッグとかどうしているの?という話になって、自分がどうしても知りたかったdebuggerの使い方を説明がありました。 デバッガの準備2/3のスライドのRemoteのConfigurationを毎回していないのが原因だったようです。 この情報もらえただけでこのトーク聞けたことに大満足です。今までログ吐いて確認ログ吐いて確認と非常に大変だったのでGradleプラグイン開発極力避けてきましたが、おかげで捗りそうです。 また、そこからはGradle Plugin Portal公開までのステップを一歩一歩説明されており、最近リリースするまでやれてなかったので、最新の動向が知ることが出来ました。

その他

セッションと関係ないけど、印象的なイベントリストアップしておきます。

運営の良さ

去年これ呟いていたんですが

しっかり対応されていました。しかも前回ガムテープだったのが、今回はプラスチックカバーになっており、電源タップにも優しい。

あとKotlinConfで良かった点をつぶやいていました。

やってくれたらなーと思ってましたが、全部揃ってました。ただ、自分が登壇したRoom6ではディスプレイがうまく表示されないという問題がありました。 Keynoteにはプレゼンテーションモードにすると動画が同期されず、スクリーンで何が起こっているのかわからない問題があります。 これの対応のため、ディスプレイが欲しかったので、なんとかなりませんか?と無茶なお願いをしたら、別の器具を特別につけてもらいました。 本当に神運営でした。ありがとうございました。(対応してくれた人の名前を聞くの忘れていました。。。)

登壇内容をまとめてもらった

初めて一枚にまとめてもらいました。嬉しかった。

でもこれを見て、Intentionの部分の説明詳細すぎて響かなかったのが良くわかりました。Androidに詳しい人達なので、Android StudioのIntention作り方とかにすれば・・・(あれ?それCfP通らなかったヤツ・・・)

Roman Guyさんと話せた

憧れな人と話せた。

プレパーティーで話しかけようと思ったんだけど、すごい囲まれていて、無理で、アフターパーティーは見つけられず、諦めかけていました。 でもDroidKaigi終わり際にソファーでのんびりされているところを見つけたので、他の人との話に割りいり、強引に話しかけさせてもらいました。 KotlinConfで登壇したこと、Kotlinのデータサイエンスへの展望、kotlin-mathの将来について話しました。 せっかくだから今の話、issue上げてよ。と言われたので、時間作ってあげてみたいです。

Kontributorsと会えた

色んなKontributorsと会えました。 すごい前から会ってみたいなーと思っていたtommykwさんにもようやく会えました。(KotlinConfにも参加してたのにお会い出来なかった。。。) 自分のトークに関しても直接色々感想を教えてくれました。嬉しかった。 KontributorsでCode Labとかやります?という話が出来ました。15人くらい集めて一気にみんなでKontributeとかしたい。Kotlin Developers Conference Japanでチャンスあればぜひ!