自室環境モニタシステム

自室の環境モニタシステムを作製中なので、現時点までにやったことをメモ。

やろうとしていること

  • 自室の環境 (温度、湿度、気圧、照度、消費電力など) をモニタリングするシステムを作りたい。
  • これらのデータを記録することで、例えば以下のような応用が考えられる:
    • 温度・湿度・気圧データ => 熱中症や乾燥などへの注意喚起、体調との相関関係の調査
    • 温度・湿度・照度データ => 在室状況や行動推定 (在室 or 不在、起床 or 睡眠くらいは区別できるかも?)
    • 消費電力データ => サーバの監視
  • また、これまでに使ったことのない種類のセンサ (気圧センサなど) やバス (I2C, SPI) などに触ってみて勉強する、という目的もある。

f:id:sobataro:20151029224858j:plain ↑環境モニタシステムの試作機の一部。ブレッドボード中央の緑色が温度・湿度・気圧センサ BME280。このままではブレッドボード上のスペースも余っているし、もう少しセンサを追加したい……

システムの概要

  1. 各種センサを Raspberry Pi に繋ぎ、データを収集する
    • I2C, SPI などのバスでセンサを接続する。
  2. データを蓄積する
    • CSV, RDB などの再利用できる形式でデータを保存・蓄積する。
  3. 収集・蓄積したデータを可視化する
    • データのグラフを確認できるようにする。
    • データの応用については、ひとまず本システムでは考えないことにする (応用を考える場合、本システムはそのためのインフラとして位置づけられる)。

検討事項と現在の試作状況

いまのところ、システムの試作を行っていて、ハードウェアは試作機が用意済み、ソフトウェアはこれから、という状況。その上で検討(した|これからする)事柄について書く。

収集するデータの種類と、利用するセンサについて

  • センサの種類としては、いまのところ以下のものを試用している。
    • 温度・湿度・気圧センサ: BME280
    • 電流センサ: CTL-10-CLS
      • 本当はもっと安いやつ (1000円未満の) でいいんだけど、試作段階ではそのへんに転がっていたやつを利用。
  • また、以下のセンサについても購入および使用を検討中。
    • 照度センサ: フォトトランジスタ NJL7502L または I2C 対応照度センサ IC TSL2561 あたり?
    • ガスセンサ: TGS2450 など (においで在室検知とかできそうな気はするけど、できてしまったらそれはそれでショックかもしれない。。。)
    • その他: ドア開閉センサ、ガイガーカウンタ、など。おもしろい応用があって、安価に入手できるセンサがあれば追加したい。

消費電力データの収集とリアルタイム処理について

  • 消費電力データ (電圧[V]・電流[A]・有効電力[W]・皮相電力[VA]) を収集するためには、電圧・電流の瞬時値を用いた計算が必要なため、少なくとも数百Hz*1のサンプリングレートが必要になる。この実現にはリアルタイム処理が必要になる。
  • Raspberry Pi でリアルタイム処理を行うには、(1)リアルタイムカーネルを利用する、(2)外付けのリアルタイム処理ユニットを追加する、の2種類の方法がある。
(1) リアルタイムカーネルを利用する場合
  • たとえば EMLID の Raspberry Pi 向けリアルタイムカーネルなどを利用して、 Raspberry Pi 自身にリアルタイム処理を行わせる方法。

    • 上記ページによると、このリアルタイムカーネルclock_nanosleep(2) のレイテンシが最小値12usec, 最大値77usec程度で収まるようだ。これを仮に、レイテンシの平均値を45usec, ジッタの最大値を+-33usecとし、さらにサンプリングレートの1%までのジッタを許容するものとすると、サンプリングレートは300Hzまで実現できる、ということになる*2
  • 利点

    • 外付けユニットが不要で低コスト
  • 欠点
    • Raspberry Pi の OS カーネルに手を入れる必要がある
    • ある程度 (数10usec程度) のジッタを防げない
(2) 外付けリアルタイム処理ユニットを利用する場合
  • Raspberry Pi 自体には手を加えず、リアルタイム処理ユニットとして適当なマイコン (Arduino や mbed など) を外付けする方法。
  • この場合、理想的には水晶発振子のジッタ程度しか気にしなくてよい……はず (不勉強のため嘘を言っているかもしれないが……)。

  • 利点

    • Raspberry Pi 側の OS カーネルはそのままでよい
    • ジッタはほとんど意識する必要がない (はず)
  • 欠点
    • 外付けユニットが必要で高コスト
結局どうするか
  • Raspberry Pi のカーネルをいじりたくなかったので、試作時点では arduino を利用したリアルタイム処理ユニットを外付けした。
  • また今回は消費電力データ収集という目的があり、AC100Vの商用電源を引き込んだ回路を作る。このため感電防止と機器保護の観点から、Raspberry Pi とGPIOで直結する回路でAC100Vを扱いたくない、という事情もある。

