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

昨日から始まってる研究室紹介で、進学を勧めてる先生が多いらしい。

目に見えて分かりやすいメリットは、学士より修士の方が給与が高いので中長期的にはそっちの方がお得。

間接的には、しっかりとした力を身につけるためには学部4年間だけでは厳しくて、修論書けるぐらいには何か一つのことに集中して掘り下げて考え、俯瞰した視点を持って、体系的に取り組むことを通して得られるノウハウに価値があるかな。

ソフトウェアエンジニア、セキュリティエンジニアなり、言われたことをするだけで済ませるなら高卒・専門高校卒ぐらいでも何とかなります。この場合は時代の変化とともに現れる新しい社会（技術も含む）への対応のため、その都度お金を払って学ぶことになることが多いでしょう。自身で探求するという行為をほとんどしていないのだから。

これに対して学士や修士ならこういう力を求めています。そういう力が身につくことを期待しているし、中長期的な計画という視点でどう動くかを節々で指導しているつもりです。

卒業研究1回だけで修士レベルの力を身につけることは難しいし、だからこそ勧めたい気持ちはあるかな。だけど、個人的には「やりたいテーマがないならまずは就職してみたら？」という立場です。こちらが提示したテーマをやるでも十分なんですが、提示してもやらないのなら修了できないし、学費も時間も勿体ないよね。仕事してから社会人枠で入ってきても良いし、共同研究的なやり方もあるだろうし、いろんな道がありますよ。

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

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

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

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

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

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

みたいな演習。

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

3年次の学生実験は、教員一人あたり数人〜10数人程度での実施になることが殆どなので、その分細かい指導がしやすくて。データマイニング班前半はこんな感じで、授業寄りの基礎演習をやってて、後半はグループ単位での開発実習をやらせてます。

これも単に「やってて疑問に思う所あったら聞いてね」とか、「たまに見て回る」ではなく、進捗確認を兼ねた作業レビューをしています。ここでいう作業レビューとはペアプロとかモブプロに近いもので、大型モニタに接続して貰った状態で、内容確認しながら作業してもらい、その様子を見て気になる点へアドバイスし、実際に一緒に問題発見してみたり、修正してみたり、場合によってはググり方とか考え方を提示するに留めて考えさせてみたり、といったことをやっています。

ここ数年でよく見る宜しくないパターン（＝Jupyter広まってから増えてるパターン）は、

• デバッガを使うことを意識していないケースが少なくないこと。
• Jupyterで書いて、後でライブラリとして使うように整理し直すことをしないこと。（毎回そこからコピペでその後も作業しがち）
• Numpy/OpenCV/TensorFlowとか便利なライブラリ使いつつ、ドキュメント参照しないこと。（怪しい解説記事を鵜呑みにしがち）

かな。関数の戻り値が何なのか分からないまま、に使ってるとかありがち。

printデバッグが多いとか、ググる際のキーワードの不適切さ（バズワードだけで検索するとか）は昔からか。

そういうのも含めて、実際に目の前で見ながら指摘してあげることができる時間ですね。プログラミングに限らず、こういう「実際の過程」に対するレビューというのは、一子相伝じゃないですが、それなりに価値があることだと考えているので、やめるつもりはありません。

私の指摘事項が古くなるという側面はありますが、、（遠い目）

卵が先か鶏が先かみたいな話でもあるし、教え方学び方に正解があるわけでもないですが、分からなくなった時に例示は理解の試金石する（手を動かす）のは大きくて。

良く分からない数式が出てきた。
良く分からないコードが出てきた。
良く分からない定義が出てきた。
エトセトラエトセトラ。

何にでも小さな例から始めて、実際に手を動かしてみないと「腑に落ちる」というのは難しい。私も時間の都合でやっちゃうことありますが、「イメージとしてやってることを伝える」のは、あくまでもイメージであってそれ以上ではない。わかりやすそうに書いてる教科書は、取っ掛かりとしては一つの選択肢だけれども、そこで手を動かすことを省略してしまうと、ふわっとしたまますぐ消えてしまう。

先週来てた留学生は、たまたまかもしれませんが数学（偏微分、重積分、行列あたり）の知識はしっかりしてて、たかだか数回のレクチャーで機械学習入門ぐらいを理解（自分で説明できる）できました。別に見たケースだと、プログラミング全く触ったこと無いけれども数学しっかりしてきたある学生は、そこから「プログラミングを学ぶ力」がとても高くて、驚くほど速くレベルアップしてく様子を目の当たりにしたことがあります。

