<code>$ rm go.sum</code>を実行して go.sum ファイルを一度削除します。

1.go.sumファイルを削除する

<code>$ go clean -modcache</code>go.sum ファイルを削除してもキャッシュが残ってる場合はエラーになるようなので、キャッシュを削除します。

2.キャッシュを削除する

<code>$ go mod tidy</code>を実行してエラーが発生しなければ完了です。

3. go mod tidy でエラーが出なければ成功

<code>$ go mod tidy</code> した際に以下のエラーが出た場合には、再度手順1から実行直してください。 <pre><code>/project # go mod tidy
go: downloading github.com/mattn/go-sqlite3 v1.14.14
verifying github.com/klauspost/compress@v1.15.6: zip: not a valid zip file</code></pre>

※再度 go mod tidy でエラーが発生した場合

【Go言語】go mod tidy, go generateで エラーが発生した時の対処法

Dockerは、ソフトウェアをコンテナという単位でパッケージ化するためのプラットフォームです。コンテナは、アプリケーションとその依存関係を一緒に包み込むことで、アプリケーションがどの環境でも同じように動作することを保証します。

Dockerとは何か？

Dockerの主な利点は、開発とデプロイメントのプロセスを簡素化することです。Dockerを使用すると、開発者はローカルマシン上でアプリケーションを開発し、そのまま本番環境にデプロイすることもできます。

Dockerの利点

Dockerを使用する基本的なステップは次のとおりです <ol><li>Dockerfileを作成します。これは、コンテナイメージを作成するためのレシピです。</li><li>docker buildコマンドを使用して、Dockerfileからコンテナイメージを作成します。</li><li>docker runコマンドを使用して、コンテナイメージからコンテナを起動します。</li></ol>

Dockerの基本的な使い方

以上がDockerの基本的な概要と使い方です。詳細な情報は<a href="https://docs.docker.com/" target="_blank" rel="noopener noreferrer">Dockerの公式ドキュメンテーション</a>をご覧ください。Dockerを使って、より効率的な開発プロセスを体験しましょう。 それでは、次回の記事でお会いしましょう！

まとめ

Dockerって何のために使うの？そもそも何ができるの？

Docker入門：超初心者向けガイド

これについては2通りの考え方があります。一つは、「古典学派」と言われるグループの考え方で、一つのテストシナリオを「単体」として扱います。DBやファイル出力、外部システムへのメッセージ送信などの「共有依存」については、そのまま使うと他のテストシナリオに影響を与えてしまうため、モックを使用します。もう一つは、「ロンドン学派」と言われるグループの考え方で、一つのクラスを「単体」として扱います。こちらは共有依存だけでなく、すべての「協力者オブジェクト」をモックに置き換えることで、対象のクラスの振る舞いのみに着目します。本書では、良いテストを構成する4本の柱を示していますが、ロンドン学派の考え方だとテストコードが実装の詳細に依存しすぎてしまい、4本の柱のうちの一つであり、かつ最も重要な特性とされる「リファクタリング耐性」を損なってしまうため、古典学派の考え方を推奨しています。古典学派のスタイルで記述する単体テストは、DDDで言うところの、最も上位層のドメインサービスやエンティティなどを対象として扱うテストのことだと自分は理解しています。 ちなみに、4本の柱とは以下のことです。<ul><li>リファクタリング耐性</li><li>退行からの保護</li><li>迅速なフィードバック</li><li>保守のしやすさ</li></ul>このうち迅速なフィードバックとは、テストをした際に結果がすぐに返ってくる、つまり実行時間が短いという性質を示します。単体テストでは共有依存を使わないため、この性質については必然的にほぼ満たされた状態になります。 テスト結果と実際の振る舞いの組み合わせパターンは、以下の4パターンがあります。（下図を参照）<ul><li>テストが成功し、かつ実際の振る舞いも正しい場合、それは仕様を満たしているということなので真の陰性です。</li><li>逆に、テストが失敗し、かつ実際の振る舞いも正しくない場合、それはテストが正しくコードの不正を検出しているということなので、真の陽性です。</li><li>テストが成功しているのにもかかわらず、実際の振る舞いが正しくない場合は偽陰性となり、テストがコードの不正を検出できていないということで、多くの場合退行からの保護が十分にできていないということになります。</li><li>テストが失敗しているのにもかかわらず実際の振る舞いが正しい場合は偽陽性となり、テストが壊れた状態を意味します。これはテストが実装の詳細に依存してしまっており、リファクタリングによって依存関係が破壊されるのが原因です。</li></ul>以上から、良いテストとは偽陰性と偽陽性の可能性を極力排除したものであることがわかります。またそのためには、4本の柱のうちの2本、つまり退行からの保護とリファクタリング耐性を兼ね備えたテストであることが必要であることもわかります。 <img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/e2658b277e13430d83249fe040047550/fact.png" alt="">

