ent では UUID 型がデフォルトでサポートされているのですが、それとは別に <a href="https://github.com/ulid/spec">ULID</a> を使う方法を解説します。

ULID の実装は <a href="https://github.com/oklog/ulid">https://github.com/oklog/ulid</a> を使用します。

ent の UUID 型は、<a href="https://golang.org/pkg/database/sql/driver/#Valuer">driver.Valuer</a> Interface を利用して値を取得しますが、 oklog/ulid の <code>Value()</code> の実装がバイナリを返却するようになっているため、このままでは可読性が悪いです。 <code>Value()</code> が String を返すようにした ULID 型を新たに定義するのが良いでしょう。そのようにすると、他の interface も実装する必要があります。

結論から言うと <a href="https://github.com/ent/contrib/blob/6623819401500db45747a2419172963217cef619/entgql/internal/todopulid/ent/schema/pulid/pulid.go">https://github.com/ent/contrib/blob/6623819401500db45747a2419172963217cef619/entgql/internal/todopulid/ent/schema/pulid/pulid.go</a> にそのものの実装があります<a href="#fn:1" rel="footnote">1</a>。この実装はライブラリ化されているものではない（ internal ）ので、そのままコピペして利用するのが良いでしょう。

使用する場合には以下のようになります。

<pre class="code lang-go" data-lang="go" data-unlink>// Fields of the User.
func (User) Fields() []ent.Field {
 return []ent.Field{
 field.String(&quot;id&quot;).
 GoType(pulid.ID(&quot;&quot;)).
 DefaultFunc(func() pulid.ID { return pulid.MustNew(&quot;US&quot;) }),
 field.Int(&quot;age&quot;).Positive(),
 field.String(&quot;name&quot;).Default(&quot;unknown&quot;),
 }
}
</pre>


prefixが不要な場合はprefixの部分を削ってしまうのが良いかと思います。

このままの実装でもう少し手軽に書きたい場合は、同<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%EA%A5%DD%A5%B8%A5%C8%A5%EA">リポジトリ</a>に <a href="https://github.com/ent/contrib/blob/6623819401500db45747a2419172963217cef619/entgql/internal/todopulid/ent/schema/pulid/mixin.go">mixin</a> が存在しますので、これを持ち出すと良いと思います。

ent は各フィールドを固有の型にできますので、例えば上記例で ID を <code>UserID</code> 型にしたい場合は以下のようになります。

<pre class="code lang-go" data-lang="go" data-unlink>type UserID pulid.ID

// Fields of the User.
func (User) Fields() []ent.Field {
 return []ent.Field{
 field.String(&quot;id&quot;).
 GoType(UserID(&quot;&quot;)).
 DefaultFunc(func() UserID { return UserID(pulid.MustNew(&quot;US&quot;)) }),
 field.Int(&quot;age&quot;).Positive(),
 field.String(&quot;name&quot;).Default(&quot;unknown&quot;),
 }
}
</pre>

<div class="footnotes">
<hr/>
<ol>
<li id="fn:1">
<a href="https://github.com/tmc/pulid">https://github.com/tmc/pulid</a> のように見えるのですが、こちらは <code>Value()</code> はバイナリを返すようです。<a href="#fnref:1" rev="footnote">&#8617;</a></li>
</ol>
</div>

ent では UUID 型がデフォルトでサポートされているのですが、それとは別に ULID を使う方法を解説します。
ULID の実装は https://github.com/oklog/ulid を使用します。
ent の UUID 型は、driver.Valuer Interface を利用して値を取得しますが、 oklog/ulid の Value() の実装がバイナリを返却するようになっているため、このままでは可読性が悪いです。 Value() が String を返すようにした ULID 型を新たに定義するのが良いでしょう。そのようにすると、他の interface も実装する必要があります。
結論から言うと https://github.com/ent/contrib/blob/6623819401500db45747a2419172963217cef619/entgql/internal/todopulid/ent/schema/pulid/pulid.go にそのものの実装があります1。この実装はライブラリ化されているものではない（ internal ）ので、そのままコピペして利用するのが良いでしょう。
使用する場合には以下のようになります。
// Fields of the User.
func (User) Fields() []ent.Field {
    return []ent.Field{
        field.String("id").
            GoType(pulid.ID("")).
            DefaultFunc(func() pulid.ID { return pulid.MustNew("US") }),
        field.Int("age").Positive(),
        field.String("name").Default("unknown"),
    }
}



prefixが不要な場合はprefixの部分を削ってしまうのが良いかと思います。
このままの実装でもう少し手軽に書きたい場合は、同リポジトリに mixin が存在しますので、これを持ち出すと良いと思います。
ent は各フィールドを固有の型にできますので、例えば上記例で ID を UserID 型にしたい場合は以下のようになります。
type UserID pulid.ID

// Fields of the User.
func (User) Fields() []ent.Field {
    return []ent.Field{
        field.String("id").
            GoType(UserID("")).
            DefaultFunc(func() UserID { return UserID(pulid.MustNew("US")) }),
        field.Int("age").Positive(),
        field.String("name").Default("unknown"),
    }
}






https://github.com/tmc/pulid のように見えるのですが、こちらは Value() はバイナリを返すようです。↩

ent ( entgo.io/ent ) で ULID を使う

最近不慣れな <a class="keyword" href="http://d.hatena.ne.jp/keyword/GCP">GCP</a> を触ることがあったのですが、最初から Terraform で書くようにしたほうが楽だったので、それについて解説しようと思います。

<h1>Web のコンソールを触るのが怖い</h1>

他のサービスが同居しているアカウントでインフラを操作すると、他のサービスに影響を与えてしまうのでは…という不安があります。関係のないサービスは別アカウントにするというのがベストプ<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%E9%A5%AF">ラク</a>ティスですが、様々な事情によりそれができない場合もあります。

最初から IaC で触っていれば、コードで生成したインフラ以外を触ることがなく、削除する時も間違えることがなく削除することができ、何度も作り直して試すことが容易になります。

<h1>手順を覚えられない</h1>

Webのコンソールでも、<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%B3%A5%DE%A5%F3%A5%C9%A5%E9%A5%A4%A5%F3">コマンドライン</a>ツールでも同様ですが、作業した内容を記録しておく必要があります。記録していない場合、同じ環境を再現することができません。

最初からコード化をしていれば、手順を覚えておく必要もありません。

<h1>必要な依存関係を最初から教えてくれる</h1>

コンソールで触っていると、どのサービスとどのサービスが繋がっているかというのがわかりにくいですが、例えば Terraform では必須パラメーターとして存在していることが多く、依存関係を設定していないと適用する前にエラーになってくれたりするので迷うことが少なくなります。

また、サンプルで組み合わせた書き方が充実していたり、組み合わせサンプルのコードが用意されていたりするので、手順を読んで試行錯誤するより確実にインフラ構築をすることができます。

特に <a class="keyword" href="http://d.hatena.ne.jp/keyword/AWS">AWS</a> で CDK や Copilot といったツールを使っておくと、複雑なサービス間の依存関係を考えることがなく構成を立ち上げることができます。

<h1>設定できるパラメーターがツールのドキュメントに網羅されている</h1>

依存関係と同様に、全てのパラメーターがドキュメントに書かれているので、「このリソースではこれが設定できる」とか「このリソースはこの設定をすることができない」というのがドキュメントを読むだけで把握することができます。

ただし <a class="keyword" href="http://d.hatena.ne.jp/keyword/GCP">GCP</a> の Cloud Run のような<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%E1%A5%BF%A5%C7%A1%BC%A5%BF">メタデータ</a>でパラメーターを指定するような類のものの場合や、<a class="keyword" href="http://d.hatena.ne.jp/keyword/AWS">AWS</a> RDS のパラメーターグループのような任意のものを指定するようなものはドキュメントには書かれていないので、そこはオフィシャルのドキュメントやコンソールの画面を併せて読む必要があります。

<h1>まとめ</h1>

コンソールで試行錯誤するより、最初からコードで書いて試行錯誤したほうが良いことが多いです。手作業を後からコード化するのは二度手間にもなるので、学習目的とかでない限りは最初からコードを書きましょう。

もちろんある程度の IaC ツールに慣れておく必要や、<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%AF%A5%E9%A5%A6%A5%C9">クラウド</a>インフラの使い方に慣れておく必要がありますので、そこは基礎教養として素振りしておきましょう。

