RubyKaigi2017 速報記事 1日目 #RubyKaigi2017

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

■ keynote/nobu

パッチモンスターnobuさんの発表
ゆるふわだったり、ガチだったり
キーノート中のライブコミットが行われる
キーノート中のコミットはお、おっとなって新鮮だった


面白いと思ったのは
# p = 2
p (-1.3).abs #=> 1.3

p = 2を代入すると
p (-1.3).abs #=> -1.3

下のケースはp(-1.3)と(-1.3)がpのメソッド引数として解釈されるため
-wオプションをつけて実行するとその警告文が表示
By hckaye


day1 キーノート感想：
・キーノート中コミット新しい
・parse.yのつらみ
・ゆるふわだけど、ゆるふわじゃない
By @ohrdev

■ Fiber in the 10th year/Koichi Sasada

・AutoFiberの紹介、Fiberのスケジューリング/スイッチングをネイティブに実行する、メリットは1)軽量 2)既存コードの変更が不要 3)スレッドより安全 デメリットは、非決定的なのでデバッグが難しい
@ohrdev


・さすが話の構成がわかりやすいと思った
Procとの比較、Threadの比較であまりFiberを詳しくない人にもPros/Consを見えやすい形で話を導入していっていた
・三ヶ月でFiberを導入した歴史の話。誰も反応してくれないけど導入してしまうのは、ゆるふわないい時代だなと思った
・実装に当たっては方針はポインタ切り替えで済む形を目指して、VMstack Machine stack Thread statusと最適化を進めていくのわかりやすかった
＝>でも、今年の最適化は全体と比べると効果が少なかったよう様子（今後の一環
桂田

■ API Development in 2017/Takafumi ONAKA

弊社@onkのセッション。API開発の系譜を体系的に解説。
RESTとは何かということから、RalisでどのようにRESTfulが推奨されていったか、
日本でどのようにRESTが受け入れられていったかなど歴史の話が興味深い。
個人的にはsoapとかRPCとか出て来て懐かしさ満載な気持ちになる。
@hisahiko


・RESTの歴史を振り返りながら、HTMLを返していた時代からスマートフォンアプリを作るようになってjsonを返すようになるまでにどのように適用していったかの話で弊社社員としてとても感慨深かった(感想)
・スキーマファースト開発をすることでクライアントとサーバーで実装の前にI/Fを決定する方法が主流になってきている
・I/Fの記述の中で特に、ドキュメントの保守性とテストの実行のしやすさにフォーカスして、どちらもYAMLの簡単な記述をすることで自動的に解決する方法を取っている
・記述が簡単になることで、サーバーサイドの知識がなくてもスキーマの定義が出来るようになる
・さらに未来はGraphQLなどの台頭により、クライアントサイドが必要なI/Fスキーマの要求をクエリによって取得することで、サーバーサイドの実装を爆速で終わらせてクライアントサイドに寄せた開発を可能にすることができるのではないか
小池


・JSON Schema をインフラに、APIを書くライブラリが増えた
・スキーマファースト開発でサーバとクライアントの認識合わせが楽になった
・GraphQLでよりクライアントサイドとサーバサイドの溝が埋まる、かも
・型があるのは良い
・型良い
平野

■ C how to supercharge Ruby with Rubex/Sameer Deshmukh

RubyのC拡張を簡単に記述するための言語の紹介
C拡張は、難しい、docが少ない、debugが大変という問題があった
独自のstruct宣言や例外処理等をRubyライクに書けて使いやすい
https://github.com/SciRuby/rubex
@ohrdev

■ How Close is Ruby 3×3 For Production Web Apps?/Noah Gibbs

実際のプロダクションで使われているコードにてRubyの速度改善についての、どのくらい改善してきたかについての話
今回、ベンチマークのために使われたアプリケーションは Discourse と呼ばれるWebアプリ
Rubyのバージョンが上がるについれて、速度はどんどん改善されており、Discourseが重くなったのを含めてもRuby2.0.0からRuby2.4.1では150%程度の速度改善が見られる
初回リクエストにかかる時間に関してはRuby2.0.0からRuby2.4.1で30%程度改善している。
ソースコードはこちらなので、同様のベンチマークができる
https://github.com/noahgibbs/rails_ruby_bench
@hayabusa333

■ Compiling Ruby/Kevin Deisz

まずは、Ruby1.8以下での ASTに関しての話
続いて、YARVに切り替わってからの話、それほどASTとの差異はない様子
コードのロードと評価周りの概要の説明があり、その後にRubyVM :: InstructionSequence :: load_iseq を使っての魔改造して、コードをロードしてから評価する前にコードの内容を書き換えたりした内容についての話
@hayabusa333

■ dRuby on Browser/Yoh Osaki

