blog.syfm

徒然なるままに考えていることなどを書いていくブログ

一年を振り返り… (2021)

Thoughts

f:id:ktr_0731:20211228003939j:plain

仕事

今年もメルペイのコード決済チームに在籍しており、主に外部パートナーさまとの接続や、既存のプロダクトの部分的な改善を多く行っていた。今年関わっていたプロジェクトは去年より小粒のものが多く、その点では達成感はやや少なかった。ただ、今年は自分たちのチームが持っているプロダクトを見つめ直す機会が多く、チームでのテックロードマップを策定するといった、プロダクトの将来を見据えて物事を考えるようになってきた。来年頭からは目指すべき将来のために一歩ずつ進んでいく計画をチームで立てているので、それに関わることができるのは楽しみ。

来年からはチームの TechLead を引き継いで、自身が新たな TechLead となるので、これらの技術的な意思決定について、自分もチームメンバーも納得がいくように尽力していきたい。

これに加えて、スポットで副業もやっていた。主に gRPC 周りの機能開発・追加で、普段の業務とはかなり異なるアプリケーションおよびコードベースだったので楽しく開発を行うことができた。

技術

仕事でよく使っていた技術については今年はあまり変化がなかった。相変わらず Google Cloud 関連プロダクトと Kubernetes、Go、gRPC、Protocol Buffers を使っている。Protocol Buffers については、エンコーダとデコーダをフルスクラッチする機会があり、より理解が深まったと感じている。

engineering.mercari.com

会社のチーム内で行っている輪読会ではデータ指向アプリケーションデザインを読んでおり、この本からログの有用性について知ることができた。ログの append-only の性質を生かした、LSM ツリーベースのストレージエンジンや、線形化可能なストレージの実装はとても学びが多かった。

プライベートでは去年に引き続き、Web フロントエンド技術を使いつつ、年末に新たに Flutter を触り始めた。もともと初期の Android 開発経験はあったので、今と昔でまったく開発環境が違っていることに驚いた。React と似た記述と高速なライブリロード、複数のプラットフォームへのビルドができる点が非常に便利。Dart も初めて触ったが、文法自体は理解に苦しむところはなかった。今はまだ触っているだけなので、今後なんらかのアプリケーションを作ってみたい。

執筆

去年・一昨年に Software Design へ寄稿した記事を再編集した「エキスパートたちの Go 言語」が出版された。自分の担当分ではあまり差分はなかったが、pkg.go.dev への切り替えや go install についての紹介を追加した。

エキスパートたちのGo言語 一流のコードから応用力を学ぶ (Software Design plus)

エキスパートたちのGo言語 一流のコードから応用力を学ぶ (Software Design plus)

Amazon

会社のテックブログでは Merpay Tech Openness Month 2021 というイベントの一環で先程挙げた Protocol Buffers の内部実装に関する記事を執筆した。

個人ブログでは去年よりさらに書けていない…。これはインプットの量が少なかったことに起因しているのは間違いないので、来年はもっとインプット・アウトプットを増やしていきたい。

イベント登壇

Merpay Tech Fest 2021 という完全オンラインのイベントで「共通QRコード決済システムの裏側」という発表をした。これは去年関わっていた、d 払いとメルペイの連携の仕組みについての発表で、いつかどこかで話す機会が欲しいなと感じていたので良い機会だった。

engineering.mercari.com

去年と変わらず新型コロナによってリモート開催のイベントばかりだったので、個人的なイベント登壇については一切行っていなかった。

OSS

Evans と go-fuzzyfinder を今もメンテナンスしている。自ら大きな機能追加を行うことは少なくなっているが、いくつか Issue や Pull Request をもらっており、マイナーアップデートを行っていた。 また、Evans の紹介を社内向けに行ったりもしていた。Evans を使ってくれている人たちが身近にいるというのは言葉では言い表せない喜びがあって、OSS やってて良かったなぁと感じる。

GitHub Sponsors では去年に引き続き 4 名、新しく 3 名の方から支援をいただいた。本当にありがとうございます！

読んだ本

技術書

  • Cloud Native Go
  • モノリスからマイクロサービスへ
  • 詳説データベース

一部はまだ読んでいる途中だが、どれも良い本で学びがある。

小説

最近マグリット表紙の新装版が出たので買った。めちゃめちゃおもしろい。

実用書

  • はじめての多肉植物 育て方&楽しみ方
  • これでうまくいく！よく育つ多肉植物ＢＯＯＫ
  • ハオルチア (NHK趣味の園芸 12か月栽培ナビNEO)
  • カクタスハンドブック 原種サボテンを楽しむ

去年亡くなった祖父は植物栽培が趣味だったので、いくつか植物を自宅へ持ち帰ったら沼にハマってしまった。地元に帰るたびに少しずつ持ち帰っている。