最近不慣れな GCP を触ることがあったのですが、最初から Terraform で書くようにしたほうが楽だったので、それについて解説しようと思います。
Web のコンソールを触るのが怖い
他のサービスが同居しているアカウントでインフラを操作すると、他のサービスに影響を与えてしまうのでは…という不安があります。関係のないサービスは別アカウントにするというのがベストプラクティスですが、様々な事情によりそれができない場合もあります。
最初から IaC で触っていれば、コードで生成したインフラ以外を触ることがなく、削除する時も間違えることがなく削除することができ、何度も作り直して試すことが容易になります。
手順を覚えられない
Webのコンソールでも、コマンドラインツールでも同様ですが、作業した内容を記録しておく必要があります。記録していない場合、同じ環境を再現することができません。
最初からコード化をしていれば、手順を覚えておく必要もありません。
必要な依存関係を最初から教えてくれる
コンソールで触っていると、どのサービスとどのサービスが繋がっているかというのがわかりにくいですが、例えば Terraform では必須パラメーターとして存在していることが多く、依存関係を設定していないと適用する前にエラーになってくれたりするので迷うことが少なくなります。
また、サンプルで組み合わせた書き方が充実していたり、組み合わせサンプルのコードが用意されていたりするので、手順を読んで試行錯誤するより確実にインフラ構築をすることができます。
特に AWS で CDK や Copilot といったツールを使っておくと、複雑なサービス間の依存関係を考えることがなく構成を立ち上げることができます。
設定できるパラメーターがツールのドキュメントに網羅されている
依存関係と同様に、全てのパラメーターがドキュメントに書かれているので、「このリソースではこれが設定できる」とか「このリソースはこの設定をすることができない」というのがドキュメントを読むだけで把握することができます。
ただし GCP の Cloud Run のようなメタデータでパラメーターを指定するような類のものの場合や、AWS RDS のパラメーターグループのような任意のものを指定するようなものはドキュメントには書かれていないので、そこはオフィシャルのドキュメントやコンソールの画面を併せて読む必要があります。
まとめ
コンソールで試行錯誤するより、最初からコードで書いて試行錯誤したほうが良いことが多いです。手作業を後からコード化するのは二度手間にもなるので、学習目的とかでない限りは最初からコードを書きましょう。
もちろんある程度の IaC ツールに慣れておく必要や、クラウドインフラの使い方に慣れておく必要がありますので、そこは基礎教養として素振りしておきましょう。

 Infrastructure as Codeは最初からやったほうがいい

<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%D5%A5%EA%A1%BC%A5%E9%A5%F3%A5%B9">フリーランス</a>としてWebエンジニアをしておりますが、プロジェクトに新規に入った時にどういう点を確認しているのかをまとめておきたいと思います。

<h1>プロジェクトの目標と直近の目標が問題ないか</h1>

プロジェクトの最終目標（理想）はとにかく大きくあるべきで、一方で直近の目標は具体的かつ十分に実現可能なサイズになっているべきです。もちろんその間くらいの目標（いわゆる<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%DE%A5%A4%A5%EB%A5%B9%A5%C8%A1%BC%A5%F3">マイルストーン</a>）も存在しているはずです。

<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%D5%A5%EA%A1%BC%A5%E9%A5%F3%A5%B9">フリーランス</a>の立場だと目標そのものに直接口を出すことはないですが、直近の目標が大きすぎると手を動かす時に困ってしまいますので、どこを削ぎ落とすのが良いのかこちらから提案することはあります。

<h1><a class="keyword" href="http://d.hatena.ne.jp/keyword/%B3%AB%C8%AF%A5%D7%A5%ED%A5%BB%A5%B9">開発プロセス</a>が問題ないか</h1>

プロジェクト参加直後はベロシティ（スプリント期間内の平均作業量）が不安定ですので、そこを許容できてちゃんと

個人的には常に<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%B9%A5%AF%A5%E9%A5%E0">スクラム</a>である必要はないと思いますが、マネージャーがいる場合はマネージャーが各メンバーのベロシティをちゃんと把握している、不在の場合は自分でベロシティが把握できていてタスクの見積もりができる、という状況になっていれば良いかと思います。「何だかよくわからないタスクをよくわからない期間で対応している」という状況では、前述の直近の目標の提案と同時に対処方法の提案を行うこともあります。

<h1>デプロイが安定かつ高速に行えているか</h1>

デプロイ速度は修正速度に直接繋がりますし、安定したデプロイができなければデプロイする単位が大きくなりがちですので、デプロイの安定性は最重要になります。

当然デプロイは完全自動化されていて、誰でも気軽に（承認フローなどは別として）デプロイできることが前提です。

誰でも簡単にデプロイできない場合、誰かにデプロイをお願いするというようなことが発生します。これでは自分と誰かの作業と、それを連絡する作業が増えてしまい、当然作業効率が悪くなってしまいますので、「誰でも」は重要です。「コマンド一発でデプロイできる」と見えても「（コマンドを実行する前にアクセスキーを取得して手元でデプロイ準備をして…）コマンド一発でデプロイできる」という場合がよくありますので、デプロイ環境自体が CI/CD 環境に移されていて手元の環境に影響せずデプロイできる（ CI サーバーが落ちていた場合は手元でも実行できる）というのが理想です。

<h1>デプロイ方法が複雑になっていないか</h1>

安定して高速にデプロイできていても、それを処理している方法が複雑だとメンテナンスの時に困ります。

メインのコードは綺麗にできてもインフラ系の<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%B9%A5%AF%A5%EA%A5%D7%A5%C8">スクリプト</a>は長くなりがちみたいなケースはよく見かけますが、インフラ系の<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%B9%A5%AF%A5%EA%A5%D7%A5%C8">スクリプト</a>もメインのコード同様に読みやすく構造化されているべきです。またインフラ系はツールが充実していることが多いので、なるべく自分で書く<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%B9%A5%AF%A5%EA%A5%D7%A5%C8">スクリプト</a>は最小限にするのが良いと思います。

デプロイ自体が安定高速動作していればとりあえずは問題ないので、ここは後回しにすることも多いです。

<h1>CI でコード品質が十分に守られているか</h1>

CI の整備は後になればなるほど大変です。<a href="#fn:1" rel="footnote">1</a>これは CI で行うことの多くはコード品質そのものを一定の品質にする（ lint など）もののため、コード量が増えた後からそれを適用しようとすると修正点が膨大になるためです。
lint はとにかくコード量が増える前に対処することが大事なので、ここは真っ先にチェックを行います。リリース前プロジェクトであればすぐ導入しますが、リリース後だと手を入れにくいので、最小限の設定にして少しずつ厳しくするという手法を採ります。

（自動）テストはそもそもテストが書けているかというのをまず確認しますが、その上で「テストに再現性があるか」「テストの内容が十分か」「<a href="https://testing.googleblog.com/2010/12/test-sizes.html">Test Sizes</a> の分類が十分にできているか」といった内容を確認します。

数回に１回落ちるようなテストがある場合で、それがテストの実行順に影響している場合はテストの書き方そのものに問題がある場合がほとんどですので、その場合は削除してしまったほうが良いことが多いです。一方で、時間に関わるテストや、乱数や<a class="keyword" href="http://d.hatena.ne.jp/keyword/%BF%F4%C3%CD%B7%D7%BB%BB">数値計算</a>の誤差などが影響するようなテストは、それ自体が重要なケースが多いのでちゃんと調査したほうがいいと思います。

<a href="https://testing.googleblog.com/2010/12/test-sizes.html">Test Sizes</a> は、テストの分類を「<a class="keyword" href="http://d.hatena.ne.jp/keyword/%C3%B1%C2%CE%A5%C6%A5%B9%A5%C8">単体テスト</a>」「<a class="keyword" href="http://d.hatena.ne.jp/keyword/%B7%EB%B9%E7%A5%C6%A5%B9%A5%C8">結合テスト</a>」といった曖昧な呼び方ではなく、「我々のプロジェクトでは３段階の分類があり、それぞれのレベルではこうなっている」というものをプロジェクト固有で定義しようというものです。

<h1>ローカルでの環境構築が問題なく行えるか</h1>

自分が受け入れられる側になるのですが、この時に受け入れ準備が十分にできているか確認し、できていない場合は改善しながら作業することになります。

一番ありがちなのは環境構築手順が整備されていないということで、これは自分がそのまま作業するのですぐわかります。

ローカルの開発に外部のサーバーが必要な場合はまずそれがローカルで再現できないのか確認します。単なる <a class="keyword" href="http://d.hatena.ne.jp/keyword/MySQL">MySQL</a> や <a class="keyword" href="http://d.hatena.ne.jp/keyword/PostgreSQL">PostgreSQL</a> などをサーバーに繋いでいる場合はローカルで立ち上げるように変更します。<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A8%A5%DF%A5%E5%A5%EC%A1%BC%A5%BF%A1%BC">エミュレーター</a>が用意されているサービスであればそちらを使うようにします。この際に設定が直接書かれていたり ENV などでの切り替えしか対応していない場合は、設定を<a class="keyword" href="http://d.hatena.ne.jp/keyword/%B4%C4%B6%AD%CA%D1%BF%F4">環境変数</a>に出して変更可能にします。<a href="#fn:2" rel="footnote">2</a>
最近だと自分は M1 (<a class="keyword" href="http://d.hatena.ne.jp/keyword/Apple">Apple</a> Silicon) <a class="keyword" href="http://d.hatena.ne.jp/keyword/Mac">Mac</a> を使用しているので、この環境で動作しないものを使っているという場面に遭遇することもあります。この場合は Docker 化を真っ先に行います。

手順はあるけど手順通りにやっても上手く行かないという場合、「使っているライブラリのアップデートで動かなくなった」というケースと「プログラムの構造の変化に対応していない」というケースが多いです。どちらにしても変更を把握できていないということが原因ですので、メンテナンス体制に難があることが多いです。外部ライブラリの更新などは把握しておく、自分で修正した場合は環境構築手順もアップデートするフローにしておく、ということが必要になります。

<h1>受け入れタスクが十分に実施可能な内容になっているか</h1>

ここでの障害は「ライブラリやツールの使い方が独自性の強いものになっていないか」「暗黙の知識が多用されていないか」といったものがあります。もちろん前述までの内容がクリアになっていないと作業に入ることもできませんので、それらを取り除いた後にようやく作業ができるということになります。