古典学派とロンドン学派

どこまでを「単体」とすべきか

すべてのコードは以下の図の4つのエリアのうちのどこかに位置します。綺麗にコードの役割分担ができていれば、右上以外のエリアにすべてのコードが属するようになります。そのようなコードは、テストコードも簡潔に書けるため4本の柱の一つである、保守のしやすさを備えたテストになります。このうち、テストに価値をもたらすのは左上と、右下に位置するコードです。左下に関してはシナリオ内でテストするか、場合によっては全くテストしなくても問題になることはほとんどありません。ロジックが単純なため間違える可能性が低く、かつドメインにおける重要性も低いためです。左上は単体テストで確認し、共有依存はすべてモックに置き換えます。右下は統合テストで確認し、外部から直接参照できる共有依存はモックに置き換えます。外部から直接参照できない共有依存の代表はDBであり、インターフェースを退行から保護する必要性がないためモックに置き換える必要がありません。その場合、事前準備フェーズで他のテストケースに影響が出ないように状態をリセットする必要があります。なおテストの種類には他にもE2Eテストがあります。E2Eテストはユーザの視点で行うテストであり、外部から直接参照できる共有依存も含めて全てのオブジェクトをそのまま扱います。E2Eテストに関しては外部に影響を与えてしまうことが避けられないため、個人的にはテストコードとして実装することは困難だと思います。 <img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/10f5d472a5154f45a601dcf1acbe1f1e/codetype.png" alt="">下の図は「テスト・ピラミッド」と呼ばれる図で、プロジェクトの理想的なテスト構成を表しています。上に行けば行くほどユーザの視点に近くなります。下に行けば行くほど横の広がりが大きくなりますが、これはテストの数の多さを表しています。つまり、単体テスト＞統合テスト＞E2Eテストの順でテストの数が多くなるべきだ、ということを意味します。先程も述べたように、単体テストではドメインモデル・アルゴリズムに位置するコードをテスト対象とするため、ロジックは複雑ですが協力者オブジェクトの数は少ないです。一方統合テストやE2Eテストの場合、対象はコントローラに位置するコードとなるため、先ほどとは反対にロジックは単純で協力者オブジェクトの数は多いです。そのため、単体テストはケース数が多くなり、統合テストやE2Eテストはケース数が少なくなるべきです。ただし、ドメインのロジックがほとんどないようなアプリケーションの場合、単体テストとそれ以外のテストは数がほとんど同じになるか、場合によっては単体テストがないこともありえます。<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/1a91e4f2ff7a4d8d9d563a1b909740b5/unit_test.png" alt="">

テストピラミッド

どこまでをテストするのか

