github.com

突然興味が出てきて書きましたが特に実用性はありません。webtransport-goがそれなりに使えるのかどうか調べるために書いたものです。
webtransport-goは紆余曲折あって（？）quic-goに取り込まれたようですが、中のファイルがまだ github.com/marten-seemann/webtransport-go のままなので（2023年1月27日現在）、こちらの名前でimportするのが良いです。修正を投げようとも思いましたが関連する他リポジトリも全て変わっていないので、そのうち修正されるのを待とうと思います。
切断周りの対応はちゃんと書いていません。
チャットメッセージはUnidirectional Streamでやりとりしています。一部で話題のTwitchのWarpもUnidirectionalで実装されているようです。webtransport-goはDatagramはまだ未対応のようです。
WebTransport自体はコネクションさえ確立されれば後はQUICなので、どうしてもブラウザ上でやりたいことがなければ普通にQUICについて調査することをフォーカスしたほうが良さそうです。ブラウザならではで想定できそうなのはやはりWarpのような動画配信でしょうか。WebCodecsと組み合わせて実装するようです。
参考記事
qiita.com

github.com 突然興味が出てきて書きましたが特に実用性はありません。webtransport-goがそれなりに使えるのかどうか調べるために書いたものです。 webtransport-goは紆余曲折あって（？）quic-goに取り込まれたようですが、中のファイルがまだ github.com/marten-seemann/webtransport-go のままなので（2023年1月27日現在）、こちらの名前でimportするのが良いです。修正を投げようとも思いましたが関連する他リポジトリも全て変わっていないので、そのうち修正されるのを待とうと思います。 切断周りの対応はちゃんと書いていませ…

webtransport-goでチャットを作ってみた

<ul>
<li>2021年 : <a href="https://nazo.hatenablog.com/entry/2021-works">https://nazo.hatenablog.com/entry/2021-works</a></li>
<li>2020年 : <a href="https://nazo.hatenablog.com/entry/2020-works">https://nazo.hatenablog.com/entry/2020-works</a></li>
<li>2019年 : <a href="https://nazo.hatenablog.com/entry/goodbye-uuum">https://nazo.hatenablog.com/entry/goodbye-uuum</a></li>
</ul>


<h1 id="2022年の仕事">2022年の仕事</h1>

去年からの続きの仕事のみで、大きく話せるようなことは特にありません。仕事をしていないわけではないですが、一度区切りをつけて来年からは大幅縮小になる予定です。

<h1 id="近況">近況</h1>

2022年は引っ越したりしていました。一応首都圏ではあるものの、通勤することを完全に捨てた場所にいます。その代わり仕事部屋を手に入れたので、リモートワークで会議が頻繁に発生することにも対応できることになりました。

去年今年と辛いことが続いていますが、来年は本厄らしいのでもうだめかもしれません。がんばります。

<h1 id="まとめ">まとめ</h1>

今後はブログを中心に情報発信を行っていこうと思います。技術的な話は <a href="https://zenn.dev/nazo">Zenn</a> にも転載していますので、技術的な話のみ読みたい方はそちらをフォローしてください。

来年からの予定は今のところ未定なので、週２〜３くらいでの案件を引き続き募集しております。詳しくは
<a href="https://nazo.dev/">https://nazo.dev/</a> をご覧下さい。

2021年 : https://nazo.hatenablog.com/entry/2021-works
2020年 : https://nazo.hatenablog.com/entry/2020-works
2019年 : https://nazo.hatenablog.com/entry/goodbye-uuum
2022年の仕事
去年からの続きの仕事のみで、大きく話せるようなことは特にありません。仕事をしていないわけではないですが、一度区切りをつけて来年からは大幅縮小になる予定です。
近況
2022年は引っ越したりしていました。一応首都圏ではあるものの、通勤することを完全に捨てた場所にいます。その代わり仕事部屋を手に入れたので、リモートワークで会議が頻繁に発生することにも対応できることになりました。
去年今年と辛いことが続いていますが、来年は本厄らしいのでもうだめかもしれません。がんばります。
まとめ
今後はブログを中心に情報発信を行っていこうと思います。技術的な話は Zenn にも転載していますので、技術的な話のみ読みたい方はそちらをフォローしてください。
来年からの予定は今のところ未定なので、週２〜３くらいでの案件を引き続き募集しております。詳しくは
https://nazo.dev/ をご覧下さい。

