RubyKaigi 2017 の1日目に参加したので、そのメモです。

最初の方は個人的なメモなので、興味がなければ飛ばして、オープニング以降からどうぞ。

移動と前夜祭

土曜日に姫路に寄ってから、岡山県の実家に泊まっていて、日曜に台風の影響で11時ごろから岡山の在来線が止まるということで、その前に移動していたので、広島には問題なく到着していました。広島では10時ごろから在来線が止まっていたようでした。 午後は新幹線も広島より西で停電があった影響で遅れたり、博多と広島の間は止まったりしていたようです。

飛行機はだいたい止まっていたようで、東京からの人はさっさと新幹線に切り替えた人は問題なくたどり着けて、遅く新幹線に乗った人は遅れていて、前夜祭に間に合わなかったりしたようです。

前夜祭は、ホテルから移動している時に傘が壊れる (1本骨が曲がる) ということはありましたが、問題なくたどり着いて参加できました。 終わった後はほとんど雨は降っていませんでした。 Twitter のハッシュタグ #rubykaigi をみていると、会場準備をしていたスタッフの人で終わった後にきて、残っていたものを食べたりお土産をもらったりしていた人もいるようでした。

朝の移動

近くのホテルに泊まっていたので、開場前に会場につけるかと思っていたら、ちょっと準備に手間取ってしまって、結局9:40頃に到着しました。

オープニング

オープニングというか最初のキーセッションの前のつなぎとして、松田さんが会場アンケートしたりしていました。 初参加の人が意外と多かったようです。

Ruby Forward

  • Money Forward によるスポンサーセッション
  • BtoC の新サービスを明日リリース予定
  • Ruby逆引きハンドブックの改訂版を出版(予定)
  • 福岡の開発拠点を新設

Making Ruby? ゆるふわRuby生活

  • Heroku の matz team
  • 日々の話
  • Repository は svn.ruby-lang.org がメインで github.com にはミラーがある
  • pull request は裏口
  • Why not Git?
  • ruby は Git より昔からあるから
  • 作業する人がいない
  • 個人的に hash がリビジョン番号の方が良い
  • コミッターにとっての利点不足
  • issue は redmine
  • 開発者会議
  • tarball からのビルドの仕方: configure + make
  • Out-of-place build
  • configure に色々オプションがあったりいろんな環境をサポートしていたり
  • 一度にビルドできる Makefile https://github.com/nobu/build-files/blob/master/Ruby.mk
  • repo からのビルド
  • subversion or git / autoconf / bison / gperf / ruby
  • BASERUBY, MINIRUBY
  • トラブルによりすとうさんのサポート
  • MINIRUBY の機能や制限
  • 2.4 までは miniruby と拡張ライブラリのビルドは parallel だったが、extconf.rb の実行が逐次実行だった
  • 親にしか依存していないので 2.5 では exts.mk ファイルを分割生成して parallel に実行できるようになって速くなった
  • 拡張ライブラリ作成時の問題点
  • C ヘッダーの場所とかが問題
  • Solution: trace_var
  • $extmk, $ruby
  • ? (突然の質疑応答タイム) → 特になし
  • Bug Report
  • ruby-list:50578
  • p = 2; p (-1.3).abs の話
  • スペースの有無によって意味ががらっと変わることがある
  • 良くいって罠
  • 少なくとも 1.1 からの仕様 (それより古いものはコンパイルが通らないので調べていない)
  • 悪魔城 parse.y
  • 難しくない?
  • ruby -w で警告が出るのでそのソースコード解説
  • EXPR_LABEL はキーワード引数の名前が置けるところ
  • lvar_defined
  • matz issue
  • ? 再び
  • literal symbol by intern
  • :"#{foo}" が intern を再定義していると Symbol 以外になることがある
  • 昨晩前夜祭の前に直した
  • Refinements で定義した to_s を String interpolation が呼んでくれない
  • .x86_64-darwin などをビルドディレクトリに使っている
  • .gitignore.*-* が入っている
  • make -C .x86_64-darwin exam commit
  • 違い: 変換が明示的に見えるようにするのと見えないようにする
  • 2.5 には目玉機能がない?
  • NEWS をみると色々
  • Reject された feature
  • 議論中
  • Kernel#method に対応する演算子?
  • Rightward assignment: -> とか => とか使っているので良いものがない

  • 質疑応答
  • extmk の分割の話で親子関係しか依存がないのを確認した? → digest が openssl に依存していた (チェックするためのメソッドを共有していた) のを切り分けた。 Windows で何かあったのを親子関係にした。実行時の依存ではなくビルド時の依存関係なのでもともと多くはなかった。
  • Rightward assignment の記号の提案 (:= が書籍では ← と書かれる言語があるので =: は?) → トークンの追加は衝突がなければ難しくない、a=:b がシンボルと衝突する。 a ~> b, a |> b ?
  • String#intern を再定義する? → する人もいるらしいので、先手を打って直した
  • yield_self が目玉機能になる? → 機能としては長い間要望されていたものが、名前問題でなかなか入らなかった。とりあえず説明的な名前で入れて、良い名前があれば alias 追加すればいいという感じで入った。