上記でも触れましたが、モックの使用についての指針は以下です。<ul><li>共有依存ではない依存はモックを使用しない</li><li>共有依存でも外部に直接公開されない依存（DBなど）はモックを使用しない</li></ul> モックを使用する場合でも、どのオブジェクトに対してモックするか、が問題になってくると思います。例えば、API呼び出しを行う場合、<ol><li>使用している言語のAPIライブラリ</li><li>APIライブラリをラップして対象アプリケーションに特化して使いやすくしたオブジェクト</li><li>2を更にラップして特定のリソースに特化して使いやすくしたオブジェクト(Repositoryのような使い方をする)</li></ol>というように複数のオブジェクトが関わっていた場合、どのオブジェクトをモック対象とすべきでしょうか？（以下の図は自分で描いたイメージ図です）<img src="https://images.microcms-assets.io/assets/b30d7661c2694503832399a83cea2137/4e44f0d080c447269a5b9c67230c6213/co-dependency.png" alt="">まず、3の場合、上記の中では最も不安定であり、リファクタによってテストが壊れやすいです。また経由するコード量も最も少ないため、退行からの保護も十分に得られません。そう考えると1が最も適切なように思えますが、本書では2が最適であると論じられています。ライブラリは対象アプリケーションだけでなくさまざまなアプリケーションで使われている汎用的なものです。一方で対象アプリケーションに特化したオブジェクトは当然対象アプリケーションのみで使用しており、プロジェクトメンバーのみで保守できるため成長をコントロールできます。ライブラリが変更された場合にも影響が2の層内で収まるようになるので(腐敗防止層)、この層のインターフェースは保護すべきです。そのため、2をモックの対象とすることで、3に比べてリファクタリング耐性も得られますし、インターフェースが変更されればテストが失敗するため、退行からの保護も得られるようになります。

共有依存との境界

何をモックにすべきか

細かいトピックですがテストコードあるあるだと思います。インプットからアウトプットを組み立てるロジックを書いていると実装をしているような気分になってきて、意味のあるテストになっているのか不安に思うことがあると思います。そもそもアウトプットをインプットから組み立てるときの心理としては、導出できるものは極力導出すべし、というエンジニア脳があると思います。この場合で言えばアウトプットはインプットから導出できます。実際、仮にアウトプットを直書きするとインプットを少し変更しただけでテストが壊れるようになってしまいまうため、エンジニアとしてはある意味正常な脳の働きだと思います。しかし本書ではむしろ直書きを推奨しています。インプットからアウトプットを導出するコードはどうしてもプロダクションコードに似てきてしまうためです。それでも本来であれば退行からの保護は得られるはずですが、単なるコピペのようなコードであった場合失敗に向き合うのではなくその場しのぎでテストコードを修正してしまう恐れがあるためとのことです。個人的には、全てのアウトプットを直書きにすべしとは思いません。場合によってはコード量が膨大になってしまい、それこそ保守がしづらいコードになってしまう場合があると思うためです。簡潔に書けるのであれば直書きすべきですし、そうでないならロジックで組み立てるのもありだと思います。ただその場合も、極力プロダクションコードには似ないようにしたほうがいいと思います。別解を探すような感覚で、ロジックを実装することになります。

アンチパターン

テストコードでロジックを書いてはいけないのか

今回は、テストコードについて掘り下げてみました。1つの記事にしたら書くことが沢山あってかなり時間がかかってしまいました。ただそれだけこの本の内容が濃かったということだと思います。今回具体的なコードを挟まなかったため抽象的な話になってしまいましたが、本書ではコードも交えながら説明しているためわかりやすいです。繰り返しになりますが、大変おすすめの本ですので興味を持った方はぜひ読んでいただければと思います。 今回得た知見を実践に活用し、そこで更に得られたフィードバックがあれば、また別の記事にしようと思います。 最後までご覧いただきありがとうございました。

<a href="https://www.amazon.co.jp/%E5%8D%98%E4%BD%93%E3%83%86%E3%82%B9%E3%83%88%E3%81%AE%E8%80%83%E3%81%88%E6%96%B9-%E4%BD%BF%E3%81%84%E6%96%B9-Vladimir-Khorikov/dp/4839981728" target="_blank" rel="noopener noreferrer">単体テストの考え方/使い方</a>

参考文献

さいごに

単体テストのベストプラクティス