2021年 : https://nazo.hatenablog.com/entry/2021-works 2020年 : https://nazo.hatenablog.com/entry/2020-works 2019年 : https://nazo.hatenablog.com/entry/goodbye-uuum 2022年の仕事 去年からの続きの仕事のみで、大きく話せるようなことは特にありません。仕事をしていないわけではないですが、一度区切りをつけて来年からは大幅縮小になる予定です。 近況 2022年は引っ越したりしていました。一応首都圏ではあるものの、通勤することを完全に捨てた場所に…

2022年の仕事と近況

<h1 id="概要">概要</h1>

modules / envs / apps で<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%C7%A5%A3%A5%EC%A5%AF%A5%C8">ディレクト</a>リを切っています。

<h1 id="基礎知識-modules-と-envs">基礎知識： modules と envs</h1>

誰が言い出したのかはわかりませんが、modules と envs に分けるパターンはよく見かけます。

modules は文字通りモジュールを配置するところで、 envs はそれらを使う環境が入っているという感じです。

<pre class="code" data-lang="" data-unlink>.
├── modules
│ ├── vpc
│ ├── app
│ └── db
└── envs
 ├── production
 └── staging</pre>


modules の抽象度は、 <a href="https://12factor.net/ja/backing-services">12 factor app の バックエンドサービス</a> くらいのイメージを持っていればいいのではないかと思います。<a class="keyword" href="http://d.hatena.ne.jp/keyword/VPC">VPC</a> みたいな基盤は特殊として、それ以外は「外しても使える程度」を意識するのが良いと思います。

一般的に envs で書かれる tf は、modules を呼び出すだけにしておくのが良いと思います。直接リソースを書くのは最終手段です。

<h1 id="modules-と-envs-はわかるけど-apps-って何">modules と envs はわかるけど apps って何？</h1>

全環境で <a class="keyword" href="http://d.hatena.ne.jp/keyword/VPC">VPC</a> も DB も分けるなら必要ないですが、「複数のアプリで同一の DB を参照したい」というケースは多々あります。進捗が別々の環境を同時に作りたい場合などです。また、費用を節約するために同一の DB リソースを共有するという場合もあります。

そのような状況を考えた時、「土台のバックエンドサービスと、自分で書いたアプリケーションは別の扱いにしたほうがいいのでは」となりました。この「土台のバックエンドサービス」が「envs」で、「自分で書いたアプリケーション」が「apps」になります。

「envs」は、<a class="keyword" href="http://d.hatena.ne.jp/keyword/VPC">VPC</a> や DB などがまとまったもので、「apps」はデプロイ単位で分けることになります。これにより、１つの <a class="keyword" href="http://d.hatena.ne.jp/keyword/VPC">VPC</a> や DB に、複数のアプリケーションを同居させることが簡単になります。

<pre class="code" data-lang="" data-unlink>.
├── modules
│ ├── vpc
│ ├── app
│ └── db
├── apps
│ ├── staging
│ ├── production
│ └── featurexxxx
└── envs
 ├── production
 └── staging</pre>


「envs」以下より「apps」以下のほうが必ず数が多くなります。また、「apps」は「envs」の設定に依存しますが、逆の依存は必ず存在しないようにします。

概要
modules / envs / apps でディレクトリを切っています。
基礎知識： modules と envs
誰が言い出したのかはわかりませんが、modules と envs に分けるパターンはよく見かけます。
modules は文字通りモジュールを配置するところで、 envs はそれらを使う環境が入っているという感じです。
.
├── modules
│   ├── vpc
│   ├── app
│   └── db
└── envs
    ├── production
    └── staging
modules の抽象度は、 12 factor app の バックエンドサービス くらいのイメージを持っていればいいのではないかと思います。VPC みたいな基盤は特殊として、それ以外は「外しても使える程度」を意識するのが良いと思います。
一般的に envs で書かれる tf は、modules を呼び出すだけにしておくのが良いと思います。直接リソースを書くのは最終手段です。
modules と envs はわかるけど apps って何？
全環境で VPC も DB も分けるなら必要ないですが、「複数のアプリで同一の DB を参照したい」というケースは多々あります。進捗が別々の環境を同時に作りたい場合などです。また、費用を節約するために同一の DB リソースを共有するという場合もあります。
そのような状況を考えた時、「土台のバックエンドサービスと、自分で書いたアプリケーションは別の扱いにしたほうがいいのでは」となりました。この「土台のバックエンドサービス」が「envs」で、「自分で書いたアプリケーション」が「apps」になります。
「envs」は、VPC や DB などがまとまったもので、「apps」はデプロイ単位で分けることになります。これにより、１つの VPC や DB に、複数のアプリケーションを同居させることが簡単になります。
.
├── modules
│   ├── vpc
│   ├── app
│   └── db
├── apps
│   ├── staging
│   ├── production
│   └── featurexxxx
└── envs
    ├── production
    └── staging