漫画

九条の大罪が結構おもしろくて好き。

旅行

今年も新型コロナによりあまり旅行はできなかったものの、ちょいちょい行っていた。

鎌倉

2 月に日帰りでシュッと行った。コロナ禍ということもあり、観光客は少なく、のんびり歩くことができた。鎌倉で飲むビールは最高。

f:id:ktr_0731:20211228124629p:plain

箱根・強羅

パートナーの誕生日に合わせて行った。初めて 3 万円クラスの部屋に泊まったが、部屋・景色・料理・温泉・接客のすべてにおいて値段以上の価値があって本当に良かった。必ずもう一度泊まりたい。
この旅行ではあまり観光をメインにせず部屋でゆっくり過ごそうと決めており、実際チェックインしてからチェックアウトするまでほとんどの時間を部屋で過ごした。客室露天風呂がついているのが神すぎる。

f:id:ktr_0731:20211230001238j:plain

観たアニメ

友人と定期的にやっているアニメを観る会で観たものは基本的にリアタイではないアニメばかりなのでわりと前のアニメも混ざっている。
個人的に今年はシン・エヴァがダントツで良かった。エヴァは旧エヴァも含めてすべて観ていたので、また EOE のようにならないか心配だったが、実際はそんなことはなく、その上すべてのエヴァンゲリオンにさよならしていたのでエヴァはようやく完結したのだなと感じることができた。

プリンセス・プリンシパル Crown Handler 第1章も無印の雰囲気が存分に出ていて良かった。第2章が公開されているのを唐突に思い出してまだ観ていなかった第1章を観たものの、第2章が観れる劇場がほとんど上映終了していたのでそちらを観るのはあきらめた…。

やったゲーム

JUDGE EYES と LOST JUDGMENT がめちゃめちゃおもしろかった。ストーリーがかなりエグくて良いのと、バンバン人をなぎ倒すことができるので楽しい。

植物

f:id:ktr_0731:20211230010925p:plain

試しに今年は植物についても書いておく。前述したとおり、祖父の家から少しずつ植物を持って帰ったり、自分たちで買ったり、ふるさと納税でもらったりした。植物は毎日少しずつ成長していくので、フィードバックループを回したり仮説検証を行うのが好きなエンジニアと相性が良い趣味だと思う。
ここには写っていないガジュマルと、ハオルチアの姫椿錦がお気に入り。リトープスの生育はかなり難しくて試行錯誤している。

人生

自身に関しては、今年からパートナーとの同棲を始めたので日々の暮らしが非常に充実し、楽しいものとなった。若干の漠然とした不安はあったものの、いざ一緒に住んでみるとほとんどストレスなく生活ができているのでやはり波長があっているんだなと思った。東京の 3LDK 以上の賃貸の少なさや、ペット可賃貸の少なさから、今はマンションを買おうか検討していて、今年は非常に人生をやってきている年だったなぁと感じる。

自分以外のことで言うと、母方の祖母が癌になった。去年は父方の祖父が亡くなっているので、不幸が連続している気がしてしんどい。自分は見守ることしかできないけど早く良くなってほしい。

また、自分の両親の仲についてもあまり良くないのだと感じさせられる年だった。そういったこともあり、楽しい自分自身の生活だけに目を向けて、自分たち以外のことからは目を背けたいと思うことがしばしばあった。

終わりに

今年は嬉しいこと・楽しいことと同じくらい苦しいこと・しんどいことがあった一年だった。毎年毎年、少しずつ、確実に年齢を重ねて老いていっている現実に目を向けると恐ろしくなるが、こればかりはどうしようもない。自分のペースで向き合っていくしかないのだ。

できることなら来年は楽しいことの割合がより増えますように。

同棲をはじめて半年くらい経過した

other

今年の初夏あたりにパートナーと一緒に住み始めて、早半年が経過した。もともと一人暮らしだった二人が一緒に住み始めるので、当然さまざまな課題に直面した。それらの一部について、自分たちの解決策とともにブログに書いておく。

家計管理

一番問題だったのがこれだった。昔からよくあるパターンだと、家事をする側が銀行口座等を一元的に管理して、もう片方が小遣い制になるというものがあるが、自分たちは一人暮らし経験が比較的長く、お互い自由に生きたい人間なのでこのパターンは肌に合わなかった。そこで、なにを達成したいかというところから考えることにした。

ざっと挙げられた前提条件は以下。

  • パートナーとは個人的な出費以外の費用を折半したい。逆に言えば趣味への支出は完全に自由に行う代わりにお金を折半したり貸し借りはしたくない。
  • できる限り運用コストは減らしたい

