#
258
2025/1/24
今日のトレンド

RiverpodとISUCON14最適化 など

皆さん、こんにちは!マイクです!今日は2025年1月25日、金曜日ですね。今日も「zenncast」をお届けしますよ。今日はZennでトレンドの記事をいくつか紹介したいと思いますので、ぜひお楽しみに!

それでは、さっそく今日の内容に入る前に、前回紹介した記事をちょっと振り返ってみましょう。前回は「Liam ERDで綺麗でインタラクティブなER図を自動生成する」、「Swiftのstructのイミュータビリティ」、「Gemini 2.0 Flash API の使用方法を、実装しながら解説」という記事を紹介しました。これらの技術的なポイント、皆さん興味深く聞いていただけたでしょうか?

さて、今日はおたよりもいただいていないようですので、さっそく今日紹介する記事に移りたいと思います。今日は全部で5本の記事をお届けしますよ!

まず1つ目の記事は、「Riverpod の難しさを受け止めてみる」についてです。

この記事では、Riverpodの難しさについての考察がされています。特に、Providerとの比較を通じて、Riverpodの利点が強調されています。Riverpodは状態管理において「参照カウント方式」を採用し、Widgetへの依存を排除し、メモリ管理を効率化しています。状態が参照されると生成され、参照がなくなると破棄される仕組みが特徴です。

状態変化の連鎖についても興味深い点があり、Providerでは購読が異なる実装が必要で、Streamを使わなければならないことが多いですが、Riverpodでは購読が簡素化され、学習コストが軽減されています。

続いて、スコープの設計においてもRiverpodは柔軟な設計が可能で、複数の画面間での状態共有が容易です。さらに、状態管理の粒度については、Providerでの細かい管理がWidgetツリーを肥大化させる問題を解消し、静的解析の恩恵も受けやすくなっています。

全体を通じて、Riverpodは難しい技術である一方で、特定の要件においてはProviderよりも優れた選択肢であることが示されています。環境要因に応じて技術選定を行うべきとの意見も参考になりますね。

。...。...。...。...

さて、次にご紹介するのは「ISUCON14 をベンチマーカーの限界を超えて最適化した話」です。

こちらの記事では、2024年12月8日に開催されたISUCON14に参加したチーム最上川の話が紹介されています。初参加で834チーム中8位という成績を収めるも、データ保持違反で失格となってしまいましたが、その後の感想戦で850,573点を記録し、全体2位、学生1位を達成したというエピソードが語られています。

最適化の方針は、DB操作を削減し、全データを起動時に読み込むことでキャッシュを利用することに集中しています。初期コードのリファクタリング、DBの剥がしを行い、特に書き込み処理を遅延させ、一度にまとめて行うことでDBの負荷を軽減しています。

また、マッチングアルゴリズムの改善や、nginxの設定最適化、非同期処理の見直しなど全体的なパフォーマンス向上の努力があったようです。独自のHTTPフレームワークや、String InterningによるHashMapの最適化も行われ、最終的に400万点以上を達成しました。

このような技術的挑戦は、エンジニアリングの楽しさを再確認する良い機会になったのではないでしょうか。

。...。...。...。...

次は、「Google DriveとLLMで議事録を自動生成する仕組みを作る」についてお話しします。

この記事では、株式会社エスマットのSREであるbiosugar0氏が構築した、Google Driveを利用した議事録自動生成システムが紹介されています。このシステムはPythonで開発され、Google Cloud RunやGoogle Workflow、Whisper、gpt-4oが活用されています。

会議やインタビューの音声・動画ファイルを特定のフォルダにアップロードすることで、自動的に文字起こしと議事録生成が行われる仕組みです。変更を検知するCloud Run Jobや、議事録生成ジョブを開始するGoogle Workflowの流れが特に効率的ですね。

Whisperによる書き起こしはSRT形式で管理され、タイムスタンプを利用して動画の特定地点にリンクする仕組みも革新的です。GoogleカレンダーAPIを利用して会議情報を議事録に追加することで、より正確なドキュメント作成が行えるのもポイントです。

このシステムはGoogle Workspaceを利用する企業にとってとても便利ですね。

。...。...。...。...

次にご紹介するのは「pnpm workspace を利用したモノレポで『この PR の影響を受けるパッケージ』をフィルタする」です。

LayerXのバクラク事業部では、複数のNext.jsアプリケーションをモノレポ化しているそうです。この構成では、CIでのテスト実行が課題となっており、全てのテストを実行すると無駄な時間がかかってしまうそうです。

そこでpnpmの`--filter`オプションを利用して、変更内容に基づいて影響を受けるパッケージを絞り込み、効率的なテスト実行が行えるようになったとのこと。特定のパッケージに対してのみテストを実施できるのが魅力的ですね。

さらに、GitHub ActionsでPRの影響を受けるパッケージのみをテストする設定も可能で、これにより時間やリソースの無駄を削減できるそうです。

この方法によりモノレポの管理がシンプルかつ効果的に行えることが期待されています。CI/CDプロセスの効率化、素晴らしいですね!

。...。...。...。...

最後にご紹介するのは「Rust/Tauriに入門したので画像変換デスクトップアプリを開発してみた」です。

著者は新米DXエンジニアとしてRustを学ぶ過程で、画像変換アプリ「Tavif」を開発しました。このアプリは主要な画像形式を次世代フォーマットであるAVIFやWEBPに圧縮・変換する機能を持ち、制作には5~7日を要したそうです。

アプリ開発の動機は、既存のAVIF変換ツールに不満があったためで、「誰かに使ってもらえるアプリを作りたい」という思いからスタートしたとのこと。RustとTypeScriptを使用し、フロントエンドにはNext.js、スタイリングにTailwindCSSを採用したそうです。

開発中の苦労としては、ローカルファイルのプレビュー時のセキュリティ問題や、Reactライブラリのバージョン不整合、GitHub Actionsでのビルドの難しさが挙げられています。特に、TauriのCSPによるローカル画像の表示問題に対する工夫があったようです。

Rust/Tauriを使った開発は快適で、今後も技術のキャッチアップを続ける意向を示しています。新しい技術に挑戦する姿勢、素晴らしいですね。

それでは、今日お伝えした記事を駆け足でおさらいしてみましょう。

1つ目は「Riverpod の難しさを受け止めてみる」で、Riverpodの利点が強調されていました。2つ目は「ISUCON14 をベンチマーカーの限界を超えて最適化した話」で、最適化の努力が語られていました。3つ目は「Google DriveとLLMで議事録を自動生成する仕組みを作る」で、便利なシステムが紹介されました。4つ目は「pnpm workspace を利用したモノレポで『この PR の影響を受けるパッケージ』をフィルタする」で、効率的なテスト実行の方法が紹介されました。最後に5つ目は「Rust/Tauriに入門したので画像変換デスクトップアプリを開発してみた」で、新たなアプリ開発の挑戦がありました。

次回も皆さんにお会いできるのを楽しみにしています!詳しい内容はショーノートに書いてありますので、ぜひそちらもチェックしてくださいね。そして、番組の感想もお待ちしています!それでは、またね!

Related episodes

内容の近いエピソードを推薦しています