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

先日書いたように最終課題は自由課題でした。その自由課題を含めて全体の採点が終わり、個々のコメントも付け終えたのですが、それだけで終わると学生にも私にも勿体無いなということで「最終課題を終えた総論」をまとめてみました。

[ レポート7総論 ]

アドバイスを「Gradle, ユニットテスト, 実装, ドキュメント」の4種に分けてみました。ここに書いてることを一通り対応できるなら、余裕で100点満点あげちゃいます。2年次〜3年次の頃には「実装の発展的話題 case 4（hard coding）、case 6（実装とコンテンツの混在）」をどうにかできて、卒業までには case 5 の線引みたいなところまでやれると良いのかな。

ただしこれは一つの目安に過ぎなくて、例えば今時なら「webサービスとも連携するモバイルアプリ」ぐらいは作ってみて欲しい気もするし、「組み込みデバイス上で動作するアプリ」、「機械学習などの大規模計算」とかいろんな行き先があることを踏まえたコアとしての授業が[ プログラミング1 | プログラミング2 ]です。1年間通して達成目標を達成できるようになってるかは一つの基準ですが、「その先へ活用するためのコア」という意味で来年以降の活躍にも期待しています（ニッコリ）。

シリコンバレーのエンジニアが語る、誰にも悪気はなかった話というのを昼頃に見かけて、昼食休み時間だけでも足りないボリュームでしたが面白くて最後まで読んじゃいました。

「誰にも悪気はなかった」というのは、ステークホルダー各々が同じ問題を抱えてるように見えても、それをどう認知しているか、どう解決しようとしているかは千差万別だという話です。この視点はデザインスクールでフィールドワークを重視している理由の一つでもあります。所謂「工学部における学問」ではモデルとして抽象化し、それをどう解決するかを考えることに重きが強いことが少なくないですが、モデル化することで削ぎ落ちた部分が重要でないかどうかは「立ち位置」によって変わります。直面してる問題の解決をしているつもりであってもそのことを忘れがち。全ての想いに応えることはできないかもしれませんが、問題の背景を掘り出し、どんな人達がどのように関わってるかを見聞きすることで初めて見えてくるモノが「実社会」にはあります。

そういうことについて話し合うことがデザインスクール内でやるワークショップですが、一方でそれだけだと「話してるだけ」にすぎなくって。これに対するザッカーバーグというかFacebook社訓として紹介されてる「DONE IS BETTER THAN PERFECT」で、完璧を目指すのではなく、まず実際に手足を動かして終わらせろと。終わらせてその結果を検証して次に活かせと。いわゆる「成功者」であってもその裏には大量の失敗があるわけで。「愚者だけが自分の経験から学ぶと信じている。私はむしろ、最初から自分の誤りを避けるため、他人の経験から学ぶのを好む。」といった格言もあったりしますが、いずれにしてもやらないよりはやった方がいいし、やったからにはその結果を次に活かすことを考えよう。「それともお前 何十年も修行して達人にでもなるのを待ってから戦場に出るつもりか？気の投げぇ話だな」というコメントもあることだし。

先生に質問しない日本の大学生というのは「あるある」の一つだよね。私自身が学生だった頃は、結果的には先生を使い倒すつもりでやってました。あくまでも結果論で、そうしようと行動してたわけじゃないです。一般高校からの入学だったこともあってどれもこれも目新しくて楽しくて。PC触るのほぼ初めてで楽しくて。Hello World! 出力するだけで感動して。割とほとんどの専門科目で質問してたんじゃなかろうか。ただし、授業中ではあまり質問しなかったかもしれない。教科書や参考書を読み漁って、考えてもわからない所があれば質問するというのを繰り返してました。

どんな形であれ「質問せずに放置する学生」については、授業料もったいないな、面白く無いのかなと思う一方。教員になった以上、質問したくてたまらない授業づくりも同じぐらい大切だと思うのですよ。プログラミング1ではレポート＆ペアプロぐらいしか機能してない気がするので、まだまだ努力（練具合）不足。面白い課題作れてないという解釈のほうが理解しやすいのだけど、応用ではないので基本だから「やればできる」レベルの間はそもそも質問しようがない、という側面もある？

