蚊帳の中の日記

ゆるく生きてます

rubykaigi 2日目 感想

昨日のAfterPartyの疲れもあったのか、正直眠かったけど、なんとか最初のセッションからこれ

All bugfixes are incompatibilities

これまでのBugfixの経験談を主に語ってもらい、普段Rubyコミッターやメンテナーがどうやってお仕事してるのか知れて楽しかった)これを聞いて思ったけど、redmineの動向とか追っておけば、来年のRubyKaigiとかで同じようなセッションあったときに「あ〜あの話ね〜」ってなって面白そう)。

初日にMatzも言っていたが、既存のRubyコードが壊れないことを考慮して互換性や名前を非常に考えながら取り組んでいて、感謝の気持ちしか起きなかった。こういったメンテナンスポリシーとは逆に破壊的な変更を許容してどんどんアップデートしていくと、進化は早くなるかもしれないが、こういったポリシーのほうが僕ら利用させてもらう立場的に本当に感謝しか無い(IO.readFile.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でフロントも書きたい...無いから、作った...まさに自給自足プログラミングを体現していた。本当楽しそう。

早速触ってみました。東京帰ったら、もっと弄ってみようっと。

メモ
  • 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大会も楽しかった〜〜〜。。。。明日は最終日....あっという間だ。