データの保存形式について

  • いまのところ、温度[℃]、湿度[%]、気圧[hPa]、消費電力 (電圧[V]、電流[A]、有効電力[W]、皮相電力[VA]) のデータを1分に1度収集して、CSV に保存している。
  • 仮にこの「1分に1度」という頻度でデータを収集して、1度のデータが100Byte*3だとすると、1年分のデータは 100 * 60 * 24 * 365 ~= 53MB ということになる。このくらいだとギリギリ CSVJSON でも良さそう。
  • データ収集頻度を1Hzとかにすると、1年分のデータは3.2TBということになってしまって、こうなるとテキストフォーマットは明らかに不向き。
  • とりあえずこのまま CSV でやって、時間があればちゃんとした DB を導入したい。

Raspberry Pi のストレージについて

  • Raspberry Pi のストレージは microSD なので、ここにデータを追記しまくるとすぐにぶっ壊れる。microSD への書き込み回数をできるだけ減らすため、一時ファイルを ramdisk (tmpfs) に保存 + 定期的にファイルサーバに転送、としている。

データの可視化について

今後

  • いろいろと書いたが、11月中にいったん完成させて、自室の環境を外からでもモニタリングできるようにしたい。

*1:電源周波数 (50 or 60Hz) の2倍以上; 有効電力と皮相電力をまともに計算するには少なくとも10倍程度が必要

*2:ここで出した数値にはあまり根拠がないことに注意。たとえばリンク先ページのグラフによると、上記カーネルのジッタの分布には偏りがあり、最頻値は25usec程度のように見える。また5%までのジッタを許容すれば、1500Hzでのサンプリングが可能になる

*3:上記の CSV 1行が100Byte程度

OSC 2015 Tokyo/Fall 1日目に参加してきた

OSC 2015 Tokyo/Fall の1日目に参加してきたので、そのメモ。

IoTのセンサーノード側の主役に躍り出たESP8266、その実力と応用事例を徹底解説 - 今岡 通博

内容

感想

  • 500円程度で合法に Wi-Fi が使えるモジュールというのは大変よい
    • Arduino YUN が1万円くらいするので、Arduino UNO とかと組み合わせても半額以下で Wi-Fi 対応 Arduino が手に入ることになる
  • ファームウェアを入れ替えなければ AT コマンドで制御するということで、Arduino とかから複雑な制御をするのは面倒くさそう。Lチカ程度の簡単な制御ならとっても簡単っぽい (詳しくは「次回記事」というのを参照?)
  • CPU に Tensilica のものを使っているということで、これはこれで Transmeta のコードモーフィングみたいでおもしろい。

AllJoyn フレームワークを使ったInternet of Everything (IoE) の開発 - 内田 信行

内容

AllJoyn とは
  • AllJoyn: IoE (Internet of Everything) 向けの、複数のデバイスやアプリが繋がるためのフレームワーク

    • コアライブラリ (デバイス共通の機能)
    • サービスフレームワーク (デバイスの用途ごと)
  • AllSeen: AllJoyn を監督する組織; Linux Foundation が設立

  • 発想

    • 既存の IoE: ベンダごと、機器ごとに個別のクラウド、個別の通信規格に fragmentation している
    • AllJoyn が目指す IoE: ベンダによらず、すべての機器同士が直接通信する
AllJoyn の特徴
  • セッション層以上のみを規定
  • OSS のコアライブラリ、サービスフレームワークを利用できる
  • 各機器はサポートする機能を表現でき、他の機器から利用できる
    • 機器外部のルールエンジンから、機器同士を協調させられる (Events and Actions API)
  • Headless な機器の初期設定もサポート (Onboarding サービス)
  • 2種類の開発ターゲット
  • ゲートウェイ (家庭内 <--> Cloud / Internet)
  • デバイス・システム・ブリッジ (DSB)
    • AllJoyn 以外の規格との相互接続性を確保するやつ
    • 現状ではおおむね Microsoft が作っていて、Z-Wave, BACnet との接続プラグインがある
対応機器
  • 発売されはじめている
  • e.g. TV, Windows 10 (全 edition), スピーカー、照明、…
    • 家電系はまだ少ない
    • 現時点での対応デバイス数: 1億2千万くらい (ほとんどが Windows 10)
使ってみよう
  • いろいろな環境で動く
  • いちばん簡単な開発環境

感想

  • IoT 関連の規格の乱立っぷりは、まさに xkcd: Standards な感じであまり好ましく思っていない (各規格が好き or 嫌い、という話ではない)。
  • 自分がある程度使ったことがある ECHONET Lite と比べ、AllJoyn は全体的に優れているように感じた。
    • たとえば Events and Actions API は大変よいと思う。ECHONET はアプリケーションやサービスに関しては「勝手にやれ」的な規格になっていて、それに比べ AllJoyn はサービスについても面倒を見てくれるフレームワークになっている。
    • また開発者のサポートについても、AllJoyn はコアライブラリやフレームワークOSS として公開されており、「自分で実装するか開発キットを買え」という ECHONET よりも優っている。
    • 他規格との相互接続性についても、 AllJoyn は Device System Bridge 経由で、プラグインを用意すれば任意の規格と接続できる (現状だと Z-Wave, BACnet のプラグインがある) のに対し、 ECHONET は UPnPゲートウェイが規格に入っているだけである。実装が提供されている (AllJoyn) / いない (ECHONET) という差は大きい。
    • Windows 10 の全 edition が AllJoyn に対応している、ということで、「いつの間にかルータ/コントローラ/ゲートウェイは持っていて、家電とかのコントロールされる側の機器を買ってくるだけで使える」みたいな状況を狙っているのだろう。そのへんの動きも ECHONET は遅いのでは、という感じ。
    • こうして比べてみると、やはり ECHONET は日本国内のみのガラパゴス規格として滅亡しそう。こんなものを HEMS向け標準規格として推奨してしまう経産省、、、