学び方という点では、どの教科でも「教科書を隈なく100%理解できるまで繰り返す」ことがやれるか否かだと思ってるので、如何にそう仕向けるかが肝だよね。輪読ゼミで「○○ってどういう意味？」みたいな質問するのもその一環。如何に「なんとなく」で読み飛ばさせないかという工夫が必要で、その工夫の中身は「やりたくなる」仕掛けがあるとベター。アフターケアだけじゃなく、事前準備にも工夫が仕組まれてると更に良い。言葉だけの能動学習とか言ってないで、そう仕向ける工夫が必要。


難しいのだけど、学生がやらないのを嘆くだけじゃなく、教員側がやれる努力はやろうよ、と。

6週のうち1回は90分丸々演習（ペアプロ）の予定なので、実質的には新しい話をできるのは5週分だけらしい。

授業の達成目標を眺めると、、、

• 目標1番目は、ペアプロ＋レポートで対応中。
• 目標2番目は、File I/Oを除いてレポート3で終える予定。File I/Oの方はこれから演習かレポートに盛り込む必要あり。
• 目標3番目は、クラスを除外する形になりそうな予感。モジュールと関数自体はこれまでにもやってて、同じくレポート3で一段落予定。ファイル名とモジュール名を区別できてない学生まだ多いけど。
• 目標4番目は、ミニテスト＋ペアプロ＋レポート諸々で対応中。
• 目標5番目はレポート2で一度はやってみたのと、先日のPyCharm+デバッガで抑えてみているつもりです。ちょっと足りないとは思うので、今後のレポート課題に組み込みたいけどどうしよっかなー。
• 目標6番目は、部品提供＋αに留まってるレベル。現状最も足りてない部分。
• 目標7番目は、変数名や関数名等の命名規則は当初から何度か盛り込んでるし、ドキュメンテーションとユニットテストはレポート2で対応済み。

という状況で、予定していた達成目標からは6番目が一番足りてないかな。

後半戦が始まってるということで、残りの週（6回+期末テストの週）でやりたいことを列挙＆優先順位を付けてみるとこんな感じかしら。

1. データ構造: list, dict, setの利用
2. 関数設計の考え方（話すだけ？デモ？演習？それ以外？）。前述の達成目標6番目。
3. バージョン管理: gitかなぁ（悩）
4. numpy
5. matplotlib
6. wxPythonか何かGUIツールキット
7. その他有用なモジュール: math, pandasとか
8. エラーと例外、アサーション
9. 余裕があれば: クラス導入
10. 余裕があれば: C言語イントロ。

1番目の「データ構造（list, dict, set）」で2週かかりそう。使えるように、というよりは「こういう構造がある（教科書とにらめっこしながら読み書きできる）」で十分なので、サラッと流すだけで良いかもしれないけど。レポート3の先生役する時間も必要なので、恐らく10回目(6/30)と11回目(7/4)はこれかな。この2週は演習時間取れるか怪しいので、12回目(7/7)は丸々演習の日にする予定。この予定で進めると、ここまでで残り3週に。（この間に File I/O and/or データ構造なレポート課題4出したいかも）

2番目の「関数設計の考え方」は、paizaのスキルチェックやAtCoderみたいな課題（最初の入力と、最後の出力だけを指定した課題）が出された時に「どんな関数を作るか」というお話。関数1つじゃ済まない（済ませたくない）ぐらいの問題を用意して、関数入出力設計*2,3個してその組み合わせで問題解決するという、設計自体に焦点を当てたい。これで少なくとも1週は潰れる予定で、この順で進めるなら13回目(7/14)が終わり。ここまでで残り2週に。

3番目以降は仮に順番付けてみたけどどれも同じぐらいの優先順位かな。この時期には線形代数の基本が終わりかけらしい。ベクトル・行列演算ということでNumpyをどこかで触らせてあげたい。軽くコード例示したりデモやるぐらいなら、授業1回分も使わないけど、どこまでやるか次第だな。Matplotlibと合わせて入門編1回ぐらいか？　その予定なら、14回目(7/21)が終了。（ここで最後のレポート5回目？）

15回目(7/28)にバージョン管理かしら。後期に回すという手もあるけど、一度話をしておいた方が良い気もするし。

16回目(8/4)はテスト期間。プログラミング1ではテスト無しなので、レポート等相談対応の時間に使うつもり。

んー、こうしてみるとペアプロに使える時間が足りてないかも。ソフトウェア演習1の山田先生と相談してみよう。