コードレビューでは、まず最初にコードが要求を満たす動作をすることが重要視されます。その上で、外部サービスの特異な動作やセキュリティ機構の考慮、不具合発生時の検知可能性、将来的な修正の困難さ、パフォーマンス問題などについても指摘が行われます。 指摘を行う際には、以下のようなタグを用いてコメントをカテゴライズします。<ul><li>must: 修正が絶対に必要な場合</li><li>imo: 自身の意見や思考を伝える場合</li><li>nits: 細部の指摘や軽微な修正を提案する場合</li><li>q: 質問をする、または不明な点を問い合わせる場合</li></ul> これらのタグは、レビューのプロセスで「心理的安全性」を保証するために重要な役割を果たします。 心理的安全性とは、ハーバード大学のエイミー・エドモンソン氏が提唱した概念で、チームメンバーが自身のミスを認め、改善のために積極的に発言する環境を指します。 コメントタグは、心理的安全性を保証するための3つの要素、すなわち「発言できる環境を作る」「自分がミスをしている可能性を認める」「好奇心を持つ」に対して以下のように貢献します。<ul><li>発言できる環境を作る: コメントタグを使用することで、自分の意見や感情を明確に表現できます。これにより、意見交換のハードルが下がります。</li><li>自分がミスをしている可能性を認める: 強い意志を示すタグ（例えば「must」）を使用することで、自分の認識のズレに気づく機会を得ることができます。</li><li>好奇心を持つ: 「imo」や「q」のようなタグを使用することで、他人のコーディングスタイルやコードの背景について理解を深めることができます。これは新たな視点を提供し、自身のスキルや知識を拡張する機会を提供します。</li></ul>

コードレビューにおけるコメントタグの使用は、チーム内の心理的安全性を強化する重要な手段です。これらのタグは、レビュアーが自分の意見を明確に表現し、レビュイーがフィードバックを適切に理解しやすくする役割を果たします。 また、タグの使用は、チームメンバーが自分のミスを認め、新たな視点を探求する環境を作り出します。これらの要素はすべて、心理的安全性の確保とチームの健全性に寄与します。

コメントタグの活用による効果的なコミュニケーションとチームの健全性

コードレビューにおけるフィードバックの分類と心理的安全性の強化

<ol><li>URLにケバブケースを使う: URLは読みやすさとSEOの観点からケバブケース（例：my-example-url）を使用します。</li><li>パラメータにキャメルケースを使う: パラメータはJavaScriptとの親和性を保つためにキャメルケース（例：myExampleParameter）を使用します。</li><li>コレクションを指す名前は複数形にする: リソースの集合を表す名前は複数形にします（例：users、products）。</li><li>URLはコレクションで始まり、識別子で終わる: URLの構造は一貫性を保つために、コレクション名で始まり、特定のリソースを識別するIDで終わるようにします。</li><li>リソースURLに動詞を使わない: リソースのURLは名詞を使用し、HTTPメソッド（GET、POST、PUT、DELETE）で操作を表現します。</li><li>非リソースURLには動詞を使う: リソースではなく操作を表すエンドポイント（例：/resetPassword）では、動詞を使用します。</li><li>JSONのプロパティにキャメルケースを使う: JSONのプロパティ名はJavaScriptとの親和性を保つためにキャメルケースを使用します。</li><li>モニタリングのためのエンドポイントを実装する: サービスの健康状態を監視するために、/health、/metricsなどのエンドポイントを実装します。</li><li>リソース名にテーブル名を使わない: データベースのテーブル名をそのままリソース名にするのではなく、ビジネスロジックに基づいた名前を使用します。</li><li>API設計ツールを使う: API設計とドキュメンテーションを助けるツール（例：Swagger、Postman）を活用します。</li><li>バージョンに単純な序数を使う: APIのバージョン管理には単純な序数（v1、v2など）を使用します。</li><li>レスポンスにリソースの総数を含める: リスト形式のレスポンスには、リソースの総数を含めることで、ページネーションなどの処理を容易にします。</li><li>limitパラメータとoffsetパラメータを受け入れる: ページネーションを実装するために、リクエストで取得するリソースの数（limit）と開始位置（offset）を指定できるようにします。</li><li>fieldsクエリパラメータを使う: 必要なフィールドのみをレスポンスに含めることで、データの転送量を削減します。</li><li>URLに認証トークンを渡さない: セキュリティの観点から、認証トークンはヘッダーに含めるか、POSTリクエストのボディに含めます。</li><li>コンテンツタイプを有効にする: サーバーはリクエストのコンテンツタイプを憶測せず、明示的に指定します（例：application/json）。</li><li>CRUD機能にHTTPメソッドを使う: CRUD（Create、Read、Update、Delete）操作はそれぞれHTTPメソッド（POST、GET、PUT/PATCH、DELETE）に対応します。</li><li>ネストされたリソースURLにリレーションを使う: リソース間の関係を表すために、ネストされたURLを使用します（例：/shops/2/products）。</li><li>CORSをサポートする: クロスオリジンのリクエストを許可するために、CORS（Cross-Origin Resource Sharing）をサポートします。</li><li>セキュリティを強化する: すべてのエンドポイントにHTTPSを適用し、データの安全性を保証します。</li><li>エラーハンドリングを適切に行う: クライアントが無効または不正なリクエストを行った場合、適切なエラーメッセージとともに4xx HTTPエラーコードを返します。</li><li>ゴールデンルールを守る: フラットはネストより良い、単純は複雑より良い、文字列は数字より良い、一貫性はカスタマイズより良い、という原則を守ります。</li></ol>