そういう意味で、何か具体的にやりたいことがある訳ではない学生へは数学英語に加えて論理的に読み書きする力という意味での国語をしっかりやろうと伝えてますが、目標がないままだと持続しないことも多くて。持続できる人はそれ自体がレアスキルという説もあるか。

面白そうな課題なり用意してみるけれども、それだけで終わってしまうと「そういうものだ」で理解が留まってしまうので、どしどし手を動かしてほしいのだよな。

（課題間の繋がりや、科目間の繋がりでもっと連携とって積み上がる形に設計しろよという話でもある）

何にでも理由がある。という訳でもなく「ひとまず」でやられてるものもありますが、ここでは教科書とか何かしら体系化された（されている、されつつある）事象について。

そういうものには何かしら体系化した人らの狙いが詰まっているし、教科書ならば何かしらの説明が加えられている。輪読形式のゼミで学ぶ場合、主に発表者が事前に解読して説明するための用意をして当日を迎えるけれども、勿論発表者が完全に理解してるとは限らないし、説明が正しいとも限らない。

「なにか質問やコメントは？」

と促してもなかなか出てこないのは勿体無いなと思うので、私の方から発表者に逆質問したり、ただ聞いてるだけの学生らに質問したり。

「ここは何故こうやるのだろう？」
「どういうメリット、デメリットがありそう？」
「同じ目的を達成するための他手段は何が考えられる？」
「より効果的な実現方法はないだろうか？」

多分、恐らく、数回程度繰り返したところで大した効果はなくて。もっと集中して時間かけるなり、そうでなくても継続的に何度も何度も繰り返さないと「あ、物事を考えるというのはこういうことか」みたいな所までにはいかない。そもそも「疑問を持つ」というのは「興味を持っている」ことが前提みたいなところがあるし、興味持っていようが「疑問を持つ」とは限らないので卵が先か鶏が先かみたいな話になりがちなんだけど。

考え方なり疑問の建て方なり、そういうレベルにまで達するのは各研究室のゼミなりでやって貰えれば良いのだろうとは思うけれども、もう少しうまいやり方が無いのかなとも思うわけで。ま、少しずつあれこれ試してみます。

プログラミング周りの実践演習向けに勉強しようということで、TDD+モブプログラミングでワイワイする会 その20に少しだけ覗いてきました。実際に見てきたのは冒頭1時間と後半20分ぐらい。

モブプログラミングそのものについてはMob Programming Startup Manualか、TDDワイワイ会inXP祭り2018あたりを眺めると、全体像が掴みやすいです。

ざっくりと手順をまとめると、こんな流れ。

・モブプロの時間（開始〜終了時間）を決める。
・cyber-dojoなり、実行環境を用意する。
　＊cyber-dojoは言語＆問題別にコード＆テスト例も用意されてて便利。
・モブ（グループ）を決める。
・開発言語と仕事（開発対象）を決める。
・ドライバー1人とそれ以外のナビゲーター、交代タイミングを決める。
・ToDoリストで「開発し終えるための全タスク」を管理しつつ、テスト駆動開発で「今やること」に集中する。
・まずテストを書き（red）、それを通すコードを目指し（green）、その後でリファクタリング（green）を目指すのが理想。ただし理想であって、TPO考慮。
・考えてることは一通り言葉にする努力を。「わからない」と表明するのも貢献の一つ。
・何か達成したら喜ぶ。
・モブプロ時間を終えたら感想等を通した振り返り。できればここで十分に時間取って形式知化できると良さそう。

覗いてみて気づいた＆感じた点は、、

• TDD x ToDoリスト x ペアプロみたいに、TDD x ToDoリストを組み合わせることで、単に「複数人でやれ」よりも、過程を可視化しやすそう＝体験や学びを促進しやすそう。
• テスト駆動を教える場合、最初から「とりあえず動くコード＆テスト」を用意してやるととっつきやすそう。
• テスト駆動だからこそ「どういう風に作り込もうとするか（≒設計過程）」を見せやすいかも。設計と実装を明示的に区別できるのが良い？　一方で、本当のプログラミング初学者からすると、「テスト」や「関数」とかの概念自体がわからないので、対象言語について1〜数時間のチュートリアルしてから、TDDxモブプロし始めるぐらいが良い？
• 1仕事終えるまで1モブで固定した方が良さそう。途中でモブ間のメンバ入れ替え発生すると、そこに辿り着くまでの流れを把握していないメンバが発生し、それを解消する情報共有コストが大きすぎるという意味で。
• 研究室でやるのも良さそうなんだけど、その場合は「今回はAさんのタスク」とか、タスク単位でモブるのが良いのかな。似たような取り組みを試験的に導入したことはあるけど、ゼミ外でやったからか定着しなかなかったので、ゼミ時間なりある程度強制的に集合する時間でやった方が良さそう。論文書けとかでも一緒で、初めてのタスクを一度皆でやるというのをやってみるかなぁ。