drb-websocket opal-drbというgemを用いてdRubyをブラウザで動かすデモ
(OpalというRuby->JSトランスパイラ, WebSocket プロトコルプラグインがベース)
dRubyを用いると、複数クライアント-サーバー間で状態を共有するアプリケーションを作りやすい
クライアントが透過的にサーバーにあるオブジェクトを触ることができる。
Google Appsのような、共同の人数で１つのドキュメントを編集するようなものを実装するとき便利

ついでに、JavaScriptへのdisがちょくちょく
hckaye 

■ Gemification for Ruby 2.5/3.0/SHIBATA Hiroshi

Rubyの追加機能をGemにすることでRubyと追加機能を疎結合にすることによって
新バージョンで追加された機能を古いバージョンで使えるところが良い。
Ruby2.5からbundlerがdefault gemに統合される方向らしい。
結局いつも追加でインストールしてたからありがたい。
Versionをユーザーがどうコントロールするかとか問題もあるらしい。
@hisahiko

現状の標準添付ライブラリのGemの形にして依存性を減らしていきたいねという話。
利点として、疎結合になることでRubyのバージョンに依存しない更新が可能になるが、
同じように後方互換性を保つため努力も必要なので、そこの点で辛身もあるなと思った
あと、RubyGemsでの名前衝突の話が面白かった
桂田

■ Do Androids Dream of Electronic Dance Music?/Julian Cheal, Eric Weinstein

機械学習を使用して、音楽を作っていくお話
今回は音はMidiのデータを機械学習にて音声データとして学習してEDM(Electronic Dance Music)を作成するようにしているもよう
ソースコードは18行、うちコメントが13行、だいたい(93%)がPythonのコードで、それを呼び出している
実際に作成された音声を流していたけれども、すごく格好良かった！
@hayabusa333

機械学習の話をしていて、rubyで1から実装したのではなく、思ったがpythonをrubyで呼び出す実装だった。
でもプレイで実際作った音楽が流れたり、マイクパフォーマンスをしてくれたり、機械学習が作る音楽はループの中で少しずつメロディを変えるのでパーティー音楽との相性は抜群なのではないかと思いました。
ラストに向けて痺れる連続音の流れができていてなかなかテンションアガる！！
基本的なことだけれども、不協和音にならずメロディーとしてのつながりが認識できる音の連なりとして認識できるものになっているのは純粋に感心しました。
小池

■ Development of Data Science Ecosystem for Ruby/Kenta Murata

データマイニングで使用される言語としては、Python、R、Scalaなどがある
すでにRubyのアプリケーションで利益を出している環境でデータマイニングをしようとした場合にはどうなるか
・Rubyでデータマイニングできるようにする(データの制約によるコストがかかる
・Pythonなど他の言語と繋ぎこみをする(繋ぎこみの作成・修正によるコストがかかる
新しい選択肢を作るためにPyCallを作成した
PyCallからPandasやKerasを呼び出せるため、Railsへの組み込みも簡単である
データマイニングのライブラリがPythonで記載されていただけで、それをRubyから呼び出すことは何もおかしいことではない
PyCallを使ってみて、足りない機能の開発をしていこう
@hayabusa333

・データサイエンスの分野においてrubyを使うためには、rubyのみでやろうとするとgemの機能が足りず、JSON APIでRとかPythonにつなぐとしても、データ変換などのコストが高かった
・そこで、RubyからPythonを直接呼び出せるPyCallを作った
・これはRuby内でrequireすることでPhtyonのライブラリを呼び出すことが可能
・１年くらいで作ったらしいがすごすぎる
小池

将来的にRuby単体でできる範囲を増やすRed Data Tools PJというのが進められているらしい。
Apache Arrowの上で使えるRubyのツールを作るというものも含まれていているらしく、
Ruby Commiterの須藤さんがApache ArrowのPMCに入ったのも良い材料になりそう。
@hisahiko

データサイエンスの分野で使用する言語はPython/R、Scalaが一般的。
Rubyにはデータサイエンス分野のgemが不足しており、
システム関連系にJSONを利用するなど本質的にデータ分析とは無関係なコストが高かった。
PyCallは端的にいえば、RubyからPythonのライブラリを呼び出せるもので、
「require pandas」ができる　(import pandas as .. ではない、すごい違和感)
デモでは、rubyスクリプトでpandasの利用、rails と pandasの連携、深層学習フレームワークとの連携をしていた。
Pycallは行列演算などタスクそのものが重量級な場合、相対的にオーバーヘッドが小さくなるが、
小さなタスクの場合は、pycallのオーバーヘッドの方が大きくなる。
* 素直にpython使う方が楽な気がするけど、Rails との連携はかっこよかった
桂田