Fiber in the 10th year

  • ささださんすごいとツイートしてほしい話
  • 所属が変わっても基本的に ruby のコアの開発をしている
  • Fiber の紹介
  • Proc との違いは restart できる

  • Fiber の利用例
  • 内部イテレーターを外部イテレータ〜にする例
  • Enumerator が内部で Fiber を使っている
  • Agent simulation : ゲームのキャラクター表現など
  • Non-blocking IO scheduler

  • Thread との違い
  • timer で自動で切り替わるかどうか
  • I/O ブロックで勝手に切り替わるかどうか
  • 同期処理が必要かどうか
  • 次のコンテキストを指定する必要があるかどうか
  • パフォーマンス

  • 以上が Fiber の歴史

  • 背景: Ruby 1.9 における Callcc と Fiber
  • 2007/05 作り始め
  • Fiber の名前は Windows API から
  • 今では他の言語でも Fiber という名前が使われているものがある
  • 最初は Fiber#pass しかなかった

  • Coroutine or Semi-coroutine
  • Coroutine は難しいがパワフル
  • Semi-coroutine (Fiber) and Coroutine (Fiber::Core)
  • 大クラス主義 (big class principle) を理由に Fiber::Core を削除してマージ
  • Semi-coroutine: resume, Coroutine: transfer

  • Fiber の実装
  • 2007年: Copy machine stack
  • 2010年: Use Native support
  • 2017年: More light weight switching
  • 速度: 5% 改善, メモリ: 30% 削減
  • VM stack や Machine stack があるので構造体のメモリ削減の影響は小さい?
  • Guild に繋げるための整理になった

  • Auto Fiber proposal
  • Automatic schedule on I/O blocking
  • 次のターゲットを指定する必要がなくなる
  • 同期が必要になる
  • 利点: 既存のプログラムを変更する必要がない、Fiber 同様に軽い、Thread より安全
  • 欠点: Thread と同様にバグりやすい

  • 質疑応答
  • 想定より多かった使い方は? → IO のスケジュールに使ってくれるのが想定より多かった。Enumerator が隠蔽するので直接使う人は少ないと思っていた。
  • アーキテクチャ依存やパフォーマンスで苦労したと思ったが、一番苦労した点は? → アーキテクチャ依存部分の最初は 1.8 を参考にしたので、ほとんど苦労しなかった。NetBSD の setcontext が動かなかったとかの話。

Handling mails on a text editor

  • 通訳の方が Emacs を知らなかったので直前まで打ち合わせをしていた
  • 自己紹介
  • Ruby で書いたテキストエディタ
  • Textbringer
  • Emacs 風
  • ターミナル上のみ
  • Pure Ruby
  • かっこいい名前
  • Law, Chaos, and Cosmic Balance
  • エディターだと https://twitter.com/ujm/status/909642340863688704
  • コードの修正もたとえば rubocop を盲信するのではなくバランスが大事
  • キーバインディングは Emacs 風で help は少ないのでリンクからソースをみる
  • 実装詳細
  • Linked Line ではなく Buffer Gap を採用
  • Internal encoding: UTF-8
  • indexing が問題になったので、基本的に ASCII-8BIT で持っておいて必要に応じて force_encoding('UTF-8')
  • 配列を使うのは文字列に変換するのが force_encoding だけより重そうだったので採用せず
  • 部分再描画は curses 任せ
  • curses を使っているなら pure Ruby じゃないというツッコミがあった
  • 動的な部分で ruby の特徴を活かせる
  • eval_expression
  • eval_buffer
  • eval_region
  • Suppress warnings : $VERBOSE = nil
  • def を使っていない理由
  • Plugin
  • Mournmail
  • MUAs for Emacs の話
  • Demo
  • メールの同期にバックグラウンド処理が必要になる
  • UI スレッドを用意した
  • UI スレッド以外では Textbringer のメソッドをよんではいけない
  • 必要に応じて next_tick を使う
  • メールを扱うライブラリ: mail.gem, Net::IAMP
  • refine でローカルなモンキーパッチ
  • 質疑応答
  • Auto Fiber? → 通訳さんとの打ち合わせで聞けていなかった。切り替わりのタイミングが想定できなくなるのは向いていないかも。
  • Emacs なのにS式がない? → Ruby で実装していて Emacs ではない
  • Emacs だと M-x だと - つながり? → Textbringer はタブを押すと -_ に変換する
  • 名前空間の衝突は大丈夫? → 適切に prefix をつければいい

