こんにちは、マイクです！今日は2024年8月6日、火曜日です。さて、今日はZennでトレンドになっている記事をいくつかご紹介したいと思います。
まずは、今日ご紹介する内容についてお知らせしますね。今日は全部で5つの記事をご紹介しますので、お楽しみに！
それでは、最初の記事に行きましょう！まずは「App Router で1年間開発した知見と後悔」という記事です。
この記事では、著者がNext.jsのApp Routerを使って1年間の開発で得た知見や後悔をシェアしています。特に、データフェッチング戦略が重要なポイントとして挙げられています。App Routerでは、RSC内でのフェッチが分離しにくく、コードが肥大化しやすいことが指摘されています。そのため、データフェッチのロジックを自分自身で抽象化する必要があるということです。
また、バックエンドのベストプラクティスとして、入力バリデーションや認証・認可の重要性が強調されています。さらに、コロケーションの導入については、コードベースが整理されている場合にURL変更時に多くのファイルに影響が出るため、後悔しているとも記されています。一方で、Intercepting Routesの使用については、未解決のバグが多く、使用を控えるべきとの警告もあります。
GraphQLクライアントに関しては、Apollo Clientから軽量なurqlへの移行を考えているようです。国際化に関しては、初期にサブパスを用いた実装に問題があり、Cookieベースに移行したことでシンプルなURL構造を実現したとのこと。
スタイリングはMantineとTailwindCSSを併用していて、特に問題はないと述べています。最後に、Next.jsのApp Routerは非常に強力ですが、開発者の力量が試されるフレームワークでもあるとまとめられています。この知見の共有がエンジニアの成長に寄与することを期待しているそうです。
。...。...。...。
続いて2つ目の記事、「Cloudflare D1 を使った日本語の全文検索を実装する」です。
本記事では、Cloudflare D1を利用して日本語の全文検索APIを実装する方法が解説されています。Cloudflare D1はSQLiteを基にしていて、特に日本語に対応した検索機能の実装に関する工夫が紹介されています。
記事では、データ登録用エンドポイントと検索用エンドポイントを設定し、データ登録時には受け取った情報をcontentsテーブルに追加しています。Intl.Segmenterを使用して文書をトークン化し、そのトークンをftsテーブルに格納しています。検索時には、渡されたクエリに基づいてこれらのテーブルを結合し、マッチした文書を取得する仕組みです。
D1におけるテーブル定義では、fts5を用いた仮想テーブルを作成し、tokenizerオプションを指定しますが、提供されるtokenizerは日本語に最適化されていないため、外部ツールを使用してトークン化しています。具体的には、分かち書きに対応したツールを使ってトークンをスペース区切りで格納する方法が採用されています。
最終的に、Cloudflare Workersを利用してAPIサーバーを立ち上げ、ローカルでの動作確認も行ったとのこと。また、Cloudflareが提供するベクトルデータベースや他の検索ライブラリについても触れています。今後の発展を期待しつつ、D1の利点を活かした全文検索機能の実装に成功した点が強調されています。
。...。...。...。
次は3つ目の記事、「事例別！Strict Concurrency対応方法」です。
Swift 6への移行にあたって、Strict Concurrencyの対応が非常に重要です。この記事では、一般的な問題に対するエラーベースややりたいことベースの解決策が提示されています。全ての例は、Swift 5モードとStrict Concurrencyでビルドされた結果が基になっています。Swift 6では、これらの警告がコンパイルエラーに変わるため、すべて対処が必要です。
SwiftのUI関連は`MainActor`に隔離され、UI操作を行う関数も`MainActor`に隔離する必要があります。影響範囲が広い場合は`@preconcurrency`を使うことで、一時的に警告を抑制できます。UIのdelegate関連では、外部ライブラリの非対応も考慮し、`@preconcurrency`や`nonisolated`の使用が推奨されています。
また、`Sendable`に関する問題も取り上げられ、`Sendable`でない型を`actor`に渡す際には、`sending`キーワードを使う方法や型を`Sendable`にすることで解決できます。グローバル変数の管理に関しても、`Sendable`なインスタンスをグローバル変数に持つことはデータ競合のリスクがあるため、隔離する方法が推奨されています。
最後には`deinit`が`actor`に隔離されない問題もあり、`nonisolated(unsafe)`を用いるか、`MainActor`に隔離された型でラップする方法が考えられています。全体として、Strict Concurrency対応は多岐にわたる問題解決が求められ、注意深い実装が必要であることが強調されています。
。...。...。...。
続いて4つ目の記事、「SRE NEXT 2024@Abema Tower 登壇資料まとめ」です。
このイベントは2024年8月4日に開催され、さまざまなSREに関するテーマが取り上げられました。Day1では「工学としてのSRE再訪」や「DevSecOpsの持続可能なセキュリティ対策」が発表され、特に「組織的なインシデント対応」や「巨大インフラ産業でのSRE」といったテーマが注目されました。
Day2では、オブザーバビリティの重要性や大規模組織におけるSLOの導入の難しさについての講演が行われました。また、プロダクト全体でのSREの取り組みや、事業フェーズの変化に適応するためのEnabling SREへの転換についても言及されています。
各発表者は自身の経験や知見をもとに、SREの実践における課題や解決策を共有し、有意義な情報交換が行われました。興味のある方は、発表資料のリンクを通じて詳しい内容を確認できます。
。...。...。...。
最後に5つ目の記事、「あなたはトレカのカード枚数を数えたことがあるか - カード自動認識スキャナーを作った話」です。
トラストハブAIチームの佐藤秋彦さんが、カードゲームのカードを自動で分類するスキャナーの開発について紹介しています。トレーディングカードゲームでは数千種類のカードが存在し、手作業での在庫登録は非常に時間がかかります。著者はカードを愛する一方で、在庫登録作業に苦労していたため、この問題を解決するためにスキャナーを使用したシステムを構築しました。
システムはカード画像を基に識別するアプローチを採用し、CNNを用いて特徴量を抽出します。オートエンコーダを利用してカード画像を500次元にエンコードし、FAISSを使ってベクトル間の距離を計算することで、スキャンしたカードを特定するのです。このシステムでは、30,000種類以上のカードを迅速に識別可能です。
システムの性能比較では、手動入力とスキャナーによる登録時間を比較し、スキャナーは100枚のカードを180秒で登録できるのに対し、手動では1500秒以上かかりました。著者は、カードショップの仕事がなくなることを危惧するのではなく、労力をコミュニティ作りに振り向けることでカードゲーム文化が豊かになることを期待しています。このシステムの導入により、カードショップの業務が効率化され、さらなる発展を遂げることが期待されています。
さて、今日は5つの記事をご紹介しました！それでは、今日の内容を駆け足でおさらいしますね。
1つ目はNext.jsのApp Routerに関する知見と後悔、2つ目はCloudflare D1を使った日本語の全文検索の実装、3つ目はSwift 6へのStrict Concurrency対応の方法、4つ目はSRE NEXT 2024の登壇資料まとめ、そして最後はカード自動認識スキャナーの開発についてでした。
次回もお楽しみに！詳しい内容はショーノートに書いてありますので、ぜひチェックしてみてください。また、番組の感想もお待ちしております！それでは、次回お会いしましょう！