為さねば成らぬ

retia.verno@gmail.com

文字数カウンタを表示する

課題

社で自分の業績評価を記入する必要があるのだが、使用しているWebサービスがイケてなく、文字数制限があるにも関わらず現在入力の文字数を出してくれない。というか文字数が超えている場合は非同期的にダイアログを出してくるのでうざい。

適当な場所で文字数カウンタが欲しい。

解決

ちょくちょく使うGoogle Docsで文字数カウンタを表示する。

メニューバー > ツール > 文字数カウンタ f:id:verno3632:20201210230210p:plain

f:id:verno3632:20201210230214p:plain

入力中に文字数を表示を選択すると左下に表示される f:id:verno3632:20201210230223p:plain

Slackチャンネルの新着がどうしても気になるので整理する

課題

弊社では社内チャットにSlackを導入している。各所属チームのほか雑談用のチャンネルがあったり、また所属していないチームのチャンネルでも気軽に入れるので自ずと加入チャンネルが増えてしまった。

チャンネルにコメントが投稿されるとチャンネル名が太字になる。もちろん今見なくても良いチャンネルはあるのだが、太字になると全てキレイに消したくなるのが人の心。

必然的にもぐら叩きのようにSlackチャンネルを開くことになり、時間を浪費するハメになっていた。ゲーセンにあるもぐら叩き好きだし。

対策1

いつからかチャンネルをセクションに分類できるようになった。チャンネルをグルーピングして折りたたんだりできる。

ただしこの際 自分の所属雑談 といった、一般的な属性でグルーピングしたため、結局すべてのセクションを展開した状態での運用になり、もぐら叩きはあまり変わらなかった。

対策2

チャンネルによってアクセス頻度が異なっていることに最近気づいた。例えば今現在メインで動いているチームでは、相談が比較的飛んでくるし反応を早くしたほうがいいので、できるだけこまめに見ている。あるいは雑談ではあるがアイマスチャンネルは、流速が早く話題にも乗りたいので常に追っておきたい。

逆に社内全体向けのチャンネルは重要な情報が流れるがこちらから反応する必要はほぼない。また野球チャンネルはそんなに早くない。シーズンが終わった今だとなおさら。

ということでチャンネルの属性に関わらず、自分が見たい頻度に合わせてセクションを分けた。

f:id:verno3632:20201127230204p:plain

(実況系 は特定のMTGで実況スレとして使われるチャンネル群。)

合わせて、セクションを分けるときに整理を行い、覗いていないチャンネルから離脱する。

常時 セクションは基本的に常に展開して新着コメントに即座に来づけるようにする。

他のセクションについては、それぞれのタイミングで展開し、それ以外は折りたたんでおく。

目に入るのがこのくらいの数であれば、あまりもぐら叩きを自制できる・・・気がする。しばらくはこの運用で行く予定。

PullRequestがマージされたときなにかする(Slackにメンションする)

課題

Pull Requestがマージされたとき、AuthorにSlackでメンションしたい。

実装

各ステップを以下のように設定する。

  1. Trigger: Github Trigger Action: New Repo Event

  2. app: Filter by Zapier Payload Action Exactly matches closed Payload Pull Request Merged is true

  3. app: Slack

SHA証明書フィンガープリントを取り出す

課題

Firebaseに設定する、証明書フィンガープリントを取得したい。

実装

apkから取得する

keytool -list -printcert -jarfile target.apk

keystoreから取得する

 keytool -list -v -alias name -keystore keystore.jks

apkに署名する際に用いるalias / key store password / key password が必要なので注意。

ビルド中に生成されたファイルを後からみる

背景

Bitriseにて新たなWorkFlowを組んでいて上手く行かないことがある。 コンテナの中で動作しているビルドの中をデバッグすることは難しい。

課題

内部で生成されるものを後からArtifactsとして参照できるようにする

結論

対象のファイルを $BITRISE_DEPLOY_DIR ディレクトリに入れ、 Deploy to Bitrise.io - Apps, Logs, Artifacts ステップを使う。 BITRISE_DEPLOY_DIRは予め定義されている環境変数であり、また Deploy~ステップでartifactとして保存するディレクトリにデフォルトで設定されている。

GsonでtoJsonする時にフィールドをsnake caseにしたい

背景

Kotlinで書いてると通常クラス名やフィールド名はCamelCaseにする。

ネイティブのクラスをJavascriptに渡そうとする時にsnake_caseとして扱われることがある。

課題

JavascriptにわたすためにクラスをJsonの文字列に変換したいが、フィールド等がCamelCaseになってしまう。

結論

FieldNamingPolicy.LOWER_CASE_WITH_UNDERSCORES を用いる。

val gson = GsonBuilder()
            .setFieldNamingPolicy(FieldNamingPolicy.LOWER_CASE_WITH_UNDERSCORES)
            .create()
val jsonStr = gson.toJson(hogehoge)

PRに対してCache保存を有効にする

背景

AndroidアプリのビルドにBitriseを用いている。 Bitriseはビルドの一連の流れをWorkflowと呼び、それを構成するのがStepである。 このStepのうちCache Pushというものがあり、これは生成したファイルをBitriseのCacheに置くものである。 通常はステップの最初に対するCach Pullを実行してファイルを取得しビルドを行い、その結果の生成物に対してステップの最後でCach Pushを実行する。 Pushするキャッシュについてはファイルを指定することも出来るが、用意されているビルドは自動的にその指定を行ってくれる。 例えばAndroid Buildはapkを生成するが、そのapkのパスををキャッシュに置くリストに自動で設定してくれる。

課題

Cache Pullに対してはPull Requestをトリガーとしてビルドされるときskipされてしまう

調査

discuss.bitrise.io

Workflow Editor (UI上でグラフィカルにworkflowを編集できる) では利用できないが、bitrise.yml (Workflow Editorで作ったかどうかに関わらず、存在するWorkflowをyml形式でweb上で編集できる) にて設定が可能。

    - cache-push:
        run_if: ".IsCI"

ほぼすべてのステップで run_if が使える。これは名前の通り特定の条件下でのみそのステップを走らせるもので、Workflow Editorの設定では前のステップでビルドがこけたら実行しない、ということが設定できる。 デフォルトでは run_if: ".IsCI | and (not .IsPR)" つまりPullRequestでは走らないようになっているのでそれを削除することで走らせることが出来る。

雑感

そもそもやりたいこととして、並列ビルドによるビルド高速化だった。 ただAndroidのビルドだとgradleはキャッシュを有効に活用することで高速化を行っており、並列ビルドをするとこのキャッシュの恩恵が得づらい状態になってしまう。 予めある程度ビルドをしておき、そのキャッシュを使って並列ビルドを実行することを考えていた。 まだうまくいってない・・・