Rails 5.1.0-betaのリリースノートを読んでみた

読んだページ

• Rails 5.1.0.beta1: Loving JavaScript, System Tests, Encrypted Secrets, and more

目的

• 参加予定のRuby勉強会がRails5.1.0についてだったので予習がてら公式の資料を読んでみた

読んだ人（俺）

• Railsの勉強を初めたばかり。
• リリースノート読んでもそもそも「今どうなっているか」あまりわかっていない。

先に言っておきますが

• 正直何言ってるのかさっぱりです・・・
• 関連する機能を使いだしてから、「あ〜このことね」って言う感じになりそう。

タイトル

Rails 5.1.0.beta1: Loving JavaScript, System Tests, Encrypted Secrets, and more

• Javascript、システムテスト、暗号化とかに特化したリリースっぽいな。

前書き的なもの

Rails 5.0 was released just some eight months ago, and now, some 3500 commits later, we’re already close to the next big release.

• Rails5.0は8ヶ月前にリリースされたけど、もう3500コミットくらいある大きなリリース控えてるよっと。
• 8ヶ月で3500ってことは15commit/1日くらいか。
• そもそもどれくらい平均でcommitされてんだ？

And what release this version 5.1 is lining up to be! 
We’ve made great strides on long-term promises and key ergonomics while also spring cleaning a bunch of deprecated code.

• 長い間約束していたこととか、人間工学的にもかなり進捗出たって。
• また、春には廃止予定コード掃除しますよと。

Let me walk you through the highlight reel:

• ハイライトを下記にあげるから見ていけよな！

Loving JavaScript

We’ve had a stormy, perhaps even contentious, relationship with JavaScript over the years. 
But that time is past. 

• 長年Javascriptとあまり良い関係じゃなかったぽいな。
• でもそれは過去のことのようです。

JavaScript has improved immensely over the past few years, particularly with the advent of ES6, and with package and compilation tools like Yarn and Webpack. 
Rails is embracing both of these solutions with open arms and letting whatever past water flow under the bridge.

• Javascriptは過去数年間で大幅に進歩したって。
• 特にES6や、YarnやWebpackのようなパッケージやコンパイルのツールのおかげだって。
  • ES6:Ecma InternationalによってJavascriptを標準化したもの
  • Yarn:Javascriptのパッケージマネージャ。npmよりも良いっぽい？　
  • Webpack:Javascript用のモジュール管理ツール。Javascript/CSS/画像依存関係を解消したファイルを生成することができるっぽい。
• Railsは過去を忘れてこれらを暖かく受け入れるぜ！的な。

JavaScript and Ruby share a deep philosophical bond over language design, if not ecosystem management. 
Let’s focus on the aspects we have in common and help Rails programmers extract the best from JavaScript with the help of some key guiding conventions.

• JavascriptとRubyは言語設計に対する深い哲学的な繋がりを共有している？どういうこと？哲学の話されてもわからんぞ・・・
• 設計思想が似ているってことか？
• Railsプログラマが、JavascriptとRubyの共通の側面に焦点を当てて、いくつかの主要なガイドラインの助けを借りてJavascriptから最高のものを引き出すのを手伝うと。
• なんかすごい上から目線だな・・・
• Javascript側からはどう思われているんだろ？

The improvements in Rails 5.1 focus on three major parts:

• Rails5.1の改善点は3つの主要な部分に焦点を当てている。
  • NPMからYarn経由でJavascriptの依存関係を管理する。
  • オプションでWebpackを使ってJavascriptをコンパイルする。
  • JQueryをデフォルトの依存関係から外す。
• 詳細はそれぞれ書いてあるな。

Manage JavaScript dependencies from NPM via Yarn. 
Think of Yarn like Bundler for JavaScript (it even has Yehuda Katz involved!). 
This makes it easy to depend on libraries like React or anything else from NPM. 
Everything you depend on via Yarn is then made available to be required in the asset pipeline, just like vendored dependencies would have been. 
Just use the binstub bin/yarn to add dependencies.

• YarnをJavascriptのBundler的なものとして考える。(Yehuda Katzさん？も参加しているって。何に？)
• これによってReactや他のNPMライブラリの依存を簡単にする。
• Yarn経由で依存しているすべてのものは、あたかも依存関係があったかように、アセットパイプラインに必要とされるようになった。
• つまり、 Yarn使ってJavascriptの依存関係の管理を楽にした ってことか！

