Archive for the ‘日記’ Category

就職センター中の人話、PostgreSQLリストア済んだその後

金曜日, 7月 4th, 2014

今日で実験1が入り込んだ忙しい週が終了。実験4コマ、授業1コマ、ゼミ3コマな週でした。別タスクとしては、デザインスクールでのテーマとして設定できそうかの下調べとして就職センターに話を聞けたか。

m_2014070402425753b614b1dc881

実験1/ネットワーク演習1は、レポート課題ではなく実技テストのみで、一応今週出席した人らは大丈夫の模様。欠席者にはメール通知済みですが、今の所一人しか反応ないらしい。もう後半だし、そういうものだろうなとも思うけど、時間も授業料も勿体無いな。

PostgreSQLリストア問題は、一通り解決。結果的には8カ所にエンコード上の問題がありました。思ったより少なくて良かった。ということで後はリストアしたやつに収集スクリプトで追加していくだけ。だと思ってたんですが、これが微妙にうまくいかない。rootで動くことも確認済みなんだけど、cron実行すると動かない。せめてエラーログ吐いて欲しいんだけど。って、そういうスクリプト噛ませば良いな気もするな。でもちょっとこれ以上追求したくない気分なので、週明けまで放置プレイで。


m_2014070402142653b60e02758dd m_2014070403262653b61ee265deb

就職センターではわざわざセンター長を初めとして3人もが時間割いて準備してくれてました。何だか申し訳ない。就職センターとしては、直接的な就職活動支援だけではなくインターンシップ/アドバイザ(キャリアカウンセラー)、その他の企画イベント(例えば企業見学)等の提供を通して「卒業生らの進路決定率(not就職率)」改善に繋げることを目標としているらしい。進路決定率を意識しているのは、「就職率」はちょっとしたマジックナンバーで母集団が卒業人数とイコールではないため。具体的には、昨年度の進路状況として公開している就職率88.3%は「就職を希望していて就職できなかった割合」であって、その隣りにある「その他」の255人は「卒業してるけど就職を希望していない人も含む(公務員/教員志望等も含む)人数」で、進路自体を決定できていない人数がかなりいるという話。

聞きたかった話は「沖縄ならでは」の話について。伝聞では「沖縄の人は辞めやすい」とかありますが、そこら辺の数値/何かしらの体験談や、就職相談等を通した県民特性なりがあれば是非とも、という気持ちで突っついてました。あいにくというか就職センターとして卒業生の追跡調査は困難なのと、企業への質問アンケート等も回答率が悪いために統計的な情報や分析はできていないらしい。ただ、就職活動支援(旅費2.5万支給)に伴う報告書を眺めたり、報告会を開催している限りでは「県外学生のアクティブさに驚いた」ケースが多いらしく、一度参加することで意識に変化が見られる学生が少なくないとのこと。その大きな要因は、沖縄が海に囲まれた小さな島(で競争相手が少ない)ことや、親御さんが必要以上に過保護にしてたり、求人自体が少ないにも関わらず最初から外を知らないので県内指向といった、県民性に根ざした問題かもしれない。という話でした。とにかく「一歩踏み出して外に目を向けよう!(あれこれ手を打ってみるがそもそも学生が来ないケースが多い)」とのこと。うん、そうだよね。B2にブログ課題やらせてるのもその一貫だし。「辞めやすい」については、恐らく事前の企業研究不足によるミスマッチではとのこと。どう調査したら良いか、そもそも調査自体していないことも少なくないとか。


個人ゼミは高橋くんの番で、やりたいといってる情報推薦とはどのようなものか、について少しずつ周辺情報を書き出し、説明し合いながら互いの認識を共有。同じ言葉でも違うことを意味していることが多々あるので、いろいろ表現し直してみるというのが重要。この過程を通してぼんやりしてたイメージを少しずつ具体化していくことに。ただ、最終ゴール自体が決まってる訳ではないので途中からは「具体例を例示」したり、「それらを抽象化することで課題例を提示」したり。テーマに落とし込む所まではやってないですが、参考になるかもしれない文献渡しつつ、咀嚼兼ねて自分なりに整理&再検討してもらうべく宿題として持ち帰り。

m_2014070410320053b682a0bf04f

