Did you know that you don't need to use the begin/rescue/end pattern within a Ruby method definition body? If you do, you might have tried like me to apply an inline rescue statement with no begin or end inside of a normal Ruby block, say a block passed to Array#each for example.

But... it doesn't work. Although it works fine inside method bodies, this is invalid syntax in Ruby 2.4 and prior, which is kind of infuriating because putting a rescue statement at the same nesting level as the do statement makes rescue operation very neatly visible.

Thanks to Josh Cheek however, this oddity will disappear from Ruby 2.5 which should arrive this coming Christmas.

One caveat is that the new behavior will not apply to blocks created with curly braces instead of do/end keywords. Which honestly makes a lot of sense.

For a few years, it felt like the Rails community was at odds with the movements of the front-end web development community. It's likely the crazy pace of change in the JavaScript community had a lot to do with this, along with some vague CoffeeScript-fueled isolationist tendencies on the Ruby side.

But since the release of Rails 5.1 in late April, a much smoother bridge now exists — beyond Sprockets — between the Rails world and the front-end world.

First, Yarn, which arrived in late 2016 and finally brought the crucial enhancements npm sadly failed to bring for years: lockfile support just like Bundler, and faster dependency resolution and download. Yarn is now a first class citizen in the Rails ecosystem with its own bin/yarn command.

Second, webpack which can replace Sprockets in the often complicated task of bundling multiple different assets together into one application package for the production environment. Rails 5.1 brought along the webpacker gem which brings a much appreciated tighter integration of Webpack into Rails, to avoid having to deal with heaps of configuration.

So while I still default to Sprockets in most of my Rails applications, if I'm ever going to integrate a front-end stack driven by React, Angular, Vue, or Ember then I'm most likely going to reach for Webpack.

Speaking of Rails 5.1, it's hard to overstate how crucial the work of Eileen Uchitelle has been towards the difficult task of bringing real end-to-end tests to the default Rails stack. We've had requests tests, controller tests, and integration tests in the past but the latter notoriously ignored the gigantic elephant in the room that is JavaScript support in those integration tests.

By integrating Capybara natively with a default Selenium Chrome driver, Eileen has not only made it easy to really test your Rails application as a user would in their browser, she's also solved some very problematic issues with the way those integration tests behaved in the past.

In the way I've been testing the codeschool.com Rails app for years, our JavaScript driver would always create independent threads to run the JavaScript examples which would use its own database connection separate from the one used inside the tests.

The usual database transaction which rolls back after a test runs meant that the headless browser's own connection wouldn't see any of the records created before the browser connection started, and vice versa. This forced us to use database truncation around the JavaScript examples and made it impossible to intermingle JavaScript & non-JavaScript tests.

This is something that was solved in Rails 5.1 by Matthew Draper. The system test opens a connection to the database that is then shared with the headless browser so they both see the same temporary database records. This alone is going to simplify user-focused feature testing a lot.

Just as I was finishing this episode, DHH released a new gem called Active Storage. The goal is to finally address the issue of having to store data on a remote server like Amazon S3 which used to require gems like CarrierWave or Paperclip.

On his blog, Mike Gunderloy went over the basic setup and interface which allows you to use the usual file_field form helper after defining sort of a virtual association inside your models. For instance, a User can define has_one_attached :avatar and Active Storage will take care of uploading the data submitted to the form straight to the storage provider.

This won't be available inside of Rails until Rails 5.2 but nothing prevents you from testing it with rails master.