画竜点睛を衝く@mapyo

日々やった事をつらつらと書くブログです

Gormのv1で想定外の挙動になることを防ぐために BlockGlobalUpdate(true) を設定しましょう

2024/03/31 追記

https://pkg.go.dev/github.com/jinzhu/gorm#DB.BlockGlobalUpdate

結論、 BlockGlobalUpdate で trueを設定しましょう。 v1の場合これがデフォルトでfalseになっており、v2からはデフォルトでtrueになっています。なので、v1のGormを使っていればwhere句なしのupdate/deleteはガードされます。 deleted_atを使っていても有効です。

ただし、structのzero valueの見落としがちな特性が完全になくなるわけではなく、引き続き残るため、この観点は引き続き注意が必要です。

完全にv1にこのメソッドがあることに気がついていなかった。。。


今更感あるが改めて現象の整理と対応方針を考えてみる Gormのv1とは以下で、

https://github.com/jinzhu/gorm

今現在は

https://github.com/go-gorm/gorm

こちらが最新(v2)になっている。

v1のドキュメントとv2のドキュメントは違うので、検索する時にはバージョンを確認するのを忘れないようにするべし。

https://v1.gorm.io/ja_JP/docs/index.html

今回はv1の話です。

どういう状態の時に想定外の挙動になるのか

structを使った際にzero valueの仕様の部分で想定外の挙動になるので、そこを注意さえできれば問題はなさそう。sliceの中がstructの場合も注意。

ライブラリとしては意図した挙動で仕様通りではあるのだけど、型でガード出来る部分でもないので、意識して書く必要がある。

Where句

whereの検索条件にstructを使った時に、zero valueな値が設定されていると、その部分がSQLのwhere句から設定されない状態になる。書いた人視点では明示的に書いているつもりだけど、それがSQLのwhere句に反映されていない状態になるため、意図しない検索結果となる。where句はみなさんご承知の通り、select, update, deleteの全てに使われるものであり、全クエリでこれを意識した上で書く必要がある。

詳しくは以下。

https://v1.gorm.io/docs/query.html

NOTE When query with struct, GORM will only query with those fields has non-zero value, that means if your field’s value is 0, '', false or other zero values, it won’t be used to build query conditions, for example:

Structを使った時に、zero valueな値を設定するとこれはクエリの検索結果には使われなくなる。

db.Where(&User{Name: "jinzhu", Age: 0}).Find(&users)
//// SELECT * FROM users WHERE name = "jinzhu";

公式のサンプルにかかれてあるが、zero valueな値を指定すると、その値は検索条件を設定することが出来ない。

Update

データを更新する時に意図した更新がされないケース。こちらもまたzero valueの問題で、こちらも公式ドキュメントにWarningとして記載がある。

https://v1.gorm.io/docs/update.html

// WARNING when update with struct, GORM will only update those fields that with non blank value
// For below Update, nothing will be updated as "", 0, false are blank values of their types
db.Model(&user).Updates(User{Name: "", Age: 0, Actived: false})

zero valueはupdateのクエリが一切発行されない。上記は何も更新されない状態となる。

また、db.Modelにわたす際のstructがzero valueが含まれている時も同様に、where句の条件から除外されるので、ここも注意しないともれなく全件更新となる。

普通にそんな書き方なんてしないよと思ったあなた!検索した結果がもし存在しない場合、db.Modelメソッドに渡すStructはid等がzero valueとなり、もれなく全件更新となる。

var result User
db.Where(&User{Num: 10}).First(&result)
db.Model(&result).Update(User{Bool: true})

Delete

https://v1.gorm.io/docs/delete.html

WARNING When deleting a record, you need to ensure its primary field has value, and GORM will use the primary key to delete the record, if the primary key field is blank, GORM will delete all records for the model

例えば、以下のような書き方をした場合、

// Delete an existing record
db.Delete(&email)
//// DELETE from emails where id=10;

emailのprimary_keyがzero valueだと、全件削除になってしまう。