お疲れモードなので月曜日はお休み。ということで3連休〜。

PD2、NAL研週ゼミ、PostgreSQLリストア時のトラブル

木曜日, 7月 3rd, 2014

今日はPD2とNAL研週ゼミで、合間に昨日のPostgreSQLリストア時のトラブルをチェックしてました。大凡の目処が立って良かった。

PD2の11回目は先週の続き。最終課題「情報工学科のCMを制作」に向けて各自のアイデアを考えて来てもらったのが先週の課題で、今週はそれを持ち寄り互いに披露し合って討論題材とし、目標像に落とし込むというのが目標でした。が、どこまでやれてるのかは謎か。実際問題として「一度決めたはずの目標像が進むにつれて*思ってたのと違う*」とか良くある話だし。それでも、決められた期間(時間)で収めることを前提に計画立てて行動し、躓いたならそれはどこか、何故そうなったのか、を経験して欲しいです。そのための実習形式課題なので。経験せずに済ませるなら適当にレポート書かせて終わりますが、それを求めている授業じゃないです。デザイン(設計)に関連した失敗を含む様々な経験をして欲しい

PMで院生も来てたので河野研/長田研でのmercurial/gitlabの使い方を聞いてみたり。河野研は論文やソース等をmercurialで管理してて、論文ならそのリポジトリを先生に伝えてメール指導/直接pushで指導されたり、印刷して持ってくる場合には赤ペン先生したりとその時々でやりやすい形で指導してるらしい。こういう添削を一通りcommitログ化しておくと、添削システム作成用のデータセットにも使えそうではあるのだけど、明確な良し悪し以外のルール化は難しそう。長田研のこの間の勉強会話は、gitlab上でのコメントを使ってみ遊んだという話だったらしい。


m_2014070309232753b5210fe90d4

週ゼミは久しぶりに全員集合。最近は「まず院生の進捗確認&討論してから4年次に1回以上質問させる」という風にやってみてるのですが、院生にも予想外の質問が出て説明する練習になって良さげらしい。本当は自分からどしどし質問して欲しいのだけど、そうなる切っ掛け作りになるなら強制しても良いか。

NNでの深層学習のDropout周りのアンサンブル学習効果について検証使用としている玉城くんは、まずはDropout率を変更してみての精度チェック。Dropout率が高くなる=稼働するユニット数が減ると「瞬間的な学習効果(1度の重み更新度合い)が高くなる」らしく、ユニット数が減った状態でBPしてるなら確かにそうかという話。当面はDropout自体に手を加えてみての検証をしてみる方向に。

トピックモデルLDA結果へ「分かり易いラベル」を付けようとしている慶留間くんは、HDP-LDAで得られるトピック数と、その際のトピックの中身自体に疑問があるとのことで、自身でチェックできる分かり易いデータセットを構築して再建してみることに。

小説読んだ際の感情を推定しようとしている平良くんは、認知評価を含めた(というか認知的評価を確認できる)アンケートを作成してみたので、検証できそうかを確認するため研究室メンバ内でもやってみてくれという報告。第一被験者になった人はありがとうございます(これからもお願いしますw)。


m_2014070310432753b533cf9434d m_2014070310495953b53557e7dd0

PostgreSQLのリストア問題は、

  • (1) pg_dump 時に owner 関連を含まないように dump させても alter owner するような SQL を出力しやがること。
  • (2) 古いPostgreSQLでのエンコーディング問題の逃げ方を参考に進めると、出力されるエラー行には何も問題が無いこと。(実際にはその前で別のエラーが出てたのだけど、それがなかなか再現しなかったために気付くのに時間がかかった)。
  • (3) pg_restore が素のSQLに対応していない(何でだよ)ので tar でやってたのだけど、エラー箇所が「行(とエンコーディングで問題あるんじゃない?というヒント)」しか出さないこと。(該当行を探すのにいちいち展開+関係しそうなファイル探し+該当行チェック、という手順を踏む必要がある)

で、ようやく問題特定できたので、修正できるようになりました。どのぐらい修正箇所あるか分からないけど、素直に delete しまくった方が早い気がしなくもない。もともと綺麗なデータセットではないので多少データ件数減っても問題無いし。ま、続きは明日やろう。この辺りの問題は MySQL では一度も遭遇したことがないので、個人的にDB構築するなら二度と PostgreSQL は触りたくないな。と思えるぐらいには面倒くさい。。

