RubyKaigi 2018 2日目

cuzic (a.k.a Tomoya Kawanishi) です。

RubyKaigi 2018 2日目の速報です。

すとうさんのKeynote

slide.rabbit-shocker.org

• メンテナンスしているライブラリ数 130！！
  • Ruby でできるようになったことをたくさん紹介する
  • やることを探しながらやっているわけではなくて、必要になったからやっただけ
  • きっかけベースでやっている。

RSS/Atom っていう、バリデーション機能付き RSS パーサ

• 世間にあるWeb のフィードは不正。分かりやすく見つけたい。

• オプションが有効がデフォルトで、無効にもできる。

• REXML

  • REXML という Ruby だけで実装された XMLパーサもある。
  • Electric XML の実装を参考に再実装した REXML。
  • メンテナンスを引き継いだ
• コード懇親会
  • コード懇親会というのが今日の夜 19時くらいからある。実験的な企画。
  • 懇親会でも一緒に Rubyを書いたら楽しそう。
• REXML
  • REXML は 2010年からメンテナ
  • 属性を取得できる API を追加。
  • XPath 関連のバグを修正し、2.6 から更新されている。
  • Ruby だけで書かれているのでインストールが簡単
• LuaJIT の XMLライブラリを作っているとき、何か新しいことができないか考えた
  • REXML の API に欠けているものとして　NodeSet に気が付いた
  • search の返り値が NodeSet だと嬉しい
  • CSS セレクタや HTML5 対応も欠けていることに気が付いた

プレゼンテーションツールがきっかけとなったもの

• Rubyist 用のプレゼンテーションツール
• 今でも Rubyist 用のプレゼンテーションツールはほかにない
• Rubyist 用のプレゼンツールには RD のサポートが必要
• RD とは Ruby Document。最近の若い人は知らない
• いつもどおりスライドを公開できる。
  • gem push で公開できる
  • gem の中にスライドが入っている
  • こういう gem の使い方、 Eric からセーフというお墨付きをもらった。
• Ruby/gtk3
  • GUI 。一般的なプレゼンツールには GUI が必要
  • Ruby/GTK3 というのがあった。1998年に Matz が作り始めた。
  • プレゼンツールを作る時にこれ足りないみたいなのがあった。
  • Ruby でできることを増やすために、いい機会だな、といままでできなかったのをできるようにすることをしている。
    • 時間はかかるけど、趣味でやっているので、いい。
  • もともと手書きでバインディングを記述していたが、最近は自動生成するようにしている。
    • そのために Ruby/GI というのを使って、バインディングを実行時に作るようにしている。
    • 性能面では、手書きよりも遅く、動的な引数の変換や libffi での呼び出しのオーバーヘッドがかかる
  • JITコンパイルできないかな、と構想中。
• pango
  • 日本語の禁則処理というのができる
  • カラー絵文字もちゃんと使える
  • 双方向テキスト
• 画像操作
• PDF Parser/Renderer
• 音声・動画プレイヤ
  • カメラ
  • 顔認識
• PDF 出力
  • rcairo
  • Ruby の GC は閾値があって、動いている。Ruby の外で確保したメモリはいいタイミングで GC できず、増えていた
  • GC の実行頻度を改善した。
  • Ruby の外で確保したメモリを Ruby に教えることができる
• カンタンにインストールできることも必要
  • native-package-installer
  • インストールするだけで満足して、プレゼン作らなくなる現象が起こる
  • gem install するだけで、パッケージをインストールする
  • rake-compiler 。クロスコンパイルで fat gem をビルド。
  • プレゼンツールをきっかけにいろんなのを作った

テストきっかけのやつ

• test-unit というなんと Ruby でテストを書けるテスティングフレームワーク

  • Ruby の標準添付ライブラリから削除
  • grouping という機能を追加
  • メンテナンスしやすくなる

• reverse-backtrace

  • 逆順のバックトレース
  • ターミナルのときだけ逆順
  • test-unit でも同じような挙動にした。
• データ駆動テスト
• test-double
  • RR integration

全文検索きっかけのやつ