オープンソースをベースとしたIOTの活用方法について

内容

  • BeagleBone Black -> Fluentd -> GrowthForecast としてセンサデータを可視化するお話。

感想

  • 対象年齢高めっぽい感じだった。
  • BeagleBone は前から気になっている (とくに PRU; Linux でありながらリアルタイム処理もできる) ハードなので、ぜひ触ってみたい。

全体的な感想など

  • 今回は全体的に組み込み系の話メインで見て/聞いてまわった。
  • AllJoyn の話が聞けたのは大変よかった。ぜひ普及してほしいし、自分も AllJoyn 対応のセンサノードとか作ってみようと思う。
  • 睡眠不足もあって後半はだいぶ疲れてしまって、あまりまじめに話が聞けなかったのが反省点。Webエンジニアが知っておきたいインフラの基本(おかわり) - 馬場 俊彰とかもおもしろい & 役に立つ内容だったのだけど、結構聞き漏らしとかがありそうなのでここではまとめなかった。内容としてはおおむね以下の本の紹介だったので、こんど時間をとってちゃんと読むつもり。

国立科学博物館で「企画展『過去5万年の時をはかる』」を見てきた

去る9月某日、国立科学博物館で「企画展『過去5万年の時をはかる』」を見てきたので、そのメモ。

www.kahaku.go.jp

展示内容

簡単な要約:「過去5万年分の“時間のものさし”が、福井県水月湖湖底を研究することで得られた」

背景その1: 年縞と水月湖

一般に、海底や湖底には生物の死骸や泥などの堆積物が降り積もっている。このような堆積物は、通常の湖や海では生物活動や水流によってかき回されてしまうが、場合によっては静かに積み重なり、断面に年縞と呼ばれる周期的な縞模様が現れることがある。

f:id:sobataro:20151006224848j:plain 図:今回の企画展で展示されていた、水月湖の年縞サンプル。

この年縞の縞模様は、季節による生物活動や気象条件の差*1によって引き起こされる。

背景その2: 放射線炭素年代測定とキャリブレーションの必要性

放射線炭素年代測定とは、放射性同位体である炭素14が、自然界にほぼ均一に存在し、かつ半減期が5730年であることを利用した年代測定法。ある生物の体内にある炭素14は、その生前はほぼ自然界と同程度の比率で存在するが、その生物の死後は新たな供給が絶たれて5730年ごとに半減していく。このため、任意の化石などのサンプルにおける炭素14の存在比率を調べることで、そのサンプルが何年前のものなのかを知ることができる。

ただし放射線炭素年代測定では、(1)自然界における炭素14の存在比率が均一であること、(2)自然界における炭素14の存在比率が時代によらず一定であること、などの仮定を置いているが、これらは実際には成り立たない。このため正確な年代測定を行うには、炭素14の存在比率とその年代との換算表を利用したキャリブレーションが必要となる。この換算表の作成には正確な年代が明らかな、“素性のよい”サンプルが必要であり、過去1万2〜3千年分については樹木の年輪を利用した精密な換算表が用意できていたが、それより古い年代については、年輪のような“素性のよい”サンプルが存在しないため、誤差の大きなものしか用意できていなかった。

本題: 水月湖と放射性年代測定

福井県にある水月湖では、周囲を山に囲まれ、水深が深く、かつ直接流入する河川もない、という環境に恵まれた結果、5万年分もの年縞が存在する。中川毅らの研究グループは、この水月湖の年縞をボーリングによって取り出し、縞模様を数えることで、正確な年代が特定されている“素性のよい”堆積物のサンプル5万年分を手に入れた。このサンプルから葉の化石を取り出し、炭素14の存在比率を調べることで、放射線年代測定に用いるためのデータセットを作成・公開した。このデータセットをもとに、より精密な放射線炭素年代測定を行うための換算表であるIntCal13が作成されている。この結果、“Lake Suigetsu”という名前はいまや考古学の分野で世界的に有名となり、水月湖のデータによる“年代測定のものさし”であるIntCal13が世界中で用いられるようになった。また、たとえば最後の氷河期が終わった年代は、従来は1万1650年±99年のことである、とされていたのが、IntCal13によって±34年まで誤差が縮小されるなど、従来よりも大幅に誤差の少ない年代測定が可能となった。

感想

本当は常設展をゆっくり見て回るつもりで、企画展はおまけ程度のつもりで最後にふらっと立ち寄っただけだった。…のだけれども、展示を見るとその内容が大変有意義であることがわかり、下記の書籍まで買って勉強してしまった。

一見地味な内容ではあって、企画展も「展示」というより「通路にとりあえずポスター貼ってサンプル置いてみました」という程度の扱いっぽかった (展示スペースが常設展のいちばん奥の廊下部分だった) のだけれども、この成果はたとえば下記書籍で以下のように述べられている通り、たいへん重要なものである。

