DroidKaigi 2018でGradleプラグインを作って開発効率を改善しようって発表をした話

Android開発者向けカンファレンスDroidKaigiも今回2018で4回目を迎え、1,000人近くの参加者、80以上のセッションを擁する大きなイベントとなった。

今年も去年に引き続き、登壇者として採択いただくことができた。今回は、昨年の「Android Bikeを作ろう」(Android端末のセンサーとBluetooth LEデバイスを使ってサイクルコンピューターを作ってみようという話)から一転、今年は普段アプリのビルドに使っているGradleのプラグインの作り方を解説するセッションをやらせていただいた。

登壇することになった流れから、資料作成のあれこれ、実際発表してみた感想までを軽く振り返ってみたいと思う。

内容

Androidのビルドで必ずお世話になるbuild.gradle. いろんな設定が書けて便利ですよね。だけど、あちらこちらのプロジェクトで同じような設定をコピペしてない？それ、共通化したいよね。プラグインを作ってしまえば世界で共有できちゃうよ！

プラグインと聞くとなんとなく敷居が高く感じるけど、実はめちゃくちゃ簡単に開発を始められるし、公開もすぐにできる。今回は開発の始め方、デバッグ、パッケージング、公開までの手順を一通り解説するよ！

というお話を詰め込んだ30分セッション。

経緯

前回と同じく「登壇者募集が始まったので、せめてもの賑やかしに」とネタを捻り出した感じ。

仕事上、他のプロジェクトのbuild.gradleファイルを見てアドバイスしたりする機会があって、そこで得た感触として「よく分からないけど貼り付けたら動く」便利スニペットのコピペだらけになってしまっていることが多いなと感じていた。

build.gradleはある程度入り組んだ設定をしようとすると、結構複雑な設定を書くことになるけど、本来ロジックは設定ファイルの外に置くべきだし、それは共有化されて再利用しやすくなっているべき…まあ、そんなことはみんな分かっているはずなんだけど、現実そうなっていない。じゃあそのハードルを下げるような話をしてみたらどうだろう？という感じのことを漠然と考えていた。

裏目的として、会社で「Gradleプラグイン開発するぞ」って人に「これ見て」で開発始めてもらえるような資料を作っておきたかったというのがあったりなかったり。

進行

だいたい去年と同じような進行で、30分発表のアウトラインを作って、アウトラインを実際に話してみて分量を調整して、最後に一気にスライドを作るという流れ。

内容は2017年末までに決めていたけど、資料のアウトライン作りに入れたのは実質1月下旬から。その頃、ニューヨークに行く予定がありその前までになんとか目処をつけようと必死になっていた模様。

なんとなくサンプルプロジェクトを作らないといけない感触は持っていたので、コード書いたり調査する時間も確保しないとな…という心の焦りがすこしあった。

しかし肝心のGradleが動かないという謎の地雷を踏んでしまってこれはマズいという気持ちに。

結局、アウトラインもそこそこに旅発ってしまい、日本に戻ってくるまでの1週間ちょっと資料の進捗はゼロ😇引き続き焦りのツイートをどうぞ。

書いてる最中は30分にはまだ内容が足りない…これ書き終わるのか…って気持ちなのに、だいたい大幅にオーバーランする不思議。ともあれ、実際に資料を作る前にアウトラインの段階で最初から最後まで通して話すのは本当にオススメ。

で、重複を減らしたり、細かすぎる話をちょっと削って調整した上でスライド作成に移る。

スライド作成の効率化

去年はKeynoteで頑張って作ったんだけど、今年はMarkdownで書いたアウトラインを、可能な限りそのままスライドに変換したい！という気持ちが強くあった。

各種ソリューションを試した所、Marp とDecksetが非常に良かったのでオススメしたい。どちらもMarkdownを流し込めばスライドが完成する素晴らしいソフトウェア。

Marp

Marpはオープンソースで、Windows/Mac/Linuxに対応したElectron製のWYSIWYGなエディタによって、編集が即画面に反映されるので圧倒的な作業効率。最終的にPDFに出力できる。今回はこれでほぼすべてのスライドの作成を行った。

Deckset

