Archive for the ‘日記’ Category

プログラミング1のレポート受付は今日まで

木曜日, 8月 18th, 2016

ギリギリまで完成度を高めてるのか、今日になって提出してる学生がちらほらいます。既に出してる人の中にも「実質的に白紙」みたいなのを仮提出しといて、出し直してる学生もいるな。頑張ることはいいことだということで採点作業は一先ず置いといて明日やろう。

NAL研ブログの第二弾は阿波連さんで、研究テーマの紹介らしい。創業を目指したスタートアップではないにせよ、やりたいことを人に見える形で表に出すというのは大切。アウトプットしてみないと分からないことは多いし。

NAL研ブログにデザインスクールブログ

月曜日, 8月 15th, 2016

学科wordpressの全RSSを参照してる人(どれだけいるか謎ですが)は既に気づいてると思いますが、

を少しずつ更新していってます。

NAL研ブログの方は週替わりで学生が担当していく予定。第一弾は伊藤くんです。今度は研究のこと書いてもらおうw

デザインスクールの方は現時点で実施日と会場、そしてテーマ概要までは決まってます。それだけしか決まってないともいえますがw

スタートアップチャンプルー PROXIMO(スタートアップカフェKOZAのキックオフイベント)

土曜日, 8月 6th, 2016

IMG_1931 IMG_1933 IMG_1935

サイト告知を眺めてた時にも感じましたが、実際の現場は想像を超える混沌っぷりでした。「チャンプルー」だし、狙った演出なんだとは思います。個人的にはライブ特有の大音量でサイドショーの部分は死にかけてました。(喜んでる人いっぱいいたので私が例外だとは理解してます)

イベント的には大成功だったんじゃないかと。この後何か生まれてくるは別として、イベント中にも前後にもあちこちで新しい繋がりが生まれてましたし。こんな舞台でLT参加して、ちゃんと発表しきった学生の皆さん。凄い。なかなかない体験だったんじゃないかと。学生の頃にこういう経験できたという点では羨ましくも思ったり。

休憩無しの4時間でしたが、登壇者多くて時間足りてない感強し。これも狙ってるかもしれないけど、「そこから掘り下げた話を聞きたいな〜」というところで時間が来るという。

全体的にはスタートアップ(創業・起業)支援ということを想定しているだけあっていくつか共通キーワードに集約されてるトピックが多かったです。記憶に残ってるのを列挙すると、、、

  • 一人でやれることには限界がある。仲間大事。繋がる可能性を増やすためにはコミュニティの存在が大きい。コミュニティじゃなくても良いが、集まる場があるのは強いメリットになる。
  • 複数人でやるということは複数の価値観が衝突するということ。相手には相手の価値観があることを認めて行動しよう。討論を効果的に進めるための手段を学んでおくことも大切。
  • 自身で実現する技術があるかどうかは後にして、解決したい問題、試してみたいアイデアがあればそれを人に話そう。アウトプットしないと誰も気づかないし、人に話すことで他の人と繋がるチャンスが増える。
  • 成功の裏には多数の失敗がある。失敗したということは何かしらそこで得た体験があるはず。挑戦したことを、失敗したことを互いに褒め称える価値観を共有しよう。
  • 創業時には先行きが不透明な中で同じメンツが顔合わせ続けるので人間関係がギクシャクすることも少なくない。リモートワークは一つの手。SlackでToDo進捗管理するとか便利なツールも多々あるので使いこなそう。
  • 大企業による大量生産頼みの時代から、個人生産がよりし易い時代に。3Dスキャナ・3Dプリンタ・センサー等など、安価で簡単にインテリジェントな一品物を試しに作ることができる。試行錯誤する視野を広げよう。
  • 許可を待つのではなく、まずやって何か問題が起きたら謝ろう。
  • 副市長:未来のニュートンのためにりんごを落とし続けます。

失敗恐れずにやりたいことやろうってことですね。

(プログラミング2) C programming as a second language

木曜日, 8月 4th, 2016

アルゴリズムへの繋ぎとしては、
  編集、コンパイル、型宣言、配列、構造体、c言語の関数
について説明してもらえると助かります。

という名嘉村先生からの依頼が届き、後期のプログラミング2の冒頭2週間ぐらいでこのあたりをサポートすることに。組み込み周りの開発で要求されることもあるので、最低限は教えておきたいというのもあったし。

ここ数日はC言語入門のための教材作成してます。数カ月先の話ですが、数カ月後には(新規担当の)授業が増えて、学会出張やらイベント対応やらあってで今から準備してないと死ぬ未来が確定してしまうので全力回避する必要があるんですよ。ご利用は計画的に。

ということでここ数日の成果がc_intro (C programming as a second language)です。文章的におかしい所、古い人なのでgccでやっちゃってる人(llvm一択でしょとインパルス先生からツッコミ頂きました)、コードのおかしい所(インパルス先生からry)、まだ修正は必要ですが、大枠は準備できたかな。