太平洋の気候変動と大西洋の気候変動が、どちらもおよそ1万5000年前であることがわかっているとする。一連の大きな変動を反映していることはまちがいない。しかし、厳密にはどちらが早くはじまっているのだろう。変動が早くはじまっていれば、その地域は大変動の「原因」により近いことになる。気候変動の単なる復元や記載ではなく、究極の原因論に迫ろうとするとき、正確な年代測定は不可欠である。

また本postでは触れていないが、湖沼由来のサンプルと海洋由来のサンプルとの“素性のよさ”の違い (湖沼由来の方がよい) といった科学的な話や、研究者としての予算・ポストの獲得と純粋な研究成果の追求との相反のようなドキュメンタリー的な話など、下記書籍はたいへん興味深いものであった。

参考文献

時を刻む湖――7万枚の地層に挑んだ科学者たち (岩波科学ライブラリー)

時を刻む湖――7万枚の地層に挑んだ科学者たち (岩波科学ライブラリー)

*1:これは、たとえば季節ごとに異なる種類のプランクトンが発生したり、冬になると黄砂が飛んできたりするため

「異端の作曲家 エリック・サティとその時代展」に行ってきた

8月某日、Bunkamuraで「異端の作曲家 エリック・サティとその時代展」を見てきたので、その感想など。

www.bunkamura.co.jp

展示内容

 エリック・サティ (1866-1925) は、19世紀末から20世紀初頭にかけて活躍したフランスの作曲家である。彼のジムノペディは、誰でも聞き覚えのある曲だと思う。


サティ/ジムノペディ 第1番 - YouTube

 サティはモンマルトルで活動し、個人での音楽活動だけでなく、芸術家との交流やコラボレーションを精力的に行った。当時モンマルトルは、ピカソゴッホほか様々な芸術家が活躍する芸術の街であり、サティはバレエ公演「パラード」「本日休演」ほか多数の舞台作品や、絵画と短い楽曲と詩とを組み合わせた「スポーツと気晴らし」などの作品群に参加し楽曲を提供した。


Picasso and Dance. Parade, 1917 - YouTube


Erik Satie Sports et Divertissements サティ「スポーツと気晴らし」絵付き ...

 このほか、具体的な展示の様子については以下ページを参照。展示の写真なども多くわかりやすい*1。本postはだいぶ雑なまとめになってしまっていて、ほとんど展示の雰囲気が伝わらないと思うので……。

www.salonette.net

感想

 今回の展示を見る前は、サティについて「ジムノペディを作った作曲家」というイメージしか持っていなかったが、今回の展示で、サティが音楽とそれ以外の芸術とのコラボレーションにも多数参加していたことがわかった。とくに「スポーツと気晴らし」は、他に類を見ない珍しい形態で音楽と詩、絵画を融合させたものではないかと思う。

 「スポーツと気晴らし」を簡単に紹介すると、狩り、海水浴、カーニバル、競馬、花火などといった21のテーマについて、絵画と楽譜、詩がセットになったもの。ただし楽譜には小節の区切りがなく、また詩は「歌詞」ではない。詩は楽譜の中に書き込まれているが、音楽に乗せて歌うのではなく、読むか朗読するもののようだ。この「スポーツと気晴らし」は、その演奏を実際に聴かずとも、楽譜を眺めているだけでそのモチーフが分かるものが多く、見ているだけで楽しめるものだった。たとえば「花火」や「ゴルフ」には、花火が打ち上がる、あるいはボールが飛んで行く場面を想起させる、長いスラーに囲まれた旋律があったり、「ブランコ」や「競馬」にも、ブランコが往復する、あるいは馬が走っている場面であることがわかるリフがあったりして、楽譜を眺めているだけで楽しめた。この「スポーツと気晴らし」の目新しいスタイルが大変気に入ったため、今回は下記参考文献に挙げた図録集まで買ってしまった。このような新しい芸術あるいは娯楽のスタイルを切り開いていく力というのは、時代を問わず価値があるものだと思う。

 またサティは「スポーツと気晴らし」に限らず、とくに舞台作品について多数の (今風に言えば) コラボ作品に参加しているが、これは当時のモンマルトルあるいはモンパルナスが、現代のスタートアップにとってのシリコンバレーのようなものだった、と自分は理解した。

 それから、とくに「パラード」に出てくる馬 (上記動画の冒頭に出てくるやつ) や、その他にも複数の絵画が、モンティ・パイソンのアニメーションの雰囲気に似ている (というより、モンティ・パイソンがこの時代の芸術をモチーフにしている) ような気がした。気のせいかもしれないが。パイソンズは大好きだ。

 最後に、このpostを書く上で、自分にとって芸術の話をうまく文章にまとめるのが大変むずかしい、ということがわかった。芸術についてそれなりの量の文章を書く機会というのは、実は初めてかもしれない。

参考文献

*1:展示スペースでは写真撮影が禁止されていたため、自分は写真を用意できなかった。リンク先のページはジャーナリストの方によるものなので、主催者側から記事執筆の依頼 + 写真撮影の許可があったのだろう。

YAPC::Asia Tokyo 2015 メモ (2/2)

(2015-08-31 修正: li要素のインデントが壊れていたのを修正)

