１．動くモノはどうやって作られているか
２．動くモノをどうやって作れるようになるか
奥出研の初級cc工房というお勉強会で喋った事を、またテープ起こししてみた。10日ぐらいアップするのを忘れてた。
今回は、必死でモノを作っている時に頭の中や手の先で行なっている事と、それの下準備として、どういう基礎を付ければ良いかを喋った。
061109(木) CC工房テープ起こし
————————-
こんにちは。じゃあ工房が始まります。今日はたった今アジェンダを流したが、先週が、今動いているようなモノがどうやって作られているか？だったので、今回はどうやって作れるようになるかという内容になると思う。多分。
前回PHPをやったが、今回はやらない。PHPはデータを加工してFlashに渡すのに向いていると言った。例えば、PHPでweb上のデータを取ってきて、FLASHで読み込んでビジュアライズする様な物もそのうちやる。
今日はとりあえず、Flickrという写真のサイトから検索して、写真を出してくるというのを作ってみてきた。sakasaiとかuriuとかzanmaiとか検索すると写真が出てくる。webから検索してくると、XMLというデータ形式で出てくるが、Flickrではこれを組み替えると写真のアドレスになる。PHPとかでXMLを整形して、Flashに渡してやるというのがよくやる方法。
XMLは単純なテキストデータで、その中の種類にHTMLとかもある。XHTMLとか言うらしいが。単純なテキストなのでPHPが加工に向いている。
この写真をflickrから検索する奴には、全然プログラムを書いていない。50行ぐらいでとても簡単に書かれていて、テクササイズのカメラセンシングよりも全然簡単。でも、多分これを見て同じモノをパクって作る事はできると思うけど、1から作るのは奥出研の人の9割はできない。だから、何人かは荒れ地を切り開いていく人になって欲しい。
別に奥出研はプログラミングをやる研究室ではなくて、他にも色々とやれる事はある。工作の素材探したりとか、全然違う「電車作りたい」とか言い出してもいい。口だけでなければ何やっても良いと思う。
でも俺が説明できるのは、自分がこういうプログラミングをどういう風に頭を使って作っているか？そしてどう勉強してできるようになったのか？だけなので、とりあえず今日はそういう話をします。話を聞いた上でそれをやらなくて良いと思っても良い。それはつまり面白いモノを作るのが目的であって、みんな同じ様な技術者になってもしょうがない。
＞実際技術系の人の方が少ないか？
技術系というかデザインには全部技術があるんだけど、まあプログラミングとかをやる人は少ない。やる人が少ない事をやった方が良いというのはある。例えば、教えあう機会があるわけだから、何回も電子工作を教えて、そのお返しに色んな人から違うことを教えてもらえる。出し抜く事、つまりいち早く他の人が知りたいと思うことをリスク覚悟で勉強するのが重要。後で知識が交換できるから。例えばこれから誰が卒業するのか？とかを観察すると、何をすべきかわかるかもしれない。
＞畑山さんとか？
畑山さんはまだ卒業しない。来年かな？
例えば映像の撮り方をちゃんとしっている人が全然いなくなってきた。合宿で俺はカメラの使い方がよくわからなかった。映像には色んな文法があるらしいんだけど、それをわかりやすく教える事ができたら、お返しに色々教えてもらえる事がある。まあこれから半年で研究室やめようと思っても俺は止めないけど、今後何が重要になるかを自分で見つけて時間を投入するのはとても重要。
古市＞僕は結構プログラミングとか興味あって、やっぱり応用きくじゃないですか
どういう時に？
古市＞プログラミングがプログラミングに応用きく。色んな分野で使われる。ちょっとコンピュータシミュレーションとかでもちょっと使っていたし、他にも色々。
コンピュータに何ができないかわかっていないと、別にプログラミングに詳しくなくて良いんだけど、たまに無茶いう人がいるじゃないか。人間とお友達になれるロボットとか。普通にプログラム書いた事があればわかると思うけど、相当無茶言ってるのがわかる。そのギリギリの線引きがわかってないと、これから先色々苦労はあると思う。無茶な経営戦略立てちゃったり。
生井さんはチアやってるんだっけ？あれはすごいプログラムっぽいよね。人の動きの組み合わせというか、アルゴリズム体操が頭に浮かんでるけど。
生井＞私は考えるのは苦手
まあいいや。
テクササイズとかでどうしてみんなが分からないかというと、基礎が無いから。基礎はデータ構造とアルゴリズム、そしてデザインパターン。英語とかでも「私は田中です」とかやるけど、そういうのを全くわかっていないでいきなり話すことはできない。
実はFlashやこないだのPHPもそうだけど、基礎ができている人たちがプログラミングしてきた事の中から、「こういう風にしたほうがいい」という経験が蓄積される。そのプラクティスから、最近の言語の仕様は作られている。
最初アセンブラやC言語など古い言語があった。ある程度色々な人が色々な現場で使っていたら、定石ができてきた。それが萩野先生や大岩先生がやっている様な、アルゴリズムとデータ構造の授業で教えられている事。それを勉強した人が、定石に基づいて言語を作っている。定石を知っていると新しいプログラミング言語を勉強するのが簡単になる。これが基礎の１段階目。
もう１つ、抽象的な基礎みたいなのが出来てきて、それがデザインパターン。デザインパターンとは何かというと・・・１個例を言います。
Iteratorパターンというものがある。本棚があるとして、0番目、1番目と本棚をたどっていく。普通は配列でやると思うが、なぜかIteratorパターンを使うとあまり配列を使わなくなる。最初コレを使えと言われた時は、普通に配列でやった方が良くないか？と思うだろうけど、色々な理由があってIteratorを使う。Iteratorを知っていると、FlashのDataSetオブジェクトとか、PHPのforeach文とかがわかる。
Iteratorは、例えば本棚が途中で分岐しているとか、1次元の配列で表現できないようなデータ構造の場合でも、データ構造の形を意識せずに順番に使えるように設計されている。プログラマが、データの構造の形に関係なしにイテレータでnext()というメソッドを実行すると、次のデータにアクセスできるというもの。
でも、これを知らないで、新しいプログラミング言語のリファレンスを見ると「これはnext()で次に進みます」とかだけ書いてある事があるので、仕様を見ても使い方もわからないし、Iteratorという言葉すら出てこない事が多い。こういうデザインパターンの様な常識のルールから、言語仕様が作られている。
古い言語から積み立てられた経験が、言語に戻されている。だから例えば順番にやりたい→foreachだ、と知っているとすぐGoogle調べられる。foreachという単語や用語が分からなければ検索して学習する事はできない。
そういう意味でデザインパターンは抑えておくべき。
データ構造とアルゴリズムの基礎を半分ぐらい、そしてデザインパターンをとりあえず5個ぐらい知っていると、あまりリファレンスをしっかり読まなくても「これ～～パターンじゃないか？」とかわかってすぐできる。
こういう基礎を奥出研は無視している。例えば奥野がRFIDリーダの使い方がわからないのもそういう事。PhidgetのRFIDリーダは、マイコンで使うFuseBitの概念を知らなければ起動すらできない。
そういう工房をそのうちやろうと思う。学部生卒業して院生になったら時間がいっぱい取れると思うんだけど。今16単位ぐらい必要なので無理。
アルゴリズムとデータ構造というのは、並び替えとか、SFCという文字でピラミッドを作れ、とかクイズみたいなものを何個かやってたらわかる。最低限は再帰とポインタと、それを使ったデータ構造を自分で実装するぐらいまでを勉強するべき。
でも時間は有限だし、面白いモノを作る事が目的なので、基礎ばかりやっててもしょうがない。俺はそういうコンピュータサイエンスの王道はある程度までしかやらない様にした。あまり数学が好きではなかったので、そのまま進むと計算を速くする効率を求めたり、暗号の作成とかになる。俺は数学がよくわからないから、そこに踏み込んだら勝ち目はないと思った。だからたくさんの言語の良い所を寄せ集めるプログラミングをどうすれば自分ができる様になれるか？と最初にコンセプトを持った。そうしたら、これらの基礎だけは逃してはならないとわかった。結構冷静にリサーチしてから勉強を始めた。
情報収集はとても重要。他の大学や、隣の分野を調べる。奥出研は結構まじめで抽象的なテーマをやっているけど、技術的にはアートの人がやっているのも取り込めるし、村井研の人たちがやっているようなネットワークの技術も浅くなら取り込める。
割とその分野でトップあたりを走っている人がblogを書いている事があって、それをずっと読む。俺の理解できないレベルの電子回路のblogを書いている人がたくさんいるが、読んでいる内に単語力が付いて、最近少しは理解できるようになってきた。最初は単語力が重要で、Googleで検索する時の取っ掛かりになる。良くわからなくてもがんばって読めば、「何を言っているか」わからないけど、「何を問題にしているか」はわかるようになる。各分野のトップあたりの人の問題意識を想像する。
こないだ学会に行って思ったのは、奥出研でやってるとどの話題にも絡める。英語話せないけど。
＊＊＊＊
Flickrは写真をアップして、tagを使ってPhotoSet作って友達と共有して、コミュニケーションできるSNS。SNSだけど写真を前面に押し出しているからあまり自己紹介とかは目立たない。proアカウントにすると年間10ドルぐらいで毎月2GB使えるし、月が変わる毎に0に戻る。アップロードも、flickrUploadrとかjUploadrが使える。YouTubeと違って、まとめて何枚も写真をアップロードできる。文字でtagを付けられて、amayanやtakacみたいな人名とか、zanmaiやshonandaiみたいな地名でも何でも検索できる。
写真のSNSみたいなんだけど、写真共有サービスと言っている通り中で閉じていないで外に開かれている。blogに貼り付けたり、blogに自分の最近撮った写真を小さく表示するwidgetや、他のSNSから写真を読み込まれていたりもある。
奥出研のチームのGroupもあるし、regunaryというフットサルチームのGroupもある。cameratossといってカメラ投げる人が投稿するGroupもある。
-35:10
俺はプログラミングは得意ではなかったけど、ある時パァーっと開けてしまった。高校の頃VisualBasicをやったけど、チュートリアルが面白くなくて3日でやめた。意味が無いと思った。
でもプログラミング入門の授業で、自分の実力では無理なものを作ろうと思って、ずっと考えて寝ないでやっていたら体育のフリスビーの時に、考えていないのにパッとバグがわかってしまった。考えたくないのに頭が勝手に動いてしまう状態になっていた。その時から開けた。
俺は基本的に怠けるから、やれと言われないと勉強しない。でもそこで学習して、やらなかったら留年する状態にしたらどうか？と思った。後先考えて、このまま何も特技が無いまま2年生に進級するよりも、無理を越える自分の性質を信じて無茶な授業を取ったらできるようになった。
小人現象というのがある。こないだ八木さんにも起こったらしいが、悩んで寝て起きたら分かっている現象。みんなそれはよくある事だと言っている。小人現象を使いこなせると凄い。夏休みはかなり無茶なものを作らないとならなかったから、一日を2分割して、2回寝るようにした。まあ寝るというより寝落ちするぐらい疲れていただけだが、それぐらいせっぱ詰まってやると、不思議と自分でも無理だと思っていた事が解決できる。
実際プログラム書いたり、難しい問題を解いている人間の頭の中というのは不思議な事が起こっている。気が付いたら小人が解いていたり、気が付いたら１日経っていたり。去年気が付いたら30時間経っていた事があった。その間リンゴしか食べていなかった。段々そういう状態に入れる様に自分を作るのは重要。しかし、その考えないでも考えてしまうという状態になるには、基礎が身体に染みついていないとできない事。
どうやって作れるようになるかは、最初基礎がある。ある程度まで行ったら毎日トップの人のblogなどをチェックして、話の流れをチェックしておく。議論のポイントや、使いやすいツールなどを抑えてメモを溜めていく。そして小人現象を使って突破する。
最近設計図を書かないのが流行っているらしい。作っているプログラムが設計図だと、みんな言っている。厳密にこないだのクラス図などを描いて、作りながら動かしながらやっていくという方法があるけど、段々色々な設計図が全部見えてくるというのもある。一番大きいのはシナリオで、そのモノが人をどう幸せにするかが自分の大きなモチベーションになるが、同時にクラス図みたいな抽象的な図も見えるし、同時に電子がどう動いているかみたいなイメージも見える。頭に何か見えたらスケッチを描いたりする。
＞設計図を描かなくてもわかる様になったという事か？
多分頭の中に描いている。設計図は１個出るのではなくて、同時に10種類ぐらい見えているもの。でもクラス図と回路図の間はつながらない。それは頭の中でつなげてるだけなので、図の描き方も工夫しないとならないのかもしれない。
途中でスケッチみたいなのはたくさん描く。回路図だって、部品の配置図とはまた別だし。
設計図を描くなと言っているのではなくて、初めから詳細に書けるわけが無いと言っている。例えば理工学部の人達は、トランジスタはこう使う、とかナントカコントローラはこう配線する、とかは習ってからやる。でも、俺みたいなちょこちょこっと色々つまみぐいしている人は、何と何を使うべきかはわかるが、どう線をつなげば良いかはわからない。
授業でも、いきなり「回路図を描いてこい」という電子おもちゃ設計論というのがあるが、一回使った事が無い部品は詳細な回路図なんて描けない。部品をリストアップする事ならできるけど。
やり方をわかっているモノだったら回路図を描ける。しかし中の詳細な仕組みが分かっていないと描けない設計図がたくさんあるので、そういうのは飛ばしていかないと時間が足りなくなる。
そういう時の考え方として、富豪的プログラミングというものがある。製品レベルではありえないぐらいに、リソースをガンガン使っても構わないという考え方。
最近になってパソコンのスペックが上がったり、部品が安くなったりしている。CPUの最適化をしないでとりあえず最適なユーザインタフェースを作るとか、あとは最近はCPUが良くなってコンパイル時間が短くなったので、今まできっちり設計図を描いていたのだけど、逆にどんどんコンパイルして試していけば良いじゃないか？という考え方。
具体的には、電子工作の場合では部品は100円もしないモノばかりなので、を使い捨てだと考えて、富豪的に壊れる事を織り込み済みでどんどん試していく。
電子工作の場合では、どうやったら壊れるか？を知ってしまえば、壊れないようにする事ができる。普通に勉強した人は三端子レギュレータの仕組みの後に、使い方を勉強すると思う。でも俺は壊れる方法と、壊れたときの回路の焼ける嫌な匂いと、こうやったら動くという実例を知っている。オームの法則とか理論はわからないけど、動かし方は知っている。
一番酷い例では、傾斜センサーが調子悪くて、俺が指で触っていた時だけ動いていた。だから指の抵抗値を測ってそこに抵抗を刺したら完成した。
滅茶苦茶にやっている様に見えるけど、基礎は抑えている。デジタル回路の場合、基礎はオームの法則ではない。
マイコンの出来る事は４つだ、という事を理解している。マイコンが出来ることは、電流を出す事、電流が入ってきた事を検知する事、電流が入っている量を計算する事、時間を計る事の４つ。
そう思った理由は、身の回りの物がそれだけで実現できそうだなと思ったから。直感で思ったけど、理工学部で4年間で学ぶカリキュラムでやったら絶対に間に合わないので、直感を信じて抑えるべき基礎だけ抑えて、後は事例の積み重ねでやるのがインターネット時代の勉強方法。何がわからないか、何を勉強すべきかがわかれば、Googleで検索して沢山の実例を見る事ができる。
俺らが全てまともにやっても個々では敵わない。絵を専門にやっている人には絵で敵わないし、プログラム専門にやっている人にはプログラムで敵わない。でも全部やらないとならないのが俺らの分野であるモノづくり。
しかし全部手を出そうと言っても4倍動けるわけではない。となると効率よくやるしかない。だから積み立てて行ってる専門家の話がギリギリわかる程度の基礎が必要だし、他の人よりもリサーチが必要。毎日1時間ずつ監視の目を光らせるし、毎日1時間新しい事を勉強する。
はてなブックマークとかでメモを取る。例えばずっと前にFlickr WebServiceというのがあるな、というのを見つけて、基本的に何ができるのかを調べてメモを作っておいた。検索結果がXMLで返ってくる事がわかった。また、FlashでどうやればXMLをparseできるのかな？というのも今年の9月にメモした。FlashでXPathが使えるというサイトとライブラリがあったので、そこで調査を止めた。
そのメモがあったので、昼の３時ぐらいから初めて1時間ぐらいでこの２つができた。
・XPath4AS2でXPathテスター
・FlashでFlickr REST-APIを呼ぶ
リサーチしてメモを溜めるのは重要。なんとなく理解する程度で、１年後に自分が読んだら理解出来る程度のメモを溜めて、暖めておく。そして引き出してきて、組み合わせる。
新しいことをやろうとしても単語がわからなくて理解出来ない。トップを走っている人のblogを流し読みし続けると、単語力が付く。新しいプログラミング言語を勉強する時は、有名な人を３人ぐらいピックアップしてblogを読むようにして、３ヶ月ぐらい読んでいるだけ。
すると、どういう言語の特徴があるのか、そしてどういうツールで開発しているのかのメモが溜まる。それを見て自分の環境を作る。基本的に人の真似しかしないのは、時間が無くなってしまうから。だから俺は既に誰かがやってる事しかできないが、多分創作している範囲は凄く広い。色々調べたが、webサービス、システムプログラミング、アート的なGUIのデザイン、電子工作を４つ全部組み合わせている人はあまり居ない。３つまでは結構居る。
——00:59:40 ここから実習——
**FlashとXML, XPathについて**
——01:20:10 ここまで実習——
＞達人がやっている事がどういう事なのか垣間見た気がする
次の話も考えていたけどマニアックすぎるかもしれない。
全体性を保って作りたいというのがある。それは何故かというと、部品で作ったら違う物になってしまう。しかし手は2本しかないので、一度に作れる場所は1カ所しかない。ではどうやるか？
上手く作っていかなければ、傘を回した時どれぐらいの速度で写真がスクロールするかとかを微調整できない。決めうちで作る事は簡単だが、インタラクションの微調整ができるコードや回路の書き方がある。
最近参考にしているのは、webの人達が俺と同じように4つぐらいの処理系を使って作っている事。その人達がどう考え、どう設計して作っているかを調べている。テスト駆動開発という、agile的な、設計図を描かない素早い開発手法の一種がある。Test Driven Development(TDD)と言って、テストを作ってからプログラムを作るというもの。for文がどうとか、細かいアルゴリズムの所ではなくて、こうやったらこう動くという定義だけ書いて、後から中身を書く。メソッドの中身を描かないで、メソッドをある程度揃えて、後から中身を書くという様な事。
その方法論をツール化した、達人が頭の中で行なっている事を道具化したテストツールというモノがある。でもまだあんまり調べてない。
でも目星は付いているので、俺らのやっているようなデザインにも取り入れられるだろうと思っている。
もう一つ、モジュールで作るといのがある。Pileusは最初Flashでカメラを扱おうと思っていたが、画質が悪かった。つまり用件を満たしていなかったので、違う部品でカメラを作らなければならなかった。また、回転のセンシングは加速度センサーという任天堂のWiiとかに入っている物でやるか、もしくはジャイロセンサという模型飛行機やヘリコプタが機体を制御する時に使うセンサーのどちらでやろうか？というのを、どちらでも切り替えられるように分割して設計する方法がある。
どういうレベルでモジュールを切り分ければ良いか？というベストプラクティスがある。そういう開発経験を上手く形にすれば、効率的な開発を自然にできるツールになるのではないか？と考えている。
要するに、色んな工夫をしているが、工夫を言葉にして説明し難い。だから、言葉にして説明するのではなく、良いモジュールの切り分けになりやすくなる「ひな形」作り、そして「こういう所に気を付けたら良いよ」、というプラクティスをまとめたい。
でも良くわからない部分がかなりある。
たくさん設計図が頭の中に見えている、という事も関係してくると思う。
テクササイズは、「こうやったら動く」というのはやってるけど、同時に理論的な背景も少しはやった方がよいと思う。例えばこないだのwebcamを使った画像解析での重心の取り方も、Microsoftが画像処理の技術文書を出しているので、少し読むとテクササイズでやったアルゴリズムの欠点がわかる。
単純に全てのピクセルを走査して重心を取ると、認識される物体が２つあった時は、２つの物体の中間の何もない所が重心になってしまう。そういう時はラベリング処理をすると、隣接するピクセルのみを一つの物として認識するので、２つ別々に物体の重心を取れる。
ラベリング処理という考え方を聞いたことがあれば、画像処理を行うライブラリを使うときに「ラベリング処理」という設定項目が絶対にある。それが何だかわかれば簡単にラベリング処理ができて嬉しいのだけど、知らなければ「番号つけるのかな」とか勘違いして遠回りしてしまう。
どこまで努力するか、そして払ってしまう時間などのコストは常に考えながら「基礎」を身に付けなければならない。