日時：　4月11日（土）　13:30～場所：　馬事公苑（仮）　※木曜日中に決定します、すみません。会費：　1500円（余ったら返却します）持ち物：　ご飯・飲み物は用意いたしますが、これが食べたい！これが飲みたい！というものがあれば、ぜひご持参ください。
by　koga

とのことですが、人数LIMITが100人になっていたり、今予約している人の2割が関係ない人だったりして謎な感じになっている。

さすがに電源は無いと思いますよ…

10月半ばごろに、適当に飲みながら？話した事を郡山さんがテープ起こししてくれたので

コピペしてみる。

ただし、ほんのちょっとだけ（暴言とか）編集した。

あと、俺は普段語尾は「である」調ではないんだけど、郡山さんが文字起こしするとそうなる。

—————-

情報世界と物理世界を同じもののように、タコの足のようにくっつけて、ひとつのものとして作る必要がある。そのための考え方であり技術の選び方を考えなければならない。「ウェブのサービス」などのように分けて考えるものではなくて、全てが一つのものである。「ウェブサービスを作りたい」と言うのではなくて、何か作りたいものの中の部品としてウェブサービスがある。

プログラムを書いている時に試行錯誤している。プログラミングは実装ではなくて、プログラムを書くことが設計である。書いてすぐ試して、というスケッチしているような中でデザインをしていく。

Pileusをつくっている時に、いきなり「こういうもの」として頭で描こうとしても、詳細に踏み込めない。作った後の今だったら、こういう傘があってこっちに振ったらこうなって歩くのにあわせて地図が動いて読んで、表示が変わって、撮影したものがアップロードされた時に自動的にタグがついて、などは分かる。

それらは、つくってみるまで具体化してなかった。「flickrの写真が出る」とかまでは言っていて、それがどう出るかとかどういう時に出ないのかとか、そういう条件を叩き出さないといけなかった。しかし、作らないとそれができない。

なぜ作らないとできないか。それは、人間の言葉は表現力に限界があるからである。普通の人間の言葉は、同時に並列にものごとが起こっていることとか、凄く複雑な論理構造（それとこれ、かつ、そうでない、など）を表現することができない。

この２つができないから、最初からPileusの完全な設計図を書くことができない。そのため、簡単にユースケースを書いた段階からどんどん作る必要がある。作ることが設計図を書くことになる。

作らないとインタラクションの詳細が分からない。むしろ、例えば影電話の場合、作ってすぐコンパイルして実機で影の行灯の表示やぼかしをかけたほうがいいなとか、ゆらぎを入れた方がいいなとか、やってみたら無い方がいいなとか、そういうことが分かる。そういったことは絶対に試しながらじゃないと分からない。設計する時には、人間の言語では表現することができない。設計はコンピュータの言語で行う。

コンピュータの言語じゃないと設計できないという問題があるから、たくさんスケッチしたあとにスケッチしたり、最後に彫刻したりする。素材を細かくしながらしていく。

音楽の人だったら、楽譜だったり楽器だったり、最初口笛で口ずさんでメロディを考えたりとか、道具を使い分けながら詳細に入っていく。

それと同じように、詳細なデザイン・設計を決めるための「思考するための道具」なのがプログラム言語である。

といった観点でいろいろ選んだ結果、最近言っている４つ、すなわち（１）インターフェースのGUIの部分、（２）タンジブルコンピューティングを行うためのフィジカルコンピューティングの部分、（３）ウェブのサービスを作るためのMVCフレームワーク、（４）その３つをつなぐタコ本体の部分のC#の部分。それが必要である。

ここで、３つの足だけにしないで、真ん中のタコ本体も入れないと、両側からくるデータの流れをさばききれなくなる。それは、僕が経験上知っているだけだが、するとC#じゃなくても微妙に弊害があって、重い処理をするところが真ん中にないといけないのかなと思っている部分もあるが、そこはまだ分からない。

というのも、Pileusと同じ思想で影電話を設計したらうまくいかない箇所があった。何を表示するかをC#が決めて、Flashはどう表示するかを決めることに専念させようとしたら、Flash側で画像処理してるから何を表示するかFlashが自分で作っていたりしている。ここのポリシーが崩れてきたので、すこし考え直す必要性を感じている。それはむしろ設計方法論の完成度を上げるためのいいことだと思う。

