読者です 読者をやめる 読者になる 読者になる

僕のYak Shavingは終わらない

車輪の再発明をやめたらそこには壮大なYakの群れが

IoT製品の生産でIoTする #builderscon / Akerun Advent Calendar 3日目

f:id:kazuph1986:20161203110527j:plain

これはAkerun Advent Calendar 3日目の記事です。 一昨日・昨日に引き続き kazuph が担当します(`・ω・´)ゞ これで一旦休憩です。

つい先程ですが、こんな内容を発表しました。

Akerunを製造する際のツールをIoTでつくったという話でした。

builderscon.io

会場の殆どの人がAkerun知っていたし、Twitterとかみると好評でだったみたい良かったです。 新婚旅行を早めて発表した甲斐がありました(汗)

ソースを使った説明が少なかった分は、今後のAdventカレンダーにご期待下さい!










ちなみに新婚旅行は京都でした。

f:id:kazuph1986:20161130174807j:plain

京都でした。

f:id:kazuph1986:20161201145838j:plain

京都でしたね。

f:id:kazuph1986:20161129172547j:plain

京都です。

f:id:kazuph1986:20161201111134j:plain

最高でした。

IoTの開発に必要なグルー思考 / Akerun Advent Calendar 2日目

これはAkerun Advent Calendar 2日目の記事です。 昨日に引き続き kazuph が担当します(`・ω・´)ゞ

今回は自分が日頃意識してる”グルー思考”の話をしたいと思います。 ポエム度高め注意です。

グルーは糊、組み合わせ思考で解決策を考え出す

glue / glu: / 接着剤、またはくっつけること

IoTは様々なレイヤーの組み合わせで実現していますが、そもそもなんでハードウェアをつくろうと考えたかで言えば、解決したい問題がありかつそれがソフトウェアだけでは解決困難なものだったからです。

「鍵をデジタルにしたい」

これを解決するために、きっと今までのようにWebエンジニアとして生きてきた自分の思考なら、ハードウェアを開発して解決しようということまでは考えなかったと思います。 今までは”自分ができること”に思考が支配されていましたが、それが仲間を集め「必要ならハードウェア開発することが可能」な状態になったことで、思考の幅がグンと上がりました。

つまり色々なスキルを”くっつけ”合うことで、できることが幅が広がったのです。

できないことへの無意識のフィルタリングを外す


人間は最適な解決策があっても、”自分”が”できる”じゃないと見て見ぬふりをしてしまうものです。 僕達が開発した「Akerun」というスマートロックは”みんな”で”できる”になったから発想として具体化し実際に世に出ました。 これは自分の頭だけでは実現できなかったことなので、素晴らしいことだなと思います。

ただし、もちろん最初は”できる”が本当の意味でできる状態ではなく”できそう”くらいから始まります。 “できそう”だったらまだいいのですが、”できない”と思ってしまっていることへは、はやり人間は対処が難しいです。

若いときは往々にして”できそう”が”できる!”に倒れてくれますが、年を取ると”できそう”なのに”できない”に倒しがちです。 その方が疲れないとか、お金がかからないとか、家庭が平和になりそうとか、そういう過去の経験則からそうやってしまいますが、それこそ老害への一歩ということで、もし”できそう”を”できない”に倒してしまっているときは”本当にできないか?”を自問自答したいと思います。

話がそれましたが、”できそう”では例え若くても”できない”と思ってしまったり、”できそう”だから挑戦してもやってみたら”できなかった”ということも多くあります(そうして丸くなる)。 それを解決する自分なりの方法は、「常に自分のできることを常に増やすように行動する」です。

“できそう”だなと思っても”できるかわからない”と人間は行動に移せない言い訳を探してしまいますが、”過去にできた”ことがある経験があると、一気に”できそうが””できる”に変わります。 過去に実際にはやったことがなくても似たようなことをやったことがあるだけでも違いますので、”できた”ことがなくても”できるだろう”くらいには昇格できると思います。 課題を見つけたときに“できそう”と思ったあと、できるだけ素早くそれが”できる”になる人はやはり強いです。