「ライブラリやツールの使い方が独自性の強いものになっていないか」というのは、自作ライブラリとかを使っている場合は当然ですが、ベストプ<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%E9%A5%AF">ラク</a>ティスに即していないようなライブラリの使い方をしているとか、<a class="keyword" href="http://d.hatena.ne.jp/keyword/%CB%E2%B2%FE%C2%A4">魔改造</a>されているというような場合には、なるべく本来の使い方に戻すよう指摘することがあります。「ライブラリやツールの公式の<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%C1%A5%E5%A1%BC%A5%C8%A5%EA%A5%A2%A5%EB">チュートリアル</a>を見た上でそれを使っている部分を読んだ時にすぐ理解できるようになっているか」というのが指標になります。

「暗黙の知識が多用されていないか」はそのままですが、プロジェクト固有の暗黙の知識がある場合は当然手を入れることができません。暗黙の知識が登場する場合はコメントなどで把握できるようになっていること、仕様と実態の乖離がないことなどを確認します。

<h1>まとめ</h1>

これらの点がクリアされているプロジェクトであれば、新しく人を入れることも容易ですし、引き継ぎの時にも困らないのではないかと思います。

書き漏れがあるかもしれないので、思い出したら追記する可能性があります。

今回はインフラの話は除外しましたが、インフラでチェックする点もまた機会があればまとめてみたいと思います。

これらの点でお悩みの方は是非私までご相談をお願いします。詳細は <a href="https://nazo.dev/profile">https://nazo.dev/profile</a> をご覧下さい。
<div class="footnotes">
<hr/>
<ol>
<li id="fn:1">
<a href="https://www.slideshare.net/nazone/ss-205324165">https://www.slideshare.net/nazone/ss-205324165</a> もご覧下さい。<a href="#fnref:1" rev="footnote">&#8617;</a></li>
<li id="fn:2">
<a href="https://12factor.net/ja/config">https://12factor.net/ja/config</a><a href="#fnref:2" rev="footnote">&#8617;</a></li>
</ol>
</div>

フリーランスとしてWebエンジニアをしておりますが、プロジェクトに新規に入った時にどういう点を確認しているのかをまとめておきたいと思います。
プロジェクトの目標と直近の目標が問題ないか
プロジェクトの最終目標（理想）はとにかく大きくあるべきで、一方で直近の目標は具体的かつ十分に実現可能なサイズになっているべきです。もちろんその間くらいの目標（いわゆるマイルストーン）も存在しているはずです。
フリーランスの立場だと目標そのものに直接口を出すことはないですが、直近の目標が大きすぎると手を動かす時に困ってしまいますので、どこを削ぎ落とすのが良いのかこちらから提案することはあります。
開発プロセスが問題ないか
プロジェクト参加直後はベロシティ（スプリント期間内の平均作業量）が不安定ですので、そこを許容できてちゃんと
個人的には常にスクラムである必要はないと思いますが、マネージャーがいる場合はマネージャーが各メンバーのベロシティをちゃんと把握している、不在の場合は自分でベロシティが把握できていてタスクの見積もりができる、という状況になっていれば良いかと思います。「何だかよくわからないタスクをよくわからない期間で対応している」という状況では、前述の直近の目標の提案と同時に対処方法の提案を行うこともあります。
デプロイが安定かつ高速に行えているか
デプロイ速度は修正速度に直接繋がりますし、安定したデプロイができなければデプロイする単位が大きくなりがちですので、デプロイの安定性は最重要になります。
当然デプロイは完全自動化されていて、誰でも気軽に（承認フローなどは別として）デプロイできることが前提です。
誰でも簡単にデプロイできない場合、誰かにデプロイをお願いするというようなことが発生します。これでは自分と誰かの作業と、それを連絡する作業が増えてしまい、当然作業効率が悪くなってしまいますので、「誰でも」は重要です。「コマンド一発でデプロイできる」と見えても「（コマンドを実行する前にアクセスキーを取得して手元でデプロイ準備をして…）コマンド一発でデプロイできる」という場合がよくありますので、デプロイ環境自体が CI/CD 環境に移されていて手元の環境に影響せずデプロイできる（ CI サーバーが落ちていた場合は手元でも実行できる）というのが理想です。
デプロイ方法が複雑になっていないか
安定して高速にデプロイできていても、それを処理している方法が複雑だとメンテナンスの時に困ります。
メインのコードは綺麗にできてもインフラ系のスクリプトは長くなりがちみたいなケースはよく見かけますが、インフラ系のスクリプトもメインのコード同様に読みやすく構造化されているべきです。またインフラ系はツールが充実していることが多いので、なるべく自分で書くスクリプトは最小限にするのが良いと思います。
デプロイ自体が安定高速動作していればとりあえずは問題ないので、ここは後回しにすることも多いです。
CI でコード品質が十分に守られているか
CI の整備は後になればなるほど大変です。1これは CI で行うことの多くはコード品質そのものを一定の品質にする（ lint など）もののため、コード量が増えた後からそれを適用しようとすると修正点が膨大になるためです。
lint はとにかくコード量が増える前に対処することが大事なので、ここは真っ先にチェックを行います。リリース前プロジェクトであればすぐ導入しますが、リリース後だと手を入れにくいので、最小限の設定にして少しずつ厳しくするという手法を採ります。
（自動）テストはそもそもテストが書けているかというのをまず確認しますが、その上で「テストに再現性があるか」「テストの内容が十分か」「Test Sizes の分類が十分にできているか」といった内容を確認します。
数回に１回落ちるようなテストがある場合で、それがテストの実行順に影響している場合はテストの書き方そのものに問題がある場合がほとんどですので、その場合は削除してしまったほうが良いことが多いです。一方で、時間に関わるテストや、乱数や数値計算の誤差などが影響するようなテストは、それ自体が重要なケースが多いのでちゃんと調査したほうがいいと思います。
Test Sizes は、テストの分類を「単体テスト」「結合テスト」といった曖昧な呼び方ではなく、「我々のプロジェクトでは３段階の分類があり、それぞれのレベルではこうなっている」というものをプロジェクト固有で定義しようというものです。
ローカルでの環境構築が問題なく行えるか
自分が受け入れられる側になるのですが、この時に受け入れ準備が十分にできているか確認し、できていない場合は改善しながら作業することになります。
一番ありがちなのは環境構築手順が整備されていないということで、これは自分がそのまま作業するのですぐわかります。
ローカルの開発に外部のサーバーが必要な場合はまずそれがローカルで再現できないのか確認します。単なる MySQL や PostgreSQL などをサーバーに繋いでいる場合はローカルで立ち上げるように変更します。エミュレーターが用意されているサービスであればそちらを使うようにします。この際に設定が直接書かれていたり ENV などでの切り替えしか対応していない場合は、設定を環境変数に出して変更可能にします。2
最近だと自分は M1 (Apple Silicon) Mac を使用しているので、この環境で動作しないものを使っているという場面に遭遇することもあります。この場合は Docker 化を真っ先に行います。
手順はあるけど手順通りにやっても上手く行かないという場合、「使っているライブラリのアップデートで動かなくなった」というケースと「プログラムの構造の変化に対応していない」というケースが多いです。どちらにしても変更を把握できていないということが原因ですので、メンテナンス体制に難があることが多いです。外部ライブラリの更新などは把握しておく、自分で修正した場合は環境構築手順もアップデートするフローにしておく、ということが必要になります。
受け入れタスクが十分に実施可能な内容になっているか
ここでの障害は「ライブラリやツールの使い方が独自性の強いものになっていないか」「暗黙の知識が多用されていないか」といったものがあります。もちろん前述までの内容がクリアになっていないと作業に入ることもできませんので、それらを取り除いた後にようやく作業ができるということになります。
「ライブラリやツールの使い方が独自性の強いものになっていないか」というのは、自作ライブラリとかを使っている場合は当然ですが、ベストプラクティスに即していないようなライブラリの使い方をしているとか、魔改造されているというような場合には、なるべく本来の使い方に戻すよう指摘することがあります。「ライブラリやツールの公式のチュートリアルを見た上でそれを使っている部分を読んだ時にすぐ理解できるようになっているか」というのが指標になります。
「暗黙の知識が多用されていないか」はそのままですが、プロジェクト固有の暗黙の知識がある場合は当然手を入れることができません。暗黙の知識が登場する場合はコメントなどで把握できるようになっていること、仕様と実態の乖離がないことなどを確認します。
まとめ
これらの点がクリアされているプロジェクトであれば、新しく人を入れることも容易ですし、引き継ぎの時にも困らないのではないかと思います。
書き漏れがあるかもしれないので、思い出したら追記する可能性があります。
今回はインフラの話は除外しましたが、インフラでチェックする点もまた機会があればまとめてみたいと思います。
これらの点でお悩みの方は是非私までご相談をお願いします。詳細は https://nazo.dev/profile をご覧下さい。
https://www.slideshare.net/nazone/ss-205324165 もご覧下さい。↩


https://12factor.net/ja/config↩

Webエンジニアが新規でプロジェクトに入った時に確認すること

<a href="https://cloud.google.com/sdk/docs/quickstart-macos?hl=ja">公式からダウンロードしてきた tarball</a> からインストールすると以下のエラーが出ます。