「envs」以下より「apps」以下のほうが必ず数が多くなります。また、「apps」は「envs」の設定に依存しますが、逆の依存は必ず存在しないようにします。

最近の Terraform のディレクトリ構造の分け方について解説します。

最近の Terraform のディレクトリ構造の分け方

git に pre-commit hook という、コミット直前に何かのプログラムを実行する機能があります。これを用いて lint や test を実行したりすることがありますが、この利用は極力避けたほうが良いのではと考えています。

<h1 id="なぜ">なぜ？</h1>

<ul>
<li>個人の環境で実行した結果は信用できない</li>
<li>ローカルコンピューターで待たせてはいけない</li>
<li>pre-commit の挙動や中断などで動作が怪しくなることがある</li>
</ul>


<h1 id="個人の環境で実行した結果は信用できない">個人の環境で実行した結果は信用できない</h1>

全員が完全に同じ環境で pre-commit hook を実行しているかは誰にもわかりません。言語やライブラリのバージョンに差がある可能性もあります。また、hook をスキップする方法もあります。

それだけを信用してチェックを行ったと判断するのは危険であるため、CI で実行することを優先すべきです。

<h1 id="ローカルコンピューターで待たせてはいけない">ローカルコンピューターで待たせてはいけない</h1>

チェック項目が増えると、hook の実行時間も増えます。

あくまで hook で行う処理の大半はガードレールなので、ちゃんと書いていれば一発通過するはずで、そのために毎回各自が待たされるのは無駄です。

チェック内容に自信がなければコミット前に手動実行すると思いますので、それでチェックが通っても pre-commit hook は実行され、さらに時間をかけてしまいます。

チェックに時間がかかりすぎるようになると、チェックを迂回するための策を考えてしまう可能性があります。

チェックが通る前提でコードを書き、素早く push して開発を効率化しましょう。

<h1 id="pre-commit-の挙動や中断などで動作が怪しくなることがある">pre-commit の挙動や中断などで動作が怪しくなることがある</h1>

ライブラリの更新などで pre-commit hook がアップデートされた場合などや、極端にリビジョンに差があって pre-commit の挙動に差があるブランチに切り替えた場合などに、pre-commit <a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%B9%A5%AF%A5%EA%A5%D7%A5%C8">スクリプト</a>とライブラリが一致していない等でおかしな挙動をすることがあります。他にも様々な理由で予期せぬ結果を起こすことがあります。

git commit に機能を追加してしまうことで、 git commit 時に git commit 以外のことを考える必要が出てきます。

<h1 id="そんなこと言っても変なコードが-push-されたらどうするの">そんなこと言っても変なコードが push されたらどうするの？</h1>

CI で防げばいいです。そのための CI です。

CI と同等の動作を「任意で」ローカルで実行できることは必要ですが、最終判断はあくまで CI にやらせましょう。

CI で必ずチェックすることで、変なコードがマージされるのを確実に防ぐことができます。また、常に同じ環境である CI に実行させることによって、環境ごとで結果に違いが出るといった現象も防ぐことができます。

<h1 id="その割には有名なライブラリたくさんあるし使っている人もいっぱいいるよ">その割には有名なライブラリたくさんあるし使っている人もいっぱいいるよ！</h1>

<a href="https://rubygems.org/gems/pre-commit/versions/0.31.0?locale=ja">Ruby の pre-commit gem</a> や nodejs の <a href="https://github.com/typicode/husky">Husky</a> + <a href="https://github.com/okonet/lint-staged">lint-staged</a> などがあり、特に nodejs 界隈ではボイラープレートに組み込まれていたりします。

どれも有名かつ人気があるので使うべきかと思いますが、「出来がよく実用しても問題ないから人気である」と「必ず使う必要がある」は全く関係がありません。これまでの理由により、基本的には使う必要はないものです。

どうしても忘れっぽい人やチェックする習慣がない初学者は任意で有効化して利用する、というのはありかもしれませんが、強制するものではないと思います。

