こんにちは、マイクです！今日は2024年9月2日、月曜日ですね。今日も「zenncast」にお越しいただきありがとうございます。今日はZennでトレンドの記事をいくつか紹介していきますので、お楽しみに！
さて、前回紹介した記事では「技術選定の成功」や「SQLに対するバックエンドのアプローチ比較」など、いろいろな技術についてお話ししましたね。具体的には、TypeScriptやReact、Next.jsなどのキーワードが印象に残っています。
おたよりはいただいておりませんので、早速今日の内容紹介に移りたいと思います。
今日は全部で5本の記事を紹介します。
まず1つ目の記事は「Web 標準と、その限界」についてです。
Web標準は、私たちが普段使っているHTML、CSS、JavaScriptを基盤として、異なるブラウザ間で一貫した動作を実現するための仕様です。HTMLはWHATWGが、JavaScriptはECMAが規定しています。これらがWeb標準の中核をなしているんですね。さらに、Node.jsというサーバーサイドJavaScriptの環境が登場し、独自のAPIを持つことでWeb標準の限界を補っています。
最近では、Node.js以外にもDenoやBun、Cloudflare WorkersといったJavaScriptランタイムが増えてきました。これらのランタイムはWeb標準を基にした基本的なコードは共通して動作しますが、サーバー起動の方法はそれぞれ異なります。特に、サーバーリクエストを処理する際にはWeb標準のRequestとResponseを利用していますが、クライアントのIPアドレスを取得する際には独自の方法が必要になります。
このように、Web標準にはサーバーサイドに必要な機能が不足しているため、各ランタイムが独自の拡張を行っています。そのため、ランタイム間でAPIが異なることがデメリットとなり、異なるランタイムへの移行時にコードの変更が必要になることもあります。解決策としては、Node.jsとの互換性を持つAPIを使用することが提案されています。
Web標準は魅力的ですが、完全ではないため、エンジニアはその限界を理解し、適切な選択を行うことが求められます。
。...。...。...。
続いて2つ目の記事は「OpenAIの最新AIモデルStrawberryとOrion（GPT-5）とは？」です。
OpenAIが新たに発表した生成AI技術「Strawberry」と、その次期モデル「Orion（GPT-5）」についてのお話です。Strawberryは、既存のChatGPTでは解決できないタスクに対応することを目指して開発され、特にその高い推論能力や自己学習機能が注目されています。スタンフォード大学の「STaR（Self-Taught Reasoner）」技術が活用されており、回答生成時に解説文を作成することでモデルを改善していきます。
Strawberryは、長期的なタスクへの対応も得意としており、特に数理問題においては90%の精度を記録しています。さらに、高品質な合成データの生成も可能であり、データプライバシーの観点からの利用が期待されています。
一方で、Strawberryの自己学習が進むことでAGI（人工一般知能）としてのリスクも懸念されています。特にAI安全保障に関わる人材の流出が問題視されており、これによりAIの安全性が脅かされる恐れがあります。
将来的には、Strawberryは「Orion」や「CUA（Computer-Using Agent）」という形で展開されると考えられています。Orionは2024年秋にリリースされる見込みで、AIの進化が楽しみですね。
。...。...。...。
次は3つ目の記事、「Remixは404ページで最大3つもログを出す」についてです。
Remixプロジェクトにおいて、開発環境で404エラーが発生すると、最大3つの異なるログが出力されることが確認されています。最初のログは、サーバーがリクエストに対するルートを見つけられなかった場合に表示されるエラーメッセージです。このとき、`entry.server.tsx`内で`handleError`関数を定義することで、404エラーやリクエスト中止時のログを抑制できます。
次に、`No routes matched location "/foo"`というログは、React Routerが一致しないルートに対して出力されるもので、開発環境でのみ表示されるため本番環境では影響しません。特別な設定は不要です。
最後の`ErrorResponseImpl`ログは、RemixがReactエラーに対してErrorBoundaryを表示する時に出力されます。このログを抑えるには、ルートファイルから`ErrorBoundary`コンポーネントをエクスポートすることでデフォルトの動作を上書きできます。
まとめとして、404エラーログを抑えるためには、`entry.server.tsx`に`handleError`を実装し、`root.tsx`に`ErrorBoundary`を作成することが推奨されます。これにより、本番環境での不必要なログ出力を防ぐことができます。
。...。...。...。
続いて4つ目の記事は「TypeScriptの型を使って設計をコードで表現する、宣言的バックエンド実装具体例」です。
この話では、株式会社CHILLNNのCTOである永田氏が、TypeScriptを用いたバックエンド開発における「宣言的プログラミング」と「関数型ドメインモデリング」の具体例を紹介しています。機能追加によるコードの複雑化や法律改正に伴う修正の必要性が導入の理由です。
宣言的プログラミングは、ビジネスロジックをコンパイラで解釈可能な形で表現することで、ユニットテストに依存せずに考慮漏れを減少させることができます。関数型ドメインモデリングでは、処理をアトミックに分割し、メソッドチェーンで処理概要を把握しやすくなります。
具体的には、型でドメインの状態をモデリングし、その後状態遷移を関数として実装する流れです。例えば、ECサイトでのクレジットカード決済処理のモデリングを行うことができます。永田氏は、設計をコード化する目的は達成できていると感じており、エンジニアの採用も行っているそうです。
。...。...。...。
最後に5つ目の記事、「node:test で jsdoc `@example` に記述したコードを使ってテストする」についてお話しします。
この記事では、Node.jsのテストフレームワーク`node:test`を使用して、JSDocの`@example`タグに記述したコードをテストする方法が解説されています。著者は主にVitestを使用し、そのIn-Source Testing機能の利点を認識していますが、ロジックライブラリのテストには`node:test`が適している場合もあると述べています。
テストコードは、JSDocの`@example`セクションに記述され、`node:assert`を用いてアサーションが行われます。具体的には、関数`add`を定義し、そのテストコードを`@example`に記述します。テストを実行する際には、`--test`オプションを使用して特定のファイルを指定します。
モジュールの変換はそれほど複雑ではなく、特定のライブラリを使用すれば効率的に実現できると結論づけています。テスト対象のファイルを適切に指定し、必要に応じて変換を行うことで、重複したテストを避けることができるんですね。
今日は以上の5本の記事を紹介しました。振り返ると、Web標準の限界からAIの進化、404エラーのログ処理まで、盛りだくさんでしたね。次回はどんな新しい情報が待っているのか、楽しみにしています！詳しい内容はショーノートにも書いてありますので、ぜひチェックしてください。
それでは、今日もお付き合いいただきありがとうございました。「zenncast」の感想もお待ちしています！次回お会いできるのを楽しみにしています。