それなあに？

詳しくはこちらをご覧ください
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で動く！！

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に関する知識は皆無でしたが今回お話を聞いて興味を持ちはじめました。開発に携わっているものに還元したい…。

最後まで読んでいただきありがとうございます！
間違っていたり、誤解を招くような記述があればご指摘いただくと喜びます！