仕事
はてなブログ タグ
initial commitの日付が1年くらい前だった。ほぼかかりきりだったので1年以上やっていたことになる。
上から下まで本当にいろいろやれて良かった。要素技術やらキーワードを挙げ連ねると:
……などなど。引きの良いものが並んでいるけど、単に映えることだけを考えて挙げたり選んだわけではなく、必要とされるものや過去の反省を活かして最適な選択肢を模索した結果、これらが妥当と判断したので、すべての要素について選んだ根拠を自信をもって説明できる。 また、矛盾するようだけれどもすべてが最適だと考えているわけでもなく妥協した点や今後より良い選択肢が出そうな点についても心当たりがある。そういったリスク含めて説明できるし責任を負えると判断して作れたのは良い経験だと思う。
一方、こうした判断の壁打ちの機会が特に初期は乏しかったので、後から加わったメンバーからツッコミはなかったものの、それは既にできあがったからじゃないの、っていう疑念が無いでもない。 別にチームメンバーからのフィードバックを信用していないわけではないけれど、なんとなくこういうことって「便りのないことは元気な証拠」とも言い難い側面があるなあと思うので不安になっているだけだと思う。
たぶん今、自分が最も困っていてかつ解決すべきなのは、チームでお山の大将に限りなく近付いていることだと思う。自分の考えを理詰めで整理して伝えることが得意だと自負しているが、それが「なんか違う気がする」くらいの指摘を呼ぶ素地が無いように見えているんだと思う。 別に自分が受ける批判・指摘の全てに一切の瑕疵があってはならないなんて思っていないけれど、普段チームを引っ張るような役割の人間が常に75点くらいの仕事をしていたら、50点くらいでも赤点のような気がする、って周りに思わせてしまうっていうのは人の心として理解はできる。
じゃあ仕事の面で自分も甘さを見せれば良いのかというとそうではない気がするし、そうだとしてもかなりやりたくない。一辺倒では解決できない問題だと思うので、気長にトライアンドエラーしていくことになると思う。
テックスキルとしては、デザイナーとAtomic Designの落とし込みやJSSの選択について初期にかなりがっつり会話できたのは良い経験だった。あれこれ比較して当初から本命だったstyled-componentsに落ち着いたものの、比較検討できたことで選択に自信がついた。
そういったフロントエンドに近いところから始まり、インフラ設計はほぼひとりで、構築は後から加わったSREと一緒にやった。VPCなどネットワーク設計より上のことは一通りやったし、だいたい勘も付いた。
カメラマン
他社もインタビューコンテンツに力を入れている中、何がフックになるかといったらTwitter Cardsとかに出てくるサムネイルが大きいんじゃないかと思い、写真係やりますよって言い出して長命なシリーズになっている。
プロの方が絶対に腕は良いけど、小回りが利くことは強みではないか。
登壇
仕事関係が2つ、完全な趣味が1つ。数は少なめだったけど、仕事の方はまだ出せそうなネタがいくつかあるのできっちり出しておきたい。
趣味のほうは、リメイクということで個人的にはちょっといただけない感じがするものの、動くデモが作れたのでトントン。
ソフトウェア
わりと仕事でやっているプロダクトで必要になったので書いてOSSにした、っていうのが多い。
go-http-replay
Go版vcr
「外部APIにアクセスするテストを書く時にスタブをしたいけど、手作りするより本物のレスポンスを使いたいよね?」「でもいちいちcurlして保存して……はだるいよね?」 → じゃあ初回だけ実際にリクエストして、そのレスポンスを保存して使い回そう! というライブラリ
Goには httputil.DumpResponse / httputil.ReadResponse っていう便利グッズがあるのでこれを使っているだけ。
http.TransportというPerlでいうLWP::Protocol的なやつを差し替えるだけでやっている。
72行くらいしか無いけど、Goのnet/httpのおもしろさが詰まっていると思うので気が向いたら読んでみてください。
go-envschema
環境変数はJSONのobjectと見なせるやん? だったらJSON Schemaで検証できるやん? という発想によるライブラリ。
詳しくは 大コンテナ時代を生きのこるためのJSON Schema
go-dsn
TypeScriptで書いたオブジェクトを https://github.com/go-sql-driver/mysql のDSN (Data Source Name) 文字列にするNPMパッケージ。
AWS CDKでRDSのhostname/portを結合してコンテナの環境変数に渡すために作った。
cdk-mackerel-container-agent
CDKで書いた TaskDefinition にmackerel-container-agentをsidecar containerとして良い感じに差し込むグッズ。
mackerel-container-agentが対応している環境変数などをいちいちドキュメントを見に行かなくてもIDEで補完してくれるようにという目的で書いた。
ベータ版の頃はクラスタがFargateとEC2かによって設定の感じが変わるのでまあまあ賢いコードが書いてあったけど、今は単にデフォルト値を与えるくらい。
CDKがDeveloper Previewのころからライブラリにしていたので毎週のbreaking changeでスナップショットが壊れては仲間たちが丁寧に jest -u してくれた思い出のライブラリです。
action-aws-assume-role
GitHub Actionsで使えるaction.
文字通り AssumeRole して得られたsession tokenやらを環境変数にexportするグッズ。
gqlgen-tracer-xray
gqlgenでAWS X-Rayのトレースを良い感じに取るプラグイン。ほとんどopentracing版を真似しただけ。
migrate-gh-repo
2つのGitHubリポジトリでissueやらラベルやらを移行するスクリプト。
似たようなツールはいろいろあるけど、ほとんどべき等になっているところとあまり賢くないが故に柔軟性が高いのが売り。
古いリポジトリのissueへのリンクを残すだけの仕様になので、たとえば複数リポジトリを1つのリポジトリへmonorepo化しつつ移行する場合にも、同じissue numberにコメントでリンクが書き連ねられるだけなので、N:1の移行も問題なくできる。
技術的には設定にCUEを使っているのがおもしろポイント。
総括
仕事に全振りした1年だった。それなりに得るものもあったけど、どうしてもやったことが仕事の文脈だけだとおもしろみが無いなあと感じてしまう。 来年は文字通りの意味でワークライフバランスの良いおもしろ技術探索をやっていく。