これを読む前から意識していたこともあるかもしれませんが、再度これを読んで意識できると品質が上がること間違いなしです！ これらのベストプラクティスを実践することで、API設計スキルを向上させ、アプリケーションのパフォーマンスとユーザーエクスペリエンスを向上させることができます。 それでは、皆さんがこれらのベストプラクティスを活用して、素晴らしいAPIを設計することを願っています！

これ意識して！

API設計スキルをブラッシュアップするための22のベストプラクティスの記事を読んだのでご紹介

CSVのバリデーションというと、ファイル名検証、文字コード検証、ヘッダ検証、レコード単位のバリデーションなどがあると思います。今回その中でヘッダ検証に焦点を当てたのは、自分がざっと調べた感じ意外とGOを使ったCSVのヘッダ検証について紹介している記事がなさそうだったためです。まあ最悪ヘッダ検証はなくてもレコード単位のバリデーションで必須チェックがあれば弾かれるとは思うのですが、ファイル単位ではなくレコード単位でコミットする設計のため、レコード単位でエラーだった場合も後続が走り、結果的に全レコード分のエラーが出力されてしまうため、好ましくないです。そのため今回はヘッダ検証の実装を行いました。

ヘッダ検証の必要性

以下が自分の実装したヘッダ検証を行う関数です。引数としてCSVから読み込んだバイト列が渡され、検証の結果NGだった場合は<code>InvalidHeaderError</code>が返されます。<pre><code>type InvalidHeaderError struct {
 notExistHeaders []string
}

func (i *InvalidHeaderError) Error() string {
 return fmt.Sprintf("CSVファイルのヘッダが欠損しています: %s", strings.Join(i.notExistHeaders, ","))
}

func NewInvalidHeaderError(notExistHeaders []string) *InvalidHeaderError {
 return &amp;InvalidHeaderError{notExistHeaders: notExistHeaders}
}

func ValidateHeader[T any](csv []byte) error {
 scanner := bufio.NewScanner(bytes.NewBuffer(csv))
 for scanner.Scan() {
 unquoted := strings.ReplaceAll(scanner.Text(), "\"", "")
 headers := strings.Split(unquoted, ",")

 notExistHeaders := []string{}

 model := new(T)
 t := reflect.TypeOf(*model)
 L:
 for i := 0; i &lt; t.NumField(); i++ {
 csvTag := t.Field(i).Tag.Get("csv")
 for _, header := range headers {
 if header == csvTag {
 continue L
 }
 }
 notExistHeaders = append(notExistHeaders, csvTag)
 }
 if len(notExistHeaders) &gt; 0 {
 return NewInvalidHeaderError(notExistHeaders)
 }
 // ヘッダのみでいいので1行読み終わったら抜ける
 break
 }
 return nil
}</code></pre>

全体像