普通にそんな書き方なんてしないよと思ったあなた。検索した結果をそのままidに設定して削除するなんて処理書くとおもうのだけど、検索した結果を適切にハンドリングしておいかないと、検索対象が存在しなかった場合に、id=0のzero valueで構造体が返ってくるので、それをそのまま指定すると、もれなく全件削除になるというわけです。こういうやつ。(あとから見直すと、Updateと同じパターンだ)

var email Email
db.Where(&Email{ID: 99999999}).First(&email)
// emailの検索結果がないので、zero valueのid=0がセットされたまま。
db.Delete(&email)

あと、あるあるなパターンとしてもう一個思ったのが、バッチ処理で特定のレコードを検索、そして削除処理を実行する場合。一般的にバッチ処理は冪等性を持った作りにしているはず。一度実行したから、もう一度実行しても、特に問題ないはずだよな。。という気持ちで実行したら、特定のレコードは初回の実行で削除されてしまい、検索結果に出てこないので、今度は全件削除されてしまう。なんてこともあるかもしれない。

対応方針

チームやコードベースによって違う

挙動と対応方針について上記のサイトで詳しくまとめてくださっていた。大変ありがたい!!!! ここを読み込んだうえでどういう対応を取ればよいのか各自で検討するのがよさそう。

個人的には最低限UpdateやDeleteに関わる部分はstructを使うことを中止した方がよいような気はする。。。が、どうなんだろうか。

structを引き続き使うことを決定したとしても、仕様をチーム全員が理解したうえでレビューしたり、プルリクのチェックリストに追加したりは最低限実施する必要があると思う。また、ゼロ値が入っていないかを全ソースに毎回チェックを入れる。。。?

MySQLの場合、 sql_safe_updatesを有効にする

これはとりあえず、ONにしておくとよいのではないかと考えた。

クライアントから接続する場合は、--safe-updates も選択肢としてはありそうだが、これをつけると sql_select_limit=1000, max_join_size=1000000; この設定も合わせて有効になってしまうので、使われ方によっては影響が何かしらに出てくるかもしれない。 その辺を考慮して、既存のコードのへの影響を考えると、 sql_safe_updates をグローバルにONにしておくのがいいのではないかと考えた。

※これを実施したとしても、Soft Deleteの機能(DeletedAtを使っている)を使っている場合は、where句に  deleted_at IS NULL などの条件が入るため、無意味。。

※gormのv2では、BlockGlobalUpdateの機能がデフォルトで入っており、明確に書かないとwhere句なしの全件更新は出来なくなっている。Soft Deleteを使っていても効く。

https://gorm.io/ja_JP/docs/v2_release_note.html#BlockGlobalUpdate

所感

Gorm V2では、全件更新に対する対策や、個別のカラムを指定してUpdateする機能追加は入っているものの、structのzero valueは言語仕様上、どうしようもないと思われるので、どのみち意識して引き続き書く必要がある。ここは皆さんどんな方針で対応してるんだろうか。気になる。ただ、DeletedAtの時もガードしてくれるので、普通にアップデートした方が良い。いろいろ違うようだけど。。

気になった方はサンプルを残しておくのでいろいろと挙動を試してみてください。

https://github.com/mapyo/GolangSample/pull/1/files

参考文献

現職に入って半年経過したので振り返る

https://freenance.net/

フリーナンスというサービスを運営している、GMOクリエイターズネットワーク株式会社という会社で4月から働いてます。10月1日でちょうど半年たったので軽く振り返ってみる。

きっかけ

GMOクリエイターズネットワークという会社は、会社HPを見てもらうと書いてあるとおり、

https://www.gmo-cn.jp/

株主構成をみるとGMOペパボが多く株を持っており関わりが深い。

GMOペパボという会社で昔働いており、そのつながりで顔なじみの関西弁を使いこなす人事の方からTwitterでDMをもらったのがきっかけ。

会社HPをみてもほぼ何も情報がなくw HPの採用情報の部分を見ても、当時は「採用はありません」とかかれてあって、採用してないのかな。。謎だなと思ったのは今となってはいい思い出であるw (今は採用ページは一応存在しており、僕が入社して少したった時にTalentio職人となって採用ページを作りました)

ただ、サービスサイトはしっかりとしたものが存在していて、それはよかった。この思想に惹かれた部分はある。

https://freenance.net/statement