• 10年くらい前に全部検索を仕事でやり始めた。
  • 気づけば 10年やっているので、詳しくなった
  • Rroonga というのがあって、全文検索のライブラリ。
  • ライブラリの場合はサーバが不要
  • Ruby でかけるから嬉しい

• Rabbit のスライドを共有するサイト。

  • Rurema サーチというのもすごい速い Rubyドキュメントを検索するサービス
  • RDoc　Search というのもある。

• 国際化

  • RDoc を元にして、日本語化する
  • 毎回、同じコマンドを実行するだけで、いいかんじの動きをするように作っている
  • format というオプションがあって、pot というのを作っている
  • ツールの整理は終わった

• groonga-cient

  • client なので、ネットワーク上でサーバにアクセスするだけ、必要なものが多くない
  • そんなにリソースが必要ない
• Ranguba
  • 全文検索システムも作りかけのものがある。
  • クローラー
  • テキスト抽出
  • それをできるようなツールを作っている

Data Processing

• CSVパーサ。csv という標準ライブラリ

  • 2007年に fastercsv に置き換わった
  • CSV はけっこう使われているので、速く読み込めるようになるといろいろ便利
  • CSV は slow to parse。Too wild。
  • カンマで区切られていればいいんでしょ！複数行あっても一狂なの！？みたいな。
  • データの相互利用で、とても多くの場合 CSV が使われている

• Apache Arrow

  • データセットを取得するライブラリ解決するようにするアプローチとして Apache Arrow
  • Apache Arrow のけっこう上のポジションになった
    • commiter が一番下。pmc project management committer
    • pmc chair というのがその上にある
    • pmc というポジションに昇進した
    • chair になる気はない
  • Apache Arrow は最近のデータ処理界隈ではとても重要な部分を解決している
  • Ruby/GI をこっちでも活用してやっている。
  • この API では load というメソッドがいろんなフォーマットを統一的に扱えるようになっている
  • 同じような感じで save というのもある。
  • Apache parquet というデータフォーマットもあって、広く使われている。

• Red Parquet

  • 2017年から始めて、毎月１回オフラインの開発イベントをやっている
• Red Dataset
  • データセットを取得するライブラリ
  • Wikipedia のデータを簡単に扱え、Wikipedia 検索ができる
• Jekyll + Jupyter Notebook
  • Jekyll の中で Jupyter を開くことができる

• Red OpenCV

  • カメラを使って、保存するやつ

• RubyData Workshop

  • Afternoon break のあとの２枠
  • 相談しながらでも Ruby でのデータサイエンスを学ぶことができる

Faster Apps, No Memory Thrash: Get Your Memory Config Right

docs.google.com

• Big/Small/Tiny Objects
  • Tiny Obects
    • 64bit の中に含まれており、追加の容量が不要なオブジェクト
  • Small Objects
    • 40byte slot, 408 Slots per page
  • Big Objects
    • SLot に入らないサイズのオブジェクト
    • それぞれのオブジェクトが Slot を管理する

• GC

  • Ruby は世代別GC を採用
  • JVM はベスト。Ruby はいい線いってるがベストではない
  • Major と Minor の２世代がある
    • Major はぜんぶみて、Minor は新しいやつだけを見る
    • GC.start # major
    • GC.start(full_mark: false) # minor
  • Grow、/ Collect、/ Expand : The GC Cycle
  • The Best way Isn't Easy
    • ゴミが増えると Expand も GC も遅くなる
    • 小さいオブジェクトがたくさんあるよりも大きいオブジェクトが1つだけある方が効率がいい
    • 破壊的メソッドは CPU でもメモリの点でも良い
  • GC.stat を使うと、メモリの利用状況が分かる
    • Useful Parts
  • GC の実行回数や Free/Live なスロットの数が分かる

• RUBY GC 関係の環境変数がいくつかある

  • malloc するバイトやスロットの数を指定すると、起動時間を速くすることができる
  • EnvMem
    • メモリ、スロットを十分に拡張した状態で始めると、起動時間を短縮できる
    • env_mem gem を使うとそれができる
    • 環境変数を出力することができる
    • CRuby で 5%～7% のwar-up time の改善効果があった

