YAPC::Asia Tokyo 2015メモ (1/2)
YAPC::Asia Tokyo 2015 の Day 1, Day 2 に参加してきました。とくに面白かったもの、印象に残ったものをメモしておきます。
Web由来の組み込みエンジニアの半年間のすべて 〜WebとiOSとBLEとハードウェアデバイスのこと〜 - Kazuhiro Homma
- http://yapcasia.org/2015/talk/show/4bab2728-00fa-11e5-9931-79c97d574c3a
- http://kazuph.github.io/presentation/yapc-2015-iot-presentation/ (スライド)
- http://kazuph.hateblo.jp/entry/2015/08/22/163000 (スピーカーの方の発表報告エントリ)
内容
- 元はWebエンジニア、組み込み系 (IoT) で起業して Akerun を作っている@kazuphさんによる発表
- Akerun を作った話 + 起業の話
IoTプロダクトの特徴
- 開発するために必要な領域: 広い (メカ、エレキ、ファームウェア、スマートフォンアプリ、サーバ・API)
- 開発〜出荷までに時間がかかる (Akerun の場合: 6ヶ月)
- メカ・エレキ「あとはファームでカバー」みたいになることも… (Webサービスとかの「あとは運用でカバー」に近い)
ファーム部分を担当するために必要な知識とお勉強
本番製品の開発
- 「本番製品で Arduino を使うのは『大学の入学式にお母さんと一緒に行くようなもの』」
- ファーム (暗号・認証) <-- BLE --> アプリ (UI) <-- N/W, TLS --> サーバ・API
- セキュリティ
Web出身の組み込みエンジニアの需要
- IoTプロダクト全体の面倒を見ることができる
- いろいろ自動化・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: 同上
最近のトレンド
- 20年前 (Ruby のできた頃) とのコンピュータ・アーキテクチャの変化: マルチコア
- アーキテクチャの振り子 (温故知新)
- e.g. サーバ・クライアント、パフォーマンスと生産性、最近のシェルスクリプトの再評価
- こういうことを考えて言語デザインをする
Streem
- Ruby の反省を活かし、 Ruby とは違った判断でシェルスクリプトっぽいことをやる言語
- ピタゴラスイッチ・プログラミング
- 特徴
- 基本的にすべて immutable
- エラー処理: デフォルトで無視
- 大クラス主義 (より少ないデータ構造)
- そろそろStreemについてひとこと言っとくか - Matzにっき も参照? (YAPC で話していた事の一部が書かれている)
感想
- はじめてmatzさんをみた。
- アーキテクチャの振り子や「歴史は繰り返す」的な話、コンピュータ・アーキテクチャに限らずいろいろなところで見られて (e.g. 人工知能に対する過剰な期待と幻滅の波) どこにでもある話ではあるのだけれど、次に来るものを敏感に捉えて、それに乗っかって何かを成し遂げられる人というのは少ないのだろうなあ、という感想。
我々はどのように冗長化を失敗したのか - Kenji Naito
- http://yapcasia.org/2015/talk/show/f2816038-10ec-11e5-89bf-d7f07d574c3a
- https://speakerdeck.com/kenjiskywalker/yapcasia2015 (スライド)
内容
- @kenjiskywalker さん
- “式年遷宮インフラストラクチャ”を構築しようとして失敗した話
式年遷宮インフラストラクチャを構築
- Redis Sentinel + mysqlfailover + Consul + consul-template
- (稼動系遷移時のダウンタイムが発生してしまう)
- 結合テスト、負荷テスト不足、 VPN の設定ミス、DB サーバの Noisy Neighbor など、いろいろ不具合発生して式年遷宮を断念
まとめ
- 本番環境と同じシステム構成で負荷テストをしよう
- せめて個別機能ごとに負荷テストをしよう
- 道具を理解してから使う
- “期待するな、計測しろ”
- “Production system is not your sandbox.”
感想
- つらそう、、、
- この次 (同一セッション) のMySQLで2億件のシリアルデータと格闘したチューニングの話 - さいけん でも「実際のデータに近いデータで負荷テストしろ」という話があって、なるほどなあという感じ。
つづく
とりあえず今日はここまで。。。 あと2〜3件分、近日中にエントリ書きます。