それで、僕らが何回も書いたり書き直したり設計していくことのためにこういう言語を選んでいるということがあるが、FlashとかProcessingといった言語は、エンタープライズの世界とは全く対極にある。ソフトウェア工学とかで博士号を取るような凄い人の記事とかを見ると、「大規模ソフトウェア10万行」などと書かれている。

10万行という異世界の話である。しかし、僕らは3000行くらいで既に大規模である。1万行あったら超凄い。パイレウスは全部併せても3、4千行しかやっていない。

なぜそういった違いが起こるか。ひとつは、プログラム言語の選び方に違いがある。10万行の世界はひとつの言語で作られている。JAVAだけとかC++だけ、といった風に。

それに対し、こちらの行数の少ない世界では複数の言語で作られていて、それぞれの用途に特化している。そのため行数が少ない。

用途に特化した言語を使うと、行数というか記述の数が少なくなる。例として人間の世界で言うと、「シュートしろ」と言った時に、目の前にボール一個とゴール一個だけあったらシュートしてくれる。「うて！」と言うだけでサッカーだったらシュートしてくれる。

でもゴールが5個とか複数あったり、敵が30人とか目の前にいる場合、そしてボールが7個とかあったら、「右から二番目のボールを敵をこういう風にかわしながらこっちのゴールに打て」と言わないといけない。

つまり、言葉とは状況が複雑になると長くなる傾向にある。状況が複雑な所で使える言語すなわち「何でも作れる言語」では、長くなって結局何も作れなくなる。何でも書けるけど、長くなって仕方がない。

何でもかける言語とは、10万行を設計図の通りに、仕様書の通りに書いていく。それと違うことは書かない。多分。しかし、僕らは設計図に従ってプログラムを書くのでなくプログラムを書くことで設計したい。3000行を何回も書くことで設計したい。その過程で10倍くらい書いてるので3万行くらい書いてる気もする。向こうは、書いたら書き直さない。こちらは、書いたら書き直す。それによって、インタラクションを考えるためのプログラム言語として使っている。そのため軽い言語を使わないといけない。何回も書き直すためのプログラム言語である。

何回も書き直すためにいろいろなプログラム言語を使うわけであり、それは大変そうという印象を与えるかもしれないが、実はうちの研究室の人は既に3つのプログラム言語が使える。

学部の情報処理の授業で習ったJavaと、奥出研に入ってから習ったFlashとArduino。実は全く違う領域で使う３つの言語が使えている。プログラムとか言語とかは、３つめからは学習コストが下がる。英語を苦労して勉強してた通り、第二外国語は簡単に勉強できたと思う。英語の時の学習の流れが分かっていたりしているから。

それと同じようにプログラム言語を新しいものを学ぶ時は全て差分で学んでいく。ひとつの言語を深くやるよりも、広く浅く勉強した方が早い。そんなに差がない。上から書いた通りに実行されるだけである。

では、プログラム言語をどれぐらい勉強するか。その言語が何に向いてるかとかができないかとかが明らかになったら、それ以上は勉強する必要がない。必要な時にそれをまた引っ張りだして使えばいい。つまりArduinoで何ができるかというと、モーターの制御とか赤外線とか、時間にクリティカルな操作は自動化して行ってくれる。その分逆に、時間にクリティカルな部分は隠蔽されているからタイマーとかスレッドなどが使えなくなっている。そのため複数の処理を同時に一個のArduinoマイコンで行うことができない。

そのことさえ知っていれば、それ以上やる必要はない。基本的な文法が分かって2、3回書いたことがあればもうやる必要はない。あとはプロトタイピングの中で学んでいけばいい。

「開拓する」というのは達人になるということでなくて、それを使ったら何ができるか、何ができないかが分かり、なんとなくプロジェクトの中で「これを使ったら1週間くらいかかるな」とか「このセンサを使うんだったら3日くらいかな」とか「このライブラリは、よく分かってないけど顔の位置を認識できるんだな」とか、1行くらいで設計できるんだなとか10行くらいで動くんだなとか、それが分かっていたらそれでいい。プロジェクトの中で日数の見積もりまで出せる所まで理解したらそれ以上はやる必要はない。あとは、横に広がっていった方がいい。「タコの足の候補」を増やせばいい。