また、フリーナンスを立ち上げられた方で事業責任者でかつ、社内のNo.2の方にいろいろお話を聞いたところサービスが目指す姿とか、今後の展開もおもしろそうだなと思った。 加えて、サービスの開発体制としては、グループ内外のエンジニアの方がメインで開発を進められており、社内にはエンジニアは1人もいない。PdMやデザイナーの方も社内に1人もいない。という状況で、社内にも開発組織を作っていきたいということで、そこも魅力に感じた。

当時シード調達をするかどうかのタイミングのベンチャーでも選考を進めていて、非常に迷ったのだけど、今の会社の方がよりサービスの成長や、開発組織づくりにコミットできそう。というか、社員のエンジニア1人目なのでコミットするしかないということもあり、入社を決めた。

もろもろやったことなど

結構雑に書いてみる。

GMOペパボと同じオフィスなので、入社初期は「ぼいらー久しぶり」という会話でまずペパボの方々と話がもりあがった。若干人見知りなところもあり、GMOクリエイターズネットワークの方々よりもペパボの懐かしい方々と話す機会の方が多かった。(今は普通に飲みに行ったりワイワイ楽しく話してます!念のため。)

とりあえず、社内にエンジニアが自分1人しかいないので、優先順位をつけてそれを周囲に共有して、高いものからやっていくしかないだろうと思った。 幸いにも開発に関してはグループ内外のエンジニアの方々で回っていたこともあり、その辺はお任しして、採用を出来る状況にすることが一番大事だろうと思ってそこに注力した。まずは募集要項の作成。どういった切り口で職種を分けて募集要項として出すのか考えたり、その中身を作った。エンジニアだけじゃなく、プロダクトマネージャーやデザイナーの採用も出来るならしたかったので自分なりに募集要項を考えて、ペパボのシニアなPdM、デザイナーな方々に募集要項をレビューしていただいた。

その後、Talentioという採用管理システムをもろもろキャッチアップしたり、ちゃんと採用できてそうな会社さんの採用サイトを参考にしながら、採用ページを作った。かなりシンプルな感じではあるが、自分ひとりでよくできた方だとは思う。 https://open.talentio.com/r/1/c/gmo-cn/homes/3922

優先順位に関連するところでいうと、自分自身の直近のミッション決めて関係者と認識を合わせた上でやることを決める必要があると思ったのでそうした。ちょっと抽象的な方向性を文章化して書いておかないと、周囲に自分がやっていることについて説明しにくいし、自分自身のタスクの一貫性も弱くなるかなと思ったのも理由の一つ。また、社内のエンジニアは1人しかいないので、やっていることを周囲にアウトプットして行かねばならんと考えたので毎月1回、先月やったことをサラリとまとめて他の方々に共有するようにした。今現在は忙しさにかまけて中断してしまっているが、再開していかないとな。。。

他やったこととしては、開発内部の情報の整理など。社内にエンジニアが1人もいなかったこともあり、いろいろと整えた方がよいなと思ったことがいくつかあった。

まずはNotionの導入。ドキュメント関連が不足していると感じ、まずは開発内部からやるのがやりやすかろうということで、開発内部メインでNotionを導入した。メンバー紹介ページとか、ジョインしたら見るページとか、会議の議事録とか、もろもろ整えた。また、仕様についての議論がGitHubのIssueやslackで主にされており、結局どういう仕様になったのかがわかりにくかった。他にもエンジニア職以外の方々は普段GitHubを使わないため、仕様を連携する部分が弱かった。これに対応するために、NotionにいわゆるPRDを書く場所を作ったり、PRDのテンプレを作った。込み入った仕様のものはPRDを作成しここで議論出来るようにしたり、議論した結果がPRDに反映されることによってシステムを使う方にさくっと情報連携しやすい状況にした。他にも、開発に依頼したい案件一覧のようなものをNotion上に作って、今まで口頭やslackで依頼されていたものをなるべくこちらに書いてもらってから開発が着手するような方向でやろうとしている。PRDやこの辺の動きについてはまだスムーズにできてない感もあるので、引き続きやっていきたい。 関連したやったこととしては、開発系のチャンネルを整備したり、開発用のGoogleの共有フォルダが存在してなかったのでそこを作ったりした。

