RubyKaigi2018の6/1 (2日目)の速報 (6/1 - 2つ目)です！
会場内で突然始まったペアプロの様子！
他の「RubyKaigi2018 速報！！」まとめ
RubyKaigi2018 速報 (5/31 1日目)！！ - メドピア開発者ブログ
RubyKaigi2018 速報 ！！ ( 6/1 - 1つ目 ) - メドピア開発者ブログ
RubyKaigi2018 速報 ！！ ( 6/2 最終日) - メドピア開発者ブログ
Journey of a complex gem upgrade
http://rubykaigi.org/2018/presentations/Edouard-chin.html#jun01
概要
- Shopifyの人。Shopifyは１つの大きなRailsアプリケーションで、今までフルリライトはされたことがない
- Gemのアップグレード時のベストプラクティスとはなにかを探っていく
やり方について
- 通常のフローはCHANGELOGを見る、Bundle updateする、CI叩いて問題なかったらDeploy
- だが、「Bleeding」をやめよう(Lessons learnt : Stop the bleeding first)
具体的には下記のような順で行っていく
- 環境をデュアルブート可能にする（新バージョンGemを使う環境と旧バージョンGemでENV分け、Gemfile内でENV分岐でGemバージョン書き換えするなど）
- Gemfileを分ける
- アプリケーションを走らせて問題を修正する
- CIを通す
問題の修正のやっていき方
- バージョン切り分けで問題となるソースをコンポーネント化 (Rails.rootにcomponentsフォルダを作る)
- どのコンポーネントがどこに依存しているかを切り分ける
- ActiveSupport.Deprecation.warn('This code is deprecated')でDeprecationを出す
まとめ
- bleedingをしないようにしよう
- ツールを活用しましょう
- Deprecationの修正に追従していきましょう
- スライドは下記のツイッターアカウントにあとでアップしていただけるとのことでした！ https://twitter.com/daroudedudek
Type Profiler: An analysis to guess type signatures
http://rubykaigi.org/2018/presentations/mametter.html#jun01
ruby 2.6の新機能
- Endless range：
(1..) - Beginless range
(..1)も出るかも？？
RDL: https://github.com/plum-umd/rdl
- 実装が公開されている注目プロジェクト
使い方
rdlをrequire- 型修飾を書く
typecheck: :callとすると、メソッド呼び出された際に型チェックが実行される。他にも:nowを渡して、定義時にチェックすることも出来る。
特徴
- 半静的な型チェックツール
- メタプログラミングをサポートしている。
- Implementationが、とても良い
- 型情報をたくさん書かないといけない。。
他との比較
Ruby3の型システムの話
型システムのアイデアと課題
- Static Analysis 1：定義されているメソッドから型を推定する。
- 静的にチェック出来るけど、引数や返り値の解析は難しい。。。
- Static Analysis 2：
n + 3だとNumelic等、式に使われている値から型を推定する。- 静的にチェック出来るけど、
StringとArrayの<<等の解析が難しい。。。
- 静的にチェック出来るけど、
- Dynamic Analysis3：TracePointを使って動的に型を推定する。
- 実装は分かりやすい、テスト実行が必要かつPerformanceに難あり。。。
Scaling Teams using Tests for Productivity and Education ( 6/1 13:50 )
Julian Nadeau @jules2689
チーム開発で起こる失敗と問題解決方法について
失敗
- 失敗を避けるためにチーム内で「これをすべき、これをすべき」のマナーを作ってもにしてもすぐに古くなる、覚えられない、どうやって自動化しよう？
問題の解決方法
- 問題を明文化するIdentify the problem
- 修正が自動化できるかを判断するdetermine if a fix can be automated
- テストを実施するimplement a test to detect and educate
問題の明文化
例：メンテナンスタスクでのファイル名 メンテナンスタスクで読み込むべきファイルの名前が間違っていたとしたら、ただ「間違っています」というエラーメッセージ出すのでは不親切 同ディレクトリ内を読み込んで、開発者にファイル名がどう間違っているかを知らせる
前のエラーメッセージが：「あなたの読み込んだファイルが間違っています」だったとしたら… 「test.rbというファイルを期待しましたが、test_test.rbファイルが読み込まれましたよ。test.rbというファイルを読み込んで下さい」と教える
間違っている可能性のあることすべて伝える(suggest any possible)
修正が自動化できるかを判断する
ユニットテストを書くこと
- ユニットテストの実行時のメッセージをできるだけ書く
- MiniTestだとしたら、asssert時のオプションmessageに上記のような細かいメッセージを書く
- 問題が常に覚えておくべきことかどうかにかかわらず、検知と教育のためにテストを書こう
rubocopを導入すること
- rubocopは便利、初心者でもとっつきやすい
- shopifyでもruby-stydy-guideのリポジトリを作っている
just in time な教育をすること
- JIT educationのJITとは、Just In Timeのことで、JITコンパイラのJITとコンテキストは近い
- 開発者が問題を認識したのを検知して、 そのタイミングで問題をと知識を共有、修正に向けて動く
Other solution
bundlerのエラー時のメッセージがわかりにくかったので、実際に上記のように修正のGemを作った https://github.com/jules2689/extended_bundler-errors たとえばbundle installに失敗したときに 「could not create Makefile due to some reason」と言われることがあるが extended_bundler-errorsを使うと 「何が問題か？どのバージョンならOKか？何をすべきか？」 を提示してくれる
感想
- 現場感のあるとてもいい発表でした。テストを書くことには動作の保証やヒューマンテストのコストを減らすだけではなく、教育の意味もあるのだなと思いました
- 問題になりやすいテストに、なぜそれが落ちるのかをメッセージで表示していくのは取り入れてみたいです
Ruby Programming with Type Checking ( 6/1 14:40〜)
概要
発表者が作った型チェックライブラリ「Steep」(前回のRuby会議で発表した)は、実験的すぎたためプロダクションでは全く使用されなかった。 https://github.com/soutaro/steep
より実践的なものにするべくここ9ヶ月に渡る改良と、この型チェックライブラリがどれだけRubyプログラミングを助けるかを発表する。
Steepの機能
type annottaiion type definition local type inference structural subtyping
昨日v0.3.0リリース
いろんな機能追加。 typing polymorphic methodなど
Sorbetとの比較
写真撮ったのであとであげる
Demo
基本的な使い方の説明から、ここ9ヶ月で実装した機能などを紹介。
ここ9ヶ月で実装した機能
インスタンス変数をattr_reader, attr_accessorで扱う場合があるが、signature対応していなかったため対応 case分の型チェック 型チェックのstrict modeを追加 ...and so on
型づけのステップ
write signatures write ruby program with annotation rub type checker
型付けの困難
ライブラリの型がない 型付けの表現が難しい メタプロへの対処
感想
RubyKaigi全体を通して型付けのセッションが多い。みんなRubyに静的型付欲しいの? このセッションでは、1日目のセッションで紹介されていた「Sorbet」との比較もあり(Sorbetの開発者もこのセッションを聞いていた)、お互い意識しているのだろうか?
(☝︎ ՞ਊ ՞)☝︎是非読者になってください
メドピアでは一緒に働く仲間を募集しています。 ご応募をお待ちしております！
■募集ポジションはこちら
https://medpeer.co.jp/recruit/entry/
■開発環境はこちら
