RubyKaigi2017 速報記事 2日目 #RubyKaigi2017

※2日目速報更新終了いたしました。

■ keynote/Matz

単一継承から始まり、多重継承が起こってきたが多重継承を行うと複雑性がますので、
MixinやMixin・Flavorsが発生した。
そこでMixin・Flavorsから発想を得て、RubyのModuleができた
Moduleは時と共に役割が増えていった、mixin・名前空間（入れ物）・メソッドの集合体など
@hayabusa333

Moduleの代表的な使い方(namespace, mixin, method setなど)の紹介と、
今提案段階にあるstructural signatureについての説明。
module単位でis_aやrespond_toのようなtype checkingができるようになる機能。
最後にはCommitterの方々がどのような活躍をしているかの紹介、Communityの大切さと、
Communityへの感謝の言葉で締めくくっていて、
積極的に技術コミュニティへ参加することへの大切さが身にしみた。
hckaye

Matzは天才プログラマではなく、プログラム言語を例外なく愛する言語デザイナー！
継承機能を題材に単一継承から多重継承、Mixin、Flavor。そこからRubyのmoduleが生まれた。
その後、現在広く利用されている各種Moduleの機能がどの言語からアイデアをもらっていったかを解説し、最後にコミュニティへの感謝。
Rubyをより良くより強くしていこう。ひいては世界をもっと良くできるのではと締めくくった
桂田

モジュール機能の遷移として
・mixinの単位から
・ネームスペース
・シングルトン
・メソッドの集まり
・メソッドコンビネーションの単位
・リファインメントの単位
・(現在提案の段階だが)Structual Signature
と、他言語からどう機能を引き継いで、Rubyに組み込んでいくのか、デザインしていくのかの紹介がされた
1993年から1人のプロジェクトとして始まり、現在はMatz自身が機能を実装することは、あまりなくなったが、Rubyがどうあるべきかを決めていくRubyのリード言語デザイナーであることは変わらない
Rubyをよりよくして、世界がよりよくなればよい、とキーノートを締めくくった
@ohrdev

■ An introduction and future of Ruby coverage library/Yusuke Endoh

テストカバレッジは
・テストされていない箇所を調べる
・良いテストスイートであるかの指標として確認できる
Rubyにとって何故、カバレッジが大切なのか
・現状はRubyでテストでしか品質を担保できていない
カバレッジが何％以上みたいなのをゴールにするのは無意味
coverage.so は自分自身がRubyのコードに対して使うために作ったため設計が悪かったりするので次回以降のバージョンでよくしていきたい。
RubyのVMにてcoveragesをもっているので、coverage.so はその内容を取得してくることができる
@hayabusa333

Rubyのロバスト性を上げるために、まず手始めにカバレッジの改善に取り組んでいるという紹介です。
テストカバレッジとは何か、どういう種類のものがあるのかの解説ののち、
カバレッジをどう理解し、どう利用すべきかの紹介がされました。
また、Rubyのカバレッジのプランを紹介し、今後どの様に拡張していくかを説明して発表をまとめられました。
@ohrdev

テストカバレッジのなかの代表的なもの3つ
・Function coverage: 関数のうち何%がテストされているか？
・Line coverage: 行数のうち何%がテストされているか？
・Branch coverage: 各分岐がtrue/false全パターンチェックされているかどうか？
現状rubyではLine coverageしか採用されていないが、
ruby2.5ではFunctionとBranchに関してもサポート出来るように実装中である
小池

■ Improve extension API: C++ as better language for extension/Kouhei Sutou

C/C++のライブラリを使って高速化したかったが、バインディングを作ってCとRubyのオーバーヘッドを作りたいわけではなく、C/C++のみで解決したかった
機械学習のために速度をだしたかった
どうやって実現していくか
・拡張ライブラリをかけるように言語を拡張
・C以外の言語を使う
・便利APIを提供
C++ベースのAPIを使う長所
・既存の資産がつかいやすい
・デバッグがしやすい
・最適化にも使用できると思われる
C++ベースのAPIを使う短所
・コンパイルに時間がかかるので開発のテンポが悪くなる
・例外の扱いが大変
@hayabusa333

拡張ライブラリのAPIを良くしたいというテーマのお話
C/C++のライブラリを使ってRubyを高速化したい（バインディングではない）
できるだけC/C++の中で完結させて、Rubyとのやりとりを少なくするアプローチで
機会学習の文脈で配列・行列に対する演算をまとめるといったことをしたいが、
Cは悪くないけどもっといい感じの方法をとりたかった。
方針として、便利なAPIを提供するアプローチをとった。
C++ベースのAPIを使うメリット・デメリットの紹介
@ohrdev