トランセンデンス->ゲームAI、古いPostgreSQL周りのエンコーディングトラブル

水曜日, 7月 2nd, 2014

トランセンデンスはまだ見てません(前置き)。

今日は短めの会議が一件あっただけで他は空いてた一日でした。オープンキャンパスの方も基本的には資料作成を一応終えている(チェック待ち)し。ということで午前中は読みたかった記事やらをあれこれチェック。

人工知能が意識を持つのは遠くない? – 「トランセンデンス」トークイベントは技術的特異点に因んだテーマにもなっている映画「トランセンデンス」の紹介記事というか、逆方向の記事らしい。特異点のキーでもある「汎用人工知能(Artificial General Intelligence; AGI)」はここでいろいろ話も進めているらしい。人工知能学会も最近特集が出てました。毛色が大分変わりますが、ゲームの中の人工知能なる三宅先生のスライドや関聯論文が。ゲームの進化と共に進化が求められたNPCの「表向きに見える歴史」と「裏側を支えて来た歴史」がずらずら出てきて面白い。

午後は堀川くんのツイート収集スクリプトを別サーバに移行しようと四苦八苦してました。いや、まだ現在進行形か。一応目処が付きつつありますが、古いPostgresには encoding 周りのバグが残ってるらしく、こんな感じでチェックしながら対応せざるをえない雰囲気。ちなみに今回は「同一バージョンでの dump&restore」なんだけど、同じ状況です。しくしく。古いバージョンに残ってるなら、今のバージョンに頑張って restore しても後でまた問題が出てくるので、一度 Postgres 最新版をインストールしてからにした方が良さげか。

というか一番時間かかったのはスキーマ dump->restore するだけで何故か失敗してたこと。ここはencoding関係ないけど「validじゃない」と言われ続けてた。mysqlだとdump&restoreでつまづいた記憶は一度もないんだけどな。。

複雑研全体ゼミ、ネットワーク演習、gitlab勉強会

火曜日, 7月 1st, 2014

火曜日恒例複雑研全体ゼミは「統計的機械学習―生成モデルに基づくパターン認識」の「3章 識別関数の良さを測る基準」と「4章 最尤推定法」を終了。終了したのだけど、イマイチ数式解釈をスルーしがち(ゼロではないけど)なのがちょっと。表面をなぞるだけの読みでは「ふーん」で終わっちゃう。一方で参加者側も質問を遠慮しがちなのもちょっと悲しい。義務づけないとしないというのは、勉強する気が無いということだよなぁ。それでも良いからと強制しても良いんだけど、それは私の主義に反する。主義に拘っても意味無いのだけど。

3章の概要は、最大事後確率則(入力パターンが属する可能性が最も高いカテゴリを選ぶ)、最小誤識別率則(パターンが誤って分類される確率を細小にするように決定する)、ベイズ決定則(誤って識別したときの損失を最小にするように識別する)を数式展開していき、本質的には「最大事後確率則=最小誤識別率則」となること、またベイズ決定則も損失が一定なら一致。その上で計算が複雑になることを避けるために最大事後確率則をチョイスし、p(x|y)をシンプルにするため条件付きでない確率密度関数p(x)を訓練標本から推定する問題として4章以降を進めるよというお話。

