自分がライブ コーディングデモをするときに気を付けていること
更新履歴
- 2024/12/05 初版作成
- 2024/12/05 「普段からツールを使いこなす」を追記
はじめに
私は、勉強会などで登壇するときにライブ コーディング デモをすることが多いです。
例えば、先日行われた .NET Conf 2024 in Roppongi Tokyo (Visual Studio Users Community 勉強会 #7) ではライブコーディングのデモがメインのセッションをしました。
ここで動画を確認できるのですが 03:05:00 から 03:13:00 までの 8 分が説明パートで、そこから 03:52:00 までの 39 分がライブ コーディング デモです。その後、03:53:30 まで、まとめをして終了といった感じです。
なので 50 分のセッションのうち 40 分がライブ コーディング デモという感じでした。(今、時間をはかってみて思ったよりコード書いてる時間の方が長くてびっくりしてる…。)
ここまでライブコーディングが多いのは流石に珍しいですが、基本的に何かのセッションをする際にはライブコーディングをすることが多いです。
ということで、今回は私がライブコーディングデモをするときに気を付けていることを書いていきます。
スペック
その前に私のスペックは以下のような感じです。
- IT 業界の経験: 20 年
- 主なプログラミング言語の経験: C#, F#(今は書けない), TypeScript, JavaScript, Java(だいぶん怪しい), Kotlin(今は書けない), Ruby(今は書けない), C++(今は書けない)
- タイピング速度: HHKBタイピング王決定戦をしてたときの速度
タイピング速度があると、できるライブコーディングの幅が広がるので鍛えよう！タイピングが遅い人はクリップボードとかをつかったコピペで代用できますが、ライブ感がちょっと落ちます。
ライブコーディングデモをするときに気を付けていること
ということでライブコーディングをするときに気を付けていることを書いていきます。
事前準備
身も蓋もないかもしれませんが事前準備が 1 番大事です。
普段からツールを使いこなす
ライブコーディングをするようになってからコードを書くのに使うツールを使い始めるのは手遅れとは言いませんが、普段からツールを使いこなすようにしましょう。
私の場合は Visual Studio 2022 がメインの開発環境で大体毎日起動して何らかのコードは書くことが多いです。他のツールでも、コードを書くためのエディター機能については、色々な機能が詰まってる部分だと思うので、普段から使いこなすようにしています。どういうコードを書いたら、どういう補完が行われるのか、どういうショートカットがあるのか、どういう時に、どういう補完機能がトリガーされるのか、最近なら GitHub Copilot が出してくれる提案にはどういうものがあるのか、などをなるべく沢山触って覚えましょう。
ライブコーディングをするときは、大体緊張するので調子が良くても普段の８割くらいしか書けなくなるので、その状態でデモができるくらいには普段から鍛えておきましょう🦾
デモ シナリオを考える
これは地道にシナリオを考えるしかありません。まず、紹介したい機能を紹介できる実装の流れを考えます。
例えば .NET Conf 2024 in Roppongi Tokyo のセッションだと、以下のようなものを伝えたいと思っていました。
- 出来上がったプログラムを紹介するのではなく、最初から作ることで実際に見た人が触る際のイメージを持ってもらう。個人的には、このポリシーはどうしても無理な場合を除き入れています。
- Microsoft.Extensions.AI を使った Chat Completions API の呼び出し
- Microsoft.Extensions.AI のミドルウェア機能
- キャッシュ、ログ、関数呼び出しの自動化
- 言語モデルを切り替えても共通のコードで動作すること
- Microsoft.Extensions.AI のミドルウェアの自作
- Microsoft.Extensions.AI を使った Embeddings API の呼び出し
これらのことを紹介するためのシナリオを考えます。今回は AI を呼び出すためにローカルかクラウドに言語モデルをデプロイして使えるようにする必要があります。私の手持ちの札はローカルで実行させるか、Azure OpenAI Service を使うという 2 枚でした。最初に考えたシナリオはこんな感じです。
- Ollama でローカルで動かす
- Azure OpenAI Service に切り替えて同じコードで動くことを示す
- 上の 1 と 2 を Chat Completions API と Embeddings API でやる
ということで、この順番で実際にローカルでリハーサルをします。本当に最初からやりたかったので .NET Aspire と呼ばれるローカルでの開発用オーケストレーションのツールを使って、Ollama のコンテナイメージを pull して phi3 などのモデルを使ってローカルで動く環境を作って、Azure OpenAI Service に gpt-4o などをデプロイする処理を書いてみました。
ぶちあたった問題点
- 環境作るだけですごい時間かかる…
ということで早々にモデル切り替えは諦めて Azure OpenAI Sevice 一本に方針転換をしました。とりあえずモデル切り替えても動くのは口頭で言おうそうしよう。
また、ライブコーディング全体が１つの流れになるように今回はデモを組み立てたいと思ったので以下のような流れにしました。
- .NET Aspire で Azure OpenAI Service をデプロイする
- デプロイが動き出したことを確認したらコーディングタイム
- Azure OpenAI Service を呼ぶためのコードを書く
- Microsoft.Extensions.AI を適用してチャットを実装する
- .NET Aspire のダッシュボードでログが出ていることも見せる
- チャットを実装して、動きを見せた後にキャッシュのミドルウェアを追加して同じリクエストにはキャッシュを返すようにして凄い早い！というのを見せる
- ミドルウェアで OpenTelemetry のログを出すように構成してログが良くなっていることを見せる
- 関数呼び出し機能を追加して今日の天気を答えられるようにする
- 関数呼び出しのハンドリングをしないと中途半端に終わることを見せる
- これを手で実装することはメンドクサイ感を出す
- 関数呼び出しミドルウェアを適用して凄い簡単！！って感じを出す
- ミドルウェアを自分で実装できることも見せて既存のチャットに適用
- Embeddings モデルの text-embedding-3-large を .NET Aspire を使ってデプロイする
- Embeddings API を呼ぶためのコードを書く
- ちゃんと動くことを見せる
- モデルが変わっても共通のコードで動くということを口頭で伝える
実際には、どこでどんな機能をどういう順番で入れるといいのかは、何度もリハーサルをして決めていきます。
練習とカンペ準備
処理の流れを頭に叩き込んだら練習をします。
練習をする中で自分が忘れやすいポイントや、これを見たら何をしたいのか思い出せる必要最低限のカンニングペーパーを PowerPoint のノート欄に書いておきます。例えば、今回のセッションでは以下のようなメモを書いていました。
1 枚目のデモスライド
猫型アシスタント チャットアプリ
- .NET Aspire で AOAI デプロイ (放置)
- Blazor Web App に WithReference
- Microsoft.Extensions.AI, Microsoft.Extensions.AI.OpenAI, Aspire インテグレーションの OpenAI
2 枚目のデモスライド
キャッシュ (DistributedMemoryCache で)
OpenTelemetry (sourceName:builder.Environment.ApplicationName を忘れずに)
Function calling (今日の品川の天気シナリオ）
AI のモデルの種類に限らず使える (Function calling は対応していないモデルだと無理）
3 枚目のデモスライド
UseCatAgent を作成
モデルに限らず使えるミドルウェア
ポイントは、文章を長々と書くと別の人に発表してもらうときにはいいのかもしれませんが、自分で作って自分がやるときには、文章のどの位置まで読んだのかわからなくなるので、必要最低限の思い出すためのキーワードだけに留めて、デモ中に一瞬チラ見すれば全体を把握できるくらいの量にしておくことです。
こうすることで「はい、では～」とか言ってる間に確認できます。
バックアッププランの準備
ライブコーディングに魔物はつきものです。
何回練習しても本番ではうまくいかないということが稀によくあります。
そんな時のためにバックアッププランを用意します。自分がとるバックアッププランは以下の２通りがあります。
- 「出来上がりがこちらです」を用意しておく
- どうしてもうまくいかないとき用に完璧に動くものを準備しておいて、うまくいかないときはそちらに切り替えます。基本だけど大事。
- デモにいくつかのチェックポイントを設けておいて、必須でやる場所、時間があったらやる場所のパートにわけておく
- 絶対に見せたいデモは最低限ここまで！ということを決めておいて、残りはオプションという感じにしておくと手間取って時間がなくなったときにはオプションはやらないでおくといった時間調整が出来ます。時間調整のバッファーがあると心にゆとりがうまれて、うまくいかないときにも冷静に対処できるようになります。またゆとりがあると結果としてうまくいくことが多いです。
- デメリットは最初から何も動かないと詰むので絶対に失敗できないものの場合は 1 と併用する
- 途中で省略したデモについても内容が確認できるような記事やスライドを用意しておいて、オプションをスキップした時にも何をしようとしたのかは伝わるようにしておく（今回はデモの内容と、ほぼ同じ内容の記事を zenn に書いていました)
今回はコミュニティイベントだったので、上手くいかないこともエンタメかなと思って 2 のプランだけで行きました。結果としては予定していたものをすべて実施できたので良かったです。
最終リハーサル
これまでのことが出来たら、実際に本番想定のリハーサルを行います。
そして、ライブコーディングデモ開始前に絶対にやっておく準備を箇条書きにしておきます。
例えば今回のセッションだと以下のような感じでした。
- Docker Desktop を起動しておく
- Visual Studio 2022 のプロジェクトの履歴からリハーサル用のプロジェクトを消しておく
- Azure ポータルを開いて Azure OpenAI Service の東日本リージョンにモデルをデプロイする余裕があるか確認 (リハーサルで作ったモデルが残ってると枯渇しがち)
- 通知をオフ
- zoomit を起動して動作確認をする
余談ですが zoomit は画面を拡大した状態で画面操作をしたり、画面を拡大して、そこにマウスで書き込んで注釈をつけたりできるので便利です。拡大鏡と違ってマルチモニター環境でも操作しやすいです。Windows ユーザーにお勧めです。
WinGet でインストールできます。
https://winstall.app/apps/Microsoft.Sysinternals.ZoomIt使い方はこちら
https://learn.microsoft.com/ja-jp/sysinternals/downloads/zoomit
ライブコーディング実施直前
最終リハーサルの所で書いたチェックリストを確認して本番に備えます。
ライブコーディング中
ライブコーディング中は以下のことを気を付けています。
- 待ち時間のある作業をやるときは、その時裏で何がおきているのか、これから何が起きるのかを話す (大事！！)
- 例: 今は裏で Azure にデプロイするためのテンプレートが .NET Aspire の機能でコンパイルされています。そして、そのコンパイルが終わるとデプロイが始まります。あっ、デプロイが始まりましたね！
これをすることで、この待ち時間は想定されているものなのか、何かトラブルがおきているんじゃないのか？という不安を取り除くことができます。
- コードを書く前に、これから何を書くのかを説明する
- コードを書いた後に、今何をしたのかを説明する
私も、一度説明を受けただけだと忘れるので、何をするのか、何をしたのかを言葉にすることで、見ている人にも何が書かれたのかを理解する助けになりますし、何より自分の頭の中で整理することができます。同じことを２回言っている間に次に何をやるのかを整理する時間として使うこともできます。
- 上手くいかないときは助けを求める
上手くいかないときは、何度練習していてもどうしてもテンパるので、やろうとしたことと何が違うのかということを説明して、聞いている人に助けを求めます。きっと最前列に座っている凄い人が助けてくれます。安心しましょう。
また助けを求めるために説明をすることで、自分でも間違いを気づくことができることがあります。
- デモがうまくいかなくてオプションのデモが出来ない時にはちゃんと用意しておいたバックアッププランを見せる
- 焦ると忘れがちなので注意
まとめ
ということで、あまりまとまりがないかもしれませんが自分がライブコーディングをする前と、する際中に気を付けているところを思いつくままに書いてみました。
もしかしたら、追加で思い出したことを記事内に追記していくかもしれません。その時は、X の方で更新した旨と記事のトップの更新履歴に追記した内容の概要と日時を載せる予定なのでそちらを参照してください。
それでは、良いライブコーディングを…！
Discussion