• けど環境変数を設定するのは大変

  • もっと簡単でもっと速くなる方法はないのか？
  • ある
  • Memory Allocator は OS 標準の malloc 以外にもあり、
  • 特に jemalloc はより良い。
  • jemalloc を使うと 10% 程度の性能改善が見込める
  • 採用実績も多く、Ruby もサポートしている。

• RUBY_CONFIGURE_OPTS オプション付きでコンパイルする。

  • LESS WASTE、適切な環境変数設定、jemalloc 、最新のRuby
  • Slot が使われていると１ページの 408スロットが解放されないと、動かせない
  • live なスロット数と エデンのページ数 * 408 の比で利用率を出せる。
  • GC::Profiler を有効化すると、より詳細な GC に関する情報が得られる
  • GC::Profiler.report というのがある。

ささだこういちさん Guild

• RubyKaigi 2016 新しい並列性モデルを提案した
  • 進捗報告
  • スレッドプログラムは人類にはとても難しい。
  • Ruby 2.6 Proc#call を 1.4倍速にする
  • block.call は block がパラメータとして渡されたときに高速化
• Cookpad のパーティに行きたいならブースに来てね。

• Ruby プログラマがもっとも気にするのは生産性

  • マルチCPU をちゃんと活用したい

• RubyKaigi 2016 の提案

  • Guild を導入し、Threadを Guild で置き換える
  • Guild は共有変数を持たない
  • Guild は少なくとも１つのスレッドから構成される
• デモ
• 100回くらいの再帰呼び出しから Guild を使う方が高速
  • Guild を管理するオーバヘッドがあるので、数が少ないと不利になる。
  • Guild は GC によりグローバルロックが発生し、複数の Guild だと遅くなる
• Guild Specification
• Thread を Guild に変えれば同じように使える
• Thread-unsafe なプログラムは Guild では書けない
  • Mutable なオブジェクトが共有不可能だから
• ふつうは、ローカルオブジェクトがたくさんあって、共有オブジェクトが少しだけある
• Shareable Objects
  • Immutable Objects。Numeric、Frozen String、Symbol
  • 現在の freeze は shallow freeze。これから deep freeze を導入するかも。
• Special mutable Objects
  • Clojure 的なソフトウェアトランザクショナルメモリを導入する
  • isolated なブロックを導入し、呼び出すことができる
• Inter Guild コミュニケーション API
  • Actor モデル。
  • destination が Guild オブジェクトと一致しているというインタフェース
• Guild Implementation
  • Before Guild
    • 複数スレッドの同時実行ができなかった *After Guild
    • 複数の処理を並行実行できる
• Garbage Collection
  • GC を実行する間は、すべての Guild を停止する

mruby can be more lightweight

• チームやまねっこの中の人
• Toppers Project というのがあって、リアルタイムOS を作っている
  • SWEST という組込み向けの合宿のイベントがあって、まつもとさんも来る
  • 平鍋さんと高田先生（リアルタイムOSの人）も来る
  • 組込みイベントに参加するのなら、今年がチャンス
• mruby をもっと小さくする！

• mruby 用の IDE を作る

  • VSCode の上で mruby 用のデバッグができるようにする
  • Eclipse 用のデバッガを開発したが、Eclipse は Rubyist には魅力的ではなかった
  • VSCode だったら使ってもらえるかな、と期待して、移植作業を行っている
  • VSCode は extension をつっこめるようになっている
  • 拡張で入るようになっている
  • 他の人のデバッガの実装があったので、参考にしていたが、C++ のデバッガがオープンソースになった
  • マイクロソフトはコード補完の方をかくしたかったようで、デバッガの方は出してくれた
  • せっかくなので、今作っているプロジェクトを見せたい
  • ふつうの C のデバッグ用のツール
  • mruby のステップ実行や変数のウォッチなどができる
  • mruby のデバッグが IDE からできる

• ET robot contest

  • なかば強引に mruby を使ってロボコンを戦うというのをやっていたら、協力してくれる人が増えてきた
• 今日の話は最近のマイコンはメモリが潤沢だから、と言ってたんだけど小さくなきゃダメだわ、と宗旨変え。
  • それはなぜか、という話。どうやってメモリを小さくするか
  • オススメのボードは何かといわれたときに、うっとなってしまう。
  • Arduino とかは電子工作している人にはよく出てくる。
  • 2000円くらいのボードで動かしたいと思って、やっている。
