無職です。 旧ブログ: 1 Entry per Day

mornin' plusを買ってみた

最近QoL上げようとNature Remo買ったりしてスマートホーム化を進めています。

カーテンの開閉も自動化できたらいいなと思い、他の自動カーテンより設置しやすく値段も安めなmornin' plusをとりあえず買ってみました。

mornin.jp

以下は設置してみた写真。既存のカーテンレールにぶら下げるだけです。 写真では見えませんが、カーテンレールを走るようタイヤが付いており、本体が動くことでカーテンを移動させる仕組み

f:id:mstssk:20180917132458j:plain:w320

メリット

  • 設置が楽
    • 他の自動カーテンはもっと大掛かりだったりするんですが、これは既にあるカーテンレールにぶら下げるだけ。
  • 安い
    • 他の製品は1〜2万円が価格の下限です。ニトリのもので9千円台のものがありますが、カーテンレールごと付け替える必要があるみたい。
  • 指定時刻に自動開閉する機能あり
    • 専用アプリで開閉する曜日と時間を決めておけます。例えば、平日の朝7時に自動でカーテンが開くようにしておくことで目を覚ましやすいです。

デメリット

本当は「ok google、カーテン開けて」とかやりたいんですが、基本的にmornin' plusではできません。 これが個人的な一番のマイナス点。

IFTTT + Pushbullet + Taskerを組み合わせてなんとかしている方はいるようです。ここまでやったのはすごい。 Google Home と mornin' を使って声でカーテンを開閉する 私も同じ環境を構築してみようとしたんですが、昔使っていた端末を人身御供にしてやろうとしたところ、Pushbulletの通知周りが上手く飛んでこずに断念しました。 端末自体がガタが来ていたとか、1つのアカウントで複数台Pushbulletログインしていた+IFTTT→Pushbulletの連携が端末を指定できない、とか細かい問題がちょくちょくある上、構築できたとしてもボイスコマンドからmornin' plusが実際に動き始めるまでに20秒くらいかかってしまうなどコストが辛いです。

今後

mornin' plusがGoogle Assistantとかと対応してくれるとありがたいんですが、一筋縄ではいかなさそうです。 スマートスピーカーとの対応は考えていないわけではないですが、今のBLE,乾電池式という設計上本体の拡張が大変なのであまり期待はできないようです。 他のスマートホーム機器のシリーズのようにコンセント直差しの中継機器なんかを出すとかでしょうか…

カーテンを自動開閉するIoT機器の開発秘話とスッキリ起きるコツとは? 株式会社ロビットに聞く。 – SmartHacks Magazine

もうしばらくmornin' plusを使ってみるつもりですが、いずれは他のものに買い換えることも考えてはいます。 単純な話、赤外線リモコンで操作できる他のものを買ってしまえば、既に持っているNature Remoで操作できるのでGoogle Assistant連携も一瞬なんですよね。

赤外線リモコンで操作できるかどうかちゃんと調べたわけではないですが、他にも自動カーテンのラインナップで見かけたものを並べておきます。

mornin' plusの本体の設置のしやすさ取り回しやすさは魅力なので、公式でよいソリューションを提供してくれるとホントは嬉しいんですが。

DevFest 2018 Tokyo 資料まとめ

最終更新 2018/09/06 22:36

GDG DevFest 2018 Tokyoの各セッションの資料まとめです(非公式)。 Twitter#DevFest18 スライド または #DevFest18 資料 で検索して探してます。

タイトルは https://gdg-tokyo.connpass.com/event/95307/ のタイムテーブルから持ってきた仮題なので、実際の資料のタイトルとは食い違っていたりしてます。 公式?の資料リストは https://gdg-tokyo.connpass.com/event/95307/presentation/ を参照。

TBDはまだ資料を見つけられていないものです。 登壇者または登壇者の所属組織の都合で資料非公開だったりする場合もあるようで、完全なリストにはならないと考えています。

10:00-10:30 セッション1

Room A+B 「(仮)実践!!Web パフォーマンス改善!」

TBD 資料非公開?

Room C+D 「Game Development for Firebase Unity SDK

Room G+H 「Quick Start GCP

TBD

Room I 「Android OSは安全なのか?」

Room J 「Flutterアニメーションの実装方法」

Room K 「Kubeflowで何ができて何ができないのか?」

