NAL’s blog @ 琉球大学情報工学科

プログラミング1でモブプロ（っぽい）演習が始まりました。友人づくり含めて繋がり形成も兼ねてますが、概観する限りではそれなりにうまく回ってるようです。多分。恐らく。

形式としては、
　・チームごとにZoomでルームつくる。
　・やってる最中の作業ログをGoogleドキュメントで共有する。
みたいにやってます。
Zoomのbreakoutしても良さそうですが、明確に記録残したい（その方がフォローしやすい側面もある）ので、この形でやってみてます。

冒頭ぐらいは意図的なファシリテーション役を配置してやるのがベターだとは思うのだけど、贅沢いってられないし。逆に今の遠隔授業だからこそやれるなということで、Zoomでモブプロ。教室内だと5名で集まるスペースを作ること自体が難しし、隣のチームの声が煩すぎると集中できないんだよね。「すぐ隣が頑張ってるからこっちも気合い入れよう」みたいなポジティブな面もあるんですが。何でも良し悪しですね。

今は遠隔授業でしかやれないし、スペースという意味では物理的制限がないので、チーム内でうまく動き出せるなら今の方が良いです。ただ、その「うまく動き出せる」ところまでの手助けはした方が良いよね。ということで、次回からはその辺りのサポートをどうにかしてみようかと。（実際にはTAに頑張ってもらうんですがw）

昨日から平日ですが、5/7(木)は水曜日振替になってて授業が水曜日体制になってて。それでも学生側の都合に問題なければ学生実験やろうかと思ってたんですが、数名都合つかない人いたので授業なしに。ま、仕方ない。ということで今朝のプログラミング1がGW明け初の授業です。

例年ちょこちょこ内容いじってたりしますが、今年度は今週第5回目までで最小限のところ（変数、逐次処理、条件分岐、ループ、関数定義、デバッグ実行）はほぼ終わってます。新しい概念・用語等使いまくり（一応説明してはいるし、教科書にも書いてある）なので、自分でまとめなおしてみろよ〜とか伝えてみたり。Mindmap紹介したり。

それでもペース早いとは思うので、来週は新しい内容少なめにして復習を目的とした演習メインの予定。グループに分かれてZoomでのモブプログラミング形式でやってみるつもりですが、実際うまくやれるかは「？」です。仕込みというか事前準備は今日でやってみました。

どうなるかなー。

4/22までは調整期間という位置づけだったので、これまでは環境・資料作りしたり、Teams/Zoom演習をしたりしてました。試した範囲では授業中は「Zoom + Mattermost + Google Drive (Documents)」でやり、サポート的にメール使うぐらいが良い感じ。喋ってる間にも疑問に思ったことは自由に Mattermost に書いてもらって、その間は随時TAがサポート。大きな問題もなく、かつ授業後のアンケートみる姜切りでは丁寧にフォローできていたんじゃないかな。

ついでに、今回の新入生は友人づくりする時間もなく「授業開始延期=>遠隔授業のみ」というコンボを食らっているので、ほぼほぼ見知らぬ同士状態。これは不味かろうということで少人数グループのZoomミーティング立ち上げてもらって自己紹介＋雑談でグループ構築もやって貰いました。こちらもアンケート上は9割以上が前向き解釈してくれてるな。かつ、授業後の質問対応で学生側にホスト立ち上げてもらってやり取りするというのもスムーズにやれたので、良かった。

そんなこんなで遠隔授業にも良い点あるんだから前向きに取り組まないと。やれる範囲でいいから、少しずつそのやれる範囲を増やしていければ。

プログラミング1の最初の課題は、例年 print 使わせつつ＋αさせてるぐらい。教科書のコードを動かせることの確認ですね。ついでに教科書買ってること確認するためにそっちの課題からピックアップすることもあるんですが、今回は用語を自分なりに解釈してもらおうかと。どういう関連付けでも体系化でも良いので、自分の言葉で説明できる形で整理してみてね。

レベル3はomittすることも考えてますが、「わからないことをどう調べるか？」という課題だったりするので、見てくれに騙されなければ難しくはないのだよな。