もろもろあって採用の温度感が下がり、次の課題としては大きめの技術課題の解消があった。基本的な作業は着手されていた方におまかせしつつ、それ以外の部分をなるべくスムーズに進むように動いた。開発外で調整が必要な部分は積極的に調整を行ったり、タスクを洗い出して適宜スケジュール感が見えるようにして、聞かれたら現時点のスケジュールを答えられるようにはした。ただ、エンジニアが十分いるわけでもないので、タスクの差し込みがちょいちょいある。障害の対応やその恒久対応などなど、緊急度が更に高いタスクをお願いする必要が出てきているため、スケジュール通りにはいかないところが苦しいところではある。

それと並行して、何はともあれオブザーバビリティを確保するのも重要だなと考えた。立ち上げから4年くらい立っているサービスということもあり、ところどころ処理が遅くボトルネックを見つけるのに時間がかかっていたり、アプリケーションエラーを上手くハンドリングできてない部分もあった。この辺は現在進行系ではあるが、DataDogの導入検討を進めている。 まずは自分たちのサービスが今どんな状況かを楽に知ることが出来る状態にする。これを実現して、自分たちの運用負荷を下げて時間を作って別のことが出来るようにしていきたい。DataDogを入れたら全部解決するわけでもないが、ツールに任せられる部分は多少コストを払ったとしても積極的に任せていきたい。この辺は今のところ他の方にお願いできる余力がないので、僕1人で進めているが、なかなか進捗が悪いです。ぴえん。でも、APMの情報やらメトリクス情報を無駄に眺めるのは好きなので少しずつ取れる情報が増えるのを楽しみながら進めている。

ややPdM的な動きも一応やってはいる。新機能のPRDを書いて関係者で認識を合わせたりした。 他には金融系サービスということもあって、結構内部の業務がいろいろと複雑である。その複雑な業務をキャッチアップしながらいい感じにシステムに落とし込んでいくということもやっていかないといけない。まだ満足にはできてないけど。。。

さらには、チームの役割を見直した。大きく2つチームがあるのだけど、運用系タスク&新規機能開発を実施するチームと、技術課題解消や、開発効率改善をやっていくチームと定義し直した。まだちゃんと運用できてない部分もあるが、開発チームとして、新規機能開発に力をいれるのか、技術課題解消に力をいれるのかの優先度を、チームに所属する人数の割合で決めると優先順位をつけやすいと考えている。例えば、技術課題の解消に力を入れたければそのチームの人数を増やせば良い。

とかとか。

まとめ

この半年間、ここには書ききれない程、めちゃくちゃいろんなことがあったなーと思った。濃ゆい半年間だった。入社前は社内のエンジニア1人目として入ったこともあり、それなりに大変だと思ってたけど、それよりも1.5倍〜2倍くらいは大変だった。人によって大変だと捉えるか、やりがいがあると捉えるかは違ってくると思うが、やりがいがあると思える部分もあった。自分としては思い描いていた部分と違った部分もあるけれども、トータルではいい経験ができているのではないかとは思っている。

ただ、プロダクト開発系人材が自分1人なので、いかんせんパワーがめちゃくちゃ足りてません。PdMやソフトウェアエンジニア(バックエンド)を今は熱望しているので、興味がある方はぜひとも一緒にやっていきましょう!カジュアル面談の枠も作った方がいいなと思って作ったりもしています!

https://open.talentio.com/r/1/c/gmo-cn/pages/79791 https://open.talentio.com/r/1/c/gmo-cn/pages/78518 https://open.talentio.com/r/1/c/gmo-cn/pages/78856

補足としては、弊グループは毎週金曜日がバータイムなので、お酒は強くないが飲むのは好きなので、社内の人とちょいちょい行って楽しんでたりはしています。

2022年ふりかえり

年末なので今年1年を振り返ってみる。内容をちゃんとまとめていくと年を越してしまいそうなので、雑にふわふわした感じで書いていく。

仕事の役割

10月頃まではAndroidチームのテックリードをやったり、サービス全体のテックリードみたいなことをやっていた。10月頃からは、サーバサイドにも注力していかないといかんやろということでAndroidチームのテックリードははずれて、サーバサイドの1つのチームのテックリードをやるようになった。