TA指導含めて、授業にも取り入れられると面白そうです。TA人数やスペース、環境とか工夫しないと現実的じゃないのが辛いところですが。

デザインスクール記事の話。

α版からβ版へということで進んでやつの原稿〆切が今月末に決まりました。それに向けてアクティブラーニングやサービスラーニングといった方面についての知識を深めながら仕上げています。

「デザインスクールの記事」という話の発端は、元々は「ワークショップやったぞイベント報告記事」ぐらいのもので、素直にやってきたことを素材として書きまくってました。が、どこに掲載するかという話からいくつか打診もしつつ調整した結果、単なる報告記事では駄目で、大学教育の一例としてより俯瞰した話や、逆に具体的に工夫した側面といった話を整理して云々という話になり。気がつけば前述したアクティブラーニングやサービスラーニングについての事例勉強しつつ記事としてまとめるという流れに落ち付きつつあります。

どちらもこれまで真面目に調査してなくて、表面的にケーススタディを見たことがある程度で。特にサービスラーニングについては今回始めて聞く単語で、石田先生からあれこれ情報提供頂くことに。ありがとうございます。

アクティブ・ラーニングについては、最初に読みたいアクティブラーニングの本がオススメ！　元々のactive learningという主張が出始めた原点から始まり、1990年代頃までの事例を踏まえた知見が整理された上で、現代ならではの話も追記されています。サーベイ論文的なものならアクティブ・ラーニング導入の実践的課題あたりらしい。

サービスラーニングについては、サマリ的なものならReflection in Service Learning: Making Meaning or Experience、サーベイ論文的なものならReflection: Linking Service and Learning—Linking Students and Communitiesが良いのかも。文科省的には用語集のように定義しているらしい。

「どう評価するか？」という点についてはやっぱり謎のままというか効果的な方法はまだなさそうなんだけど、「どう工夫するか？」という点では知見が散りばめられてて、あぁ、やっぱり論文として書くのは重要なんだなと改めて実感した次第。皆も論文書こう。

colaboratoryでペアプロすることもできそう（問題はあるにせよ）ということとは別に、レポート課題として提出させる際の問題点はあるかなという点で考えてみると、、、

[ 現時点ではGoogleドキュメントでレポート作成＆Googleドライブ提出させている ]

このメリットは思ってた以上に大きくて、
(1)赤ペン先生しやすいし、コメントでメール自動送付してくれるのは楽。
(2)学生側もどこに対するコメントなのか把握しやすい。

この2つの合わせ技で、学生側はそのメール内のリンクをクリックするだけで(2)の状態になり、チャットやり取りのようにみえるからか敷居を感じない学生が少なくないようで、指摘したコメントに対する改善をしてくるケースが増えています。具体的なリンクなしのメールコメントは昔からやってるんですが、具体的にそこまでやってくるのは少なかった。その意味では、GoogleドキュメントのコメントUIを含めた形が指導に向いてるように感じます。

これを「colaboratory/jupyterでipynb形式でレポート代わりに作成＆提出」という形にしたらどうなるか。

現時点ではGoogleドキュメント並みのコメントUIがないので、コメントしづらいし、学生側も改善にまで動こうとするかは怪しいかなという気がします。妄想なんですが。目的が違うよねということは理解できるんですが、JupyterLabでもその辺りの機能は無さげな気がする（多分）。

GitHub x Issue あたりで似たようなことできなくも無さそうですが、うーん。

Jupyter Notebook環境を仮想マシン上で実行してくれるColaboratoryを今更ながら試してみました。環境構築せずにすぐにお試しできるというのは初学者には嬉しいでしょう。それとは別に、授業でペアプロすることがあるのでそこで使えないかなという確認を兼ねてお試し。

[ 1. 教員側でノートを用意する ]

• ColaboratoryなりJupyterなりでipynb形式で作成。
• googleドライブで共有する場合、これまでのファイル共有とやり方は一緒。（プログラミング1の場合、共有用ディレクトリを用意してあるのでそこにファイルを置けば良い）