<code>T any</code>はCSVをマッピングするモデルクラスです。例として以下のような構造体を定義します。<pre><code>type User struct {
 ID int `csv:"id"`
 Name string `csv:"name"`
 Email string `csv:"email"`
}</code></pre>このように定義しておくと、<code>csvuti.Unmarshal()</code>を使ってcsvから一発で構造体にマッピングしてくれます。（csvのタグ名がCSVのヘッダ名に紐づきます。）CSVのヘッダ情報を別の変数などで管理すると、もしもヘッダ名が変更になった場合に複数箇所を修正しなくてはならないため、csvのタグ情報で一元管理するようにしています。 まずヘッダ検証なので最初の1行のみが欲しいのですが、scanner.Scan()で1行ずつ読み込んでくれるので、最初のループが回った時点でbreakします。<pre><code> // ヘッダのみでいいので1行読み終わったら抜ける
 break</code></pre>次にヘッダの文字列からカラムの配列を取り出しています。CSVのフォーマットはダブルクォートありの想定なのでダブルクォートを取り除いてから、カンマで区切って配列を取得しています。<pre><code> unquoted := strings.ReplaceAll(scanner.Text(), "\"", "")
 headers := strings.Split(unquoted, ",")</code></pre>そしてその後が重要なのですが、モデルのインスタンスを生成し、<code>reflect.TypeOf(*model)</code> でモデルの型情報を取得。<code>t.NumField()</code> でモデル構造体のカラム数が取得できるのでforループで回し、<code>t.Field(i).Tag.Get("csv")</code> でCSVのタグ情報を取得しています。あとは先程取得したCSV側のヘッダカラム配列を走査し、ヒットした時点で<code>continue L</code> によってモデル構造体のカラム毎のループから抜けます。そうするとCSVヘッダカラムのループが最後まで回り終わった時点で該当カラムが欠損していることがわかるので、<code>notExistHeaders</code>に該当カラムを追加します。<pre><code> L:
 for i := 0; i &lt; t.NumField(); i++ {
 csvTag := t.Field(i).Tag.Get("csv")
 for _, header := range headers {
 if header == csvTag {
 continue L
 }
 }
 notExistHeaders = append(notExistHeaders, csvTag)
 }</code></pre>最終的に<code>notExistHeaders</code>が存在していれば、カラムの欠損があったということでエラーを返しています。

解説

実装内容

今回はCSVのヘッダ検証の実装をご紹介しました。自分で解説していて、改善点として<ul><li>Tがanyなのであらゆる型が入れられてしまうのがあまり良くない<ul><li>できればTは構造体であるという制約をつけたい</li><li>csvのタグがないとおそらく落ちる</li></ul></li></ul>などがあるなと思いました。今後上記の課題が解決できたらまた記事にしようと思います。最後までご覧いただきありがとうございました。

最後に

GOでCSV import ~ ヘッダ検証編

こんにちは、Vercelのブログにて、Nuxt.jsを使用して静的サイトを構築し、Vercelでデプロイする方法が紹介されました。 <a href="https://vercel.com/blog/nuxt-on-vercel" target="_blank" rel="noopener noreferrer">この</a>記事では、Nuxt.jsの概要や、Nuxt.jsを使用して静的サイトを構築し、Vercelにデプロイする方法が解説されています。Nuxt.jsは、Vue.jsをベースに構築されたフレームワークであり、Vue.jsと同様にコンポーネントベースでの開発が可能です。 静的サイトの構築には、Nuxt.jsのgenerateコマンドを使用することで、事前にHTMLファイルを生成することができます。また、Vercelは静的サイトのホスティングに特化しており、高速かつシームレスなデプロイが可能です。 この記事では、Nuxt.jsとVercelを組み合わせることで、静的サイトを構築し、高速かつシームレスなデプロイを実現する方法が紹介されています。静的サイトの構築やVercelの利用に興味がある方は、ぜひ<a href="https://vercel.com/blog/nuxt-on-vercel" target="_blank" rel="noopener noreferrer">この</a>記事を参考にしてください。 以上、Nuxt.jsで静的サイトを構築し、Vercelでデプロイする方法についてご紹介しました。

Nuxt.jsで静的サイトを構築してVercelでデプロイ！

Vercel Ship Day5 #2 〜Nuxt.jsで静的サイトを構築して Vercelでデプロイ〜