Optionally compile JavaScript with Webpack. 
While there are a million different module bundlers/compilers for JavaScript, Webpack is quickly emerging as the preeminent choice. 
We’ve made it easy to use Webpack with Rails through the new Webpacker gem that you can configure automatically on new projects with --webpack. 
This is fully compatible with the asset pipeline, which you can continue to use for images, fonts, sounds, whatever. 
You can even have some JavaScript on the asset pipeline and some done via Webpack. 
It’s all managed via Yarn that’s on by default.

• Javascript用の異なるバンドラやコンパイラが100万あるけど、Webpackは優れた選択として急速に出現していると。
• 100万ある中から出てくるってすげーな。
• 100万番目のバンドラ/コンパイラ気になる。
• Webpacker gemってのを使って、簡単にWebpack with Railsをできるようにしたって。
• 使うときは --webpack で新しいプロジェクトを作るみたい。
• アセットパイプラインと完全に互換性があって、画像 / フォント / 音楽とか引き続き使えるって。
• アセットパイプラインってさっきも出てたけど何？
  • アセットパイプライン:Railsの機能で、JavascriptやCSSを結合したり圧縮して、ブラウザのリクエスト回数を削減したりする機能。
• アセットパイプライン上にJavascriptを持ち、Webpack経由で使うことができるって。
• いままでRailsにあったJavascript管理の機能とか、全部デフォルトでYarn経由で管理できるのか。
• つまり、 Yarn使ってJavascriptのコンパイルとかを楽にした ってことか！
• またYarnかよ！Yarn大好きだな！！！ヤーーーーーーーーーーーーーン！！！

Drop jQuery as a default dependency. 
We used to require jQuery in order to provide features like data-remote, data-confirm, and the other parts of Rails UJS. 
This dependency is no longer necessary as we’ve rewritten rails-ujs to use vanilla JavaScript. 
You’re of course still free to use jQuery, but you no longer have to.

• データ確認、データリモート、Rails UJSの他の部分などの機能を提供するためにJQueryが必要だった。
• vanilla Javascriptを使うためにrails-ujsを書き直したので、JQueryへの依存はもう必要ない。
  • vanilla Javascript:JQueryより軽量で高速なフレームワークみたい。
  • (ご指摘頂きました)ここでいう vanilla Javascript はJQueryなどを使わない素のJavascriptとのこと
  • 何もかかってないバニラアイスに例えてるのか。
• JQueryはまだ自由に使うけど、必須ではない。
• JQueryにいろいろ依存してたのね。でもそれももうやめよう〜ってなったのか。

Thanks to Liceth Ovalles for her work on Yarn integration, Dangyi Liu for his work on rails-ujs, and Guillermo Iguaran for chaperoning the whole thing!

• Liceth Ovallesって人のYarnのインテグレーションに感謝！
• Dangyi Liuって人のrails-ujs改修に感謝！
• そして全てのまとめ的なことをしてくれたGuillermo Iguaranに感謝！

System tests

In my 2014 keynote at RailsConf, I spoke at length about how an over focus on unit tests (and TDD) has lead us astray. 
While unit tests are part of a complete testing solution, they’re not the most important one. Integration tests that verify behavior all the way from controllers through models and views should play a much bigger part. 
Rails already has a great answer for these baked in.

• 2014年の基調講演にユニットテストやTDD(Test Driven Development?)に焦点を当てすぎて、私達を迷わせた。
  • これか！！
  • タイトルが TDD is dead なんですが・・・
  • これからTDDでやっていこうとしていたのにすでに3年前に死亡宣言が出ているとは・・・
  • これは別途読む
• astrayって迷いって意味なのか。どこかのガンダムの機体名がアストレイだったような・・・
• ユニットテストは完璧なテストソリューションの一部だが、重要なものではない。
• ユニットテストより、コントローラやモデルを横断したインテグレーションテストの方が大事。
• Railsはすでにこれらの基礎が出来ている。
  • そういやRailsチュートリアル5.0でintegration testってのを書いたな・・・
• 2014年の基調講演での TDD is dead をザラッと読んだ感じだと、ユニットテストが蔓延した結果、ユニットテストが有効なものであることよりも、検証が実施しているかどうかが重要になってきたしまっているという。
• テストすることが大事、というわけでなく、そのプロダクトにとって必要な有効なものをやれ、っていう意味かな。

