
Rails 5.1.0 Beta 1 - claudiob
http://weblog.rubyonrails.org/2017/2/23/Rails-5-1-beta1/
======
technion
I don't like this "secret storage" system. Unauthenticated CBC mode, and
doesn't actually set an IV (I'm assuming a hardcoded default comes into play).

~~~
stouset
This needs to be higher up. It's using Blowfish (a 64-bit block cipher),
unauthenticated, in CBC mode. These should _not_ be the defaults for a system
designed and built in the past five years.

~~~
deedubaya
What should be the default?

~~~
stouset
AES-128-GCM (or ChaCha20-Poly1305 if you're feeling particularly hipster) with
a new, random IV every time data is encrypted.

------
out_of_protocol
Actually pretty major release. Hopping on javascript's crazy train. It was
expected anyway, there are no way to ignore js-crazyness anymore (most of the
frontend toolset exists only as js implementation).

Also, Phoenix (ideological successor of rails) took this approach from the
start

~~~
donjh
I think the JavaScript updates are great news, enough for me to finally dive
into Rails.

~~~
pastullo
This release is in my opinion a life saver for Rails. Instead of forcing
people to hop off the Rails train, it empowers them and let them choose their
favourite JS library on top of it, while serving them hassle-free, in a very
rails fashion.

Shouldn't this have been shipped in 5.1, it might have very well been a bit
too late.

------
randall
The marquee upvote worthy headline:

ES6 love + webpack + Yarn in the asset pipeline.

If you're still in rails land this seems pretty cool.

------
TheAceOfHearts
This is awesome. Webpack and yarn are incredibly powerful tools. There's a
learning curve with webpack, but once you pick it up, it's easy to make it do
anything you need. If you actually dig into the internals, you quickly realize
that everything is incredibly modular and you can pretty much hook into
everything.

If you're not already using yarn, go check it out right now. Migrating
literally took our team less than 5 minutes, and we haven't had a single
problem so far. Its default behavior is much more sensible than npm.

Writing a SPA that handles every edge-case is really challenging, so it's
actually incredibly refreshing to write a fully server-side rendered app.
Especially after spending a lot of time working on SPAs. It's pretty mind-
bending how easily you can wire up a meaningful prototype, just by sticking to
rails' guidelines. Even though my love for ruby has diminished after having
tried other languages, I'll still happily reach for rails in many situations.

I think for many apps you'd strike the best balanced in complexity by mixing
both server-side rendering and having some pages which are small javascript
applications, instead of going for a full-blown SPA. Depending on what the app
does, somewhere between 5k and 10k SLOC seems to be a sweet spot for an app to
be useful while still being trivially easy to change and keep track of
everything. Once you pass ~20k SLOC, I've found it starts to get harder to
follow everything, and changes start to require a bit more effort. It's worth
noting that those numbers are pretty arbitrary and are probably wrong :).
Again, it depends on the application.

In my job we had a period where everything was handled by a SPA, and it was
pretty painful. If you have a password-gated app, consider doing all the auth
views with server-side rendering, and only load the SPA for logged-in users.
This lets you drastically simplify how you handle things like resource caching
and routing. Leverage the server more, stop trying to handle everything on the
client! That's gotta be one of the most important lessons I've learned.

My really big complaint with rails is that it works so well until it grows
enough, and then it gradually starts to fight you. How do you transition
beyond rails MVC? I've looked at stuff like Trailblazer [0], but I'm uncertain
if that's really the direction a growing rails app should take.

