Continuity is The Father of Success

Androidアプリとかゲームとか。毎日続けてるものについて。

Kotlin愛好会 vol.15に参加してきました

9月後半の話ですが、またまたKotlin愛好会に参加 + 談義してきました。

love-kotlin.connpass.com

愛好会の様子

今回の会場はビズリーチさんでした。 すごいオシャレ空間……!

f:id:D_R_1009:20191002232152j:plain

談義

最近作った、Kotlin Coroutinesの動作確認をするデモプロジェクトを紹介しました。

github.com

経緯なんかは、作成時に簡単にまとめてあります。

blog.dr1009.com

作成して1月半ほど経ちますが、業務のチームでは一通り共有し、レビュー時に混乱することが減ったように思います。 やはり手元で動かしながらコードを見た方が、動作のイメージが浮かびやすいのでいいのでは、といった感じです。

聴講していた談義

たるさんの「Github Actions (v2) でDanger + ktlintを実行させる」が面白い + とてもためになりました。

qiita.com

実際、翌日に業務で扱っているSDKのCIをGithub Actionsに移行してみています。 OSSならGithub ActionsでササっとDangerやテストを回してしまうのはアリ。

終わりに

専門学校におけるプログラミング教育について談義があるなど、いつも以上に気づきがある会でした。 また、時間があれば参加していきたいなと思いっています。

Kotlin Fest Reject Conference 2019 [非公式]でLTしてきました

だいぶ遅くなってしまった。。。

いつもの感じでLTしてきました。 台風の日だったので参加できるかちょっと不安でしたが、なんとかなったのでよかった!

dena.connpass.com

参加の経緯

Kotlin Fest 2019の懇親会にて、Kotlin Fest Reject Conf 2019の紹介があったので参加を決めました。 Kotlin Fest 2019には一つ出してダメだったネタがあったので、ちょうど良いやと思っていたので軽い感じで参加。

その後はちょこちょこ資料を作りながら当日に備えていたのですが、会の当日がまさかの台風15号の直撃後になってしまいました。 会は開かれるのか、というか自分はそもそも会場に迎えるのか……などと考えながらリモートワークをしていたのを覚えています。

17時半ごろから電車移動を開始したところ、案外問題なく会場までたどり着けたのでよかったです。

会の雰囲気

Reject Confということで、肩の力が抜けたLTが多く気軽にしかし深い内容を聞けたように思います。 個人的に面白いなーと思ったのは、タケハタさんの「サーバサイドKotlinでgRPCをやってみよう」。

speakerdeck.com

LT内でも触れられていますが、Kotlin Fest 2019でいくつかあった”サーバーサイドKotlin + GraphQL”に対する”サーバーサイドKotlin + gRPC”! 普段はAndroidアプリを作成しているのでこれらの技術選定に関わることはないのですが、もしgRPCを使うことになったらアプリは何がよくなるのかなーと考えながら聞いてました。

paniniさんがgRPCのKotlin codeを生成するライブラリを書いているので、導入すればアプリサイドはフルKotlinで実装できる気も👀

github.com

LT内容

業務アプリを色々とKotlinに書き換え、途中で詰まったところについて話しました。 ささっと進めばいいかと思ったけれど、5分では詰め込みすぎたかもと反省。

speakerdeck.com

スライドでは足りなかった箇所を補足します。

2つのインスタンス化メソッドとNonNull

例えば、下記のようなクラスがあったとします。

ケース1

public class HogeFragment extends Fragment {

    public static HogeFragment newInstance(Fuga fuga) {}

    public static HogeFragment newInstance(Fuga fuga, Piyo piyo) {}

}

この時、

ケース2

public class HogeFragment extends Fragment {

    public static HogeFragment newInstance(@NonNull Fuga fuga) {}

    public static HogeFragment newInstance(Fuga fuga, Piyo piyo) {}

}

ケース3

public class HogeFragment extends Fragment {

    public static HogeFragment newInstance(@Nullable Fuga fuga) {}

    public static HogeFragment newInstance(@NonNull Fuga fuga, @NonNull Piyo piyo) {}

}

であることがあります。 (ありました)

ケース1では piyo は引数から明らかに nullable です。 ですが fuga はどうでしょうか? アノテーションがついていないJavaクラスからのコンバートでは、処理を一通り追わないと non-null とすることはできません。

ケース2が一番辛いケースとなります。 サンプルコードでは引数が2つなので違和感に気付きやすいのですが、実際のコードでは引数が3~4あることがあるためです。 この場合、かなり網羅的なテストを行わないとミスに気づくことが難しくなってしまいます。

対応は、複数のインスタンス化メソッドを持つクラスにおいては、インスタンス化時に引数とした値の利用箇所を全て確認する方針とするしかありません。

共通データクラス(神データクラス)

特にJSONのパース処理がつらいので、seald classを使ってちゃんとパースしたいクラスの形にしましょう、という話。 Swaggerなどが整備されているならば、Swaggerの通りにnon-nullとnullableを表現したデータクラスを0ベースで作った方が、早いかもしれません。

使い回されるデータクラス

