2006年9月29日金曜日

history



Gimiteがやってるのをみてなんとなく、ちなみに.bash_history



80 (echo


55 ls


48 cd


25 cat


24 less


22 printf


19 killall


18 emacs


15 grep


13 echo


10 sudo


10 fetch


10 ./lighttpd


8 top



(echoが多いのは、きっと



(echo OPTIONS / HTTP/1.0;echo ;echo ;sleep 1)|telnet hogemogeo 80



とかやってるから、printfもほぼ同様の理由。


ま、結論としてろくな事につかってねぇ。。。





2006年9月27日水曜日

IVRCの勝ちかた@東京大会



なんだか、今年の作品故障率たかかったです。


自分らのコンセプトを示すのが目的じゃなくて作品を完成させる事が参加の目的になってしまっているチームもあるような気がしました。


インタラクティブ作品は体験できてなんぼですちゃんとうごかしましょう。


個人的な見解だけれども作品を動かすためのテクニックを。。。。


ミニマムサクセスを設定する


プロジェクトに遅れはつきものです。大会までに当初構想していたもの全てができるとは限りません。



あなたの伝えたいことはなんですか?



それを念頭にして、最低限どの部分だけ完成すれば「伝える」事ができるかを考えます。


そのための最小限の装置をつくって展示することがミニマムサクセスです。


無論IVRCである以上口頭発表での空想ではなく、実際に体験できることが重要です。


たとえば、自動車の展示を考えてみましょう。


その自動車の走行性能を伝えたいのならば、最低限ちゃんと走る事が必要です。


カーエアコンもオーディオも付いていなくても大丈夫です。(ついている方が望ましいですが)


その自動車の居住性を伝えたいのならば、走る必要はありません。


逆にカーエアコンもオーディオも最高の完成度が求められます。


(ただし、ミニマムサクセスが最初から思い付かない場合も多いです。


作っているうちに、だんだんとその作品の肝が見えてくる事だってあります。


その作品の肝をちゃんと責任もって見続けるリーダーがいれば最初に作りながらミニマムサクセスを考えるのも有りだと思います)





ミニマムサクセスを取り入れた、プロジェクト計画


さて、ミニマムサクセスを考えたとして、どのように作品を作成すれば良いでしょうか?


基本的な原則は



いつでもミマムサクセスに戻れるようにする



です。


これは製作中に頓挫したら、バックアップとしてミニマムサクセスに戻るという意味もありますが、


もっと重要な事は、ミニマムサクセスのためのシステムをテストしつづけると言うことです。


当然ながら作品を作り初めて初期のうちにミニマムサクセスは完成します。


それに、追加の機能を加えながら作品の最終形態を作り上げる事になります。この機能追加の期間中ミニマムサクセスシステムは連続動作テストを行っている事になります。


IVRCは御存じのように二日間お子さまの攻撃に耐えながら作品を体験可能な状態にしておく必要画あります。


装置も時間と共に故障したりもします。そんな時であっても、作品を作っている間中連続動作試験を行ってきたミニマムシステム部分は故障しないか、故障したとしてもチームメンバーがミニマムシステムの修理の仕方に習熟しているためにすぐにミニマムシステムでの稼働状態に持ち込む事ができます。



どんな良いインタラクティブ作品も動かなきゃ単なるでかい箱です。



最低限の動きができる事は重要です。








また、ミニマムシステムに機能追加を行っていくと言った事からわかるように、重要度の高い部分から作成していきます。上記の理屈どおりに行けば、展示中に故障するのは作品の本質は関係ないどうでも良い所だけになるはずです。





メカのアイディアを考えない


IVRCでの故障で一番多いのは機械系です、次にセンサー・電気系です。


多くの場合、模型部品を組み合わせて作った機械等がよく故障します。


なぜでしょう?模型がへろいから?


それもあるでしょう、予算の都合が付く限り直線運動したいならリニアアクチュエーターのユニット


を買ってくる等の処置をとりましょう。


予算がない場合、特殊な動きで汎用品が使えない場合はどうしたら良いでしょう?


今まで数百年と蓄積された機械の組み方をぱくりましょう。


無論、機械系じゃない人間には難しく思える事でしょう。


でもヒントは日常に一杯ころがっています。


まず、自分が作りたいものと同じ動きをする機械をさがしてきましょう。


そこに、壊れずに動き、簡単に作れるヒントがあります。


様々な動きをする機械の一覧として「メカニズムの事典」等がありますので一度目をとおすのも良いと思います。


電気系も考えない


電気系もほぼ同じ事が言えます。電気の場合はリファレンス回路と呼ばれるものがあってそれを使うと大体はうまくいくのですが、、、やっぱりやりたいことによってかなり違うものをつくらざるをえないところがあります。


基本は、以下の通り。




  1. 回路を基本的な機能のブロックに区切ってしまいます。(例えば、光センサー部、AD部、マイコン通信部等)

  2. それぞれのブロックに関して本やで似た回路を紹介しているものを探します。

  3. それぞれのブロックを結合します。


下手にがんばって、ブロックの壁を取り除いて部品点数を減らそうなんてしてもはまるだけです。


よっぽどの事画無い限りやめましょう。





いざって時のムタセンサ(黒子フィードバック マン・マン・マシンインターフェイス)


私の所属していたロボット技術研究かいには、「ムタセンサ」と呼ばれているデバイスがあります。


それは、なにかセンサーが故障したとき、アクチュエータが故障したときにそれらの装置を代替


する万能の装置です。一般には「人間」と呼ばれる装置です。


どんなものだって故障は免れません。でも大会は2日間デモをしつづけなければなりません。


そんな時「故障中」の札を掛けて完全停止してしまっては負けです。確かに完璧な作品を


体験してもらうには「故障中」の札をかけて修理するのも良いでしょう。でもそれをみた


お客さん、審査員はどう思いますか?


故障したら故障した部分を人間が代替しちゃえばいいのです。人間はかなり自由度が高い


センサー・アクチュエータです。そうやって人間を装置に組み込んで展示している裏で


他のメンバーが修理すればいいのです。


そのためには、装置の中の各モジュールを手動で操作できるようにする必要があります。


手動で操作するための機構を組み込むのは二度手間のように感じるかもしれません。


でもよく物を作っている所を想像してください。最初から全モジュールを一気に結合しますか?


おそらく単体でそのモジュールが動いている事を確認してからつなぐでしょう。


単体での動作確認の時には人間からデータを入力するなりして動作を確認するのが多いと思います。


その単体動作確認のための、人間が操作するインターフェイスを会場に持ってくるだけで


いざって時の「ムタセンサー」用アダプタになるのです。


設置環境にたいしてロバストに


IVRCの会場は、研究室に比べて光・音・風・電波的に不安定です。


それは、人が通るのもあればとなりの作品から出る騒音が原因だったりします。


従って、音を使うものならあるていど柔軟に音量を出せるスピーカーが必要ですし。


光センサーを使うならば、遮光カーテンなどを持参する等、ちょっとやそっとの


環境の変化に対応する準備が必要です。


さらに深刻なのは電波で、電波は遮るのが難しいので最悪有線での通信に切替える


準備をしておく必要があります。


搬入日の話


さて装置搬入の日、まずやることは?


隣近所の装置の設置場所を確認し、音・光・風についてお互いに影響ないかを確認します。


この確認は早ければ早いほど良いです。もしどうしてもとなり同士に置くのがまずい作品があればスタッフに相談すれば席替えも可能な場合が多いです。


次に、いかにお客さんに体験しやすいレイアウトを作るかを考えます。


正直いってもろにとなりのブースの影響を受けます。おとなりさんと話し合って


お互いにどういう風に客を流したほうが両方を効率よく体験・見学してもらえるかを考えます。


「体験」のほかに「見学」があるのが味噌です。


お客さんは普通いきなり体験しません。誰かがやっているのを見て、興味をもって初めて体験します。


なので、基本的には作品の回りには人垣ができる事になります。


その人垣をどこに作るかを考えたら、次はその人垣を見て「何をみんなで見ているのだろう?」と


遠くから見ている人をターゲットにします。ここで、説明プレートが役に立ちます。


説明プレートはあくまで人垣の後ろに置くのです。作品の前に置いても大して意味はありません。


(無論お客さんが少ない時は作品の前でも効果ありますが)


このようにして「なんか人垣があったけど、なんだかわからないからスルーしてきちゃった」という状況を防ぎます。





当日の話


当日は、正直いってノリの勝負と言った所もありますが、基本的な所をおさえると楽です。


朝:客が少ないとき

前述のようにお客さんは始めから体験しようなんて事はしません。まず、自分で軽く操作しながら待機します。


お客さんが来たら「笑顔で」、「やってみられますか?これは、XXXができるですよ~」と声を掛ける。


で、ここでのXXXが肝です。あまり事象について言ってもだめです。


例えば、ここにバトンを振るとそれにあわせて噴水が出る作品があったとします。



ダメな例:


やってみらますか?このバトンを振るとそこにある噴水が吹き出す用になっている作品なんですけど・・(以下略)




改善例:


やってみられますか?こちらの作品は噴水を意のままに操る作品なんですよ。(バトンを差し出す)



実際の操作方法なんてものは、体験しながらでいいんです。「こんな風に楽しい」作品なんですよってことを一言いえばOKです。


昼:客が多いとき


体験者の世話をする人とは別にもうひとり解説役をつけましょう。


体験者の世話をする人は、回りのギャラリーの中にやりたそうな顔をしている人がいたら


「やってみますか?」っと聞いてあとはその作品と一緒にその作品の演出を行います。


体験者を楽しませるための演出家であることを忘れてはいけません。


その作品で楽しむための最高の楽しみかたに誘導してあげます。


先ほどの噴水の例で言うならば、「もっと、ガツンと振ってみてください、噴水もそれに答えてくれますよ」というように、誘導してあげます。そのためには、自分で試してどうやったら楽しいかを研究しておく必要があります。


あくまで、楽しむのをサポートするのがお仕事です。


技術的な事を紹介する必要がある人は自ら聞いてくるので、そのときにいつもの理系大学生のノリで説明すればOKです。


そして、もう一人の解説役の仕事はギャラリーに対する説明です。


もちろん、何ができる作品なのかを説明する必要があります。


そのときにお客さんの視点と自分の視点をあわせるのが大切です。


複数人ギャラリーがいるので大変ですが、おおにして目の前で作品を体験している人をみています。


その体験者の行動を見ながら、「いまあの人がバトンをふったから、それにこたえて噴水がでたんですよ~結構きれいでしょぉ?」といって話をふっていきます。


興味をもった人は、ちょっとおおげさな相槌をしたり、操作方法等について質問してくるので体験させてあげましょう。


また、歩いてきてちら見したお客さんの足を止めるのも解説役の仕事です。



「こんにちわ~、こちらの作品はこんな風に(だれかが体験中の作品を指す)噴水を意のままに踊らせる作品なってます」



といった感じで声をかけます。そこで歩いて行ってしまうのは仕方ないですが、足をとめたらすかさず「よかったらどうぞ~」と声をかけましょう。


お客さんだって初めての方が多くて、この手のコンテストの作品を体験するのにはなれてないです。


誘導してあげましょう。


なれてくると、既に見ているギャラリーに体験者をネタにして解説しつつ、ちら見した人に声をかけて


短く作品を説明してギャラリーに加えるという事ができるようになります。

















以上とりあえず、思い付いただけ書きました。


異論・反論・抜けの指摘等コメントにお願いします。





2006年9月26日火曜日

用語:NOD ネタ指向開発



ふと今朝おもいついた用語。でも私はこれを目指している気がする。あとで整理しよう。


でも音的にはNOAがいいな。





2006年9月25日月曜日

偽科学



http://www.amazon.co.jp/exec/obidos/ASIN/4861990424


こんな本が出てるらしいけど、うちの実家でもいくつか、かなーり怪しい偽科学にはまってるんだよねぇ。


お金の被害なら、勉強料ってことで水に流せる事もあるけど、健康被害は確かにやばいねぇ。





まぁ、ひとつ言えるとするなら、人より長く生きたい・美しくなりたい、とか普通の欲望でも


あまり欲の皮がつっぱってくると、それに漬け込んで来る人が出るってことなのかなぁ?





髪型をかえた



眼鏡もかえました。


旧知の人からみるとびっくりみたいです。


とりあえず、ちょっと恐い人になってしまったらしいですが。。。。


ちょっと恐い人って原点回帰な気もします。





2006年9月22日金曜日

修羅突入



あ~やっちゃったよ、会社で修羅突入。


来週から残業食をもちこまなきゃいけなさそうなスケジュール。


どうせコンビニで買ったパンなんだよなぁ。。。


弁当作ってくれる嫁さんが居る奴がこのときばかりはうらやましい。


久しぶりにまじめに仕事すっかぁ。





2006年9月19日火曜日

2006年9月10日日曜日

実はプログラミング嫌い?



なんだか、数式いじったり、ひさしぶりに勉強したりしてるんだけど。。。


プログラミングしてる時と同じぐらい楽しくて、肉体的にはかなり楽。


最終アウトプットを出したい気持ちはあるのだけれども、なかなかコーディングに


手を付ける気が起きない。


だれか助手募集。(ぉ


ま、数式いじったり本読んだりするのに飽きたらまたコーディングするかな。


昔は、プログラミング->電子工作->工作機械の掃除->工作と飽きたら


気分転換するものがあったからよかったけど。。。


最近ないしなぁ。


工作機械の掃除とか、単純な工作とか何も考えなくていいから


良い気分転換だったのになぁ。。。無心に集中できる雑用があるってのは


幸せなのかもしれない。





2006年9月9日土曜日

いまさら線形代数



アルゴリズムを高速化しようとおもうと、やっぱり既存のアルゴリズムを参考にせざるをえない。。


ということで、、、いまさら線形代数の教科書をひっぱりだす。


でも、学生時代に線形代数がなんでこんなに苦痛だったのかが理解できないほど気楽。


趣味でやってるからってのもあるんだろうけど、学校の授業はなにかまちがっていたのか?


それとも、私が成長したのか?


自学自習ベースががいちばん効率的なのかもね。





2006年9月6日水曜日

電子入札



実家で電子入札クライアントのどうにゅう !


ってのをNTT社員がやってるらしい。


ldapプロトコルがとおらねぇ~ゴルァって電話がかかってきたので、ポートフォワードをかけてあげる。


てか、どこのネットワークもNAPTでインターネットにつないでるとおもうなでげす。


こんな危なっかしいPC群をNAPTで外にだせますかって~の。





ブラインドデコンボリューション



うーん、なんだか静止画像1枚から、同心円状のボケ関数なら抽出できることはわかりました。


一応数学的にさっくり算出できる。


でも、怪しい、簡単すぎる。なにか罠がある?


ノイズに関しても検証くわえてみないとなぁ。





2006年9月3日日曜日

それにしてもゼロシート法マイナーすぎ???



下の研究の元になったゼロシート法ってのがあるんだけど。。。国内だと研究すらも少ない。


やっぱり、高次解を求めるのがネックなのかなぁ?


とりあえず、熊本高専、大分高専、京都工芸繊維大学ぐらいしかなかった。。。。


さすがに微妙すぎなのか?





2006年9月1日金曜日

学部時代の研究 Part2



学部時代はn x n pixの画像のでこんぼりゅーしょんに2n乗方程式をとかなくちゃいけなくて。


32x32pixでも64乗方程式っていう精度的に辛いものを解く必要があった。


でも、冷静に考えると画像を2n枚用意すればいいことに気がつく。


そうすれば単純な引き算の繰り返しでもとまって(°д°)ウマー。


32x32pixの画像のデコンボリューションには64枚の画像があればOK.


しかも64乗方程式を解くよりはるかに速いはず。


そんな思い付きも後で検証しなきゃ。


因みに下のほうでかいていた、回転にすれば。。。ってのはあらかたよさそうだけど。


一般にXXであることをいうのは簡単でも、XXでないことをいうのは大変という法則にどっぷり浸かった世界になっちゃいました。


まぁ、あとは計算して結果がでればってことでしょうか?