授業グループウエアとしてのサイボウズLive

これまで授業での情報共有にはながらく(7年くらい)qwikWebを使っていたんだけど、去年の秋にサービス終了が告知されて今年からは別のものにしないといけなくなった。

ちょうどそれを考えていたころ参加した「wikiばな同窓会」という飲み会にて、ただただしさんとその話(qwikWeb終了)になり授業での情報共有に向いたサービスとかないもんですかねと水をむけたところ「サイボウズliveとかでいいんじゃないの」と提案され、しかにwikiとかでなくてもふつうのグループウエアでいいのかと思って今年は試しにサイボウズLiveを使ってみた。授業も終わったのでふりかえり。

授業の情報共有では

  • 受講者への積極的な通知(休講情報とかのわりと緊急に全員に伝えたいこと)
  • 毎週の授業の講義録や資料などの共有
  • 毎週のプログラム課題の提出

などをおもにするんだけど、資料の共有とか課題の提出はそんなに問題なかった。サイボウズLiveの掲示板はファイル添付とか添付されたファイルやURLのプレビュー機能がわりと充実しているのがなかなかよかった。ただやっぱコメント追記型の掲示板なので、コメントの再編集ができないので添付忘れとかがあってコメントが入り乱れてしまったり、提出された課題にあとから返信してもコメント同士が離れてしまうのでいまいち情報としてストックされていく感じにならないのは使いにくいなと思ったところ(いちおう機能としては掲示板のヘッダ部分にWikiのように継続的に情報をメンテンスしていけるような仕組みが用意されているんだけど、今回の使いかた的にはあまり役に立たなかった)。

意外と向いてなかったのがグループメンバー全員への積極的な通知の方法がないことで、qwikWebは基本的にMLなので連絡事項がちゃんとサブジェクトの付いたメールとして流れるのがよかったんだけど、サイボウズLiveでそれをしようとするとメンバー全員を参加されたチャットルームを作ってそこに連絡事項を投げるくらいしかないのかな? しかもそれの通知は新着情報のチャットの新着発言1つとしてメールなどで知らされるだけなので、あんまり緊急連絡にならない。アプリをインストールしていればプッシュ通知されるだろうけど、半期の週1の授業のためにあんまりアプリいれないよね。連絡がチャットメインというのはマシンが起動しているときは常ににタブが開いておくようなふつうの仕事で使うぶんにはいいんだけど、学生に週1の授業で使ってもらう(それ以外のタイミングではサービスがほぼ見られない)というユースケースだとあんまり有効じゃない感じだった。

というわけで、来年も引き続き使うかというとちょっとどうかなという感じだった。


フレームワーク化が必要

第14回で、前期最終課題の制作日。学生の出してきた企画を軌道修正しながら、プログラムの制作に入ってもらうんだけど、やっぱりプログラムをどこから手をつけるか、という問題分割の考えかたはうまく伝えられていないようで、最初から乱数を使うプログラムを作ろうとして悩みはじめたり、直近習ったプログラムの書きかた(ファイルを分けた複雑な関数の使いかたや、配列など)に縛られてしまっていたりした。うーむ。ちゃんと完成形のプログラムの前段階のプロトタイプを制作することを課題に盛り込んだり、ワークシートに書き出させたりするようなフレームワーク化をしたほうがよさそうなので来年度はそうしていきたい。


モチーフのバリエーションを生成するプログラムとそれによる写真集

前回休講してしまったけど、第13回。ほんとは前回から始めたかった前期の最後の課題のオリエンテーションと企画制作。最終課題はいろいろ思いを巡らしたのだけど結局授業開始以来続けている「モチーフのバリエーションを生成するプログラムを作り、そのプログラムで生まれたバリエーションを素材に写真集をつくる」という課題そのままにした。

「モチーフ」というのは椅子とか自転車とかマークとか、ある(物理的、機能的な)規則によって構成される形態をもったモノで、課題のために決めたモチーフについて調査してそのモチーフを構成する規則(椅子であれば足の本数の制約や足の長さ、座面の大きさ、背板のありなし、高さ、傾き、肘掛けのありなし…などなど)を抽象化してそれらをパラメータとしてランダムないしUIで調節可能にしてモチーフのバリエーションが生み出せるようなプログラムを制作する。このプログラムが提出物その1で、その2がこのプログラムで生み出せる(はず)のモチーフバリエーションを最低100パターンの画像などで書き出し、それを素材としてBCCKSで写真集をつくるというものにしている。現実世界のモチーフからルールを抽象化してプログラムの形で実装するというプログラミングに関する基礎技能に対するおさらいと、乱数的に生み出されるバリエーションで事故的にうまれる「作品」の面白さ、というコンピュータの使いかたに触れてもらうのと、プログラムは道具として制作してそこから生み出されたもので別の制作物をつくるという職業プログラマー以外の人がプログラム技術を活用するかたちの提案、というあたりがねらい。以前は提出物その2はポスターにしてたんだけど、せっかくなのでBCCKSで写真集をつくるというものにしている。

さて今年はどんなものができるか。


ゲーム開発駆動プログラム学習

授業第11回。前回の課題(ゲームっぽいものを作ってみる)の制作週。サンプルプログラムからとりあえず差し替えたプレイヤーや敵キャラの画像を確認して、これがゲームだとしてこの先どんな感じに発展していくものかを確認して、それに合わせてプログラムの拡張の方向性やステップをアドバイスしてプログラムを進めてもらった。ゲームはそのプログラムのなかでの論理性(どのタイミングで何が起きないといけないかとか、フラグの管理とか)がイメージしてもらいやすいのとプログラムに機能を付け加えていくためのステップを作りやすいのである程度以降の段階でプログラムを実践的に作る課題としては向いている気がするな。とはいえ「ゲームとかぜんぜんやらないのでいまいちなにをしたものか…」みたいな学生もいるからむずかしいけど。


