RubyKaigi2018に行ってきたメモ

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

[追記 2018-06-02]

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

[追記 2018-06-02]

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

# 1日目

## Improve Ruby coding style rules and Lint

http://rubykaigi.org/2018/presentations/koic.html#jun01

### スライド

https://speakerdeck.com/koic/improve-ruby-coding-styles-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](https://github.com/soutaro/steep) の 0.3.0 が昨日リリース :tada: 

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


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

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


## RNode with code positions
http://rubykaigi.org/2018/presentations/spikeolaf.html#jun01

最近の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
```

https://github.com/ko1/rubyhackchallenge/issues/16#issuecomment-326214530

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


## Type Profiler: An analysis to guess type signatures

http://rubykaigi.org/2018/presentations/mametter.html#jun01

### コミッターとしての活動
Endless range というものができた
`1..` とかける
配列のある時点から最後までという書き方をするときに便利

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


## How Ruby Survives in the Cloud Native World

### スライド

https://speakerdeck.com/udzura/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

### スライド

https://www.slideshare.net/ichitonagata/how-happy-they-became-with-h2omruby-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


### スライド
https://speakerdeck.com/matsumoto_r/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の処理 を再開させる