RubyKaigi 2018に行ってきた【Day1】
まだ途中ですが、公開してから考えようと思います。
Keynote
ことわざの話
「名は体を表す」= 名前重要
ソフトウェアの世界には物理的制約がなく、概念で構成されているため名前はとても重要。
なのでソフトウェアエンジニアは概念に名前をつける必要がある。
1. 振る舞いに名前をつける
クラス、メソッド、変数に名前をつけるのがこれに該当
よく「メソッドの命名が難しい」と言うが、名前をつけるのが難しいのではなく十分に概念を理解できていないだけ
使う場面、機能を十分に理解していれば難しくない
なのでいい名前がついている機能は自然と良い機能・実装となる
Rubyにはyield_self
というメソッドがある
class Object def yield_self(*args) yield(self, *args) end end
何がしたいかという情報が入っていない
なので昨日コミットして新しいaliasを作った(matzがCRubyに機能面でコミットしたのは5年ぶりらしい!)
object.c: Add a new alias then
to Kernel#yield_self
· GitHub
thenという表現はmatzが推しているだけで他のRubyコミッターはみんな反対しているとのこと
2. プロジェクトに名前をつける
良い名前は求心力になる
例えばRuby
Rubyという名前をつけなかったら仙台に1000人以上集まってくれるような言語になってなかったんじゃないか
Rubyは良い名前付けだったなぁと思うが名前を付けたのは1993年の話
今つけるとしたらもっと違う名前をつけるかもしれない
今はググラビリティ(=Google検索時の単語のユニークさ)を意識した方がいい
悪い例としてGoやSwiftが挙げられる(www)
現代のプロジェクトの名前付けのトレンドとしては
- 単語を組み合わせる(Ruby on Rails, tensorflowなど)
- 既存の単語から1文字変えてみる
- 変な単語を選ぶ(kaminari, hanami, kibaなど) ← 何をやっているのか分からないという弊害もある
名前はとても重要なので、良いプログラマーは名前つけにsensitiveであるべき
「時は金なり」= Time is Value
時間をどのように使うかが自分の人生を決定づける
プログラミングにおける時間は2つあると思っている
開発時間 ≒ エンジニアがPCに向かってる時間
Rubyは生産性が高い
- 便利なメソッドがたくさんあるのでやりたいことはだいたい探せばある
- 色んなフレームワークがある
- Rubyを使っている人がたくさんいる
- 個人の言語の選択基準は「近くに詳しい人がいる言語」を選ぶべき
- (見かけ上)シンプルな構文
実行時間 ≒ コンピュータが処理する時間
パフォーマンスの話
Ruby 1.8以前は確かに遅かった
Ruby 2.6からはJIT compilerが入ったりとかなり改善されてきた
今まで言われ続けてきたconcurrency(=並列実行)もどんどん現実のものとなってきている
Ruby 3.0ではRuby 2.0の3倍速くなる
実行時間が短くなればサーバーのリソースを減らすことができて、その分が全て利益になる
「塞翁が馬」
人生の幸、不幸は予測できない=なにが起こるか分からない
1995-2004 Rubyを知らない人が多かった
2005-2012 普及し始め「Ruby is Great!」と言われるように
2013-2018 一時期の興奮が冷め安定期に入った
Rubyは死んだのか?という記事を目にするようになった
Rubyは毎年死んで毎年生まれ変わっている
Ruby is Dead Every Year
互換性は大事だが変化は止めてはいけない
RubyKaigiが「Rubyがもっとこうなったらいいなぁ」と考える機会になればいいなあと締めた。
Analyzing and Reducing Ruby Memory Usage
TODO: スライドを見つけたらまとめる
草生えるの人
feature cache Direct Isen - メモリをどのくらい使われているか調べる方法 - Reading code - Mall stack tracing - rubyは2つのヒープに分けられる - object space - allocation tracer - malloc stack logging :love: - プログラムがどのくらいメモリを使っているか - どこがメモリを食っているか - 誰がmallocしたのかが分からない - メモリ使用量を減少するパッチについて - feature cacheの最適化 - shared strings - 存在する文字列の添え字の調整で表現できるならそれで - 同じrequireは1度だけ - どうやって同じファイルとするのか? - 毎回requireされたかどうかチェックすると遅い - setupに時間がかかるようになる - key generation - ruby objectを消す - cacheを参照するときに生成していたruby objectを作成しないでよくする - rails アプリケーションのメモリ使用量4.2%減らせる - パッチを書く前にすでにないか調べてみよう - Stack VM - コード - AST - Linked List - Byte Code - Byte CodeはVMによって実行される - Linked List(T_NODE) -> ByteCode
puts “Hello World”
Hijacking Ruby Syntax in Ruby
www.slideshare.net Rubyの黒魔術を使って
final
override
abstract
with
defer
といった他の言語にある機能を作ってみたよ、という発表。
使った黒魔術たち
Binding#local_variable_set
はbindingした箇所でlocal変数を宣言できる
存在しない変数を定義したときはbindingのblockのスコープを抜けるとその変数定義は消える
存在する変数に対して定義したときはoriginalの変数定義を上書きする ← 🤔🤔🤔
↓
ということは好きなところで変数の中身をいじれる!
TracePoint
ほぼ全てのイベントをhookに処理を走らせることができる
- 行を移動したとき
- raiseが発生したとき
- classを定義したとき
- returnしたとき…
- bindingしたとき
これらの情報を合わせると コードの任意の箇所の変数を上書きできる!
refinements 前の記事を参照
finalist, overrider, abstrikerで使われているMethod Hook
Module#method_added
Module#method_removed
Module#method_undefined
BasicObject#singleton_method_added
BasicObject#singleton_method_removed
BasicObject#singleton_method_undefined
Rubyはmethod定義の方法がたくさんあるため、このくらいMethod Hookをつける必要がある。 同じようなことをしようと思ったときは気をつけてねという話でした
TODO: 途中
All About RuboCop
TODO: スライドを見つけたらまとめる
英語が分からんぞ、、、
Fast Numerical Computing and Deep Learning in Ruby with Cumo
TODO: スライドを見つけたらまとめる
chainerの人 PFN Cumo
CUDA programming GPUはやい コア数の桁が違う 行列演算早い
CUDA GPUのメモリをallocate CPU メモリ -> GPU メモリ GPU側で計算 特徴 非同期になる GPU likes a job queue
Numo -> Cumoの文字列置換で動く element-wise operation 要素ごとの足し算 並列的に処理がしやすい reduction operation 和をとったりするやつ 並列かさせるのむずかしい 行列の積にも対応 cuBLAS
cudamallocが遅くなりやすい memory poolを使おう 一番簡単な実装は配列 best-fit hashのchain法かな? 基本はchain法、ほしいメモリサイズよりも大きいものが余ってたら切り出して利用する
rubyでは文字列評価によって行う
NumoよりCumoの方がめっちゃ早い 75倍早い
GPUはGCと相性がよくないかも? mkmfの機能が足りない 第三のコンパイラの指定ができない broadcast operationが遅かった
すごそう
+=
のoverrideができない
A parser based syntax highlighter
TODO: あとでまとめる
既存のhighlighterは正規表現で実装されている atomはcsonという形式で書かれてる
それの問題点は?