ゲームっぽいものを作る

授業第10回。これまで学んできたプログラムの要素をフル活用してつくられるものとしての「ゲームのようなもの」(複数のキャラクターが画面上を動いたり、プログラム全体が状態管理されて複数のシーンが順序立てて進行したり、フラグによってルールが運営されたりするもの)がどんな感じのプログラムで実現されるかと、ゲームっぽいものを作るための機能としての配列の解説をした。課題は自分なりの「ゲームっぽいもの」の制作。

今回から画像を読み込んでキャラクターとして表示させる方法も軽く説明したら、みんなどんどん画像検索して脈絡のないもの画像の背景を抜いてキャラクターとして動かすのに熱中し始めた。そうだよなーそれらしい画像を出してカーソルで動かせるとそれだけでも「自分が作ったもの」な感じになるからなー。ちゃんとそのモチベーションでルールの部分のプログラミングのほうでもこだわりを見せてくれるといけど。


添削したコードを共有するサービス

第8回。前回授業の課題(グラフィックツール的なものを作る)の制作実習の日だけど、その前の課題(パターン模写)の提出を確認してプログラムを添削してフィードバックを返したりした。

テキストを公開したりコードを共有するようなサービスっていろいろあるから、元のコードと添削後のコードを並べて差分表示できるようないかしたコードシェアサービスがきっとあるんだろうと思って調べていたんだけどあまり見つからなかった。まあgithubのdiffのスプリットビューでいいだろとも思ったんだけど(processingnのシンタックスハイライトもあるし)、githubのスプリットビューはコードが分断されてしまうので慣れてないとプログラムを追えないような気がしたので、差分表示されつつ双方のコードは分断されないオンラインdiff系のサービスのmergelyにコードを貼って課題のフィードバックをしてみた。mergelyもそんなにいい感じはしてないんだけど。他にないものかな。


圧縮化志向

第7回。関数についての解説の前段として、コンピュータとプログラムの文化としての「圧縮化志向(同じ条件でより高いパフォーマンスを生むほうがエライ/同じ目的を満たすならより短いほうがエライ)」について解説したうえでDemosceneとかコードゴルフなどを紹介した。

課題は「オリジナルのグラフィックツールをつくる」というわりとふつうのもの。


授業中のPost-it

前回に引き続いてパターン模写の課題を各人に進めてもらった。

各人が進めるマシンを見まわって質問や原理の理解が難しいポイントに個別にその場で答えていくという十数人相手の家庭教師みたいな状態で進めるんだけど、今日はたまたま大判のPost-itを持っていたのでその場で説明したメモ書きをPost-itに書いてそのまま渡すようにしてみたらなかなか便利だった(いつもは学生のノートを借りたり配ったプリントの裏に書かせてもらったりするんだけど)。これからも持っていくようにしよう。


パターンの模写

第5回。今回は条件分岐(if文)の解説をさらっとして(今回は残念ながらコンピュータ雑学をからめる余裕がなかった)、「プログラムによるパターンの模写」の課題に入った。テキスタイルパターンなど線や図案が規則的に敷き詰められたパターン画像を探して、Processingの図形描画命令とfor文、if文をつかってそのパターンを再現するプログラムをつくってみるという課題。次回も制作時間に充てて今回はサンプルプログラムなしで自分でゼロからプログラムを制作してもらう形。

プログラムの学習のための「パターンの模写」というお題は「Built with Processing」の本のなかでも紹介していた。たとえばデザイン科とかだと雑誌の紙面デザインのスキャン画像をイラレの下レイヤーに敷いて、そのうえにグリッド線やエレメントを配置して元デザインを可能なかぎり再現するデータを作るような演習したりすると思うんだけど、そういうなにかを学ぶための練習として「お手本を自分の手で完コピしてみる」訓練をプログラムでもするといいんじゃないかと考えて、でもこの場合お手本プログラムを写経してもあんまり意味ないので、自分の好きな繰り返しパターンをプログラムで再現するという課題にしてみている。

ほんとはパターンみたいな漠然としたものじゃなくて、プログラムを学びたいような人にとってモチベーションを感じるようなものを模写する課題にできるといいんだけど、パターン以外でちょうどいいモチーフはいまのところ見つけられていない。ちなみに『世界が変わるプログラム入門』ではそれに当たるモチーフを(昔の)ゲームにしていて、それはひとつの形だなとおもった。


プログラムの流れとジャンプ

第4回はfor文のレクチャで、はじめてプログラムに実行行のジャンプやそれによる繰り返しがでてくるところなので、コンピュータにおいてメモリ上のプログラムが逐次実行される流れとそのジャンプでなにが起きるのかということと、ちょっと間違うと無限ループになったりへんなとこにジャンプしてブルースクリーンになったりするよという話をして、Ben fryのdisMapを紹介したりスーパーマリオワールドTAS glitch(あるバグを引き起こすことでプレイヤースプライト管理データ部のデータがプログラムとして読み出されることを利用して特殊なプレイによってスプライト管理データ部にエンディングシーケンスにジャンプするコードを作ってゲームプレイのみによってゲームの状態を変更するデモ)を見せたりした。

ところで現代のプログラミングにおいてfor文をどのタイミングで教えるべきかってわりと悩ましい気がしていて(LLだとforってもうほぼ使わないしね)、今回も関数とif文を教えるのを先にしようかぎりぎりまで考えていたんだけど、結局forを先にした。前書いた2冊めの本( \Processing アニメーションプログラミング入門\ )では配列データの処理のところまでfor文を教えるのを送ったりしたんだけど。