テックリードとは

テックリードとはそもそも何か?これは会社や組織によって役割や定義が違っていると思う。今の組織の開発の進め方としては、外部の開発パートナーの方々に大部分をお願いして作って頂いている形になっている。そういった組織の中でのテックリードの役割としては、技術的な作りの部分の方針や意思決定を行うことや、品質面の担保をしていくことではないかと思う。文面だけみると一般的なテックリードと同じような感じ。。?

時期によっても役割が変わっていったように思う。今作っているアプリをリリースする前の役割(2021年の話だけども)としては、決まった期日までに品質面を維持した上で開発を完了させる。何か懸念があれば適宜アラートを上げる。開発がうまくいくように出来ることはなんでもやる。というような役割だった。テックリードというより、プロジェクトリードみたいな感じ。。?

リリースが終わると、継続的にいい感じに開発を回していくにはどうすればよいか?ということを考えて実践していく事が多かったかもしれない。 また、大きめの開発案件でなおかつ技術的に検討が必要な部分に関しては積極的に関わっていくけど、それ以外は開発が普通に回っている場合は積極的には関わらない感じにはなっていった。

サービス全体のテックリードとは

これは正直なところ、自分の中でうまくワーク出来ているかどうかはわからない部分ではある。。。全体と名前がついている通り、1つのチームを見るだけでなく、複数チームの技術面について見ていくということだろう。 1チームのテックリードだと、自分のチームをメインでみつつ、他チームに対して必要であれば調整をしていくという考え方になるが、それが1つレイヤーが上がることになる。

視座が今までよりは1つ上がったような感じはするが、まだまだこれからな気もしている。

一般的なプラクティスがそのまま流用出来るわけではない

エンジニア界隈の記事を見ていると、この手法いいよ!とかこの技術やこのやり方を使って問題を解決!!というような記事をよく見ると思う。これをなんともなしに導入しようとだけするとうまく行かないことが多い。いわゆるスクラムアジャイルの手法を取り入れるなども。

いま自分たちが置かれている状況はなんなのか?目的はなにか?どういった課題があってそれを解消するために導入するのか?その辺を適切に整理してやっていくことが重要かなと思う。逆に、目的や課題の設定が適切にできていて、関係者の中での認識が揃ってさえいれば大体のことはうまくいくのかなぁとも思ってきた。

とりあえずやってみるということと、ちゃんと考えてからやるの境目

個人的には不可逆な選択じゃなくて、ある程度効果が見込めそうなものであれば一旦やってみようぜ! という精神ではあるものの、なんでやるのかとか、やることで得たいものなどなどをすり合わせてからやる事も必要だなとも思っている。

LayerXさんの 「NoじゃなきゃGo」の精神は非常に素晴らしいと思った。そういったアジリティの高い組織はすごいと思う。

ぼいらー室

半分ネタ的な名前ではあるけれども、技術的な相談の場としてぼいらー室という会議が開催されるようになった。現職ではぼいらーというあだ名が浸透しているので、初めてお会いする人からも、あのぼいらー室のぼいらーさんですね。みたいな感じの事を言われたりもした。

Androidの座談会

チーム内の定例だけだと作っているサービスに関する技術的な話しか出来なくて、一般的なAndroidの知識や、定例で話すまでもないわからないこととか、何でもゆるく話す会が欲しいなと思って始めてみた。 これは自分でいうのもなんだけど、個人的にはけっこうよい取り組みだったなと思う。技術の事に関してワイワイ出来るのはエンジニアとしては楽しいものです。

ふりかえり

いわゆるKPTとかYWTとかその辺のふりかえりである。リリースが終わってアプリチーム内でどこかのタイミングでふりかえりが定期的に行われるようになった。改めて思ったのだけど、ふりかえりの文化は非常に重要かなと思う。 なにかの施策や大きなプロジェクトが終わったタイミングや、継続的に開発をしている組織の場合は定期的に期間を決めて、ふりかえる事は非常に大事だと思う。