Gemification for Ruby 2.5/3.0

  • self.introduce
  • 歴史: RAA, RubyForge, gems.github.com, gemcutter.org, rubygems.org, bundler
  • 組み込みライブラリ: require しなくても使えるもの
  • 標準添付ライブラリ: 別途インストールしなくても require できるもの
  • Standard Libraries, Default Gems, Bundled Gems
  • Pure Ruby, C extensions
  • Standard Libraries: upstream が svn.ruby-lang.org
  • Default Gems: Upstream が GitHub の Ruby team
  • Bundled Gems: メンテナが別
  • Default gem
  • *.gemspec があると特別扱いされる
  • 具体例: ruby/openssl
  • メインの upstream は https://github.com/ruby/openssl
  • 利点: gem update openssl で新しい openssl gem を使える
  • セキュリティアップデートも、例えば最近の例なら json gem だけあげて ruby 本体をあげなくてもできる
  • psych : libyaml に依存、upstream に JRuby integration がある
  • rdoc: rdoc/rdoc から ruby/rdoc に移動
  • ripper 対応してくれた人が現れた
  • Bundled gems
  • gems/bundled_gems にある gem を普通にインストールする
  • アンインストールも普通にできる
  • test framework の問題
  • test-unit, minitest が upstream と非互換になった
  • 標準添付から外して本体のテスト専用に
  • test library がなくなるのは問題ということで bundled gem という方法が生み出された
  • rake は標準添付ライブラリでなくて良いのでは、ということで bundled gem になった例
  • bundled gem の問題
  • コンパイルがちゃんとできるかサポートできないので、拡張ライブラリを含むものはサポートしていない
  • bundled gem のテストが必要
  • Gemifying Ruby standard library
  • bundled gem や default gem の仕組みができたことで段階的に外していくことができるようになった
  • Gemification は利用者に利点は多いがメンテナは大変
  • たとえば rubygems はまだ Ruby 1.8 対応しているので大変
  • rubygems
  • rubygems/rubygems.org は rails で書かれているサイトそのもの
  • rubygems/rubygems はコマンドラインツール
  • メンテナなどは完全に別
  • Reserved words on rubygems.org
  • fileutils, fiddle, gdbm
  • Future
  • Ruby 2.5 では bundler が default gem に
  • RubyGems に Bundler 統合予定
  • 全部 default gem, bundled gem にしたい
  • rubygems-2.7.0 がテストで bundler を使うようになる
  • bundler-2.0 のリリース後に rubygems-3.0 は本体でも bundler を使うように開発していく予定
  • Gem activated problem for default gems
  • require into module
  • shared library 問題, LOADED_FEATURES 問題

How to optimize Ruby internal

  • 私用により途中から聞いていました。
  • 細かい改善の話でした。
  • 質疑応答
  • Hash の最適化で st_table を再利用するという案はなかったのか? → とりあえず想定していなかった? よく聞き取れず
  • 聞き取れず → Ruby のメソッド一つ一つを計測してどうなったのかだけ
  • ベンチマークツール? → Apple 提供の可視化ツール
  • CI に回すのがどれくらいできそうか? → 1時間半ぐらいかかるが大丈夫か? グラフ表示したい。→ RubyBench が何か持っているかも。
  • どのくらい網羅しているかとか、みんなで追加すればいいのではないかとか → 発表が終わったのでオープンにしていきたい
  • ユーザーがカスタマイズする余地が消えたもの、壊す可能性が消えたものの見極めは? → 基本はテストが通るもの

