昨日のAfterPartyの疲れもあったのか、正直眠かったけど、なんとか最初のセッションからこれ
All bugfixes are incompatibilities
これまでのBugfixの経験談を主に語ってもらい、普段Rubyコミッターやメンテナーがどうやってお仕事してるのか知れて楽しかった)これを聞いて思ったけど、redmineの動向とか追っておけば、来年のRubyKaigiとかで同じようなセッションあったときに「あ〜あの話ね〜」ってなって面白そう)。
初日にMatzも言っていたが、既存のRubyコードが壊れないことを考慮して互換性や名前を非常に考えながら取り組んでいて、感謝の気持ちしか起きなかった。こういったメンテナンスポリシーとは逆に破壊的な変更を許容してどんどんアップデートしていくと、進化は早くなるかもしれないが、こういったポリシーのほうが僕ら利用させてもらう立場的に本当に感謝しか無い(IO.read
、File.read
でブロック変数の最初にパイプ渡したらそれ以降に記述したコマンドを実行してしまう話を禁止するか、互換性を保つためにwarningを喚起するだけにとどまるかの議論も、聞いてて楽しかった)。
parse.y
は魔境
better csv processing with ruby 2.6
終始、漫才感のある発表で、内容ともに楽しかった!
csvのパース、エクスポートを高速化した話が主。
「CSV,generate_line
vs CSV#<<
」の話では、複数行書き出す時は<<
を使うと、10倍も早くなっちゃうのよ〜〜すご〜〜〜い(each_line
が最速のパース方法らしいけど、クオートがあるとうまく出来ないという制約があるらしい)。
どうやって、これらの高速化出来たのかという話についても、Rubyのコア部分の話になるのかなと思って身構えたが、そんなことはなくて、普段僕レベルでも知っているメソッドのたちが登場した。
例えば、複雑なクオートを利用しているcsvだとsplit
を使うと遅くなってしまうらしいので、StringScanner(.scan)
を利用したらしく、split
使うと遅くなるし、コードも汚くなるけど、scan
ならコードきれいになりやすくて、メンテナンスしやすいし、性能が劣化がないというメリットを説明してくれて、なるほど〜となった。
ただ逆に、複雑なクオートではなく、単純なクオートを使ったcsvだと、StringScanner
では遅くなってしまうらしく、そっちはsplit
を利用していた。ケースバイケースで使い分けてる。
他にも、CSVオブジェクトを作成するタイミングを遅延化(lazy
)して、毎回オブジェクトを初期化する無駄を省いて高速化したという話もあった。これも、僕らが普段使うような@a ||= object
みたいなコードが出てきて、ふむふむってなれた。
今後もこれらの高速化に取り組むらしくが、まだutf-8
などへの文字エンコーディングの速度が問題らしく、これが今後の主な課題らしい。
お手頃なKEN.CSV
みたいなcsvを、どっかから取ってきてcsvいじってみたくなった。
メモ
quate_char:
オプションparse_column_value
liberal_parsing
オプションbackslash
オプションstrip
オプションgem install csv
でとりあえず早い方の使えるぜ!RedDataTools
の取組の一環
Ovto: Frontend web framework for Rubyists
「自給自足プログラミング」これ好き。
OvtoというHyperApp
というJS製のFWに強く影響してて、更にOpal
によってRubyでフロントエンドもかけちゃうフロントエンドフレームワークを紹介してもらった。単純に楽しそう。
普段、VueとかReactは趣味で触っていたので、VirtualDOMやReduxは知っていたが、その辺りの基礎的な説明から入ってくれて、それらを機能が使えるHyperapp
について紹介から始まった。その後、Rubyからjsコードを生成してくれるOpal
も紹介してもらい、その後それらを使った表題のFWの説明とデモを見せてくれた。
jsは嫌いじゃないけど、普段使っているrubyでフロントも書きたい...無いから、作った...まさに自給自足プログラミングを体現していた。本当楽しそう。
早速触ってみました。東京帰ったら、もっと弄ってみようっと。
#rubykaigi さっそくovtoで遊んでみる 🐙 pic.twitter.com/WD4DyWxYHK
— kamelo151515 (@kamelo151515) April 19, 2019
メモ
runtime.rb
: OvtoApp -> ovtoが変換 -> JS(VirtualDOM -> hyperappcoreに送る。アプリ側の処理が重くない限り、ある程度の速度は担保できる?wired_actions.rb
???You might not need redux
- SSR, routeも欲しいという話がでたら、作る予定。
The fastest way to bootstrap Ruby on Rails
uzuraさんのセッション。
CRIU
は初めて聞いたし興味津々だった。linuxのプロセス情報をimageでdumpしてくれるらしく、dumpしたimageは別ホストでrestoreすれば、同じコンテナを簡単にマイグレーションできる優れものらしい。
また、CRIU
を利用することで、例えばモノリシックで大きなRailsアプリケーションとかでも、linuxのプロセス初期化をうまいことスキップしてくれるので、その初期化分の時間をreduceできて、結果的にbootstrap処理時間が早くなるというものだった。また、一つのホスト上のコンテナが死んでも、自動で別ホストでリスタートしてアクセスもそっちに流すようこともしてくれる。コンテナスケールアウトのコストも削減。
ほえ〜と思いながらここまで聞いていたが、ここからが本題で。
これらはコンテナ環境で利用できるが、VM環境をサポートしたものが無いので、同じようにmigration,checkpoint,restore
を実現するGrenadine
を紹介していただいた。
英語もわかりやすかったし、Grenadine
触ってみたい!ってなったけど、正直コンテナとか園周辺の知識というが個人的に乏しかったので、こういった機能とかワードがあるんだな〜というのも知れてよかった。dockerにも既にcheckpointの機能は既にあるらしいのだが、まだまだ出たばかりということもあり、Grenadine
を作るきっかけにももなったらしい。作ってしまうのですごい。。。
CloudNativeバンザイ!!!!
Benchmarking your code, inside and out
いままで聞いたセッションとは毛色が違う内容だった。。。と思う、、、英語リスニング力が弱くてわからなかった...。
多分、Micro benchmarking
に関する取り組みとか、rally
などを利用した計測のベストプラクティスとか話してくれたのかな...。くっ...、英語リスニング力付けたい
最後のLT大会も楽しかった〜〜〜。。。。明日は最終日....あっという間だ。