カレーの恩返し

おいしいのでオススメ。

RubyKaigi 2018に行ってきた【Day1】

まだ途中ですが、公開してから考えようと思います。

Keynote

f:id:euglena1215:20180605102252j:plain

ことわざの話

「名は体を表す」= 名前重要

ソフトウェアの世界には物理的制約がなく、概念で構成されているため名前はとても重要。
なのでソフトウェアエンジニアは概念に名前をつける必要がある。

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 前の記事を参照

euglena1215.hatenablog.jp

github.com

github.com

github.com

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倍早い

GPUGCと相性がよくないかも? mkmfの機能が足りない 第三のコンパイラの指定ができない broadcast operationが遅かった

すごそう +=のoverrideができない

A parser based syntax highlighter

speakerdeck.com

TODO: あとでまとめる

既存のhighlighterは正規表現で実装されている atomはcsonという形式で書かれてる

それの問題点は?

  • コードを読むのが辛い
    • 正規表現は難しい
      • 問題にぶつかったとき多くの人は正規表現で解決しようとするけど、問題が2つにふえる
  • highlightが完璧じゃない
    • トリッキーなコードを書いているとsyntax highlighterを倒すことができて
  • Iro
    • ripper based syntax highlighter
    • iro vs iro vim
      • iro vimがiroにデータを渡してiroで処理する
    • advantage iro
      • easy to read
        • parseはripperに任せている
      • ローカル変数をhighlightできる
      • parseがeditor依存じゃなくなる
    • implementation
      • Ripper.lex
        • tokenizeしていい感じに返す
          • 行番号と列番号
          • keyword, space, identify
          • その文字
          • lex state
      • Ripper.sexp
      • event driven

        - performanceのため