• 去年は標準の mruby をむりやり動かすというのをやっていた。
  • そうでなくて、考えるにはどうすればいいか、考えた。
  • みなさんが知っているのは401のボード
  • RAM が少ないやつの方が利用者が多く、ネットにも情報が多い
  • RAM 96KB で動かせるようにしようと考えた
• F401 で動くようにするために何をしたか
  • 実行時にメソッドを書き換えられるように　RAM に置く人が多い
  • 追加するコードを最小限にしようと思って、障害物までのコードを図るセンサ。それをするだけのプログラムを書いた。
  • default は何もしない状態。どんどん小さくなったら、小さいボードに乗せ換えて、というかんじ。
  • mruby のデフォルトの設定をいじって、というかんじ。 　 * まんなかのだけだと、メモリの使用量としてはそこまでいってないので、大丈夫だけど、起動時まだけで使う。 　 * 起動してからもメモリを使うで実用的なことが難しいということで、もっと少なくても済むように工夫した
• ROM にシンボルをアサインした話
  • なんで、RAM にメソッド定義を置くのか
  • RAM を減らすためには ROM に置けるものは何でも ROM に置きたい
  • pre-defined method は ROMにおいて、あとから定義するメソッドを ROM に置く人が多い

以下、集中力が切れ、メモしておらず。。。

サミーア・デシュムク

speakerdeck.com

• 自己紹介
  • Pune 市出身
  • インドのオクスフォード
  • 東京工業大学の大学院生
  • 東京在住
  • Ruby Science Foundation に属している
• 過去の発表 　　 Daru 　　 Data Frame Library 　　 Rubex 　　 Rubex improvement（イマココ）
• Ruby はいいけど、遅い。 　　* Ruby nokogiri は libxml ラッパ。 fast_blank はC のラッパ
  • C 拡張を使うことで高速化できる
• 関連研究、Ruby inline、FFI、swig、Helix
• 理想的な解決方法は Rubex 　　* Rubex は Ruby のためのフェラーリ
• この１年間の改善点
  • サミーアさんがは日本語を話せるようになった！
  • Rubex はずっと安定した
  • 内部的なコードをたくさんリファクタリングした
  • C拡張の移植性・可読性の向上に少し目標をシフト
• Rubex の使い方
  • Rubex プログラムでは型を指定する
  • Rubex コードを C Code にして、 CRuby ランタイムで動作するようにする
  • arrは配列、hsh は配列をあらわすキーワード
  • each_with_index.to_h よりも Rubex で同じことを実装した方が 1.59倍速い
  • attach キーワードがあると allocation、dellocation の責任を Rubex が持つ
  • Rubex で構造体をラップすると、とても簡潔に書ける
  • cfunc キーワードがあると、C の関数を呼ぶことができる
  • 全自動でパッケージングされ、コンパイルできるメリットがある
• Ruby の GIL の説明。
  • rubex の中では GIL をなくす no_gil というキーワードがある 　　* rubex_csv_parser
    • 並列実行できるため、非常に高速化できる
    • C のデータ構造しか no_gil のブロックの中では使えない
    • GIL のリリースと再獲得に関するオーバーヘッドがある
  • 例外制御
• zero compliances with begin .. end
  • Rubex はとてもよい抽象を提供
• memory view があると NMatrix や NArray gem で役立つ
• Ruby Plot というプロジェクトが数週間前にはじまった
• Nmatrix と numo/narray の並立
  • その間のブリッジが必要
  • plures ソリューションになりそう
  • plures は numpy を作った Quansight がサポートしている

Red Data Tools Workshop

GitHub - RubyData/rubykaigi2018

JupyterNotebook を使えば自学自習可能。

Red Data Tools に関する LT

Red Data Tools での取り組み紹介

