OSS の公開と保守再開的な何か
最近いくつか OSS を公開したり、保守を再開しました。最近は Ruby 4割弱、BashScript 2割、Kotlin 2割、Golang 1割、YAML 1割、残りJava みたいな生き方をしています。
danger-apkstats
Assertion system である danger/danger の Android apk 解析用 plugin です。
現職のアプリの機能は非常にシンプルで、だからこそむやみに apk サイズを大きくすることは好まれません。
そういうわけで apk サイズの変化を計測したかったこと、また permission や feature についても同様に注意を払うために「2つのapkの差分をレポートする」機能を実装しました。
どうやって前の apk を用意するかについては今後どこかで LT をするような気がします。
dpg
DeployGate API clientのGolang CLIを公開しました。 CLI ですが、API クライアントとしても利用できるようなパッケージ構成になっています。 初 Golang OSS な上に実務 Golang-er と働いたこともないので、パッケージ構成やら何やら非常に Java っぽい。マサカリをください。
公開した背景
DeployGate ではメンバー管理を行うための API も公開されていますが、アプリ開発者の関心事は「デプロイ（アップロード）」に注視しがちで、あまり他の API について関心を払う人はそう多くないように見受けられます。本来開発版アプリの管理を考えるなら手動による管理や手放しの運用は決して褒められるものではなく、メンバーデータと API を用いた自動管理を前提としたいところです。
公式ドキュメントとして curl サンプルが存在するので API コール自体ができない人はそういないと思いつつも、エラーレスポンスのクオリティは逆立ちしても実用的とは言えず非常に難を強いてしまっているのではないかと思っています。1
そこで、ある程度のバリデーション層を用意し、かつそれらを強い静的型付けの中で行い、CI との親和性や保守性を考えた結果が Golang によるクライアントの実装でした。これの開発中にエラーメッセージが意味不明すぎて、サーバーのコードを読まないとトラブルシューティングできない不便さに本気でブチギレていたことは記憶に新しいです。
公式 dg コマンドとの違い
公式ではすでに dg コマンド、gem名称は deploygate として公開されたものがありますが、これはデプロイ周りのヘルパー CLI であって純粋な API クライアントではありません。2
GitHub - DeployGate/deploygate-cli: A command-line interface for DeployGate
非公式の理由
これは僕個人の感情が多いに影響しています。
公式として提供する場合、会社として精神的な面も含めてメンテナンスの運用体制を整える必要があります。Golang による実装、IssueやPRへの対応といった人的リソースに関してはもちろんのこと、会社として実装するということは「機能の取捨選択を会社目線で行う必要性」が出てきます。
現在すでに webサービス以外に dgate、gradle plugin、android sdk を抱えており、人的リソースについてはお世辞にも「人を割ける」とは言えません。
また dpg はただの API クライアントではなく、いくつかの API を組み合わせて実現する半・全自動化された手続き（現状は配布ページの自動作成・削除のみ）のサポートを視野に入れています。こういった応用について、会社からの例の提示ではなく機能として提供するケースでは多くの意思決定を挟む必要があります。特に破壊的変更によるサポート提供の停止について、公式資産がその意思決定に影響を及ぼすこともあるでしょう。
それが嫌だったという表現ではなく、「現状、それはお互いに不幸である」と思ったので非公式にしています。
remocon
remocon は Remote Config as a Code を目標とし、YAMLベースで Remote Config を管理するための Ruby Gem です。これの保守を行いました。
そもそもの開発モチベーション
前職では Remote Config をフル活用していたのですが、値に JSON を用いるも Web コンソールからはバリデーションが存在しない、PUBLISH CHANGES 押し忘れなどの問題が存在していました。これらの問題点を解決するため の、そして shibuya.apk の発表に間に合わせるため に開発を行いました。
保守
現職では Remote Config を使っていないことからメンテナンスを放置していたという怠惰な背景があります。
つまりgem 開発のモチベーションは前職に置いてきたのですが、 現職でも Remote Config を利用できるようしておこうかなと思ったことと、最近前職の先輩が CI 連携（未完成品だった）を修正しようとしている悲鳴（CI failure 通知や数十にも及ぶチャレンジコミットなど）が聞こえてきたこともあり、放置していたタスクを再開しようと思い直しました。3
APIの変更
ちょっと見ない間に API レスポンスの仕様が変わっていたり、validation のみを行う API コールが増えていたりと、色々と対応した結果、0.1 から現在は 0.4.1 まで上げました。
実装にあたり API ドキュメントに誤りがあったので、フィードバックを送っています。とはいえクリティカルな部分でもなんでもなかったですし、全体的にドキュメントが丁寧で最高でした。
新しいコマンドや機構の実装
Firebase Remote Config は短命の OAuth2 トークンを使って認証を行います。サンプルがあまり見当たらなかったことと発表に間に合わなかったので python で代替していたのですが、今回トークン発行のコマンドを Ruby で実装しておきました。YAML 管理を行わなくとも、remocon を使えばトークン発行、configの取得・更新を利用できるようになったという形です。
また以前は YAML にある定義をヒューリスティックに更新する機構がなかったため、web コンソールから変更を行ってしまったのち、それらの変更を YAML に反映させるためには手動で行う必要がありました。現在はこの問題点に対し、シンプルな差分を計算し、ある程度は YAML を自動更新できるようにしています。
Remocon Starter Kit
gem だけあっても使えないんだけどというクールな DM を貰ったので、一理あるなあと思って CircleCI 上でメンテナンスを開始するためのスターターキットも作成しました。
このリポジトリには CircleCI で remocon を使った Firebase Remote Config の管理を始めるにあたり、必要なジョブ（.circleci/config.yml）やスクリプトを埋め込んであります。
これのテストをセキュアにやるにはどうやればいいのか思いつかなかったので、今は手動でやっています。とてもつらいです。何かあったら Issue 立ててください。
今後保守するもの
Vector Drawable Previewer
VectorDrawable をプレビューする Chrome Extension です。
が、バグを放置したまま保守をしていませんでした。現職のアイコン類を全て VectorDrawable にする必要があるんですが確認がつらすぎるので、実は今一番必要に迫られています。
import-android-icons
public にしてるんですが公開の体裁を整えていません。また jar とシェル芸とnode という継ぎ接ぎなので、全部 jar にして提供し直そうと思います。