対するDecksetはMac専用の有料ソフト。テーマが充実しているのと、画面全体に大きく文字を表示したり、複数の画像をきれいに配置したりできるなど、Markdownの独自拡張があってレイアウトの自由度が高い。

さらに、Keynoteなどと同じように発表時にプレゼンター用画面が出せてノートの表示もできるなど、よりプレゼンに特化した機能が提供されている。

ただ、エディタは各自好きなモノを使ってくれよな！という感じなので、編集中の快適さはMarpが格段上な感じ。一応、ファイルが保存されたタイミングで修正箇所を自動的に画面に反映するので、お好みのエディタ＋Decksetでもそこそこ作業はできる。

今回は最後の調整と実際の発表はDecksetで行った。スライドはこちら。

副産物

今回は実際のプラグインの例を考えるのがすこし大変で、簡単なものと、少し複座なもの、かつ、どちらも実践的なやつが必要だった。結果的に、新しいGradleプラグインを2つ作って公開できることになった。

auto-debug-suffix は、アプリのDebugビルドのapplicationIdとversionNameに、自動でdebugのサフィックスがつくようにするプラグイン。Releaseビルドとの住み分けができるようにする。

locate-apkは、アプリのビルド完了時に出力先のファイル名を表示するようにするプラグイン。出力先をFinderで開いたり、ビルドが完了したときに開くようにするタスクもある。

ぜひ使ってみてね！

反応

まず、冒頭の豆知識として「.gradleファイルはリモートに置いて直接 apply from: できるよ、なのでAPIキーとかそういう類の共通化ぐらいであれば、gistでも社内サーバでも置いてしまえば完了ですよ」という便利系の話。

あとでハッシュタグを追ってみたら、実際モンスターラボさんではそういう形で運用されている（た？）模様。

そこから、発表前半10分でプラグインを1つ完成させてしまうのだけど、「それぐらい簡単にできるよ」ということも伝わったようでよかった。

一番反応が大きかったのは、build.gradleにもデバッガがアタッチできるよという話。

GradleもJava VM上で動くアプリケーションなので、普通にAndroid Studioの持ってるJavaのDebuggerがアタッチできる。理屈はそうなんだけど、設定方法がいまいちまとまってないので、改めてまとめて紹介した感じ。

感想

概ね、やってよかった。Twitterでの反応を見る限り、それなりに役に立つ知識を共有できたと思う。タイムテーブル的には最終日の最後だし、もう帰っている人も少なくないかなー？と思ったけど、蓋を開けたらたくさん来ていただいていて嬉しかった。

自分は、発表が始まる直前になると勝手に緊張して、指先が冷たくなって震えだしたり、話し言葉も噛みがちになってくるのだけど、これはもう無意識の反応なので仕方がないと思っていて、せめてもの気晴らしに登壇前からちょっと雑談を始めたり、小ネタを挟んだりして場を暖めたりしていた。途中で賑やかしにやってきたmhidakaさんの「最後締めお願いしますね（ニッコリ）」という突然の無茶ぶりに「はー 😨さらっと無茶ぶりしてくよね、あれが主宰ですよ」と煽って返してみたりとか。

そこで「あ、この人のセッションは笑ったりして大丈夫な空気なんだ」と思ってもらえたら、聞いている側も反応しやすくなる。それが功を奏してか、発表中「こんな機能ほしくないですか？」と言ったら「ほしいー」と反応してもらえたりしたのはとてもよかったと思う。

同様な話はkonifarさんが書いていて、まさしくそうだよね、と思った。

それから、今年も「スタッフ兼登壇者」だったのだけど、枠が最後の最後になるとイベントを通して気持ちが落ち着かなくてしんどい、というのが正直あった。発表直前は時間を空ける配慮はしてもらってるけど、そこまでに既に結構体力を消耗しているので、そこから落ち着いて発表者に切り替わるのはなかなかの難易度。ただ、この辺はタイムテーブルを決めるときの変数の多さに起因していて、綺麗な正解がないので正直難しいところ。シンプルにどっちか一方を取るという戦略がいいのかもしれない。

ともあれ、何かを発表する機会が得られることもとてもいいことなので、引き続き頑張っていきたい。なおこの後、撮影スタッフとしての話、オープニング映像の話、会場BGMの話、その他細々を書いていきたいと思う。