そういったことを勉強した後は、メッセとかで1対1で人に伝えるよりは、ブログに書いた方があとあと逆に情報が集まるようになるので有益である。30人の中で29人に1対1で教えて、それかける29回教えるよりは、どっかに書いて読みたい人だけ読んでもらった方が楽である。そうでないと追いつかない。また、それにより何回もラピッドなプロトタイピングを繰り返すことができる、

それが奥出研の方法論を支える根幹にもなっている。それの複雑なインタラクションを支えることができるのがこれのポイントである。

こっちを押したらあっちのFlashが光るとか、Flashのこっちのボタンを押したらマイコンのここのモータが動くとか、そいうった直結した簡単な論理構造で並列に時間が走ってないようなインタラクションでは、次元が上がっていかない。1アクションでもたくさん豊かなことが起こっていかないといけなくて、その点で、いろいろな方向からくるメッセージをさばくことが必要になる。インタラクションの言語性。

傘を持って、歩きながら傘のインターフェースを見て、ここの地図と見比べて、その後に「この辺か」と思ってスイッチを切り替えて写真モードに変えてくるくると回して、写真をブラウズしてこの場所行きたいなと思って地図に戻して、歩きながら写真を撮りながら向かっていく。

その流れをラピッドにプロトタイピングできるようにしないといけない。Pileusは本当に作りながら考えた。実は1stプロトは夏休み中に3回ほど作り替えた。最初の2回は思った通り動かなかった。というところを、作りながらシナリオを作る、みたいなところが必要である。

…アーキテクチャイノベーションから話し始めると、それ単体では説明できるがタコ理論までつなげるのがなかなか難しい。

こちら側から説明すると、破壊的イノベーションを起こせるデザイナになりたいというビジョンがある。飛行機の部品を作れるようなはんぱなく凄い技術を持ってる人が東大とか東工大にはたくさんいるのだが、飛行機そのものを作れる人はいない。そういった、最後にインテグする人材を作った方が日本のためにいい。

それは、全体の必要なパーツと機能を抜き出すこともできるが、全体の絵がかけて、いろんな人に話し掛けながら頑張って一個のものにしていくこと。実際、ただ設計図を書く人という意味ではない。ただ設計図を書くだけじゃなくて、設計図とは、最初から書くことができない。作りながら書くことしかできない。人間の言語はそういう風にできていない。なので、それをやりたい。

破壊的イノベーションができるとどういうことが可能になるか。それは、パソコンの規格品の部品等とは違い、簡単に手に入る部品はいろいろある。そういうものを集めて、既存のものを集めて違う価値のものが作れる。そのため部品調達コストが低いのに、豊かなものが作れる。またお金ももうかる。

最後にそれをインテグする人は、設計図を書くことだけでは設計図を書くことができなくて、合体・インテグさせながら設計図を書かないと設計にならない。

という感じで、破壊的イノベーションを行うには、何回もプロトタイピングできるように技術のレベルを調節しながらやっていくしかない。下を作っては上を作っていく、といった具合に。

コアの技術とは、各部品から来るメッセージをさばく部分のことであり、ただの設定ファイルのようなものではない。スイッチAがこうだったらスイッチBがこう動くとか、そういうものでない。

もっと、20ミリ秒止まるとか、そういう所まで来ると、設定ファイルみたいな書き方では実現できなくなる。ほんとにプログラム言語じゃないと書けない。同時に、並列的にイベントが起こるため。処理80％くらいのときに向こうから指令がきたらどうなるか、とかまで踏み込まないといけない。

フィールドワークは実はこの場合にすごく重要で、常にフィールドにいてプログラムを書かないといけない。何故かというと、作ってすぐコンパイルしてすぐ動く状態にして試すのがいい、重要だと主張しているわけだが、試した結果が正しいとかこうした方がいいとかう基準になるのは、ユーザーである。あるいは自分が使ってみて使いやすいかとか嬉しいかでもいいのだが。