• 発表者名をメモし忘れた
• OSS Gate というイベントに参加したことがあって、興味を持った
• Apache Arrow のバインディングを開発
• Ruby とかほかのスクリプト言語からでも使えるように開発している
• GObject Introspection を利用して開発している
• Apache Arrow は C++ で開発されているが、このプロジェクトでは言語の知識は問題ではないということで、開発をしている
• 具体的には
  • ドキュメントの修正をやっていた
    • インストール手順を修正したり
    • こういうのって、あまり知らない人の方が気づきやすいというか、こういう修正からやった方がいい
  • garrow_chunked_array_slice
  • Arrow::ChunkedArray#slice
  • スライスを使えるようにしている
  • Arrow::Decimal128 を追加している
  • ここの開発のところをごにょごにょやっている
  • オブジェクトを作れるだけというのみ
  • Apache Arrow はいろんなものを配列で扱える
  • 今後は Decimal も配列で扱えるようにしようとしていきたい
• 須藤さんのコメント
  • 分からないからやってみて勉強するというやり方もいいと思っている
  • 知らないからやる、できるというのはいいと思った。
  • Decimal 知らないところから始まっている
  • データサイエンス分からないというのがあっても、やれば分かるのでいいんですよ。

@naitoh さん

• Red Chainer

  • お仕事では Python を使っている
  • Ruby のツールがないので、　Python のツールを移植したいと思いだした
  • Python から移植するのを手助けする py2rb.py を開発
  • RejectKaigi2017 で発表
  • Red Chainer を紹介されたので、プロジェクトにジョイン

• Red Chainer

  • Chainer 2.0 を Ruby にポーティングする仕事をした。
  • 活性化関数の追加、テストコードの追加。iris の例を追加。

• Numo::NArray への取り組み

  • Red Chainer が遅いので、 Numo::NArray を調査 *バグ報告、改善要望

• Red Chainer の実装状況

  • 活性化関数 15 vs 5
  • 損失関数 17 vs 2
  • 最適化手法 9 vs 2
  • connection 12 vs 2
  • pooling 14 vs 3
  • example を増やしたい。対応関数を増やしたい。

• Red Chainer の開発について 　　* IDeepのサポート

  • GPU版は開発中の Cumo を利用していくことを想定

• 須藤さんコメント 　　 内藤さんは Python の知識を Ruby で活かしたい、という立場 　　 example を増やしていくと、内部への理解も深まっていく

@hatappi さん

• 一年間の振り返りの話
• Red Data Tools との出会い
  • OSS Gate in Spee
  • OSS 開発サポート
  • 毎月すとうさんに来てもらっている
  • そのときに Red Data Tools を紹介してもらっている
• Red Chainer
  • Red Chainer はさっきの紹介があったとおり
  • 深層学習で必要な各種 API を順次追加している
  • 昨日も発表したが、 Red Chainer は特定のネットワークを構築するというよりは、任意のネットワークを作るというのがやりたいこと
• Red Chainer の歴史
  • 2017年の8月が最初のコミット
  • Chainerの2系を見ながら、せっせと移行するという人力の作業をしていた
  • 2017年の 10月に最初のリリースをした
  • 最初は MNIST をサンプルとした
  • CNN 用のAPI を提供している
• データ処理で使われるデータセットを取り出しやすくしたもの 　　* データセットからの取り出すところを担当している
  • Red Chainer に取り込んだものを扱うこともできる
• CIFAR
  • Python の形式では提供されている
  • 他の場合は binary を扱うことができる
• 開発モチベーション
  • まだないものを開発することがしあわせ
  • いろんな人と開発できる
  • Ruby をキメると気持ちいい
  • 動くようになると、一人で叫んだりする
• Continued development
  • 会社だとある程度、強制力が働く
  • 継続して開発していくモチベーションを保つというのが大切
  • 小さくていいので、ちょこっとずつ進める
  • 下のやつが好きな記事。John Resig さん
    • Write Code Every Day
    • 言われると難しい
    • 継続するということと近しい
    • 毎日 30分、コードを書く時間をとるようにしている
• まとめ
  • 開発は毎日しているので、止まることはない

（すとうさんコメント） * 他の人と一緒にできるというのもメリット * 会社以外の人とコードを書く機会がない人も多い * ほかの世界を知るといろいろ思うところがある。 * やることはいろいろとあるので、一緒にやっていくと面白い。