前回の記事 の続きです。

Adventures in Refactoring - Ben Lavender

内容

リファクタリングとは
  • 振る舞いを変えずにコードを変更すること
  • リファクタリングのための悪い理由 (これらは計測できない!)
    • 一貫性
    • DRY
    • 抽象化
  • 良いリファクタリングとは
    • 行数が減る (diffstat)
    • テストのカバレッジと「表現性」が増える
    • パフォーマンスが良くなる
    • 開発者の幸福度が増す
リファクタリングの理由・動機
  1. 開発者の幸福度
  2. パフォーマンスの向上
  3. 技術的負債の返済 (Gain confidence for future work)
  4. 開発者の教育・トレーニング
リファクタリングのテクニック
  1. コードを幸せにする
    • 深いネストをやめる
    • 関数の抽出
    • 良い抽象レイヤの追加
    • 一貫性
    • 整形
    • スタイルガイドを手に入れる (つくる or 持ってくる => 従う)
      • go fmt => すばらしい
  2. 動詞の名詞化
    • 複雑な動詞の処理 => 名詞化してクラスにする
  3. 抽象化レイヤの追加
    • pull.branch_valid?, pull.branch_exist? => pull.branch.valid?, pull.branch.exist?
    • _ のところに1つのレイヤを追加できるかも
  4. 不要な抽象化レイヤの削除
    • かなりのコードとテストを減らすことができる
リファクタリングのためのツール
  1. Backscatter
  2. Scientist
Complaining
質疑応答
  • リファクタリングに関して議論になった場合は?
    • => Metrics を見る、デザインガイドに従う、議論を重ねる
  • リファクタリングと新規の開発、どちらを優先する?
  • リファクタリング: 振る舞いを変えない、その「振る舞い」というのは何? 「振る舞い」に自信がないときは?
  • リファクタリングデザインパターン使う? どんなパターンを多く使う?
    • => No, コードがテストにフィットするように書かれてしまう
    • よいテストはよいコードから生まれる
    • ただし「自分はやらない」というだけで、他人に対して「やるな」とは言わない
  • スタイルガイドの変更/更新はする?
    • => スタイルガイド: 1枚の web ページ、プルリクベースで変更する
  • リファクタリングは退屈なこともあるけど?
    • => 素晴らしい仕事をしたら褒める、ハッピーな絵文字を振る舞う
  • テストがない or 少ない場合は?
  • テスト自体のリファクタリングは?

感想

  • 何をするにもまずはテストを書け、という話がまず前提としてあって、ちゃんとテストを書かねば、という気持ちになった。
  • その他にも、本を読めば書いてありそうな話が結構多くて、それを現場できちんと実践するのはなかなか難しいという現実があるけれども、それでも守るべき、という主張の発表だと認識した。
  • 「素晴らしい仕事をしたらハッピーな絵文字を振る舞う」 => チーム開発の場合はそれで良いのだけれども、1人で開発をしている場合にもうまいことリファクタリングに対する動機づけができるとよい…かもしれない。
  • さらっと聞き流してしまったせいか、テストの「表現性」の部分が理解できなかったのだけれども、 YAPC::Asia Tokyo 2015 2日目に参加してきた. - てきとーになんか書きます によると、“テストが何をやっているかがどれだけ分かりやすいかの指標”ということだったらしい。

HTTP2 時代の Web - Jxck

内容

  • @Jxck さん
  • HTTP2: RFC7540 になった
    • 策定フェーズ => 使うフェーズ
    • どうするか
現状
  • HTTP の高速化 => RTT (距離、レスポンス速度), RT (アクセス回数) を減らす
HTTP/1.*
  • Header: テキストベース、圧縮不可、毎回送る、重複多い (UAとか)
  • Body: バイナリも送れる、圧縮可
  • 毎回TCPコネクションを確立 (3-way handshake)
  • HTTP Head of Line Blocking (1度に1つだけのリクエスト、1つ詰まると残りもブロック)
    • 現状: 同時に6本接続
  • シンプルだけど高速化に限界 (既存の回避策: ハイパフォーマンスWebサイト)
HTTP/2
  • バイナリフレーム
    • パースしやすい、サイズ効率が良い、データ分割しやすい
  • セマンティクスはHTTP/1.*のものを維持 (互換)
  • HPACK
    • Huffman符号で圧縮
    • 頻出ヘッダ (e.g. Status: 200) を共有
    • 送信済みデータ (e.g. UA) を再利用
    • (圧縮率は実装次第; そこまでは仕様で規定していない)
  • コネクションは1本; ストリームを多重化
    • コンテンツの優先度制御 (e.g. html > CSS > js > 画像その他)
    • 帯域を効率的に消費できる (スロースタートとか輻輳制御とか3-W-Hとか)
    • Head of Line Blocking を解消 => 画面中の白い部分が早めになくなったりして、速く感じることも
  • Server Push
    • e.g. HTML の中で使われている js とかを、GET HTML の時点でサーバからクライアントに Push する
    • 1 Req / 1 RT の壁を超える
  • 積極的な Cache Control
    • Browser Cache: 熾烈な奪い合い
    • そのセッションだけに着目して、もっと積極的に Push
  • Server Push with Service Worker
    • API で Push を受け取る => 双方向通信 (Fetch / Push) ができる!
    • WebSocket on HTTP2, RPC on HTTP2 とかができる