たとえ適切なTryが出なかったとしても、関係者の間でやったことを供養したり、課題感を共有するだけでも全然違うと思う。また、自チーム内だけではなく、他チームなどの一緒に仕事をしている組織間でのふりかえりも得に重要かなと思う。一度立ち止まって言語化したり、言語化しきれないこの気持を話して会話してみるだけでも全然違う。

自分のチーム・組織間のふりかえりをやると重複した部分も出てきて時間が消費されることもあるけども、一旦気にせずにやってみてから考えるのはいかがかな?

企画と開発でワイワイ出来る会

企画と開発で部署がわかれており、会議体で普段やりとりしているという事もあって、もうちょっと突っ込んだ話がしてみたいなと思って開催をしてみた。 テックラボというかっこいい名前付けがされているが会議よりもより少人数で話す会である。 会議体に持ち込んで話すみたいな仰々しい感じではなくて、ちょっと気になってる事とか、この辺技術的に出来るの?みたいなところを話すのがメインである。 今までよりもワイワイ話すことが出来てやってみてよかったと思う。

決まった時間でSlackのHuddleで開催したり、話す内容をSlackで適宜流す事で気になった人は気軽に入りやすい感じにはなった。まさにHuddleの英単語の意味に近い。

コードはほぼ書いてない

2021年もそうだったが、仕事ではほとんどコードは書かなくなってしまった。プライベートではちょいちょい書いているけども。コード書くのは楽しいなー。

やっぱりいわゆるICがいいなぁと思う時もあれば、テックリードより上のキャリアも歩んでみたいなと思うこともある。この辺は自分の中でもわからない部分はあるものの、後悔の人生を送ってみたいものです。一度経験してみて駄目だったという事実がわかるだけでも自分の中の糧にはなりそう。

睡眠は大事

年末は車を運転して久しぶりに実家に帰った。

https://blog.recruit-productdesign.jp/n/n3cf8b8d5ddd2

帰る前にこのブログを読んでおり、睡眠に対する意識が高まっていたので、8〜9時間くらい寝るようにしていた。

しっかり寝ていたということもあって、昔の時よりも余裕のある運転が出来た。やっぱり睡眠は大事!!

まとめ

いろいろと思いついたことを雑多に書いてみたがそろそろ時間切れっぽいのでこの辺で。 来年はどんな1年になるのかなー。

2021年買ったものを振り返る

amazon楽天で買ったものを振り返って、記憶が残っているものに関して自分なりの感想を書いていく。アフィリエイトリンク的なやつ貼ってるので必要であればよしなに回避してください。かなり昔に設定してるのでちゃんと動いているかどうかも怪しい。

改めて振り返ってみると、いっぱい本を買ってたけど、全然読んでなかった。。。

ヤフーの1on1―――部下を成長させるコミュニケーションの技法

1 on 1 を定期的に行うという文化が今の会社にはあって、どんな感じでやっていくのがいいのか参考になった

マイクロサービスパターン

まだ全部は読めていない。なるほどという感じ

本好きの下剋上シリーズ

Amazon Kindle Unlimitedを使っていて、配信されていたので読んでみたら面白かった。全部読み放題で配信されているわけではないので一部だけ購入が必要。

周辺機器

Anker PowerExpand+ 7-in-1 USB-C PD Media Hub, 85W

Mac Book Airを使っていたのだが、USB-CのPD対応PCモニター と、キーボードとかマウスとかつなぐようのUSBハブをつないだらそれでいっぱいいっぱいだった。 たまにPD経由で充電していると電池がジリジリと減っていく減少が起きてしまい、USBハブをこれに置き換えて充電がジリジリ減っていく減少が起きた時にこれをつないでUSB-Cが刺さる部分に電源をさせば解決するのでは?と思った買ってみた。結果は解決しなかったので、あまり使ってない。

SATA to USB Converter Adapter

大昔のHDDの中に昔撮りためていた写真とか動画を入れっぱなしにしていて、取り出す時に使った。これで心置きなく大昔のHDDを捨てられる。

ガジェットなど

Kindle Oasis

スマホだけで本読んでると辛いので買ってみた。読みやすいといえば読みやすいが、技術書でレイアウトがちゃんとなされてないものに関しては読みにくいので、iPadとかPCとかで読んだほうがいいのかも。 小説(ほとんど読まないけど)とかを読むときは結構よさそう。