But integration tests do not help you test the entire system, if that system relies on JavaScript. 
And most major web systems today rely at least to some extent on JavaScript. 
That’s where system tests driven by a real browser come in.

• インテグレーションテストはJavascript依存の箇所があると役に立たない。
  • たしかにJavascriptを使っている箇所のテストをどう書いてよいかわからん。
  • Capybaraとか使うとか？（よく知らないけど）
• だいたいのWebシステムはJavasriptに依存しているから、ブラウザを使ったシステムテストの運用が始まっている。
  • 古来、人が手でやっていたテストのようなことですかね・・・・？

There’s long been an answer for system tests like this in Ruby called Capybara. 
It’s just been kind of a journey to configure properly for Rails. 
So now we’ve baked them straight into the framework! 
You get a lovely wrapping of Capybara that’s preconfigured for Chrome and enhanced to provide failure screenshots as part of Action Dispatch. 
You also don’t have to worry about extra database cleanup strategies anymore because the baked in transactional tests now rollback system test changes.

• Rubyのシステムテストでのこれらの回答はCapybaraと呼ばれています。
  • ここにCapybara書いてあった。
• CapybaraをRails用に設定するのはちょっとした旅だった。
  • Capybara使っているプロダクトを見たけど、至難の業なのか？
  • ↑もっとよく見てみよっと。
• なので、フレームワークに直に焼き付けた！
  • Railsがデフォルトでやってくれる？！
• Chrome用に事前に設定されたCapybaraのもらえるって。
  • lovely wrappingとは・・・
  • それは失敗したAction Dispatchの一部のスクリーンショットを提供してくれるって。
  • エラー出たらSS撮ってくれるのか？！
• また、トランザクションテストやロールバックテストも焼き付けたので、データベースのクリーンアップを心配しなくていいみたい。
  • ここもっと詳しく知りたいな・・・

These tests are not without trade-offs. 
It’s of course still slower to run through a whole browser setup than just test a model with a stubbed out database. 
But it also tests so much more. 
You’d do well to familiarize yourself with system tests and have them as part of your testing answer.

• これらのテストにトレードオフは無い。
  • え、いいことだらけ？！
• もちろん、データベースからスタブアウトしたモデルをテストするときだけでなく、ブラウザ全体の設定を実行するのが更に遅くなる。
• しかしそれは適したテストである。
• システムテストの一部、としてとかテストの答えの一部だと思えばうまくいく、みたいな。
  • TDD is dead. の中で言っていたことかな。
  • 有効なテストやれと。

Thanks to Eileen M. Uchitelle for her work extracting this from Basecamp!

• ベースキャンプで抽出してくれたEileen M. Uchitelleに感謝！
• このインテグレーションテストは、今やっているプロダクトにすごい合うのでもっと深追いしたいな。

Encrypted secrets

If you’re checking production passwords, API keys, and other secrets undisguised into your revision control system, you’re doing it wrong. 
That’s not safe and you should stop it! 
Now that’s an easy prescription, but without a coherent answer to what you should do instead, it’s also not that helpful.

• 本番パスワードやAPIキーや他の秘匿情報をrevision管理システムに載せてないかチェックしろ！
• それは間違っていると指摘すべき。安全じゃない、止めるべき！
  • しねーだろ。しないよね？
• 簡単な対処だが、代案が無いんじゃ役に立たん。
  • 否定するなら代案だせ、っていつも思っていますよ！

People have long been loading up the ENV to store these secrets or used a variety of other solutions. 
There are all sorts of trade-offs and drawbacks to the ENV-model, not least of which that you still need to store those secrets for real somewhere else.

• 人々はこれらの秘匿情報を保持するためにENV読み込んだり、他のソリューションを使ってきました。
  • 使ってます。使ってますとも。
• ENVモデルはいろいろなトレードオフと欠点があるから、他の方法で保存したほうがよいと。
  • どんな欠点だ・・・・？気になる。

Inspired by Ara T. Howard’s sekrets gem, we’ve built encrypted secrets management into Rails 5.1. 
You can setup a new encrypted secrets file with bin/rails secrets:setup. 
That’ll generate a master key you’ll store outside of the repository, but allow you to commit the actual production secrets to your revision control. 
They’re then decrypted in production either through an injected key file or through RAILS_MASTER_KEY in the ENV.

• Ara T. Howardの sekrets gem に触発されて、Rails5.1に暗号化した秘匿情報を組み込んだ。
  • え、まじ？