これらを鑑みた結果、パートナーとの共有の貯蓄用口座をつくり、そこから共通の費用を折半する運用を目指すことにした。

この目標を実現できそうなものについて、以下のようなものを検討した。

家族カード

クレジットカード業界には家族カードというものがあり、これにより別々のクレジットカードを単一の銀行口座へ紐付けができる。そのため、銀行口座をどちらかの名義で開設し、お互いのメイン口座からその口座へ送金を行えばやりたいことが実現できる。 しかし、この家族カードは基本的にどのイシュアーも戸籍上の家族である必要があり、しばらく結婚する気のない自分たちにとってはそもそも使うことができなかった。

バンドルカード、Revolut などのプリペイドカードが発行できるサービス

これらには共通口座という概念がないので、そもそも今回の目的には合わなかった。Revolut には割り勘機能があるが、日常的な支払いをすべて割り勘にするのは面倒なので見送った。

かぞくのおさいふ

共通の口座にチャージし、別々のプリペイドカードから支払いができるサービス。一見やりたいことは達成できそうだったが、プリペイドなので出金はできず、残高を引き出したいときに困りそうだった。また、「家族」の定義が曖昧で、同棲で利用できるサービスなのかが判別できなかったので見送った。

www.smbc-card.com

Kyash 共有口座

最終的に選んだのは Kyash の共有口座という機能だった。各々が Kyash に登録して共通の口座を作成することで、その口座から支払いができる。この口座は資金移動口座なので口座から銀行への引き出しや自口座への移動といったことも自由にでき、貯蓄用途としても使えるのが大きかった。また、Google Pay や Apple Pay から QUICPay として設定でき、リアルカードを発行すれば Visa タッチ決済対応のプリペイドカードも発行できるので、日常のだいたいの決済で Kyash 経由の支払いができるのも大きなメリットだった。

共有口座から決済を行うと、カテゴリータブから支出の内訳が見れなかったり、自口座への自動振込はできても共通口座への自動振込はできなかったり、細部で不便な点はあるが、あまり大きな問題ではないので今の所 Kyash から乗り換える予定はなさそう。

www.kyash.co

家

住む家に関してもそれなりに検討した。まず、前提として以下があった。

  • 賃貸であること
  • 東京かつそれなりにアクセスが良いこと
  • 2LDK 以上であること

お互いもともと東京 23 区内に住んでいたので、あまり大きな環境の変化は避けたかった。また、自身は基本的にフルリモートで仕事をしているが、パートナーはリモートと出社を併用して仕事していたので、住むエリアについてはパートナーの職場へのアクセスも考慮に入れた。自身の職場へのアクセスは特に考慮していなかったが、結果的に自宅から 30 分未満で行けたのでラッキーだった。

また、お互い一人の時間を大事にしたい性格なので、個室のない 1LDK 以下は論外だった。そのため、最初から 2LDK 以上のみを選択肢として考えた。1LDK 等に比べて家賃が高くなるのはわかっていたが、もともと一人暮らししていたときも職場へのアクセスを最優先に考えてそれなりの家賃を払っていたので金銭面に関してはあまり気にならなかった。この選択は結果的に大正解だった。お互いリモートで働く際に声がもう一方へ漏れることはないし、個室があることで手軽に一人になれて良い。

賃貸に関してはあまり本腰を入れずに探していた期間も含めるとおおよそ半年くらい検討していた。Web 上で住みたいエリアを決め、実際に遊びに行ってみることで雰囲気をつかみ、最終的に地元に根付いた良い不動産屋を見つけて今の家を紹介してもらった。決めた家は 2LDK+S で、他の同じ条件の賃貸と比べると一回り家賃が安く、仲介手数料も 0.5 ヶ月だったので非常に良い買い物だった。家が広いと開放感があり、それだけで日々のストレスが軽減されている気がする。

半年住んでみて、家自体にはまったく何の問題も感じないものの、最近では 3LDK 以上の家に住みたいと思ったり、猫を飼いたいと思っているのでそろそろマンションを購入することも視野に入れていろいろ情報収集している。

家具・家電

家具はお互いの所有していたものをそれぞれ持ってきて使っており、新しく買ったものはほとんどない。家電類は重複してしまうので、基本的にどちらか一方のものだけを新居へ持ってきた。

ただ、唯一冷蔵庫だけは新居へ引っ越してから買い替えた。お互い結構な頻度で自炊をする人間なので、単身向けの冷蔵庫だとすぐに食材で一杯になってしまっていたが、買い替えてからはかなり余裕が出て食材管理が一気に楽になった。正直今年一買って良かったものだと思う。

情報共有

共同生活をする上で、さまざまな情報を共有する必要があるので、そのあたりも検討した。