■ Ruby, Opal and WebAssembly/Yutaka HARA

DXOpal(https://github.com/yhara/dxopal)という、ブラウザで動くRubyゲームライブラリの紹介。
元はDXRubyというWindows製のゲームライブラリ。

Rubyを書いたら、特にコンパイルや、ローカルサーバーを立てる必要なく、
file:///のパスでブラウザで開いたらすぐ動く。
Opal自体をOpalでJSに変換し、ajaxで.rbファイルを取りに行って動かす仕組み
描画はOpalの%x記法で、JSのcanvas APIとかを叩いている

WebAssemblyについては、Rubyを動かすのは現状難しそう。
Rubyが動的すぎるため、静的な形にコンパイルするのが難しい。
Rubyの処理系を全部載せる　と行った形や、全てをstructでラップするなどの方法はあるが、
パフォーマンスやサイズの問題などがある

また、WebAssemblyの主目的はファイルサイズを削減して転送速度を高めることなので、
実行速度自体はJSとそこまで差がない
銀の弾丸ではないし、未来は待てないので今すぐOpalを使って欲しい
hckaye

■ Automated Type Contracts Generation for Ruby/Valentin Fondaratov

IDEのサポートによるcode jump, typo, refactorなどの話
Rubocopでの静的解析では検出しきれない問題もある。検出方法を変えれば検出も可能であるがRubyのDSLは静的解析がしにくい。
関数に渡す引数の型へのcheckingをオートマトンを使用しての検出するためにどうしていくかなどの説明
この考えを使用して自動的にアノテーションを付加していく
データを集めるために、もっともっともっとテストが必要
Rubyist持っているプロジェクのテストの実行した情報をクラウドに集めて、よりよくしていくサイクルを回す
一人ではできないけれどもコミュニティなら限りなく100%に近づいていける
https://github.com/JetBrains/ruby-type-inference
@hayabusa333

■ Static Typo Checker in Ruby/Yuki Nishijima

スペルミスを検出する did_you_mean というgemについて

typo してるとサジェストしてくれるありがたい標準gem。
変数名やハッシュのキーのtypoもサジェスト。
必要のないサジェストはされなくなった。

static に使える（完全に静的ではない
VSCodeのプラグインにもなっている。
Ruby から stdout を通してVSCode に JSON返してる

いろいろな gem に依存したりしてて今はまだ遅い
小さいプロジェクトでは全然使えるけど、大きいプロジェクトだときついかも
静的解析超パワフル
平野

ruby2.3以降から導入されたdid_you_mean gemについて
初期はメソッド名や変数やkey名に関してのサジェストを行なっていたが
バージョンアップして、毎回ではなく本当に必要な時にだけ出すように修正された。
VSCodeにpluginがあり、実際に使ってエディタでもtypoチェックを行うデモがあったが、typo多いのですごくいいなと思いました。
did_you_meanは依存が多くとくにサジェストを探す部分の動作が遅いが、小さいプロジェクトであれば問題なく動く。
小池

型検査が欲しいと考えるのは、型検査ができるとバグの発見、検証が可能なドキュメンテーションができる、自動補完、リファクタリング時に使用できる、またより高度なプログラムの解析などを行えることができる。
そのため12年前から型チェックを入れようと動き続けているがRubyとの相性が悪く難航している
静的型推論の実装自体は存在しているけれども、最近のRubyではもう動かなくなってしまったりもしている
Rubyでの型は制限が多すぎており、現実的に求めるレベルでの型推論は難しい
なので制約を緩めて、必要十分な型を求めていくようにしていく。それだけでも十分に役に立つ
soutaroさんの 一番直近のtype checkerは下記
https://github.com/soutaro/steep
@hayabusa333

Ruby の型推論に関するお話。
まず型があるメリット
- バグを見つけやすい
- 検証可能なドキュメンテーション
- 自動補完
- リファクタリングの簡易化
- 高度なプログラムの解析
に使えるから
Ruby と型チェックの相性はあまりよくなくて、制約を緩める動きがされてる。
最近作った型チェッカーのsteepはアノテーションによる静的型検査を行う。型注釈を付けてチェックする。
平野

Rubyの型推論のお話
・型のメリット
・10年ほど前から型検査の取り組みはある
・静的型推論の仕組みもあるが、そもそも今のRubyで動かない
・各種先行研究を総括して、Rubyに対する制約が大きすぎて、実用的とは言い難い。平たく言えば、Rubyの型推論は無理なので制限を緩めてみる。それでも十分に役立つ
・steepの話
桂田

■ Serial Protocol Analyzer on Ruby/Mayumi EMORI

termios、serialportといったgemを使って、シリアルポートの通信をRubyで行った話。
termiosはCのstructのラッパー、serialportはWindowsのCOMポートでの通信を簡単に扱える
複雑そうに思えたが、実際に出来上がったコードはシンプルにできた
異なるプロセス間でのfile descriptorの共有で、IO.pipeを使うと上手く実装できた話など
hckaye

■ Asynchronous and Non-Blocking IO with Ruby/Joe Kutner

非同期処理、ノンブロッキング処理に関するセッション
ブロッキングの処理はマシンリソースやスタックフレーム（そしてお金）を消費するので悪、
ノンブロッキングの処理はそのデメリットがないので良いという説明がされました。
JRubyのシステムで、NettyとRatpackを使って非同期ノンブロッキングの処理をどう実現しているかの解説をデモを交えて解説していました。
RatpackはSinatraの様なマイクロフレームワークで、Nettyはイベントドリブンの非同期通信を担うプロダクト。ちょうど
Sinatra <=> Rack
の関係の様に、
Ratpack <=> Netty
という関係性を持っています。
セッションの質疑応答では、Akkaとの比較等について議論されました。
@ohrdev

■Ruby Language Server

自動補完の内容、メソッドの定義はどこにあるか、
エディタとサーバがプロトコルで通信を行っている
各エディタが独自にプラグインを実装していたが、Language Serverがあることによって、エディタ側でLanguage Serverに対応すればよくなる
Microsoftが出してきたものだけど、Rubyの自動補完なんだからRubyで実装したい！
最低限必要なのはJSON-RFCで、トランスポート層の制限などはないもよう
Language Serverのプロトコル情報
https://github.com/Microsoft/language-server-protocol
@hayabusa333

LanguageServerとは、エディタ等のツールに対して自動補完やメソッド定義といった情報を提供するサーバーのことで、JSON-RPCベースのLanguageServerProtocol(LSP)でプロトコルが定義されています。
Ruby対応のプロダクトが存在しなかったので作成することにしたそうです。
既存のプロダクトはnodeベースのものしかなく、Rubyで書くためにまずLSPのgemを作成したとのことです。発表の後半では、このLSPを使ってどのように、LanguageServerを実装しているかの解説が行われました。
@ohrdev

■Bending The Curve: Putting Rust in Ruby with Helix

Helix: 
https://github.com/tildeio/helix
http://usehelix.com/
を用いて、Rubyのnative extensionがRustで書ける　という話。
Cだと危険な操作ができてしまったり、maintenanceabilityが低いのでRust
Rustの強力なmacroを使ったDSLで、Cと比べてnative extensionを書くのに必要な行数が凄く短く書ける
Rubyで普通にclass定義する+α程度。
いくつか実際にHelixで作ったnative extensionの利用例や、どのように実現しているかの一部の紹介なども。

個人的に面白そうで、試してみたいと思った。
@hckaye

■Food, Wine and Machine Learning: Teaching a Bot to Taste/Mai Nguyen

冒頭でAI, Machine Learning, Deep Learningの関係ををわかりやすく教えてくれている。
ごっちゃになりがちなので意外とこういう前提宣言みたいなのは地味に大事だなと思う。
Sessionは機械学習の基本的なところをWineとFoodの実例の話に沿ってわかりやすく教えてくれていた。デモも楽しかった。
@hisahiko

食べ物にあうワインを提案してくれるbotを作成した。
Pycallを使ってrubyからpythonを呼び出す形での機械学習。
食べ物はレシピの原料から、味ごとに要素を分けて味を学習させ、
ワインも渋さや重さ等およそ20近い項目の情報を学習させていた。
機械学習をゼロからやってみる時に必要な流れが体系的に学べるながれだった。
小池

ワインが好きでワインづくりとかやってたんだけど、
いろいろ質問がきたのでワインのサジェストを自動化したいっていう思いから始めたらしい。
動機がすごくエンジニアっぽくていいなと思った。
そして、Rubyが好きなので機械学習もRubyでやったとのこと。
ざっくり言うとデータを作ってトレーニングさせると言う流れなんだけど、
いいデータを作る方法・データをよくする方法とか、
トレーニングデータセットでトレーニングして、テストデータセットで評価して、を繰り返してmodelを作るって話とか、
機械学習を始めるにあたっての必要な要素をわかりやすく教えてもらった。
実際にbot使ってみたけど、ラーメンに合うおすすめワインも教えてくれて便利すぎた。
平野