「全てはクラウド経由で」を目指すCloud Terminal Deviceの前振りとして、１歳になったR2-D2をiPhoneとAndroidで制御する仕組みを作ってみました。
クラウドの末端神経デバイスの試作を行う事になりました。具体的には、あらゆるセンサー情報およびリモートＳＷをクラウド経由で取得・制御・ロギングできるデバイスで、スタイルとしては、無線ＬＡＮで接続し、どこでもコンセントに指すだけ。という形の実現を目指します。
安直な利用イメージとしてはこんな感じです。
gumstix ってご存じでしょうか？
昔、ぷらっとほーむで扱っていた時期もあった、チューインガムサイズの超小型Linuxボードです。当時、「これはすごい！」と購入したのですが、結局、日本ではメジャーにはなりませんでした。しかしながら、私はいまだにgumstixの小型でトランスフォーマーなコンセプトはかなり行けていると思っています。
で、なんとこのgumstixで、ついにAndroidを動かすのに成功した方が現れました。
かなり時間がかかっていますが、確かに上がっています。
液晶を取り外せば、間違いなく世界最小のAndroidマシンだと言えると思います。すごいですね～♪
Google Android Hackathonに参加してきました。
初めてのHackathonだったのですが、明らかに準備不足でチームのメンバーには迷惑をかける結果となってしまいました。この場を借りてお詫び申し上げます。
作ろうとしたのは、Ｉｄｅａｔｈｏｎでお題になったスカウター（Android + Nikon Media Port UP)です。ＧＰＳチーム総勢５名で取りかかりました。私は、サーバ側を担当し、予定では１時間ぐらいで完成して、Ａｎｄｒｏｉｄ側の作業に取りかかる予定だったのですが、Djangoのmodelの使い方がよくわからず、つまらないところで何時間もハマッてしまいました。できあがった時は、すでに発表３０分前という状況で、一行もAndroidのコードを書かずじまいで、何をしに行ったんだか。。。という結末でした。
みんなが頑張ってくれたおかげでかなりいいところまで来ていたのですが、最後はモックで発表という残念な落ちとなってしまいました。技術的な問題点はすべてクリアできたのが締め切り１０分ぐらい前。(^^; たぶん、もうちょっとあれば完全に完成していたと思います。
また、最後発表をまかされたのですが、精も根も尽き果ててしまい、ろくなトークができず、完全に失敗してしまいました。
もし、またHackathonが開催される事があれば、是非、リベンジをしたいと思っています！
一緒のチームで戦ってくれた皆さん、これに懲りずに、また機会があればよろしくお願いします！
＃Hackathonにおいて時間内に完成できなかったときに、あれほどの脱力感を感じるとは。。。いゃ本当に疲れました(^^;
「iPhoneはどうせニッチ層＆富裕層。Androidは貧困層も含め爆発的に広まる」と思っていたのですが。。。
アメリカでは、99ドルという話が出たとおもいきや、日本でついに０円販売がスタートしてしまいました。
こうなってくると、iPhoneの普及率が読めなくなってきそうです。
「学生は絵文字が」とか「iPhoneは爪が長いと」なんて話って、最後は料金で全て吹っ飛ぶと思っています。私が学生だったら、この０円には負けて買ってしまうかもしれません。
ただ。。。
弊社のiPhoneユーザの請求書を見ると、パケット量がパケット定額じゃなかった場合、月額70万ぐらい使っているそうです。「ソフトバンクはインフラにもうお金がかけれない」という噂もあるのですが大丈夫なんでしょうか？
iPhoneにSIPをしゃべらせて、自宅のAstariskに接続している方を見つけました。香港にいながら自宅の電話をiPhoneで使えるんだそうです。
この方法であれば、ｓｋｙｐ アウトに比べて遅延もなさそうですし、発番も怪しい番号にならずにすみそうです。
現在、会社の電話環境をastarisk化しようとしているのですが、うちでもこれ使えるかもしれません。
最近オフィスの電話の調子が悪くて困っています。既に製造停止から１０年選手の端末をつかっているため、代替機もなく修理も出せない状況です。
そんな背景から、元交換屋としては、asterisk を使って社内の電話を制御したい虫がうずうずしています。
当然、端末としてはSIP対応のAndroidが欲しくなってきます。
asterisk + (Android + SIP)が組めると、いままで出来なかったような社内サービスが実現できると思うのですが、どうでしょうか？
昔は、SCSIならAdaptecの2015や2010。IDEならiodataのdelta2あたりをつかっておけば、いざっていうときは、RAIDカードを撤去してマザー直指しで復旧作業が出来ました。
しかし、昨今のHardware RAID カードは、メーカー独自フォーマットが主流となってしまいました。その影響で、サーバメンテナンス業者は、
というリスクが伴います。
それでは、LinuxのSoftwareRAIDにしたら?という話になります。
ハードウエアRAID vs ソフトウエアRAID。
この論議を机上論で行うとハードウエアＲＡＩＤに軍配があがるのですが、実際の泥臭い現場の状況からすると、ハードウエアＲＡＩＤは結構痛い目に会うことが多いのは事実だと思います。これまで１４年間。数百台のサーバを作り最後まで看取ってきましたが、ハードウエアＲＡＩＤのホットスワップで得た恩恵の回数と、ＲＡＩＤカードを使った事によるトラブルに巻き込まれた回数とあまり変わらないように思います。やはりシステムの摂理として、シンプルなのが一番で、複雑になればなるほど事故も増加します。
そこで、システムが冗長化になっていれば、ホットスワップが出来ないＳｏｆｔｗａｒｅＲＡＩＤの方がメリットが多いのではないか？という切り口から、いまさらながら、ハードウエアRAID vs ソフトウエアRAIDのスピードテストを行ってみました。速度さえトントンであれば、この際、ハードウエアRAIDを捨てるのも現場的にはありかと思ったからです。
結果は、以下の通り。弊社ではこれを機会に冗長化してあるシステムにおいて、ハードウエアＲＡＩＤはやめる事にしようと思います。
■測定環境
マザーボード Super X5DPR-8G2+ CPU Intel(R) Xeon(TM) CPU 2.40GHz x 2 メモリ 2GB ハードウエア RAIDカード 3ware 8006-2LP ハードディスク ST31000333AS x 2 OS CentOS 4 データベース PostgreSQL 8.1
■ 測定結果
以下SW=Software RAID, HW=Hardware RAID。水色が勝者。
▼bonnie++
○アクセス速度
Sequential Output Sequential Input Random Sequential Create Random Create Per Chr Block Rewrite Per Chr Block Seeks Create Read Delete Create Read Delete K/sec K/sec K/sec K/sec K/sec /sec /sec /sec /sec /sec /sec /sec SW 29738 76693 28425 26180 63601 387.5 33087 211403 35711 34286 273394 35336 SW(-n 256) 29221 76877 28401 26384 62070 377.2 19978 200433 509 11538 252888 266 HW 27081 57677 22943 25966 56936 379.2 29879 N/A N/A N/A N/A 32170 HW(-n 256) 27983 56850 23303 24297 54209 352.6 19401 194718 715 11494 246347 377
○CPU使用率
Sequential Output Sequential Input Random Sequential Create Random Create Per Chr Block Rewrite Per Chr Block Seeks Create Read Delete Create Read Delete %CP %CP %CP %CP %CP %CP %CP %CP %CP %CP %CP %CP SW 97 44 11 78 10 1 97 100 100 99 100 100 SW(-n 256) 95 45 11 79 10 1 70 100 2 40 99 1 HW 89 32 9 75 10 1 90 N/A N/A N/A N/A 98 HW(-n 256) 91 31 9 70 9 1 70 99 2 41 99 1
▼pgbench
○条件
transaction type: TPC-B (sort of)
scaling factor: 100
number of clients: 50
number of transactions per client: 200
number of transactions actually processed: 10000/10000
○結果
SW 123.03785 tps HW 95.591599 tps
昨日、粋べんのAndroid 実践編に行って来ました。講師はAndroidの会の幹事の平出心さんでした。以前、丸山先生の公演で付き添いに来ていらっしゃっていてお顔は存知上げていたのですが、あとから副業が競馬予想屋(!)という事から非常に興味がありました。その中で、wikitudeの紹介があったのですが、「そうだ！Nikon UPのファインダーに写したら面白いかも！」と思って試したところ、これが結構いい！
G1のカメラをあえてガムテープで塞ぎ、wikitudeをin Camモードで起動。G1の画面（文字だけ）をビデオカメラ経由でNikon UPに送ったのですが、ちょっと気分はユニバーサルソルジャーです♪
データセンターの分散化をする場合、いまでもDNSラウンドロビンは現役です。
YahooやGoogleを始め、広くでも使われています。
先日、お客さんのサイトでトラブルがあり、ログを比較していたところ、特定のセグメントに、
かなり偏りがあることが判明しました。
１年ぐらい前はそんなことはなかったので、DNSラウンドロビンの誤差とも思ったのですが、
ログの量がほぼダブルスコアでした。はじめ、ログ収集でミスがあるのではないかと
必死に追ったのですが、全く問題がありませんでした。
トラフィックを見たところ、トラフィックも間違いなくダブルスコアになっています。
間違った、比率で応答するDNSがいるのかとも思ったのですが、全く見つけられませんでした。
そんな中、鈴木君が、ログ解析システムで、データセンター毎のユーザエージェントを
眺めていて、「あれ？なんかデータセンター毎のユーザエージェントがおかしい」言い始めました。
そう、Vistaが特定のデータセンターに集中していたのです。
| Data Center | DNSラウンドロビンIP数での比率 | Windows XP比率 | Windows Vista比率 |
|---|---|---|---|
| A | 25 | 23 | 7 |
| B | 50 | 47 | 17 |
| C | 25 | 30 | 76 |
※OSとブラウザの組み合わせで出る問題なので、OSだけのデータでは語れないので参考値
いろいろと、調べて見ると、同じように騒いでいるページがあることがわかり、
結局、Vistaのgethostbynameが、DNSラウンドロビンの時は、
一番小さいアドレスを返す仕様（バグ？）であることが判明しました。
micorsoftさんもDNSラウンドロビンを使っているように見えるのですが、
みんな、困っていないのでしょうか？
Windows7でこの問題が治っているのを祈りたいところです。
それとも、getaddrinfoだと大丈夫なのでしょうか？
今後も改善されないとすると、結構、困ったことになりそうです。