@youchan さん

• 自己紹介
  • Retrieva という会社にいる
  • Opal に関する発表をしている
  • レトリバは機械学習とか自然言語処理の会社
  • RubyKaigi のスポンサーにもなっている
• 3日目に How to get the dark power of ISeq という発表をする
  • RubyKaigi が終わるので、ようやく取り組めそう
• Data Visualization のライブラリ
  • Charty
  • シンプルにデータビジュアライズするというコンセプト
• このビジュアライズの部分にフォーカスしてやるということ
• 上にあるのはデータのレイヤ
• Array をそのまま出してあげましょうとか。
• Red Data Tools でも使っているものが多い
• いろんなソースを扱えるようにして、そことのつなぎはインタフェースを作ってあげて使えるようにしましょう、と。
• 出力先も抽象化して、いろんなツールでデータをビジュアライズしましょうというコンセプト
• 実際はまだそこまで行っていない
• Python の HoloViews というののサンプルを参考にしている
• API としては Ruby らしく書けるようにしている
• iris というデータセットをいろんな複数の軸の組合せで、複数の角度からみたデータの塊を描画できるようにする
• クラスタで分かれているというのを表示できるようにする
• アヤメの種類を判別するという例題なんだけど、それを可視化できるようになっている
• RubyKaigi が終わったらこっちにコントリビュートしたいと思っている

Red Data Tools Meetup and Cumo / @sonots さん

• 自己紹介
  • CRuby コミッタ。DeNA
  • Chainer の開発にたずさわっている
  • 昨日 Cumo というライブラリの話をした
• Cumo
  • 開発のきっかけになったのが、 Red Chainer に刺激された
  • おもしろそうだな、と思った
  • Numo を使っていたが、 Cuda をサポートするのを選んだ
  • Chainer の開発で GPU の知見が得られていたので、Ruby にも還元したいと思った

• Red Data Tools Meetup

  • マイルストーンとして機能している
  • 自分の進捗管理になっている
  • Ruby Association の Grant をもらってやっていた
  • Red Data Tools の日までにこれをやろう、みたいなかんじでマイルストーンを決めてやっている
  • 自分の中でうまく機能している

• Inplace Math Operations

  • 新しくメモリを確保しなくてもいいようにしたい。

Ruby Committers vs the World

Ruby 2.6.0 preview 2

• Ruby 2.6.0 preview 2 がリリースされました。
• naruse さんからひとこと
• リリースマネージャの naruse
• 2.6 の目玉は MJIT。
• preview 1 にも入っていた
• k0kubun さん
  • preview 2 のほうがだいぶ速い 　　* AST 構文木を取得する機能が追加された
• RubyGems 3 がマージされた
  • 目新しい機能はない
  • コードを消しまくっている
  • 中の構造はけっこう変えた
• endless Range： (1..) .. の右側を省略できるようになった。
  • 1 から無限大まで iteration するときに便利になった
• $SAFE に関して非互換性が導入された
  • $SAFE は機能を縮小しながら、消すことが決まっている
  • proc の中で値が変わらないという機能
  • これを外すことで、Proc が速くなるという成果があるので、
  • 性能のために非互換性はどうか、という議論もあったが $SAFE はいいだろ、という話になった
• preview 3 は夏のあと、９月とかその辺を予定している。
• 例外が多段になっているときに、元の例外のバックトレースを出力する機能を入れようと思っている

QA

• AST の機能は入るか？

  • こういうときのために、入れた。
  • ノードに特化した情報というのは出さないようにしている。
  • 今は１つのクラスて管理している
  • Proc から AST が欲しいとか。
  • 現在は既存のコードからとりたいという話もあるが、それは今ターゲットではない

• Language tooling support

  • 自動補完とか
  • 定義に飛ぶための機能
  • これも AST で解決できる機能はありそう
  • 伝統的に、コア開発ツールの手に余るので、third party に開発してもらうことを想定していた
  • language server protocol のプロトタイプとか
  • そういうのを進めていってもらいたいと思っている
  • 実行時にこういう情報がほしいとか、core に要望があれば提案は welcome
  • jetbrains から API 追加に関する相談があれば、対応する余地は多い
  • type db という構想はある。この位置にメソッドを定義しているとかを提供できるといいな、と思っている
  • IDE に直接組み込むところまではコアチームではやらない。
  • 使ってくれるなら、使ってもらって、不足している分は追加開発していくという進め方になる