1年次のうちにC言語も少し触る予定だったけど、前期の最後にちょろっとやって後期に忘れてしまうぐらいなら、後期で触ったほうが良いか。

1年次のレポートということもあって、レポートの書き方を含めた細かいフィードバックをしたいなと。でも教員で全部やるのは辛いなと。1度目のレポートはやったんですが、そのままだと辛いので誰か採点TAやりませんか。という話を大分前にやったのですが、それに対してやりたいという声が上がってくれて、先週締切のあったレポート2の採点からお願いできることになりました。

解答例と大まかな基準を用意してお願いした結果、TAスコアと教員スコアとでは平均点の違いを除くと傾向的にはほぼ同じ（相関係数0.98強）ということで、院生でもレポートの良し悪しは気づいてくれる訳で、安心しました。今回私の方はざっくりと眺めるだけにしたのですが、それでもおおよその結果は良いらしい。一方で見逃してた点に気づけたので、細かいところをTAにお願いするのは正しいらしい。

ということで、フィードバックを活かして下さい〜＞受講生の皆さん

（まだフィードバック公開はしてないけど）

8回目は、やり忘れてたFile I/Oに、新しいデータ型 Tuples、そしてツール紹介として Jupyter Notebook を触ってみました。

今日が締切のレポート2は、未提出が1割強。難しいとは思うのだけど、教科書や授業でやった内容ではあるのだよな。そういう意味では「(a)問題の意図を理解していないか、(b)取り組み方が想像できない」のどちらかで詰まってるようです。

(a)は私の問題（設問文の質の問題）であるケースと、書いてるけど読み飛ばしてるケースに分かれてて、後者のケースも少なくなくて。最初は文章の問題が主要因かとも思ってたんですが、そうじゃなくて読んでなかったり、もしくは読んでるだけで咀嚼されてなかったりというケース。具体例を出すと、授業中に何度も「int型オブジェクト」という表現を多用していますが、個別に対応してるとこれが通じない学生がいたりするという。もう8週目なんだけど、まだ共通の辞書が作れてないらしい。いや、「オブジェクトって何？」とかいう話もありそうなんだけど、int や integer でも通じないので、テキスト・授業を理解できてないのだなぁと。身に染みます。

(b)は、この授業の中で達成させたい目標の一つ。「次の一歩が分かる」ように、問題分割して取り組む方法をデモしたり、過程を言葉や文章で表現させたり、リファレンス参照させたりといったことをさせてみてます。まだまだな学生が多いかもですが、一方で頑張ってる学生もいて。元から素養があった、という話だと悲しいですがw　それだとしてもそういう思考方法を共有させるためにペアプロを標準導入してる訳で。

ということで、中間地点を過ぎましたが、前途多難だなーという話でした。

1年次後期に使うJava本探しにジュンク堂であれこれ探してみました。那覇店にも洋書の専門書があったような気がしたけど、今はもうなさ気か。ということで今回は和書のみのチェック。隣の棚にAndroid本もあって「そっちでJava＆オブジェクト指向導入するのもありか？」と数冊眺めてみましたが、やっぱりなしだな。達成目標に対して回り道過ぎるので。

オライリー棚とか一部にJava関連がある棚含めて4つぐらい棚をチェックしたところ、大雑把に分けると次のようなタイプに別れるのかな。跨ってるのもあるとして。

• (1)Java言語解説書（言語仕様解説書）
• (2)特定機能についての解説本
• (3)取り敢えずコード書けることを目指したチュートリアル本
• (4)オブジェクト指向開発解説等、設計中心本
• (5)デザパタ本
• (6)リファレンスやクックブック的な本
• (7)周辺知識本

「1冊だけ」という縛りを入れると授業で扱いたいこと（オブジェクト指向プログラミング解説＋Java8＋コード多め）を一通り触れてるものは無さそう。普通はそうだよね。今やってるPython本もそれ踏まえて足りないところは補う形で使ってるし。何を補うかという点からは、年々updateされる言語最新事情についてはひとまず置いておく（補足対応する）というのがベターかしら。

「Java言語仕様ついては基本を抑えるぐらい、オブジェクト指向プログラミング解説とコード例多め」を基準とすると、眺めた書籍の中での候補はこんな感じ。良さそうな順。

• スッキリわかるJava入門 第2版 (2014)
• 新わかりやすいJava入門編 (2015)
• 新・これならわかる Java (2008)
• 理工系のJavaプログラミングテキスト (2004)