[0] [http://trailblazer.to/](http://trailblazer.to/)

~~~
pierrehenrit
Good points! It always seems easy to start with a SPA for a small app but I
noticed that it can be quite hard to maintain if the app is not super actively
developed. Even if the code is simple you usually have a lot of dependencies,
not always well maintained themselves, and upgrading is hard.

------
verisimilidude
This is pretty great. Since hopping back onto Rails about six months ago, I've
made a habit out of removing the asset pipeline from every new project in
favor of webpack and Yarn. It always feels a little cobbled together, but
worth the trouble to take full advantage of the JS ecosystem. Having these
tools as a native part of Rails will hopefully make my own workflow a bit more
streamlined. Looking forward to it.

~~~
losvedir
How do you handle versioning of the compiled assets and linking to them from
the view? `<%= javascript_tag 'foo' %>` is the main benefit of the asset
pipeline to me, so they can be long-expiring and busted with any change.

I, too, agree that the asset pipeline is clunky. But at my startup we went the
other way: use npm/webpack but compile the resulting file _into_ the assets
directory, so we can still use the asset pipeline. It sort of double processes
the assets but it was the only way I could think of to take advantage of
modern JS with imports and exports, and still get the cache-busting goodness
and easy rails view interoperability.

~~~
TheAceOfHearts
You can use a plugin like assets-webpack-plugin [0] to get a JSON file that
maps to the compiled file names. That's basically the same thing asset
pipeline would do.

Here's a blog post [1] explaining how to use webpack with rails.

[0] [https://github.com/kossnocorp/assets-webpack-
plugin](https://github.com/kossnocorp/assets-webpack-plugin)

[1] [http://clarkdave.net/2015/01/how-to-use-webpack-with-
rails/#...](http://clarkdave.net/2015/01/how-to-use-webpack-with-
rails/#including-precompiled-assets-in-views)

------
oliwarner
These release notes _really_ let Rails down. Crowing on about the number of
commits and rationalising decisions is a waste of my time, just explain how
it's going to make or ruin my day. Links you'd expect to explain features just
take you to source files, not documentation. And a HUGE amount of the changes
are actually scattered around in sub-project changelogs.

They should look at Django for some inspiration. Here's their latest beta
release notes [1]. It's concise, _everything_ links to relevant documentation
with examples, and the entire project's changes are handled on the one page.
There's even a list of things to check if you're upgrading.

[1]:
[https://docs.djangoproject.com/en/dev/releases/1.11/](https://docs.djangoproject.com/en/dev/releases/1.11/)

~~~
matt4077
I think they're excellent – the text is actually interesting to read and it
gives me a much better impression of the relativ importance of changes than a
simple list would.

I also can't find fault with giving some appreciation to the relevant people
who contributed by actually naming them.

~~~
oliwarner
You'd call the Django release notes a simple list?

My main problem isn't the fluff, it's the lack of real documentation for new
features. Or that the link doesn't go to the documentation, it goes to the
merged PR on guthub. And that it's very incomplete (see Everything else).

This is not excellent, in that it could keep the things you like and still be
much better.

------
sergiotapia
At StackShare[0] we're using the webpack-rails gem to use React and ES6
javascript.

[https://github.com/mipearson/webpack-
rails](https://github.com/mipearson/webpack-rails)

It would be awesome if someone could write a migration guide for this switch.
I'm sure a lot of Rails teams are using the webpack-rails gem and are planning
to switch to the official gem.

[0] -
[https://stackshare.io/stackshare/stackshare](https://stackshare.io/stackshare/stackshare)

------
poorman
I'm happy they've provided a solution to Encrypted Secrets instead of simply
saying "You should not commit secrets".

~~~
artursapek
There's a new command, `bin/rails secrets:setup`. I haven't worked with any
recent versions of rails, but it's kind of surprising that they are just now
addressing this. I know I've seen Rails secrets being checked into Github.

~~~
stouset
Even with this, I think it's personally a bad idea. But sometimes security is
improved more by reducing the _impact_ of making poor decisions (e.g, storing
secrets in your repo more safely) than it is by chastising users to make
better decisions (not storing them in your repo at all).

------
swilliams
Is CoffeeScript still the default then? I see it referenced in the codebase
still.

~~~
evolve2k
I'd imagine with ES6 all nicely wired up in this release that moving away from
Coffee would be an obvious next step but was way to large to undertake in one
release.

------
romanovcode
I am the only one who sees this JS integration as bloated overkill?

Nowadays developers prefer to do SPA based approach where you have API (RoR -
JS Stuff) and Front-End (Whatever front-end people decide to choose that will
be outdated in 1 year).

Why can't RoR just focus on the back-end stuff instead of adding bloat that
will be obsolete in 1 year?

~~~
nsommer
Because it's a fullstack framework.

------
wes-k
biggest change for me is the new webpack gem. Hopefully I can replace my
current setup with this so that I can get seamless es6 within my asset
pipeline.

------
LouisSayers
Very interested to see how webpack plays with the asset pipeline.

With Capybara, I'm not keen on the default transactional rollbacks. The reason
for this is, that it's handy to keep the data in the db after a test to see
what the final state of it was. I always drop the data before a test runs -
but then again, I prefer the use of factories over fixtures.

Can someone please explain the benefits of this encrypted secrets business??
I'm struggling to see the benefit - I understand that you need access to the
code + the env var, but in all practicality, if someone has access to your env
vars, then is it really that much more of a reach to figure out what the key
in the code is?

~~~
stouset
In a nutshell, the point is that despite near-constant warnings not to commit
secrets to repositories… people do. So this lets developers commit secrets to
their repo with reduced risk of leaking the secrets themselves.

That said, there are other good reasons not to commit configuration like this
to your repo (configuration and code don't always change in unison; sometimes
you need to use older code with more recent configuration, for example) but
it's at least better than the current situation where careless developers wind
up with thousands of dollars of charges against their AWS accounts after
accidentally committing AWS keys.

~~~
LouisSayers
So, I guess now these same developers will commit two keys into their repos?
:D

------
jrochkind1
I had heard that Capyabara-based tests were going to be incorporated in Rails.
As the multi-threaded concurrent nature of these always makes things a pain,
hard to get right, leading to much pain for devs with non-trivial test suites
-- I was curious to see how they'd handle it, if there'd be an 'official'
Rails solution, ideally backed by some deep Rails knowledge.

I was surprised that they've chosen to use the 'shared database connection
accross two threads' approach. While this was for a while popular approach
amongst people trying to figure out the best way to use Capybara-based tests
with Rails -- mostly because you get to keep transaction-based database
cleanup -- it was largely determined through experience to be too flaky.
ActiveRecord's architecture just wasn't designed for a Connection object
(representing a single actual network connection) to be shared between two
threads, it's not a thread-safe object.

José Valim originally proposed the approach in a gist, and you can see a long
discussion among people having hard-to-debug problems with it here:
[https://gist.github.com/josevalim/470808](https://gist.github.com/josevalim/470808)

There are other such threads in various places from over the years.

Here's one blogger explaining the race condition issue, with the ActiveRecord
architecture not actually being concurrency-safe in this use case:
[http://influitive.github.io/news/2015/09/02/dont-use-
shared-...](http://influitive.github.io/news/2015/09/02/dont-use-shared-
connection.html)

I thought I remembered Valim actually posting somewhere himself "Yeah, turns
out, that wasn't a great idea", but now I can't find it. (It may be that José
deleted most of his tweets when he left twitter?)

So I'm surprised Rails took this approach. I can't tell for sure if the
approach now in Rails just basically takes Valim's approach (violating AR's
concurrency contracts and expectations), or actually takes a new approach that
will truly be concurrency-safe, while somehow still sharing the connection
(another lock somewhere? Are AR connections in general now safe for sharing
between threads? Cause that'd be huge if it was true in the general case).
[https://github.com/rails/rails/pull/28083](https://github.com/rails/rails/pull/28083)
Can anyone else?

Either way, reliable Capybara has been a real challenge to a lot of devs due
to race conditions, it would be shocking if Rails gets it right on the first
try, when many devs haven't managed to figure out a right way to do it in
years of trying! I expect lots and lots of frustrated devs running into race
conditions and filing Issues. It will be interesting to see if this ends up a
maintained feature, or another Rails internal abandonware. If dhh and his team
use it, and run into the race conditions, then it will certainly be addressed;
otherwise, some 'difficult' Rails features seem to sometimes end up basically
abandonware.

~~~
why-el
What kind of race conditions are you talking about? I ran this setup for
years, and just about the only thing that has been stable in the whole setup
is ActiveRecord.

~~~
jrochkind1
You ran the shared connection situation with no problems? Great, but I linked
to examples of people who have had different experiences, you can follow the
links to see. Like all race conditions, sometimes they appear and sometimes
not, and it can depend on your particular app.

They are not surprising, because the concurrency guarantees of AR do not
include sharing a connection object between threads, it is not meant to be
thread-safe.

With postgres, the race conditions on sharing a connection between two
concurrent threads sometimes look like "PG::Error: connection is closed" or
"PG::UnableToSend: another command is already in progress", with mysql
sometimes like "Mysql2::Error: This connection is in use by: #<Thread:...>"

------
desireco42
Looks like fanatastic release! Yarn and Webpack support, inspired from Phoenix
probably. Capubara!... I mean Capybara and DB cleanup. All this looks pretty
great. I need to look into mailer upgrades.

------
Soliah
How is the upgrade to 5.x from 4.x? Kinda dreading rolling out the upgrade and
running into the inevitable gem incompatibility dance.

~~~
elsurudo
Wasn't a huge pain in my opinion. I always use
[http://railsdiff.org](http://railsdiff.org) to start, but yeah I did run into
a couple of unmaintained gems that weren't compatible and I had to patch
myself.

------
deedubaya
Great improvements here which will eliminate boilerplate setup in a lot of
circumstances. Thanks to everyone who has contributed!

------
jincheker
I feel like it should be version 6 instead of 5.1. Many should be considered
as major release

------
mark_sz
In terms of integration with Javascript, RoR seems to be behind for example
(PHP) Laravel.

~~~
elsurudo
After this integration with webpack, will it still be behind?

~~~
yeskia
I wouldn't have thought so.

Laravel 5.4 shipped a month ago with browser integration testing and Webpack
by default, now Rails has the same.

------
config_yml
nice! A welcome addition to my default stack. Thank you rails team for putting
in the work!