<pre class="code lang-sh" data-lang="sh" data-unlink>/google-cloud-sdk ❯❯❯ ./install.sh
Welcome to the Google Cloud SDK!
Traceback (most recent call last):
 File &quot;/Users/nazo/google-cloud-sdk/bin/bootstrapping/install.py&quot;, line 12, in &lt;module&gt;
 import bootstrapping
 File &quot;/Users/nazo/google-cloud-sdk/bin/bootstrapping/bootstrapping.py&quot;, line 32, in &lt;module&gt;
 import setup # pylint:disable=g-import-not-at-top
 File &quot;/Users/nazo/google-cloud-sdk/bin/bootstrapping/setup.py&quot;, line 57, in &lt;module&gt;
 from googlecloudsdk.core.util import platforms
 File &quot;/Users/nazo/google-cloud-sdk/lib/googlecloudsdk/__init__.py&quot;, line 23, in &lt;module&gt;
 from googlecloudsdk.core.util import importing
 File &quot;/Users/nazo/google-cloud-sdk/lib/googlecloudsdk/core/util/importing.py&quot;, line 23, in &lt;module&gt;
 import imp
 File &quot;/opt/homebrew/Cellar/python@3.9/3.9.1_6/Frameworks/Python.framework/Versions/3.9/lib/python3.9/imp.py&quot;, line 23, in &lt;module&gt;
 from importlib import util
 File &quot;/opt/homebrew/Cellar/python@3.9/3.9.1_6/Frameworks/Python.framework/Versions/3.9/lib/python3.9/importlib/util.py&quot;, line 2, in &lt;module&gt;
 from . import abc
 File &quot;/opt/homebrew/Cellar/python@3.9/3.9.1_6/Frameworks/Python.framework/Versions/3.9/lib/python3.9/importlib/abc.py&quot;, line 17, in &lt;module&gt;
 from typing import Protocol, runtime_checkable
 File &quot;/opt/homebrew/Cellar/python@3.9/3.9.1_6/Frameworks/Python.framework/Versions/3.9/lib/python3.9/typing.py&quot;, line 26, in &lt;module&gt;
 import re as stdlib_re # Avoid confusion with the re we export.
 File &quot;/opt/homebrew/Cellar/python@3.9/3.9.1_6/Frameworks/Python.framework/Versions/3.9/lib/python3.9/re.py&quot;, line 124, in &lt;module&gt;
 import enum
 File &quot;/Users/nazo/google-cloud-sdk/lib/third_party/enum/__init__.py&quot;, line 26, in &lt;module&gt;
 spec = importlib.util.find_spec('enum')
AttributeError: module 'importlib' has no attribute 'util'
</pre>


<a class="keyword" href="http://d.hatena.ne.jp/keyword/curl">curl</a> でインストールするともう少し進みますが以下のエラーが出ます。

<pre class="code lang-sh" data-lang="sh" data-unlink>~ ❯❯❯ curl https://sdk.cloud.google.com | bash
（略）
Welcome to the Google Cloud SDK!

To help improve the quality of this product, we collect anonymized usage data
and anonymized stacktraces when crashes are encountered; additional information
is available at &lt;https://cloud.google.com/sdk/usage-statistics&gt;. This data is
handled in accordance with our privacy policy
&lt;https://cloud.google.com/terms/cloud-privacy-notice&gt;. You may choose to opt in this
collection now (by choosing 'Y' at the below prompt), or at any time in the
future by running the following command:

 gcloud config set disable_usage_reporting false

Do you want to help improve the Google Cloud SDK (y/N)?


This will install all the core command line tools necessary for working with
the Google Cloud Platform.

Beginning update. This process may take several minutes.
ERROR: (gcloud.components.update) The following components are unknown [anthoscli, kuberun].
</pre>


これは <code>anthoscli</code> <code>kuberun</code> の<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%B3%A5%F3%A5%DD%A1%BC%A5%CD%A5%F3%A5%C8">コンポーネント</a>がインストールできない（ <code>gcloud components install anthoscli kuberun</code> と同等）のが原因です。

回避するには、<a class="keyword" href="http://d.hatena.ne.jp/keyword/curl">curl</a> で上記エラーが出た時点で <code>~/google-cloud-sdk</code> にファイル一式があるはずなので、移動して以下のように実行します。

<pre class="code lang-sh" data-lang="sh" data-unlink>~/google-cloud-sdk ❯❯❯ ./install.sh --override-components core gcloud-deps bq gcloud gsutil
Welcome to the Google Cloud SDK!

（略）

Your current Cloud SDK version is: 323.0.0
Installing components from version: 323.0.0

┌────────────────────────────────────────────────────────────────────────────┐
│ These components will be installed. │
├─────────────────────────────────────────────────────┬────────────┬─────────┤
│ Name │ Version │ Size │
├─────────────────────────────────────────────────────┼────────────┼─────────┤
│ BigQuery Command Line Tool │ 2.0.64 │ &lt; 1 MiB │
│ BigQuery Command Line Tool (Platform Specific) │ 2.0.58 │ &lt; 1 MiB │
│ Cloud SDK Core Libraries (Platform Specific) │ 2020.07.10 │ &lt; 1 MiB │
│ Cloud Storage Command Line Tool │ 4.57 │ 3.5 MiB │
│ Cloud Storage Command Line Tool (Platform Specific) │ 4.51 │ &lt; 1 MiB │
└─────────────────────────────────────────────────────┴────────────┴─────────┘

For the latest full release notes, please visit:
 https://cloud.google.com/sdk/release_notes

（略）

For more information on how to get started, please visit:
 https://cloud.google.com/sdk/docs/quickstarts
</pre>


インストールに成功しました。

<code>override-components</code> で指定した引数は、以下で確認したものからエラーが出るものを抜いたものになります。

<pre class="code lang-sh" data-lang="sh" data-unlink>~/google-cloud-sdk ❯❯❯ cat bin/bootstrapping/.default_components
[&quot;core&quot;, &quot;gcloud-deps&quot;, &quot;bq&quot;, &quot;gcloud&quot;, &quot;gsutil&quot;, &quot;anthoscli&quot;, &quot;kuberun&quot;]%
</pre>


anthoscli も kuberun も、おそらく無くて困る人は多くないのではないかと思いますので、抜いてインストールしてしまっていいと思います。

公式からダウンロードしてきた tarball からインストールすると以下のエラーが出ます。
/google-cloud-sdk ❯❯❯ ./install.sh
Welcome to the Google Cloud SDK!
Traceback (most recent call last):
 File "/Users/nazo/google-cloud-sdk/bin/bootstrapping/install.py", line 12, in <module>
 import bootstrapping
 File "/Users/nazo/google-cloud-sdk/bin/bootstrapping/bootstrapping.py", line 32, in <module>
 import setup # pylint:disable=g-import-not-at-top
 File "/Users/nazo/google-cloud-sdk/bin/bootstrapping/setup.py", line 57, in <module>
 from googlecloudsdk.core.util import platforms
 File "/Users/nazo/google-cloud-sdk/lib/googlecloudsdk/__init__.py", line 23, in <module>
 from googlecloudsdk.core.util import importing
 File "/Users/nazo/google-cloud-sdk/lib/googlecloudsdk/core/util/importing.py", line 23, in <module>
 import imp
 File "/opt/homebrew/Cellar/python@3.9/3.9.1_6/Frameworks/Python.framework/Versions/3.9/lib/python3.9/imp.py", line 23, in <module>
 from importlib import util
 File "/opt/homebrew/Cellar/python@3.9/3.9.1_6/Frameworks/Python.framework/Versions/3.9/lib/python3.9/importlib/util.py", line 2, in <module>
 from . import abc
 File "/opt/homebrew/Cellar/python@3.9/3.9.1_6/Frameworks/Python.framework/Versions/3.9/lib/python3.9/importlib/abc.py", line 17, in <module>
 from typing import Protocol, runtime_checkable
 File "/opt/homebrew/Cellar/python@3.9/3.9.1_6/Frameworks/Python.framework/Versions/3.9/lib/python3.9/typing.py", line 26, in <module>
 import re as stdlib_re # Avoid confusion with the re we export.
 File "/opt/homebrew/Cellar/python@3.9/3.9.1_6/Frameworks/Python.framework/Versions/3.9/lib/python3.9/re.py", line 124, in <module>
 import enum
 File "/Users/nazo/google-cloud-sdk/lib/third_party/enum/__init__.py", line 26, in <module>
 spec = importlib.util.find_spec('enum')
AttributeError: module 'importlib' has no attribute 'util'



curl でインストールするともう少し進みますが以下のエラーが出ます。
~ ❯❯❯ curl https://sdk.cloud.google.com | bash
（略）
Welcome to the Google Cloud SDK!

To help improve the quality of this product, we collect anonymized usage data
and anonymized stacktraces when crashes are encountered; additional information
is available at <https://cloud.google.com/sdk/usage-statistics>. This data is
handled in accordance with our privacy policy
<https://cloud.google.com/terms/cloud-privacy-notice>. You may choose to opt in this
collection now (by choosing 'Y' at the below prompt), or at any time in the
future by running the following command:

 gcloud config set disable_usage_reporting false

Do you want to help improve the Google Cloud SDK (y/N)?


This will install all the core command line tools necessary for working with
the Google Cloud Platform.

Beginning update. This process may take several minutes.
ERROR: (gcloud.components.update) The following components are unknown [anthoscli, kuberun].