HTTP2は必要か?
  • 性能
    • Response Time だけを測っていてもだめ、人間が速いと感じるかどうか
      • Metrics: Speed Index, Film Strip, TTFB (Time to First Byte), First Paint, RUM (Real User Monitoring), ...
      • バックエンドだけの数値ではないので簡単ではないが、それだけ見ていてはだめ
  • HTTP/1.* に最適化してしまっている
    • Bad Hack 無しの素直な作りでも速くなるなら…?
  • 実装あるの?
    • いま進んでいるところ、成熟していない
  • インフラは?
    • need more 知見
    • とくに HTTPS の終端については問題かも
  • HTTPS にしないといけない!
    • Pervasive Surveillance (スノーデンとか) => TLS 推奨の流れ (W3C, IETF, Google, Mozilla, ...)
    • Let's Encrypt: 個人向けに、無料 or 安価に証明書を発行しよう、というプロジェクト (Arriving Q4 2015 らしい…)
    • HTTPS でないといろいろ不具合がでる
      • ブラウザが未実装
      • WebRTC の getUserMedia() で毎回確認ダイアログ出る
      • Service Worker: HTTPSでないと登録できない
      • など…
  • HTTP2はハイパージャイアントのもの?
    • HTTP/1.1 との戦い: Web 全体の課題
    • 使いたくなければ使わなくてもよい
    • クライアントはすでに (勝手に) 対応している、あとはサービス側が対応するかどうか
  • 敷居が高い
    • とりあえずリバースプロキシ入れるだけでも速くなるみたいな話もあったり
    • 検証は容易、どうしてもダメなら HTTP/1.1 にすぐ戻せる
研究課題
  • priority 最適化
  • hpack の圧縮戦略
  • push による cache の管理戦略
  • など…
  • TCP の限界 (パケットが詰まったらどうしようもない)
    • => HTTP2 over UDP, QUIC over UDP
まとめ
  • よく知らない、導入しない => HTTP/1.1 もこの先使える
  • 理解した、導入しない => それが低コストである保証はないが、そういう選択もあり (ただし特に HTTPS 化には逆らえない…)
  • よく知らない、導入する => エコシステムが成熟すればそうなる、いずれそうならないといけない
  • 理解した、導入する => 今までできなかったことができるようになる
  • まずは使ってみよう (導入はまだ早いけど検証は十分できる!)

感想

  • HTTP/2 の背景と現状、展望がたいへん分かりやすくまとまっていた。
  • HTTP/2 自体について、全体的に HTTP/1.* 時代のバッドノウハウをきれいに再構成して規格化した、きれいなままで性能のでるプロトコルのようで大変よいと思う。
  • 「エコシステムが成熟すれば『よく知らないけど使っていた』という状態になる」という件、たしかにその通りではあるのだけど、それに甘えることなく自分で検証とかして勉強すべきであるなあ。

その他、全体的な感想など

YAPC::Asia Tokyo 2015メモ (1/2)

YAPC::Asia Tokyo 2015 の Day 1, Day 2 に参加してきました。とくに面白かったもの、印象に残ったものをメモしておきます。

Web由来の組み込みエンジニアの半年間のすべて 〜WebとiOSとBLEとハードウェアデバイスのこと〜 - Kazuhiro Homma

内容

  • 元はWebエンジニア、組み込み系 (IoT) で起業して Akerun を作っている@kazuphさんによる発表
  • Akerun を作った話 + 起業の話
IoTプロダクトの特徴
  • 開発するために必要な領域: 広い (メカ、エレキ、ファームウェアスマートフォンアプリ、サーバ・API)
    • 開発〜出荷までに時間がかかる (Akerun の場合: 6ヶ月)
    • メカ・エレキ「あとはファームでカバー」みたいになることも… (Webサービスとかの「あとは運用でカバー」に近い)
ファーム部分を担当するために必要な知識とお勉強
  • 必要な知識
    • エレキの知識 (回路図やデータシートを読める、簡単な回路を作れる)
    • C/C++
    • 物理の知識 (数式、速度、時間、角度、…)
    • DMM, オシロスコープとお友達になること
  • まずはArduinoでお勉強した
    • 学んだこと: setup() してから loop() が無限ループする、PWM, GPIO, Timer, I2C
    • 本番 (Arduinoより高機能なマイコン) に引き継げなかったこと
      • ずっとマイコンが起きている前提のプログラミング
      • 長い処理はOS (WatchDog) に殺される
      • Arduinoの便利記法
      • 「ググれば解決する」
  • IoTに追加で必要な知識: BLESerial で勉強した
    • BLE
    • セキュリティ
本番製品の開発
  • 「本番製品で Arduino を使うのは『大学の入学式にお母さんと一緒に行くようなもの』」
  • ファーム (暗号・認証) <-- BLE --> アプリ (UI) <-- N/W, TLS --> サーバ・API
  • セキュリティ
    • BLE4.0自体はあまりよくないので、汎用技術 (AES256, HMAC, RSA, ...) を使う
    • わからないことはプロに相談 (勉強会 + Facebook, シニアモード)
    • おすすめ書籍: 暗号技術入門、マスタリングTCP/IP 情報セキュリティ編
