blog.syfm

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

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

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

家計管理

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

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

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

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

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

家族カード

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

バンドルカード、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 が自動でマージできなくなる問題を修正する

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

個人利用のリポジトリや社内リポジトリでは 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 が動かない

一年を振り返り… (2020)

f:id:ktr_0731:20201231032607p:plain

仕事

去年と変わらずメルペイのコード決済チームでバックエンドエンジニアをしていた。
今年関わったプロジェクトの中でもっとも大きかったのはメルペイと d 払いの QR コード (MPM) 統一だった。これによってメルペイの QR コードを d 払いアプリで読み込んで決済ができるようになった。個人的には今はなき MoPA を思い出す Yet Another MoPA だったので今度こそは、という気概があった。また、決済周りの開発のコアメンバーとして携われ、今まで得た技術・運用知識を元にベストな設計を模索できる時間が十分にもらえたのもありがたかった。実際にリリースされると、店頭で新しいアクセプタンスマークを見ることが多くなったので達成感も非常に大きかった。

jp.merpay.com

また、運用を二年もしているとあらゆるパターンの障害やデータ不整合を経験するので、これらによって発生する問題を解消するためにどうするかを考えることも多かった。単純にデータ不整合を解消するだけであれば比較的容易であっても、ビジネス要件からデータ不整合の状態が許容される時間が制限されるので、いかにしてデータ不整合の未解消時間を短くするかが一番中心の課題だった。

技術

仕事面では去年と変わらず同じチームに所属していたため、扱っていた技術はあまり大きな変化はなかった。Cloud Spanner や Cloud Pub/Sub、Kubernetes、Go、gRPC、Protocol Buffers あたりが最もよく使っていた技術だと思う。Cloud Spanner の気持ちも少しずつわかってきて、クエリを見てそのクエリがどんな感じで実行されるのかがわかるようになってきたし、シンプルに記述するだけではどうやっても効率が悪くなるクエリをどう書き換えれば良いかがだんだん掴めるようになってきた。*1

また、社内で Istio の導入が始まっているため、Istio を始めとした Service Mesh 関連技術の勉強を始めた。

ソフトウェアアーキテクチャパターンへの関心が薄れてきて、高凝集で疎結合かつ SOLID 原則に基づいたモジュール分割ができていればそれで良いというシンプルな考えかたでコードを書くことが多くなった。おそらくこのあたりの考え方は以前に読んだ A Philosophy of Software Design の影響が強い。

プライベートではもっぱら Go を書いていることが多い。もともとプログラミング言語自体にあんまり関心がないので、自分がやりたいことをシンプルに記述できる言語である Go ばかり使っているし、今後も使い続けると思う。
趣味のプログラミングではバックエンドだけでなくフロントエンドも書くことが多かったので、JavaScript や TypeScript もよく使っていた。最近書いていたアプリケーションでは TypeScript、Vue.js、Nuxt.js、Apollo GraphQL あたりを使っていた。このあたりの技術はかなり Developer Experience が良くて好き。

執筆

Software Design へメルカリ・メルペイエンジニアが寄稿している連載の一環でゴルーチンとチャネルについての記事を書いた。普段の業務でゴルーチンやチャネルをそのまま扱うようなコードを書くことがあまりないため、自分自身にとっても良い頭の整理となった。また、自分が Go を学習しているときに読んでいた、プログラミング言語 Go を読み返してその内容の深さに改めて驚いた。

個人ブログではあまり多く執筆できなかった。ちゃんと意識していないとどんどん書かないようになってしまうので些細なことでもしっかりまとめてアウトプットしていけるように心がけたい。

イベント登壇

Merpay Tech Fest 2020 で登壇する予定だったが、新型コロナの影響でイベント自体が中止になった。12 月に Software Design へ寄稿したメルペイメンバーによる座談会で話したりはしたものの、今年はイベントで登壇することがほとんどなかった。リモート開催のイベントでスピーカーになる意欲はあまりなく、今と同じ状況が続くのであればしばらくは登壇することはないだろうなと漠然と感じる。

OSS

引き続き Evans や go-fuzzyfinder のメンテナンスをしていた。ただ、Evans へ新しく機能追加するモチベーションがなくなってきているので、v1 を見据えてそろそろ Evans の今後をどうするか考えないといけないなと漠然と感じている。go-fuzzyfinder については、利用してくれるツールが増えてきていたり、コントリビュートしてくれる人が増えてきているのでとても嬉しい。インターフェースのシンプルさがかなり気に入っているので、このシンプルさを保ったまま継続的に改善していければ、と思う。

自作 OSS の影響で自分が知っているツールを開発している企業からリファラル DM が飛んできたり *2、自作 OSS を紹介している記事が増えてきたりしていてとても嬉しい。自分がつくったものが実際に使われているのを目撃するとやっぱり嬉しいし、頑張ろうという励みになる。