河野先生からプログラミング授業のエディタでVisual Studio Codeにしてはどうかという提案が。

インストール後にアプリ起動すると ~/.vscode が生成されるけど、ここにはプラグイン関連が置かれるだけ？　後で設定したインタプリタとかの記述は見つからないな。どこに保存してるんだろ。アプリ削除してインストールし直しても、指定したインタプリタを優先するようになってるのでどこかに保存してるはずだが。

初めて起動するとwelcomeウィンドウ表示されてて、そこで言語ごとの最小限のプラグイン（インデント、カラー表示、補完ぐらい？）がインストールできるっぽい。

Pythonインタプリタの設定方法が良くわからなかったのだけど、一番簡単なのは一度適当な.pyファイル保存すると画面左下にインタプリタが表示されるようになるので、そこで選択することか。

これぐらいで最小限の環境になるっぽい。

VS CodeでPython動かす場合、基本的にはRun/Debugぐらいに留めて、gitとかdoctestとかはコマンドラインからやる流儀なのかしら。extension探すとgitあれこれ出てくるけど、そっちは使いたい人が勝手に使えで良さげな感じ？　統合開発環境じゃなくて「エディタ」と呼んでいるだけあって、基本はそっちメインなのかな。確かにデバッガサポートあるならそれで十分ではあるだろうし。

気持ち悪いのは、PyCharmでいうところの「新規プロジェクト作成」に相当する機能はないのに、何か設定いじろうとするとworkspace開けみたいにいわれることか。最初から作らせろ〜。

プログラミング1を担当し始めて4回目。課題設計はまだまだ試行錯誤の余地大きいですが、授業全体の流れは固まりつつあるかな。毎年見直してて特に今年は大きめに変えてますが、それでどうにか落ち着いた感じ。

授業評価アンケートを見る限りでは、基本的には書いてくれてる人は「難しい」「達成感はある」「予襲復讐の必要性を感じた」みたいな感じらしい。

今回は課題を難しめに用意して「最後までやれなくても良いから取り組んだ過程を書いてくれ」という形でやってみたのですが、やっぱりそう簡単にはうまくいかなくて。他人のレポートを読んでみて良いとこチェックしてみるとかもやってみてますが、これも何度も繰り返してみないと「報告書として何を書けばよいのか」が身につきにくいのだろうな。もう少し丁寧にレポートに対するレビューしてあげられれば良いとも思うけど、簡単すぎる課題の場合には「過程も何もやった内容を使って実装する」ぐらいで、難しすぎると「そもそもどう取り組むかが思いつかない」学生が多いらしい。

道具は提示しつつ、その組み合わせで考えてみてという話をしたり。
実際に問題を分割して考える例を示してみたり。
最初から小分けされたものを実装して、まとめあげてみたり。
腑に落ちる学生もいますが、落ちない学生がゼロにはならないですね。
仕方ないのかもしれないけども。

Q4.この講義で補助教材は役に立ちましたか？
（※ここでの『補助教材』は、「シラバスにある参考書、または参考図書、授業中に配布されたプリント、配布データ、サンプルプログラム、サンプルソースなど」を指しています。配布物はオンライン配布（講義のページからなど）のものも含めます。）

毎年のことですが、上記に対する回答で「補助教材がなかった」と回答する人いるし、、。

大辞林で「構造」を検索した時の説明文がこれ。

① 全体を形づくっている種々の材料による各部分の組み合わせ。作りや仕組み。 「機械の－」 「耐震－」
② さまざまな要素が相互に関連し合って作り上げている総体。また、各要素の相互関係。 「社会－」 「精神－」 「物質の－」 「文の－」 「汚職の－」

プログラミング1や、赤嶺先生の演習1で何度も出てきているキーワードの一つが構造化。対象をどういう機能に分解できるのかを考え、その機能を一つずつ作り上げていく。

最初から綺麗に分解できるとは限らないので、間違っても良い（後で使わない事になっても良い）からまずは「何かしらの一つの処理を実現する機能」に分解してみて、それを確認するための簡単なテストを用意し、テストが通るように実現する。