「Akerun」をつくったときも電子回路については大学時代に勉強したことがあったので、”できそう”が”できない”に倒れることはありませんでした。

学生時代に「今は意味はわからないかもしれないけど将来役に立つことがあるから」と先生に教わりながら勉強したことは無駄ではなかったんです笑 そのために常に今は使わないことでも色々勉強して触っておくことが重要かなと思います。

自分の立場を一歩捨てて思考してみる

自分は長いことWeb・iOSエンジニアとして活動してきて最後に組み込みをやりましたが、それによってエンジニアとしてはどっちつかずなアイデンティティになったと思います。 ただ一時期割りと長い期間iOSエンジニアをやっていたためか、思考が偏り課題を解決するためにiOSを使うケースが多かったとも思っています。

それは今もそうだし、実際社内の運用ツールをiOSで爆速で実装できるのでうまくことも多いのですが、そのせいで最高の解決策を導き出せてないと感じるときもあります。

細かい話でいうと、iOSはBLEデバイスに接続する場合にMACアドレスでフィルタリングできないのですが、Androidならできます。自分はAndroid自体の開発経験もあるのですが、今では相対的に慣れてないために選択肢に上げないことがほぼほぼです。

これはいつももったいないことだと思っていて、なにが最適な解決策なのかの前に自分のスキルを持ってきてしまっていることです。 ”iOSエンジニアとしての自分”を捨てれば今からでもちゃんとAndroidを習熟し直して、最適なツールをAndroidで書いてもいいのです。

何が言いたいかと言えば、何かをやるときに自分の立場や利益を大事にしてしまいがちですが、他の人にお願いすることで本当に価値のある解決策を導き出すこともあるということです。

今回のAkerunではまさにソフトだけでは解決できない問題をハードのメンバーとも一緒に解決しました。 スマホアプリだけでは解決できないけど、ハードをつくれば解決することは世の中には結構あります。

自分が一番得意な解決策に固執しつせず、多レイヤー、多分野、多視点で思考できるといいなぁと毎回思います。

まとめ

簡単ですが、自分が普段意識しているグルー思考について書いてみました。 一つのツールや一つのスキル、一つの思考にとらわれず常に自分を広げながら”できない”をことを減らす行動をすることで、IoTでの開発もスムーズに行くのかなと思います。

ということで今日のポエミーな話を終えたいと思います。

明日の担当も僕です!お楽しみに!

IoTの開発に必要なスキルセット Akerun Advent Calendar 1日目

IoTの開発に必要なスキルセット / Akerun Advent Calendar 1日目

記念すべきAkerun Advent Calendarの第一日目は、スマートロックロボット「Akerun」を開発している株式会社PhotosynthのCTOの @kazuph が担当させていただきます。

今回はBLEを含むIoT製品制作のための設計に必要な能力の話です!

まずすべてを見ることをあきらめて仲間を探す、そして頼る

どんなプロダクトもそうかもしれませんが、取り分けIoT製品はカバーしないといけない領域が普通のWeb系のプロダクトに比べて膨大です。

インフラやサーバーサイドでのアプリケーション開発の能力はもちろんのこと、Bluetooth Low Energy(以下BLE)を使うなら、BLE自体の規格の知識とiOSAndroid自体の開発スキルに加えてBLEまわりの開発スキルが必要です。

ここまででも全体の1/3〜1/5くらいのカバー度。

そして問題のハードウェア部分の知識は、IoTの”I”の部分の量かそれ以上あり、かつネット上に落ちてないことがほとんどです。

最近ではハードウェア関連の情報もネットに落ちる始めて来たかもしれませんが、大手メイカーの中にある情報はまだまだ大きく、何回もサイクルを回してきたなりの経験と実績があります。

そのような知識を今この瞬間Webエンジニアである人が集めようしても難しいものがあります。そして僕自身、習得のための膨大な年限をかけた車輪の再発明をする無駄を考えると、1人では匙を投げていたと思います。

だからこそ、IoTという製品をつくるときは仲間が重要です。