「便利だから」との理由で似たインタフェースを持つAPIへのリクエストや、外部SDKからのコールバックをラップしたクラスが生成されていることがあります。 このため、複数のクラスから(特に理由もなく)利用されているクラスはnullの扱いを慎重にする必要があります。 とりわけSDKからのコールバックをラップしている場合、特定のSDKを利用した時のみクラッシュするといった、検証しにくい不具合を引き当てることがあります。

onActivityResult

Activityクラスの onActivityResult には @NonNull@Nullable アノテーションがついていません。 このため、Convert to KotlinするとNonNullの引数として定義されてしまいます。 (また、親クラスにアノテーションがついていないためAndroidStudioのlint機能で対応することもできません。)

Cross Reference: /frameworks/base/core/java/android/app/Activity.java

リネーム機能を利用してあらかじめアノテーションを付与したり、コンバート後にリネームする対応が必要となります。 特に、第3引数の Intent がnullとなってクラッシュするケースが多いように思います。

R8

OkHttp4系やKotlin Coroutines 1.3系のために、R8対応しましょう。 Gsonからの移行がつらいです。

終わりに

息の長いプロジェクトからの知見のため、あんまり響く人はいないかもなーと思っています。 が、どなたかの助けになればいいかと思っています。おわり。

転職して1年がたった(3社目)

現職に転職して1年が経ちました。2018年9月1日〜2019年8月31日が1年目。2019年9月1日から2年目に突入です。

転職前のこと

2社目はAndroidアプリをJavaで書きつつ、新人さんのOJTなんかをしてました。

最後に所属していたチームは、Android Architecture ComponentsのStable版リリースとほぼ同時に入り、AACを導入して片っ端から設計を直していた覚えがあります。 当時Fat ActivityなMVCからMVVMへ書き換えた経験、またRxJavaオンリーの環境に LiveData を導入した経験、UXエンジニアと一緒に働けた経験が今の自分を形作っているなーと。

なお、転職時期のあれこれはこちら。

blog.dr1009.com

転職後のこと

やっていること

教育系のAndroidアプリ作ってます。 最近では3人チームのリーダーになり、開発以外にも計画だとかそいういうところもやるようになりました。

ユーザーさんの数が多いのでクラッシュに気を配りつつ、一方でレガシーなコードが多いので急ピッチで書き換えをしています。 とあるリリースで15%ほどコードを書き換えてリリースすることになった時には肝を冷やしました。。。

また、会社としてのアウトプットにも力を入れるようになりました。 開発に関連するところでは、Androidに関わるテーマで。

tech.studyplus.co.jp

tech.studyplus.co.jp

そのほかには、開発チームとしての取り組みについて。

tech.studyplus.co.jp

どういったことを伝えるといいんだろうか、などと考えながら書いています。 まだまだ書ける箇所はあるので、チームとしてアウトプットすることを推進できればなーとも考えています。

開発のペースについて

仕事の中で気につけていることの一つに、時間当たりの効率があります。 生産されたコードの質はなかなか測れないので、プロダクトに乗せることができた(≒masterブランチに追加できた)コードの量を自分の中でバロメータとしています。 そんなこんなで確認してみたところ、前職では「半年でGitの+と-が合わせて8万行( git log コマンド調べ)」でしたが、現職では「1年でGitの+と-が21万行(Github調べ)」になってました。 多分スピードアップ。

ざっくりとコードを書いて詳細を詰める塩梅が上手くなったとか、一つ一つのコミット粒度が揃ってきたとか。アプリの設計が上達したとか、単にKotlin使えるようになったとか色々とありそうです。 まだまだやりたいことがあるので、効率をどんどんあげていければなと思います。

f:id:D_R_1009:20190901012011p:plain
1年間の様子

Kotlinのこと

開発言語はKotlinになり、Kotlin + Kotlin Coroutinesを毎日勉強してます。 9割5部Kotlinなので、Javaを書かなきゃいけない時にすっかり戸惑うようになってしまいました。

Kotlinの学習を振り返ってみると、一通り使えるようになったのでちょっと深掘りしたくなっている感じが出てますね。

blog.dr1009.com

blog.dr1009.com

blog.dr1009.com

blog.dr1009.com

blog.dr1009.com

Kotlin Coroutinesにflowが加わったことで、RxJavaを置き換えられるシーンもさらに増えるように思います。 2年目はRxBusをいかにして置き換えるかが一つの挑戦になりそうです。考えていくぞ。

LTのこと

LTをする機会が増えました。 SpeakerDeckを見て数えたら、8つほど社外でやってたみたいです。 前職では社内向けに一つだった(1年半で1つだった)ので、めちゃくちゃに増えました。

speakerdeck.com

初めはなかなか上手くいかない時期が長かったのですが、ようやく準備を含めて慣れてきたかなーと思います。 会とか、前後のLTに合わせてもっと調整しながらやれるようになりたいなーと思っているこの頃。

公開リポジトリのこと

気づいたら色々と作ってました。

EmptyRecyclerView は業務で利用したくて作ったので、割と気に入っています。 簡単なものを利用しやすく整理するという意味で、ライブラリ化は効果があるなーというのが1年目の実感なので、引き続き取り組んでいければなと思っています。

終わりに

転職して一年で何してたっけなー、と思い返しながらつらつら書いてみました。 来年の同じ日に、楽しく1年を振り返られるよう、頑張っていきたいと思います。