10:40-11:10 セッション2

Room A+B 「Googleアシスタント最新動向」

Room C+D 「Flutter Overview」

Room G+H 「PWAのイマ」

Room I 「Firestore Database Design」

Room J 「Advanced Room」

Room K 「GCP Compute 概要と選定」

11:20-11:50 セッション3

Room A+B 「AndroidX時代のHello world

Room C+D 「Google AIY Vision kitで遊ぼう ~麻雀牌のリアルタイム識別」~

Room G+H 「Firebase Overview for native application」

TBD

Room I 「GCP のデータベース・ストレージ」

Room J 「Goでネットワークプログラミングするためのよもやま話」

Room K 「FlutterPluginの作り方」

12:50-13:20 セッション4

Room A+B 「Angularの最新情報」

Room C+D 「DialogflowとCloud Functions で作る Google アシスタント アクション」

Room G+H 「Cloud Kata」

Room I 「KotlinでFlutterを書けないか色々試してみた(仮」

Room J 「Flutterとの1年」

Room K 「Growing your app with Firebase」

13:30-14:00 セッション5

Room A+B 「TensorFlow Liteで機械学習Androidアプリを超簡単に作る」

Room C+D 「Container」

TBD

Room G+H 「新しいMaterial Design と MDC(仮)」

Room I 「Introduction of Polymer 3.0」

TBD

Room J 「Realtime Database for high traffic production application」

Room K 「Generative Modeling in the Wild」

TBD

14:10-14:40 セッション6

Room A+B 「Goらしいコードを業務でも書くために(仮)」

Room C+D 「TypeScript導入で得られる「変えていく勇気」」

Room G+H 「Transactions APIを使って飲食店の予約が出来るGoogle Assistantアクションが出来るまで」

Room I 「AndroidThings で CO2 を計測し、警告&サーバーに計測値を投げるシステム」

Room J 「GCPでつくるデータ処理パイプライン」

Room K 「"Fan out" to create twitter like timeline with Cloud Firestore and Cloud Functions」

14:50-15:20 セッション7

Room A+B 「Androidパネルディスカッション: AAC実践導入について」

TBD

Room C+D 「Firebase Realtime Database in Production」

Room G+H 「機械学習、どこから手をつける?」

Room I 「非中央集権ウェブ」

Room J 「Auto ML Overview」

TBD

Room K 「GtugGirlsがヤバいんです」


以上!

Google Assistantのルーティン機能が最高だった

もともと、帰宅して「ただいま」と言ったらエアコンやら証明やら一括で電源を入れるようにしたかったんですが、いつの間にか公式でサポートしていてやったぜ!という感じです。

しかし、Nature Remoで制御しているエアコンについてGoogle Assistantの設定画面では「OFFにする」という指定ができないようでした。 ですが、「エアコンを消して」といったボイスコマンドをそのまま指定できるので代替できます。

WEB+DB PRESSの仮想DOM記事を読んでの感想やらなんやら

WEB+DB PRESS Vol.106の「仮想DOM革命」という記事を読んでの感想やらなんやら

gihyo.jp


これまでほぼAngularしか触ってなかったんですが(jQueryとかモダンでない旧世代以前のあれやこれやは除く)、そろそろReact触ることになりそうなので勉強しようとしていたら、WEB+DB PRESS Vol.106に「仮想DOM革命」という記事が載っていたので、早速買って読みました。

以下、著者の意図とは違うだろうけど、自分的に良かった点について。

Reactのよくわからんかった部分がわかった

Reactはほとんど触ったことがなくて、去年のDroidKaigiのサイトがReactベースのGatsbyだったので、少々触ったくらいでした。

仮想DOMがどうやって何を実現してくれるのか、ReactにおいてProps/Stateの立ち位置・使い方は何なのかがわかったのが、この記事を読んでの俺的な一番の収穫でした。

Angularと比較してどう違うのかがわかった(気になった)

(Angularについてはv2の頃に調べた話が元なので今は違うかも)

Reactでは仮想DOMによって差分のみをDOMに適用する一方、Angularでは変更を検知したプロパティを使用しているテンプレート中の該当部のDOM操作を行います。

つまり、コンポーネントが複雑になってもDOMに適用するのはあくまでその差分だけなReactに対して、テンプレートに記述したロジックをDOMにそのまま反映していくAngularの違いがあります。 特にAngularではAOTコンパイルでテンプレートをTypeScriptのコードにすることもあり、テンプレート書くときもJavaScriptとしてのパフォーマンスを考慮しながら書いたりする必要があると思ってます。

Angularの方はコンポーネントCSSカプセル化を最初からやっているとかプロパティの双方向バインディングがあるとかいう違いもありますが、フロントエンドのフレームワークで一番パフォーマンスに影響が出るDOM操作周りの振る舞いの違いは重要です。

React-Redux勉強メモ

近くReact+Reduxを触るのでとりあえずざっとQiitaの記事あたりを読んでいったメモ。


概要

react-reduxはreactの各コンポーネントのprops/stateの変更をreduxにすべて委譲してしまう仕組み。 reactは個々のコンポーネントの描画とボタン押下時にどのactionを実行するか(dispatch)だけに注力する。 reduxはdispatchされたactionによってStateをどう変更するかをreducerで管理する。 Stateの変更によるコンポーネントへの反映はreact-reduxのconnect関数とProviderによって実現する。

connectとかProvider

react-reduxの場合、Reactのコンポーネントを直接使わずconnectでwrapしたconnected componentを使う。 connected componentはactionを経由して行われたStateの変更を引き受けて再描画される。 正確に言うとそれだけでは動かなくて、Providerというreact-reduxのコンポーネントが親になっていてそこでStoreと繋ぐ。

const store = createStore(reducer)
render(
  <Provider store={store}>
    <App />
  </Provider>,
  document.getElementById('root')
)

Action

Actionは単純なJavaScriptのオブジェクトに過ぎない。 typeプロパティを持つという制約があるだけ。↓のpayloadというは任意の値を受け渡す場合の例であって別のプロパティ名などでも問題ない。

{ type: "アクションを一意に示す任意の文字列", payload: "アクションの引数" }

Action Creator

typeの値の定数とかコンポーネントから渡される引数をpayloadにマッピング薄い関数をAction Creatorと呼ぶ。

function actFoo(arg) {return {type: ACT_FOO, payload: arg}}

dispatch

dispatchとはAction Creatorを呼びつつRedux側にActionを実行させる部分。 個々のコンポーネント毎にどのActionをdispatchするかは指定しておく必要がある。 その記述は今は結構雑に書けるそうだ。 ↓の場合、HogeComponentのpropsにactFooとactBarをdispatchするだけの同名の関数が渡されるので、コンポーネント内のclickイベントなどでそれを実行するようにしておくだけでよい。

export default connect(
    // mapStateToProps
    state => ({ value: state.value }),
    // mapDispatchToProps 
   { actFoo, actBar } // connectの第2引数にAction Creatorを纏めたオブジェクトを渡す
)(HogeComponent)

Container

実際には個々のコンポーネントごとにconnectしておくのではなく、ネストの親コンポーネントでだけconnectしておいたりすることがある。 それをContainerと呼ぶ。

StoreとReducerの分割

ReduxではStateを管理するStoreは基本的に1つだけにする。 そのStoreでactionを処理するReducerも1つにすることになる。 しかし、大きなアプリケーションだと1つのReducerになんでもかんでも突っ込むのはヤバイので、実際にはStateのプロパティごとにReducerを作り、それを纏めたReducerを使う。 その際は、分割した個々のReducerを自前で書いてcombineReducersというヘルパ関数でガッチャンコする。

function fooReducer(state = initialState, action){
    /* Stateのfooプロパティを扱うReducer */
}
function barReducer(state = initialState, action){
    /* Stateのbarプロパティを扱うReducer */
}
export default combineReducers({
    foo: fooReducer,
    bar: barReducer,
})

combineReducersを使わずに自前で分割するのも出来るっちゃ出来るがcombineReducers使った方が無難そう。

export default reducer(state = {}, action) {
  return {
    foo: fooReducer(state.foo, action),
    bar: barReducer(state.bar, action),
  }
}

Reducerは分割出来るがStateはあくまでもアプリ全体で1つだけであることを忘れずに。 上記の例ではReducer側ではfooやbarという単位で扱っているが、コンポーネント側ではあくまでfooもbarも持つState全体が渡ってくるので、mapStateToPropsでは気をつける。

参考文献