クラウドの末端神経デバイスの試作を行う事になりました。具体的には、あらゆるセンサー情報およびリモートＳＷをクラウド経由で取得・制御・ロギングできるデバイスで、スタイルとしては、無線ＬＡＮで接続し、どこでもコンセントに指すだけ。という形の実現を目指します。
安直な利用イメージとしてはこんな感じです。
gumstix ってご存じでしょうか？
昔、ぷらっとほーむで扱っていた時期もあった、チューインガムサイズの超小型Linuxボードです。当時、「これはすごい！」と購入したのですが、結局、日本ではメジャーにはなりませんでした。しかしながら、私はいまだにgumstixの小型でトランスフォーマーなコンセプトはかなり行けていると思っています。
で、なんとこのgumstixで、ついにAndroidを動かすのに成功した方が現れました。
かなり時間がかかっていますが、確かに上がっています。
液晶を取り外せば、間違いなく世界最小のAndroidマシンだと言えると思います。すごいですね～♪
Google Android Hackathonに参加してきました。
初めてのHackathonだったのですが、明らかに準備不足でチームのメンバーには迷惑をかける結果となってしまいました。この場を借りてお詫び申し上げます。
作ろうとしたのは、Ｉｄｅａｔｈｏｎでお題になったスカウター（Android + Nikon Media Port UP)です。ＧＰＳチーム総勢５名で取りかかりました。私は、サーバ側を担当し、予定では１時間ぐらいで完成して、Ａｎｄｒｏｉｄ側の作業に取りかかる予定だったのですが、Djangoのmodelの使い方がよくわからず、つまらないところで何時間もハマッてしまいました。できあがった時は、すでに発表３０分前という状況で、一行もAndroidのコードを書かずじまいで、何をしに行ったんだか。。。という結末でした。
みんなが頑張ってくれたおかげでかなりいいところまで来ていたのですが、最後はモックで発表という残念な落ちとなってしまいました。技術的な問題点はすべてクリアできたのが締め切り１０分ぐらい前。(^^; たぶん、もうちょっとあれば完全に完成していたと思います。
また、最後発表をまかされたのですが、精も根も尽き果ててしまい、ろくなトークができず、完全に失敗してしまいました。
もし、またHackathonが開催される事があれば、是非、リベンジをしたいと思っています！
一緒のチームで戦ってくれた皆さん、これに懲りずに、また機会があればよろしくお願いします！
＃Hackathonにおいて時間内に完成できなかったときに、あれほどの脱力感を感じるとは。。。いゃ本当に疲れました(^^;
先日、Google の Android Ideathonに参加してきました。
場所は、これまでテレビ等で見てきた、Google 東京オフィス。初潜入してみて、いろんな突込み所が一杯あったのですが、極めつけは入り口になぜか、ゲーセンにある「電車でGO」が。。。Googleのスタッフに写真の許可を得ようとして、忘れていました。来週、またいくのでだめもとで聞いてみようと思っています。(^^
Andoridの会のスタッフのみなさん＋googleスタッフの方＋３０名程の参加者という形でスタートしました。流れとしては、来週のHackathonで作りたいテーマ別に班分けをして、各班でアイディアを戦わせみんなで投票。優勝班にGoogleのTシャツプレゼントという趣向でした。私はGPS班に入り発表、テーマは「Android + Nikon Media Port UP＋オープンソーシャルでスカウターを作る」でした。結果はというと２位で惜しくもTシャツはGETならずでした。(^^;
本当はこのIdeathonで多くの人の意見を聞きたかったネタは大量にあったのですが、結局、出せずじまいでした。以下、今後、私が個人的に作ってみたい主なアイディアです。
もし、これをご覧になられた方で、「面白い！」と思われる方がいらっしいましたら、一緒に遊んでみませんか？
少し前になりますが、Google の GDriveの話題がありました。GDriveがもし一般にリリースされると何が起こるか？単にファイル置き場としては当然いろんなアイディアがあるかと思いますが、期待するのはネットワークブートじゃないでしょうか？PXEじゃ役不足なので、新しい何がしかのロジックの登場に期待したいところです。気が付くと、全マザーボードメーカーのBIOSでGDriveネットワークブートが標準で実装されたりして。。。
そうなってくると、その先に何が起こるか？やっぱり、ライセンスにこだわる有料OSは、徐々に排除されそうな気がしてきませんか？
「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に送ったのですが、ちょっと気分はユニバーサルソルジャーです♪
