「 組み込み 」一覧

Interface 2013年9月号 マイコンボードとHTML5特集

Interface (インターフェース) 2013年 09月号 [雑誌] Interface (インターフェース) 2013年 09月号 [雑誌]

CQ出版 2013-07-25
売り上げランキング :

Amazonで詳しく見る by G-Tools

特集目当てで買ってみた。

フィジカルコンピューティングとか、センサーとマイコンボードを組み合わせてとかは、mbedやRaspberry Pi、Beagle系とかデバイスもいろいろと登場してけっこう盛り上がっているようで自分もそこに参戦したかったのだけど、この1年くらいはできずじまい。

今号のInterface誌の特集ではHTML5推しで、なんでもできますよみたいな推し方なんだけど、HTML5ってそこまでいろんな環境できちんと動くほどの状態にあるのだっけか。ブラウザ依存とかまだまだあったりしないのかな。まぁ早かれ遅かれその辺も解決するだろうから今のうちから触っておこうということなんだろうけど。

福岡に戻って、もし時間に余裕がある状態になったらこの辺にも手を出してみたい。


エンベデッド試験 合格

もうダメだと思っていたのに、少し予想外。

合格発表は金曜日だったけれど、肝心の受験番号が書かれた受験票を先月、福岡に帰ったときに一緒に持って帰ってしまっていたので、試験センターに電話で受験番号を問い合わせ。氏名と受験会場と生年月日、住所を伝えるとその場で教えてくれた。

それにしても午後2がボロボロだったのに合格してたということは、配点などで調整が入ったのかもしれない。ネット上でも午後2は難しかったというのを多く見たのでおそらくそうだろう。

ほとんど諦めていたけど、デスマなプロジェクトの合間で勉強して受験しにいった甲斐はあったということか。


エンベデッドシステムスペシャリスト受験

朝5時半に起きて、少し早めに会場の名古屋大学へ。刈谷からなのでそこそこ移動に時間がかかる。

DSCN1308

情報処理試験を受験したのは、なんだかんだで4年ぶり。若い頃は春秋ほぼ欠かさず受験していたのに、4年もブランクが空いてしまったのか…。

参考書を買ったのは2月とはいえ、今回も仕事がデスマ気味の中で準備は万端とは言えない状況。まぁ本気で勉強する時間を作ろうと思えばもっと作れたとは思うのだけども…。

前回のエンベデッド受験では午後1で脱落だったわけだけど、今回はどうだったか。

前回受験した時と少し異なる感じがしたのは、ITSS/ETSSに準拠や新シラバス対応になっていて、ESの午前2でも経営系の問題が出るようになった(前回もあったかも?)とかですかね。

午前1

午前試験は、前回受験時でも高得点だったのでそこまで不安視はしていなかったものの、午前1は他区分と共通なので割と幅広い範囲から出題されるので、参考書を読んで一通りは復習しておいた。

ただ最後のほうの経営系、マネジメント系の問題は用語も初見だったりするものもあって自信なし。問19、問23、問26、27、29あたり。

まだ答え合わせしていないけど、ボーダーは超えているはず。

午前2

午前2もそこまで不安視してないけれど、4年も前だと論理回路や計算問題は記憶が怪しかったので、これも参考書読んで復習はしておいた。

けれど、マルチプロセッサ、マルチコア系の問題は参考書でもあまり見かけず、ちょっと面食らった。問2、問4。

過去問そのままの問題もあったりしたものの、すべて覚えてるわけでもないので、問8も過去問で見たような気もするけれど、解答自信なし。問13の半導体の3次元実装技術もちょっと戸惑ったかな…。

おそらく午後2もボーダーは超えてるはず。答え合わせは近々にするつもり。

午後1

前回脱落の午後1。前回はガスメーターとウォシュレットの問題で時間内に全部解答できずに撃沈したわけだけど、前評判を見ても午後1はだいたい時間ギリギリな問題ボリュームなのが常のようだ。

今回の選択問題は問2のポータブルナビを選択。問1と併せて全く正解が思いつかない設問は無かったものの、計算問題でかなり手こずる。昔は電卓使えてたのにね…。筆算でかけ算・割り算なんて普段しないから途中で位取りとか間違えないかヒヤヒヤする。