帯に「完全独習テキスト」と書いてるだけあって予習復習に向いてそうなのは「新わかりやすいJava入門編」。一方で楽しんでやれそうなのは「スッキリわかるJava入門 第2版」かな。特に「スッキリ」の方はスタックトレースの読み方、エラーメッセージ一覧、構文リファレンスとか痒いところも整理してくれてるのは良さそう。ただし全体的に「対話やり取り」での説明が多く、ぱっと見でどこにに何書いてるかが分かりにくそうなところが難点に感じます。最初から一通り通すだけならそれで良いんだけど、復習するのが辛そう。（復習考えると前者のほうが良さそう）

あと、Java言語プログラミングレッスン第3版が、まだノーチェックで気になる。

少し違うアプローチとして、UMLを交えて設計中心で話が進む「UML&Javaオブジェクト指向開発」も、選択子としては捨てがたい。別の講義で、モデリングと設計があるからそっちに任せるので良いとは思うんだけど。

名前だけ聞いたことがあった「EFFECTIVE JAVA 第2版」はどうかと思ったんですが、これは一度Javaを勉強した後で参考にするノウハウ集なのね。

そろそろ後期の授業・プログラミング2の教科書選定するかということで、今週末にでもジュンク堂に行こうかと。オススメありますか？＞先輩の皆さん

ちなみに私自身は Java 歴ほぼ0に近いです（ぉぃ）。学生の頃、Javaが出初めの頃にApplication, Applet作って遊んだぐらいか。Application はほぼC言語丸写しでどこにJavaらしさがあるんだ、というソースになってたはずですがw

そんな訳でJava大先輩からのオススメがあればWelcomeです。

去年までは山田先生が担当してて、最後の年は「本格学習Java入門 [改訂新版]」を指定してたらしい。これが良さげなら踏襲するのもありだよね。2011年なので結構古いのだけど、受講済み学生（現2年次）としてはどんな塩梅でしたか？

目次を眺める限りでは基本を抑えつつ、いくつか応用編を組み込んでるらしい。古いだけあって例えば（必要かは置いといて）GenericsやAnnotationあたりの話は書かれてないのかな。一方で、足りない分はオフィシャルドキュメントで補うという形もありそうではあるか。

＜対象学生の背景＞

• 対象は1年次。
• 前期にPython3（留年してる学生はC言語）でのプログラミング経験はあるので、一般的な構造化プログラミングぐらいの知識は既に勉強済み。
• 一方でPythonしかやってないと「コンパイラ」の存在を知らない。

＜教えたい知識の候補＞
上記を踏まえると、、、コンパイラ、JavaVM、オブジェクト指向、クラス（軽い話はPythonでもやる予定）、継承、Absract/Interface、Annotation、Generics、といったJava話をメインにする方が良いのかしら。

教科書は置いといて、去年の時点で考えた授業計画叩き台的には次のようになってます。

第1回: プログラミング1の振り返り，インタプリタ言語とコンパイラ言語，静的な型付け，環境構築，実行
第2回: Javaの基本知識（変数と定数，演算子，型変換，配列，制御文）
第3回: コメントとコーディング規約
第4回: バージョン管理，pull request と merge，diff
第5回: ユニットテストとjarの利用
第6回: Gradleによる構成管理
第7回: 振り返り1（プログラムの実行，バージョン管理，ユニットテスト，コード読解）
第8回: オブジェクト指向1: クラスとインスタンス，コンストラクタ
第9回: オブジェクト指向2: 関数 vs. メソッド，処理と情報の隠蔽(カプセル化)，継承
第10回: オブジェクト指向3: 多重定義(Overload)
第11回: オブジェクト指向4: 多態性(polymorphism)とオーバーライド，アノテーション
第12回: 抽象クラス(Abstract)，インターフェース(Interface)と多重継承
第13回: 例外と例外処理
第14回: Java: クラスライブラリ
第15回: 振り返り2（実践的なプログラミング，継承，隠蔽，オーバーロード，オーバーライド，多態性）

この流れでやれるかどうかはさておき、これがJavaらしい中身になってるかの判断がつかないぐらいには、Javaのことよく分かってないんだよな。

GW直前に初めてのレポート課題を出したのですが、友人・先輩・教職員らへの相談含めて頑張ったようです。（GWめちゃくちゃ頑張りましたという報告ありw）