自作 OSS 以外へのコントリビューションは、普段利用しているライブラリやツールのバグを見つけたときに行うことが多かった。GCP の Go ライブラリや Datadog APM の Go ライブラリ、protoreflect など。思ったより少なかったのでもう少し OSS のコードを読む量を増やしていきたい。

GitHub Sponsors では去年に引き続き 4 名もの方から支援をいただいていて、とても励みになっている。支援に見合うだけの動きができるように努力したい。

読んだ本

技術書

  • Database Internals
  • Istio: Up and Running
  • Microservices Patterns
  • OAuth徹底入門 セキュアな認可システムを適用するための原則と実践
  • Kubernetesで実践するクラウドネイティブDevOps
  • 人月の神話

かなり少ない…。月に最低一冊くらいは読んでいきたい。

ビジネス書

どちらもかなり読み応えのある本だった。Winny については金子勇自身が書いた本も読んでみたい。

ルポルタージュ

  • サカナとヤクザ: 暴力団の巨大資金源「密漁ビジネス」を追う

知らないことだらけで面白い。

哲学書

  • 愛するということ

哲学が好きなので引き込まれた。また読み返したい。

漫画

サマータイムレンダ、ランウェイで笑って、進撃の巨人が特に面白かった。

旅行

本来であれば草津や、毎年恒例の ISUCON メンバーでの旅行など、もっと多くの旅行をするつもりが新型コロナによって大きく予定が狂ってしまった。来年は少しは落ち着きますように 🙏

沖縄

閑散期である 1 月に行った。航空券は往復で 8000 円程度と非常に安くなっていた。また、大学の友人らと行ったため Airbnb で一軒家の宿を借りたところ、広々とした綺麗な家で大満足だった。アメリカンビレッジへも徒歩で行ける距離だったので夜ごはんや飲みのために繰り出したりできて便利だった。

京都

Go To トラベルが適用されていた 12 月の第一週に行った。東京 ⇔ 京都の新幹線往復券 + 一泊で 15000 円に加え、地域共通クーポン 3500 円分、京都タワーでもらえた謎の商品券 1000 円分が加わり実質 10500 円程度という異次元の安さだった。ちょうど Go To トラベルを停止するべきという声が大きくなっていた時期だったのもあり、人出は思った以上に少なくなっていた。特に清水寺二年坂あたりは普段であれば尋常じゃない人がいるのに、今回は周りを気にせず歩けるくらいに人が少なかった。また、はてなインターン同窓会ぶりにカマルへ行けたので良かった。

f:id:ktr_0731:20201229133301j:plainf:id:ktr_0731:20201229133305j:plainf:id:ktr_0731:20201229133453j:plainf:id:ktr_0731:20201229133306j:plain

観たアニメ

あんまり観た記憶がなかったけど、履歴を元に洗い出したら結構な数のアニメを観ていた…。テレビアニメだと思い出補正もあるだろうけどイエスタデイをうたってが特に良かった。劇場アニメだと千と千尋の神隠しを除くと SHIROBAKO が最も良かった。観ると仕事を頑張ろうという気持ちにさせてくれるようなアニメだし、制作陣がやりたいことをやっているのを感じられて良かった。円盤も買ったので年明けが楽しみ。千と千尋の神隠しは最も好きな・影響を受けたアニメーション作品なので、今の時代に劇場で観れたことが本当に嬉しい。

やったゲーム

十三機兵防衛圏はかなりストーリーが難解で、かなり後半にならないと全貌がわからなかったが、伏線が張り巡らされていてとても面白かった。Detroit: Become Human は今年やったゲームのなかで一番面白かった。*3 哲学的な面も多くあるのでこういった近未来 SF はとても惹きつけられたし、ゲームシステムも独特で常に映画を観ているような臨場感があった。コナーとハンクの関係が好きすぎる。

人生

父方の祖父が亡くなった。きわめて身近な人の死に触れたのは初めてだったのでとても哀しかったし、家族や自分自身の死を考えてしまって改めて死への恐怖を感じるようになってしまったのとともに、日常の変化からだんだんと身近な人の死が近づいてくるのが感じ取れるようになってしまって苦しい。人間いつかは死ぬものの、今は死ぬのに未練がありすぎるし早く電脳化したい。

終わりに

今年は新型コロナによって生活が大きく変わり、常識だったものがそうではなくなってしまった一年だった。その影響で苦しいことが増えた一年だったものの、嬉しいことや楽しいこともまた同じように感じられた一年でもあった。WFH をしていると変化のない日常が繰り返されているかのように感じてしまうので、来年はいろいろな変化をつけられるような年にしていきたい。


去年

syfm.hatenablog.com

*1:とはいえ必ず実行計画を見るべきだけど…。

*2:今の所転職するつもりはないので断った…。

*3:そもそも本数が少ないけど