P.S.
今日の授業はレポート相談対応のため教室に滞在してましたが、TAで殆ど対応頂けました。ありがとうございます。今度なにか食べに行きましょう。

(プログラミング2) Javaの教科書選定

火曜日, 8月 2nd, 2016

5月頃に候補を絞ってましたが、新しく「新・明解Java入門 (明解シリーズ)が出たとのことで改めて絞り込むことに。

選定時のポイントは、
・既にPythonでプログラミングの基礎は終わっている。
・クラスやオブジェクト、オブジェクト指向、メソッドといったあたりの話はゼロ。
・上記を踏まえて、(a)クラスやオブジェクトあたりの解説が読みやすいか、(b)コード例が豊富か、(c)学生自身が独習(予習・復習も含む)に使いやすいか。
といったところです。

上記を踏まえると、こんな感じ。

3位の「スッキリわかる」の方は、ドラクエ風ゲーム作成を念頭に進んでいくのでそっち方面に興味があって、コード例を中心に頭から最後まで一度通す分には悪く無いです。ただし、前にも書いたように全体的に「対話やり取り」での説明が多く、ぱっと見でどこにに何書いてるかが分かりにくそう(=復習やリファレンス用途に向いてない)なところが難点。あと、ゲームの例が分かりやすいとは限らないという話もあったし。

2位の今回眺めた「明解」の方は、「スッキリわかる」よりは一般的な事例を採用し、対話方式でもない分探しやすい(読みやすい)のですが、解説のボリュームがやや不足気味。「オブジェクトやクラスって何?」という質問に対して「こういうニュアンス。こう使う」という解説が事例で少し触れてるぐらいで、基本的にはチュートリアル+αに近い印象。書き方は分かるかもしれないけど、何故そう書くのかは分かりにくそう。

1位の「新わかりやすい」の方は、オブジェクトの捉え方についても取り上げて解説されてる分、他2冊よりも「読んでて腑に落ちやすい」構成に見えます。帯に「人気No.1の完全独習テキスト」「学生のわからないを徹底的になくした」とあるのに納得の解説具合です。抜けてるというか簡素化しすぎてる部分もありますけどね。Java仮想マシンの話ほぼ無いとか。

ということで、プログラミング2の教科書は「新わかりやすいJava入門編」に決定かな。これ以上新しく探す余裕は(あまり)無いし。

沖縄市のスタートアップカフェに潜入

金曜日, 7月 29th, 2016

写真撮り忘れましたがorz

遠藤先生と、コリンザ近くに出来たスタートアップカフェ関連施設巡りをしてきました。来年にはコリンザに移動するらしい(今は工事中)けど、今の場所のままでいいんじゃないかと思うぐらい中身も周囲の環境も良いです。

  • スタートアップカフェ・コザ:総合窓口的な位置付け?。1階は誰でも自由に使えるスペースになってて、例えば学生なり社会人なりが入り浸っても全然問題ない(むしろ使ってくれ)スペース。
  • カフェの2階にKOZA shore Studioという名前で教育プログラムの実施を想定しているらしい。想定してるというか準備してるプログラムもあるけど、一緒にプログラム検討するところからもやりたいらしい。大学も使っていいっぽい。
  • カフェの向かい側(別の建物)の2階にMIRAI FACTORYがあって、そこではプロトタイプ作成するための機器類(3Dスキャナ、プリンタ、削りだし等など)が勢揃い。これも自由に使いまくれるし、既にあれこれ試作してる人もいました。

ちなみにコンシェルジュとして入られている人の中にはLight-up cosplayの中の人(技術のほうね)がいたりして、分からないことあれば聞いてくれというスタンスらしい。

実際に触れるものがないとわからないことは多いというか、物があって初めて学べることがあるという話で、どんなものがあるとどういう効果があるのかを実験(実体験)しながらブラッシュアップできる環境の重要さを熱く語ってました。

そんなこんなでスタートアップ支援に絡めて教育やら問題解決やらいろいろやってくよ!というスタートイベントStartup Champloo “PROXIMO”が8/5(金), 17:00に音市場で開催されます。遠藤先生もスピーカーです。また、これからの調整になりますが情報工学生もLT参加の方向で進みつつあります。学生運営メンバー募集してるようですが、実際には「運営ヘルプして欲しい」ではなくて「(仕事ないけど来て参加して)色んな人と繋がるチャンスを活かして欲しい」らしい。ただの一般参加者よりは運営側に回ることでそっちの人らと近くなるチャンスを作ってるという位置づけですね。

ということで、時間取れる人は参加しよう!

(プログラミング1) 最終課題の難易度

木曜日, 7月 28th, 2016

授業最後の週はバージョン管理入門+軽い振り返りと、ペアプロでの演習という塩梅。振り返りがあること以外は普段通りですね。

最終課題「力技で解く巡回セールスマン問題」で学生が相当悩んでるらしく、今週に入ってからちらほら相談に来る学生が出てきました。考え方をあれこれ提示してみたり、具体例で少しほぐしてみたり。問題の分割してみたり、分割した後に機能としてどう設計するか一緒に検討してみたり。

