Repro4PDE: コード編集後に動作と操作を任意の地点に復元可能な開発システムの実現

Repro4PDE: コード編集後に 動作と操作を任意の地点に 復元可能な開発システムの実現 明治⼤学 古賀壮 中村聡史 1

対象⾔語 ‒ Processing Processing: インタラクティブなアニメーションプログラムを 作るための⾔語。プロトタイピングや教育向き マウスクリックすると⾊が変わる⽟が左から右に動く例 2

デモ ‒ コンプリートガチャプログラム • ボタンを押すと5種類の カードの中から1枚を引く • それぞれ何枚ずつ持っている かを表⽰ • 全てのカードをコンプリート するとカードを⾚くする デモ⽤スペース 3

課題 ‒ Processingにおける動作確認の⼿間 • コードを修正して、動作確認のために再実⾏する時 プログラムは最初から実⾏されるため プログラムを動作確認したい状態まで持っていくのは⼿間 • アニメーションプログラムは実⾏に時間が掛かるので 特定の状態になるまで待つ必要がある • 例えば実⾏開始から1分後にバグが発⽣することが分かったら 修正して再実⾏後、動作確認のために1分待つ必要がある • マウスやキーボード操作が必要なインタラクティブな プログラムでは再度操作が必要である これらの⼿間を軽減できれば動作確認が簡単になり、 開発の⽀援になる 4

背景 - 既存のツール・関連研究 • Webフロントフレームワークにおけるホットリロード • ライブプログラミング⾔語 • REPLを⽤いて即時のフィードバックを可能にする 教育⽤Java開発環境[Allenら, 2002] しかし，Processingのように毎フレームユーザが定義した描画関数が 呼び出されるアニメーションプログラムに対応したものはない ALLEN, Eric; CARTWRIGHT, Robert; STOLER, Brian. DrJava: A lightweight pedagogic environment for Java. In: Proceedings of the 33rd SIGCSE technical symposium on Computer science education. 2002. p. 137-141. 5

⽬的 • アニメーションプログラムを作る⾔語であるProcessingを対象に 再実⾏時に前回の状態に持っていく ⼿間を減らすツールRepro4PDEを提案・実装 • 実験によってシステムの特徴について明らかにする 6

必要要件 • プログラム再実⾏時に前回の実⾏時と同じ操作をし、同じ時間 が経った状態にすることを容易にする • 実⾏位置を任意の位置に巻き戻すことができる 7

提案⼿法 ‒ 状態復元 • 実⾏位置やマウス/キーボードイベント・乱数のシード値を 記録しておき，再起動時にイベントを再現しながら 前回の実⾏位置まで描画処理などを省略しながら実⾏ 8

提案⼿法 ‒ UI 状態復元によってプログラムを任意の位置から実⾏可能に: • メディアプレイヤー⾵UIのシークバーによって、 プログラムの再⽣位置を変更可能にする 実⾏開始時(0フレーム⽬) 前回の終了時のフレーム数 9

提案システム • プログラムを修正すると⾃動で再起動し、状態を復元 • メディアプレイヤー⾵UIによって実⾏位置の変更や マウスホバーによるプレビューが可能 10

提案システム 実⾏開始から時間が経つと エラーが発⽣する例 システムを使うとプログラムを 変更してすぐにエラーが発⽣ しなくなったことを確認できる 11

実験 • 10⼈をシステムによる状態復元あり/なし群の5⼈ずつに分け 指定したプログラムを作る課題を3問⾏わせた • 以下のことを検証 • システムを使うことで動作確認の⽀援になるか • どのようなプログラムにおいてシステムが有⽤か • どのようなプログラムで検証したか • アニメーション要素があるプログラム • インタラクティブなプログラム • ランダム要素があるプログラム 12

実験 ‒ Q1: パラメータ調整タスク • ボールが壁に当たると跳ね返るプログラムを 配布し、摩擦係数と初速度を変更することで 緑の枠内で⽌まるようにパラメータ調整を⾏う • 動作確認に時間が掛かるアニメーション プログラムのパラメータ調整に有⽤かを検証 13

実験 ‒ Q2・Q3 • Q2: デモで⾒せたコンプリートガチャ • 乱数を使うプログラムにおける状態復元の有⽤性を検証 • Q3: マインスイーパータスク • インタラクティブで複雑なプログラムを1から作るのに使えるかを検証 14

結果 ‒ 正答数 Q1を除いて状態復元なし群のほうが正答率が⾼かった 15

結果 ‒ 回答時間の分布 システムあり群のほうが回答時間の分散が⼩さかった 特にQ1は安定して短時間で課題を解いている 16

結果 ‒ 実⾏回数の分布 Q1はシステムあり群のほうが短時間で多くの回数実⾏ していることが分かる Q2とQ3はあまり違いがない 17

考察 • パラメータ調整を⾏うタスクであるQ1は より多くの試⾏をできることが有利に働いたのでは • 実⾏を開始してから発⽣したイベント全てを再現するという 動作の理解が難しかったのでは • Q2，Q3は本システムで⽀援対象ではないロジックの難しさが ⼤きく，使い慣れないシステムを使うことによるデメリットが システムを使うことによるメリットを上回ったのでは • 今後: デバッガとの統合、⻑期実験 18

まとめ • 実⾏に時間が掛かるアニメーションプログラムや，マウスや キーボード操作が必要なインタラクティブなプログラムにおい て動作確認の⼿間を軽減するシステムを提案 • 実験の結果パラメータ調整タスクでは試⾏回数の増加などが⾒ られたが，その他タスクでは正答率が低下した • 今後はどのようなタスクが向いているのかといった検討や、 システムを使い慣れてもらった状態で実験するといった⻑期的 な検証が必要 19