• Refinement は 3で消しますか？

  • 前田さんが提供する機能は使われない
  • 消すつもりはない
  • 仕様が変更することができる
  • isolated proc という機能に関する発表がある
  • refinement は仕様がとても難しい
  • 継承関係がどうかとか、prepend したものとか、実装も仕様も難しすぎる
  • もっと薄いやつにするというような案もあったと思う
  • モジュールを refine したときにいま module なのにスーパークラスがあって、いかがなものかという意見がある
  • インスタンスメソッドとか reflection API でとってくるときは隠すとか。そういうことをする、とかはある

• autoload やめようぜ、という話

  • ほかに alternative がない
  • transition 移行パスは必要
  • 読み込みが遅延させたい。Rails では必要。
  • 遅延させたい
  • rails console はとても遅い。現在の科学が足りない。
  • .irbrc でたくさん autoload 書くとベンリ
  • autoload が欲しい理由は使わないものは遅延したい、メモリ使用量を抑制したい。
  • Rails でテストをまわすとか、autoload をなくすと開発効率に影響する。
  • Production 用途では重要な機能
  • ドメインごとにサービスが分かれているが１つの Rails で構成しているとき
  • autoload がなくなるとすべての持っている機能を読み込むことになる
  • autoload がなくなるとマジ困る
  • Rails の test モードと development モードとかでは必要。
  • Speee で Matz に Rails を教える会をやりたいと思っている
  • スピードアップの話だけなら全部ロードしてもなお速いようなマジカルな技術を生み出せばいいけど
  • それで解決するのかしないのかが分からない

• yield_self の名前を考えよう

  • いい名前
  • Ruby はコミッタはだれでも入れられる
  • RubyKaigi までに入らなかったらあきらめよう、と言っていたら
  • 自分で入れやがったという話
  • yield_self という名前では紛糾していた
  • then はキーワードと同じというのと、Promise で同じ名前がある
  • なんかヤだよ、と。とりあえず動詞でない、という
  • だから、なにか？
  • 何年かに１回、みんな反対みたいなのがある。
  • -> lambda もみんな反対
  • 何年かたったらみんな慣れてきた。
  • みんな妥協できるかな、となってくる。
  • 手をあげてもらうと、パラパラといる
  • then は案外 受け入れられる（かも）
  • もっと良い名前を提案してください。
  • リリースされたら、どうしようもない

• syntax sugar for method reference

  • map(&Math.:sqrt)
  • method メソッドはシンボルを渡すんだけど、シンボルである必要はない
  • 2.6 では決心がつかなければ、入らない可能性もある
  • 今さらまだまだ Ruby に文法が変わる余地があるというのは面白い
  • うしろに何かを付け加えるというのは考える余地がありそう
  • 大喜利
  • ` ( backtick ) を地上げする案があるがあった
  • 地上げの対象としては不可能じゃないと思った
    • package システムを導入したときに区切り文字として backtick を使う案を提案した
    • みんなに却下された

• startless Range：

  • Endless Range があるとどうか？
  • ..1.year と書くと１年前までを表現できるとベンリ
  • パーサとしては実装できそう。
  • begin less が必要なユースケースがあれば、入る可能性は高まる
  • 範囲としての使い方はある
  • 順番に生成するという Range の機能は使えない
  • 範囲として負の値を含めて指定したいときに便利
  • Rails を使うときは、beginless Range は欲しい
  • 使う人がいれば前向きに検討したい。実際にコーナーケースを考えてみたい。

• SO_ORIGINAL_DST という定数が欲しい

  • 興味を持てないテーマだったので、メモしてない。

• while with else keyword like Python

  • Python はすごく昔からある
  • どうしようと思ったことはある
  • end がつくやつはぜんぶ rescue 書けてもいいのではないか。
  • while に　else を使えるようにすると意味がコンフリクトする問題
  • if で　rescue できるようにしたとしたら else の意味がカオスになる