リモートに push されること自体が望ましくないものを防ぐ場合は使って良いと思います。例えば <a href="https://github.com/awslabs/git-secrets">git-secrets</a> のようなものです。一般的な lint エラーやテストの失敗といったものはリモートに push されても何の問題もありません。誰もマージできないだけです。

<h1 id="まとめ">まとめ</h1>

よほどの理由がない限り、pre-commit hookは使わないほうがいいと思ったほうが良いでしょう。各自の判断で手動実行 + 必ず CI でチェック、でほとんどの場合は十分です。絶対に使うなというわけではないですが、なぜ pre-commit hook を使う必要があるのか、何のために使うのかをよく考えて利用しましょう。

<h1 id="参考">参考</h1>

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.thoughtworks.com%2Finsights%2Fblog%2Fpre-commit-don-t-git-hooked" title="Pre-commit: Don’t git hooked!" class="embed-card embed-webcard" scrolling="no" frameborder="0" style="display: block; width: 100%; height: 155px; max-width: 500px; margin: 10px 0px;" loading="lazy"></iframe><cite class="hatena-citation"><a href="https://www.thoughtworks.com/insights/blog/pre-commit-don-t-git-hooked">www.thoughtworks.com</a></cite>

git に pre-commit hook という、コミット直前に何かのプログラムを実行する機能があります。これを用いて lint や test を実行したりすることがありますが、この利用は極力避けたほうが良いのではと考えています。
なぜ？
個人の環境で実行した結果は信用できない
ローカルコンピューターで待たせてはいけない
pre-commit の挙動や中断などで動作が怪しくなることがある
個人の環境で実行した結果は信用できない
全員が完全に同じ環境で pre-commit hook を実行しているかは誰にもわかりません。言語やライブラリのバージョンに差がある可能性もあります。また、hook をスキップする方法もあります。
それだけを信用してチェックを行ったと判断するのは危険であるため、CI で実行することを優先すべきです。
ローカルコンピューターで待たせてはいけない
チェック項目が増えると、hook の実行時間も増えます。
あくまで hook で行う処理の大半はガードレールなので、ちゃんと書いていれば一発通過するはずで、そのために毎回各自が待たされるのは無駄です。
チェック内容に自信がなければコミット前に手動実行すると思いますので、それでチェックが通っても pre-commit hook は実行され、さらに時間をかけてしまいます。
チェックに時間がかかりすぎるようになると、チェックを迂回するための策を考えてしまう可能性があります。
チェックが通る前提でコードを書き、素早く push して開発を効率化しましょう。
pre-commit の挙動や中断などで動作が怪しくなることがある
ライブラリの更新などで pre-commit hook がアップデートされた場合などや、極端にリビジョンに差があって pre-commit の挙動に差があるブランチに切り替えた場合などに、pre-commit スクリプトとライブラリが一致していない等でおかしな挙動をすることがあります。他にも様々な理由で予期せぬ結果を起こすことがあります。
git commit に機能を追加してしまうことで、 git commit 時に git commit 以外のことを考える必要が出てきます。
そんなこと言っても変なコードが push されたらどうするの？
CI で防げばいいです。そのための CI です。
CI と同等の動作を「任意で」ローカルで実行できることは必要ですが、最終判断はあくまで CI にやらせましょう。
CI で必ずチェックすることで、変なコードがマージされるのを確実に防ぐことができます。また、常に同じ環境である CI に実行させることによって、環境ごとで結果に違いが出るといった現象も防ぐことができます。
その割には有名なライブラリたくさんあるし使っている人もいっぱいいるよ！
Ruby の pre-commit gem や nodejs の Husky + lint-staged などがあり、特に nodejs 界隈ではボイラープレートに組み込まれていたりします。
どれも有名かつ人気があるので使うべきかと思いますが、「出来がよく実用しても問題ないから人気である」と「必ず使う必要がある」は全く関係がありません。これまでの理由により、基本的には使う必要はないものです。
どうしても忘れっぽい人やチェックする習慣がない初学者は任意で有効化して利用する、というのはありかもしれませんが、強制するものではないと思います。
リモートに push されること自体が望ましくないものを防ぐ場合は使って良いと思います。例えば git-secrets のようなものです。一般的な lint エラーやテストの失敗といったものはリモートに push されても何の問題もありません。誰もマージできないだけです。
まとめ
よほどの理由がない限り、pre-commit hookは使わないほうがいいと思ったほうが良いでしょう。各自の判断で手動実行 + 必ず CI でチェック、でほとんどの場合は十分です。絶対に使うなというわけではないですが、なぜ pre-commit hook を使う必要があるのか、何のために使うのかをよく考えて利用しましょう。
参考
www.thoughtworks.com

