先ほどのエントリの続き。 タチコマさん。 Windows にソフトを入れてみました。 🙂
hiromasa.another :o) » Blog Archive » 超合金タチコマきた。
特徴は USB で PC につながって、声が出たりランプがついたりすること。
Linux では失敗しましたが、やはり USB audio として機能するようです。（←先に Windows でやれ。。）
センサー部と LED が動きます。
USB audio デバイスをメディアプレイヤーに割り当てて鳴らしてみるの図。
ちゃんと鳴ります。 🙂
みためふつーの USB audio デバイスなので、他の OS でも鳴るんじゃないかな～。 さっき、Linux で鳴らなかったは OS 側の設定っぽいですね!
超合金。 超合金。 なぜ、"超" 合金。 すごい不思議。 というわけで、超合金タチコマが我が家にやってきました。 といっても買ったのは同居の人です。
さすがに、定価 13,000 円だけあってできがよい。 ずっしり、ディテールもよく、ちゃんと墨入れもされております。
特徴は USB で PC につながって、声が出たりランプがついたりすること。
・・・ PC と接続できる。。
・・・ PC と接続できる。。
[tegaki]かえして～[/tegaki]
とは同居の人の弁ですが、早速 Linux に接続して lsusb です。 🙂
内蔵スピーカから声が出るということで、さすがに本体に wav をもたせることはしないとふんで USB 接続してみたら、やはり USB audio デバイスの模様。
$ cat /proc/bus/usb/devices
T: Bus=04 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#= 3 Spd=12 MxCh= 0
D: Ver= 1.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1
P: Vendor=0992 ProdID=0706 Rev= 1.00
S: Manufacturer=BANDAI
S: Product=USB Tachikoma
C:* #Ifs= 3 Cfg#= 1 Atr=80 MxPwr=100mA
I: If#= 0 Alt= 0 #EPs= 0 Cls=01(audio) Sub=01 Prot=00 Driver=snd-usb-audio
I: If#= 1 Alt= 0 #EPs= 0 Cls=01(audio) Sub=02 Prot=00 Driver=snd-usb-audio
I: If#= 1 Alt= 1 #EPs= 1 Cls=01(audio) Sub=02 Prot=00 Driver=snd-usb-audio
E: Ad=02(O) Atr=09(Isoc) MxPS= 192 Ivl=1ms
I: If#= 2 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid
E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=1ms
BANDAI USB Tachikoma ですね。 HID のデバイスも見えるので、おそらくこちらは顔とLEDの動きの制御でしょう。
dmesg してみると、
usb 4-2: new full speed USB device using address 2
input: USB HID v1.10 Device [BANDAI USB Tachikoma] on usb-0000:00:02.0-2
usbcore: registered new driver snd-usb-audio
ということで、あっさり USB オーディオとして認識しているようなのですが・・・
$ mpg123 -a /dev/dsp hoge.mp3
ALSA lib pcm.c:1972:(snd_pcm_open_noupdate) Unknown PCM /dev/dsp
[alsa.c:144] error: cannot open device /dev/dsp
[audio.c:517] error: failed to open audio device
[mpg123.c:687] error: Failed to initialize output, goodbye.
うーん、なんでじゃろ。 たぶんぼくがミスってるだけだと思うんですが・・・・。
接続した Linux のサーバで、タチコマから時報でもならせれば面白いと思ったんですが残念。
まぁまぁ、 200% 同じことをする人がいると思うので、他の方の情報を待ってみることとします。 USB の信号 hook してモニタできるような Windows ソフトってあるんかな？ 🙂
オブジェクト指向言語と、RDBMS のインピーダンスミスマッチというのは昔からずーっと言われてきていて、最近ではいろいろなライブラリ、フレームワークのたぐいがそれを解消してくれるようになってきました。 しかし、この2つの組み合わせにはもっと恐ろしい弊害があるなと思っていて、自分の中で整理するためにもここに書いてみることにします。
RDBMS はエクセルなんかでおなじみのみためは２次元の表の集まり。 これをリレーションと呼ばれる表間のキー接続をつかって様々なデータを表していきます。
ここで問題となるのが、プログラムにおけるデータの持ち方とデータベースにおけるデータの持ち方が異なること。 特にオブジェクト指向でつくられたプログラムは RDBMS の２次元の表とデータの持ち方が異なり、データベース保存時に変換する必要があります。 そして、オブジェクト指向の場合、カプセルの単位がデータだけでなく"機能"も含まれます。
よくメンテナンスされたプログラムは、このインピーダンスミスマッチを O/R マッピングライブラリなどで解消し、そしてオブジェクトの持つ"機能のカプセル"部分もうまく再現できるようにつくられています。
そのへんが不出来なプログラムをみていて、思ったことがあるのです。
[tegaki]RDBMS がグローバル変数。[/tegaki]
オブジェクト指向の一番基本的な使い方は、同じ処理は同じところに書くこと。 継承などのオブジェクト指向特有の機能はそれを実現するためのツールです。
ところが、RDBMS のアクセスをいれたとたんそれが崩壊するときがあります。
それは、あちこちのモジュールからテーブルをアクセスし、データを書き換え、それを"モジュール間の連携手段"として動作させたとき。
同じたぐいの処理だったものが各モジュールに分散し、もはやオブジェクト指向の意味なし。 常に、各モジュールはデータベースのカラムの値を意識しなければいけない最悪。
不用意なカラムの書き換えは死を招き、調査にソースコードを全 grep する必要があり、恐ろしいアプリケーションに発展していきます。
まさにグローバル変数。
Java や C# などの言語は、たとえばグローバル変数を"使えない"ように言語体系でプログラマを縛ります。
言語はあるいみフレームワークとなり、無茶なプログラムが書けないようになるために、誰が書いても一定水準、メンテナンス製が高くなります。 また、できないことが分かっているため、修正等で考慮しなければいけない部分もぐっと減ります。
しかし RDBMS アクセスがはいり、それをたった１つの不適切なモジュールがした瞬間に、言語フレームワークの壁が崩壊してしまう印象があります。
モジュール間の連携で RDBMS を経由するのは、グローバル変数をつかってモジュール連携しているのと同じ意味です。 ソースコードの繋がりがそこでいっきに途絶えるので、特に MVC でつくられているプログラムは、処理シーケンスもデータフローもがソースコード上から読みとるのがとても困難で、また、読めた確証を持つ時間が大幅にかかります。
これはたとえ O/R マッピングのライブラリをいれても、プログラムの書きようでどーとでもなってしまう部分。 オブジェクト指向と RDBMS を組み合わせる場合最大のインピーダンスミスマッチ弊害なのかもしれません。
縛りを入れつつ、それを縛りとおもわせない解は RDBMS じゃなくて、オブジェクトデータベース使うことかなーって思うんですが、アプリをつかわずとも簡単にデータパッチできる RDBMS の運用性の高さ、信頼性、周辺ノウハウはなかなかおいそれと手放すわけにはいかず、歯がゆいところです。
"気をつけて書く" じゃなくて、書けないようにする。 窮屈ですが、人間考えることを少なくする方がいい結果を生むことも多いってもんです。 🙂