• bin/rails secrets:setup で暗号化されたファイルを設定できるって！
• リポジトリの外側にマスターキーが生成されるけど、実際の本番の秘匿情報をrevision管理システムにコミットして良いって。
• それらは注入？されたキーファイルまたはENVの RAILS_MASTER_KEY から複合されるって。
  • これいいな！

Thank you to Kasper Timm Hansen for the work on this and Ara for the inspiration!

• Ara T. HowardのインスピレーションとKasper Timm Hansenに感謝！

Parameterized mailers

Action Mailer is modeled on Action Controller. 
It shares underpinnings through Abstract Controller, but it’s long been disadvantaged from its controller cousin in the way it can share logic between actions.

• Action MailerはAction Controllerをモデルにしている。
  • Action MailerはRailsでメールの送受信ができるもの。
• Abstract Controllerを通して基礎を共有しているが、アクション間でロジックを共有することにアドバンテージがない。
  • Superクラスが同じってことか？
  • 似てるけど従兄弟くらいの関係の意味がない？

In Action Controller, it’s common to use before_action and similar callbacks to extract logic that applies to multiple actions. 
This is doable because the params hash is available before the action is invoked. 
But in Action Mailer, we’ve been using regular method signatures with explicit arguments, so those arguments haven’t been available to filters that run before the actions.

• Action Controllerでは、before_actionやコールバックを使用して、複数のアクションに適応するロジックを抽出することが一般的。
• アクションが呼び出される前にparamsハッシュが有効になるから。
• しかしAction Mailerでは、明示的な引数を持つ通常のメソッドシグネチャを使っている。
  • 何言ってんだ？
  • Action Mailer使ってないのでピンとこないな・・・
• なのでこれらの引数はアクションが実行される前にフィルタすることができない。
  • Action Mailerではbefore-actionとかでparamsいじれないってことか。

With Parameterized Mailers, we now give you the option of calling mailers with parameters that, like in controllers, are available before the action is invoked. 
This combines with the default to/from/reply_to headers to dramatically DRY-up some mailer actions.

• パラメータ化されたメーラーで、コントローラーのように、アクションが呼び出される前に利用可能なパラメータを持ったメーラーを呼び出すオプションが付いた！
  • お、パラメータ周りでAction Controllerっぽくなったってことか。
• これはデフォルトの to / from / reply_to ヘッダとともにメーラーアクションのDRYを劇的に向上してくれるって。
  • テストとかしやすくなったのかな。

It’s completely backwards compatible and you can convert just the mailers that stand to gain the most from extraction first.

• 完全に下位互換性があって、最初に抽出する一番大きなメリットを持つメーラーに変換できる。
  • 互換性があるから、気兼ねなくパワーアッポしろってことか。

Direct & resolved routes

We have a lovely, simple API for declaring new resource routes. 
But if you’d like to add new programmatic routes that has logic determining the final destination based on the parameters, well, you’d have to row your own boat with helpers and other messy approaches.

• 新しいリソースrouteを定義するための素敵でシンプルなAPIがある。
• しかし、パラメータに基づいた最終的な目的地を決定するためのロジックを持つプログラムチックな新しいルートを追加したくても、ヘルパーや他の面倒なアプローチをする必要がある。
  • ルーティングの話？
  • パラメータで変わるルートは面倒？

With directed routes, you can now declare programmatic routes that have the full power of Ruby to do different things depending on the parameters passed.

• ダイレクトルートを使うと、渡されたパラメータに応じて、Rubyのパワーを最大限に引き継いだプログラムルートを宣言できる。
  • 上記で言ってた複雑なアプローチがなくなるってことか？

With resolved routes, you can reprogram the polymorphic look-up for models based straight to compatible methods. 
So this allow you to turn link_to @comment into a final route like message_path(@comment.parent, anchor: "comment_#{@comment.id}").

• 解決済みルートを使うと、互換性があるメソッドに直接基づいたモデルへのポリモーフィックなlook-upを再プログラムすることができる。
• これらは link_to @comment を経由して最終的な message_path(@comment.parent, anchor: "comment_#{@comment.id}") のようなルートをたどることになる。
  • ルーティングがやりやすくなったのか・・・・
  • 今がよくわかっていないから何が問題なのかもわからんが・・・

Thank you to Andrew White for making all this work!

• このすべての作業をしてくれたAndrew Whiteに感謝！

Unify form_tag/form_for with form_with