どっちの方に持っていきたいかとか、文化的なコンテキストとかユーザー的なコンテキストに沿ってそちらに寄せていかないといけない。なので、使ってみた結果僕のターゲットにしてるおじいちゃんには使えないなとか、それが分かるためには最初からフィールドワークが必要である。そのユーザーのコンテキストを自分に取り込んでいないと、いくらラピッドに試せるとしても、反映できない。

フィールドワークができてなかったら、それがいいかどうか分かる筈がない。ポストプロダクションではないが、プロダクションしている途中なのだが、最初のアイデアを得る段階でフィールドワークが必要だということもあるが、その出来た物が良いか悪いかということはフィールドの中じゃないと分からない。

スモールチームについて。これらのことは、小さなチームで意思決定しながらじゃないとできない手法で、たぶん20人とかいたら月あたりの人件費が600万円とかいくものである。でも学生4人だったらもっと低くて、リスク度外視で動ける。

どんどん冒険しないといけないし、そもそもこの開発手法だとあまり金がかからない。破壊的イノベーションだから、出来合いの既製品を集めてきてやってるわけで、かかったとしても200万とか。それだと、全然企業のデザインプロジェクトよりもお金はかかってない。

スモールチームで、Web側から、タンジブルインターフェースでみんなをカバーできるようにしないといけなかったから、軽い言語を使わないと、スモールチームではカバーしきれない。

大きい30人とかの組織でそれら全部をカバーすることはできるのだが、そうすると今度は意思決定が遅くなる。意思決定を早くしようとすると、ヘッドの3人くらいのデザイナーとその下の27人くらいの構造になるが、そうするとウォーターフォールモデルの開発になる。

デザイナと開発者に分かれていて、しかしデザインすることと開発することは同じである。手を動かす人と考える人とリスクを背負う人と頭を動かす人は全部同じ人じゃないといけない。その3、4、5人くらいのチームでデザイン領域の技術全部と、フィールドワーク先のコンテキストを取ってくる技能、本読んで勉強したりする技能、それら全てをもってないといけない。

ちょっとちゃちいけど動くプロトタイプを、少人数で2週間に1個とかのペースで作れるからこそできる種類のものがある。それと一番相性が合うのが破壊的イノベーションである。

個々の部品は性能が上がるものであり、実際、携帯電話に入るプロジェクタを作ってたりする人とかいて、つまり後から性能は上がるものである。ユースをあげれば性能を上げる人は他にいるから、俺らががんばると科学者の人もうれしい。

身体的なインタラクションを考察したドーリッシュの話があるが、実はオペレーションのところじゃなく、アクションでもユビキタスコンピューティングは動くよねという話。操作しなくても自動的に動くのだが、しかしぎりぎり操作になる。歩くとか、毎日寝起きしてるだけでもベッドが勝手に体調管理してくれるとか。

使わされてるわけではなく、使っているのだが、オペレーションではないのにEmbodiedなインタラクションがある。具体的なオペレーションではなく、生活しているアクションで使うことができる種類の、「大きい」Embodied Interactionはwebのサービスと相性がいい。

それのアクションをトリガーにして、ベッドで寝起きするだけとか、トイレを使うだけとか、傘をさしてただ歩くだけとか、行灯の前でただ生活するだけとか、カメラとかを埋め込まれたセンサーが認識してくれて、それでウェブのサービスが動くようになる。それがEmbodied Web。ウェブのサービスがウェブだけにあるのではなく、身体化される。

言語に粒度がある、ということについて。

基本的には、先ほどの何でも書ける言語は何も作れないということ。また、いろいろな言語をいじっていると分かることがある。PerlとPHPとRubyは全く違うもので、今では同じ用途のものとして扱われることもあるが、まず最初の頃にC言語があった。そして、スクリプトでC言語が書けるようになって、ハッシュと正規表現があるのがPerlである。PerlにCGIがついて、HTTPの機能がついたんだけど、そのHTTPの機能を中心にPerl側の正規表現とかに伸ばしていったのがPHP。Rubyは、それとPythonというDelphiっぽい変態言語から長所短所を整理し直してオブジェクト指向を中心にして作った。Rubyで完成された、ちょっと傲慢な思考のオブジェクト指向の考え方をもういっかいPerlに戻したのがPerl6.0、らしい。知らんけど。もちろん、JavaScriptみたいな変なのもあって、クラスが存在しないオブジェクト指向もある。

