蚊帳の中の日記

ゆるく生きてます

rubykaigi 3日目 感想

下書き状態で、公開するのを忘れていた。。。いまさらopend。

Reducing ActiveRecord memory consumption using Apache Arrow

  • apache arrowというデータ処理系のツールや機能を多言語で共有して使えるする取り組みに期待
  • ARをapache arrowに最適化するために、ARのオブジェクトの中身(ActiveRecord::result)をapache arrowを扱えるオブジェクトに置き換えれる。
  • 行志向ではなく列志向のオブジェクトになれば、データ操作が早くなる。(raw-majoar vs column-majoar)。縦方向の検索に早くなるということ。

The future of the Bundled Bundler with RubyGems

  • まず、言語を入れたセットアップ完了ということで、bundlerを辞めたいという話
  • 改めて2FAなどの推奨
  • rubygem3は古いrubyのサポートを切って、色々と新機能が追加された。bundler2も同じ感じ。また古いrubyのサポートを切ったのでrubybuildの時間もすごく短縮された(いずれにしても長いけど)
  • bundlerのテスト ⇛ make test-bundler
  • Rspecの本体もruby本体に入れられる????!!!!革命。今まではmini-testとかであったけど、Rspecも入れられるのはすごすぎる
  • rdoc-6.0.4のエラー、、、見たことある気がする。
  • bundlerがないよ!って言ってたのが、Update BundlerVerionFinderが機能として追加されたので、その機構がエラーを吐いていた
  • dependencyゾルバといsてmonillio???みたいなのがある。bundler,rubygemでも使われている。
  • rubygem3(鋭意パッチを募集中)
  • gelうまく親和性を保っていければ...。

The challenges behind Ruby type checking

  • gem install steep
  • duck typingについて、どういったインターフェイスを呼び出すとプログラムが暗黙的に想定され、どういったオブジェクトを呼び出すのかも暗黙的に想定されるといってもいいかも
  • eval, define_method, ARのhas_manyとかもメタプロといえる。色々メタプロが活用されている物がある。
  • Rubyへの型定義
    • Rubyの標準ライブラリとして、先に型定義が使えるようなシグネチャを用意して、既存コード残しつつ、この型定義の浸透を広める狙い。
    • 現在、ruby-signatureというリポジトリで開発中
    • Rubyと同じ文法でかける。静的にrubyを読み込んで解析するだけで、rubyコードはrbi上では実行不可。
  • rbiについて聞いた感じ、いままでのRubyのコードと全く同じような書き方としては捉えないほうがいいかも知れない。 ruby <--> signature。
  • sorbetのセッション聞いてないから、その辺りとの兼ね合いを聞きたいな。
  • rubyのprivateMethodってmixinでアクセス出来てしまうので、その辺りも型シグネチャで確認することができるようになっている。privateMethodの型定義をするかどうかは開発者に委ねられる。

Cleaning up a huge ruby application

巨大なRailsアプリケーション Cookpadのコアコードが肥大化しているので、いらないコードは削除しようというプロジェクトとそれに伴って作ったツールのお話。 KitchenCleanerというセンスありまくりのツールで、定期的に未使用のコードが無いかどうかを検知して、疑わしいコードがあればtachikomaみたいにissueを立ててくれる。 実際に使われていないコード検知については、iseqloggerを使いRubyVMがRubyコードを解釈したときに出力されるiseq(instruction sequence)を見て、その結果をログインしているらしい。ログ情報はfluentdに送って、最終的にredshiftに溜め込んでいる模様。 ただ、このiseqを見る方法だと良くない部分はあるので、より綿密に見れるoneshot coverageといった方法でも実行されたコードを見たりする。

  • コード削除では既知と既知でないものもあり、今回は既知でないコード削除を対象。やはり、コストが高い作業で、本当に消して良いコードなのかを調査しなければいけない。これがなかなか不要なコードを削除できない理由の一つとも言える。
  • またどうしても優先順位が低いというのも、なかなか取り組めない理由の一つと言える。まあ、優先度を上げる提案をしないといけない。耳が痛い。priorityを他のタスクとも兼ね合って考える。
  • 未使用のテンプレートなどを探すのは向いていそうだけど、if文などの細かいところは検知がちょっと曖昧感があって、そういったところは実際にコードを見に行って判断しないと行けなそう
  • 今度はoneshot coverageという方法で、一度でも実行されたコード行を見てくれる。
  • ケースバイケースでコードカバレッジの精度が変わるので、うまく使い分けてる

  • alias_method?