Posts for: #2022/04

テックブログを更新した

23時に寝て1時に起きて3時に起きて7時に起きた。

ストレッチ

今日の開脚幅は開始前162cmで、ストレッチ後163cmだった。先週より少し数値がよくなった。相変わらず背中や腰の張りは強くてストレッチしてもらっていてなかなか辛かった。昨日は祝日だから早めに切り上げてゆっくりしてたし、ワクチン接種後というのもあるけど、最近は睡眠時間を多く取るようにして安静な生活を送ってたりする。それでもどこかしら張りがあったりする。ストレッチを受けると毎日座ってお仕事をすることの負荷を実感できる。

今日で1年以上ストレッチをしていただいた トレーナーさんが転勤 で最後。おかげで私は健康に過ごせているので感謝しかない。新しい環境でも活躍してほしい。来週から新しいトレーナーさんになる。それはそれで相対比較ができるのでトレーナーさんの違いもわかると思うから楽しみ。

コミット連携機能の紹介

少し前に対応したんだけど、backlog-github-integration-action でコミット連携ができるようになった。

そのことをブログの記事にも書くことにした。1時間もあれば書いてしまえる内容なのに英語で書くというだけで後回しにしてしまう。私は英語を書くときは GrammarlyDeepL を使って書いている。自分の言いたいことを Grammarly で構文チェックしながら書いて、それを DeepL で日本語訳して意味がとれるかどうかで内容があっているかの確認をするといった感じ。

第3期のふりかえり

23時に寝て5時に起きた。本当は夜に打ち合わせの資料を作らないといけなかったが、なんかだらだらやってそのまま寝て朝起きてから資料を作り始めた。今日は祝日だから業務委託のお仕事は完全に休むと決めた (非稼働日もデイリースクラムには参加するし、なんだかんだで軽いチケット整理や作業などはしている) 。その分の余裕が資料の作成を先延ばしにした気がする。

隔週の雑談

顧問のはらさんと隔週の打ち合わせ。今日の議題は会社の第3期 (前期) のふりかえりにした。半分ぐらいは資料はできていたものの、5時半ぐらいにはオフィスに行って6時過ぎから残りの部分を作り始めた。8時前には完成した。いつもは2-3日前には資料を提示するようにしていたが、今日は祝日でだらだらモードで1時間前 (打ち合わせは9時から) となった。はらさんも直前で資料に目を通してもらったが、こういうのはよくなかったと後で反省した。

資料を作っていて、ふと思い浮かんだ気づきの1つをあげる。

会社の銀行口座と自分の銀行口座残高がダブルでただひたすらに減額しているさまを見るのって普通にメンタルに良くないんですよね。しかも事業も全然伸びていきませんし…。

ソフトウェアエンジニア社長として起業してから会社清算するまでの4年間の振り返り (完結編)

前期は3ヶ月ほど仕事をせずに遊んでいた。数字だけをみたら6ヶ月ほど遊んでいてもよい余裕はあったと言える。それでも3ヶ月ほど経ってから次のお仕事を探して、いま受託開発をしているのは 銀行口座の残高がダブルで減り続ける恐怖に抗うのが難しい からと言える。会社が倒産するわけでも、生活に困るわけでもなく、銀行口座の残高が減り続ける毎日が怖いという話し。「死の恐怖は死そのものよりも怖ろしい」と誰かの名言があるが、その経営者バージョンかもしれない。難しい判断は心身ともに落ち着いていて余裕をもった状態で下すのが望ましいと、誰もが頭では理解できるだろうが、実際に銀行の口座がずっと減り続けている状態でそう在れるかというのは別問題だという話し。無計画に仕事せずに遊ぶのは、うちの会社の場合は3ヶ月程度が限界だと分かった、というのが今期の財務における収穫と言える。

そんな1年を通したふりかえりを雑談してたら2時間ほど経過していた。また2週間後に第4期の展望をやることにした。

jvm の脆弱性対応

23時に寝て3時に起きて5時に起きて7時に起きた。なんか調子が微妙。

jvm の脆弱性対応

少し前だけど、jvm のセキュリティアナウンスがあった。

java 11 向けの docker イメージのビルドはあまり緊急度が高くなかったせいか、17よりは優先度が低かったようにみえる。docker イメージビルドの作業状況は次の issue で管理されている。

これまで adoptopenjdk/openjdk11:alpine-jre という docker イメージを使っていた。Transition to Eclipse - An Update によると、Eclipse Temurin という組織が管理する Adoptium というプロジェクトに移管されたらしい。この機会に docker イメージも eclipse-temurin:11-jre-alpine に移行した。

障害調査と先入観

23時に寝て5時過ぎに起きた。

インフラの不具合調査

本番環境に初回デプロイして ecs から secrets manager のアクセスに失敗しているエラーが出ていたので調査した。エラーメッセージでググるとクラスメソッドさんの記事が出てきた。

この記事によると、次のどちらかの原因かなと推測していた。

  • 実行 IAM ロールの権限不足
  • SecretsManager エンドポイントへの不到達

