ライブコーディングを使用して教えるためのヒント


11

初年度のプログラミングとアルゴリズムのコースに参加しています。最近の講義で、ライブコーディングを使用して資料を提示することにしました。つまり、本質的にはキーボードの後ろに座ってコードを記述し、emacsを使用してコードを評価し、プロセスを容易にしました。

これは非常に成功し、学生たちはよりアクティブなフォーマットを高く評価したことについてコメントしました。これがこの教育形式を使用した最初の試みだったので、完全に実行されなかったことがわかります。問題の中には、emacsに精通していないことに関連するものもあれば、生徒の質問によってスクリプトから遠く離れすぎてしまうこともありました。私はもっ​​と上手にできることを知っています。

ライブコーディングレクチャーを使用してレクチャー(およびその他のデモンストレーション)を行うためのガイドラインは何ですか?
避けるべき落とし穴は何ですか?


2
私はライブコーディングについて予約しています(主にスループットと理解の幻想について)。それにもかかわらず、2つの提案があります。1)質問を構造化するために、クラスルーム応答システムの使用を検討しましたか?2)それがどれほど実用的かはわかりませんが、ideone.comのようなものを使用することは興味深いかもしれません。なぜなら、学生は講義後にあなたのコードにアクセスし、何もインストールしなくてもそれを実行できるからです。
ラファエル

@Raphael:私は以前よりもずっと注意を向けていました。それは確かにプラスです。あなたの二つの提案はとても良いです。1)現在、実際にフォローしている人だけが何らかのフィードバックを提供しています。2)私の言語はリストにありません。そうは言っても、すべてのコードはスライドで使用できます(私は無視しました)。
デイブクラーク

回答:


8

ここでは、1週間ライブコーディングを使用した後、および同僚との会話から収集したいくつかのヒントと落とし穴を示します。

する

  • 従うスクリプトを準備し、それに固執するようにしてください。
  • バッファを頻繁にクリアして、関連する部分に焦点を当てます。
  • 新しいトピックごとに新しく開始します。
  • 大きなフォントを使用してください。
  • 使用しているツールを習得して、些細なことに時間を浪費しすぎないようにします。
  • バックグラウンド関数を事前にコーディングしてください。特に関係がない場合は、作業ファイルに表示されるのではなく、インポートできることを確認してください。
  • すぐにフィードバックが得られる言語で作業することが理想的です。この点で、対話型シェルの言語が最適です。
  • 型付きを使用する場合は、記述している関数の予想される型を指定してください。これは、生徒にガイドライトを提供します。
  • 自由に間違いを犯します(多すぎません)。これらがどのように修正されるべきかをステップスルーします。
  • 忘れないでください–絵は千の言葉を描く:インターリーブスライドとブラック/ホワイトボードはコーディングセッションで機能します。
  • あなたがカバーしたポイントの要約スライドがあります
  • コードを変更するときに、コピーを作成してそのコピーを変更する場合があります。これは比較のポイントを提供します。
  • コードを定期的にクリーンアップします。
  • あなたが間違いを犯し、公然と生徒があなたを訂正できるようにすることを受け入れます-これにより、仕事が簡単になり、彼らに力が与えられます。
  • 独自のスタイルでコードを記述します。たとえば、他の場所からコードをコピーした可能性があります。しかし、これを再現するのは難しいでしょう。自分のスタイルで書いたほうがいいです。たとえば、私は主にHaskellをプログラムしているので、常にカリー化された関数を記述します。しかし、標準MLはこのイディオムをあまり頻繁に使用しません。カリー化された関数を期待することは、私がクラスで行う最も一般的なエラーです。
  • 物理的には、スペースが適切に設定されていることを確認してください。適切な高さ、適切な高さのケーブル、すべてのケーブルが適切な場所にある、物理的な障害物など、優れたキーボード。スペースを確保するために、1分ほど時間をとってください。
  • 1つのアプローチは、たとえ間違っていても、生徒の言うことをすべて書くことです。これにより、学生はコーディングと修正を行うことができます。最後にコードをクリーンアップすることをお勧めします。このアプローチは、生徒が何が起こっているかを理解するために注意を払う必要があるため、注意と相互作用の教室モデルを作成することができます。

してはいけないこと

  • オンザフライでコードを最適化して、修正できないような方法でコードを壊さないでください。
  • コンピュータとの会話は避けてください。生徒と話してください!
  • 特にボイラープレートコードのタイプをしすぎないようにしてください。環境を利用して、テンプレートを吐き出してください。
  • テキストエディタを使用する場合は、常にスクロールしないでください。追従しようとする人に乗り物酔いを引き起こします。
  • テキストエディターを使用する場合は、コードに根本的な変更を加える前に、生徒に何が行われているのかを追跡できるように、そのことを生徒に警告します。

1
あなたのクラスには何人の生徒がいますか?インタラクティブ性に対するDOは好きですが、それが50、100、250人の学生にどのように拡大するのか疑問に思います。
ラファエル

1
クラスの後にコードを公開していますか?生徒があなたが作成したさまざまなバージョン(クラスに登場したことのない洗練されたコメントバージョンなど)を閲覧し、その違いを確認できるGithubリポジトリを想像します。また、リポジトリを複製して、一度作成したアルゴリズムを宿題のサブルーチンとして簡単に使用することもできます(それが望ましい場合)。
ラファエル

1
コードを実行するための単体テストを準備していますか?それがすべてのクラスで適切であるかどうかはわかりませんが(プログラミング言語、ソフトウェア開発、またはアルゴリズムの原則を学ぶことに重点を置いていますか?)、途中でいくつかのベストプラクティスがわかるかもしれません。
ラファエル

2
1)クラスには128人が登録しましたが、約60〜80人が参加しています。2)スライドにすでにコードがありますが、スライドを使用していません。ですから、生徒たちは私がすることのバージョンを持っています。中間のステップはありません。すべてのバリエーションがあるのがどれほど面白いかはわかりません。3)いいえ、私はしませんが、非公式な仕様を書いています。焦点は、最初のプログラミング言語といくつかのアルゴリズム/データ構造を学ぶことです。しかし、私は同意します。ユニットテストは、コースにさらに深く統合することを検討するものです。質問/暗黙のヒントをありがとう。
デイブクラーク
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.