オブジェクト指向が何故いいか。それは、プログラム言語が僕らの生きている世界とfamiliarityを持ったところにある。書き方が似ている。主語.動詞(目的語, 目的語, 目的語)、という書き方ができる。それがオブジェクト指向の一番いい所である。

今まで、主語無しで動詞だけとか、いきなり目的語＝目的語とか繋げたりしていた。それに対し、わりと人間の言葉に近いのにコンピュータのロジックにコメントできるギリギリの境界を作ったのがオブジェクト指向の考え方の一番凄いところである。

メモリアドレスに現実世界に似せた自由な名前を付けられることと、それに関数を関連づけること、それだけで主語.動詞()、の書き方のように人間の言葉に似た書き方ができるようになってよかったねということである。

もちろんフォーカスが違うということもある。CPUの中のことをそのままやりたければアセンブラが一番いい。現実世界のものごとをコンピュータに移したくなったらオブジェクト指向。

図の右上の言語学・記号論について。

以上の話が、言語学とか記号論とか文法とかの面で、そして今のオブジェクト指向とかプログラム言語の見方で、さっき言った言語学と同じように文法と記号の並び方の文法でできているわけなので、3つ目以降のプログラム言語は早く勉強できる。それはそのまま成立するし、言語で思考しているし、言語によって思考の詳細化ができるレベルが違うとか、逆に詳細になりすぎて全体が書けなくなる言語があるとか、そういうところは多分言語学とかと通じる。

図の左下のオートメーション、人工知能について。

オートメーションと対になる言語性のあるインタラクションというもの、それは複雑さを縮減する方法をどうするかという話でもあるが、現実世界で起こっていることをセンサーで入力して電圧とかになってコンピュータに入り、記号処理されてデータベースに問い合わせてそれが戻ってきて、その記号から電圧からアクチュエータに戻って人間に戻ってくる。

そこで、情報が変換されたり減ったり増えたりしている。それをやるときの方針が、オートメーションか言語的なインタラクションか、という話になってくる。僕はそれはミックスでいいと思っている。白鳥さん的なベイジアンネットワークにmastabaとかcara clockみたいな面白いインタラクションを重ねる。

現実世界にある情報は扱いきれないものだが、それを一回センサーが変える。例えば樹がやってたような「笑ったセンサー」というものがあって、笑ったセンサーがついてる机のまわりでみんなでDSでゲームをやっているとする。盛り上がったらその人の所だけ画面がでかくなってハイライトされたりする。それでゲームがより面白くなったりするとする。

もしかしたら「笑った」というのは「大声を出した」とか足をバタバタさせたとか、そういう箇所で取ればいいのかもしれない。もう少し複雑なセンサで取ってもいいのかもしれない。そういう風にして、複雑な・曖昧なところをコンピュータで計算可能な状態に変えていく。それを計算して、出力結果を人間に理解可能な状態に戻して、渡してあげないといけない。

さっきのEmbodied Webの話の様な事をやる時は、その変換が凄く重要になる。なんでかというとwebでやりとりされる情報は、XMLとか生テキストとか地図とかビデオみたいなすごくリッチな情報だけど、人間とインタラクションする部分をGUIだけじゃなくてTUIでもやろうとするとモータをこう動かす、LEDをこう光らせるというチープなただの「物理現象」に変換しないといけない。翻訳が重要。

人間に理解可能なものをコンピュータで計算可能にして、そしてまた戻すこと。Computationalな部分とUnderstandableな部分それの行き来をさせるのが、おそらくコンピュータを使ったメディアを作る醍醐味である。それが、「こっちを押したら向こうが動く」とかではなく、何かの変換が行われて違うものが出てくることの面白さである。

インタラクションのデザインなんだけど、それはある面ではその変換のデザインである。その変換することの方針が、オートメーション型で情報を縮減していって計算して出していくことか、言語的なインタラクションでより多い情報や可能性を記述できるようにしてコンピュータに伝えることか、ということ。人間が発することができる言語なんだけど、コンピュータに十分状況が伝わるようにインタラクションを設計するか、という違いである。それら両方を使うと、たくさんまとめると大量に伝えて、それを一気に表示して記号処理してまた戻してきてくれたら凄く面白いものになる。

