それなあに？
詳しくはこちらをご覧ください
http://www.digitalfukuoka.jp/events/60
"mruby x IoT"の今 についてのアツいお話を聞ける・できる会 と解釈しています。
ソレに興味をもったため参加してきました！興味深かった講演の内容をまとめてみました。
matzさんのrabbit
「Rubyの未来」
興味深いお話で聞き入ってしまいました。
バージョン方針
- 言語の仕様バージョンは2桁で表現する
- 1.9.3 → 2.2
- セキュリティのパッチをあてたアプデは下一桁で表現する
- 1.9.3p484 → 2.2.0
リリーススケジュール
- 年に1回クリスマスに！(2.x.0)
- 安定進化！
- 意図しない動きを例外に、ほぼ間違いなくアプデしてもそのまま動く！
- 年に数度アプデ！(2.x.y)
2.2新機能
- インクリメンタルGC
- GCを少しずつする
- シンボルGC
- シンボルはパフォーマンス向上のためにGCの対象になっていなかった
- Unicode7.0対応
- より高速
- より安定
- 高い互換性
- 2.1で動いているものはほぼ間違いなく2.2で動く！！
- 2.1で動いているものはほぼ間違いなく2.2で動く！！
Ruby3.0構想
- いつになるやら
mrubyのお話
- デバイスの中にシステムを入れるときにもソフトウェアの生産性をUP!
活用されている場面
- 電子百葉箱
- インターネットルーター
- 自動販売機
- ロボット
ソフトウェアとして
- HTTPサーバ
- 検索エンジン（オプティマイザ）
- スマホアプリ
ゲーム組込みとして
- キャラなど hobby系のものが多い
- SID MEIER'S STARSHIPS（本気ゲーム！）
2014年にリリース
- Ruby1.9.xベースから2.xベースにしたい
- さらなる軽量化・高速化
- 極端な変化は避けたい
- 「よりよい」を継続的にがんばる
「よりよい」を継続的にがんばることの困難さ
- 困難さ
- 性能とコスト
- メモリ容量と機能
- 進歩と安定
- 機能の追加と複雑さ
→ バグ・後方非互換
- 「よりよい」は「ちょうどよい」
- 「使えない」「つまらない」もダメ
- ↑進みすぎ ↑進まなさすぎ
「ちょうど良い」は変化する
期間を伸ばすと見えやすくなる
- 30年前のPC
- CPU: 700/ MEM: 60+ sto 3000
- 20年前のワークステーション
- 5年前のPC
- 使えないが使えるに！
- メモリがまだ足りない
- CPUがまだ足りない
「使える」と「使えない」のタイムラグ
使えるようになってから始めるのでは遅い
-
イノベーションはタイムラグの向こう側にある
- クラウド
- IoT
- オブジェクト指向スクリプト言語
- 組込み向け高級言語
-
アイディアはシンプル
- 誰でも思いつく
- だれでも実現できるわけではない
- 「遅い」「高機能すぎる」「不要」
- 心が折れそうになる…
- 「新しいスクリプト言語？shellでいいじゃない」から「すばらしい！」に変わってきた！
組込みにmruby
- メモリ足りない CPUの無駄 → 要らない！
- 心が折れそうになる
- 近い未来に動くのが当たり前になる
- タイミングが重要
- 遅すぎるとイノベーションにならない
悪いところばかりではない
- RoRが出てきて盛り上がったり、コミュニティができて応援団のような存在になったり！
未来をみて未来を信じてゆっくりと歩く
- 周りを巻き込んで
- 柔軟な対応をしていく
確定した未来はありえない
- 確定されたみらい かっちりした 計画・仕様 調整と配分
- 会議会議…
- リスクの回避
- イノベーションの破壊
- 漠然とした計画
- 存在しないロードマップ
- 柔軟に方針変更
- 積極的なリスクテイク
偉大な素人
- 所謂「プロフェッショナル」ではない
- 素人 → 計画遂行に重きをおかない
- 素人 → モチベーション駆動
- 素人 → 初心者
- 技術力はあるけどマインドは素人
- 計画ではなく解決策を見る
- ポリシー（哲学）をもつ
Streemのお話
- 動かないものを置いていてもpullreqがいっぱいきた！
- 動かなくてもええんかい…！
- Agile
- 変化の許容
- 柔軟な対応
- 開発への集中
- 会議をいくらしてもソースコードは増えない！
- OSS
- 開かれた開発
- ここを直そうが言える、言ってもらえる
イノベーションを起こすための要素
- 哲学 情熱 継続
- 素人っぽさ
- neoamateurism !
- 偉大な素人
組込みのお固いところに楽しさをplusした！
mrubyデバッガのお話
「 mrubyデバッガの紹介，および，応用事例の紹介 」
http://www.slideshare.net/kazuakitanaka391/ruby-44092362
軽量Ruby
- Rubyと基本的には同じ文法
- 実行に必要な資源が少ない
- メモリの消費が少なめ
- C による機能拡張が容易
mrubyバイトコードはデバイスアーキテクチャ非依存
- 開発環境で必要なもの
- mrubyコンパイラmrubyVM ← ここは簡単め
- ターゲットデバイスで必要なもの
- mrubyVM ← ここが一番大変 きも
ただのアセンブラじゃないのか？
- ちがう！オブジェクト指向！
- +メソッド: 数字なら足し算 文字列なら連結など！
ビルドが要らない
- デバッガはgithubのmruby/mrubyから
- http://forum.mruby.org
できること
- 実行
- ブレークポイント
- 式評価
- コマンドライン
すべてのデバッガの機能はAPI提供されている
- 機能拡張
- 開発環境からの呼び出し
- リモートデバッグ
基本的にはCによるmruby拡張の手法
- mrubyのソースコードを書き換える
- オススメではない
- 別な機能を付けたいときとか
- 新しい機能はつけておきたい箇所とそうでない箇所がある
- mrbgemsをつかう
- gitをつかう
MQTTのお話
http://mqtt.org/
mqttプロトコルの説明が聞けました。
前提知識は皆無でしたが興味深いお話でした。
自己紹介
- （雨男ならぬ）雪男さん
IoTのお話
- 2020年には電球がinternetにつながっているだろう
- （わくわくします…！）
求められるもの
- リアルタイム性
- 双方向性
課題
- 解析をやりだすと間に合わなくなってくる
- 企業の壁を越えた水平分業
- 方言を許すと大変になる
特徴
- MQTT(web socket上でも動く！) OASIS（方言は許さない） pahoo
- 2バイトのHeader
- TCP
- 非同期双方向通信！
- 出したいときに出せる
- クライアントはheartbeat(2byte)を送りたいときに送る
- あるべき姿を見据えている
- ただ単にオープンにしているだけのものとは腹づもりが違う
- will 遺言
- 川の上流のセンサー
- 切れた瞬間にpublisherに届けられる
- QoS（quality of sevice）
- car easy play
- 視聴している番組で興味を持っていそうなCMにかえたりするサービスの実現が可能に
感想など
matzさんのアツいrabbitを聞けたこと、バックグラウンドの違った人たちとのディスカッションができたこと、とても楽しかったです。
matzさんのイノベーションを起こすには—辺りのお話は、最近似た議論をしたのでとても共感が持てました。
ディスカッションでは「IoT × 医療、ヘルスケア、教育」で言いたいことを自由に発言できるようにファシリテートしてくださいました。ありがとうございます！しゃべっていたのでメモを取れず。。記憶もナイのでまとめられずです。。。
IoTに関する知識は皆無でしたが今回お話を聞いて興味を持ちはじめました。開発に携わっているものに還元したい…。
最後まで読んでいただきありがとうございます！
間違っていたり、誤解を招くような記述があればご指摘いただくと喜びます！