想定通りに動かないなら、使ってるライブラリのドキュメントを参照したり、デバッガを利用して、「何故こう動いているのか？」を明らかにしよう。

まずはテストが通ることを最優先し、バージョン管理。バージョン登録することでいつでもそこに戻れるようになる。余裕があればその動いたコードを俯瞰して、「よりうまい機能の切り出し方がないか」、「似たようなコードが散見していないか」等の観点から、見通しの良いコードを目指してみよう。

関数名・変数名等の命名規則や、ドキュメントも適切に用意することでコードの読みやすさが向上する。

みたいな話を14週かけてやってきました。残す所あと1回。

プログラミング1でユニットテスト（doctest）自体は既にやり終えてましたが、復習も兼ねてもう一度。関数単位での動作確認をしやすくするため、使い方例示のため、といった振り返りをしつつ、今回はテスト駆動開発のお話も。

実際にはいくつかの要素を組み合わせて振り返ってるので、だいぶ時間が。

• まずテストを無視してシンプルな関数を書く。
• その関数を実行するコードを書いて動作確認。
• そのスクリプト1を別ファイル2からimportした時の動作確認。
• その理由を確認するためにbreakpoint指定してデバッグ実行。
• 特殊変数の確認と、これがimport時と直接実行時とで中身が変わっていることを確認。
• 元のスクリプト1を、__name__で動作変わるように修正。
• スクリプト1をimport時の動作と、直接実行した場合とでの動作の違い確認。
• doctest追加して、テスト実行。
• 関数を拡張して、2要素を返すように修正。戻り値がtupleになってることを確認。
• tupleに合わせてテストを修正。スペース有無含めてstr型での判定になっていることの確認。

ぐらいの内容で、ユニットテスト＋import＋関数戻り値を確認しつつ、新しいtuple型の説明までをまとめて実行。ユニットテストがあるとドキュメントを補足する例示にもなるよと。

それを踏まえて、同じ関数を「最初はコードを分からないものとし、最初にテストを書こう」ということでテスト駆動開発の話へ。

• 実現したい関数の入力と出力の組を1例考え、テストとして記述する。
• そのテストが通るような実装を書く。
• そのコードでは通らないような別のテストを書く。
• 以下繰り返すことで、少しずつ一般化していくことを考える。

みたいな演習。

テスト駆動開発がベストだとは思わないけど、モデルの入出力を明確にすることでそもそも何を実現したいのかを目に見える形にする、という点では間違いなく有用だよね。

例年だと、Thonnyという「初心者向けIDE」を使ったデバッグ実行に、PyCharmでのデバッグ実行（breakpoint, step into, stackframe確認とか）ぐらいで終わってました。それでも前期の間に2回取り上げているという話でもあるけども。

今年はこれに加えて、PyCharmによるデバッグ演習2で、「マニュアル見よう、エラー文解釈しよう、デバッガから得られる情報から推測しよう、処理対象を小さくしよう、最小限のコードで再現してみよう」というデバッグ・シンキングな演習もやってみました。

step intoとか breakpointぐらいの操作は別例でやってます。それでも一回では慣れない部分もあるし、それ以外にも「そもそも要因を発見する、特定する」ための考え方やアプローチが一杯あるよねと。同じ例題に対していろんな視点から取り組んでみることでより豊かな考え方が得られるかなと、じっくり時間かけてやってみました。去年まではここまではやってないのだよな。

プログラミング1は、if文、for文は触ってたので既にインデントやブロックの概念は教えていますが、その振り返りも兼ねて今回は「関数定義」な話。

単純な例を示しつつ、一連の命令群に名前をつけるて定義すること。定義した関数の使い方。戻り値が必要な場合と不要な場合。スライドでは「ここからここまでが関数定義の範囲」「ここがTrueブロック」とか示してたので、それがない状態でブロックを自分で把握するという話。2次方程式の解の公式を実装させてみる練習（短い時間だったけど数人実装できてた）。とかとか。

毎年微妙にやる順序が変わってるのだけど、これまでと比べるといい感じに進められてるのかも。