これは anthoscli kuberun のコンポーネントがインストールできない（ gcloud components install anthoscli kuberun と同等）のが原因です。
回避するには、curl で上記エラーが出た時点で ~/google-cloud-sdk にファイル一式があるはずなので、移動して以下のように実行します。
~/google-cloud-sdk ❯❯❯ ./install.sh --override-components core gcloud-deps bq gcloud gsutil
Welcome to the Google Cloud SDK!

（略）

Your current Cloud SDK version is: 323.0.0
Installing components from version: 323.0.0

┌────────────────────────────────────────────────────────────────────────────┐
│ These components will be installed. │
├─────────────────────────────────────────────────────┬────────────┬─────────┤
│ Name │ Version │ Size │
├─────────────────────────────────────────────────────┼────────────┼─────────┤
│ BigQuery Command Line Tool │ 2.0.64 │ < 1 MiB │
│ BigQuery Command Line Tool (Platform Specific) │ 2.0.58 │ < 1 MiB │
│ Cloud SDK Core Libraries (Platform Specific) │ 2020.07.10 │ < 1 MiB │
│ Cloud Storage Command Line Tool │ 4.57 │ 3.5 MiB │
│ Cloud Storage Command Line Tool (Platform Specific) │ 4.51 │ < 1 MiB │
└─────────────────────────────────────────────────────┴────────────┴─────────┘

For the latest full release notes, please visit:
 https://cloud.google.com/sdk/release_notes

（略）

For more information on how to get started, please visit:
 https://cloud.google.com/sdk/docs/quickstarts



インストールに成功しました。
override-components で指定した引数は、以下で確認したものからエラーが出るものを抜いたものになります。
~/google-cloud-sdk ❯❯❯ cat bin/bootstrapping/.default_components
["core", "gcloud-deps", "bq", "gcloud", "gsutil", "anthoscli", "kuberun"]%



anthoscli も kuberun も、おそらく無くて困る人は多くないのではないかと思いますので、抜いてインストールしてしまっていいと思います。

M1(Apple Silicon) Mac に google-cloud-sdk を無理やりインストールする（2021/01/19時点）

今年は合計2社にお世話になりました。ところで<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%D5%A5%EA%A1%BC%A5%E9%A5%F3%A5%B9">フリーランス</a>で関わった会社名とか公表するものなのでしょうか？

<h1>関わり方</h1>

1社最大週2で、なるべく事業<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%C9%A5%E1%A5%A4%A5%F3">ドメイン</a>から遠いところをお手伝いする、というスタンスで働きました。事業<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%C9%A5%E1%A5%A4%A5%F3">ドメイン</a>に直接関わるものだと大抵はスピード感（主に緊急対応という意味で）が必要になるため、なるべくそこから遠いけど役に立つ内容で関われるものでお手伝いしております。

1社週2にしているのは、複数社の案件を同時に受けたいというのがありましたが、実際には私の<a class="keyword" href="http://d.hatena.ne.jp/keyword/%C3%CE%CC%BE%C5%D9">知名度</a>が足りなくそこまで仕事が回ってくることはありませんでした。数ヶ月だけ週2 x 2社の状態はありました。週5は疲れてしまうので当面はしない予定です。

原則として準委任契約による月額払いでの契約をお願いしております。これは私は一人でアプリを全部仕上げたりデザインを納品するような作業は得意としておらず、テクニカルな困りごとを<a class="keyword" href="http://d.hatena.ne.jp/keyword/%CE%D7%B5%A1%B1%FE%CA%D1">臨機応変</a>に対応するという内容を中心に活動しているためです。また原則フルリモートでお願いしております。

<h1><a class="keyword" href="http://d.hatena.ne.jp/keyword/Rails">Rails</a> によるアプリケーション開発 1社目</h1>

<a class="keyword" href="http://d.hatena.ne.jp/keyword/Rails">Rails</a> のバージョンを 4 -> 5 に上げる仕事、同時に Webpacker のバージョンも同様に上げる仕事を中心に行いました。

<a class="keyword" href="http://d.hatena.ne.jp/keyword/Rails">Rails</a> 側は元の書き方がそこそこ行儀が良い（ <a class="keyword" href="http://d.hatena.ne.jp/keyword/Rails">Rails</a> そのものを<a class="keyword" href="http://d.hatena.ne.jp/keyword/%CB%E2%B2%FE%C2%A4">魔改造</a>していない）ために問題になることは少なかったですが、Webpacker 側は動かないものが大量発生して大変でした。アップグレード作業は定形で引っかかる箇所もありますが、どちらかというと固有の事情を解決することが多そうなので、どれだけ全体を把握できるかが勝負になると思います。

<h1>Elixir ( <a class="keyword" href="http://d.hatena.ne.jp/keyword/Phoenix">Phoenix</a> ) + Vue ( Nuxt ) + <a class="keyword" href="http://d.hatena.ne.jp/keyword/AWS">AWS</a> EKS によるアプリケーション開発</h1>

Elixir 全く書いたことなかったのに誘っていただいて貴重な経験ができました。今年はほぼこの案件を中心に動いていました。実稼働している <a class="keyword" href="http://d.hatena.ne.jp/keyword/k8s">k8s</a> を触れたのも良い経験になりました。

Elixir はパターンマッチが強力なため、今までとはちょっと考え方を変えて書かないといけないところもあり、頭の体操的な面白さがありました。一方で <a class="keyword" href="http://d.hatena.ne.jp/keyword/Erlang">Erlang</a>/OTP 側がわからないと詰まるところもたまにあり、そのあたりの調査力はまだまだ不足していると感じました。あとドキュメントが少ないので大体<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%BD%A1%BC%A5%B9%A5%B3%A1%BC%A5%C9">ソースコード</a>を直接追うことが多いのも大変かなと思います。利用者がもっと増えてほしいところです。

アプリケーション側以外で大きくやったこととしては、以下のようなものがあります。

<ul>
<li>既存インフラの Terraform 化（Terraform Cloud）</li>
<li>ExUnit でのテスト整備</li>
<li>Lamnda@Edge での OIDC 認証</li>
<li>Headless <a class="keyword" href="http://d.hatena.ne.jp/keyword/CMS">CMS</a> の採用</li>
</ul>


特に Terraform 化では、既存のインフラとの整合性を保ちつつ IaC しやすい構造を作るというところで多少矛盾が生じるところもあり、落とし所を見つけるのが大変でした。「ここはインポートしたけど新しく追加しないで！」というような感じのコメントを残したりすることでなるべく今後も秩序を維持できるように残しておきました。

前職で<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A2%A1%BC%A5%AD%A5%C6%A5%AF%A5%C1%A5%E3">アーキテクチャ</a>設計やCI/CD設計などを全て自分がやるしかなかった経験が生かされ、ある程度構成を見ただけで実用的なTerraform分割の道筋がすぐ見えるようになったと思います。またCI/CDワークフローも整備し、誰でも安全にデプロイできるようにしておきました。

<h1>その他プライベートでやったようなこと</h1>

<h2>ECSのタスクスケジューラをどうにかしたかった</h2>

<a class="keyword" href="http://d.hatena.ne.jp/keyword/AWS">AWS</a> ECSの<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%D0%A5%C3%A5%C1%BD%E8%CD%FD">バッチ処理</a>をもう少し使いやすくできないかなーと試行錯誤し、Goでシンプルなスケジューラーでも書こうと思ったのですが、すぐにやる気が消えてしまったのでやめました。ECSの異常終了の検知が思ったより簡単だったのでそれでいいかなという感じもします。（ <a href="https://nazo.hatenablog.com/entry/slack-notify-ecs-stopped-task">AWS ECS&#x306E;&#x30BF;&#x30B9;&#x30AF;&#x304C;&#x7570;&#x5E38;&#x7D42;&#x4E86;&#x3057;&#x305F;&#x3089;&#x30ED;&#x30B0;URL&#x4ED8;&#x304D;&#x3067;Slack&#x306B;&#x901A;&#x77E5;&#x3059;&#x308B; - nazolabo</a> ）

現在は MWAA（ <a href="https://aws.amazon.com/jp/blogs/news/introducing-amazon-managed-workflows-for-apache-airflow-mwaa/">Amazon Managed Workflows for Apache Airflow (MWAA) &#x306E;&#x3054;&#x7D39;&#x4ECB; | Amazon Web Services &#x30D6;&#x30ED;&#x30B0;</a> ）も存在し、Airflow側でもawslogsから実行結果を取得する機能が入っていますので（<a href="https://note.com/dd_techblog/n/nfcc531d7587a">Airflow&#x306E;&#x30BF;&#x30B9;&#x30AF;&#x5B9F;&#x884C;&#x74B0;&#x5883;&#x3092;&#x5206;&#x96E2;&#x3059;&#x308B;&#xFF5C;Dentsu Digital Tech Blog&#xFF5C;note</a>）、ECSのタスクスケジューリングでは機能不足な場合でも困ることはないのではないかと思います。

<h2>Vue 3.0 （というか composition <a class="keyword" href="http://d.hatena.ne.jp/keyword/API">API</a>）</h2>

使うかどうかわからないのですが、Vue/Nuxtの最新を追うためにいくつかコードを書いていました。 <a href="https://github.com/nazo/binsen/pull/7">https://github.com/nazo/binsen/pull/7</a>

現在のVue/NuxtはReact/Nextの後追いになっている感じが強く、もともとNuxtのほうが実用性としては先行していたはずだったのにというところから、もっとReactとは違う良さを出していってほしいなという感じがします。とはいえ現時点でのフロントエンドはNextかNuxt以外は選択肢にはないと思います。