まず、いろいろなメモを集約する場所として Notion を使った。Android/iOS ともにアプリが提供されており、非エンジニアでもある程度直感的に使えるのが良かった。 Notion では、たとえば個人のメモを書いておいたり、引っ越しの際の TODO 管理、月々の共有口座への入金額を算出した際のログなど、雑多な情報を集約している。

スケジュール管理としては Google カレンダーを使った。専用のカレンダーを一つ作り、共有したい予定をそこに作成している。

まとめ

これらの検討はいずれも良い選択で、今の所ほとんど不自由・大変な思いをせずに過ごすことができている。とはいえまだまだ改善の余地がある運用負荷があるので、エンジニアらしく効率化・自動化していきたい。

Go の "missing go.sum entry" エラーによって Dependabot による PR が自動でマージできなくなる問題を修正する

Programming

今まで設定していたものたち

個人利用のリポジトリや社内リポジトリでは Dependabot を利用していて、依存のアップデートを自動で行うようにしていた。
依存のアップデートがあると Dependabot は Pull Request を出してくれるものの、放置しがちだったので自動で approve してくれるような GitHub Actions を入れていた。

これと GitHub ネイティブではない Dependabot の automerged_updates という設定項目を有効にすることで approve がついたものを Dependabot が自動でマージしてくれるような設定にしていた。 *1

Go 1.16 からの変更

Go 1.16 から go.mod に含まれている依存のうち、go.sum に含まれていないものが1つでもあるとビルドが通らなくなった。これは Go 1.16 Release Notes にも記述されている。

Build commands like go build and go test no longer modify go.mod and go.sum by default. Instead, they report an error if a module requirement or checksum needs to be added or updated (as if the -mod=readonly flag were used). Module requirements and sums may be adjusted with go mod tidy or go get.

これにより、 go mod tidy を行っておらず、新しい依存を go.sum へ記録していないケースではビルドが通らなくなってしまった。

そして、Dependabot は go mod tidy を行うことができないという制約があった。 *2

GitHub ネイティブな Dependabot の go mod tidy サポート

GitHub ネイティブな Dependabot では v2 から go mod tidy が公式にサポートされることになった。

github.blog

これにより、GitHub ネイティブな Dependabot の v2 へ移行することでビルドが通るようになった。

自動マージ問題ふたたび

しかし、GitHub ネイティブな Dependabot へ移行したことにより、自動マージができなくなってしまった。
GitHub が自動マージを削除した理由としては以下のようなものがある。

Auto-merge will not be supported in GitHub-native Dependabot for the foreseeable future. We know some of you have built great workflows that rely on auto-merge, but right now, we’re concerned about auto-merge being used to quickly propagate a malicious package across the ecosystem. We recommend always verifying your dependencies before merging them. *3

理由としては至極まっとうなので、これからもしばらくは自動マージ機能を入れるのは難しいだろうな…と思う。

しかし、Go の場合、Go modules を入れていれば、タグを切らない限り新しい変更が伝搬することはない & リリース前にそれぞれの依存にどんな変更があったのかはチェックしているので、自プロジェクトであれば自動マージを入れても問題ないと判断した。

そこで、GitHub Actions を使って自動的にマージを行ってくれるワークフローを書いた。

name: "Auto approve Pull Requests and enable auto-merge"
on:
  pull_request_target
jobs:
  worker:
    runs-on: ubuntu-latest
    if: github.actor == 'dependabot[bot]'
    steps:
      - name: Auto approve and merge Pull Request
        uses: actions/github-script@v3.1
        with:
          github-token: "${{ secrets.GH_TOKEN }}"
          script: |
            await github.pulls.createReview({
              owner: context.repo.owner,
              repo: context.repo.repo,
              pull_number: context.issue.number,
              event: 'APPROVE'
            })

            const res = await github.graphql(`query {
              repository(owner: "${context.repo.owner}", name: "${context.repo.repo}") {
                pullRequest(number: ${context.issue.number}) {
                  id
                }
              }
            }`)

            await github.graphql(`mutation {
              enablePullRequestAutoMerge(input: { pullRequestId: "${res.repository.pullRequest.id}" }) {
                clientMutationId
              }
            }`)

secrets.GH_TOKEN *4 に対応するアカウントが PR を approve し、Enable auto-merge を有効にしてくれる。これにより、PR がすべてのチェックをパスすると自動的にマージされるようになる。

*1:Dependabot には GitHub ネイティブのものと、そうでないものの2種類がある。GitHub ネイティブのものは自動マージ機能が削除されている。

*2:https://github.com/dependabot/dependabot-core/issues/2229

*3:https://github.com/dependabot/dependabot-core/issues/1973#issuecomment-640918321

*4:デフォルトで設定されている secrets.GITHUB_TOKEN だと enablePullRequestAutoMerge が動かない