フットレスト導入した
ここ数ヶ月は終業後に下半身からくる怠さを感じるようになっていて、どうやらデスクで座っていると太もも裏が圧迫されて血流が悪くなっているらしかった。終業後にランニングや懸垂をするルーティンだったのだが、この怠さがあると足が重くてどうにも出かける気になれない。
昇降式デスクでたまに立ちあがると少しは楽になるのだがずっと立っているわけにもいかず、座っている間はダメージが蓄積するデバフがある。これは着席中のダメージを減らさないといけないと思いフットレストを導入した。
選定基準
特にこだわりもないのでネットで検索して決めたが、比較検討する中でいくつか思うところはあった。
- デスクチェア側で調整できるので段階調整はいらない
- たまに裸足でも使うことがあるので金属とかの冷たい素材はNG
- カバーを外して洗濯したい
感想
導入してから2週間ほど経過した。振り返ればここ1週間は終業後に運動をする気力が残っていたので、本来の目的であった血流改善にはなんらかの効果があったような気がしてきた。
ちなみにどのあたりが人間工学デザインなのかはよくわかっていない、低反発枕みたいな感じで踏み心地が良いあたりかもしれない。裏返した状態で足首を動かすのも悪くない。
ただの台なのでもっと安くてもいいのでは...という気持ちは正直あるが、血流問題だけでなく、深く座って背筋を伸ばす正しい姿勢を維持しやすくなったこともある。おかげで腰痛や肩こりも最近は軽減されているように思い始めたので、良い買い物だったと信じていく。
『ビジネスも人生もグロースさせる コミュニティマーケティング』を読みつつEM Meetup運営を振り返る
ruby-jpで紹介されていて気になったので読んでみた。本の著者はAWSのコミュニティマーケティングを長年手掛けており、JAWS-UGという馴染みあるコミュニティの実例が数多く紹介されていそうだったのも本を手にとったきっかけでもある。
BtoCサービスを運営する企業で働いているのでマーケティングをかじっても損はないだろうという気持ちで読み始めたが、ミートアップを主催していた者としてはコミュニティ運営者目線で共感できる箇所が多かった。
タイトルの「ビジネスも人生もグロースさせる」がなんだか鼻につくので無いほうが硬派で好きだし紹介しやすいのにと思ったりもするが、新書のマーケティング的には仕方ないのかもしれない。
コミュニティマーケティングとは
まったく知らなかったので改めて整理すると...
製品のファンと呼べる人たちをコミュニティ化することによって、新たな顧客を獲得していくというマーケティング戦略のこと。「コミュニティに売る」のではなく「コミュニティを通じて売る」のが基本。
この文脈においてコミュニティは集まった人が情報を発信・拡散するコンテンツ生成装置（Contents Generator）となる。集まることが目的ではない。
マーケティングでもっとも難しいのは製品を「自分ゴト化」させるところ。マスマーケティングやマス広告はターゲットにリーチできるが、自分に関係があると思ってもらえるかどうかはクリエイティブ次第。一方、コミュニティマーケティングではコミュニティが製品について「自分ゴト化」できる目線で発信・拡散する。この活動がチャーンレート（解約率）を下げ、LTV（ライフタイムバリュー＝顧客生涯価値）を上げていく。
インフルエンサーマーケティングとの最大の違いは、強いメッセージが育つ仕組みと持続性があること。影響力のある人なら一時的には効果はあるが自分ゴト化するメッセージを長く発信してくれるわけではない。
身の回りの実例
JAWS-UGでのコミュニティマーケティングはAWSからできたわけではない、他の会社や事業にも再現性がある、というのは本書中でも強調されている。
これまで意識してこなかったが、確かにコミュニティマーケティングの実例は身近でもいくつか挙げられる。どれも成功事例かどうかわからないが。
GitHub CommunityやCircleCI Discuss、Monzo Communityのような完全オンラインのコミュニティ。オフラインではminneハンドメイドマーケットとか、スタディサプリ合格祝賀会のような自分にとって身近なものが思い浮かんだ。
気になったポイント
完全オンラインでのコミュニティ形成は成立するか
優れたコミュニティは、「わかっている人が、わかりたがっている人に話をしている構図」 なのだということでした。説明してもムダな人には、時間をかけないのです。だから効率がいい。わかりたい人に、わかっている人が説明する場こそ、つくるべきコミュニティ
ここで語られているような優れたコミュニティになるには、本書にあるようにオフラインでの繋がりが一定重要に思う。
オンラインだったから、と一概に言えるものでもないが... 2021年に終了した某フリマアプリのコミュニティサービスは運営にだいぶ苦慮したようで、サービス終了後も5chのスレなどから当時の様子が伺えた。匿名のオンラインでスタートし、先鋭化・過激化してしまったコミュニティを軌道修正する術はあるのだろうか。
フィードバックのうまい扱い
フィードバックを聞きたくない、という人や会社にある大きなバイアスの一つは、「聞いてしまったらすぐに対応しなければいけない」という思い込み です。しかし、実際は「今すぐできない理由」をきちんとコミュニケーションすればいいのです。
このコミュニケーションが通じるのは信頼関係が前提であり、そこが破綻しているといかに建設的な理由も聞かれないのでは、と思う。1対1では話せばわかることも1対多では通じない、ということもよくある。
顧客との信頼関係構築にあたってまず1つや2つぐらいはフィードバックを受け入れてしまおう、という避けがたい引力がありそうだ。
向いているビジネス
初速が必要なビジネスには、コミュニティマーケティングは向いていません。コミュニティマーケティングの「自分ゴト化」にはそれなりの時間がかかりますし、そこには「真実の声」がないといけないからです。 そして、聞いた人が本当にこれをいいと思わないと、次には伝えていかない。
この点以外にも色々適性はあると思う。
たとえば家電やハードウェアのように物理的な製品の場合はフィードバックを取り入れ改善するサイクルがソフトウェアに比べて長くなりがち。そのような製品だとコミュニティに話題を定期的に持ち込むのが難しくないか、とか。
他には映画やアトラクションのようなエンタメ系のサービスはどうだろう。体験直後は自分ゴト化できていても風化するので生活に根付くわけではない...と書いたがディズニーという圧倒的なレベルでできている例もあった。
日常的に長く使う x ないと困る x 高いアップデート頻度 ...あたりのサービス特性は適性が高そう。
コミュニティ運営全般に言えること、EM Meetup振り返り
僕はEngineering Manager Meetup（以下、EM Meetup）というコミュニティを2018~2020年のあいだ約2年ほど運営していた。connpassのグループ参加者は1,300人超で、野良コミュニティにしてはまあまあ多くの方に興味を持ってもらえたと思う。（過去形なのは、個人での運営を手放してコミュニティに引き継いだため）
EM Meetupは特定企業や製品のマーケティングとしてやっていたわけではないので本書の趣旨とはいくぶん異なるが、このコミュニティ運営において僕が意識したことや、振り返ってみて大事だったと思う点を同書にも見ることができた。とりわけ手探りで実践したことが良しとされているなど、数年越しに"答え合わせ"ができたのは嬉しかった。
初期のメンバーが大事
「いいコミュニティは情報を発信していくことが自分自身のプラスになっていく、というメリットに最初から気づいている人たちが中心」とあったが、これはEM Meetupで強く実感したことだ。
初回の開催メンバーにも恵まれたおかげで開催前〜終了直後にTwitterで感想が拡散され、参加できなかった層に勝手にリーチしていき、すぐに第2回を企画しなければという"需要"と"手応え"を感じたことを覚えている。
情報発信がプラスだという風土をつくる
コツが「アウトプットファースト」です。クラウドはいいね、という人たちが集まってきて、そこだけで盛り上がっていても仕方がありません。 (中略) 声が外向きに出ないといけない。 「よかった」というツイートでもいいし、ブログでもいい。それらが外に伝わるように表現してもらう。そうでなければ、肝心の熱量が外向きになりません。
EM Meetupではプレゼン形式でもOSTでも感想・意見をtweetしてもらうようしつこくお願いし続けた。登壇者や参加者同士でオープンなフィードバックを送りあうことでよりコミュニティが活性化し、モチベーションを高く保つことが第一義だと思っていたが、このムーヴがコミュニティのマーケティングにも寄与していたようだ。
また、EM MeetupのSlackワークスペースを作り、ミートアップ以外の場でもアウトプットや交流をできるようにしたことで、その場限りではなくゆるく長くつながる"コミュニティ"になっていった、というのも肝要だったように思う。
運営に巻き込む
コミュニティ経験者は、新しいコミュニティにも進んで運営側にまわる人が多いのです。ＡＷＳのコミュニティでも、そういう人が多いですね。 そして、すぐに仲間を集めて負荷分散を図る。ひとりでやるより、複数人でやるほうがコミュニティの開催頻度も上げられ、テーマの幅も広く、深くすることができる。なにより、コミュニティの成長速度が速くなります。
ここは出来ていた面とそうでない面がある。
コミュニティは、リーダーだけを見つけても仕方がなく、 どうやったらフォロワーが集まるようになるか、が重要なのです。 ですから、コミュニティづくりをサポートするとき、極めて大切なのは、フォロワーの候補者を集めるために、コミュニティマネジャーやコミュニティマーケターが手助けをして、リーダーとフォロワーの関係性を最初からつくっていくことです。
EM Meetupでは初期から早々に運営を手伝ってくれる方々が現れ、非常に助かった。エンジニアリングマネジメントに関心のある人が集まっていることもあり、信じられないぐらいサポーティブでフォロワーシップの強い方々と動くことができたので一切の不満がなかった。個人的には慣れないイベント運営をたくさんサポートいただけたことで主催としてしっかりやっていこうというモチベーションにもつながった。
しかしながら、イベントの運営をずっとコミュニティに移譲せずにいたため効率的にイベントを供給できなかったという反省もある。個人の忙しさやモチベーションに依存して開催頻度が変動してしまい、「もっと頻繁にやってほしい」「次はいつですか」という声に応えられないこともあった。
マネジメントの成果はそうそう短期には出ないので、1~2ヶ月の間隔で開催しても自身が進歩や成長を感じられないままであったり、実践の機会がなく、抱える課題意識が変わらないままミートアップを重ねるとループしている気分になる。そういったタイミングでは自分抜きでコミュニティに開催してもらえばよかった。
コミュニティとの向き合い方
最後に、運営側ではなく個人としてのコミュニティとの向き合い方について。以下の内容には100%同意できる。
おすすめするのは、コミュニティに加わったら、 積極的にアウトプット（発信）側にまわること です。常に「ギブ」することを考える。そうすれば、自然にまわりに見つけてもらえるようになり、インプットや引き合いも増えていくからです。 たとえば、コミュニティに１００回参加するよりも、１回の登壇が効果を発揮します。自らアウトプットすることが、より良質なインプットを得ることにつながっていく。登壇すれば、すでに自己紹介が終わった状態で懇親会やネットワーキングにも参加できるので、まわりの反応が得やすく、相当有利な状況にある （太字は当記事著者によるもの）
2018年に実践を通じてこのことを学んだ。
いろんなところに顔を出すの面白いと思ってJS ConfやiOSDCなど専門外の領域で登壇したりもしたが、やはり「自分がオーナーシップを持てる」コミュニティや場に参加していくのがコミュニティにとっても自分にとっても最良の結果を得やすいし、持続しやすい（本書でいう「自分ゴト化」）。
本の感想文を書くつもりだったが過去の振り返りになってしまった。
記事冒頭でタイトルの「ビジネスも人生もグロースさせる」に文句を付けたりしたが、実際にコミュニティ活動が僕の人生やキャリアに大きく影響を及ぼしているし、まったく外しているわけでもないな、と思い直した。
ビジネスでのマーケティング実践についてはエアプなので何も言えることはないが、もしこれからコミュニティを形成したい人や会社のブランディング・採用活動等に関わる人にとっても何がしか得るものがある本だと思う。
1Password CLIから指紋認証でパスワードやOTPを取得する
1Password CLIから指紋認証でパスワードやOTPを取得する方法について。
1Password CLIは使ったことがなく、Your CLI wish is our command 🪄💫 | 1Passwordを見て興味を持ち、セットアップしたらとても便利だった。
セットアップ手順
1. 1Passwordのセットアップ
まず https://1password.com/downloads/mac/ 1Password 8以上のデスクトップアプリをインストールする*1。
2022-03-28時点でApp Storeや brew install 1password では7系しかインストールできない。かつ、macOSの1Password 8はbeta扱いなので画面下のほうにある以下のリンクからダウンロードする。
インストールした1Passwordを起動してログインしておく。
2. 1Password CLIのセットアップ
https://developer.1password.com/docs/cli/get-started を参考にすればよい。一応手順を書く。
1Password CLI v2以上をインストールする。
https://1password.com/downloads/command-line/ からダウンロードしてもいいし、brew install 1password-cliしてもよい。brewでもv2をインストールできる。
インストールしたらCLIからアカウントを追加する。
$ op account add Enter your sign-in address (example.1password.com): Enter the email address for your account on <sign-in address>: Enter the Secret Key for <email address> on <sign-in address>: Enter the password for <email address> at <sign-in address>:
Vaultにある 1Password Account (<username>) に書いてある内容を移せばOK。
| 項目 | 入力事項 |
|---|---|
| sign-in address | 個人アカウントなら大抵は my.1password.com でよいはず |
| email address | （1Passwordアカウントのメールアドレス） |
| Secret Key | （1PasswordアカウントのSecret Key） |
| password | （1Passwordアカウントのパスワード） |
$ eval $(op signin) Enter the password for <email address> at <sign-in address>:
account addしてもアカウントを追加しただけでsign inはできていないため、このコマンドでsign inする必要がある。ちなみに1Passwordに設定した期間で強制sign outされる。
3. 指紋認証を有効化する
1Passwordのデスクトップアプリで以下の手順を行うことで、パスワード認証ではなく指紋認証でsign inできる。
1Password > Preferencesで設定モーダルを開くDeveloper > 1Password CLI 2にあるBiometric unlock for 1Password CLIにチェックを入れる
試しにOTP取得してみる
上記のセットアップが完了していれば以下のコマンドにて、1Passwordへの指紋認証を経て各種itemのパスワードやOTPなどを取得することができる。
$ op item get my-item --otp
このOTPをパイプで流し込んだり、aliasを登録しておくとCLIでの多要素認証の手数が減る*2。Your CLI wish is our command 🪄💫 | 1Passwordにあるように環境変数を流し込むようなこともできる。
コマンドについて
op item get { <itemName> | <itemID> } --otp
1Passwordに登録されたitemの情報を取得するコマンド。
itemNameに空白等が入っていてCLIとかで扱いにくいな〜ってときにItemIDが使える。
itemIDは op item list や op item get で確認できる。
$ op item list ID TITLE VAULT EDITED 2nkisfqj3bh2tb6soowptfkooa my-item Personal 3 years ago
--otp でOTP文字列を返す。OTP以外のフィールドも取り出し放題で、他にも様々なオプションがあるのでリファレンス参照。
関連ドキュメント
個人サイトのビルドツールをwebpackからViteに移行した
個人サイト https://ohbarye.github.io/ のビルドツールをwebpackからViteに移行した。
まぁ、移行と大げさに言っても、元々vanilla JSとSassでちょっと動きと装飾を付けただけのペライチページなのだけど。
実質ただのリンク集
理由
State of JS 2021のビルドツール部門でViteが1位になっていたが利用したことがなく気になっていたため。手元にある最小のフロントエンドプロジェクトが個人サイトだったのでplaygroundとして試してみた。
https://2021.stateofjs.com/en-US/libraries/build-tools より
Viteとは
Vite公式を斜め読みした。ランキング中だと経験あるビルドツールがwebpack, Parcel, Rollupあたりで止まっていたのでそこからの差分で理解すると...
- esbuildというGo製の爆速ビルドツールが生まれた
- でもまだproduction向けにbundleする機能は安定しておらず、webpackとかRollupのほうが成熟してる
- Viteはesbuildを開発用に使い、production向けのbundleにはRollupを使う
- esbuildを使ってdependenciesをpre-bundleしたり、HMR提供して開発体験を最高にする
- 2つのツールの併用になるが、Viteはconfig周りの複雑さを吸収してデフォルトだとzero configで動く
という感じか。
移行手順
プロジェクトの外側でyarn create viteを試してみてどんなファイルが生成されるかを一通り眺める。vanilla JSとTypeScriptを選んだ場合は数ファイル程度だったのですぐに理解できた。
生成されたファイルやpackage.json内のnpm scriptやdependenciesを元々のプロジェクトにコピペする。
index.htmlがあるディレクトリをrootとし、相対パスで指定したファイルが依存ツリーに勝手に追加されていく。yarn devで起動し、おかしいところがあれば直す。今回はsassのインストールと、相対パスの置換ミスぐらい。
感想
2つのツールをラップしてると聞くと「結局開発者が両方知らないといけないやつでは...？」身構えてしまう。
ただ、https://ohbarye.github.io/のようにちょろっとTypeScriptやSassでサイト作りたい程度であればconfig知識ほぼ不要でセットアップできたし、このあたりはParcelの初出の頃を思い出した。
一部ビルドに工夫*1が必要なところも、Viteのconfigからrollupにオプションを渡すぐらいのことは問題なくできた。configオブジェクトに型が付いているのはとても良い。mis configurationを避けられる。
開発時のビルド速度の向上はやはりある程度以上の規模がないと恩恵がわからないので、業務のアプリケーションでもそのうち試してみたい。
状態、結合、複雑性、コード量の順に最適化する
There’s No Such Thing as Clean CodeのHacker Newsコメント経由でコードやシステム設計・最適化についての良いコメントを見つけた。どうやらHacker Newsで何度も引用されているらしいが日本語で言及された記事が見つからなかったので取り上げてみる。
コメントは2016年のSandi MetzのThe Wrong Abstractionに関するもので、発言者のcurun1rいわく「私は設計の優先順位をこの順序で学習することで、優れた開発者になれた」。*1
4つの基準と優先順位のガイドライン
状態 > 結合 > 複雑性 > コード量
私は状態 (state)、結合 (coupling)、複雑性 (complexity)、コード量 (code) の順に削減することでコードを最適化する。
- コードがよりステートレスになるなら、結合を増やすこともいとわない
- 結合を減らすためには、コードをもっと複雑にすることもある
- コードの複雑さが軽減されるなら、コードをコピーする
- コードの重複排除をするのは状態・結合・複雑性を増さない時のみに限る
ステートレスを最優先する理由
ステートレスなコードを最優先する理由は、それが最も推論可能なものだからだ。
- ステートレスロジックは、通常のコード実行・並列処理・分散処理のいずれでも同じように機能する
- 状態を再現するためのセットアップコードがほとんど必要ないので最もテストしやすい
- コピーを実行するだけなので、スケーラビリティも高い
状態が入り込むとプログラムは...かなり難しくなる。
Once you introduce state, your life gets significantly harder.
初心者のプログラマはコード量にのみ注目する
初心者のプログラマがコード量を削減するのは、4つの基準の中で最も見つけやすいからだと思う。
他の3つはコード量に比べてはるかに微妙で主観的であるため、発見するにはより多くの経験が必要になる。*2
このコメントに対するツッコミと、curun1rによる回答。
「ステートレスかどうかと結合度は直行する概念では？」
対立するシーンはいくつもあり、小さいプログラムよりもシステムアーキテクチャでよく見られる。たとえばシステムコンポーネントがジョブキューをインメモリで管理する場合、その状態を別のキュー管理コンポーネントに任せる（状態--; 結合++）ほうがうまく状態を管理でき、明晰になる。
「複雑性は結合が生み出すものでは？」
複雑性にはたくさんの種類があり、結合はその一形態に過ぎない。たとえば循環的複雑度も1つの複雑性を示す指標である。複数の複雑性の組み合わせこそが私の考える複雑性であり、プログラマの認知負荷を高めるものだ。
元のコメントで述べられてるコード最適化ガイドラインについてはここまで。以下は感想。
「状態 > 結合 > 複雑性 > コード量」の優れている点
様々なシーンに適用できるエレガントなガイドラインだと感じたので、優れていると感じた点を述べてみる。
基準の普遍性
古今東西様々なプログラミング原則が存在するが、"state > coupling > complexity > code" のガイドラインはシンプルでわかりやすく、パラダイムによらない普遍性があると感じる。
重なるところの大きいCode Smellを端的に言い表しているようにも見える。
順序付き
特定の原則を遵守するときにトレードオフが発生することがあるが、優先度が付けられているので「要はバランス」とならずに判断しやすい。
もちろん画一的な判断はできないがコンフリクトした際の指標があるというのが良い。
（最近はあまり聞かないかもしれないが）DRY原則を持ち出してコード量を減らすパッチを受け取ったときに「変更によって状態・結合・複雑性が増しているから受け入れない」と言うことができる。
適用範囲の広さ
ソースコードだけでなくシステムアーキテクチャについても同様の最適化が可能であるという一貫性も良い。マイクロサービスアーキテクチャにSOLIDの一部は適用できる、といった半端さがない。
たとえば、HTTPやイベントソーシング*3が状態を削減しつつ結合や複雑性を増やしていることも、同じ基準によって評価できる。
覚えやすさ
そして、何より覚えやすい。4という数が覚えるのにちょうどよい。
欲を言えば、より端的に表す名前が欲しい。acronymでSCCCとかS3Cみたいな名前が付けられそう*4。
関連する言説
思いついたものを2つ。
同主張への関連を見出だせる設計原則やソフトウェアに対する考察は無数にありそう。
Out of the Tar Pit
複雑性といえば、Rich HickeyがClojureを作る時に影響を受けたという"Out of the Tar Pit"。同論文では複雑性について以下の主張をする。
- 複雑であるとは、推論が効きにくいか、不可能であること
- プログラムの複雑性は、状態・制御・コード量・言語のパワフルさに由来する
- 複雑性はコントロールできる（とりわけ、"偶発的な複雑性"を指して）
ここでは複雑性がより広い概念として扱われ、状態 (state)・コード量 (code) は複雑性を生む要因の1つに含まれている。
ただし、状態は「コンピューターシステムにおいて絶対になくならない"本質的な複雑性"」とラベリングされているので、コントロールの難易度・アプローチが異なる"偶発的な複雑性"とは切り分けて扱うのが妥当に思う。
「複雑性にはたくさんの種類がある」という補足を先述したが、4つの基準が原則たるためには複雑性という言葉に明晰な定義が必要かもしれない。
Clean Architecture
『クリーンアーキテクチャ』本における「プログラミングパラダイムは制約を課すものであり、何をすべきでないかを伝えている」という一節を思い出した。
各パラダイムの制約が促すプログラム設計により、4つの基準での最適化が推進されるのではないだろうか、と。具体的には以下のようになる。
構造化プログラミングは、直接的な制御の移行に規律を課すものである
モジュール分割によって、結合・複雑性が削減される。
オブジェクト指向プログラミングは、間接的な制御の移行に規律を課すものである
コードの依存関係の制御によって、結合が削減される。
関数型プログラミングは、代入に規律を課すものである
タスクの関数化によって、状態が削減される。
最近の業務であった設計
卑近な例との関連。
これまで1つの責務しかなかったモデルに新たな役割（ユースケース）が追加されそうになる、というありがちなシーンに同僚が直面していた。一緒に設計の相談をした末に2つの実装パターンに思い至ったので、どちらが良いかを評価するために両方のパターンのコードを同僚に書いてもらった。
- 同モデルで複数のユースケースの振る舞いを扱えるようにする。変更にかかるコード量は最も少なくても済むが、同一モデル内で気にすべき状態が増える。*5
- ユースケースごとに対応するモデルを追加し、元のモデルは抽象にする。変更するコード量はかなり多いが各モデルで気にする状態は少なくなる。
最終的には2を選び、「コード量と複雑性は高いけれども状態と結合は少なくてすむことを優先した」と説明できるようなプログラムになった。
この選択が正解かどうかは時の洗礼を受ける必要があるが、試し書きしたコードをレビューする時点で認知負荷の低さを感じたし、テストもユースケースごとに分割できていて見通しが良かった。
AI Programmer
オフトピック。
最近tabnineやCopilotを使っていてコード補完や生成におけるすさまじい技術の進歩を感じるが、この4つの基準で最適化されたコードがsuggestされると面白そう。
現時点でもコードの重複の削減は簡単に提案されるし、状態・結合・複雑性の削減も、循環的複雑度の高さやローカル変数の個数など特定の指標ごとに指摘するツールは多くあるが、さらに一歩先で「インスタンス変数への依存をなくし関数にしませんか」「このクラスは2つの状態に依存していますが取り除くことができます」的な。
まぁ、機械が書いたコードを機械が読むような、真にプログラマが不要な世界に到達したら人間にとってのコードの認知負荷は問題ではなくなるのだが。
無職を経てSmartBank, Inc.に入社しました
掲題の通り、SmartBank, Inc に入社しました。
- From: Quipper, Inc.
- To: SmartBank, Inc.
2021 in review - valid,invalidに書いたとおり転職は2020年の出来事で、入社日は 2020-08-01。2021 の間違いではなく 2020 である。入社してから半年程度はステルスでプロダクト開発を行っていたため書くきっかけを見失ってしまい、以降ずっと執筆をサボっていた。
当記事は入社後 1 年半の振り返りではなく2020年のオファー受諾時や入社時に何を考えていたかを主に記述する。（が、結果として当時の期待やオファー受諾の決め手が概ね間違っていなかったことを追認することになった）
続きを読むCLIでpull requestsをまとめてapproveするワンライナー
GitHub公式CLIのghを使って複数のpull requestsをまとめてapproveする。
まれに使うのでメモ。
前提
gh install済み、かつcurrent directoryが対象のrepositoryであること
コマンド例
Approve all pull requests in the repositrory
$ for pr in $(gh pr list --json 'number' -t '{{ range $i, $pr := . }}{{ $pr.number }} {{end}}'); do gh pr review -a $pr; done
Approve all pull requests with dependencies label in the repositrory
$ for pr in $(gh pr list --json 'number' -t '{{ range $i, $pr := . }}{{ $pr.number }} {{end}}' --label dependencies); do gh pr review -a $pr; done