今回の午後1は時間内に解答は全て書くことができたけど、やっぱり時間はギリギリ。残り5分を切っていたような。

解答した感触からすると、おそらく今回はボーダー超えてるんじゃ無いかと思うのだけどね…。微妙に記述式の解答でキーワードが入っていないとか、そういうミスが無ければだけども。

午後2

今回の鬼門は午後2だった。

問2のヒートポンプ式給湯器を選択したのだけど、正直、全ての解答を埋めることができず、おそらくダメだと思う。どう考えても6割正解できてると思えない。

試験開始前に解答用紙が先に配られた時点で、問1と問2の回答欄の数がけっこう違うのが気になっていたのだけど、それでも解答欄の多い問2のほうがソフトウェア寄りだったので選択。

それが裏目に出たのか、120分という試験時間では足りなかった。計算問題も時間を使ったし、そもそも問題読んでも何を解答すれば良いのかイメージが湧かなかった問題もあったし、解答したものの要求された文字数に達してなく、何か解答漏れがあるパターンなど…散々。

あともう1時間、試験時間があったら9割くらい埋められたかも、というレベル。

120分かけてあれだけ問題を残してしまった、ということが自分でもショックで、実はだいぶ凹んでいるのです…。

ただ、ネットの掲示板とかを見ていると、この問2は難しいと思っている人が多かった模様で、同じ思いをしてる人が多いというのは本当に問題の難易度が高かったのかもということだけど、それでも点数が増えるわけでもないだろうからねぇ…辛い。

午後1までは万全とは言えないまでもボーダーは超えたかな、という感触であとは午後2さえ行ければ!という勢いだったのが、玉砕した感じ。

ふと残り30分で未回答の問題の量と見比べて、この時点でああダメだ間に合わない…と悟ってからの終了までの30分は辛かった。負けが見えてる勝負をやってる感覚。でも途中で投げ出して退出するというのは嫌いで、昔から今までやったことないし悪あがきで1問でも多く解答を書こうとしたけれど、残した問題がどれも大変で…。

問1選んでればいけたのかなぁ…。リレーとか抵抗とか回路系の問題っぽかったのであまり問題見ていないけど。

その他

そういうわけなのでまた来年、ですかね。ちょっと会社関係で資格取って申請すれば色々できたのでそれを狙っていたのだけど…。

せっかくなので秋試験も何か受験する方向で考え中。おそらく午前1免除にもなると思うので、セキュリティスペシャリストかな…。

あと、会場の名古屋大学。行くのは最初で最後だろうけど、綺麗で広いキャンパス。ざっと歩いた感じでは建物も比較的新しいのが多くて綺麗だったね。

4月の新入生シーズンだけあって、掲示板にはサークルの募集ポスターがたくさん。私は専門学校卒なので大学生の経験が無いので、こういう資格試験で大学が会場だったりするといつも物珍しい気分になるのよね。

IMG_20130421_164310


EPG処理のミス?で録画できなかった録画機

TBS「とんび」で騒動勃発!“録画失敗”でシャープに苦情も…食い違う見解(ZAKZAK(夕刊フジ)) - エンタメ - livedoor ニュース

その昔、EPG周りの処理を扱うことがあったのだけど、きちんと番組変更に追従する処理を作るのが大変だった覚えがある。

EPGの規格としてはARIBという放送系の規格で決まってはいるのだけど、細かい部分は「運用で」などとなっている部分もあったりして、同じ番組延長というケースでも放送局によっては変更情報の出し方が微妙に違うとかあって…。

TBSはEPGの送出は問題なかったと言っているので真実は分からないけれど、EPGの仕様として番組の終了時間が時刻データではなく「未定」というデータを送ることができるのでそれを受けたときの後続番組の情報の扱いが良くなかったのか、何段階かに分けて延長、延長と変更情報を出しているうちに何か録画機側でおかしくなったのかなぁとか、一瞬でも後続番組の情報が放送局側のEPGデータから消えたりしてなかったのだろうか、とか想像するだけでいろいろケースが出てくる。