ちなみに、授業で課題提示した時から繰り返し伝えてたつもりなんですが、「(初学者にとっては)相当難しい」です。友人なり先輩なり協力し合って取り組むのを推奨してます。あと、「100%なレポートは求めてない。サブ問題に取り組むも良し、途中段階まででの報告でも構わないからできたところまでで報告してくれ」という話をしたら少しは安心してくれた、かな?

正直、2年次の学生でも「一人では解決できない人」って結構いると思うぐらいの難易度です。でも、問題そのものは理解しやすいので、これをどうコードに落としこむかという過程を見るには良い問題だとも思ってます。これまでに教えた物だけで実現できる問題でもあるし。

来週は期末試験期間ですが、レポート出し切れてない人は集まるようにと指示。ただし、他の科目優先したい等の選択は学生に任せす。取り敢えず来い。

(プログラミング1) 例外とアサーション

木曜日, 7月 21st, 2016

残り少ない授業で何を扱うかと悩みつつ、今日の本題はテキストでも触れてる例外とアサーション。おまけでiris dataset さんにご登場頂きつつPandas + Matplotlibなデモをすることに。途中でポリモーフィズムな話も少し出ましたが、今は「聞いたこともある」ぐらいで十分。まだクラスの話も出してないし。続きは後期にやりましょう。

ペアプロ演習中の質問対応してると、「引数」という用語を理解してない学生がいたりしてシクシクだったりしますが、ま、少しずつ共通辞書作っていこう。どの科目でも一緒なんだろうけど、やる学生とそうでない学生との差は半年間で大きく開くなぁ。

来週15回目最後の日はバージョン管理を触る予定です!これで授業としては一段落かな。最終レポートの対応は置いといて。

P.S.
8/5(金) にスタートアップチャンプルーPROXIMOなるイベントがあるらしい。キーノートも含めてあれこれメンバー凄いな! 「内外の専門家とクリエイターを集め、ライブホールで音楽などのカルチャーとスタートアップが融合したイベント」という謎の融合具合ですが、遠藤先生もスピーカー登場する模様。(皆で押しかけようw)

(プログラミング) 先輩とペアプロ?

水曜日, 7月 20th, 2016

1年次のプログラミング1でペアプロ導入してますが、本来とは異なり、素人同士で組んでるペアが大半です。一部には高校時代に経験のある人も混じってますが、割合的には少数ですね。できれば先輩と組ませてあげたいなと思っていたのですが、何やらやれる可能性はゼロではないらしい。

想像してた方向は、例えば院生がやってるPMのように(別の)授業の一環という形でのペアプロ参加。単に聞かれた質問に答えるような立ち位置ではなく、例えばコーチングなりオブザーバー教育をした上で望んでもらい、1〜2週間に一度サポーター等による報告・問題共有・対策検討を行う場の用意して、教員フォローを含む形での先輩参加を考えていました。実現できるかどうかは置いといて、別の授業を立ち上げる、と。

そんなところに遠藤先生からの情報で、学習サポートを活用する方向はないか、という話が。予算の都合を把握してないですが、やれるんだろうか。

(プログラミング1) テストとデバッグ周りのTips+関数設計Tips

木曜日, 7月 14th, 2016

しつこく繰り返してるミニテストの方は、どうにか正答率8割〜9割にまでたどり着いたらしい。自作モジュールの使い方とか順序付きシーケンスに該当するオブジェクトを選べとかその類の設問ですが、相当繰り返してます。それでもまだ1割強が間違ってるわけですが。

13回目の授業はユニットテストとデバッグ周りの話をしつつ、関数設計というデザイン寄りの一日でした。解説自体は50分ぐらいで終えて、残りの時間はペアプロ演習。演習風景を眺めてると未だに関数実行するところで躓いてる人もいます。関数もオブジェクト同様に扱えるという話をしたせいで逆に混乱させてるという節はあるかも。

関数設計の話は、問題が目の前に提示された時に「いきなりコーディングし始める」のではなくて、タスクを理解・整理してからプログラミング言語に翻訳する必要があるよと。どんな機能が必要になりそうかを列挙するにあたり、各々の機能を「タスクを知らない人間にやってもらうにはどう伝えればよいか」を考えてみよう。まずは日本語で伝えるとしてどう伝えればよいか。相手に教えられるぐらい言語化・整理できたら、それを変数・制御文・関数なりに置き換えてみよう。といった話をしつつ、具体例で学生に質問当てたりしてみるものの、応答が「分かりません」も少なくなくて。うーん。

もっとじっくり時間かけてやっても良いのかもしれないが、うまいやり方ないかなぁ。個々の関数をどう実装するかというレベルの話ではなくて、どういう関数を用意したら良いかというレベルの話。唯一の正解があるわけではないし、間違ってもいいから歩き出すための土台(設計書)を作ろうという話なんですが。

そういうことを求めるレポート課題を出せ、という話でもあるのだろうけど、レポート書けても理解出来てるわけではないからなぁ。(課題の出し方が悪いという話はあるか)