git に pre-commit hook という、コミット直前に何かのプログラムを実行する機能があります。これを用いて lint や test を実行したりすることがありますが、この利用は控えたほうが良いと考えています。ここではその詳しい理由を説明します。

git の pre-commit hook はなるべく使わないほうがいいのでは

<ul>
<li>2020年 : <a href="https://nazo.hatenablog.com/entry/2020-works">https://nazo.hatenablog.com/entry/2020-works</a></li>
<li>2019年 : <a href="https://nazo.hatenablog.com/entry/goodbye-uuum">https://nazo.hatenablog.com/entry/goodbye-uuum</a></li>
</ul>


<h1>Go による <a class="keyword" href="http://d.hatena.ne.jp/keyword/API">API</a> サーバーと React による管理画面開発</h1>

Go で gRPC サーバーを作りつつ、 React と gqlgen で 管理画面を作るというような内容でした。

都合により短期でしか関われなかったのですが、あまりお目にかかれない環境での開発で非常に楽しい経験をさせて頂きました。

<h1>株式会社ハグカム　様</h1>

<a href="https://www.global-crown.com/">GLOBAL CROWN</a> という子ども向け英会話サービスを提供しております。<a href="https://prtimes.jp/main/html/rd/p/000000004.000019731.html">今年初めに資金調達も行っており</a> 、絶賛成長中のサービスになっております。

私も少しだけお世話になっており、主にコア<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%C9%A5%E1%A5%A4%A5%F3">ドメイン</a>からは少し距離を置いたものを中心に、以下のような内容を行っておりました。

<ul>
<li>GCE で動いていたインフラを Cloud Run に移行</li>
<li>インフラの Terraform 化</li>
<li>linter を整備してコード品質を上げる</li>
<li>CI / CD の整備</li>
<li>負荷チューニング</li>
<li>Docker 開発環境の整備</li>
<li>言語や<a class="keyword" href="http://d.hatena.ne.jp/keyword/%A5%D5%A5%EC%A1%BC%A5%E0%A5%EF%A1%BC%A5%AF">フレームワーク</a>のアップグレード</li>
</ul>


サーバーサイドの言語としては <a class="keyword" href="http://d.hatena.ne.jp/keyword/PHP">PHP</a> と <a class="keyword" href="http://d.hatena.ne.jp/keyword/Ruby">Ruby</a> を利用しており、久々に長期で <a class="keyword" href="http://d.hatena.ne.jp/keyword/PHP">PHP</a> を触っていました。

また、<a href="https://www.hugcome.co.jp/">コーポレートサイト</a> を Next.js + Netlify で SSG 化したり、未公開の内容についての対応なども行っておりました。

今年は仕事以外のところでいろいろあったのですが、ハグカム様にはかなり融通を利かせて頂いて助かりました。

<a class="keyword" href="http://d.hatena.ne.jp/keyword/Rails">Rails</a> エンジニアや Flutter エンジニアなどを積極的に採用中ですので、興味があれば以下から応募するか私までご連絡下さい。

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.hugcome.co.jp%2Fengineer" title="ソフトウェアエンジニア | 株式会社ハグカム" 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://www.hugcome.co.jp/engineer">www.hugcome.co.jp</a></cite>

<iframe src="https://hatenablog-parts.com/embed?url=https%3A%2F%2Fwww.green-japan.com%2Fcompany%2F8109" title="株式会社 ハグカム | IT/Web業界への転職ならGreen(グリーン)" 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://www.green-japan.com/company/8109">www.green-japan.com</a></cite>

<h1>まとめ</h1>

今年はプライベートで良くないことが続く年でしたが、来年後半からはまた良い状況が生まれてくるはずなので、そこから活動を増やしていきたいと考えています。

引き続きお仕事を募集しております。詳細は <a href="https://nazo.dev/profile">https://nazo.dev/profile</a> をご覧下さい。