調べども調べどもテスト環境との違いがわからなくてはまってしまった。ある検証をしていたときに、テスト環境を手動で構築した担当者から datadog の api key を設定してないんじゃない?と言われて、まさにそれが原因だった。cdk のコード上は設定済みのものとして ecs の datadog のサイドカーに設定していた。先入観で rds の credential 情報を取得できずにエラーになっていると思い込んでいたが、サイドカーの datadog の api key が原因ではまるべくしてはまったという感じ。

一方で secrets manager に登録するサードパーティの api key をどこで管理するかというのは難しい問題でもある。cdk のコードの中に書いてしまうというのも1つのやり方ではあるが、昨今の github 関連のサードパーティから派生したセキュリティインシデントで private リポジトリのソースコードにアクセスされることも発生しているのでソースコードには書きたくない。で、手動で secrets manager に設定しないといけないから、今回みたいな初回デプロイ時に誰も気付かないみたいなことが起きる。

開発は生きもの

0時に寝て5時過ぎに起きた。

事例紹介

いまやっているお仕事の事例紹介の承諾をいただいたので掲載した。感謝。この事例紹介は私の自己満足なところも大きい。世の中に対して自社が貢献しているということを再確認するための手順の1つと捉えている。もちろん複合的に宣伝にもなるので自社にとってメリットもあるが、それ以上に自分に向けて書いているという思いがある。それはこれまで私にとっての、意義のない開発をし経験から、そういうお仕事はしないようにしようという戒めでもある。これまで組織の論理が自分の想いや方向性とズレてしまったときに退職してきたが、業務委託だと契約を終了できるので転職するよりは補正しやすいという側面もある。

ふりかえり

スクラムのふりかえりで pull request のルール適用による成果について共有した。ルール適用前まで pull request のレビューに正社員のレビューを必須としていた。開発チームは協力会社主体であり、正社員は1人しかいなかった。そのため、レビュー負荷がその正社員に集中し、その人が多忙だと pull request のレビューが2-3日停滞するというのが常だった。そこで協力会社の approve でもマージできるような条件を設定したり、そもそも approve を必要としない pull request の条件を追加したり、pull request を作らずに main に直接コミットしてよい内容なども作った。ルール適用の前後で1ヶ月間のチームの平均値を比較した。

その結果、findy teams の pull request の作成からクローズにかかる時間が30%に短縮された。3倍近くクローズが早くなった。私個人の「1プルリクあたりの平均マージ・クローズ時間」においても 14.7h → 4.1h に短縮された。平均で1日待たないと approve をもらえなかったのがその日中にもらえるようになったと言える。ふりかえりで成果を共有したところ、わりと成果の大きさに驚かれたのに私が驚いた。経験が浅いチームの当たり前には価値基準や手順などに乖離があるんだろうなと思えた。私にとっては当たり前のことをやって、当たり前の成果が出て、当然こうなるって話しでしかないのだが、開発を数字でしか把握できない人たちにとっては斬新にみえるのかもしれない。

本番環境反映の監督

昨日は思いっきり昼寝してしまったせいか、夜に眠れなくて3時ぐらいまで起きてて、寝たのか寝てのかよくわからない雰囲気で7時前に起きた。

インフラ作業の本番反映

先週対応した api gateway のコード化 を本番環境に反映した。手動で作成されていた api gateway, vpc link, セキュリティグループとそれに関連するリソース群を cdk 管理のコードで置き換える。既存のリソースを削除してから cdk でデプロイするため、失敗しても切り戻しできないのでプレッシャーがかかる。とはいえ、想定通りに作業が進捗して2時間ほどで完了した。それと並行してテスト環境では、手動で作成された rds を cdk 管理のコードで置き換える移行作業をしていた。これも一筋縄ではいかなくて右往左往しながら作業してた。これを本番環境でやるのもまた億劫だなぁと思いながら発生したエラーや事象を書き綴っていた。あと本番環境で行う大きな移行作業はこれだけ。

個人開発楽しい

0時に寝て7時に起きた。朝から雨降りだったのでだらだらしながら家を出たけど、オフィスに着いたのは9時頃だったと思う。午前中にコードを書いてテストして、それからお昼ご飯食べて、家に戻って、ちょっとゆっくりしてからオフィスに戻ろうと思ってたら3時間ほど寝てた。

backlog のコミット連携の反応

たまたまツィートしていたらこみやさんが関心をもってくれた。fix, close などでチケットのステータスを変えたいという要望をもらったので作ることにした。

3時間ほどとわりとすぐに実装できた。いまのプロジェクトでは使わない機能なので当初は乗り気ではなかったけど、やっぱり使いたいという人がいると開発のモチベーションになる。

機能拡張して、テストしたり、ドキュメント書いたりしてた。github discussions も積極的に使ってみようと思っていてちょっとした faq も書いてみた。

1-2週間ほど試験運用して問題なさそうだったら v1 のタグをつけて marketplace などに公開してもよいかもしれない。ブログにも書かないとな。まだまだタスクは残っている。

個人開発の日

0時に寝て6時に起きた。午後から昨日作った機能拡張のテストをしながらコードの修正やテストコードを追加したりしていた。