We’ve long had two parallel structures for creating forms. 
Those that were based off records through form_for, where we used convention over configuration to extract the details, and manually configured ones using form_tag. 
Now we’ve unified these two hierarchies with form_with. 
A single root tree that you can configure through an inferred record or manually. It’s much nicer and simpler.

• formを作るための2つの並列構造がある。
• 詳細を抽出するための設定に関する規則を使ったform_forを通したレコードを基にしたもの。
• form_tagを使用して手動で設定したもの。
  • 表現が抽象的すぎてわからん・・・form_forとform_tagを調べんと。
• form_for/form_tag:両方フォームの開始・終了タグを生成するもの汎用的なフォーム
  • form_for:汎用的なフォーム
  • form_tag:特定のモデルに特化したフォーム
• これらを回りくどく言っただけか。
• そしてこの2つが form_with に統合されたと。
• 推定されるレコードと手動での設定が一つのシンプルなツリー構成になると。
• それはとても良くてシンプル
  • 今までは、汎用的なフォームを作るときは form_for つかって、モデルに依存しているところは form_tag 使ってたけど、これらを form_with で使えて、モデルとかも推測してくれるってことか。

Thanks to Kasper Timm Hansen for this one too!

• これもKasper Timm Hansenに感謝！

Everything else

In addition to the highlight reel, we have hundreds of other fixes and improvements across all the frameworks. 
Please peruse the CHANGELOGs to acquaint yourself with all the goodies:

• ハイライトリールに加えて、すべてのフレームワークを横断して何百もの修正と改良を行っている。
• すべてを知りたければCHANGELOGを熟読してくださいと。そりゃそうだな。

* Action Cable CHANGELOG
* Action Mailer CHANGELOG
* Action Pack CHANGELOG
* Action View CHANGELOG
* Active Model CHANGELOG
* Active Record CHANGELOG
* Active Support CHANGELOG
* Active Job CHANGELOG
* Railties CHANGELOG

• これを見るのはまた次の機会で・・・

Your release manager for Rails 5.1 is Rafael França. 
He’ll be chaperoning us through the betas, release candidates, and onto the final release in advance of RailsConf 2017.

• Rails 5.1のリリースマネージャはRafael Françaって人。
• RailsConf2017より前に、ベータ版、リリース候補版、ファイナルリリースへの付き添いをするでしょう。

As per our maintenance policy, the release of Rails 5.1 will mean that bug fixes will only apply to 5.1.x, regular security issues to 5.1.x and 5.0.x, and severe security issues to 5.1.x, 5.0.x, and 4.2.x. 
This means 4.x and below will essentially be unsupported!

• メンテナンス方針に従って、Rails5.1のリリースは5.1.xにのみバグ修正が適用されて、5.1.xと5.0.xへの通常のセキュリティ問題、5.1.xと5.0.xと4.2.x重大なセキュリティ問題が適用される。
• これは4.x移行は本質的にサポートされない。
  • はやく5.0にはしとかんと、セキュリティ面でやばくなりそうね・・・

Please help us test this beta version of Rails. 
It’s always frustrating when we put a lot of work into a new release, betas, release candidates, and then get people report all sorts of issues on week one of the final release. 

• このRailsのベータ版へのテストを手伝って下さい。
• ニューリリースや、ベータ版、リリース候補版を出して、ファイナルリリースを出した直後の一週間でたくさんの問題が発生したら腹立つでしょう。
  • そりゃそうだ。

Basecamp 3 is already running this beta in production. 
This is an incremental upgrade to Rails 5.0. 
Please do your community duty and help us land a solid 5.1 without needing an immediate 5.1.1. Thank you! Gracias! Merci! TAK!

• Basecamp3ではすでにbeta版が稼働している。
• これはRails5.0への段階的なアップグレード。
• すぐに5.1.1を出すのでなく堅実な5.1を作るのを手伝って下さい。
• あなたのご協力に感謝します。

感想

• RailsとJavascript仲悪かったってのがウケる。
• Javascript関連はイメージ湧きづらかったけど、 System tests と Encrypted secrets は今まさに業務でやっている箇所なのでとても興味深い。
  • もっと掘り下げてみよう！
• Parameterized mailers と Direct & resolved routes は何となく意味はわかったけど、実際にやってみないとわからない。
• すくなくとも5.0.xにはしないと、セキュリティ面でやばいことになりそうというのがわかった。
• まあまずは現在の業務に使えそうな System tests と Encrypted secrets をやんぞ！