もしこれはバグだとしたらやっちゃってるなぁ…でももしEPGの変更情報の出方もイリーガルだったりしてたら…。

とはいえ、今回のケースは結果的にはSHARPのソフトの作り込み、テスト不足、もしくは元々の仕様として想定したケースに合致しなかった、ということになるのだろうけど、EPGの番組延長や短縮、番組の中止などの編成変更に追従する仕様と処理はかなり面倒だった記憶が蘇ってきたので書かずにはいられなかった。


RGB565画像を作るならGIMPが使える(C言語ソースも出力可)

RGB565の画像データを必要とするケースというと、主に組み込みでVRAMに書かないいけないとかそういうケースがほとんどかなぁと思うので、割とニッチではあるのだけど仕事などでやっているとたまに「さくっとPCでテスト用画像を作ってRGB565にしたいなぁ」と思うことがある。

とりあえずちょっとしたテスト用として、C言語のソースにバイナリデータとして埋め込んで動作させたいとかいう時もあるかと思う。

何か使えるツールはないだろうかと探していたら、GIMPが使えることが分かった。

分かった、と書いているけどGIMPでRGB565でのC言語ソース出力の機能は最新のGIMP2.8の一つ前、2.7から搭載されている機能らしい。

とりあえず方法。

1.絵を描く

Clipboard01

必要な幅高さなどの条件で絵を描きます。他の画像ファイルを読み込ませても良いはず。

2."Cソースコード"形式でエクスポートする

Clipboard02

メニューから、「ファイル」→「エクスポート」を選択すると画像の出力形式を選ぶ画面になる。ここで「ファイル形式の選択」で"C ソースコード"を選択する。

3.出力オプションでRGB565を選ぶ

Clipboard03

Cソースコードで出力を選ぶと、このようなオプション画面が出るのでRGB565形式で保存、のチェックボックスを入れる。他の項目はお好みで…と言いたいところだが、どうもGIMPのバグなのか?チェックボックスの組み合わせによっては、RGB565形式で出力されないパターンがあったので要注意。

出力結果

Clipboard04

このように幅、高さ、1ピクセルあたりのバイト数、画像データが構造体の形でファイルに出力される。

このまま使うも良し、必要に応じてデータ部のみ抜き出して使うも良し。

注意点

・出力オプションで"structではなくマクロを使う"を選択すると、#define部がRGB565形式で出力されない。(データ部はRGB565で吐かれている)
・出力形式を"Cヘッダファイル"にするとRGB565では出力されない

バイナリで出力したい場合はどうすればいいのだろう…。Windows BMP形式だとRGB565で出力するオプションがあるので、いったんBMPで出力してBMPヘッダを削ればいいのかな…?


組み込みの現場でRTOSベースの既存システムをAndroidに移植しようとした時にありがちなこと

今の仕事は、いちおうAndroidをプラットフォームにした仕事ではあるのだけど、もともと組み込みのRTOSベースのシステムを移植するようなプロジェクトでシステムのアーキテクチャはAndroidというより"組み込み"の考え方。過去「スマートフォン開発もやっぱりデスマか」でも書いたのに似ていて以下のような感じ。

  • 他社から出てくるモジュールのJavaレイヤのI/FがC(Native)レイヤの関数をそのままラップしている
  • RTOSアーキ時代のタスクがそのままAndroidのSerivceになってる
  • Service間やActivityの間でやたらと非同期の呼出しや通知が多い
  • RTOS時代はこの方式で上手くいってたので、と押し切られる

他社から出てくるモジュールのJavaレイヤのI/FがC(Native)レイヤの関数をそのままラップしている

例えばJavaレイヤに、int xxxFunc(byte[] data) のようなI/Fが提供されて、引数byte[]に自分でバイナリデータを組み立てて(しかもビット単位で)呼び出さないといけない。nバイト目のn~mビット目にはxxを指定する、のような。

システム内で広く使われる予定のコアなモジュールの割にはI/Fが不親切。既存のNativeライブラリがそういうI/Fだからということらしいが、ヘルパーメソッドくらい用意すべきと思う。

こういうケースは、

  • 担当者がAndroid(というかJava)の経験が浅いか無い
  • 単に期間的、工数的に楽になる実装にしたかった(ラップするだけだものね)