入力装置、ではなく、変換装置である。意味が減ったりしている。人間の言語は絵みたいなものであり、ハエが頭の上で飛んでいて、みたいな感じで状態や物と物の関係は記述できる。しかし、同時にとか複雑なこととかが自明なことになっていて伝えきれていない。それがないとコンピュータは動かない。

インタラクションの言語性という話について。

オートメーションするのはコンピュータ側で複雑な情報を全部計算可能な状態にするような人工知能というアプローチもある。コンピュータで計算可能かつ人間で理解可能なこと、という点について、実際問題、Webでやりとりされているコンテンツは全部それしかない。

テキストと地図と写真とビデオと音声しかない。5種類しかない。それらは、地図はもちろんなのだが、人間がそれ自体をそのまんま見てコンテンツとして楽しめて、かつそれの中身のデータを解析してコンテンツ間の関連性を計量したり計算したりとか課金したりとかできる性質のものしか記述していない。

なので、そのまんま写真、とか、そのまんま音声、とか、そのまんまビデオ、など。Web2.0で発達したのは、そこのお金のやり取りとインタラクションのコストが下がったこととくらいしかなくて、コンピュータで計算してお金のことを考えたりとか、コンテンツ間のリンクを生成したりとか、人間がそのままそれを楽しめることが同時に満たされているものしか、ウェブではコンテンツとして流れていない。

でも、この言語的なインタラクションのこととかを考えたりしていると、もうちょっと変わってくるのではないかと思う。コンテンツとはバイナリのデータファイルのことを言うのではなくて、tumblrのdashboardを流していく事がコンテンツなのではないかと思う。一枚一枚の写真に意味があるのではなくて、キーボードの jボタンを連打しながら流していて、頭がシャワーに流されているような、上流から凄い勢いで桃を流してる人がいる事件みたいなのが起こったりするのがコンテンツ。

それが、これから作るものの指針になってくるんじゃないかと思う。インタラクションに価値が出てくる。このときのポイントは、現実世界の多過ぎる情報をどうやってコンピュータで計算可能な状態に縮減していくか。

シンガポールで開催していたMobileHCI2007と、MobilityConferenceにPileusの発表で参加しました。

今回はそれぞれデモとペーパーの発表でした。

デモの各発表ブースにシールを貼って投票するという方法で、2位になったらしい。エイドリアン先生とちょっと仲良くなったかも知れない！！

（ちなみに僅差で1位になったのは Mobile Interaction with Web Services through Associated Real World Objectsというケータイでがっつり実装されてるモノで、これ面白かったので後で論文読みます）

デモ発表前の2-munites-madnessで、デモ概要を120秒でアピールするようす


(Picasa ウェブ アルバム – Yongsoon Choi – Mobile HCI 2007 – _MG_0263.jpg)

やっぱ壇上に上がると台詞飛ぶ。please come to touch our demonstrationって最後に言うの忘れて退場しちゃった…

使ったスライド

デモ発表しているところ


(Uploaded on September 11, 2007 by 22n)

デモ発表するma22nさん

MobilityConferenceでのペーパーのようす

モバイル系のHCIは、電池やユーザインタフェースのサイズの面で過酷で、コンテンツ配信や位置情報などの面ではすごく商業化に近くて、まあなんというか激戦区なわけです。面白かった。いまだに英語慣れないけど。

ベストペーパーに選ばれてたHuman-Battery Interactionとか、名前からして面白い。

今日は奥出研の今学期の最終発表で、

畑山さんと臼井さんが修士を卒業するという事で、祝辞が述べられたりしたんだけどそこをustream/channel/shokaiし始めたらどんどん卒業生が集まってきた。

同時に録画もしておいたので時間が合わなかった人もどうぞ。

hatayan and ussy graduate (1/2)

hatayan and ussy graduate (2/2)

ustreamのチャットでアマガメとか貼られたりしてうけた。

あと古川先生に和田さんがblogで絡んだりとか、天谷さんが八木さんに萌えてたりとか。

チャットはこんな感じだった↓