<h2>WebAssembly</h2>

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fnazo.hatenablog.com%2Fentry%2Frust-nes-wasm" title="rust-nesをwasm化した - nazolabo" class="embed-card embed-blogcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 190px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://nazo.hatenablog.com/entry/rust-nes-wasm">nazo.hatenablog.com</a></cite>

<h1>感想と今後</h1>

週2で開発業務は翌週に記憶が切れていることが多く、単純にもう1日やったほうがいいなと思うこと多かったので、事業<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%C9%A5%E1%A5%A4%A5%F3">ドメイン</a>から外れていてもなかなか厳しいと思いました。よほどピンポイントに専門的な内容を行う場合（技術顧問的な？）でない限り、週3はあったほうがいいのではないかと思います。

声をかけていただいた会社さんの中には良いポジションを提示してくれたところもあったのですが、週5・出勤あり・正社員でと言われるとお断りするしかないため、申し訳なく思うところもありました。とはいえ今の働き方が現時点では一番良いと思っているので、当面このままで続けていこうと思います。（将来的には変えるとは思います）

こちらから積極的に声をかけていないということもあり、残念ながら現在仕事が途切れてしまっている状態なので、現在積極的に仕事を募集しております。気軽にご連絡をお待ちしております。詳しくは <a href="https://gist.github.com/nazo/a6042a1ce09ed470a63c9f37132fef7b">&#x30DD;&#x30FC;&#x30C8;&#x30D5;&#x30A9;&#x30EA;&#x30AA; &middot; GitHub</a> をご覧下さい。

それでは来年も皆様宜しくお願い致します。

今年は合計2社にお世話になりました。ところでフリーランスで関わった会社名とか公表するものなのでしょうか？
関わり方
1社最大週2で、なるべく事業ドメインから遠いところをお手伝いする、というスタンスで働きました。事業ドメインに直接関わるものだと大抵はスピード感（主に緊急対応という意味で）が必要になるため、なるべくそこから遠いけど役に立つ内容で関われるものでお手伝いしております。
1社週2にしているのは、複数社の案件を同時に受けたいというのがありましたが、実際には私の知名度が足りなくそこまで仕事が回ってくることはありませんでした。数ヶ月だけ週2 x 2社の状態はありました。週5は疲れてしまうので当面はしない予定です。
原則として準委任契約による月額払いでの契約をお願いしております。これは私は一人でアプリを全部仕上げたりデザインを納品するような作業は得意としておらず、テクニカルな困りごとを臨機応変に対応するという内容を中心に活動しているためです。また原則フルリモートでお願いしております。
Rails によるアプリケーション開発 1社目
Rails のバージョンを 4 -> 5 に上げる仕事、同時に Webpacker のバージョンも同様に上げる仕事を中心に行いました。
Rails 側は元の書き方がそこそこ行儀が良い（ Rails そのものを魔改造していない）ために問題になることは少なかったですが、Webpacker 側は動かないものが大量発生して大変でした。アップグレード作業は定形で引っかかる箇所もありますが、どちらかというと固有の事情を解決することが多そうなので、どれだけ全体を把握できるかが勝負になると思います。
Elixir ( Phoenix ) + Vue ( Nuxt ) + AWS EKS によるアプリケーション開発
Elixir 全く書いたことなかったのに誘っていただいて貴重な経験ができました。今年はほぼこの案件を中心に動いていました。実稼働している k8s を触れたのも良い経験になりました。
Elixir はパターンマッチが強力なため、今までとはちょっと考え方を変えて書かないといけないところもあり、頭の体操的な面白さがありました。一方で Erlang/OTP 側がわからないと詰まるところもたまにあり、そのあたりの調査力はまだまだ不足していると感じました。あとドキュメントが少ないので大体ソースコードを直接追うことが多いのも大変かなと思います。利用者がもっと増えてほしいところです。
アプリケーション側以外で大きくやったこととしては、以下のようなものがあります。
既存インフラの Terraform 化（Terraform Cloud）
ExUnit でのテスト整備
Lamnda@Edge での OIDC 認証
Headless CMS の採用
特に Terraform 化では、既存のインフラとの整合性を保ちつつ IaC しやすい構造を作るというところで多少矛盾が生じるところもあり、落とし所を見つけるのが大変でした。「ここはインポートしたけど新しく追加しないで！」というような感じのコメントを残したりすることでなるべく今後も秩序を維持できるように残しておきました。
前職でアーキテクチャ設計やCI/CD設計などを全て自分がやるしかなかった経験が生かされ、ある程度構成を見ただけで実用的なTerraform分割の道筋がすぐ見えるようになったと思います。またCI/CDワークフローも整備し、誰でも安全にデプロイできるようにしておきました。
その他プライベートでやったようなこと
ECSのタスクスケジューラをどうにかしたかった
AWS ECSのバッチ処理をもう少し使いやすくできないかなーと試行錯誤し、Goでシンプルなスケジューラーでも書こうと思ったのですが、すぐにやる気が消えてしまったのでやめました。ECSの異常終了の検知が思ったより簡単だったのでそれでいいかなという感じもします。（ AWS ECSのタスクが異常終了したらログURL付きでSlackに通知する - nazolabo ）
現在は MWAA（ Amazon Managed Workflows for Apache Airflow (MWAA) のご紹介 | Amazon Web Services ブログ ）も存在し、Airflow側でもawslogsから実行結果を取得する機能が入っていますので（Airflowのタスク実行環境を分離する｜Dentsu Digital Tech Blog｜note）、ECSのタスクスケジューリングでは機能不足な場合でも困ることはないのではないかと思います。
Vue 3.0 （というか composition API）
使うかどうかわからないのですが、Vue/Nuxtの最新を追うためにいくつかコードを書いていました。 https://github.com/nazo/binsen/pull/7
現在のVue/NuxtはReact/Nextの後追いになっている感じが強く、もともとNuxtのほうが実用性としては先行していたはずだったのにというところから、もっとReactとは違う良さを出していってほしいなという感じがします。とはいえ現時点でのフロントエンドはNextかNuxt以外は選択肢にはないと思います。
WebAssembly
nazo.hatenablog.com
感想と今後
週2で開発業務は翌週に記憶が切れていることが多く、単純にもう1日やったほうがいいなと思うこと多かったので、事業ドメインから外れていてもなかなか厳しいと思いました。よほどピンポイントに専門的な内容を行う場合（技術顧問的な？）でない限り、週3はあったほうがいいのではないかと思います。
声をかけていただいた会社さんの中には良いポジションを提示してくれたところもあったのですが、週5・出勤あり・正社員でと言われるとお断りするしかないため、申し訳なく思うところもありました。とはいえ今の働き方が現時点では一番良いと思っているので、当面このままで続けていこうと思います。（将来的には変えるとは思います）
こちらから積極的に声をかけていないということもあり、残念ながら現在仕事が途切れてしまっている状態なので、現在積極的に仕事を募集しております。気軽にご連絡をお待ちしております。詳しくは ポートフォリオ · GitHub をご覧下さい。
それでは来年も皆様宜しくお願い致します。

2020年の仕事と技術の振り返り

<blockquote data-conversation="none" class="twitter-tweet" data-lang="ja"><a href="https://t.co/E2VxlwpIHi">https://t.co/E2VxlwpIHi</a> <a href="https://t.co/s4zLgpjhaX">pic.twitter.com/s4zLgpjhaX</a>&mdash; nazo (@nazo) <a href="https://twitter.com/nazo/status/1340250195045445632?ref_src=twsrc%5Etfw">2020年12月19日</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script> 

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2Fnazo%2Frust-nes-wasm" title="nazo/rust-nes-wasm" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.com/nazo/rust-nes-wasm">github.com</a></cite>

相変わらずOAM描画もキー入力も実装されていないのに<a class="keyword" href="http://d.hatena.ne.jp/keyword/NES">NES</a><a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%A8%A5%DF%A5%E5%A5%EC%A1%BC%A5%BF%A1%BC">エミュレーター</a>ってレベルじゃないだろという感じですが、ついでに元のrust-<a class="keyword" href="http://d.hatena.ne.jp/keyword/nes">nes</a>よりいくつか修正してwasmで動くようにしました。ちなみに元のバージョンは<a class="keyword" href="http://d.hatena.ne.jp/keyword/SDL">SDL</a>です。

<a href="https://github.com/rustwasm/wasm-pack">GitHub - rustwasm/wasm-pack: &#x1F4E6;&#x2728; your favorite rust -&gt; wasm workflow tool!</a> を使うと、手軽にRustでWebアプリケーションを書くことができます。コアになるライブラリは
<a href="https://github.com/rustwasm/wasm-bindgen">GitHub - rustwasm/wasm-bindgen: Facilitating high-level interactions between Wasm modules and JavaScript</a> なのですが、wasm-packはこれにWebpackなどを追加し、ホットリロード的なものとかを最初から提供してくれるものです。

<a href="https://rustwasm.github.io/docs/wasm-bindgen/examples/index.html">Examples - The `wasm-bindgen` Guide</a> が充実しており、今回必要だった<a class="keyword" href="http://d.hatena.ne.jp/keyword/canvas">canvas</a>やfetch、requestAnimationFrameなどはもちろん、<a class="keyword" href="http://d.hatena.ne.jp/keyword/WebGL">WebGL</a>やWebRTCのサンプルもあり、すぐに試すことが可能です。Rustが書ける方であればすぐに使えると思います。

