PICK UP

監視カメラでslack通知(後編)

LAB

澤 規仁

こんにちは。前編に続いて、監視カメラの解説です。
前編から半年近く経ちましたが、年末の整理ということで。

ちょっとつくってみたとはいえ、毎日つかうものなので、ユーザビリティ大事です。ということで、今回は監視カメラのユーザ・インタフェースについてご紹介します。

機能1:監視状態の切替

普段からアラートが飛んできたらウザくてしょうがないですので、監視/非監視の状態を切り替えできるようにしておきます。切り替えかたはアプリを立ち上げて、タップするだけです。

kanshi-1

kanshi-2

ボタンすら、無いです。

機能2:録画

録画は、動画でなく静止画で記録することにしました。目的は見たいところにすぐにたどり着けるためです。動画だとずっと再生で追っかけないと見たいところに辿りつけないですが、静止画の一覧なら一発です。

毎秒1枚を録画していますが、「監視」という目的に対して、それ以上の枚数は必要ないと判断しました。実際に使っていても十分だなと思えます。

また、静止画にすることで通信帯域を節約できる利点も得られました。

必要なところを必要なだけ見られればよいので、監視モードの時に反応した前後30秒間をスマートフォンから見られるようにします。
 

rec-11

 
スワイプで前後秒に移動です。

rec-2

これで十分。

ちなみに

通信帯域やファイルサイズなどからサーバの性能設計をします。毎秒で録画をしますので、1日に86,400枚の画像が保存されます。(60×60×24) 1枚あたりの画像サイズは、800×600pxで50Kbyte程度でしたので、常時50Kbyte/sec、つまり400Kbpsのアップロード通信量が発生しています。1日分の録画のデータサイズは、50×86,400 = 4,320,000Kbyte:4.3GBですね。1ヶ月で129GBです。定期的に消さないとエライことになってしまいます。ということで、日次で30日前の画像を削除する処理をつくっておきます。これで1ヶ月間録画されます。

ついでにLinuxのファイルシステムでは作成できるファイル数の上限が設定されています。

$ df -i
Filesystem       Inodes  IUsed    IFree IUse% Mounted on
/dev/sdc1      65536000 230902 65305098    1% /data   

inode上限は65,536,000です。1ヶ月に作成されるファイル数は86400 × 31 = 2,678,400個なのでここは問題ないですね。上記の要件でサーバの選定を行ってます。

なるべく、つくらない

Bunnyhop Inc.ではいつもデザインと機能を同時に考えるのですが、デザインの検討の初動は目的の明確化です。何ができていたらいいのか。達成すべきことは何か。目的に達するための手順をひとつでも減らせないか。プロトタイプではありますが、今回は毎日使うものだからこそ、必要最小限の構成要素が望ましいと考えました。

コンピュータの画面だって、つくらないデザインってのがあるんではないでしょうか。

“Less is more.” Ludwig Mies van der Rohe