Development of Data Science Ecosystem for Ruby

  • BigData is important in your business
  • RubyKaigi 2016 in Kyoto で Ruby が Data Science に使えない話とどうすれば良いかという話をした
  • 今は使えるようになっている
  • 将来も使える状態を維持していきたい
  • self.introduce
  • 私はカエルです
  • 現状
  • Ruby で書かれているものに追加したい場合
  • Ruby だけでやるか Python や R を JSON 経由で併用する方法があった
  • 第3の選択肢として PyCall を作った
  • PyCall の話
  • 使用例
  • 数列の合計
  • bugs.ruby-lang.org の7月ごろのスナップショットをもらってデモ: ソースは https://github.com/mrkn/bugs-viewer-rk2017
  • Pandas.read_from_sql は第二引数に ActiveRecord の connection を渡せるように拡張してある
  • Object recognition (物体検出) by Keras
  • https://github.com/mrkn/ssd_keras
  • Python is a best friend of Ruby from now on
  • https://github.com/mrkn/pycall.rb
  • Python での選択肢は Python のみか Rpy2 で R と連携の2個
  • 今は PyCall を使えば良いが将来的には Ruby で
  • https://red-data-tools.github.io/
  • Apache Arrow https://arrow.apache.org/
  • 一つの言語で完結することは少ないので、データ交換が必要
  • シリアライズで結構 CPU 時間を使っている
  • シリアライズも組み合わせそれぞれから、共通化しようとしている
  • https://github.com/red-data-tools/red-arrow
  • Apache Arrow のコアメンバーにすとうさんが昨日入った
  • https://gitter.im/red-data-tools/ja https://gitter.im/red-data-tools/en
  • 明日の 13:50-15:50 in Room Ran で RubyData Workshop in RubyKaigi 2017
  • jupyter との連携は? → いい感じに使えている
  • Python のオブジェクトのメモリ管理と PyCall のオーバーヘッド → Ruby のオブジェクトが死んだ段階でデクリメントしている、オーバーヘッドは呼び出す処理による、 sin 関数などだとオーバーヘッドが大きいが numpy の行列計算などの重たい処理の場合はオーバーヘッドはあまり考えなくて良い
  • オブジェクトを変換しているか? → numpy のオブジェクトなどは変換していない、プリミティブは変換している

cookpad のスポンサーセッション

  • microservice 化でモデル数は減っている
  • なぜ Ruby Committer Sponsor ?
  • もっと良い言語が出てきたらどうするの? → Ruby を強くすれば良い
  • Ruby 3 に本気で向き合っている
  • cookpad << mame

Ruby Committers vs the World