WebAssemblyの現実的な用途としてはWeb的なものよりバイナリ操作的なものが中心になるのではないかと思うのですが、突然使うことになるかもしれないので今のうちに触っておいて損はしないのかなと思っています。

久々に触ってて面白かったので、もう少し機能を実装したいところです。

https://t.co/E2VxlwpIHi pic.twitter.com/s4zLgpjhaX
— nazo (@nazo) 2020年12月19日
  
github.com
相変わらずOAM描画もキー入力も実装されていないのにNESエミュレーターってレベルじゃないだろという感じですが、ついでに元のrust-nesよりいくつか修正してwasmで動くようにしました。ちなみに元のバージョンはSDLです。
GitHub - rustwasm/wasm-pack: 📦✨ your favorite rust -> wasm workflow tool! を使うと、手軽にRustでWebアプリケーションを書くことができます。コアになるライブラリは
GitHub - rustwasm/wasm-bindgen: Facilitating high-level interactions between Wasm modules and JavaScript なのですが、wasm-packはこれにWebpackなどを追加し、ホットリロード的なものとかを最初から提供してくれるものです。
Examples - The `wasm-bindgen` Guide が充実しており、今回必要だったcanvasやfetch、requestAnimationFrameなどはもちろん、WebGLやWebRTCのサンプルもあり、すぐに試すことが可能です。Rustが書ける方であればすぐに使えると思います。
WebAssemblyの現実的な用途としてはWeb的なものよりバイナリ操作的なものが中心になるのではないかと思うのですが、突然使うことになるかもしれないので今のうちに触っておいて損はしないのかなと思っています。
久々に触ってて面白かったので、もう少し機能を実装したいところです。

rust-nesをwasm化した

<a href="https://github.com/nuxt/http">https://github.com/nuxt/http</a> は実質 <a href="https://github.com/nuxt-community/axios-module">https://github.com/nuxt-community/axios-module</a> の後継に当たるもので、fetch <a class="keyword" href="http://d.hatena.ne.jp/keyword/API">API</a>をベースにした <a href="https://github.com/sindresorhus/ky">https://github.com/sindresorhus/ky</a> を利用しています。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fqiita.com%2Fil-m-yamagishi%2Fitems%2Fa823c1afbdf253e84a34" title="nuxt.js は axios を捨てて ky になる様子 - Qiita" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://qiita.com/il-m-yamagishi/items/a823c1afbdf253e84a34">qiita.com</a></cite>

<a href="https://http.nuxtjs.org/migration">Migration Guides - Http Module</a> を見てわかる通り、axios-module と比較しても名前が変わっただけのような作りになっており、置換だけでほぼ完全に移行することができますが、nuxt/http では <code>credentials: true</code> オプションが削除されています。今回はこれをどうしたらいいのかという話になります。

<h1>そもそも axios-module の <code>credentials: true</code> とは？</h1>

axios-module の <code>credentials: true</code> は、 <a class="keyword" href="http://d.hatena.ne.jp/keyword/XMLHttpRequest">XMLHttpRequest</a> に対し <code>withCredentials = true</code> をデフォルトで設定するためのオプションです。クロス<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%C9%A5%E1%A5%A4%A5%F3">ドメイン</a>で<a class="keyword" href="http://d.hatena.ne.jp/keyword/Cookie">Cookie</a>等の資格情報をXHR経由で渡す時に設定するものです。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fyamory.io%2Fblog%2Fabout-cors%2F" title="CORS &amp; Same Origin Policy 入門 | yamory Blog" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://yamory.io/blog/about-cors/">yamory.io</a></cite>

<code>withCredentials</code> オプションは XHR 固有のもののため、fetch <a class="keyword" href="http://d.hatena.ne.jp/keyword/API">API</a> には存在しません。代わりに <code>credentials = 'omit' | 'same-origin' | 'include'</code> というオプションが存在します。

<ul>
<li><code>omit</code> : 同一<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%C9%A5%E1%A5%A4%A5%F3">ドメイン</a>上でも資格情報が送られない</li>
<li><code>same-origin</code> : 同一<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%C9%A5%E1%A5%A4%A5%F3">ドメイン</a>上でのみ資格情報が送られる</li>
<li><code>include</code> : 全ての<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%C9%A5%E1%A5%A4%A5%F3">ドメイン</a>で資格情報が送られる</li>
</ul>


XHR での <code>withCredentials = false</code> が 'same-origin' で、 <code>withCredentials = true</code> が 'include' に該当します。（ただし polyfill を使うと <code>omit</code> に該当する XHR のオプションが存在しないために同一<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%C9%A5%E1%A5%A4%A5%F3">ドメイン</a>上では資格情報の送信が行われます）
なおサーバー側の <code>Access-Control-Allow-Credentials</code> 等は状況に応じて別途必要です。

<h1>nuxt/http で再現する</h1>

該当のオプションが存在しない nuxt/http で再現するには、デフォルト値を無理やり書き換える必要があります。<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%D7%A5%E9%A5%B0%A5%A4%A5%F3">プラグイン</a>で対応します。参考：<a href="https://github.com/nuxt/http/issues/92">Globally set options.Credentials &middot; Issue #92 &middot; nuxt/http &middot; GitHub</a>

<pre class="code lang-javascript" data-lang="javascript" data-unlink>export default ( { $http } ) =&gt; {
 $http._defaults.credentials = 'include'; 
}
</pre>


TypeScriptではプロパティにアクセスができないので、型を破壊して強引にプロパティを変更します。

<pre class="code lang-typescript" data-lang="typescript" data-unlink>import { defineNuxtPlugin } from '@nuxtjs/composition-api';
import { Context } from '@nuxt/types/app';

export default defineNuxtPlugin(({ $http }: Context) =&gt; {
 ($http as any)._defaults.credentials = 'include';
});
</pre>


<h1>まとめ</h1>

セキュリティ上の懸念点があるためにこのような対応が行われていると思いますので、強引に変えるのは良くないのではないかと思います。

nuxt/http では <code>setToken()</code> というメソッドが用意されており、 <code>Authorization</code> ヘッダをこちらでグローバルに指定することが可能です。こちらで資格情報を管理するのが良いのではないかと思いますが、axios-module と互換性があると言うのであれば credentials 指定があっても良かったのではないかと思います。

https://github.com/nuxt/http は実質 https://github.com/nuxt-community/axios-module の後継に当たるもので、fetch APIをベースにした https://github.com/sindresorhus/ky を利用しています。
qiita.com
Migration Guides - Http Module を見てわかる通り、axios-module と比較しても名前が変わっただけのような作りになっており、置換だけでほぼ完全に移行することができますが、nuxt/http では credentials: true オプションが削除されています。今回はこれをどうしたらいいのかという話になります。
そもそも axios-module の credentials: true とは？
axios-module の credentials: true は、 XMLHttpRequest に対し withCredentials = true をデフォルトで設定するためのオプションです。クロスドメインでCookie等の資格情報をXHR経由で渡す時に設定するものです。
yamory.io
withCredentials オプションは XHR 固有のもののため、fetch API には存在しません。代わりに credentials = 'omit' | 'same-origin' | 'include' というオプションが存在します。
omit : 同一ドメイン上でも資格情報が送られない
same-origin : 同一ドメイン上でのみ資格情報が送られる
include : 全てのドメインで資格情報が送られる
XHR での withCredentials = false が 'same-origin' で、 withCredentials = true が 'include' に該当します。（ただし polyfill を使うと omit に該当する XHR のオプションが存在しないために同一ドメイン上では資格情報の送信が行われます）
なおサーバー側の Access-Control-Allow-Credentials 等は状況に応じて別途必要です。
nuxt/http で再現する
該当のオプションが存在しない nuxt/http で再現するには、デフォルト値を無理やり書き換える必要があります。プラグインで対応します。参考：Globally set options.Credentials · Issue #92 · nuxt/http · GitHub
export default ( { $http } ) => {
    $http._defaults.credentials = 'include'; 
}



TypeScriptではプロパティにアクセスができないので、型を破壊して強引にプロパティを変更します。
import { defineNuxtPlugin } from '@nuxtjs/composition-api';
import { Context } from '@nuxt/types/app';

export default defineNuxtPlugin(({ $http }: Context) => {
  ($http as any)._defaults.credentials = 'include';
});



まとめ
セキュリティ上の懸念点があるためにこのような対応が行われていると思いますので、強引に変えるのは良くないのではないかと思います。
nuxt/http では setToken() というメソッドが用意されており、 Authorization ヘッダをこちらでグローバルに指定することが可能です。こちらで資格情報を管理するのが良いのではないかと思いますが、axios-module と互換性があると言うのであれば credentials 指定があっても良かったのではないかと思います。

nuxt/http で axios-module の credentials: true を再現する

<a href="https://gist.github.com/nazo/400638c53982b485b4865e3b2361ab45#file-gistfile1-txt">gistfile1.txt</a>
 <div class="js-gist-file-update-container js-task-list-container file-box">
 <div id="file-gistfile1-txt" class="file my-2">
 

 <div itemprop="text" class="Box-body p-0 blob-wrapper data type-text ">
 