であることが多いように思う。

でもそのI/Fの使用者がシステム内の各所にいるような重要なモジュールなら多少はヘルパーなり呼び出しやすいI/Fで提供して欲しいところなのだが、要請しても必要性が分からないとか「今までのシステム(RTOS)はこうだったから」と言われてお終い。

経験上、こういうひどいI/Fを出して来るときの一番多い言い訳が「呼び出し側の実装の自由度を考えた」というのだけど、いちいち引数組み立てたりしないといけない実装を各モジュールで作らせるのが自由度とは思わないけどもね。

こういうひどい設計は、上手く呼び出し側の他社も巻き込んで「使いにくいから考え直せ」と攻めてみるのが筋だろうけども…。

RTOSアーキ時代のタスクがそのままAndroidのSerivceになってる

xxxxTask -> xxxxServiceに名前が変わって再実装。

モジュール分割がRTOSと同じ感覚でちょっと細かすぎやしないだろうか、というケース。AndroidのServiceが乱立するのもね。RTOS時代から関わってる人には同じ感覚で仕事できるからいいのかもしれないけど。

Service間やActivityの間でやたらと非同期の呼出しや通知が多い

RTOSのタスク間メッセージと同じ感覚でI/F設計してしまうから。

→"xx要求"
←"xx受付通知"(相手側が受け付けましたという非同期通知)
←"xx応答"(相手の処理が完了して結果が乗ってくる通知)
でワンセットになってたりするケース。

応答を受けるまでは次の要求を投げてもエラーになります、キューイングはしないので呼び出し側で管理してください、が割合多い。

確かに、ハードウェアまでアクセスするために応答時間が数100msかかる可能性があるので非同期処理、というのは組み込みでは多い。

RTOSならセマフォやシグナルとか駆使して実装するのがセオリーだろうけど、Androidだとメインスレッドはブロックできないし、I/Fを使う側としては呼び出しと応答後の続きの処理がソースコード内の離れたところになってしまう。なのでソースコードを見たときに処理が見通しにくい。

多少、ブロッキングするメソッドであっても同期型でI/Fを用意してもらって、使う側でスレッド立ててその中で呼び出すなりできるけどなぁとは思うけれど正解がよく分からない。

ただ、コールバックやスレッドを上手く設計しておかないと後からバグだらけの懸念。内部の状態管理もきちんとしないといけないだろうし。

RTOS時代はこの方式で上手くいってたので、と押し切られる

…今回のプラットフォームはAndroidなんですけど…?

開発メンバーにRTOS時代からずっと関わってる人が多いと、「今までのやりかたが最強」ということになりがち。上に書いてるように、モジュール構成とかI/Fの考え方を既存のRTOSでのシステムからそっくり持ってくるからってことなんだろうけど。

でもAndroidのアーキテクチャと合わない設計をして無理やり作り込んで後で火を噴かなければいいけども…。ActivityとかServiceのライフサイクルは考え方としてそれなりに特殊だし、Android Frameworkとの兼ね合いもどう付けるのか…。たぶん火を噴いた時にはさらにパッチ的な回避をしてどんどん複雑化していくのだろうな。

こういう感じのシステムだと

もはや作っているものはAndroidというよりRTOSの仕事をしているのと大差が無くなってしまっている。よく分からないxx管理タスクと先にやりとりしないとアプリの起動ができないとか、シーケンスを引いていくとアプリ層やService層でやたらとあちこちの"タスク"に対して複雑なシーケンスをこなさないと処理が進まない仕組みに。

いろいろ改善を試みて一部はとりあってもらったものもあるけど、もう既に各社で設計が進んでしまっててひっくり返すには遅すぎるし、プロジェクト内のパワーバランス的にこちら側の力が足りない。

たぶんこれは結合試験以降の工程で大変なことになりそうだ…。

1つの処理に対してシーケンスが多いからユーザ目線でのレスポンシビリティーが心配だとか、クロスシーケンスを各社どこまで事前にケアできてるかとか(下位レイヤは単なるラッパーレベルでしか作ってこないだろうから期待薄)、どこかにしわ寄せが来そうな気がする。