毎週やってるミニテストは趣向を変えて、（他の科目はともかくプログラミング1では）初めてのレポートということもあるので「他の人はどう書いてるだろう？」をやる時間に使いました。自分の学籍番号付近のレポート4件眺めて貰ってそこから良レポートをセレクト。それを隣の人と良さを説明しあってベストレポート1本を互いに検討し、投票。結果としてはダントツで票をゲットした学生が1名、3,4名から投票ゲットした学生が9名、それ以外にも1,2票ゲットした学生が20名弱でました。

投票するだけではなく理由も記入してもらったところ、

• エラーについて詳しく調べられていた．また，web検索で色々な関数を調べて使っていた．
• 整数以外を入力した際に整数を入力するように促すようにするなど私には思いつかなかった気遣いがあって優れていると感じたため。
• 実行コードや結果などを四角で囲っていたのがとても見やすかったです。
• 失敗例を漏らさず書いており、正解へのアプローチの過程がしっかりできていると思う。ファイル形式をPDFなど簡単に見られるようにしてほしかった。
• しっかり図も踏まえて説明していて、しっかり分析できているから。さらに、より良い、方法を試そうと試みが現れてるなあと思いました。

等、多数のコメントが寄せられました。提出されたレポートはいつでも閲覧できるようにもしてあるので、次回からは良い所を真似て書いてくれることを期待します（ニッコリ）。

一方で、取り組み方への相談も少なくなく。初めてのことなので当たり前なんですが、これをどうにかしたいなということでスライドp.13のような抽象的な話をしつつ、これに基づいて実演しました。課題を読みながら「まずはこの部分について取り組んでみるか」「ここを分割するとこうなるかな」「これなら余り使えばできるな」みたいに考えてることを喋る＆テキストに残しつつ、それにもとづいて書いたコードとその結果をそのテキストにコピペ。こうして「プログラミングのプロセスを残そう」という話を最後まで。所々でTips加えて「ヒストリを使おう」「置換しよう」「インデント対応してるエディタだとこういうことできるよ」「Markdownってのがあってね」等など。その結果がこんな感じに。最後らへんはテキスト化端折ってるところもありますが、「後でレポートにまとめる」のではなく、「取り組んでる最中から記録に残すことでプロセスが見れるようにしよう」と。取り組み方やレポートの書き方にどれだけ心響く形になったか分かりませんが、大分噛み砕いて実演してみたつもりです。

次回からのレポートがどれだけ質向上するか分かりませんが、相互レポートチェックと実演とで課題・レポートへの取り組み方が何となく分かってくれてたら嬉しいのですが。

P.S.
今はインタプリタ＋エディタという形で進めてますが、後でJupyter Notebookも導入してみるつもりです。コピペする必要もなくなると思うので。

プログラミング1の担当をすることになってから、「学生の頃こうだったなー」というのをよく思い出してます。当時は「自分のパソコン」とかそんなもの無かったので、基本的には学内で課題。これは「皆とやる」とかそういう要因ではなくて、環境制限のため。そういう環境だったので今の学生よりも触れる時間は短かったはずですが、逆にPCルームという形で何やるにしても集中しやすかったからか、課題はちょちょいで済まして比較的「お遊びしてる」時間もあったと思います。そこの境界ははっきりしないのだけれど、やってる本人的にはかなり遊んでました。

「printf(“Hello world!¥n”;)」でも楽しかったし、そもそもタイプするだけでも楽しかった。コンピュータに触れてる感があって。そういう意味ではやっぱり「24時間自由に触れなかった」という制約がハングリー精神に繋がったという側面はあったのかも。

if文やループを覚えてからはミニゲーム作成に精が出て。
関数を覚えてからは main() 関数から何か一つ関数コールして終了するみたいなことしたり。
ポインタは何がなんだか分からないままだった気がしますが、アドレス見て「あ、メモリってこういうことか」と感動したり。
デバッガで処理途中の状態確認できるの見て震えたり。

そんなこんなで道具を少しずつ増やしていく都度あれこれ遊んでました。今の私がやってる授業でももっと遊んで欲しいという気持ちはありますが、今はまだそこまで余裕が無い学生が多いかなー。演習含めてあれこれ詰め込みすぎかしら？　でも一人でやるのと、ペアでやるのとではまた違う勉強になるからなぁ。ということで今回は演習課題あれこれ作りまくっております。