ライトニングケーブル

普通に使えている

USB-Cケーブル

普通に使えている

モバイルバッテリー

普通に便利に使えています

Echo Show 5

セールの時にかった。電源は入れているがほとんど使っていない状態。。。

スマートプラグ

これもセールの時に買っては見たものの、使い所がなくて使っていない。。。

ポケモンGO オートキャッチ

ポケモンGOに対する意識が高まって買ってしばらく使っていたが、ブームが過ぎて結局使わなくなってしまった。 自動で取れまくるのはとても便利。後は近所に手頃なジムがあればもっとやってたのかも。

ScanSnap iX100

これは買ってよかった。書類系は全部スキャンしてEvernoteに突っ込む運用をしている。 家の中で持ち運んで使うことを考えてこれにしたけど、ほとんど持ち運ぶことはないので、最近発売された据え置き型を買っても良かったかも?とも思った。

ソニーブラビア

結構高い買い物をした。 でっかいテレビを買った。地デジ化直後に買ったテレビで5年くらい使ってたのでそろそろいいかなと。 今まで使ってたテレビはサブのゲーム用として使われている。同じソニー製のテレビで、横並びで配置しているので、片一方の電源を入れるつもりが両方の電源が入ってしまうみたいな現象が起きてしまう。 テレビ単体でも音の質もよくなったので(そこまで音質にはこだわらない方)、よかった。

MacBook Pro M1 Max

www.apple.com

でかい買い物だった。今までMacBook Airを使っていてもっさりした動きをすることが多かったのだが、これを買うことでそのなやみから開放されてサクサク動いてストレスから開放されるようになった。 10年くらい使えて欲しいけど、その辺はどうなんだろうか。。。

日用品

電動コーヒーミル

コーヒーにじわじわハマりだした年でもあった。 これは定期的に使っている。買ってよかった。いろいろと置くスペースがあるのであれば、全自動のミルを買ってもいいかもしれない。

水出しコーヒーポット

1度使ったんだけど、予想以上に苦い仕上がりになってしまってそれ以降使わなくなった。もっといい感じにやってたら美味しくできたのかもしれない。

ペーパータオル系

トイレにタオルを設置するとタオルを定期的に変えるのが面倒くさいと思うようになって買ってみた。今度は吹き終わった紙を定期的に捨てるのがめんどくさくなってしまった。。

電動歯ブラシ

5年くらい使ってた電動歯ブラシが、充電池がヘタって、1回充電したら1回しか使えない状態になってしまったので買い替えた。1回充電したら1週間ちょいくらいは使えるので便利になった。

ランドリーバスケット

普通に便利

ザイグルボーイ2

たまに使ってる。煙がめっちゃ飛び散らないのでいい感じ。ゴリゴリ焼きたい場合は向いてないかもしれない。じんわりやける。

筋トレ系

筋トレにハマりかけた時期があったけど、最近はブームが廃れてしまった。 ダンベルはいつも隣に置かれてあるので後はやるだけの状態にはなっている。

キャンプ道具

デイキャンプにハマりだしたのでちょいちょい買った。 今年はテント泊してみたい

その他

卓球セット

テーブルに取り付けて卓球をするやつ。買ってからしばらく卓球ブームが来ていた。 最近はやらなくなってしまった。

所感

途中から数が多くてやめようかと思ったけど、なんとか最後まで書ききった。 振り返るといろいろ買ってた事がわかったので、今年は控えめにやっていこう。 定期的に振り返るの大事。

2021年振り返り

年末なので今年を振り返ってみる。結構ゆるふわな記憶なので細かい時期感は違ってきているかもしれないw まずはざっくりとした時期ごとに何してたかを振り返って、あとは適当に書く。

1月〜5月

なんやかんやめちゃくちゃ忙しかった。 Androidチームのリード的なことをやってて、昼間はミーティング、夜はコードレビューみたいな感じでゴリゴリ仕事してた。 基本的にフルリモートなのでよかったけど、出社前提だったら厳しい戦いだったと思う。

夜ご飯は普通に18時とか19時くらに食べてまた仕事するみたいな感じだったから、そこら辺は規則正しく出来ていたのでよかった。