携帯電話開発の現場でも、ガラケーからAndroidスマホに開発がシフトしていく時に通った道ではあるけど、これからAndroidの採用が見込まれている色んなデバイスの開発現場は「Androidでの初物」の開発では同じ道を通っていくのだろうか。

せっかくAndroid経験のあるメンバーを投入しても、もう少しアーキテクチャや設計の考え方には、既存システムの開発に長けていて自負があったとしても耳を傾けたほうが良いと思う。数年前と違ってAndroidのエンジニアは大きく増えているしAndroidのノウハウを持った人間もたくさんいるのに、その意見を頭から潰していたら良い物はできないと思う。

既存のRTOSの資産やノウハウを流用するとしてもAndroidに載せたときにどうするのが良いのか折衷案は出せると思うし、あとあと火を噴かないために注意すべきこととかは上流工程で検討しておくのが良いはずだけど。

往々にして開発スケジュールに余裕が無いからなどの理由で既存をベースに流用すればなんとかいけるだろう、というのはどこでもある話だけれども、それで進めると設計、実装、単体テストあたりまでは一見うまくいく。けど、各モジュールを結合していくとシーケンスの不備、Android特有の動作、動いてもモッサリ、メモリ食い、Low Memory Killerで殺される現象などにきっと泣くことになる…と思うなぁ。


発熱問題

発熱問題の詳細を確認:ARROWS Z ISW11Fは温度が上昇しやすい仕様 - ITmedia +D モバイル

温度上昇それ自体は、おそらくどのメーカーの端末でも多かれ少なかれあるはずだし温度上昇した時に端末の一部機能が制限されるのも存在するけど、簡単に高温になってしまうのはどうなんだろう。

ハード設計側としてはソフトウェア側でクロックの動的制御などでできるだけ回避して欲しかったというのが本当のところかも。Wimaxを絡めた時だけ温度情報が激しそうなところを見ると

温度が上昇しやすい“仕様”であるため、ソフトウェアアップデートなどで改善されることもないとのこと。

というのもあながち間違いでは無いと思う。CPUの高負荷が原因での温度上昇なら一時的にCPUクロックを落としたりして何とかアプリが動くように倒すことができるはずだけど、通信系の場合はそうもいかなさそうだし。

筐体設計とか回路は素人だけど、熱設計とかどうしようも無かったのかなぁ・・・。兄弟機種と筐体をできるだけ共通化するような指示が出ていて、やりたくてもやれなかったのかもしれないけど。


キャリア自ら携帯端末向けチップ開発に

ドコモ、国内企業やサムスンとチップセット関連の合弁会社 - ケータイ Watch

”ガラパゴスチップ”にならなければいいけど。

メーカー側もQualcommなどの大手メーカーのチップを採用するのに比べてメリットを見いだせるんだろうか。

例えば市場への供給ボリュームの差から、ドコモチップは割高になって端末コストに跳ね返るとか、AndroidとかOSの移植に意外と手こずるとか、メーカーからしてみてQualcommで慣れていた”チップの癖”をハンドリングするノウハウが使えなくなって阿鼻叫喚とかなったりしないかな。

ベースバンド周りの事情は詳しくないけど、いま端末メーカーって3キャリアでほぼ同じハードとソフトウェアベースを使ってキャリア仕様の所だけを派生開発してるような体制だと思うのだけど、ドコモ向けだけチップが違いますよ、とかなると影響でたりしないのかも気になる。まぁ今でもauとSBM/Docomoで規格違うから分かれてるのかも知れないけど。

どうも、キャリア主導の「共通部品」的な何かは、auのKCP+と言い(ソフトウェアだけど)、大変なだけで上手くいかないというイメージがあるのだが・・・。ドコモは研究所で次世代プロトコルの研究開発をやっているのでその延長線上という考え方もできるし、LTEもLTE-Advancedも世界規格ではあるので海外にも販売できればまた違ってくるのかな。


REGZA Phoneの不具合原因からいろいろ想像

ドコモ、「REGZA Phone T-01D」の通話・通信できない不具合の原因を発表 - ITmedia +D モバイル

