RubyKaigi2018に行ってきたメモ

最初に

まだスライド公開されていないものもあるので、順次足していきます。
深く理解していない部分もあるので間違っていたらご指摘いただけると助かります。　

[追記 2018-06-02]

直接聞けていない発表も、スライドがあがったら追加します

[追記 2018-06-02]

日別に記事を書くのをやめて、この記事に集約します

1日目

Improve Ruby coding style rules and Lint

スライド

冒頭

do-endは文で{}は式

Rubocopでこういう動きがあるとうれしい

自分たちが起きたことは他のプロジェクトでも起こりうる
→Cop化してOSSに還元するとみんな幸せ

OSSに還元した例

Rubocopに追記して他のプロジェクトでつらくならないようにしたい
トップレベルで include されてつらいということがあった
→トップレベルでinclude されないようにルールを加える
→defの中でincludeするケースがあってつらい
rake new_cop: RuboCop で新しい cop を生成できる

% bundle exec rake new_cop\[Lint/UriEscapeUnescape\]
Files created:
  - lib/rubocop/cop/lint/uri_escape_unescape.rb
  - spec/rubocop/cop/lint/uri_escape_unescape_spec.rb

Do 3 steps:
  1. Add an entry to the "New features" section in CHANGELOG.md,
     e.g. "Add new `UriEscapeUnescape` cop. ([@your_id][])"
  2. Add an entry into config/enabled.yml or config/disabled.yml
  3. Implement your new cop 
引用： http://koic.hatenablog.com/entry/2017/09/11/000000

• include をトップレベルで使うとよくないので、警告を出すようにした
  • method の中で使うと false positive になってしまってつらい→再帰で解決
• Rubocop と　Rails, どちらに機能をもたせるか迷うことがあった
• 多様性がある時代になった
  • Rubocopに自分が正しいものを乗せることで、間接的にコードレビューしていこう
• Rubocop は書き方のルールなどは対話をもとに作っていきたい

所感

「自分がいないところでも自分がレビューする」という考え方は非常に良い
さいきょうのRubocop を作って、コードを良い状態にしていきたいという気持ちが伝わった

Scaling Teams using Tests for Productivity and Education

背景

*　開発者がミスを犯すとプロダクトが壊れた
*　プロダクトを壊さないように気をつけることを増やしたら認知の過負荷が生まれた
→自動的にチェックするように進めた

対応策

• 問題を識別
• 定義を自動化

やったこと

• ファイル名が変更されたときに対応するテストファイルの名前が変更されていない、というミスに気づくために、対応するテストファイルが存在することを検証している
• 特定のgemやパターンを禁止している
• アプリのコードだけではなくてプロジェクトの構造をテストしている

JIT education

• ユーザーが認知すべき時を検出
• 彼らに伝える
  1. 問題はなにか
  2. なぜこれが問題なのか、その意味はなにか
  3. どうすれば直るか
• みんな幸せ

考え方

• 必要になる前ではなく、必要なときに教育するべき

• native extensions のエラーを冗長に出してくれる(RMagickとか)
  https://github.com/jules2689/extended_bundler-errors#extendedbundlererrors

Ruby Programming with Type Checking

steep の 0.3.0 が昨日リリース

Steepにおける型チェックのステップ

1. シグネチャを書く
2. アノテーションつきでRubyプログラムを書く
3. 型チェックを実行(steep check)
   →1へ

Steepにおけるscaffold

steep scaffold というコマンドでシグネチャを生成できる
https://github.com/soutaro/steep#scaffolding
実際にどんなものが入るかまでの推測できないケースが多いため、ほとんどanyになってしまう

所感

別ファイルで型情報を定義できるので、すでに稼働しているアプリケーションにも入れやすそう

RNode with code positions

最近のRubyは行番号だけでなくカラム番号も保持していている

dump オプションすごい

% ruby --dump=y -e '1+2' | grep Shif
Shifting token tINTEGER ()
Shifting token '+' ()
Shifting token tINTEGER ()
Shifting token '\n' ()
Shifting token "end-of-input" ()

以下のように打つとhelpが見れる

% ruby --dump=help

codeの位置情報を解析することで、 NoMethodErrorなどでpower assertのような表示ができそう。

Type Profiler: An analysis to guess type signatures

コミッターとしての活動

Endless range というものができた
1.. とかける
配列のある時点から最後までという書き方をするときに便利

Type Profilerの話

TypeDBという構想がある
その手段として TypeProfiler が必要
動的な型推定はかなり遅くてつらい

How Ruby Survives in the Cloud Native World

スライド

2日目

Build your own tools

自作ツールを作ろう

発表者はウェブアプリケーションが嫌い
SaaSS(Service as a Software Substitute)
作りたいものと自分がユーザーとして使いたいものが一致しないと続かない

自作ツールを作るにあたって

モチベーション、 時間、 技術
自信を持とう
テーマを見つける
簡単なものから作ろう
コーナーケースを排除する
必要なら車輪の再発明
テストは後にして、毎日使おう

ソフトウェアのおすそわけは他の人に配っても減らない
みなさんも自分のツールを作りましょう

How happy they became with H2O/mruby, and the future of HTTP

スライド

H2O+mruby > Nginx

printf debug できる
以下のように担当を分けることができる
Nginx:ベーシックな設定
mruby:複雑な処理

H2Oでできること

channel, task を使うと非同期処理が簡単にかけるようになっている
server-timing: ON
→connect time, response time などが response header に入る

Early Hints 103
Early Data　header

100番台はヒントである
本当の回答は 200番台

Design pattern for embedding mruby into middleware

スライド

マルチスレッド戦略
→スレッド単位でmrb_stateを起こすのがよい

mrubyを組み込むときに重視するポイント

• メモリ管理
• パフォーマンス
• 使いやすさ

shared mrb_state and bytecode

初期化の段階でbytecodeを用意しておく
bytecodeのコンパイルは一切しない

メリット

パフォーマンス良い
初期化段階で、objectをスクリプト同士で共有できる

デメリット

リクエストごとにスクリプトを変えられない
メモリ管理が少し複雑

non-blocking middleware with mruby

問題

mruby は 一般的に同期処理なのでブロッキングしてしまう
処理時間のかかる処理をmrubyにやらせてしまうとresponse時間が遅れてつらい

解決策

non-block mode で実行されたら、 ブロッキングメソッドが完了するまで mruby を一時停止する
mrubyから middlewareのイベントループに返す
イベントループのコールバック関数によって mrubyの処理 を再開させる