2020-03-15

秘伝のタレを受け取ったときにまずやること

秘伝のタレとは

年単位で職人によって継ぎ足され、熟成されたソースである
衛生環境が良い秘伝のタレは素晴らしい味だが、常に良い衛生環境の中で育つわけではない

深呼吸する

何事も、一歩ずつ解決しなければならない

コードフォーマッタを適用する

最初にやる
フォーマッタが適用されてないことは多い
これを最初にやらないと、Intellij等の自動フォーマッタが意図しないタイミングで走ったときにマージ地獄に陥る
- 手癖でFormatコマンドを実行する人は要注意だ
- 普通はそんな注意しなくていいんだけど

sdkVersionを更新する

様々な事情により（大抵はAndroid OSの破壊的変更の影響を回避するため）、compileSdkVersionが古い場合がある
しかしGoogle Playは無慈悲で、新しいバージョンでcompileしないとアップロードすら行えない場合がある
更新してあげよう

dependenciesを更新する

様々な（ｒｙ
年単位で古いライブラリもザラにあるし、Google Play ServiceのSDKはGoogle側の事情でdeprecatedになったりする
素直に新しいバージョンに更新しよう
アパッチ族のハイパーテキスト魔術をよく見かける

JavaをKotlinに変換する

我慢しよう
一気にやるとどこかでミスる上に差分管理が断絶するので、ここは慎重に行おう
開発範囲内で、ちょっとずつやれるところからやっていく
戒めである

CIを組む

やれたらやったほうが良い
ソースコードは引き継いてでも、CIは引き継げないことも多い（例えば元がオンプレJenkinsとか、無理でしょ）

覚悟を決めて、 `abortOnError false` を外す

abortOnError false のコードは、すべてレガシーコードである
lint解決に時間をかけなかった、かける価値を感じなかった、やり方を知らなかった、そういった積み重ねの産物である
これの有無を見るだけで、秘伝のタレの深みがわかるであろう
覚悟です。覚悟ですよ、ナナチ

2020-03-09

Android Studio 3.6.1で稀にReleaseビルドが失敗するのを回避する

失敗時のログ

Execution failed for task ':app:minifyReleaseWithR8'.
> Multiple entries with same key: Method $$ServiceLoaderMethods.$load0 Proto L java.util.Iterator =Encoded method Method $$ServiceLoaderMethods.$load0 Proto L java.util.Iterator  and Method $$ServiceLoaderMethods.$load0 Proto L java.util.Iterator =Encoded method Method $$ServiceLoaderMethods.$load0 Proto L java.util.Iterator

おそらくの理由

何度か実行してみた結果、 --parallel オプションを付けて minifyを有効化する と４〜５回に１回位の割合でビルドに失敗する。 --parallel オプションを消せば再現しなくんった（多分）

CIのリリースビルドの時しか影響がないので、素直に --parallel を外してビルドする。

Issue Tracker

https://issuetracker.google.com/issues/148929520

ワークアラウンドが載っているが、R8バージョンをデフォルトから変更するので選択は慎重に。

2020-03-03

branchを切ったらすぐにpushしてCIだけは通しておこう

技術系全般

前提

masterやdevelpoブランチでビルドが通っている
その状態で作業branchを作成する
branchを作ったら、何も更新してなくてもすぐにpushしてCIは通しておく

理由

CIが壊れるのは自分の更新だけが理由ではない
CI設定の間違い
サーバーが更新されて動作しなくなった
ライブラリのバージョンがいつの間にか変わっていた
- dependenciesのバージョン名に + とかつけるのはやめよう
キャッシュ有無で正常にCIが通らなくなった
mavenリポジトリが死んでしまった
- bintray、おまえよく死ぬな

自分の作業によってCIが壊れたか 環境によって壊れたか の違いをちゃんと切り分けてから作業しないと、無駄な確認作業が発生するぞ

2020-02-22

Kotlinでinterface定義モジュールと実装モジュールを分離した上で実装を隠蔽する

Android

やりたいこと

interface定義と、その実装をなるべくキレイに切り分けたい

インターフェース定義用モジュール