バッテリー残量が5%以下に著しく低下した際、または初回電源投入時に通信できなくなる場合があるという。

あくまで想像であまり当たってる感じはしないけど、REGZA Phoneに限らず国産Android端末ならありそうなことを思い浮かべてみた。

初回電源投入時

端末初回起動時は、端末内の各アプリやモジュールが「初回起動時だけ」行う初期設定を走らせることが多い。

例えばアプリが自分で使うデータベースを初期化・生成したり、設定ファイルを作ったり初期データを作ったりなど。これらの各アプリ・モジュールの処理が初回起動時の起動直後に一気に走り出すので、端末は高負荷となり想定より初期化処理にかかる時間が長くなったりする。

そうすると、モノによっては異常と判断して初期化処理を中断してしまったり、ANR(Application Not Responding:応答なし)が発生して「強制終了」ボタンを押されたりして想定外のところで処理が中断されるケースが出てくる可能性がある。こうなると重要な初回起動時処理が正常に完了していない状態になるので、アプリやモジュールが異常動作したり、落ちたりするようになる。

リカバリ処理をきちんと実装していない物は、電源を入れ直しても中途半端な状態のままで起動してしまうので復旧することができない…。工場出荷時状態に戻すかショップ交換になったりする。

「初回起動時」しか動かないロジックにどこまで完璧なリカバリ処理を実装するか、となるとなかなか日の目を見ないところで、実装されなかったり、弱かったりする。

初回電源投入はショップ店員がやるから問題が出る(変なタイミングで電池抜かれるとか)ことは少ないだろうとか、一見データベースファイルなどが生成されているようにプログラム上から検知されるのだけど、データやファイルが壊れていて特定のアクセスをするとその時に落ちる、など「異常」のパターンが色々あってそれをチェックするのは意外と面倒だったりする。個人的にも、とても確率が低いながら設定ファイルが正常に作成・更新されないという市場不具合に当たったことがあり、調査したりなんだりやったな…。

初回電源投入は開発時でも良く行う(端末焼き換えして初回、は普通にやる)のでテストできないわけではなく、考えるとよほど確率の低いケースで不具合がでることはあると思うけど、このREGZA Phoneのように高確率で発生するとなると初期設定だけの問題では無いのかもしれない。

バッテリー残量が5%以下に低下した際

バッテリー残量が低下すると、動作を止めたり、起動しないようにする処理が入っているアプリやモジュールがある。「電池残量が少ないので充電してから起動してください」みたいに言われるアプリとか。プリインアプリには多いのではなかろうか。

これは突然の電池切れ(電源断)による予期しないタイミングでの終了を避けるためが多く、アプリによって5%だったり10%だったり20%だったりとリミット(閾値)が違ったりする。

「処理中の電池残量低下」でリミットを超えると、処理を止めて自分を終了したりするわけだけど、その時の終了のさせ方が悪かったりすると、上に書いた初回電源投入時のように中途半端な状態が残ったままになり二度と正常動作しなくなることがある。電源を入れなおしても現象が改善しない場合はだいたいこの「中途半端で終わってしまって次回起動時にリカバリできない」パターン。

そうでなければ、充電して電源を入れ直せば復帰するものも多いはず…。

あとは何もユーザーにメッセージを出さないまま、電池残量が少なくなったので起動を止めてしまう場合だと、ユーザーから見ると「よく分からないけど動かない、故障?」と思われる可能性はあるかも。

現場は

ともかく原因が分かって良かったね、というのと同時に、ドコモから相当きついクレームがメーカーに入ってるだろうことは想像に難くなく、中の人は眠れない日々だったんじゃないかと。販売停止レベルの不具合だと、ドコモにメーカー担当(偉い人も?)がずっと詰めててリアルタイムで状況報告上げないといけないとか、メーカーの現場(と下請け)もおそらく寝ずに調査と修正してるとかはありそう。

携帯開発やっていると、キャリアの人がバグを見つけるとメーカーに対してすぐに報告書と再発防止策、なぜテストで見つからなかったか、どんなテストをしたのか詳細に書いて提出しろ、みたいな話になりがちなので大きい不具合が起きた日には…。

個人的にもこういうケースは人ごとでは無かったりするので、気をつけないと。