Web出身の組み込みエンジニアの需要
  • IoTプロダクト全体の面倒を見ることができる
    • ハード・ソフトを行き来して、全体のアーキテクチャや処理シーケンスを扱える
    • OTADFU (On the Air Device Firmware Update) したりできる
  • いろいろ自動化・Web化できる (向上・検査・出荷あたりの管理アプリとかサクっと作れる)

感想

  • スピーカーの@kazuphさんのように、自分もWeb方面の人間でありながら組み込みにも興味を持っていたりするので、とくに「Web出身組み込みエンジニアには需要があるよ」という話には勇気づけられた。
  • 質疑応答で出た、「メカ〜サーバ・APIまでの幅広い範囲について、いい具合に分業できたのか?」→「わりと自分が一番忙しかったような…エレキの人はもう少しファームをやってくれても良かった気がする」的な話があって、そういう分業のつらみはあるよなあという感想。お互いの専門分野が (それなりに) 違うエンジニアが集まったときに、うまくエンジニアリングをする、というのは難しいのだろう。
  • 「本番製品で Arduino を使うのは『大学の入学式にお母さんと一緒に行くようなもの』」という件、 Akerun のようなそれなりに高度なプロダクトならその通りかもしれないが、要件的に Arduino でも十分な (OSのない8bitマイコンでも事足りる) プロダクトであれば、本番製品に Arduino (というより ATmega328 とか) を採用するのもアリではないか、という疑問が後から出てきた。

TBD - Yukihiro "Matz" Matsumoto

内容

  • matzさんによる、 Ruby の反省と、それを活かした新言語 Streem の話
Ruby の反省
  • Perl の影響
    • Perl を置き換えられるような言語をつくろう」
    • e.g. $ 変数: 変数に代入するだけで状態が変わる
  • Lisp の影響
    • Fixnum, Bignum: 使い分ける必要はない (ぜんぶ Integer に隠蔽すればよい)
    • String, Symbol: 同上
最近のトレンド
Streem

感想

  • はじめてmatzさんをみた。
  • アーキテクチャの振り子や「歴史は繰り返す」的な話、コンピュータ・アーキテクチャに限らずいろいろなところで見られて (e.g. 人工知能に対する過剰な期待と幻滅の波) どこにでもある話ではあるのだけれど、次に来るものを敏感に捉えて、それに乗っかって何かを成し遂げられる人というのは少ないのだろうなあ、という感想。

我々はどのように冗長化を失敗したのか - Kenji Naito

内容

  • @kenjiskywalker さん
  • 式年遷宮インフラストラクチャ”を構築しようとして失敗した話
式年遷宮インフラストラクチャを構築
  • Redis Sentinel + mysqlfailover + Consul + consul-template
    • (稼動系遷移時のダウンタイムが発生してしまう)
  • 結合テスト、負荷テスト不足、 VPN の設定ミス、DB サーバの Noisy Neighbor など、いろいろ不具合発生して式年遷宮を断念
まとめ
  • 本番環境と同じシステム構成で負荷テストをしよう
  • せめて個別機能ごとに負荷テストをしよう
  • 道具を理解してから使う
  • “期待するな、計測しろ”
  • “Production system is not your sandbox.”

感想

つづく

とりあえず今日はここまで。。。 あと2〜3件分、近日中にエントリ書きます。

mixiのインターンに参加しました

2014-08-18 (月) から2014-09-19 (金) までの5週間、株式会社ミクシィインターンに参加してきました。その記録をここに残しておきます。

参加までの経緯

ミクシィに就職した研究室の先輩から誘われたことが最初のきっかけでした。 誘われた時点ではあまり興味がなかったのですが、その後逆求人イベントなどでミクシィを含む複数の会社の方と面談し、オフィス訪問をするなどした結果、ミクシィのインターンが最も良さそうだと思い応募しました。その主な理由は以下の3点です。

  1. 2週間を超える比較的長期間、実務が経験できること。 Web系他社のインターンは、数日から2週間程度のハッカソン・アイディアコンテスト的なワークショップ形式のものが多く、ミクシィのように長期間の実務に参加できる環境は少数のようでした。

  2. Web系企業 (というか、自社でサービスを開発・運営している企業) におけるアジャイル開発やPullRequestベースの開発フローに参加し、これらを学びたい、という私の希望に合致すること。

  3. オフィスが渋谷にあり、自宅から比較的通勤しやすいこと。

応募に至るまでの間に、すでに人事やエンジニアの方と複数回面談していたため、(インターンの) 採用選考としての人事面談はありませんでした。希望部署について人事の方と相談した上で、受け入れ部署の方と1度面談し、採用と配属が決まりました。

新規事業開発部門

私が配属された新規事業開発部門は、現在リリースに向けて新たなサービスを開発しています。事業について詳しくは書けないのですが、上記募集要項に

コミュニケーション系のスマートフォン向けアプリの開発

とか

<歓迎>動画のエンコード・ストリーミングの経験

と書いてあるあたりから雰囲気は予想できる…かもしれません。

