DroidKaigi 2017 ～ 1日目
XamarinとAndroid Wearぐらいしか触ったことがなかったのですが、DroidKaigiに行ってきました。Androidというくくりなので、話題の幅が多岐にわたり、Androidのことも学べるし、開発全般についての知見も得られると思い、参加してます。
技術的に詳しくないことが多々あるので、きちんとしたレポートはできませんが、何か書いてみます。
まず、スライドのまとめ記事がありましたので、これを見ながら思い返してみます。
逆引き マテリアルデザイン（荒木 佑一氏）
マテリアルデザインの話です。
デザインのことは全く素人なのですが、デザインのことを考える入り口として、マテリアルデザインを学んでみたいと思いました。
以下の内容が気になりました。
- しっかりとしたガイドラインがある。 → 登壇した人みんなが読むことを勧めていたように思います。
- タッチフィードバックを入れましょう → 自分は一切入れていませんでした。今までずっと、もっさりしたソフトを生み出していました。
まずはガイドラインをしっかり読みたいと思います。 WindowsでもMetro UIのガイドラインはしっかりしたものがあるのか気になりました。
スライド 逆引き マテリアル デザイン
リリース自動化と効率の良いリリースフローを求めて（Ryo Sakaguchi氏）
Android特有の話はあまりわからなかったのですが、ためになりました。
- ミス防止、属人化防止、そして本質的な業務に注力。
- git push origin master したらリリース。というのが理想。
Git-Flowが基本となる。そしてCIの紹介。
週1リリースしたいです。
その前に年１リリースを実現したいです。
小さくて速いモバイル開発の知見を、レガシーソフトウェア開発でもうまく取り入れられたら良いと思います。
スライド リリース自動化の導入と効率の良いリリースフローを求めて // Speaker Deck
大規模アプリのリノベーション（北村 涼 氏）
ためになりました。
古いアプリをリノベーションしていくことの実際を知ることができました。
ドメイン知識の獲得
- 紙に印刷して画面を知る。あるべき名前に変えていく。
画面を洗い出して印刷することに共感しました。
調べてみると知らない画面がたくさん出てきますよね。
ほかにいい方法があれば知りたいところですが、こうするしかなさそうという感覚です。
設計
- ライブラリを上げまくる
- アーキテクチャ。守るのではなく、着くずし。
- 「設計が確認できる程度のサンプルアプリを作る。」
サンプルを作るのは、いいアイディアだと思いました。
設計が確認できる程度というのが大事なのだと思います。
その後MVVMのようなモデルを採用した話になりました。 ViewModelは階層を持つようにしたという点。なんとなくそうなのかなと思っていたのでスッキリしました。
「見積る」ことが大事とのことです。
１～２週間ごとにリリースして様子見するとのこと。
短い間隔でのリリース体制はある程度前提かもしれません。
スライド droidkaigi-2017-renovation // Speaker Deck
Android アプリ開発の体力づくり(@operandoOS 氏)
初心者向けセッション。とはいっても DroidKaigi ですから、超初心者はほとんどいませんでした。
作りたいものを小さく早く作っていくのが大事ということなのですが、私はできていない。
早く何か形にしたいと思いました。
Material Design おすすめされていました。読みます。
Instant Apps というものがあるらしい。
インストールしなくても動くアプリとのことで “すぎょい”
だがしかし、勝手に未知の機能が立ち上がる未来を想像して、完全にそうなったらちょっといやかなとも思った。
スライド https://speakerdeck.com/operando/androidapurikai-fa-falseti-li-dukuri
ReactNativeはクロスプラットフォームモバイルアプリ開発の夢を見るか（中川 幸哉氏: @Nkzn）
ReactとReactNativeの話。
Reactを覚えると、似たような感じでReactNativeが使える。
Reactをまず知っている必要があり、Reactの世界に足を踏み入れる必要があるものの、入ったら結構まとまっていて、効率の良い開発ができるのではないだろうか。
Xamarinとは相容れない？
でも、どちらも知っておきたいです。
「銀の弾丸はない」ということです。
クロスプラットフォーム界隈の人々は必ずそういいます。