Android Make Days in 明星和楽に行ってきた

いやー、凄かった。

AndroidとMakeというテーマで福岡でイベントをやって、あれだけの人が来るってのが凄いし、スタッフの動き、会場の熱気を見ていて「あ、これ九州版ABCみたいだな」とも。

もちろん、ABCとは規模は違うけれどやってることはほぼ変わらない。講演あり、展示あり、LT、ハンズオンありのてんこ盛り。

開会/基調講演 日本Androidの会会長 丸山不二夫氏

2011-11-12 13.14.06
丸山先生の講演。いつものようにクラウドやApple、Amazonの話題など大きな範囲からの話題から始まってAndroidは後半で、のパターン。

ただ今のIT業界の潮流の中を見た上で、Androidの立ち位置、そしてAndroidが出来ることを知るには良い構成と思う。ほんとに、日々状況は進化、変化していってるなぁというのを、凝縮して聞くとよく分かる。

GClue 佐々木氏

Androidとガイガーカウンター

2011-11-12 14.04.56

震災以降、ガイガーカウンターを有志で作るっていうのがたくさん出てきたけれど、ADKがあるAndroidというプラットフォームはハードウェアとアプリを介してネット・クラウドに繋げることがやりやすいのがメリットということ。

それこそ、ハードの部分はアイデアやニーズ次第でバリエーションはたくさんあるだろうし、そこで収集したデータをWebサービスなどを使ってどう公開、集計したりするかというのもバリエーションはたくさんあると思うし。

2011-11-12 14.26.31

R246氏

モテるtwicca ~モテるアプリを作るための4つの心得

フリーであれだけの開発モチベーションを維持するには、使いやすいアプリにするにはどうするかってのが、ぷんぷくり~ん、なんて言いながらも要所要所で大事なこと言っていて、あぁやっぱり裏にはしっかりした考え方を持っているからだなぁと。

ブリリアントサービス 杉本氏

AndroidとNFCがなぜやばい?

個人的には「その発想は無かった」。

言われてみれば確かにその通りで、NFCを使ってのポイントシステム、さらに相互利用の仕組みを押さえてしまえばそれはすなわち「通貨」だよね、と。そこをビジネスとして押さえることができると…。

JuJu氏

フィジカル・コンピューティング~あと一歩のときの電子工作~

「どこのご家庭にもあるサーバw」を使ってのホームオートメーションの話…という建て前で、主にリモコンとの格闘の歴史のような話題に。

でも電子工作の知識は持ってて損は無いよなぁといつも思う。自分はソフト屋だけれどハードの知識があって回路設計とかできたらどんなに楽しくて可能性が広がっただろうかと思ったことは学生の頃から数知れず。コンピュータに出会うのがもっと遅かったらもしかすると電気系行ってたかもしれないし。

でも今の時代はそういう「電子工作やりたかった」層にマッチするArduinoとかが出てきているということだよね。ソフトを書いてそれで回路を制御できる、っていうソフト屋にも理想的な環境。だからもっと触って遊んで楽しみたいんだけど。

phytonicide氏

個人開発のすすめ~もうひとつの土曜日の過ごし方

twiccaのR246氏もそうだけど、やっぱり「使いやすいのが無かったから自分で作った」という動機がいちばん開発が長続きするし、使いやすいアプリに成長していくのかなぁという気もする。今でこそAndroidマーケットには国内、海外を問わずアプリが溢れていて色んなジャンルで「定番」のようなアプリが出てきているけど、それでもちょっと違う角度だったり少しニッチなものだとまだまだ「痒いところに手が届く」アプリが見当たらないのも実状かと。

そういう隙間と、自分自信のニーズがあうのなら、アプリを作って公開してみると良いのかも。ひょっとすると他の人も同じようにその部分を埋めるアプリを欲していたかもしれないし。

コンテスト発表

Android Make Daysの前日夕方から始まっていた24時間でアプリを作るコンテストの発表。

私自身はハンドベルのアプリが出てきた時点で、これが優勝かも…と思った。テーマ「愛」に多人数を巻き込んで力を合わせて合奏するというコンセプトはぴったり合っているし、アプリ側だけでなくサーバ側もどの音色がどれだけ選ばれてるかバランスを取るための機能を作り込んでいたりして芸が細かかったから。

