PROSYM 50にいってました

ここ4日ほど、プロシンに学生スタッフとして参加してきました。

端的に言うと、デモを準備していかなかったのを超後悔した。あれだけの面子が目の前にいるのにねー

感想類

個人的には招待公演がやっぱり面白かった。。あと最後のviscuitかなぁ 結構初期から追っているので、これが世間でウケてるのが個人的には(自分のことのように)うれしい。

以下個人的な感想。

  • qmail.jpのDNSレコードが面白い(dig qmail.jp MX)
    • 無理やりTCPDNSクエリさせる(tc bit立てる)とbotはクエリしてこないらしい。OS標準のリゾルバを使ってない?
  • 『構成的アルゴリズム論』という言葉を知らなかったので調べる
  • DelFEMは気になるので追う( http://delfem.sourceforge.jp/ , http://d.hatena.ne.jp/etopirika5/ )
  • 手抜きDDR-SDRAMコントローラの反応が上々だった。masui氏が微妙に興味を示していた。
  • Winampのvisとかcontext free artで使うような式を集積して多言語に提供するサイトを作るとウケるかもしれない(メガデモに出てくる式講座)

IRCヒット賞

決定しづらい(大賞なし)。

候補

  • 花嫁候補

17:46 (***) なんだっけ 吊橋効果
17:47 (***) つり橋で合コンするとみんな美人に見えるあれか

  • fnami氏のブラウザがNetscapeだったときの某氏の反応

17:51 (***) Netscape??

  • 形容

11:24 (***) いま緩やかに止まったね
11:24 (***) うん,ゆるやかだった

どこまでがプログラムか論争

後の宴会自由討論でmasui氏と喧嘩になったのは、どこまでがプログラムなのかというあたり。

料理のレシピだってプログラムで、積み木の積み方はプログラムでない あたりがmasui氏の主張。僕はあまり立場を明確にしなかったのだけれど、積み木の積み方だってそれは情報なのだからプログラムだと思う。積み木そのものは機能を果たさないから微妙だけれど。

もう一つの争点としては、ソフトウェアは生物のように連続的に進化するしかないから、不連続な進化はあまり良いアイデアでないという視点。僕はソフトウェアは生物と違って不連続な進化が可能だと考えている。

あと、関連するのはUIのためにOSを作るのは(すでに動くものがあるんだから)無駄だという視点で、個人的にはOSを作るコストのほうが、UIデザインを既存のOSで実現するためのコストを下回っていると考えている。例えば、マウスを二つ使ったプログラムをWindowsAPIで作るよりも、直接USBマウスをlibusbなりなんなりで制御してしまったほうが簡単だし、それは現実に機能する。

ぜひユビキタスコンピューティングをということなのでちょっと考える。

世界中に配置したセンサの情報を一箇所にあつめて一つのインターフェースでアクセスしたいという需要がまず存在して、そこからどのようなインターフェースを設計していくかというところが途上。

『3分の調理時にYoutubeの3分の動画を表示する電子レンジ』をQuartz Composerで作れるか問題 が明確に立場の違いを表している気がして、個人的には、画面が付いてそれがPCから制御できるような電子レンジが市場に存在しないんだから作れないという立場。しかし、そういうものが存在すれば作れるんだから作れるという立場もある。

共通の認識は、そのようなプログラミングが思いつくのと同じスピードで出来なければならないという点。アプリケーションなんて存在しなくていい。ただ、それを既存のOSで実現できるか否かは見解が分かれる。

設営の反省点

  • 電源タップはほどいてから(ねじれてるのを直してから)使う
  • 電源タップはシリアルに配線する = 前後の席を連続して接続する
  • AirMac Extremeに統一したらいろいろ問題が出た。WPAの一時期の実装は出来損ないが多い。
  • 学生バイト定位置を設定すべき
  • スライド先頭に色検証を入れる
  • 一日の頭にコーヒーが無いのはしかたない。。(夜の間は電源切ってるので)
  • Q&Aのときに、QやAをIRCに書くべき(あとで読んでもわからない説)

境界

今年の夏のプロシンのテーマが「境界の情報科学」というテーマなので、個人的な研究テーマであるところのunbarriered programming(仮)について何か話すつもり。

unbarrieredはちょっとかっこ悪いのでもうちょっとそれっぽい名前を今は考え中。

要するに、思いつきの速度でプログラミングを可能にする(プログラミング)アーキテクチャであって、それを実現するために必要なQoSなどを実現するためのカーネルデザインやプログラミング手法について。

barrieredというのは、今のWindowsに見られるような、

  • Windows XP には(SSLライブラリとして)高度な暗号化アルゴリズムが搭載されている
  • しかし、それをつかって(PSKで)暗号化するような簡単なUIは殆ど無い
    • おそらくZIPフォルダの暗号化程度
  • つまり、高度な暗号化はUIが存在しないせいでエンドユーザからは使用できない

といった状況のこと。これを無くすための技術。ほかにも、GraphEditで解決できるような問題がアプリケーションとして提供されていたりとか、MacOS Xとかに稀にある「それスクリプトで一発だろ」系のシェアウェアをどうにかする話でもある。

いまのところ「プログラマと一般人の境界」みたいなタイトルを予定。

もちろん、一般的な突っ込みとして「思いついたような絵さえ描けないのに、思いつきをプログラミングするなんて可能なのか」のような議論があるだろうけれど、そういうのは最終的にも程度問題で、今、大事なのはお絵かきで言うところのMSペイントに相当するツールすら今のOSには無いこと。

"最低でも"、積み木程度のインタラクションが可能でないといけない。積み木で作った汽車が汽車として機能するかどうかは重要ではなくて、汽車のようなものが作れるレベルをまず目指す必要がある。