どうもこんばんは、マイクです。FMラジオ風テック番組「zenncast」、本日も始まりました。
今日は二千二十六年十月五日、月曜日の朝七時台にお届けしています。
この時間は、今日のZennのトレンド記事をピックアップして、みなさんと一緒にゆるっとチェックしていきます。
今日はですね、ぜんぶで五本の記事をご紹介します。
AI時代のテストの話から、自作OSの授業利用、トランザクション設計、次世代バージョン管理ツール、そして意外と罠だらけなJSONの仕様の話まで、けっこう盛りだくさんです。
それでは、さっそく一つ目からいきましょう。
。。。。
まず一つ目は、「AIがコードを書くようになった時代のテスト戦略」みたいなテーマの記事です。
ざっくりいうと、「AIがコードを書くようになっても、テストの本質的な役割は変わらないよ」という話なんですね。
この記事では、まずテストの種類ごとの役割が整理されています。
型チェックとか、リンター、それからユニットテスト、プロパティベーステストみたいな、いわゆる「細かいレイヤー」のテストたちは、ロジックの正しさとか、境界値のチェックを、ものすごく高速なフィードバックで、広く網羅的に検証する担当だと。
ここがしっかりしていると、AIにコードを書かせて、直して、また試して…という反復のサイクルを、安心してどんどん回せるんですね。まさに土台になるレイヤー。
一方で、インテグレーションテストとか、エンドツーエンドテスト、いわゆるEツーEですね。
これはどうしても遅い代わりに、データベースとか外部サービスとの結合、画面をまたぐフロー、本番に近いブラウザ環境でしか起きないような問題を受け持つべきだと。
なので「なんでもかんでもEツーEに突っ込めば安心」ではなくて、ここは本数とか実行タイミングにちゃんと戦略がいりますよ、という指摘をしています。
さらに面白いのが、「書かれていない不具合」の話です。
仕様の漏れとか、ユーザーの想定外の使い方みたいな、そもそもドキュメントに載っていないズレって、自動テストだけでは拾いきれないんですよね。
そこで重要になってくるのが、探索的テスト。
人間が実際に触りながら、「あれ、ここってこうも使えるよね？」みたいに試行錯誤することで、仕様の穴とか、設計の前提のズレが見えてくる。
で、そこで見つけた問題は、可能ならより速いレイヤー、たとえば型とかユニットテスト、プロパティテストに一般化して取り込んでいこう、とまとめています。
AIがコードを量産してくれるからこそ、「どの種類のテストで、どんな不具合を拾うのか」をちゃんと切り分けるのが、ますます大事になってきているんだな、というのが伝わる内容でした。
。。。。
続いて二つ目は、Rustで作られた自作OS「オクトックス」、英語だと octox ですね。
これが、サンフランシスコ大学のオペレーティングシステム、OSの授業で実際に教材として使われているという事例の紹介です。
この授業では、ガイドやスライドとセットで、システムコールとかカーネル、ページテーブルといったOSの仕組みを、オクトックスのソースコードと一対一で対応させながら学ぶようになっているそうです。
つまり、「教科書のこの概念が、ここ、この行のコードでこう実装されているよ」というのを、Rustのコードベースを通して理解していくスタイルですね。
課題もけっこう実践的で、たとえばユニックスでおなじみの `seq` や `tail` のようなコマンドを、オクトックス上で自分で実装してみる。
さらに `track` という独自コマンドと、それを支える専用のシステムコールを追加して、プロセスの動作を計測したり、可視化したりする課題もあるそうです。
こうすることで、ユーザー空間のプログラムを書くだけじゃなくて、その下にあるカーネルの拡張まで、一連の流れとして体験できるのが、このカリキュラムの大きな特徴になっています。
記事の後半では、「AIがコードを書く時代に、OSとかRustを学ぶ意味って何だろう？」という問いにも踏み込んでいます。
筆者のスタンスとしては、Rustの型システムを活かして、メモリアドレスの種別を型で分けるなど、安全性をプログラミング言語そのものに埋め込んでおくことで、AIが生成したコードも含めて、バグ検出とか形式的な検証をずっと効率よくできる、という話なんですね。
たとえばC言語でも、外部ツールと組み合わせて検証するアプローチはありますが、Rustの型による保証と、形式検証ツールを組み合わせたほうが、全体としてコスパがいいのでは、と。
で、その延長として、定理証明支援系の Lean を使って、オクトックスそのものの形式検証にもチャレンジしていく予定だと語られています。
自作OSが、単なる個人プロジェクトにとどまらず、大学の授業で使われて、さらに形式検証の題材にもなっていく、というのはワクワクしますね。
。。。。
三つ目は、トランザクション設計の話です。
これはECサイトの注文処理などを例にしながら、「トランザクションの中にどんな処理を、どんな順番で入れるべきか」を整理してくれている記事です。
まず前提として、トランザクションの中で行う処理は、失敗したときの扱い方によって三つに分類できると説明しています。
ひとつ目が「非保護」。これは失敗しても、まあ放置で問題ない処理。ログを書けたらうれしいけど、書けなくてもアプリ全体には影響しない、みたいなものですね。
ふたつ目が「保護」。データベース更新など、ロールバックで取り消せる処理。これはトランザクションの恩恵をフルに受けられる領域です。
そして三つ目が「実」と呼ばれているカテゴリ。メール送信とか、外部サービスへの決済リクエストなど、一度やってしまうと後から取り消すのが難しい、あるいは不可能な処理です。
ECサイトの注文を例にすると、在庫数の更新とか、注文テーブルへの書き込みみたいなものは「保護」にあたります。
一方で、お客様への注文確認メールの送信なんかは「実」の処理ですね。
ここで問題になるのが、取り消せない「実」の処理を先に実行してしまうと、そのあとに続く処理で失敗したときに、システム内部の状態と、現実世界の状態がズレてしまう、という点です。
メールでは「注文完了」と送ってしまったのに、内部的には在庫更新が失敗していて注文が通っていない、とか、怖いパターンですよね。
なので記事では、まずトランザクションに含める処理を整理したうえでの基本方針として、
「保護できる処理、つまりデータベース更新など、ロールバック可能なものを先にやる」
「そして、取り消せない処理、メール送信や外部決済といった『実アクション』はできるだけ最後に持ってくる」
という順番に組み立てよう、と提案しています。
それでも、「実」の処理が複数あったり、順番を入れ替えづらいなど、うまくいかないケースももちろんあります。
そういった難しい状況では、トランザクショナルアウトボックスパターンのような仕組み、つまり一度データベースに送信予定を確実に書いてから、別プロセスで外部送信を行う、みたいな構成も検討しよう、と締めくくっていました。
実務の設計で迷いがちなポイントを、分類と順序という切り口で整理してくれる、読み応えのある内容でした。
。。。。
四つ目は、バージョン管理ツールのJujutsu、読み方は「ジュジュツ」ですね。
AIコーディングが当たり前になってきて、逆にGitのややこしい操作とか、履歴管理がボトルネックになっているなかで、「Jujutsuを使うと、その負担と不安が劇的に減るよ」という話です。
Jujutsuの大きな特徴として紹介されているのが、「作業ディレクトリの状態が、そのまま履歴に保存される」という点です。
これによって、Gitでおなじみの `add` をどうしよう、ステージングどうしようとか、ちょっとだけ変えたから `stash` しておくか…みたいな細かい操作を、あまり意識しなくてよくなります。
もしファイルをうっかり消してしまっても、ほとんどの場合は履歴から戻せるので、「消したら終わりかも」という恐怖もかなり薄まると。
さらにJujutsuには、「チェンジ」という単位があります。
このチェンジを使って、ちょっとした実験や分岐、破棄、復元を、すごく気軽に行えるんですね。
結果として、Gitで頭を悩ませがちな、複雑なブランチ操作とか、リベースどうしよう問題から、かなり解放されると筆者は述べています。
履歴の表示も特徴的で、ふつうの一列のログというより、二次元のグラフとして、高い情報量で可視化してくれる。
で、「このときの状態に戻って少し直したいな」と思ったら、その地点に移動して、編集して、そのまま書き換える、という直感的な操作で済むようになっているそうです。
内部のストレージとしてはGitをそのまま使えるので、GitHubなど、既存のホスティングサービスともちゃんと連携できます。
ただ表面の操作感はGitとはまったく別物で、筆者は「もうGitには戻れない」とまで語っています。
あわせて、Git的な考え方から頭を切り替えるための、「挫折しないJujutsu入門書」も書いたそうで、JujutsuとAIコーディングを組み合わせた、新しい開発フローを広めていきたい、という意気込みも紹介されていました。
Gitに若干トラウマがある方には、ちょっと希望の光が見える記事かもしれません。
。。。。
そして最後、五つ目はJSONの話です。
「JSONってシンプルでしょ」と思いきや、仕様が厳密に決まっていない部分があって、処理系ごとに動きがズレることがあるんだよ、という内容になっています。
筆者が特に取り上げているのが、数値、文字列、オブジェクト、この三つの扱い方の違いです。
いろんな言語やデータベースで、JSONのこれらの型の扱いが微妙に異なるせいで、「同じJSONを読み込んだはずなのに、結果が違う」ということがありえる、という整理ですね。
まず数値について。
ある実装では整数と小数をきっちり区別するけれど、別の実装では全部フロートとして扱ってしまう、みたいな違いがあります。
さらに「安全に表現できる範囲」を超えたときにどうするかもバラバラで、エラーとして弾くライブラリもあれば、自動的に浮動小数点数に逃がしてしまうものもある。
プラスマイナスの無限大、いわゆるインフィニティとか、負のゼロの扱いも統一されていません。
文字列については、UTF十六のサロゲートペア、つまり補助平面の文字を二つ組で表す仕組みですね。
このサロゲートペアをどう扱うか、壊れたサロゲートが来たときにエラーにするのか、なんとなく通してしまうのか、そのあたりも実装によって分かれてきます。
オブジェクトについては、もっと身近なところで差が出ます。
同じキーがJSONの中で重複していたときに、最初に出てきたものを優先するのか、後から出てきたものを上書きとして採用するのか、それともエラーにしてしまうのか。
さらに、キーの順序をそのまま保持するかどうか、ここも統一された決まりがないんですね。
こうした細かな違いが積もり積もると、「サーバーではこうパースされてるけど、クライアントではこう見えてる」みたいな、ややこしい不整合につながります。
記事では、そういったポイントを一つひとつ整理して、「どこで差が生まれるのか」を意識しながらJSONを扱おうね、というメッセージになっていました。
。。。。
ということで、今日は五本の記事をご紹介しました。
AI時代のテストの役割分担の話、自作OS「オクトックス」が大学の授業で使われている話、トランザクション内の処理を三つに分けて順番を設計しようという話、Gitの不安を減らしてくれるJujutsu入門の話、そしてJSONが実は処理系ごとに挙動がズレるよという話まで、ざっと駆け足でおさらいしました。
気になった記事やキーワードがあれば、詳しい内容はショーノートにまとめてありますので、あとでゆっくりチェックしてみてください。
番組「zenncast」では、みなさんからの感想や、取り上げてほしいテーマのリクエストもお待ちしています。
「この技術もっと掘り下げてほしい」とか、「こういう現場あるある話してほしい」など、気軽に送ってください。
それでは、そろそろお別れの時間です。
お相手はマイクでした。また次回の「zenncast」でお会いしましょう。
今日も良い一日をお過ごしください。