2020年 : https://nazo.hatenablog.com/entry/2020-works
2019年 : https://nazo.hatenablog.com/entry/goodbye-uuum
Go による API サーバーと React による管理画面開発
Go で gRPC サーバーを作りつつ、 React と gqlgen で 管理画面を作るというような内容でした。
都合により短期でしか関われなかったのですが、あまりお目にかかれない環境での開発で非常に楽しい経験をさせて頂きました。
株式会社ハグカム　様
GLOBAL CROWN という子ども向け英会話サービスを提供しております。今年初めに資金調達も行っており 、絶賛成長中のサービスになっております。
私も少しだけお世話になっており、主にコアドメインからは少し距離を置いたものを中心に、以下のような内容を行っておりました。
GCE で動いていたインフラを Cloud Run に移行
インフラの Terraform 化
linter を整備してコード品質を上げる
CI / CD の整備
負荷チューニング
Docker 開発環境の整備
言語やフレームワークのアップグレード
サーバーサイドの言語としては PHP と Ruby を利用しており、久々に長期で PHP を触っていました。
また、コーポレートサイト を Next.js + Netlify で SSG 化したり、未公開の内容についての対応なども行っておりました。
今年は仕事以外のところでいろいろあったのですが、ハグカム様にはかなり融通を利かせて頂いて助かりました。
Rails エンジニアや Flutter エンジニアなどを積極的に採用中ですので、興味があれば以下から応募するか私までご連絡下さい。
www.hugcome.co.jp
www.green-japan.com
まとめ
今年はプライベートで良くないことが続く年でしたが、来年後半からはまた良い状況が生まれてくるはずなので、そこから活動を増やしていきたいと考えています。
引き続きお仕事を募集しております。詳細は https://nazo.dev/profile をご覧下さい。

2020年 : https://nazo.hatenablog.com/entry/2020-works 2019年 : https://nazo.hatenablog.com/entry/goodbye-uuum Go による API サーバーと React による管理画面開発 Go で gRPC サーバーを作りつつ、 React と gqlgen で 管理画面を作るというような内容でした。 都合により短期でしか関われなかったのですが、あまりお目にかかれない環境での開発で非常に楽しい経験をさせて頂きました。 株式会社ハグカム 様 GLOBAL CROWN という子ども向け英会話サービスを提供…

2021年の仕事まとめ

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 では UUID 型がデフォルトでサポートされているのですが、それとは別に ULID を使う方法を解説します。 ULID の実装は https://github.com/oklog/ulid を使用します。 ent の UUID 型は、driver.Valuer Interface を利用して値を取得しますが、 oklog/ulid の Value() の実装がバイナリを返却するようになっているため、このままでは可読性が悪いです。 Value() が String を返すようにした ULID 型を新たに定義するのが良いでしょう。そのようにすると、他の interface も実装する必要が…

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 ツールに慣れておく必要や、クラウドインフラの使い方に慣れておく必要がありますので、そこは基礎教養として素振りしておきましょう。

最近不慣れな GCP を触ることがあったのですが、最初から Terraform で書くようにしたほうが楽だったので、それについて解説しようと思います。 Web のコンソールを触るのが怖い 他のサービスが同居しているアカウントでインフラを操作すると、他のサービスに影響を与えてしまうのでは…という不安があります。関係のないサービスは別アカウントにするというのがベストプラクティスですが、様々な事情によりそれができない場合もあります。 最初から 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エンジニアをしておりますが、プロジェクトに新規に入った時にどういう点を確認しているのかをまとめておきたいと思います。

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 も、おそらく無くて困る人は多くないのではないかと思いますので、抜いてインストールしてしまっていいと思います。

公式からダウンロードしてきた 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/boot…

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

<ul>
<li>2019年 : <a href="https://nazo.hatenablog.com/entry/goodbye-uuum">https://nazo.hatenablog.com/entry/goodbye-uuum</a></li>
</ul>


今年は合計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> をご覧下さい。

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

2019年 : https://nazo.hatenablog.com/entry/goodbye-uuum
今年は合計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 をご覧下さい。
それでは来年も皆様宜しくお願い致します。

2019年 : https://nazo.hatenablog.com/entry/goodbye-uuum 今年は合計2社にお世話になりました。ところでフリーランスで関わった会社名とか公表するものなのでしょうか？ 関わり方 1社最大週2で、なるべく事業ドメインから遠いところをお手伝いする、というスタンスで働きました。事業ドメインに直接関わるものだと大抵はスピード感（主に緊急対応という意味で）が必要になるため、なるべくそこから遠いけど役に立つ内容で関われるものでお手伝いしております。 1社週2にしているのは、複数社の案件を同時に受けたいというのがありましたが、実際には私の知名度が足りなくそこま…

なぞらぼ

なぞらぼ by nazo

Webシステム開発

Webインフラ構築（AWS, GCP）

Webインフラ保守

技術顧問

最近のアップデート