おはようございます！ zenncast、MCのマイクです。11月7日、土曜日、朝7時になりました。週末の朝、みなさんいかがお過ごしでしょうか。今日もZennでトレンドになっている記事から、気になる話題をお届けします。
今日は、GPUでの学習を効率よく進めるSlurmの活用から、TypeScriptの設定、AI時代のテストツール選び、そして.NETやC#の一歩踏み込んだ工夫まで、全部で5本の記事をご紹介します！
....
まず1本目は、Slurmを使って、AIの学習実験を途切れずに進めるお話です。
Slurmに学習を予約しておくと、GPUが空き次第、順番に実行してくれます。GPUが1枚の環境でも、次の処理を人が投入するまでの待ち時間を減らせるんですね。しかも、AIエージェントの接続が切れてしまっても、予約した学習はそのまま続きます。
実行する順番は、sbatchの依存関係で指定します。たとえばafteranyなら、前の処理が成功したかどうかに関係なく次へ進みます。一方のafterokは、前の処理が成功したときだけ次を動かします。失敗しても続けたい実験なのか、成功が前提の処理なのかで使い分けるわけですね。
GPU、CPU、メモリの指定は、共通の投入スクリプトにまとめます。これでGPUの指定忘れや、ログの上書きを防げます。実験の設定、結果、そして「なぜ次にこの実験をすることにしたのか」という判断の経緯も、ファイルに残しておくのがポイントです。エージェントが再開したとき、そのファイルを読み直せば、途中から作業を続けられます。
運用面では、squeueで待機中・実行中の状況を監視して、予約が減ったら通知する仕組みも用意します。Slurmだけで次の実験を追加したり、通知したりしてくれるわけではないので、ここは別途仕組みが必要なんですね。
さらに、メモリの必要量は学習時だけでなく、評価時も測って決めること。再起動したあとは、nvidia-smiとsinfoで、GPUとSlurmが正常か確認することも大切です。計算を回す仕組みと、作業の記録を残す仕組み。この両方が、実験を止めないための鍵になりそうです。
....
続いて2本目は、TypeScriptのパスエイリアスを、Node.jsの標準仕様に寄せていこう、という記事です。
TypeScriptでは、tsconfig.jsonのpathsでパスエイリアスを設定できます。ただ、これだけでは済まず、ビルドツールなどにも同じ設定が必要になることがあります。さらに、Node.jsで実行したときに、ファイルが見つからないという問題が起きることもあるんです。
そこで筆者が勧めているのが、Node.jsの標準仕様であるSubpath Importsへの移行です。設定をpackage.jsonに集約できるため、対応しているツール同士で設定を共有でき、追加ライブラリへの依存も減らせます。
同じ設定をあちらにも、こちらにも書く。その管理の手間を減らせるのは、うれしいですよね。
もう1つの利点は、実行環境に応じて、読み込むファイルを切り替えられることです。ただし、エイリアスは必ず「#」で始める必要があります。今使っている名前をそのまま移せるとは限らないので、移行時には、このルールも確認しておきたいですね。
....
3本目は、Claudeにテストを書かせるなら、有料のMagicPodは必要なのか、という比較のお話です。
筆者は、未知のWebアプリを対象に、MagicPodとPlaywrightを比べています。その結果、テストの質はほぼ互角。一方、作業の速さと、日付を制御する点では、Playwrightが優位だったそうです。
ただ、この記事で大事なのは、生成されたテストの出来だけで選ばない、という視点なんです。筆者は、決め手になるのは「誰がテストを読み、直し、動かし続けるか」だと述べています。
エンジニアが中心なら、コードとして管理できるPlaywrightが向いています。一方で、コードを書かない担当者がテストを修正したり、実行環境の管理まで任せたかったりするなら、MagicPodには引き続き価値がある、という整理です。
作れるかどうかだけでなく、作ったあとの運用まで見る。これは、ツール選び全般にも通じる考え方ですよね。
なお、実験は限られた条件で、それぞれ1回ずつ行ったものです。この結果だけで、どちらが一般的に優れているかは断定できません。そして、どちらを使う場合でも、AIが作ったテストは1回成功しただけで安心しないこと。繰り返し実行して、安定して動くかを確かめる必要があります。
....
4本目は、IL、つまり中間言語の命令を使った、少し低いレイヤーのお話です。
記事では、constrained.命令を直接使うことで、型制約のないTでもDisposeを呼ぶ方法を紹介しています。この方法では、構造体の元の値を直接更新でき、メモリ割り当てなしで、その変更を残せるのがポイントです。
ただし、呼び出す前の確認は欠かせません。対象の型がIDisposableを実装しているかを調べて、その結果を型ごとに保存しておきます。実装していない型をそのまま渡すと、例外が起きたり、プロセスが終了したりする可能性があるためです。
さらに記事では、構造体をobjectとして扱うためのボックスを、スタック上に手動で作る方法も紹介しています。検証した.NETとUnityの環境では、ILによる呼び出しと、この手動配置の両方で、準備処理が終わったあとのメモリ割り当てはゼロだったそうです。
とはいえ、手動配置には注意点もあります。実行環境ごとのメモリ配置に合わせる必要があり、作った参照を呼び出しの外に残してしまうと無効になるため、寿命の管理も必要です。
既存の変数をref Tで更新したい用途には、ILによる呼び出しが向いている、ということですね。割り当てを減らせる魅力だけでなく、安全に成立する条件まで、しっかり押さえておきたい技術です。
....
最後、5本目は、ビルド前の処理をC#で完結させる方法です。
使うのはDirectory.Build.targets。.csprojと同じフォルダーに置いたbuild.csを、ビルドやテストの前に自動実行する仕組みを紹介しています。OSごとにシェルスクリプトを用意したり、人が手作業で準備したりする手間を減らせるんですね。
用途として挙げられているのは、外部ファイルの取得や、データをC#の定数に変換する処理です。実行時に必ず最新版を取得する必要がないなら、ビルド時に取り込んでおくことで、安全性や実行速度の改善につながります。
また、build.csの先頭に、dotnetで実行することを示すシバンを付けておく工夫も紹介されています。これによって、設定ファイルの追加忘れをエラーとして検知できます。
運用上は、テストのたびに処理が走る場合への配慮も必要です。ファイルの更新時刻などを見て、実行頻度を調整します。また、この使い方ではVisual Studioで入力補完が効かないため、記事ではVS Codeを勧めています。
普段のC#の知識を、アプリ本体だけでなく、ビルド前の準備にも生かす。作業環境を整える選択肢として、覚えておきたいですね。
....
さて、今日のzenncastは、5本の記事をお届けしました。
Slurmで学習実験を途切れずに回す工夫、Subpath ImportsでTypeScriptのパス設定をまとめる方法、MagicPodとPlaywrightを運用する人の視点で選ぶお話。そして、ILを使った割り当てなしのDispose呼び出しと、C#でビルド前処理を自動化する方法でした。
詳しい内容はショーノートに書いてありますので、気になった話題はぜひチェックしてみてください。番組の感想もお待ちしています。「この話が役に立った」「こんなテーマも聞いてみたい」など、気軽にお寄せくださいね。
この番組はSpotifyやApple Podcast、YouTubeなどで毎日配信しています。気に入ったら、登録や高評価をつけてもらえるとうれしいです！
それでは、次回またお会いできるのを楽しみにしています。みなさん、すてきな土曜日をお過ごしください。マイクでした！