この時点で、Colaboratoryからipynbファイルを指定して開くことは可能。しかし、共有先のGoogleドライブからは「開けないのでダウンロードする？」という状態に。同時に「アプリで開く（Open with）」でもColaboratoryを選択できず、直接編集できる状態では開けず。勿論、一度ダウンロードした上で自分のColaboratoryで参照できるスペースにアップロードしたら開けますが、これだと独立したファイルなので「同時同じファイルを編集する」みたいな使い方はできません。

[ 2. 必要かもしれない手順 ]

• 一度Colaboratoryにアクセス。それだけで閉じる。（ひょっとすると一度コード実行する必要あるかも）
• 改めて共有ドライブにアクセス。
• ipynbファイルを右クリック（Ctrl+クリック）し、「アプリで開く（Open with）」からColaboratoryを選択。

これでも直接開けない（アプリが選択できない）場合、暫く放置しておくと良いのかも。単に設定の問題ではなくて、各自のGoogleドライブ側からColaboratoryとの連携に多少の時間が必要なだけかもしれない。（放置してたら開けるようになってた）

[ 気になる点というか特徴 ]

• 一つのモニタを使う一般的なペアプロだと、遅延は発生しない。これに対してColaboratory共有だと、Googleドライブ共有分の遅延は発生する。「そこインデントおかしい」みたいなナビゲート側のアクションに遅延が発生することに。
• 以下は問題にならなそうな特徴。
• Colaboratory側で用意される仮想マシンは、一番最初の起動時には少し（数秒程度）時間がかかる。
• FAQによると仮想マシンはあるタイミング（最大存続期間 or 一定のアイドル状態）で殺されるっぽい。実際暫く放置しておくと「接続が切れて、再接続を促される」状態になりますが、ワンクリックで繋げ直せます。

前述のように Colaboratory でペアプロできるのだとすると、、

• 去年までのペアプロ: 問題を問題ページに用意して、ローカル上でコード書いて実行し、うまくいったらそのコードと結果をドキュメントに貼り付ける。個々人でノートPC持ってるため、ドライバが入れ替わるとそれまでの履歴をナビゲータが引き継ぐ際の手間がかかる。
• Colaboratory上でのペアプロ: コードや実行結果を貼り付ける必要は無い（これはJupyterの利点）。ファイル共有された中で実行できる（Colaboratoryの利点）ので、スムーズに引き継ぎできる。

みたいになるのかな。

ただ、「一つのモニタで作業をやる」ことにも意義があると感じている人なので、少しその点が気がかりではあります。ノートPCだと見づらいんですけどね。

[4/11, 15:45追記]

手順2の「必要かもしれない手順」は、以下のようにするのが本筋っぽい。

[ 2. 本手順（Colaboratoryとの連携設定） ]

• 共有ドライブをブラウザで開く。
• ipynbファイルを置いてるフォルダを開く。（既に開いてるなら次へ）
• フォルダメニューをクリックし、「アプリで開く（Open with）」から「アプリを追加（connect more apps）」を選択。
• 検索窓に「Colaboratory」と入力して検索。Colaboratoryをクリックして追加。（「connected」になればOK。）
• ☓ボタンをクリックして設定終了。
• ipynbファイルをダブルクリック。開く際に「ダウンロードするか、Colaboratoryで開くか」を選べるので、Colaboratoryを選択。

新入生PCとなるべく同じ環境にするため、今のタイミングでOSアップグレード。前回の10.11 -> 10.12のときには手こずった記憶が強いのですが、今回は割とスムーズにいったか。brew更新時に同じような問題出ましたが、既に対策わかってるので同じようにやるだけで解決（したはず）。

ただ、学科で用意してるie-developers/ie tap周りでdeprecatedが出てるな。2018年度はどうする予定なんだろう。

Warning: Calling ‘depends_on :python’ is deprecated!
Use ‘depends_on “python@2″‘ instead.
/usr/local/Homebrew/Library/Taps/ie-developers/homebrew-ie/mercurial.rb:17:in `’
Please report this to the ie-developers/ie tap!

今日は電気電子の金子先生の最終講義でした。人それぞれ違うし、学生はまだ学生なのだから想定外の問題を抱え込んでしまうこともある。それを確認するためにも「2週連続で欠席したらまずは連絡を取るメソッド」を布教＆実施してたのは、すごい。