橋本租界: ustream.tv/channel/shokai

こういう感じで卒業生がすっと戻ってこれるというのも面白い。

以前、卒業生が光臨できる定点カメラというのを設置しようと思ってたけど、ustreamのお陰で個人のwebcamがそういう役割に早変わりできちゃう

Satera｜LBP3950/LBP3900

DNP2階に設置された新しいネットワークプリンタのセットアップ方法です。

DNPのネットワーク内のPCから印刷できるようになります。

まずOSに合ったドライバをダウンロードしてくる。

キヤノン：サポート｜ソフトウエアダウンロード

OS選んだ後に2種類出てくるので、「LIPS LX プリンタドライバ」の方。

ダウンロードしたファイルを起動すると「インストール先」と訊かれるので、そのままOKする（インストールじゃなくて実はただ解凍するだけ）

解凍してできたフォルダを開いて、setup.exeかinstall.exeか忘れたけど実行する。

ダイアログをそのまま進む。

ここから少しややこしい。

「ポートを手動で設定」

LBP3900を追加

ポートの追加

Standard TCP/IPを選択

「192.168.0.16」を書く。全部半角。

使用するポートに「192.168.0.16」が増えているので、選択して「次へ」

インストール完了。

プリンタとして選べるようになりました。

無駄遣いしないように。あとこれ両面印刷できるらしい。

帰国する時にドイツでビール買ってきた。

ACE参加しながらUbicompにsubmitしたからな。こっちも打ち上げだぞー

グーテンターク。

今フランクフルト空港にいます。まわりはみんなでっかいビール持ってます。

これから、飛行機乗り継いでザルツブルグで開催されているACE2007にポスターを貼りにいってきます。

そういえば、↑ポスターの右下にも書いてあるけどMobileHCI2007のデモにも通ったので、9月にシンガポールでデモしてきます。

ma22nさんが3ヵ月ほどアメリカに旅立ったので、メッセージビデオを表示するプレイヤーをFlashCS3で作ったり

→ ma22tube

あとエプロンをあげた。これがあればプロトタイピングできる。

■ソースコードとか

Source Code (fla) Flash CS3/AS3

ちょうどこの日でFlash CS3体験版の試用期限が切れたので俺はこれ以上編集できない。

flvの読み込みはs.h.log: FlashCS3 – flvファイルの読み込み、スライダーで制御を参照。

ソースコード。フレームアクションで。

varnum:Number=18;//videoの数

varnow:Number=1;//今再生しているビデオ

tNext.addEventListener(MouseEvent.CLICK,nextVideo);

tPrev.addEventListener(MouseEvent.CLICK,prevVideo);

player.addEventListener(“complete”,

function(){

if(now
playVideo(++now);

uiReload();

}

});

playVideo(now);

uiReload();

functionuiReload(){

playText.text=now+”/”+num;

pink1.alpha=now*3/100;

pink2.alpha=now*3/100;

}

functionnextVideo(event:MouseEvent):void{

if(now
playVideo(++now);

uiReload();

}

}

functionprevVideo(event:MouseEvent):void{

if(now>1){

playVideo(–now);

uiReload();

}

}

functionplayVideo(num:Number){

varsource:String;

if(num<10){

source=”flv/0″+num+”.flv”;

}

else{

source=”flv/”+num+”.flv”;

}

player.source=source;

}

大好評開発中の雨の日を楽しくするインターネット傘Pileusですが、渋谷での実験のフルバージョンビデオを公開しました。

傘持って歩きました。色んな人が絡んできて楽しかったです（9分あたり）

このバージョンでは、GPSとデジタルコンパス（方位センサ）が追加されています。

・Flickrからの写真の読み込み、GeoTagを付けてアップロード。

・GoogleEarthをGPSとデジタルコンパスでコントロール。歩くと地図も動く。

ができます。

撮影や準備を戸松と菅野さんと吉田さんと畑山さんに手伝ってもらいました。ありがとうございます。

あと、4月末にフランスで受賞したLaval Vritual Awardだけど、Prix du l’innovationというのは部門賞ではなく1個上らしい。でもグランプリではないみたい。

Laval Virtual 2007 – Palmar�s des Troph�es Laval Virtual 2007