Edited at

RubyKaigi2018に行ってきたメモ

More than 1 year has passed since last update.


最初に

まだスライド公開されていないものもあるので、順次足していきます。

深く理解していない部分もあるので間違っていたらご指摘いただけると助かります。 

[追記 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. どうすれば直るか



  • みんな幸せ



考え方


Ruby Programming with Type Checking

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の処理 を再開させる