4章は最尤推定法の定義と特徴を示しつつ、マハラノビス距離(wkipediaslideshare)の紹介。ガウスモデルのシンプルな形(カテゴリ毎の分散共分散行列Σが等しいと仮定するとフィッシャーの線形判別分析(slideshare)を「訓練標本をガウスモデルで近似することで最尤推定量(μとΣ)を算出し、それから超平面を構成する傾きと切片を算出できるというお話。

良い演習が用意されているのでそれを宿題にしつつ「発表担当者以外も事前学習しよう」と突っ込み入れて終了。


午後は実験1の情報ネットワーク演習1の火曜日組み2週目、動的経路制御と実技テストを終了。ネットワーク演習するようになってから7,8年目?ぐらいですが、(先週)授業終わった直後に再確認したいからといって復習し始めたグループがいたのも、(今週)授業が始まる前に来て復習してたグループがいたのも初めてかも。実技テスト前の動的経路制御な演習や、先週も含めて「いきなり全体を構築するんじゃなくて、小さく設定して動作確認しながら進めよう」と何度も口酸っぱく言ってるつもりなんですが、どうしてもゼロにはならない。教育というのはそういうものなんですけどね。でも、こういう「細かくチェックする」という癖を早めに身につけておかないと、(その人にとって理解の範疇を越える)複雑なシステムに直面すると太刀打ちできないだろうという意味で、これからも言い続けます。


5時限目は、名嘉村研の嘉数先輩によるgitlab (git/github/gitlab) 講座。gitlab を研究室で使い始めてるところが出て来ているらしく、どういう使い方してるのか聞いてみたいということと、1年次の学生から講座開いて欲しいという話を耳にしていたこともあって調整した結果、今日開催してもらえることに。いや、最初は「話を聞く」だけだったんですが、偉大なる嘉数先輩は資料まで準備してくれて話をしてくれました。ありがたいことです。ちなみに長田研での勉強会もあったらしい。こういうのを学科atndか google calender か何かで共有すると良さそうなんだけど、自分から用意するほどでもなく。学生が自主的にやってくれれば良いと思ってるし。でもあった方が良いのだろうなとは思う(シツコイ)。

話を聞いた限りでは、一番のネックは検索性だということが分かった。自前で clone & grep しても良いのだろうけど、それだとリポジトリ横断検索しづらいし。自分でそういうツール作れば良いという話でもあるけど、一方でカスタマイズしすぎると「gitlabのバージョンアップに追従し続けるコスト」もあったりで悩ましい所。そういうのを避けたいというのが一つの理由で、gitlabはどうなんだろうという気持ちで聞いてみたかった訳だし。あと、研究室用途という点では「プロジェクトとは切り離したトップページとしてのwiki機能」も欲しいのだけど、現状では別途pukiwikiなりを用意するか、wiki専用のリポジトリを作ってそれで運用するかみたいな対応になるらしい。gitlab上だと検索できないのでpukiwikiか何かしらのwikiクローンを用意することになりそう。適材適所で使い分ければ良いという話でもあるか。3つ目のネックは通知機能で、「プロジェクトはクローズドだけどcommit log程度の情報をRSS feedで受け取りたい」という微妙なもの。いちいち自分でpullするのは嫌だし、かといって Mail/Twitter なりでいちいち「pushしました」と言われるのも嫌な状況での利用なんですが。具体的には論文指導する時だな。

河野研ではtexというか論文指導もmercurial経由でやってるっぽいのだけど、指導コメントは特に何も考えずpushするだけなんだろうか。diffで見れれば十分という話ではありそうだけど、何か工夫の余地がありそうでもある。

m_2014070110174253b28ac686352

晩ご飯はヘチマたっぷりの味噌汁。適当に白葱加えたのは失敗でした。汁飲む分/香り具合には構わないけど、ネギ自体の味は邪魔だな。ヘチマさんが死んでしまう。

個別ゼミの再始動/進路相談(私の場合)

月曜日, 6月 30th, 2014

全体ゼミなり欠席組みの調子が改善してから再始動するつもりだったのが、いつまでもずるずると長引くことになってしまって早幾月。待つだけ月日を無駄にしちゃってる感が出て来たので、それはそれとして個別ゼミを再指導することに。いつまでもテーマ決まらないとちゃんと来てる方も心配だろうし。

再始動個別ゼミの1回目は神谷さん。ターゲットが小説という点で平良くんにも近く、どこかで互いに補える部分がでてくることを期待しています。今回はテーマとしてどういう目標を設定できそうかを列挙し、互いの言葉やニュアンスからズレや違いを修正し直しつついくつかの具体的な目標例を設定。そして目標に対するアプローチをいくつか検討してみるという流れで話を進め、卒業研究全体像をイメージしてもらってました。あれこれ図やイラスト書きながらだと手書きが早いし、書いたものを広げて俯瞰したり繋げてその先を考えることもしやすい。ということで裏紙さんを使いまくり。別に新しいコピー用紙使っても良いんだけど。

その後は別学生からの進路についての相談。私自身の場合は、大学入学時にはゲーム作りたかった(ので、課題と無関係にあれこれミニゲーム作って遊んでた)。B1前後では全く進学なんて考えてませんでした。2,3年次で人工知能とか知能ロボットといった知能情報系科目に出会ってから大きく変わり、関連本探したり先生に質問に行ったりしてたはず。その頃もまだ進学というのは意識してなかったのだけど、研究室仮配属されて具体的に論文手渡されてから「そっちの道」を考え始めました。正確には、「どうしようか」だったのが、「そっち一本」になりました。その前後で企業見学ツアーとかにも参加してたのだけど、それ以上に魅力があったし、今でもその魅力に取り付かれている。

論文を手渡され、関聯論文を探しに図書館へ出かけて「雑誌(=学術雑誌)」の意味が分かったり(それまでは学術じゃない定期紙のことだと思ってた)。検索エンジンなかった当時、学会事の学術雑誌が膨大に陳列されてる様を眺めて戦いたり、あれこれ読み漁ってツッコミいれたり、何を書いてるのか分からず悩んだり。(今は検索エンジンある分良くも悪くも探し易いのだけど、それがかえって「巨人の肩」を実感し難くなってるのかなと妄想してしたり)。ツッコミ入れるぐらいなら自分でやれよということであれこれやって論文書いたり。たまたま地元開催してたからという理由で発表ねじ込まれた学会から「論文書かないか?」と声かけられて喜び勇んで書いて投稿したら「分野が違うからNG」とか言われて拒否られ、そのことについて遠藤先生が怒り心頭で先方に電話で怒鳴りまくったりとか。没頭してただけあっていろいろあったか。

具体的な研究活動の始まり「論文読み」だったとすると、具体的に学外に出て発表したのは情報処理学会の全国大会で、当時のログを見ると9月に発表してたらしい。当時はまだプロジェクタなんて一般的ではなくて、OHPシートを使っての発表が一般的な時代。アニメーションは手動(一枚ずつ上乗せ)でやる時代。人によってはその場で党名のOHPシートに書きながら発表したりしてた時代。学内の周りでは見聞きしないことだらけで楽しかったのだけど、先生含めて他の人からは真面目に参加してる変わったやつとか見られてたらしい。そのまま博士後期課程までいくかとか、その後どうするかとか何も考えてなかった(これは事実。自分の人生なんて自分が楽しければそれで良いと思ってるので)のですが、気がつけば今こうしています。ここ最近は研究から遠ざかっている(指導ばかりで自分自身で論文書く回数がめっきり減っている)のが当面の一番の問題だな。自分が楽しめない研究なんて楽しくないし。

ちなみに、一番苦労したというかもう二度とやりたくないのは「博士論文〆切1週間だか2週間前に連絡貰ってそこから徹夜が続いた」ことです。博士後期課程3年目は授業等取り終えてたので丸々1年間アメリカのFermiLabに研修に行ってました。離れてることもあって「日程決まったら連絡ください」とお願いしつつ、修論ぐらいのタイミングだろうとたかをくくってたら数ヶ月単位で違い、それを数週間前に伝えられて死ぬかと思いました。もう、あの頃には戻りたくない。。

でも研究自体はやりたいので時間下さい。(オープンキャンパスの準備しながら)

P.S.
やりたいことがあるなら、そのことを快適にやれる場所に進路を進めるのが。なんとなくでは時間が勿体無いです。

(不定期コラム) こんなレポートは嫌だ

土曜日, 6月 28th, 2014

先日実験1のレポートチェックを終えましたが、今年ならではのという話ではなく、私が教員として大勢の学生を相手にチェックするようになってからずーーーーーーっと続いてる普遍的な傾向。つまりは例年やってるレポート指導。折角なのでまとめておこう。

傾向を大別して「一般的なレポートとしてのおかしさ」と「LaTeX文書としてのコマンド等のおかしさ」に分けてみました。


一般的なレポートとしてのおかしさ

悪い点まで含めて丸々コピペ。
先輩等含めて他人のレポート参照するのは推奨してます。理解して自分で書くなら。理解もせずにコピーするのは「コピー機」でしかなくて、何の勉強にもなっていないのだけど、高い授業料払ってそれで良いの?。電子ファイルは複製しやすいですが、それと同じぐらいコピペ判定も簡単なのを分かっていないのだろうなとも思う。「悪い点」までコピペする(それを採点するコストを他人に強要する)というのは喧嘩を売ってるということだよね?
日本語の文章になっていない。
見出しでもなく本文中に「結果」と一言書いて図表掲載してるだけとか、文章が日本語になっていないというケース。報告書以前の問題なので、まずは文章書けるようになってください。参考文献としては「知へのステップ―大学生からのスタディ・スキルズ」、「大学生のためのリサーチリテラシー入門」とか? いや、まずは「文章で説明しろ」というだけの話なんですが。
句読点の使い方がおかしい。
補足も何もあったものではないですが、文字通り「句読点が無い文章」や「本文中の句読点が不揃い」というケース。個人的なメモなら自由にやってくれて構いませんが、レポート(報告書)ならそれなりの文章を書こう。
パラグラフを意識していない。
ツイートとかの short message 系ツールに慣れ親しんでるから、という訳でもなくこれも昔っからある傾向ですが、パラグラフが存在していないケース。句読点で改行されてることが多いけど、無関係に改行が入ることも。パラグラフで書けないということは、報告書が構造化されていないのと同等なので、意識して(章節や段落という意味で)構造化文書を心がけよう。構造化文書書けない人はプログラミングも苦手だろうなと思う。どう心がけたら良いかの具体例としては、「やればできる 卒業論文の書き方」か「レポートの組み立て方」あたりを一度は読んでみるとか。
本文の無い節がある(箇条書きだけ/図表だけ/本当に何も無い)。
これも見出しだけで言い切ってますが、「2.2 結果」と見出しに加えて図や表はあるもののそれに関する説明文等が本文中に一切無いケース。派生ケースに「自由課題に取り組んでる割には目的/手段を述べずにいきなり結果を示してる」ものも。一般的に、報告を受ける人はエスパーじゃないので文章でストーリーを説明してください。
図表や参考文献を本文中で参照していない。
授業レベルのレポートではそれでも良いかなとも思えるのですが、正式には「どこで参考にしたか」を参照して示すべき。例えば web でリンク張る時に無関係の所にリンクが用意されててもムカつくよね?
図表にタイトルが無い or 同一タイトルの図表がある。
原則として同一タイトルで異なる図表が同一レポート内に存在するというのは不適切。違う意図があって作図したからこそ複数掲載しているはずなので、図表事に適切なタイトルを付けよう。
折れ線グラフ等の軸ラベルが小さすぎて読めない。
ベクター形式になってるなら拡大して読めますが、それでも本文の文字サイズと比べてラベルの文字サイズが小さすぎるなら、改めましょう。誰でも読み易くない報告書は読みたくないよね?
(ソースコードではなく)本文中で用語等をダブルクォーテーションで囲う際に向きを気にしない。
“ここを強調したい”のようなケースでカギ括弧や丸括弧は剥きに気を使うのに、本文中のクォート類で向きを無視する人多数。プログラミング言語では剥きが無いことケースも少なくないからだとは思うけど、文章中ではちゃんと剥きを整えよう。
結果を現在形で書く。
分かった事実は過去形で書こう。関連して、事実とそうでないもの(考察等)は文章から明確に区別できるように書こう。

LaTeX文書としてのコマンド等のおかしさ

texを使う理由は、数式等を綺麗に出力したいからだけではなく、目次生成/図表文献番号の整理等を自動化するためでもあります。例えば、途中で図表を中間に追加したり文献追加したりする度にそのインデックスを自分の手で書き直すのは嫌ですよね?

図表のインデックスを手動で書いている。
図表なら caption で図番号&タイトル付けると共に、label でユニークなラベル名を付けよう。本文中から参照するには ref。参考文献なら bibitem と cite。
PDF/EPSといったベクター形式で作図したのに、PNG等のラスター形式に劣化させたあげくファイルサイズを数十MBにして掲載する。
お願いだから辞めてください。ebbでbounding box情報を抽出して、テンプレートを参考に埋め込めるようになろう。
目次を手動で書いている。
tableofcontents 使おう。勿論、section/subsection 等で見出しを書いていることが前提になります。(こういうのを自動生成するために目印を付けるのが section等のコマンドな訳だ)
section, subection 等を使っていない。
前述の目次にも絡む理由で、見出しにはちゃんとコマンドを使おう。言い換えると見出しと本文を明確に区別しよう。
\\ で改行しまくる。
新しいパラグラフを始めるなら「空行」をいれよう。\\ では「新しく段落が始まる」ということを tex が認識してくれないので、「段落始まりである時下げ(スペース)」を自動で入れてくれません。
本文を verbatim で書く。
気持ちは分かる。けど、それ何の解決にもなってないネ。似たケースに table や何かしら罫線で囲う人も。こうして罫線文化が生まれているのかなぁ。。本文は環境使わずにそのまま書こう。
本文中で記号をエスケープせずに全角で書き直して出力する。
verb なりエスケープするなりして半角のまま記号を出力しよう。

その他:担当教員名の誤り。

(年次指導でもあるのに。しくしく)

Agile Japan 2014 サテライト <沖縄>

土曜日, 6月 28th, 2014

Agile Japan 2014(リンク張ろうとして気付いたけど、タイトルも本文もスペル間違ってるぞw)なるイベントがあったのに気付いたのがお昼前。準備したら午後に間に合うタイミングではあったのだけど既にあれこれ調理を始めてて動きが取れずでUstream参加してました。準備してくれてた名嘉さんや主催者らに感謝。

CA3E4938

agile な開発というのを個人的な解釈でまとめると「細かく見える化してフィードバックを貰いながら進める」。以上。基調講演(1),(2)の話はどちらも初めて聞く話で面白かったです。ウォーターフォール型だろうがアジャイル型だろうが「全て開発するならアジャイル型の方がヘッダがある分コストが高い」、しかし、「アジャイル型はウマく開発しなくても良かった部分を見つける」ことや「そもそもユーザが望んでいたゴールが勘違いである可能性」等も同一チームとしてレビューしながら進めれる点にメリットがあるとか。なるほど。平鍋健児さんの本(アジャイル開発とスクラム 顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント)倉貫義人さんの本(「納品」をなくせばうまくいく ソフトウェア業界の“常識”を変えるビジネスモデル)買って読んでみよう。(最近財布の紐が緩いな)

「(設計を含む)開発」が暗黙知というのはそうだよな。逆にマニュアル的にやれる部分というのは「プログラマというよりはコーダー」レベルの話で、そういう部分はどんどん自動生成に置き換えられていくでしょう。暗黙知なものを他の人に伝えるには empathy が必要で、具体的には徒弟制度チックにやるのが一番早いというのも納得。実際問題、学生実験でプロジェクタ通してリアルタイムにコード書かせながらコメントしたり、コードレビューしたりすると「一般的な座学」では得られない部分があるし。ただ、このやり方にも限界があって、人数が多すぎるとどうにも進まない。だから実験3,4の人数は個人的には6名ぐらいが上限なんだけど、他の先生に押し切られて今年度から10名強になってるんだよな。どうなることやら。

m_2014062818565653ae916897dd1 m_2014062819321653ae99b0f1b66

m_2014062820313453aea7961c690

晩ご飯は前々から気になっていた炭火やきとり ながたへ。十分肉美味しかったのだけど、もうちょっと野菜串の種類が多いと嬉しい。いや、実際に野菜が多いとあれもこれも頼みまくりそうだから、財布事情的には今ぐらいが丁度良いかもしれないナ。

胃袋を鷲掴みにされるということ

金曜日, 6月 27th, 2014

昨日の梅雨明け宣言後もまだ高湿度な日が続いていますが、今日は比較的「シンプルに暑い」という天候具合で、本格的な夏日の始まる予感がひしひしと。日傘の有り難みを感じるのは良いけどそれにも限界があって、朝通勤するとまずは汗を拭うなり酷い時にはまず着替えからという状態。何かもう一つ徒歩通勤を快適にするグッズが欲しいが、具体的に何が効果的かは良く分からず。あれこれやっても汗かくのは避けられないから着替えで良いじゃんとも思うし。

CA3E4936

本格的な夏に突入ということでここ数週間は洗濯機の稼働率も高し。夏物のズボンが少な目だったこともあり、買い物ついでに330沿いの青山へ。何気に330をバスで移動するの初めてだったんだけど、どれでも近くを通るだろうということで適当に乗り込み、無事到着。160円だしか待ち時間殆ど無かったしで実用性高いな。折角ここまで来たしということで姜先生に教えてもらった海産物の美味しい居酒屋さん友綱へ。お昼は(この質にしては)めっさ安いのですが、晩ご飯も普通に易かった。これだけの海鮮丼が税込み1,400円ちょっとなら十分安い。〆のアサリの味噌汁も格別。疲れが貯まってるからか、ちょっと泣きそうになった。しくしく(嬉し泣き)。

実験1「情報ネットワーク演習1」の2組目の1日目が終了で、これで忙しい1週間がようやく終わり。一部のグループで「正しく設定しているはずなのに動作しない」らしく物理層からチェックしまくってたが原因不明で。「NICが物理的に死んでる可能性」を潰すために学科LANに繋げると問題無く稼働。その後、もう一度実習用に設定し直したら普通に動きました。うーん?。

オープンキャンパスの方は、会場調整が2件動いているのだけど、回答待ちが続いてて調整できず。勝手に決めても良いんだったら決めちゃうんだけど。しくしく。パネル作って終わったので、確認含めてもう一度突っついてみよう。

意図を取り違えたままの演習は効果が半減?

木曜日, 6月 26th, 2014

PD2の前々回課題(KJ法2回目)のチェックをしてみたところ、いくつかのグループが「結論がそもそもテーマに対する回答や主張になっていない」という悲しい状況に。KJ法の演習という点では気にしなくても良いとはいえるけど、目標無しで何をやるんだという話でもある。何かしらそのグループ内で思い描いていた問題があって、それへの提案になってるなら良いという話でもあるかも。でも、そもそも「主張していない」というのは如何なものかなぁ、と。本人らが気付いてない可能性があるので、コメントとして明文化(pd2-day8-ex-memo.txt)してフィードバックしているのだけど。フィードバックのない課題ほど悲しいものはないし。

といいつつ、半分ぐらいの学生はそこまでは見ないんだろうなとも思いつつ。

CA3E4932

例によってゼミ生から連絡なし。寝てるのか電話取らず。しくしく。

全体ゼミとは別に輪読ゼミやりたかったのだけど、就職活動勢が多いのと、待ち過ぎてしまったのとでタイミングを逃したなぁ。。来年度からは様子見せずに最初からスケジュール組む(その時々で調整する)ようにした方が互いに幸せか。はぁ〜ん。

P.S.
3時限目の講義が始まる直前から数分間に渡り火災警報がなり続けました。だけど自動アナウンスに従って非難したのはビル全体で数十名ぐらい? 笑ってる学生が多かったけど、不審に思わないというのはちょっと危機感欠けてると思う。(私と名嘉さんがチェックしに行って大丈夫だと分かったから続けたけど、こういうのを一任するのも危機感欠けてると思う)

今年のデザインスクールは3日間

水曜日, 6月 25th, 2014

京大から報告が届き、今年度のデザインスクールは3日間で実施することに決定。1日余裕ができるだけで大分違う。丸一日フィールドワーク等の調査活動に割り割くこともできるし、(例えばプログラミングとかの)課題解決に必要スキルを習得する時間としても使えるかもしれないし、全員共通でデザイン手法を学ぶとかもできるかもしれない。具体的なテーマや実施方法等はまだ討論が始まったばかりですが、3日間前提で考えることができるのは自由度の面で広がるので、個人的には嬉しいです。(運営的にはコストがあがるのだけど)

ちなみに、OCC・金城さんから提案があってオンライン討論しやすいようにGithubどうかという話があり、情報系じゃない人もいるのでwikiが限界かもということでpukiwikiを設置してまったり進行してるのですが、琉大側ですらなかなかそこに入らないという状況に。うーん。忙しいと言う人に限って「対面して話したい(だけどスケジュールきつい)」みたいな現象はどうしたものか。対面しないと伝わらない側面があるのは否定しないけど、逆に便利なツールはツールとして使って欲しいのだけど。それ以前の話として前回同様に船頭多くして状態なのが一番のネックか。この点についてはどうしたいのかがさっぱり分からないので放置中。具体的にタスクを投げれば良いのかもしれないけど、そうして欲しそうにも見えないし。ううーん。