#すごいな、twitterでバグレポする時代。ある種report golfingか(笑)。
##知らなかった。
#SIGINFO/^T じゃないのか RT higepon: ddコマンド実行途中に、何バイトコピーできたかを見る方法 (さくらインターネット創業日記)http://tanaka.sakura.ad.jp/archives/001069.html #へー知らなかった。自分で書く時に適当なシグナルを受けて状態を報告するようにすることはあるけど。
#SIGINFOってあんまりポータブルじゃなさそうな感じがある
#実際、kill -l をよくみたら linux にはなかったです。 RT shiro: SIGINFOってあんまりポータブルじゃなさそうな感じがある http://bit.ly/hTErgc #シグナルは対応してないプログラムに送ると困ったことになる場合が多いから、「このプログラムならこのシグナルで意味のある動作をする」っていうのをピンポイントで知ってないとならないのがつらいね。安全だってわかってるなら気軽に試し打ちして「ああこれはこうなるんだ」って知ることができるけど。
#この方法あたりまえですが dd の man にしっかり書いてありました。読んでないのがバレバレだ
#よく考えたらシグナルになっている理由が分からないな。普通に progress 出すオプションがあれば良いような。
#とりあえず始めちゃったけどずいぶん時間が経ってるなあ、あとどのくらいかなあ、なんて時に事後的に問い合わせられるのは便利ですよ＞シグナル
#まあでも、ddが作られた頃とscpが作られた頃で文化の違いはありそう。前者では基本的にコマンドは寡黙なものだった。
#私はどっちかというとscpがデフォルトでprogress出したのにびっくりしたくらいです。
#bsd だと端末で ^T たたくと foreground の process に SIGINFO が送られるんです。
#つまり、簡単。
#なるほど～。
#自分は完全に scp 世代だなあ。
#自分の twitter の TL には流れていたんですが、ping/fsck/ftp/find も SIGINFO うけると状態を表示します。
#SIGINFOのデフォルトハンドラってSIG_IGNだっけ。ぐぐってみたけどsiginfo(5)がヒットしてしまう。
#少なくとも NetBSD はそうです。でないと大変。
#ですよね。デフォルトで無害なことがわかってるととても便利だと思う。
#wilikiの本文に紛れ込ませてちまちまとリンクを置いてくspamが時々来るので、手作業で(書き込まれるurlを)blacklistに追加してるんだけど、このblacklistをネットで取れるようにしたら嬉しい人っているかな。
#blacklistへの追加は、私だけか何らかの登録をした人だけができるようにしといて、取るのは自由、間違いの場合はappealできるようにしとく。
##あ、まちがえました。Kinect でマイノリティリポート。
##コンシューマデバイスでここまで出来るようになったかあ。
#ブラックリストの管理には wedata みたいなサービスが便利かも。
#kinectは本当におもしろいおもちゃですよ. 簡易モーキャプがすでにできちゃうです.
#ブラックリストについては、一ヶ所に集中させないほうが良いと感じています。集中させると(1)そこがダウンした時の影響大(2)spammerもそこだけ見てれば回避策を取れる(3)poisoningのターゲットにもしやすい。なのでいくつもある場所のひとつにパブリックなデータ置き場を使うってのはありですが、メカニズムの本質はフォーマットかなと。
#で、間違ったエントリが混入した時にappealできるようにするには、各エントリごとにoriginを追跡できるようにはなってないとまずかろうなと。いくつかのブラックリストをアグリゲートして公開する、なんてことが起きた場合にも大元をたどれるように。
#とはいってもいきなり大げさにするつもりもないので、とりあえず最低限動くやつをwiliki向けに運用してみて、使えそうならぼちぼち広げるって感じでいいとは思いますが。最低限の前提として、分散管理とエントリ毎のorigin追跡は欲しいなと。
#簡易モーキャプについて: モーキャプは本格的に関わったことがないけど昔から薄い縁があってちらちら見たりいじったりしてましたが、「
#「モーキャプできる」というレベルが非常に広い話で、アプリケーションによってどこらへんのレベルが必要かっていうのが大きく違いますね。なので「どういう使い方をするか」が先にないと、できるかできないか、の議論にならないような気がします。
#もちろん、より高いレベルがより身近に手に入るようになってきているという流れはあって、kinectが一つの大きなステップであることは間違いないですが。
#UIに使う場合は、正確な動きのトレースよりも、動きの「シンボル」をユーザとの間に共有できるか、というのがポイントだと思います。ユーザが「このコマンドを入れたい」と思ったら、ほぼ確実に入れられる、という安心感が重要だなと。人間、同じ動きをしているつもりでも結構毎回違ったりします。動き全体を同じウェイトで見ちゃうと、本人が同じ動きをしてるつもりなのに入ったり入らなかったりして不満がたまる。「コツ」を飲み込んだら確実に入れられるような特徴をデザインする必要があって、特徴さえ取れたら細かい動きはわりとどうでもいい。
#アニメーションなどに使う場合は逆に細部の動きにこそ重要な情報が載ってるので、精度が重要になりますね。
#リアルタイムのアバターコントロールだと話がややこしくなって、ユーザがアバターを制御するところはアニメーション的なんだけど、ほんとに伝えたい相手はそのアバターを見てる別のユーザで、伝えたい内容によっては細かい動きよりもシンボルの方が重要だったりする。正確なトレースを目指すよりも、半ば自律的にアバターを動かしといてそのモードのスイッチにmocapから取れる特徴を使う方がいいかもしれないし、さじ加減が難しそうです。
#まあアプリを作ってる人たちってのはとっくにわかってて色々ノウハウがたまってるんだと思いますが。
Gauche > Archives > 2010/12/09