ストレッチ

今日の開脚幅は開始前161cmで、ストレッチ後161cmだった。先週はワクチン接種後にダウンして寝込んでいて数値が悪かったのが元に戻った感じ。それでもまだ復調にはいたらないのか、右の肩甲骨が硬いのと腰の張りもすごかった。3月からずっとだらだらした生活を送っているのでもうちょっと生活をびしっとしないといけない。インフラエのお仕事を引き受けてから深夜早朝に作業する機会が増えて生活のリズムを崩しているのもあるとは思う。歳をとって体調がよくない日が増えるという話しを聞いたけど、私もストレッチを始める前はそうだったような気がするけど、毎週ストレッチに通うようになってからそういう印象が解消した。もう1年以上通っているから間違っていないと思う。毎週どこそこが悪いといったことも書いたりはしているけど、それはストレッチをする上でのよくないところや前週よりも成果が出ないところの話しであって、日常生活を送る上ではまったく影響はない。ストレッチは正義。

Go Conference 2022 Spring Online

ストレッチを終えてから Go Conference 2022 Spring Online に参加した。いくつか発表を聞きながらコードを書いたりもしていた。一番よかったのはたいちさんの DBアクセスライブラリkra の発表かな。taichi/kra というライブラリも知らなかったので機会があれば今度使ってみようという気になった。私も sql 好きだし、orm の弊害の話しも共感できてよかったと思う。orm 使うなという話しではなく、それぞれの用途にあわせて使い分けたい。

カスタム action の開発再開

22時に寝て0時に起きて3時に起きて5時半に起きた。

ワーケーションのリトライ

オミクロン株の流行で延期していた開発合宿を行う。レンタカーと きのいえ の予約を6月3-5日で確定させた。3回目のワクチンを接種したばかりだし、世の中の雰囲気も with コロナへの取り組みになってきている気がする。行き先は同じなので前回作った旅のしおりをコピーしていくつか修正しながら再計画していく。Go To トラベル 再開が6月ではないかという噂もある。

backlog-github-integration-action の機能拡張

先日作った backlog-github-integration-action に push という新たなサブコマンドを追加した。コミットをリポジトリに push したときのイベントをフックしてカスタム action を実行する。インプットが github から取得できるデータになるため、GitHub Events 単位にサブコマンドを作ればトリガーと扱えるインプットデータが一致してわかりやすい機能分割になるんじゃないかと思えた。ひとまずそれでやってみる。今日のところはローカルで動かしてコミット連携ができることを確認して、いくつかテストを書いていた。また明日、結合レベルのテストをやってみる。

rds の再作成

23時に寝て5時半に起きた。久しぶりによく眠れた気がする。

rds を独立したスタックに分離

昨日の続き。ライフサイクルにあわせたスタックに分割し、スタック間の依存関係を適切に定義することで堅牢なインフラコードになる。最後に残った DatabaseStack を分離するところを朝からやっていた。

  • DatabaseStack
    • BackendStack
      • GatewayStack
        • FrontendStack

rds を壊して、バージョンを aurora postgresql 最新の 13.x にアップグレードして、cf のテンプレートで小細工をしながら既存の環境を移行したりしていた。pg_dump を使ってテキストに dump したデータを、psql を使ってリストアしたりもした。データ量が少なかったらこれで移行してもいいかもしれない。

$ pg_dump --host mydb.xxx.ap-northeast-1.rds.amazonaws.com --username user mydb > mydb.dump
$ psql --host mydb.xxx.ap-northeast-1.rds.amazonaws.com --username user --dbname mydb --file ./mydb.dump

堅牢なインフラコード

23時に寝て5時に起きた。

駐輪場の定期更新

3ヶ月ごとの更新。ちょうどいまのお仕事の契約と同じ更新月になっている。前回と同じ金額だったのでまだ駐輪場の料金は値上げされていない。世界的にインフレしているのに日本が全然インフレしていない理由の1つとして不動産が値上げしていないからというのを日銀の記事で見かけた気がする。どこかのタイミングで不動産関連の値上げも始まるのかもしれない。

インフラコードの抜本的リファクタリング

約2週間かけて、新規インフラ環境の構築、既存インフラの cdk/cf と同期されていなかったインフラ (rds, security group, croudfront, api gateway, waf) の同期など、インフラコードの大きな変更をやり終えた。一部 fromLookup でインポートしているリソースもあるが、いま完全に cdk/cf 管理なインフラとなった。ここからはせっかく cdk でコードを書いているので、モジュール化や共通化など、再利用可能なリソースとして定義して、複数の Stack でコードを再利用するといったリファクタリングをしていく。ひとまずこのことをボーナスステージと呼ぼう。いま完全に同期されたインフラがあるため、インフラ上のリソースの差分が出なければリファクタリングは正しいことが保証される。cdk は Stack 間の依存関係 も定義できるため、適切な依存関係を定義することでより堅牢なインフラコードとなるはずである。具体的には次のような依存関係になる。然るべき堅牢なインフラコードに書き換えていく。

  • DatabaseStack
    • BackendStack
      • GatewayStack
        • FrontendStack