他のアプリも限られた時間の中で発想(とネタ)を凝ったものが多くて非常に楽しめた。

展示ブース

どこからこんなに各企業さんを引っ張って来たんだろうと思うほど、モトローラやソニエリ、NECビックローブ、DeNa、KDDIなどが出展。

最初は人の集まりがどうかな?と思っていたら基調講演後には以下のように大盛況。
2011-11-12 13.57.56

Make系の展示ということでロボットもあれこれと。

こちらは前も一度ブログで紹介したロボット。
リモコンもAndroidデバイスで、ロボット側にもBeagleBoard+Android+制御基板でアームや付いているWebカメラの制御をしているもの。けっこう細かく、滑らかに動くんですよね…これ。
2011-11-12 12.49.19

こちらはAndroidの会神戸支部の出展。大きなほうのロボットは大阪からHTTPをロボットに直接飛ばして操縦しているんだそう。少し遅延はあるもののちゃんと動いてました。
2011-11-12 15.33.19

あとはMTMなど数々の出展実績のあるJuJuさんの展示。
いつもながら、動的に組み替えが出来るマトリクスLEDのデモはインパクトありますねぇ。
あと、レゴを基板の受けに使ったものも。聞くと「レゴの穴にちょうどLEDが上手い具合に入るから」だそう。なるほどー。
2011-11-12 12.39.28

その他

LTはほかのセッションを聞いていてほとんど見れていなかったけど、いろいろ面白いことをやっていたようで歓声とか笑い声がセッション会場にも聞こえてた。
2011-11-12 16.27.32

Arduinoの体験ハンズオンも2回に分けて実施もどちらも満席だった様子。少しでも興味持ってもらえるといいすね。そしてMake系に足を踏み入れ…みたいな。
2011-11-12 14.27.55

閉会

何ヶ月も前から準備、そして当日会場を忙しく動き回っていたスタッフの方々が勢揃い。私は何にもお手伝いできなかったけど、皆さんすごいよ、ほんとに。

スタッフ用のfabebookグループは本当にたまにしか見れなくて、当日会場に行くまでこんな規模のイベントだったとは思いもしなかったもの。設営もスケジュールも講師陣も出展者も本気レベルだったし、参加した人数も福岡のイベントの中では多い方だったんじゃないだろうか。会場行ってビックリしたもの。

2011-11-12 19.04.36

懇親会

2011-11-12 19.29.29

スタッフはもちろん、参加者の人もたくさん残って懇親会。こちらも大盛況でしたねぇ。

懇親会の最後まで残っていたら、zeemoteもらった。
2011-11-13 13.00.14

感想

よく鉄道マニアが電車に乗ったり写真撮ったりして「鉄分補給」なんて言ったりするけど、今回の場合はコミュニティのパワー「コミュ分補給」「開発意欲補給」といった感じがピッタリな雰囲気だったと思う。

きっと参加した人の中にもそれぞれ刺激を受けたりモチベーションがアップした人が多いんじゃないかなぁ…と思って終わったあとのtwitterを見ていると、やはり刺激を受けた人は多かったみたいで、いろいろ開発熱、Make熱が盛り上がりそうな予感。このトレンドが冷めないうちに小規模なフォローアップイベントをやってみるというのも悪くは無いかも。せっかく新しい層の人たちにもリーチできたと思うので、その人たちを巻き込まない手は無いかなぁ。

それにしてもスタッフの皆さんは、これだけの規模のイベントを準備して運営してと、本当に頭が下がります。お疲れさまでした。

あとルビセンはこういうイベントにはうってつけの設備なんだな、と。おそらく会場費はそれなりにかかったとは思うけれど、設備と機材が使えて博多駅近くのあの場所、というのは大きいような気がした。福岡はAIPCafeといい、場所に恵まれているのかもしれない…。

あと、当日のUstreamの録画が以下で見られる。
http://www.ustream.tv/channel/androidmakedays/videos
http://www.ustream.tv/channel/androidmakedays2


スポンサーリンク