// ":interface-module" に定義を書いていく...
interface AuthService {
  fun login(id: String, password: String)
}

実装用モジュール

// ":impl-module" に実装を書いていく...
internal class AuthServiceImpl {
   override fun login(id: String, password: String) {
       // ログイン処理する....
   }
}

コレの問題点

AuthServiceImplがinternalなので、他のモジュールから見えない
けれどAuthServiceImplをモジュールの外に開放したくない（後で入替えたりとかやりやすいように）

解決

interface側にcompanion objectを入れておく

interface定義を修正

// companionだけ書いておく
interface AuthService {
  fun login(id: String, password: String)

  companion object
}

実装用モジュールにExtensionも定義

// ":impl-module" に実装を書いていく...
internal class AuthServiceImpl {
   override fun login(id: String, password: String) {
       // ログイン処理する....
   }
}

// CompanionのExtensionとしてインスタンス生成メソッドを生やす
// これはinternalにしない。
// 利用側からは `AuthService.newInstance()` と呼ぶことができる
fun AuthService.Companion.newInstance() {
    return AuthServiceImpl()
}

これでinternal classを開放せずにインスタンスを作れる

2020-02-18

Androidアプリビルドの並列最大化の限界値

この記事ではコマンドラインによるフルビルドのみを対象にする
gradleのソースコードと挙動観察での現時点での推測

ビルド速度に影響する要素

CPU論理コア数
シングルコアスペック
メモリ
プロジェクト自体の並列性

gradleのworker設定

gradleには --max-workers 設定がある
このオプションを闇雲に指定しても意味はない
デフォルト値はCPU論理プロセッサー数

    public DefaultParallelismConfiguration() {
        maxWorkerCount = Runtime.getRuntime().availableProcessors();
    }

Workerが増える条件

並列可能なタスクが発生すると、Workerが増える
Workerは予約されない。なので、 --max-workersオプションをいくら設定しても、不必要なworkerは起動しない
mavenのライブラリ取得とか、並列実行しやすいタスクが発生すると一気に増えるのが観測できる
- ローカルキャッシュを全消しして、--max-workersをやたら増やすと壮観な図を観れる

   // DefaultBuildOperationQueue
    @Override
    public void add(final T operation) {
        lock.lock();
        try {
            if (queueState == QueueState.Done) {
                throw new IllegalStateException("BuildOperationQueue cannot be reused once it has completed.");
            }
            if (queueState == QueueState.Cancelled) {
                return;
            }
            workQueue.add(operation);
            pendingOperations++;
            workAvailable.signalAll();
            if (workerCount == 0 || workerCount < workerLeases.getMaxWorkerCount() - 1) {
                // `getMaxWorkerCount() - 1` because main thread executes work as well. See https://github.com/gradle/gradle/issues/3273
                // TODO This could be more efficient, so that we only start a worker when there are none idle _and_ there is a worker lease available
                executor.execute(new WorkerRunnable());
            }
        } finally {
            lock.unlock();
        }
    }

最終的に収束するWorker数

どんなに頑張っても、module同士の依存によって増えるworker数には限度がある
その状態ではCPUコア数よりもシングルスレッド性能のほうが重要となる

例

これらのビルド速度は最終的にほぼ同一に落ち着いた
- Ryzen 1950X(16C32T) + RAM64GB(Ubuntu 19.10)
- Mac mini 2018 Core i7(6C12T） RAM64GB, 6C12T

快適性

ビルド速度は同一だが、快適性とは別問題
- Windowsマシンはそもそもビルドが遅い
- Mac miniは騒音がある
- UbuntuはAdobe製品が使えない、など
次のマシンは何にするか

2020-02-06

Firestoreのローカルエミュレーターは同時にトランザクション接続しすぎるとフリーズする

GoogleAppEngine Google

問題点

表題のまま
100個くらいのUnitTestがgoroutineで２〜３のトランザクションを並列発行した
フリーズした

回避

UnitTest時のみ、トランザクションが集中する箇所でmutexによる排他制御を入れた
まあしゃあない

2020-02-05

FirestoreとMemorystoreとDatastoreと