51–60 of 78 posts
Earlier quoted context omitted.
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.
Looks like you opened up an issue, which is a good first step: https://github.com/rails/rails/issues/28135 Not sure how much of the Rails team browses HN comments, but an issue will certainly get their attention.
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 secr…
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.
I'm happy they've provided a solution to Encrypted Secrets instead of simply saying "You should not commit secrets".
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.
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…
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…
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…
Webpack has built in support for this as it generates chunk hashes and can output filenames with them in it, then you just get that data and do the same as above.
How you put that in your Rails app is up to you - could be a simple helper like javascript_tag, that would be easy to do.
Rails really didn't have any magic to the asset pipeline in that regard.
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…
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 secr…
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…
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.
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…
Here's a blog post [1] explaining how to use webpack with rails.
[0] https://github.com/kossnocorp/assets-webpack-plugin
[1] http://clarkdave.net/2015/01/how-to-use-webpack-with-rails/#...