2005-11-17 Embedded Technology 2005
_ ET2005
組み込みの展示会に行って来ました。
組み込みは専門外なのでよく分からないのですが、
回ってみるといくつか面白いものが。
どこかの大学がテーブル型ディスプレイデバイスを使った
新しいコミュニケーションを提案してました。
タッチパネルにもなってて見てると面白い。
テーブルも自分たちで作ったのかな？
次に組み込み用のJAVA。
JAVAだとメモリアクセスとか大変なんで、
便利にするクラスライブラリも提供するとか。
携帯の機種依存をJAVAVMで吸収してくれたら楽そうだ。
組み込みのFLASHなんてのも。
ATMのインターフェイスなんかに使えるかな。
１周するとなんかもうなんでもできる気がしますね。
前にいた会社も展示していて、
車のエンジン回転数や速度情報を取り出してPCに送るシステムとか。
これ欲しい。ええ、趣味で。(^^)
すごいのは、実際の車のボードを使ってエミュレート環境ができていたこと。
ヤフオクで購入したとのこと。
すごいもんが売ってるんですねー。
_ パネルセッション「アジャイル手法は組込みシステム開発に使えるか」
アジャイルとは、迅速な開発を可能にする手法群。
具体的にはXPやオブジェクト指向なんていう開発手法や、
QoEL（エンジニアの幸せ度）の向上や個人の尊重なんてのもアジャイルの精神のようだ。
いくつかトピックをあげてみます。
・上司受けが良い言葉で相手を懐柔
「アジャイル」と言ってしまうと知らない人にとってはすっとんきょうに感じられてしまう。
「カイゼンしましょうよ！」とか相手の知っている言葉なら無血開城が可能だ。(笑)
・アジャイルは品質向上に効果があるか？
組み込みは特に品質が重視されて、
「80点で出しておいてあとでアップデート」のM$式は使えない。
この「80点の状態から100点を狙う」部分にアジャイルは貢献できるか？という議題。
例えばテストファーストやペアプロが品質向上に効果がありますね、
でも具体的にそれが80点以上を狙える決定打ではないのでは、といった結論に。
80点→100点への汎用的な手段というのはとても難しいように思えるので、
テストファーストやペアプロは少なくとも他の手法と比べて
それを可能にする潜在能力は持っているのではと感じた。
・アジャイルはアウトソーシングに効果があるか？
確か「ない」という結論。
エンジニアのコミュニケーションが地理的に阻害されるとアジャイルは効果薄。
「海外への外注でコストを下げて品質を保てというのは非常に困難」
というのが当たり前なのだけどなぜか新鮮に感じた。
・組み込みエンジニアとコミュニティ
組み込みエンジニアは労働時間が他のITエンジニアと比較して長いというデータを元に、
アジャイルは労働時間短縮になにか貢献できるか、という議題。
話の流れで平鍋さんが
「組み込みエンジニアも積極的にコミュニティを形成して、
例えばアジャイルなどの開発手法を積極的に取り入れてみてはどうか？
コミュニティに参加したり作ってみません？」と啓蒙。
こうやって種を蒔くのかと勉強になる。
平鍋さんの話し方は非常に分かりやすく受け止めやすかった。
・総評
アジャイルの具体例をもっと示して欲しかったなぁという感想。
聴講者のレベルがどの程度かは把握していないが、
おそらく「アジャイルってなんだろう？」と興味を持っているけど
やり方が分からない、という人が多いのでは。
平鍋さんのカンバン方式みたいに、
具体的な実施例をいくつか並べて、
「できるものからやってみよう」という内容だと実りが多く感じられると思う。
パネルセッションであってプレゼンではないから仕方がないのだけどね。
でもいろいろと知識吸収できたので満足。
_ KIKKA
某B社の方々と渋谷のKIKKAというお店で飲み会。
しかし某S社関係者がなぜか過半数。(笑)
いろいろと面白い話が聞けました。
落ち着いた雰囲気のいいお店でした。
渋谷駅前ではsonyがビルの一角を使ってダンスチャレンジとやらをしていた。
みんな指をさしていたのでインパクトはあるみたいだけど。。。
2014-11-17
_ RubyConf2014 - Matz keynote
今年のRubyConfはSan Diego。さきほど恒例のmatz keynoteが終わりました。今年も内容のメモをとりました。今年は進みが速くて例年以上にメモれなかったので、詳しくはあとで公開される動画をご覧ください。：）
"Feeding the Sharks"
OSSコミュニティはサメみたいなもので、新しいことで泳ぎ続けていないと死んでしまいます。楽しいことがないといけない。 過去のRubyConfでは未来の話をしてきました。最初のRubyConfではVirtulaMachine。これは2007年のRuby1.9で笹田さんによって実現しました。ほかに、M17N, Native thread, Generational GCなんかも実現しました。
2005年はサンディエゴ Stabby lambda(->), Real multi-value, Traits。-> は当時は批判もあったけど、今ではみんな書くようになった。ほら、私は正しかった。（会場笑い）
2006年デンバーは新アイデアなし。2007年Charlotte、1.9の紹介、この年も新アイデアはない。2008年はポートランド、なし。2009年サンフランシスコもなし。RubyKaigi2009ではいくつか紹介した。（略）
2001年から2005年はエキサイトだけど確かじゃない新アイデアを、2009-2013年はImpelementationの改善で新アイデアはなかった。そろそろガソリンが必要だろう。
そう、Ruby3.0だ。
その前に、Ruby2.2は次のクリスマスに出ます。笹田さんの新しいGCとか入ります。
Ruby3.0は Concurrncy, JIT, Static typing.
Concurrency はみんなご存知のGVLをなんとか。詳細未定。（※あとでmatzさんに聞いたら、matzさんと笹田さんで検討中とのこと。）
JITはまたはLLVMかも。
Static typing、これは？ScalaとかTypeScriptとかモダンな言語にあるようにRubyにもあっていいんじゃない？メリットは？パフォーマンス、コンパイル時のチェック。
静的型付けは高速化のほかにも、better documentにもなる。Static typing は Duck typing と衝突する。DuckTypingを失ったRubyはRubyと言えるのか？私はRubyはRubyで居続けると思う。
型宣言よりも型推論(= Soft typing)。型はどこで示すか。メソッド定義時（名前と引数の型と数）、クラス定義時。一部の機能に制限をいれることもあるかも。たとえば require, define_method, method_missingとか。requireが変数を受け取ると解析できないから、定数しか指定できないとか。
コンパイラがあなたの意志(型)を読み取って、あなたにレポートを返す。ドキュメント生成やIDEの情報にする。コンパイラとあなたがより密にコミュニケーションをとるようになる。
最初は静的解析からはじめると思う。つまり、最初は外部のツールで解析するようなものを作るといいのではないか。それでの知見は言語に良い影響を与えるはず。その結果、どういう風に言語を作ればいいか分かってくる。
あ、このキーノートはアイデアだから、実現するかもしれないし、しないかもしれない。
これらのアイデアからRuby3.0が生まれるんじゃないかと思う。Happy Hacking!