最近ではハードウェアのものづくりなどの知見を共有し合う品モノラボというコミュニティ(http://www.ashita-lab.jp/tag/%E5%93%81%E3%83%A2%E3%83%8E%E3%83%A9%E3%83%9C/)があったり、DMM.make AKIBAなど人と人をつなぐことでまさにネットだけでは習得できないであろう知識を得る場があります。

もしこれからハードウェアをインターネットに接続して何かやりたいと思っている人は、まずはすべてを自分でやろうとせずに、仲間(そうでなくても話の聞ける相談相手)を見つけるところから探してみてもいいかもしれません。

IoT製品のソフトウェアの設計

ということで、暗に僕自身はIoTのすべてを把握しているわけではないという言い訳を言う土台ができたところで、Web出身者である僕がIoT製品を設計・開発するために必要だったスキルセットを並べてみたいと思います。

Web関連の知識と実装経験全般

この辺はこのカレンダーに気づいて読んでくれている読者の人たちは大体Web系だろうということで雑にまとめます。 例えばAWSでサーバー構築して、Railsでアプリケーション開発ができ、ついでにスマホアプリの開発経験があれば十分です。

あとは、Webまわりの設計を過去にどれだけやっているかで、IoTのプロダクトについても同じような勘所で思考すれば設計できると思います。 結局は相手側の要件定義がしっかりしているかの話が重要だと思います。

(仕様上必要なら)BLEの知識と実装経験

BLE自体は必須というわけではありません。ハードウェア自体に3G/4GやWi-FI搭載させているケースも多いです。 ただし、IoTという言葉が流行る背景に、沢山のセンサーデバイスがBLEによってボタン電池程度でも実用的な稼働時間になった、という部分があるので、BLEも考慮することで届けたい価値の実現性が上がることがあります。

BLEではない通信規格ももちろんあるのですが、現在販売されているスマホにはBluetooth(BLE)しか積まれてないものが大半なので、スマホの連携まで考えると必須になって来ます。

ですので、デバイス自体の電池寿命やスマホとの連携を考慮する必要がないのなら、あまり必要にはなってこないかもしれません。 開発コストでいうならば、BLE自体の概念を理解し、ハード側のチップでの実装に加えiOS/AndroidでのBluetooth制御、そして多端末対応までも行うことを考えてもこれだけで膨大になります。 人件費含めた出費を抑えたいのならBLEありきの設計にそもそもしないということも考慮に入れてもらえればと思います。

組み込み(ファームウェア)の知識と実装経験

組み込みの場合は、まず仕様するチップ/マイコンを選定し、それで動作するようにCなどのプログラミングを行います。 ベースとしての組み込みC言語の知識に加えてチップごとの開発環境構築・独自の仕様の理解が必要です。

BLEのチップについても、チップの製造元によって完全に開発の方法が変わってきます。 この辺で使いやすいものを選ぶことで、後々の開発のスピードが変わってきます。

半年ペース後くらいには、また別の良いチップが発表されていたりするので、その時々で調査をし、自分たちの製品にとって最適なものを選ぶ必要があります。

電子回路の簡単な把握

電子回路の開発をする場合は、当然深い理解が必要なのですが、自分やらずに仲間に頼れる場合は、仲間が書いた回路図・アートワークを最低限”読める”必要があります。 自分は書かれた回路図を丁寧に回路エンジニアから教えてもらって、その時に大体ファームウェアを実装する上で必要な回路の知識は理解できました。 ほとんどをデジタルなロジックに落とし込むことが可能なので、「デバッグ」と「低消費電力化」に遭遇しなければ、ある程度動くものはできると思います。

遭遇したらあきらめて回路のエンジニアと一緒に降りていきましょう。

筐体の物理的な動作の理解

モーター駆動するような製品の場合は、”物理”のお時間になります。 実際に僕もホワイトボードにxy座標をプロットして、制約条件や、駆動の法則を数式に落とし込みファームウェアで実装するということがありました。

ただあまり臆することはなく、メカニカルなハードウェアも場所ごとにモジュール化してつくれるので、回路やファームウェアレベルだと抽象化されていることがほとんどです(例えばギアが複雑に収まっているギアボックスなどは、特に内部の動きのすべてを把握する必要はありません)。

最後にセキュリティ

勉強しましょう。Webの知識があればある程度ファームウェアなどでも応用は効きます。TLSの原理などもそのまま適用できるケースがあります。

そしてつくったらちゃんと有識者に検証してもらいましょう👀

まとめ

ということで、僕目線で必要そうに思ったことをおおざっぱにまとめて見ました。 ハードウェア目線なことは(特に製造)、できればもう一人いる別のエンジニアに詳しくまとめてほしいなぁと思っているので、お楽しみに!

ノブレス・オブリージュ

ノブレス・オブリージュという概念を初めて知ったのはいつだっただろう? 高校のときの倫理の時間だったかもしれない。いや、ロンドンに卒業旅行に行ったときだったかもしれない。それよか東のエデンを見た時かもしれない。

いつかは忘れたけど、自分が覚えているのは「持てる者の義務」「王は国民に家や農地を分け与える」「王は自分の持つものすごい高価な絵を売って、そのお金で民のために下水工事をした」などだ。

自分は当然”王”じゃないし、全然”持っている”わけではない。

それでも地球上のどんな人も遭遇したことがないであろうことに遭遇することはある。そしてそれを工夫して解決したこともあると思う。そしてそれをブログに書いたことも。

この行為がノブレス・オブリージュだと言うつもりはないけど、ノブレス・オブリージュ「的」だと思ってはいいと思う。

自分は自分がした経験は他の人にどんどん共有していいと思っている。

たぶん自分だけが困っていて、それを解決した。

どんな人だって少なからずあると思う。世界に自分1人しかこんなことで困ってないだろうなぁみたいなことに遭遇したことが。

世の中で出会う問題の99%くらいは大抵他の人が先に遭遇していて、解決方法をブログに書いてくれている。でも残りの1%は自分だけが世界で初めて解決した可能性がある。そうじゃないかもしれないけど、そうかもしれない。少なくともググッても見つからない。だからそうだと思っておこう。

——

世界に1人だけ自分だけが困っていること、そしてその解決方法を知っている、って書くとかっこいい。でも内容は造作もないことだったりする。

あるビルの裏口の開け方のコツかもしれない。 近くのコインランドリーの一番空いている時間帯かもしれない。 WinユーザーがコピペしてくるNASのPathをMacでも快適に使えるように置換する方法かもしれない。 ある時期にあまり気づかれてなかったVimのSnippetの有用さかもしれない。 各IT企業のノベルティーシールの剥がしづらさかもしれない。 Vimバイナリ置換をするためのワンライナーかもしれない。 長岡花火をgifアニにすると氣持ちいとかそういうことかもしれない。 IoT製品をつくるときのWebからハードまでの設計の勘所かもしれない。

なんだっていいけど、世界中の誰だって一度だって考えたことがないことを、自分が世界で初めて考えている可能性がある(そうじゃない可能性も当然ある)。

それを自分だけの中で閉じるか?外に出して知見を共有するか?

自分は共有したいと思っている。その瞬間に世界の経験値の総和が0.0001でも増えるかもしれない。天才たちが1時間に世界の経験値を100上げているかもしれなくても、自分はその0.0001に意味があると思っている。世界の人口が70億人いるなら、全員が0.0001出し合えば70万の経験値になる。

天才たちが「あ、これ知らなかったらもっと時間がかかっていたよ、ありがとう」と思うかもしれない。

そういうのでもいい。

自分は天才じゃなかったけど、人類の進化には貢献したい。

誰だって人に説明すれば「それ知りたかった!」ということを持っていると思っている。

でもそれを表に出す人は自分の観測範囲だとあんまりいない。

自分も忙しいとやれなくなってしまう。

それでもたまにどんなに小さい記事でも書くのは、それによって0.0001でも助かる人がいるかもしれないから。

たまに「ググッて解決したと思ったらkazuphの記事だった」と言われることがある。

それは正直に嬉しい。自己承認欲求を満たしているだけかもしれない。

それでも、その人が無駄にするはずだった3分なり、1時間なりをなかったことにできたなら、多分意味があることだったと思う。

——

昔は土地を分け与えたえるなんてどんな人でもできることじゃなかったけど、 今は知識でそれができる。

ノブレス・オブリージュ

自分が新しいことに挑戦して成功しても失敗しても、何かしら世界の経験値に貢献できるように、それを続けていきたい。

Re:Viewのリアルタイムプレビューをgulp/gruntのlivereloadを使わずにbrowser-syncとfswatchだけでやる

f:id:kazuph1986:20160515144004g:plain

つい先日Re:Viewを使って本の執筆をやってみたので、その時に捗るTipsを紹介します。

reviewのCLIツールのインストール

$ gem install review

browser-syncのinstall

browser-syncはローカルにあるファイルを配信し、かつファイルの変更をwatchして、更新されたらブラウザ自体も更新するものです。livereloadと違ってブラウザのextensionも必要ないので、ミニマムですぐ導入できます。python -m SimpleHTTPServer 3000などを使う際の完全なる上位互換と考えてもいいと思います。

$ npm install -g browser-sync

fswatchのinstall

fswatchは特定のファイルに変更があったときにstdoutを行うものです。pipeと組み合わせるとファイルの更新後にコマンドを実行することができます。

$ brew install fswatch

使ってみる

雛形の作成

$ review init review_test
$ cd review_test

として雛形のプロジェクトを作成します。

ファイルの編集

review_test.reというファイルができているので、これをメインに編集していきます。

HTMLの生成

次に実際にreファイルからhtmlを生成してみます。

$ rake web

これだけです。webrootというディレクトリの中にindex.html他が生成されています。

ブラウザで表示する

webroot以下をlocalhost:3000で配信しつつ、webroot以下のファイルの更新をwatchする場合は以下のようなコマンドになります。

$ browser-sync start -s "webroot" -f "webroot" &

※&はバックグラウンドで実行するためのものです。フォアグランドにする場合はfgコマンドを使います。fg後にctrl+cで終了できます。

これでファイルの変更があればブラウザが自動で表示され、webroot以下の中で更新があれば自動でブラウザがリフレッシュされます。

reファイルの修正後にHTMLを生成し直しブラウザを更新する

reファイルを弄って保存したら自動でrake webが実行されブラウザが更新されるようにします。

$ fswatch review_test.re | xargs -L1 rake web && browser-sync reload

今回はfswatchの出力自体は無視していて、単に|の右側のコマンドが実行されることだけ使っています。

xargsをつけないと、都度終了してしまうのですが、つけることでfswatchのstdoutを延々監視することが可能です。

また、browser-syncの仕様としてどうやら更新は拾えるのですが、ディレクトリが一度削除されてからもう一度生成される場合は検知ができないようです。これはreviewのrake webの仕様なのでどうしようもないと思うのですが、ちょっとハマってました。

結果的にbrowser-sync reloadによって、強制的にリロードができるようだったのでそれを使いました。

ということで

gulp/gruntを一切使わずにlivereloadが実現できました!Re:Viewを使わないときでも重宝するのではないでしょうか?

PrevimでPlantUMLをプレビューできるようにしたらさらに便利になった

f:id:kazuph1986:20160503215813g:plain

元々すごい便利な↓のVim用のMarkdown Preview Pluginを愛用していたのですが、

kannokanno.hatenablog.com

今回以下の様にPlantUMLに対応させてみました。

github.com

設定

まだマージされてないので以下の様に設定します。

" マークダウンのプレビュー
" NeoBundle 'kannokanno/previm'
NeoBundle 'kazuph/previm', 'feature/add-plantuml-plugin'
NeoBundle 'tyru/open-browser.vim'
" let g:previm_open_cmd = 'open -a Safari'
nnoremap <silent><Space><Space>p :PrevimOpen<CR>

使ってみる

以下の様にumlと指定してMarkdown中にソースを書くことで展開されます。

 ```uml
 @startuml
 title 男女の関係
 start
 if (男?) then (はい)
     :興味なし;
 else (いいえ)
     :( ・`д・´)b;
     :♥;
 endif
 
 :帰る;
 
 stop
 @enduml
 ```

gyazo.com

超絶便利!!

僕はRxJS(+noble)を使ってスマートロックを開けたかったということに気づいた

ソースを載っけることはできないんですが、手元のラズパイ的なデバイスでRxJSとnobleというnodeからBLEを制御するためのライブラリをつかってAkerunの開閉に成功しました。

かねてよりリアクティブプログラミング自体には興味があって、ずっとこれを使ってAkerun開けてみたいなぁって思っていたんですが、ついに成功しました。 (というか別に昨日ちょっとやっただけですが)

なんの説明にもならない図なんですが、以下の通りAkerunは中間のゲートウェイデバイスにより間接的にインターネットにつながるデバイスです。 ゲートウェイデバイスとはライズパイ的なデバイスのことでBluetoothやらWi-Fi/3Gやら積んであって、ネットにつながっていないセンサーデバイスから情報を吸い出す役目をすることが多いです。最近ではラズパイ3も出て標準でBluetoothWi-Fiが搭載されたことは記憶にあたらしいですね。

http://plantuml.com/plantuml/png/SynEBIhDSqajoqnELR3HjLDutBpoSTEknyqJ7pSjUJwhvN7ZgiVDxO-R9m2vZvjsAbWfEFcuSX5G13B7CS0Jg3YZfAIW6000

普通はスマフォアプリを使って開閉を行うんですが、Akerunにも専用のゲートウェイデバイスを用意しているので、今回はそれでやってみました。 単にLinuxなのでAkerunやスマフォ端末とは違い普通にLLが動きます。

今回はBLE搭載ゲートウェイ界隈では最も使われそうなnode製のBLE制御ライブラリであるnobleを使ってみました。

AkerunのIoTをかっこよく言うと

Akerunはよくあるセンサー情報吸い上げ型のIoTデバイスと違い、

「人間が行った操作によってインターネットを通して現実世界に物理的な現象を引き起こすデバイス」

です。

※BLEを使って間接的にネット通信し最終的に錠につながったモーターを回しているだけです

なぜRx?

APIを叩くだけなら単にPromise使っていても良い気がします。asyncでもいいと思います。

ただAkerunの場合は開閉までに数えてみたら10(!!)を越えるくらいの非同期処理があります。

主には以下です。

  • MQTT系(Sub/Pub)
  • BLE系(電源ON/スキャン/接続/GATTの探索/データの書き込み/データの受け取り)
  • WebAPI系(ごにょごにょ)

これがそれぞれの括弧の項目含めて何度かやる必要があるのと、場合によってはリトライも必要です。

上記を実現するときにコールバック地獄になるのはゴメンです。

やってみてわかりましたが、すべての処理をストリームとして流した結果、ほぼ一本の綺麗な処理で記述することができました。 あっちにいったりこっちにきたりを全くせずに記述できるのが良かったです。

特に各ノード間で連続で複数回信号を送る必要があるのですが、それを束ねる操作がとてもうまく書けました。

またほとんど知らない状態でやってみましたので、いくつかベストプラクティスをスルーしてると思いますが、 EventEmitterで書かれたnobleのラップと独自のcreateの作成やflatMapを何個も重ねた非同期処理の一本化、filterやmapやreduceなどの基本的なリスト処理の操作など交えつつ最後まで書けたので一旦いいのかなと思っています。

まとめ

今回の僕の目的は、RxJSを使ってリアクティブプログラミング自体の習得と、今後がっつりスマフォアプリがRx化されてもいつでも即戦力としてヘルプできるようになることでしたが、下手にbacon.jsなど亜種のようなものを使わずに書いてみて正解でした。

ドキュメントを見に行くと他の言語の記述の方法もあるので、一つがわかっていると頭の中の概念を転用できて便利です。

ReactiveX - Create operator

gyazo.com

実はAkerunスマホアプリはすでにRx化されています

Androidアプリは開発当初からRxJava/RxAndroidを使って開発されていました。 iOSも現在順次RxSwiftを使って作りなおされている段階です。

がんがんRxでUIやAPIとの通信、BLEの制御やってみたい人はご応募待ってます!

www.wantedly.com

www.wantedly.com