こんにちは、Vercel Ship Day4にて、フロントエンドアプリケーションに認証機能を簡単に実装する方法が紹介されました。 <a href="https://vercel.com/blog/authentication-for-the-frontend-cloud" target="_blank" rel="noopener noreferrer">この</a>記事では、Vercelが提供するAuth0という認証プラットフォームを使用し、フロントエンドアプリケーションに認証機能を簡単に実装する方法が解説されています。Auth0は、多様な認証方法をサポートしており、簡単に実装することができます。 認証機能を実装することで、ユーザーのプライバシーやセキュリティを保護し、信頼性の高いウェブアプリケーションを作ることができます。また、Auth0を使用することで、ユーザー認証に関する複雑な機能やセキュリティについての懸念を払拭することができます。 この記事では、VercelとAuth0を組み合わせることで、フロントエンドアプリケーションに簡単かつ高度な認証機能を実装する方法が紹介されています。認証機能を実装したい方は、ぜひ<a href="https://vercel.com/blog/authentication-for-the-frontend-cloud" target="_blank" rel="noopener noreferrer">この</a>記事を参考にしてください。 以上、VercelとAuth0を組み合わせた、フロントエンドアプリケーションに認証機能を簡単に実装する方法についてご紹介しました。

【Vercel】フロントエンドアプリケーションに認証機能を簡単に実装できるように！

Vercel Ship Day5 #1 〜【Vercel】Frontend App に認証機能を簡単に実装！〜

こんにちは、Next.jsの新しいバージョン「Next.js 13.4」がリリースされました。今回のアップデートでは、Incremental Static Regeneration（ISR）という新機能が追加されました。 ISRは、静的生成されたウェブページを、動的に再生成する機能です。これにより、ユーザーがウェブサイトにアクセスした際に、古い情報が表示されることを防ぎ、常に最新の情報を提供することができます。 また、ISRは、ウェブサイトのパフォーマンスを向上させることができます。通常の静的生成では、全てのページを一度に生成する必要がありますが、ISRを使うことで、必要なページだけを再生成することができます。これにより、ウェブサイトのロード速度を改善し、ユーザー体験を向上させることができます。 Next.js 13.4では、ISRを簡単に実装するためのAPIが提供されています。また、ISRを活用することで、動的なコンテンツを持つウェブサイトでも、静的なウェブサイトと同じように高速でスムーズな動作を実現することができます。 以上、Next.jsの新機能「Incremental Static Regeneration」についてご紹介しました。Next.jsを利用している方は、ぜひこの新しい機能を活用して、ウェブサイトのパフォーマンスを改善してください。

【Next.js 13.4】新機能のIncremental Static Regenerationでウェブサイトのパフォーマンスを改善！？

Vercel Ship Day4 〜【Next.js 13.4】新機能のISRでウェブサイトのパフォーマンスを改善！〜

こんにちは、Vercel Ship Day3について書きます！今回は、Vercelの新機能「Visual Editing」についてご紹介します。 「Visual Editing」は、Vercelが提供する新しいウェブサイトエディターです。このエディターを使えば、HTMLやCSSの知識がなくても、直感的にウェブサイトを作成することができます。 具体的には、ドラッグアンドドロップでコンポーネントを配置し、テキストや画像を編集することができます。また、複数のデバイスに対応したレスポンシブなデザインを簡単に作成することができます。 さらに、Visual Editingは、リアルタイムのプレビュー機能を備えています。これにより、作成中のウェブサイトの外観や動作をすぐに確認することができます。 VercelのVisual Editingは、ウェブサイト制作において初心者から上級者まで、幅広いユーザーに利用されることが期待されます。ぜひ、この新しいエディターを使って、自分だけのオリジナルなウェブサイトを作ってみてください。 以上、Vercelの新機能「Visual Editing」についてご紹介しました。Vercelを利用している方は、ぜひこの新しいエディターを使って、より簡単にウェブサイトを作成してください。

Vercelの新機能「Visual Editing」で簡単にWebサイトを作ろう！

Vercel Ship Day3 〜Visual Editingで簡単にWebサイト作成〜

こんにちは、先日行われたVercel Ship Day3について書きます！今回は、Vercel Spacesを使ってチームで開発を効率化する方法についてご紹介します。 Vercel Spacesは、Vercel上で作成した複数のプロジェクトをグループ化し、関連するプロジェクトを一つの場所にまとめることができる機能です。そして、このVercel Spacesを使えば、プロジェクトごとに異なるチームメンバーを招待することができます。 具体的には、プロジェクトごとに異なるチームメンバーを招待して、そのチームメンバーだけがアクセスできる環境を作ることができます。これにより、プロジェクトの開発状況やタスクの進捗状況を共有し、よりスムーズな開発作業が可能になります。 さらに、Vercel Spacesでは、プロジェクトごとに異なる環境変数やシークレットを設定することができます。これにより、チームメンバーごとに異なる権限を与えることができ、セキュリティ面でも安心して開発作業を進めることができます。 Vercel Spacesは、開発者がチームで開発作業を行う上で非常に役立つ機能です。設定も簡単で、Vercelの全てのプランで利用可能です。ぜひ、Vercel Spacesを使ってチームでの開発を効率化してみてください。 以上、Vercel Spacesを使ってチームで開発を効率化する方法についてご紹介しました。Vercelを利用している方は、ぜひVercel Spacesを活用して、よりスムーズな開発作業を行ってください。