開発フローはGitHub上のPull Requestをベースとし、TravisCIやSlackを導入しているなど、わりと今風な環境だと思います。

業務

インターンでの業務は、基本的には社員と同様に扱っていただくことができました。新規事業自体のプロダクト開発とチャットボットの開発に携わったほか、コードレビューやスクラムセレモニーにも加わりました。

新規事業開発

プロダクト自体については、インターンの全期間を通じ、主にサーバサイド (Rails) の開発に参加しました。インターン序盤はコードや設計の説明を兼ねたペアプログラミングが中心でしたが、中盤からは主に1人で開発し、チームにかける負荷よりもアウトプットの方が大きい状態とすることができたと思います。具体的な成果としては、いくつかのバグ修正と新機能の実装を行いました。

チャットボット開発

チーム内で「レビュー途中のプルリクが放置されてしまう」という問題が発生していたため、放置されていそうなプルリクをSlackに通知するrobotaroというボットを開発しました。この開発はインターン2週目から着手し、ほとんど未経験だったcoffeescriptとnode.jsを勉強しながら、基本的には1人で開発しました。完成後、公開のお許しを頂いたためMITライセンスでGitHubに置いてあります。放置されていそうなプルリクだけでなく、コンフリクトしたプルリクや誰もレビューしていないプルリクも通知してくれる便利なbot (自画自賛) なので、ぜひご利用ください。

スクラムセレモニー

週に1度のスクラムセレモニーでは、今週の振り返り (スプリントレビュー・スプリントレトロスペクティブ)、来週の計画 (スプリントプランニング)、その他共有・議論すべきテーマに関するミーティングが行われます。ここではプロダクトの利用者を想定した新機能に関する提案が採用されたり、KPTで挙げたTryがいくつか実施されるようになるなど、純粋な開発以外の面でもチームに貢献できたと思います。

インターンの感想

開発フローや技術面について

アジャイル開発や開発フローについては、インターン参加前にも多少書籍で勉強するなどしていたのですが、実際にチームの一員として参加することで大変勉強になりました。

また純粋な技術面についても、初体験であるCoffeeScriptやnode.jsを触ったりするなど勉強になりましたが、まだまだ勉強不足ですし、常にキャッチアップし続けていかないといけない部分ですので、今後も継続的な勉強が必要だという感想を得ました。

開発環境やツールの使いこなしについて

テキストエディタやGitなどの使いこなしについて、これまで個人で使っている範囲ではあまり不自由していないつもりだったのですが、現職のエンジニアの方とペアプロをすることで、自分がいかにツールを使いこなせていないのかを痛感しました。この部分は突き詰めればいくらでも改善できる部分ですし、今後も継続して作業効率を意識するようにしようと思います。

新規事業開発部門ならではのこと

インターン開始前はあまり深く考えていなかったのですが、新規事業開発部門というのはミクシィ社内でも特殊な環境でした。 たとえばインターン期間中、プロダクトのコンセプトや、プロジェクト自体 (e.g. どの時点でプロダクトをリリースするのか、収益の柱をどこに求めるのか、など) について再検討する機会がありました。これらの議論は決して容易なものではなく、新規事業ならではの産みの苦しみのようだと思いますが、これらを経験できたことは大変貴重であるとともに、個人的には楽しむことができました (プロジェクト自体の再検討については、途中でインターン期間が終了してしまいましたが…)。

またプロダクトがリリース前であるため、インターンで何をやったのか詳しく他言できないことや、ユーザの反応が確認できないことは少々残念ではあります。

その他

  • 食事事情について

    • 20日間の期間中、ランチはずっと外食でした。少人数でのランチの行き先は重複がなく (多人数だと入れる店が限られるため重複した)、どの店も大変おいしかったのはさすが渋谷、といったところでしょうか。八王子や調布と比べると値段は高めでしたが…。

    • また、インターン開始後すぐにオフィスおかんとフリードリンクが導入されました。オフィスおかんはおいしいチルド食品が1品100円で提供されるという優良サービスで、味も大変おいしく何度か利用しました。フリードリンクも設置後は毎日利用していました。

  • 会社すぐ近くにあるラーメン凪と金王八幡宮に行ってみたかったのですが、機会がありませんでした。またそのうち遊びに行こうと思います。

  • 八王子から1時間強で通勤できるとはいえ、帰宅時にしばらく座れない or 京王線の狭い椅子に座るのが辛く、3週目からは中央ライナー or 特急で帰宅していました。510円で最高の帰宅体験ができるのでおすすめです。

  • 5週間という期間について、開始当初は「もっと短くしておけばよかったかも…」とも思っていたのですが、終わってみるとあっという間でした。できることならせめて、サービス公開まではチームに残りたいところなのですが、大学の都合によりこれ以上は続けられず残念です。

  • 楽しい部署でした。

最後に

私を受け入れてくださった部署の方々、ほんとうにありがとうございました。純粋な技術面から、考え方や働き方についてまで、たいへん勉強になりました。また人事部の方々をはじめ、インターン中にお世話になったみなさまにお礼申し上げます。

1ヶ月間という長期間、新規事業開発の現場に身を置けたことは大変貴重な経験でした。Web系志望の方にはたいへんおすすめできる内容だったと思います。

最高の夏でした!!!!