<table class="highlight tab-size js-file-line-container" data-tab-size="8" data-paste-markdown-skip>
 <tr>
 <td id="file-gistfile1-txt-L1" class="blob-num js-line-number" data-line-number="1"></td>
 <td id="file-gistfile1-txt-LC1" class="blob-code blob-code-inner js-file-line">https://github.com/nuxt/nuxt.js/tree/dev/packages/types/app</td>
 </tr>
 <tr>
 <td id="file-gistfile1-txt-L2" class="blob-num js-line-number" data-line-number="2"></td>
 <td id="file-gistfile1-txt-LC2" class="blob-code blob-code-inner js-file-line">
</td>
 </tr>
 <tr>
 <td id="file-gistfile1-txt-L3" class="blob-num js-line-number" data-line-number="3"></td>
 <td id="file-gistfile1-txt-LC3" class="blob-code blob-code-inner js-file-line">ここにある</td>
 </tr>
</table>


 </div>

 </div>
</div>

gistfile1.txt
  

        https://github.com/nuxt/nuxt.js/tree/dev/packages/types/app
      

        

      

        ここにある

Nuxt.jsの型定義ファイル

<a href="https://gist.github.com/nazo/d2f765da5942b8d71797b188f20c4bb0#file-wsl2-md">wsl2.md</a>
 <div class="js-gist-file-update-container js-task-list-container file-box">
 <div id="file-wsl2-md" class="file my-2">
 
 <div id="file-wsl2-md-readme" class="Box-body readme blob js-code-block-container p-5 p-xl-6 ">
 <article class="markdown-body entry-content container-lg" itemprop="text"><h1><a id="user-content-wsl2でシェル補完が遅い時" class="anchor" aria-hidden="true" href="#wsl2でシェル補完が遅い時"><svg class="octicon octicon-link" viewBox="0 0 16 16" version="1.1" width="16" height="16" aria-hidden="true"><path fill-rule="evenodd" d="M7.775 3.275a.75.75 0 001.06 1.06l1.25-1.25a2 2 0 112.83 2.83l-2.5 2.5a2 2 0 01-2.83 0 .75.75 0 00-1.06 1.06 3.5 3.5 0 004.95 0l2.5-2.5a3.5 3.5 0 00-4.95-4.95l-1.25 1.25zm-4.69 9.64a2 2 0 010-2.83l2.5-2.5a2 2 0 012.83 0 .75.75 0 001.06-1.06 3.5 3.5 0 00-4.95 0l-2.5 2.5a3.5 3.5 0 004.95 4.95l1.25-1.25a.75.75 0 00-1.06-1.06l-1.25 1.25a2 2 0 01-2.83 0z"></path></svg></a>WSL2でシェル補完が遅い時</h1>
<a href="https://github.com/microsoft/WSL/issues/4234">https://github.com/microsoft/WSL/issues/4234</a>
/etc/wsl.conf に以下を記述する
<pre><code>[interop]
appendWindowsPath = false
</code></pre>
<h1><a id="user-content-windows起動時にwsl2を起動しないようにする" class="anchor" aria-hidden="true" href="#windows起動時にwsl2を起動しないようにする"><svg class="octicon octicon-link" viewBox="0 0 16 16" version="1.1" width="16" height="16" aria-hidden="true"><path fill-rule="evenodd" d="M7.775 3.275a.75.75 0 001.06 1.06l1.25-1.25a2 2 0 112.83 2.83l-2.5 2.5a2 2 0 01-2.83 0 .75.75 0 00-1.06 1.06 3.5 3.5 0 004.95 0l2.5-2.5a3.5 3.5 0 00-4.95-4.95l-1.25 1.25zm-4.69 9.64a2 2 0 010-2.83l2.5-2.5a2 2 0 012.83 0 .75.75 0 001.06-1.06 3.5 3.5 0 00-4.95 0l-2.5 2.5a3.5 3.5 0 004.95 4.95l1.25-1.25a.75.75 0 00-1.06-1.06l-1.25 1.25a2 2 0 01-2.83 0z"></path></svg></a>Windows起動時にWSL2を起動しないようにする</h1>
できなさそうなのでスタートアップに適当なバッチファイルを作って <code>wsl --shutdown</code> と書いておく
ちなみにシャットダウンした後の起動はWindows Terminalを起動するなりしてWSL2にアクセスしようとすると自動的に起動する
</article>
 </div>

 </div>
</div>

wsl2.md
  

WSL2でシェル補完が遅い時
https://github.com/microsoft/WSL/issues/4234
/etc/wsl.conf に以下を記述する
[interop]
appendWindowsPath = false


Windows起動時にWSL2を起動しないようにする
できなさそうなのでスタートアップに適当なバッチファイルを作って wsl --shutdown と書いておく
ちなみにシャットダウンした後の起動はWindows Terminalを起動するなりしてWSL2にアクセスしようとすると自動的に起動する

WSL2 小ネタ

<a href="https://github.com/nazo/rust-nes">GitHub - nazo/rust-nes: Rust NES Emulator (Work In Progress)</a> を <a class="keyword" href="http://d.hatena.ne.jp/keyword/Windows">Windows</a> の <a class="keyword" href="http://d.hatena.ne.jp/keyword/VSCode">VSCode</a> で<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%C7%A5%D0%A5%C3%A5%B0">デバッグ</a>しようとしたのですが、そのままではビルドが通りませんでした。

基本情報として、<a class="keyword" href="http://d.hatena.ne.jp/keyword/Windows">Windows</a> 上で <a class="keyword" href="http://d.hatena.ne.jp/keyword/Microsoft">Microsoft</a> <a class="keyword" href="http://d.hatena.ne.jp/keyword/C%2B%2B">C++</a>ツールセット（ <a class="keyword" href="http://d.hatena.ne.jp/keyword/Visual%20Studio">Visual Studio</a> のツールセット）を <a class="keyword" href="http://d.hatena.ne.jp/keyword/Visual%20Studio">Visual Studio</a> 以外から使うには、vcvarsall.bat を呼び出して<a class="keyword" href="http://d.hatena.ne.jp/keyword/%B4%C4%B6%AD%CA%D1%BF%F4">環境変数</a>を設定する必要があります。rust-<a class="keyword" href="http://d.hatena.ne.jp/keyword/nes">nes</a> は <a class="keyword" href="http://d.hatena.ne.jp/keyword/SDL">SDL</a> を使っていますので、当然 <a class="keyword" href="http://d.hatena.ne.jp/keyword/Windows">Windows</a> <a class="keyword" href="http://d.hatena.ne.jp/keyword/API">API</a> が呼び出せなければいけません。

<a class="keyword" href="http://d.hatena.ne.jp/keyword/VSCode">VSCode</a> のショートカットのプロパティを開き、「リンク先」を以下のように変更します。

<pre class="code" data-lang="" data-unlink>&#34;C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\Tools\VsDevCmd.bat&#34; -arch=amd64 &amp; &#34;C:\Program Files\Microsoft VS Code\Code.exe&#34;</pre>


パスは <a class="keyword" href="http://d.hatena.ne.jp/keyword/Visual%20Studio">Visual Studio</a> のバージョンなどでも変わるので、適宜自分の環境に合わせて書き換えてください。

launch.<a class="keyword" href="http://d.hatena.ne.jp/keyword/json">json</a> 側でどうにかする方法もあるとは思うのですが、多分これが一番早いと思います。

※ <a class="keyword" href="http://d.hatena.ne.jp/keyword/Windows">Windows</a> 環境にはあまり詳しくないので、用語などに多少の誤りがある可能性があります。

<h1>参考</h1>

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fdocs.microsoft.com%2Fja-jp%2Fcpp%2Fbuild%2Fbuilding-on-the-command-line%3Fview%3Dvs-2019" title="コマンド ラインから Microsoft C++ ツールセットを使用する" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://docs.microsoft.com/ja-jp/cpp/build/building-on-the-command-line?view=vs-2019">docs.microsoft.com</a></cite>

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fvscode-cpptools%2Fissues%2F278" title="Building/debugging using cmd/msvc 14 · Issue #278 · microsoft/vscode-cpptools" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.com/microsoft/vscode-cpptools/issues/278">github.com</a></cite>

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fgithub.com%2Fmicrosoft%2Fvscode-cpptools%2Fissues%2F1839" title="How to: Use VS Code with Visual C++ Build Tools · Issue #1839 · microsoft/vscode-cpptools" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;"></iframe><cite class="hatena-citation"><a href="https://github.com/microsoft/vscode-cpptools/issues/1839">github.com</a></cite>

GitHub - nazo/rust-nes: Rust NES Emulator (Work In Progress) を Windows の VSCode でデバッグしようとしたのですが、そのままではビルドが通りませんでした。
基本情報として、Windows 上で Microsoft C++ツールセット（ Visual Studio のツールセット）を Visual Studio 以外から使うには、vcvarsall.bat を呼び出して環境変数を設定する必要があります。rust-nes は SDL を使っていますので、当然 Windows API が呼び出せなければいけません。
VSCode のショートカットのプロパティを開き、「リンク先」を以下のように変更します。
"C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\Tools\VsDevCmd.bat" -arch=amd64 & "C:\Program Files\Microsoft VS Code\Code.exe"
パスは Visual Studio のバージョンなどでも変わるので、適宜自分の環境に合わせて書き換えてください。
launch.json 側でどうにかする方法もあるとは思うのですが、多分これが一番早いと思います。
※ Windows 環境にはあまり詳しくないので、用語などに多少の誤りがある可能性があります。
参考
docs.microsoft.com
github.com
github.com

最近のアップデート