Vercel Spacesを使ってチームで開発を効率化しよう！

Vercel Ship Day3 〜Vercel Spacesを使ってチームで開発を効率化〜

こんにちは、Day2ではセキュリティに関するアップデートを発表しました。 まずはじめに、Vercelはユーザーが自分たちのカスタムドメインを使用する際に、DNSサーバーをより強力に監視し、DNSハイジャック攻撃に対する防御を強化しました。 次に、Dockerfileを使ってアプリケーションをデプロイする際に、より厳格なイメージ検証を実施することで、セキュリティの向上に取り組んでいます。また、依存関係の脆弱性を検出するための自動化されたセキュリティスキャンを改善し、ユーザーに通知するスピードを向上させました。 最後に、自社のセキュリティに関するドキュメントをより詳細に整理し、ユーザーに提供することで、セキュリティに関するトピックについてより分かりやすく説明しています。 以上が、VercelのShip Day 2で発表されたセキュリティアップデートの概要です。これらの改善により、Vercelはより安全で信頼性の高いWebアプリケーションのデプロイとホスティングを提供することができます！ Vercelはどんどん進化していくのでDay3からも楽しみです。 詳細は以下のリンクよりご確認ください。<a href="https://vercel.com/blog/vercel-security" target="_blank" rel="noopener noreferrer">https://vercel.com/blog/vercel-security</a>

BuildersIO produced by YOKU

【Go言語】go mod tidy, go generateでエラーが発生した時の対処法

Docker入門：超初心者向けガイド

単体テストのベストプラクティス

コードレビューにおけるフィードバックの分類と心理的安全性の強化

API設計スキルをブラッシュアップするための22のベストプラクティスの記事を読んだのでご紹介

GOでCSV import ~ ヘッダ検証編

Vercel Ship Day5 #2 〜Nuxt.jsで静的サイトを構築して Vercelでデプロイ〜

Vercel Ship Day5 #1 〜【Vercel】Frontend App に認証機能を簡単に実装！〜

Vercel Ship Day4 〜【Next.js 13.4】新機能のISRでウェブサイトのパフォーマンスを改善！〜

Vercel Ship Day3 〜Visual Editingで簡単にWebサイト作成〜

Vercel Ship Day3 〜Vercel Spacesを使ってチームで開発を効率化〜

Vercel Ship Day2 〜セキュリティのアップデート〜

機密情報の漏洩を防ごう！～gitleaksの運用方法～

【AWS】boto3でDynamoDBを操作するときによく使うメソッド

単体テストのベストプラクティス

【Go言語】go mod tidy, go generateで エラーが発生した時の対処法

Docker入門：超初心者向けガイド

単体テストのベストプラクティス

コードレビューにおけるフィードバックの分類と心理的安全性の強化

API設計スキルをブラッシュアップするための22のベストプラクティスの記事を読んだのでご紹介

GOでCSV import ~ ヘッダ検証編

Vercel Ship Day5 #2 〜Nuxt.jsで静的サイトを構築して Vercelでデプロイ〜

Vercel Ship Day5 #1 〜【Vercel】Frontend App に認証機能を簡単に実装！〜

Vercel Ship Day4 〜【Next.js 13.4】新機能のISRでウェブサイトのパフォーマンスを改善！〜

Vercel Ship Day3 〜Visual Editingで簡単にWebサイト作成〜

Vercel Ship Day3 〜Vercel Spacesを使ってチームで開発を効率化〜

Vercel Ship Day2 〜セキュリティのアップデート〜

【Go言語】go mod tidy, go generateでエラーが発生した時の対処法