おはようございます、みなさん！「zenncast」のマイクです！今日は2024年6月4日、火曜日です。今日もZennからトレンドの記事を紹介していきますよ！
さて、まずは前回紹介した記事を軽く振り返ってみましょう。「PayPay Api使って爆速で支払いシステム作ってみた」、「enableForestを使うことでReact Compilerでメモ化のレベルを変更できる」、そして「AWSでB/GデプロイやCanaryデプロイができそうな機能をまとめて比較してみた」でしたね。どれも興味深い内容でした。
さて、今日は5つの記事を紹介しますので、どうぞお楽しみに！
まず1つ目の記事は「PPR - pre-rendering新時代の到来とSSR/SSG論争の終焉」です。
Partial Pre-Rendering、略してPPRは、Next.js v14.0で導入された新しいレンダリングモデルです。SSR（Server-Side Rendering）やSSG（Static-Site Generation）に続く、革新的な技術として注目されています。Next.jsは2016年にSSRをサポートするReactフレームワークとして登場し、2019年にはSSGやISR（Incremental Static Regeneration）もサポートするようになりました。その後、App Routerの登場で、Next.jsはstatic renderingとdynamic renderingという新しい概念を導入しました。
PPRは、Streaming SSRをさらに進化させた技術で、ページ全体をstatic renderingとしつつ、部分的にdynamic renderingにすることが可能です。これにより、TTFB（Time to First Byte）の速度を維持しつつ、動的要素の表示も可能になります。PPRを利用することで、ページの一部を静的化し、他の部分を動的にレンダリングすることができるため、パフォーマンスと実装のシンプルさを両立できるのです。
PPRの導入により、SSR/SSG論争は過去のものとなり、「どこまでをstaticに、どこからをdynamicにするか」という細粒度な議論にシフトします。しかし、PPRは銀の弾丸ではなく、dynamic renderingを必要とするケースにおける最適化であるため、パフォーマンス指標に応じた適切な選択が重要です。PPRはNext.jsユーザーにとって非常に理想的なレンダリングモデルであり、今後の進化が非常に期待されます。
....
次に2つ目の記事は「SQLクエリに対するスナップショットテストの実践例」です。
この記事では、ORMを使用したSQLクエリに対するスナップショットテストの実践例を紹介しています。この記事で取り上げられているクラス`UserRepository`の`find()`メソッドを例に、SQLクエリの組み立て部分とデータ取得部分を分けて、`buildFindQuery()`メソッドをテストすることで、生成されるSQLクエリのスナップショットを取得します。テストには`java-snapshot-testing`ライブラリを使用します。
スナップショットテストのメリットとして、実行が高速であるため、特にDB接続を伴うテストの実行時間を短縮できる点が挙げられます。実際の開発現場では、約60パターンのSQLクエリの結果をスナップショットテストで検証し、実行時間を2.4倍短縮する効果がありました。複雑な条件分岐を含むクエリの場合、スナップショットテストを用いることで実際に実行されるSQLクエリを確認しやすくなるのです。
ただし、スナップショットテストを乱用すると、新規実装や改修のコストが増加する可能性があるため、適切な範囲での利用が重要です。この記事を通じて、SQLクエリに対するスナップショットテストの実践方法とそのメリットを理解し、プロダクトの品質向上に役立ててください。
....
そして3つ目の記事です。「Cloudflare Pages + D1 + Honoでプロフィールサイトを作ってみた」というタイトルです。
この記事では、Cloudflare Pages、D1、およびHonoを用いてプロフィールサイトとブログページを作成する方法を紹介しています。エンジニアリングの背景にはGo、React、Google Cloudの使用経験があり、最近はCloudflareを楽しんでいるそうです。
技術スタックとしては、Cloudflare Pages、D1（データベースソリューション）、Hono（ウェブフレームワーク）を使用しています。Honoのスターターを使用し、簡単にプロジェクトを開始。Cloudflare PagesとHonoの組み合わせで、アイコンなどのアセット配信も容易に行える点が魅力です。
ディレクトリはAPI、コンポーネント、設定ファイルなどに分割し、管理のしやすさを追求しました。ブログデータを管理するためにD1を使用し、セットアップは簡単で、必要な情報を`wrangler.toml`に記載するだけ。セキュリティ面でもシークレット情報を`.gitignore`に追加して保護しています。
Honoのヘルパーを用いてCSSの管理も行い、基本レイアウトを`renderer.tsx`に記載しました。ブログページのAPIを作成し、D1を利用したデータ取得やバリデーションを実装。Honoのミドルウェアを活用してCSRFプロテクションやバリデーションも導入しています。
Cloudflare PagesにGitHubレポジトリを連携し、Push操作で自動デプロイが可能。環境変数やD1の設定もCloudflare Pagesの管理画面から簡単に行えます。今後も改善を続ける予定で、CloudflareとHonoの組み合わせが非常に便利であると感じています。
....
続いて4つ目の記事は、「とあるQAエンジニアによる日本語へのこだわりのススメ」です。
株式会社ナレッジワークのQAエンジニアであるiinoさんが、社内のLT大会で発表した内容をもとに、日本語の使い方にこだわる重要性について述べています。特に、ソフトウェア開発において誤解や勘違いがバグの原因となるため、設計ドキュメントやテスト設計ドキュメントにおいて明確で一貫性のある表現が求められるとしています。
iinoさんが提案する日本語へのこだわりは以下の通りです：
1. 主体、対象・データ、機能の表現にこだわる
2. 対象やデータを名詞で、機能を動詞で記述する
3. データの出所や目的地を明確に記述する
4. 条件を複数指定する際に同じ表現を繰り返さない
5. 曖昧な表現を避け、具体的かつ明確に記述する
iinoさんは、これらのこだわりを持つことでバグの種を摘み取り、誤解や勘違いを防ぐことを目指しています。また、社内LT大会での発表が好評だったことを受け、この記事を書いたと述べています。ナレッジワークではエンジニアを積極採用中で、興味のある方はカジュアル面談に参加することを勧めています。
....
最後に5つ目の記事です。「Glue データカタログのクロスアカウント共有 [RAM, Lake Formation]」です。
この記事では、AWS環境において、あるアカウントに存在するGlueテーブルを別のアカウントから参照する方法について解説しています。具体的には、Lake Formationを使用し、Resource Access Manager (RAM) を通じてクロスアカウント共有を行う手順を紹介しています。
手順は以下の通りです：
1. Glueテーブルの作成
2. RAMリソース共有の作成
3. 組織内からのGlueテーブル参照許可
4. リソースリンクの作成
5. GlueジョブロールにLake Formation権限を付与
6. S3バケットポリシーの更新
7. Glueジョブロールに必要なIAM権限を付与
8. 動作確認
記事の最後には、Lake Formationの権限設定に関するトラブルシューティングが役立つ情報として紹介されています。クロスアカウントでのGlueテーブル共有は手順が多いため、この記事がエンジニアの助けになることを期待しています。
....
さて、今日は「PPR - pre-rendering新時代の到来とSSR/SSG論争の終焉」、「SQLクエリに対するスナップショットテストの実践例」、「Cloudflare Pages + D1 + Honoでプロフィールサイトを作ってみた」、「とあるQAエンジニアによる日本語へのこだわりのススメ」、そして「Glue データカタログのクロスアカウント共有 [RAM, Lake Formation]」の5つの記事を紹介しました。
次回もどうぞお楽しみに！詳しい内容はショーノートに書いてありますので、ぜひチェックしてください。そして、番組の感想もお待ちしています。それでは、またお会いしましょう！