コミッターなので壇上にいました。

  • 新コミッター紹介
  • rhe さん : openssl
  • k0kubun さん : ERB
  • watson さん : ちまちま速くするパッチを投げていたらコミッターになれた
  • 質問のサンプルとして、型注釈の話
  • 絶対書きたくない : 6人ぐらい
  • 書かなくても良いが書くと良くなる : 多め
  • コメントぐらいなら良い (いざとなれば無視できる) : 多め
  • OpenMP みたいな感じ?
  • rdoc みたいなのがうれしい
  • 古い処理系で無視されるといえば、すでにマジックコメントがある
  • 現状だと動くものが型で制限されると嫌
  • matz: nominal type は絶対採用しない、String と書いても structal にしたい、できれば未来のためにプログラムの中に書くのは採用したくない、最低でもコメントに留めていたい
  • 型を書かせたくないと思っているコミッター? → 4人ぐらい
  • Q(ujm): 右代入の本気度? →
  • akr: yield_self は右代入の代用の部分があるのではないか、左から右に流れるように書きたいことがあるのではないか
  • matz: 完全にフリーハンドであれば入れたい、長い歴史の中で記号を使い尽くしているので良い候補がない、既存のプログラムを壊れるような変更をしてまで入れるようなものではない
  • shyouhei: 他の言語では?
  • メモ取れず
  • durest: メソッドチェーンの話があったので、記号がなければメソッドでやってみるのはありではないか
  • 会場を含めたアンケート
  • 概念としてありは割といる
  • ないだろうはほとんどいない
  • Q(ujm): 変数とか定数とかどのあたりまでサポートするかという質問だった →
  • matz: 今代入の左辺になれるものは右代入でもサポートしたい
  • 多重代入は難しい?
  • Q: YARV の命令仕様を確定して公開すると他の言語処理系が作れる? → 変化していくために固定する予定はないという感じ
  • 他の案としては LLVM とか
  • Q: 右代入は setter= も対象? → matz: 当然
  • 一番大変なのは parser
  • 右代入で多重代入
  • 後置 if との組み合わせ? → akr: 今の代入は式なのでできる、右代入は文にするというのはありかもしれない
  • 機能制限するバージョンがあるか? → matz: ない、補助輪みたいなものは別のツールでサポートすれば良いのではないか
  • takao: 実際に使わせている子供達は補助輪を外したがっていたり、Ruby 認定資格を取りたがっていたりする場合もある
  • CI の実機が足りない問題は解決した? 今日の別の発表で Rails アプリケーションのベンチマークが取れるものが出てきている。Ruby 3x3 のユーザーからのフィードバックは何が必要? →
  • mame: 速くするパッチが必要 (watoson さんがやっているような)
  • 以前 Mac の CI が足りないとか、ベンチマークが足りないとかいっていたが解決した? → matz: その件についてはだいぶ解決した
  • hsbt: CI 用のマシンは Ruby Association (RA) 経由である程度手配できるようになったが、 Windows の環境が足りない
  • Windows Server とか Visual Studio のライセンスを良い感じにする必要がある
  • matz: benchmark CI?
  • naruse: watson さんのが欲しい
  • ko1: RA や日本 Ruby の会経由で CI 用のマシンはなんとかなっている
  • さらにその上でベンチマークをなんとかしたい
  • RubyBench というのが何かやっている
  • watson: 今は個人のマシンで動かしている、自宅にはおきたくない、安定した結果が欲しいので実機が望ましい、足りないベンチマークを増やしたい
  • ko1: rails とか optcarrot とかだけではなく、これを速くして欲しいというのを提案して欲しい
  • matz: RA か日本 Ruby の会に寄付してくれると嬉しいが控除などはないのが申し訳ない
  • shyouhei: パッチを投稿していただくのはありがたいが、敷居が高いなら、雇って書かせるという手がある
  • Ruby 会議の運営を手伝ってもらえると、手が空いて間接的に、というのもある
  • hsbt: RubyKaigi 後に回復したら、パフォーマンスベンチを進めたい
  • matz: 転職活動している人?
  • ko1: 手があげられないのでは。
  • ko1: optcarrot と Rails 以外に使っている人?
  • shugo: テキストエディタが速くなると嬉しい、String が速くなるとうれしい
  • 会場: fluentd
  • 会場: puppet
  • amatsuda: ハッシュが速くなったので、fluentd が速くなったという話を聞いた
  • Q(ujm): Ruby, C, Streem, Emacs Lisp 以外に好きな言語?
  • matz: Swift, Clojure
  • mame: OCaml, Haskell?
  • takano: Smalltalk
  • akr: coq
  • nobu: FORTH
  • mrkn: julia
  • ko1: Ruby は好きだけど不満があるから直したい人が壇上には多いのでは
  • Q: インスピレーションの源になっているのは何?
  • matz: Lisp からたくさん、今後もたぶん、最近 2.0 の method prepend は CLOS のメソッドコンビネーション
  • takano: Lisp のマクロが羨ましい
  • mrkn: julia 推し
  • transform_keys は Active Support (AS) と挙動は同じ? → nobu: 同じはず、Hash#slice も同様
  • amatsuda: 使い勝手は変わらないが、C実装になるのでちょっと速くなる
  • AS のようなものをどんどん入れる?
  • matz: 全部入れる気はないが、use case などでちゃんと説得してもらえば入る可能性はある、AS に入っているからという理由で入ることはない
  • amatsuda: AS は Web では便利だが、汎用的に入れるものかどうかは疑問
  • ko1: 年単位で議論して入ったものもある (入らなかったものもある)
  • amatsuda: 違う仕様で入ったものもある、 Array#sum とか
  • mrkn: Cで書くと float の誤差が改善されるということで、そういう実装が入った

懇親会

食べ物の列は待っていれば短くなるかなと思って、話をしながら待っていたらそんなことはなかったので、並んでみたらギリギリ少し残っていたのが食べられて、その後で野菜が残っているのをみつけたのでそれを食べたりしていたので、全然食べられないということはなかったので、二次会には行きませんでした。

明日の懇親会と違って、オフィシャルパーティーはみんな集まっているので、複数人で話したいこと(getter for original information of Enumeratorの件)は、この日のうちに話しておくべきだと思ったのですが、集められなかったので無理でした。後から確認したら、頑張って英語で書いたおかげで代わりにメンテナーを説得しようとしてくれる人がいて、結果的には大丈夫そうです。いいたかったのも、直接は関係がないので mrkn さんとかに説得を頑張って欲しいと言いたかっただけぐらいなので、明日以降に個別に言っておいても良いかもしれないと思いました。

Disqus Comments

Kazuhiro NISHIYAMA

Ruby のコミッターとかやってます。 フルスタックエンジニア(って何?)かもしれません。 About znzに主なアカウントをまとめました。

znz znz


Published