Android Studio Arctic Foxでなんかフォントが変わったのか日本語が豆腐表示になってたので解決方法。 図の場所のチェックを入れるとシステムフォントを使うようになるので文字化けが解消される。
退職エントリ2021
様式美の写真がコロナ禍で撮れなかったのでMacで代用。お気持ちを残しておくためにも退職エントリを書いておく。
2018年8月にDeNAに入って2020年4月に事業承継でMobility Technologiesに転籍になりましたが、 2021年7月15日を最終勤務日にして1.5ヶ月ほど有給消化をした後に9月1日から新しいところで働きます。 結局コロナ禍で、オフィス移転してから1度も出社せずに退職です。
次の会社は入社後にオープンにしようかなと。次もAndroidエンジニアをやる予定です。(多分)
TL;DL
他人の退職エントリ、読んでも面白くないものもないので3行でのまとめ
- 最高の同僚だったけども、音楽性の違いで辞めるよ！
- 転職活動はリファラルで低コスト戦略が当たったよ！
- 引き継ぎをピンポイントでやるためにコミットログ分析するツール書いたよ！
所感
通算で3年ほどでしたが、DeNAではオートモーティブ領域や転籍だったり、最高な同僚にも恵まれ、色々と楽しい体験出来ていい会社でした。 仕事内容でもフルリモート下での市場不具合解析、ログ分析とか中々出来ない体験も出来て面白かったです。 入社時に考えてた自分の持っているスキルセットや経歴を活かせそうという思いは間違ってなかったかなと思います。
辞める理由は一言で言えば、音楽性の違いってやつです。
俺はヘビメタバンドやってるつもりだったけども、マネージャーはクラシックオーケストラを作ろうとしてた、みたいな感じです。 それぞれはそれぞれで良い事があると思うので、音楽性の違いだなぁと思いました。 この感じた違いは、色々と個人的にふりかえりしたり、同僚とワイワイして話ができて良かったです。 マジ同僚最高。色々と得た知見は次で活かせそうです。
事業内容の方向性にも違いを感じて、自分は自家用車を持ってるしタクシー配車アプリをほぼ使わないし、地元の親も自家用車移動でタクシーに乗らないといった状況で、 もっと自分や自分の子供や周りの人が使うサービスに関わりたくなり、今の事業内容では音楽性が違うなと思い転職します。
転職活動
自分の現状分析やチーム、事業、会社へ求めるものを整理し、育児中の自分が転職活動で取れるコストや音楽性の違いがある現状を考え、以下のような戦略で進めました。
リファラルメインで活動したので自分のやりたい領域をやってる会社の知人や、声をかけてくれた友人とカジュアル面談を3社ほどやり、 希望度合いの高い順に1社ずつ攻めていく一本足打法戦略で進めていきました。
結果としては活動を初めて1ヶ月ほどで第一希望だった1社目でゴール出来ました。
振り返ってみてよかった点としては
- 普段から転職サービスに登録してて職務経歴書とかが比較的最新な状態を保てていたので準備が楽だった
- コロナ前から勉強会参加やカンファレンス運営スタッフをやっていたおかげで友人に恵まれていた
結果としては普段から用意をしておくことが大事だったってことかもしれません。
失敗したなと思った点としては
- 知人にカジュアル面談をお願いしてたので断りを入れるのが中々悲しい気持ちにもなった（一緒に働けたらそれはそれで楽しいだろうな）
といった感じです。
引き継ぎ
引き継ぎの際にリポジトリマイニングを行って、自分しか触っていないコードを調べて、そこを重点的に引き継ぎ資料を書いたりコメント追記したりして、引き継ぎをしました。
Gitリポジトリのコミットログをガーッと見ていって、ファイルごとのコミット数やAuthorを集めてきてくれるgitのサブコマンドを作りました。
本当は他にもコミット回数やAuthorの多さから不具合の可能性が高いファイルを可視化しようとしてPythonで書いてたけども、
せっかくなのでgitのサブコマンドとして使えるようにGoで書き直してbrewでインストールが出来るようにしました。
brewでインストールしたら git analyze が使えるようになって、 対象になるリポジトリのディレクトリで git analyze -search-only-target-author -author=iwata-n って感じで実行すれば
以下のようなコミット回数順でソートされた指定された人だけが触っているコードが出力されます。
git analyze -search-only-target-author -author=iwata-n searchOnlyTargetAuthor commit count, path, authors 6, git-analyze.go, [iwata-n] 3, .gitignore, [iwata-n] 3, args.go, [iwata-n] 3, logger.go, [iwata-n] 2, .goreleaser.yml, [iwata-n] 2, README.md, [iwata-n] 2, analyzer.go, [iwata-n] 2, commit_file.go, [iwata-n] 2, error.go, [iwata-n] 2, go.mod, [iwata-n] 2, go.sum, [iwata-n] 2, parser.go, [iwata-n] 1, LICENSE, [iwata-n] 1, sort.go, [iwata-n]
ただ、コミット数が多いリポジトリを解析するとすごく時間がかかります（手元のMBP16インチで2500コミットを解析するので5分ぐらい）
git analyze -parse-file=result.json と指定すれば1度解析した中間ファイルをresult.jsonとして出力してくれて、次からは
git analyze -parse-file=result.json -skip-parse -search-only-target-author -author=iwata-n と実行すればOKです。
今の所は分析が特定の人だけが触っているコードを調べるってことしか出来ないのであまり意味がないですが、今後出来ること増やしたときとかに役立つかなって思ってます。（本質的には解析の速度をあげるほうが良さそうですが）
最後に干し芋です
既存のNavigationとJetpack ComposeのNavigationを併用する時の注意
"androidx.navigation:navigation-compose:2.4.0-alpha04" をimplementationに入れてビルドすると
Class 'Xxx' is not abstract and does not implement abstract member public abstract val actionId: Int defined in androidx.navigation.NavDirections 'getActionId' overrides nothing 'getArguments' overrides nothing
のようなエラーが出る。
その時は、既存のnavigationのライブラリ側が2.3.x系を使っていたりと古い場合があるので、
依存ライブラリで
"androidx.navigation:navigation-fragment-ktx:2.4.0-alpha04"
"androidx.navigation:navigation-ui-ktx:2.4.0-alpha04"
と、プラグインが
"androidx.navigation:navigation-safe-args-gradle-plugin:2.4.0-alpha04"
とcomposeと同じ2.4.0系を使ってあげる
bugspotsをDokcer上で動かす
bugspotsの依存ライブラリが現在の環境だと動かない状態だったのでGemfileを用意して動かした手順
Gemfileの中身
source 'https://rubygems.org' gem 'rugged', '0.21.0' gem 'bugspots'
Dockerfileの中身
FROM ruby:2.3 RUN apt-get update && apt-get install -y cmake WORKDIR /bugspots ADD Gemfile ./ RUN gem update && bundle install --path vendor/bundle --binstubs=vendor/bin
Rubyがちょっと古いけどもruggedが依存しているのが古いバージョンみたいで2.5だとエラーになった。
これで
docker build -t bugspots bugspots とかでイメージを作って docker run -i --rm -v=$PWD:/work bugspots bundle exec bugspots /work とか動かせばOK
JetpackComposeで無限ループで値を変える
rememberInfiniteTransition と animateFloat を組み合わせて、更にイージングを LinearEasing にすることで無限ループで値が一定間隔で変化する
val infiniteTransition = rememberInfiniteTransition()
val time by infiniteTransition.animateFloat(
initialValue = 0.0f,
targetValue = 1.0f,
animationSpec = infiniteRepeatable(
animation = tween(
durationMillis = 1000,
easing = LinearEasing
),
repeatMode = RepeatMode.Restart
)
)
マッサージガンMYTREX REBIVEを買った
在宅勤務も1年以上してきて急に肩こりからくる頭痛が毎日のように襲ってくるようになったのでマッサージガンを試しに買ってみた
買ったのはMYTREX REBIVE。 このご時世現物を試すことも難しいので、Amazonでもヨドバシでもマッサージ機器ランキング一位だったのを頼んでみた。 ドクターエアーのが1万ぐらいで出てたけども失敗したくないし、何よりも早く良さそうなのが欲しかったので奮発した。
こんな感じの段ボール箱に入ってた
出してみるとこんな感じの専用のケースに入ってる
ケースの中は全部入り。充電ケーブルがUSB Type-Cなのが地味に嬉しい。
使ってみた感じだと、ガン形状なので首、肩、肩甲骨あたりまでは一人で簡単に当てることが出来る。Twitterで肩甲骨無理じゃね？みたいな話してたけども、意外とガン形状だからなのか無理せず当てる事が出来た。
強さ的には振動が一番少ないモードよりも一番強いモードの方が痛みが少なくていい感じな気もした。
丸い形状のヘッドはマイルドに首、肩に振動を伝えてくる感じだけども、棒状のはしっかりと叩いてくれているような感じ。
これでしばらく続けてみて頭痛が治まると良いなぁ
追記 これを使いながら仕事しようとすると手が1本塞がるのと、何よりも振動が強いので目がブルブルしちゃって文字がまともに読めなくなるので向いてない。
CorotineScopeでの注意点
class HogeFragment() : Fragment() { // 1 val scope = lifecycleScope + errorHandler // 2 val scope = viewLifecycleOwner.lifecycleScope + errorHandler // 3 val scope get() = viewLifecycleOwner.lifecycleScope + errorHandler override fun onViewCreated(view: View, savedInstanceState: Bundle?) { scope.launch { while (isActive) { delay(500) Timber.d(this.toString()) } } } }
1のscopeはFragmentのライフサイクルに応じたスコープなのでHogeFragmentがスタック上に行ってもcancelされない。 なので、Timber.dはFragmentがスタック上に行っても出力され続ける。
2のscopeはFragmentのスタックをPopして再度HogeFragmentが表示された時にはcancel状態になってしまう。 スタック上に行った際にViewのライフサイクルに応じたスコープなのでcancelされるが、scope自体はFragmentのメンバ変数なのでFragmentが破棄されて再生成されない限りは同じインスタンスになっている。 なので、Timber.dは1度目のFragment表示時は動いていて、Fragmentがスタック上へ行った際に止まり、Popしてきても再度動かない。
3のscopeはHogeFragmentがスタック上に行ったらcancelされて、再度表示された時にActive状態になるのでコルーチンが動く。 なので、Timber.dはFragment表示時は動いていて、Fragmentがスタック上へ行った際に止まり、Popしてきたら再度動く。