Live data from Hacker News

Rails 5.1.0 Beta 1

weblog.rubyonrails.org

21–30 of 78 posts

Re: Rails 5.1.0 Beta 1

#22
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.

Re: Rails 5.1.0 Beta 1

#23
post #19

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

Wasn't a huge pain in my opinion. I always use 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.

Re: Rails 5.1.0 Beta 1

#25
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.

Re: Rails 5.1.0 Beta 1

#26

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

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

Re: Rails 5.1.0 Beta 1

#27

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.

How do you handle versioning of the compiled assets and linking to them from the view? `` 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.

Re: Rails 5.1.0 Beta 1

#28

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).

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.

Re: Rails 5.1.0 Beta 1

#29

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 'sha…

The Rails app runs in one thread, the test in another one. There are no problems as long as you don't use the database from the tests, which would be against the spirit of integration testing anyway. Only browser actions, even to check if the assertions are valid. A little inconvenient but safe and true to what users will do and see. I never got any problems in that way.

Re: Rails 5.1.0 Beta 1

#30
post #28

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).

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.

What should be the default?
Post reply on HN