6月〜10月くらい

忙しさはじわじわと下がっていきつつも細かい感じのやつがちょいちょい尾を引いてるみたいな感じだった。余力が出てきて、今後どんな感じで改善していく?みたいな話をしたりもした。アプリだけじゃなくて、サーバとかインフラよりのことに目を向け始めてたりもしていた。

筋トレを頑張ろうと思って、ダンベルとか筋トレグッズを購入したのだが、結局使わずに机の隣に置かれてあります。

釣りも去年よりは行かなくなってきた気がする。やはりブームが去ってきたのかもしれない。ずっと堤防からサビキ釣りをしてるけど、シーバス釣りたいなと思ってダイソーでルアーを買ったけど結局1回もシーバス釣りにはいっていない。

デイキャンプに少しハマりだす。BBQコンロ、折りたたみテーブル、タープなどなど購入した。まだテントは買ってないけど、テントを買うか借りるかしてテント泊をしてみたい。

10月〜12月

それなりに余力が出てきた。入社してからずっと関わってきたサービスがついにリリースされたので感慨深さを感じていた。 サーバとかインフラ周りとかキャッチアップしていた。

一度もリアルで会った事がない方がいる

これはコロナでの転職あるあるだと思うのだけど、今の会社に転職して1年とちょっとたったのだけど、一度も会った事がない方や、最近になってやっとリアルで会った。みたいな方が多い。一度も会ってないと、もしかするとインターネット上の高性能なAIが人間のふりをしている可能性もワンちゃんあるのではないかという気持ちになったりもした。

コロナもあるのでなかなか難しいところだけど、週に1回くらいは、ピークを避けて出社してランチ一緒に食べて家に帰る。みたいな感じでもよさそうかもしれない。

コードを書く機会が減った

コードを書くよりも、圧倒的に読んだり、ドキュメント見たり、ミーティングに出る機会の方が多かった。今年の前半の開発が佳境だった時ですら、自分ではほぼ書かずに開発は他の方にお願いして、コードレビューや仕様調整に徹していた。プライベートでコードをちょろっと書くのがこれまた楽しい。キャリアを積んでいくというのはこういうことなのか、もっと大きなバリューを出していくには必要なことなのかもしれないのだが、完全にそっちに振り切るには、まだそのレベルに達していないような気もしていて悩ましい。

コードを若干書きつつもサーバサイド全般に軸足を移していくみたいなことができるといいなぁと思うけども、さぁどうなるかなということろ。

技術力という面で見ると、コーディング力は少し落ちている気がする。この辺は多少なりとも書くか、プライベートででちょいちょい書いていきたい。

アウトドアよりの趣味

今年はデイキャンプにハマりつつある年でいろいろと揃えて、何回かデイキャンプしにいった。地元であれば車をちょっと走らせればデイキャンプできそうなところが無料であった気がするのだけど、こっちだとそこそこ走らないといい感じの場所がないのが残念なところ。

来年は暖かくなったらテント泊をしてみたいし、釣りも適宜いきたい。

まとめ

よいお年を!

jEnvを使ってjava8と11を切り替える

Android Studio Arctic Fox使うためにjava11使ったり8使ったりする機会があったのでメモ

jEnv入れるところまでは頑張る。

brew install --cask corretto8
brew install --cask corretto11
jenv add `/usr/libexec/java_home -v "1.8"`
jenv add /Library/Java/JavaVirtualMachines/amazon-corretto-11.jdk/Contents/Home


jenv global 1.8

jenv local 11

コマンドラインでAndroidアプリをビルドして起動し直す

最近ブログ書いてないので細かい内容だけどメモ

export APPLICATION_ID=com.example.myapplication
./gradlew assembleDebug; adb install -r app/build/outputs/apk/debug/app-debug.apk; adb shell am force-stop $APPLICATION_ID; adb shell monkey -p $APPLICATION_ID -c android.intent.category.LAUNCHER 1

たまにAndroid Studioのことが信じられなくなることがあって、そういう時はコマンドラインで一通りやりたくなる。アプリを起動する時に、Acitivityを指定する必要があるのかなと思ってたけど、monkeyというコマンドがあるのを知らなかった。