For those curious as to how things go from Rails 3 to Rails 4.1, I've now built a few Rails 4 and 4.1 apps for clients and here's been my thoughts:
1) Turbolinks comes standard with Rails 4, and you will either love it or hate it. If you do use it, expect your javascript to break at one point or another. The jquery.turbolinks gem helps, but I've still had to debug a bunch of funky behavior with it.
2) Strong parameters takes a while to get used to from the old attr_accessesible way of doing things. That being said, I think it's worth it to learn it. It prevents a lot of conditional attr_accessible :blah, :as => :admin that goes on. The one thing I'd say is if you are going to use strong parameters, you might want to install a gem like Annotate so you can keep track of your attributes in the models. Sure you can just look in Schema.rb, but tabbing back and forth gets to be kind of a pain.
3) Secrets.yml is great, no more worrying about adding your config.secret_token to the .env file when generating every single project.
4) Mail Preview is nice, but for some reason I still seem to use Mailcatcher mostly to view / see how emails render out. Think this is mostly me sticking to my own ways.
5) ActionController::Live still feels pretty half baked. The fact that most examples / tutorials on the web still use the default example of:
Seems quite telling. It feels like they've given some of the pieces to get live streaming working flawlessly, but we are still missing a few tools here.
----
The biggest problem I've had is that some gems that we used frequently would break because they weren't Rails 4 ready. We use ActiveAdmin pretty frequently in our client apps, and it's worked for a while, but it's always been on a custom branch and still had some issues that were just recently fixed. YMMV for gems that your app relies on in terms of what will break and what will work.
Yes, but I still prefer Figaro[1], which makes it super easy to configure an app on Heroku, especially when the app has multiple environments on Heroku:
I've used figaro but recently switched off in favor of a combo of foreman, dotenv, and heroku-config[1].
- Foreman is great because you'll get parity with how Heroku runs things (they use the same Procfile and read a .env file). Plus, if you have separate workers, then you can easily boot up your app.
- Dotenv is drop-in for Rails and supports .env usage outside of foreman.
- The heroku-config plugin is great because it works throughout your system and can also pull down the current config from Heroku.
I never understood why you would use YAML for storing settings. In fact, I observed that because of YAML devs are less likely to extract things into configuration settings, especially adding a setting seems to involve a manual server restart. I wrote a gem that's IMO much better:
Settings are configured in Ruby, split into separate files/groups, are easily overwritten per-Rails-env and per-particular-installation, in development environment they are reloaded automatically after a setting is added etc.
I think it's largely a case of cargo-culting a Rails core decision made somewhat arbitrarily before Rails was even released (ie. config/database.yml).
Theoretically I suppose YAML is supposed to be a human-editable data format, but after trying to get translators to translate app strings in YAML format I decided that YAML is worthless as anything except an interchange format, and even there, primarily for Ruby because of its rich semantics.
Yeah we use figaro for local dev and non-heroku production apps to override already sane defaults (extra cruft in config/ and initializers to do that), which the "variables" table can override and is app-admin configurable.
3) Secrets.yml is great, no more worrying about adding your config.secret_token to the .env file when generating every single project.
How is adding config.secret_token to secrets.yml, which you're going to keep out of version control, so much better than adding config.secret_token to .env, which you're also going to keep out of version control? Both files need to be lugged around.
Secrets.yml is a one-toe-in-the-water solution. I hope next minor release we will just have dotenv in Rails for real.
Secrets.yml is in .gitignore by default, while secret_token.rb is not, right? Most (beginner) programmers don't think to implement something like Foreman which handles their secret tokens / API keys and commit them straight into their code. With it being standard in the Rails app, gems can rely on sending their secret keys into a file they know will not be committed by default.
As is, you need to remember to dig through all your initializers and copy out all the tokens (Devise, Omniauth, etc) and put them in a .env file
That makes sense, since database.yml is not going to contain any sensitive data anymore (passwords and usernames will be stored in secrets.yml), this file can be safely stored in repository.
I like this approach but there is a trade-off - you're an SQL injection away from losing your secrets, as opposed to a RCE or file reading bug when they're stored in .env. SQL injection bugs are more likely.
We've also built and upgraded a few projects on Rails 4.1 recently and it has been very smooth.
On a side note: we avoid ActiveAdmin like the plague for the very reason that you specify here; our experience upgrading it between Rails versions has been terrible. We use our own simpler admin 'scaffolding' instead - https://github.com/SquareMill/generic_admin_controller/tree/...
It depends. For initial work, AA is a quick hack to get something out there fast. It's akin to django admin. Anything more complicated than batch spreadsheet CRUD will benefit from non-AA, custom admin UIs. One thing that we've encountered is we'd like Disqus style comments, but AA's are flat without an ability to delete them. Yeah we had to use a whole raft of crap to get AA working on 4.1rc including pinning sprockets and sass-rails version. Overall, AA has its place but there's never been, nor will there ever be, a perfect tool for all seasons.
I've had many more problems with AA in the past. (Like Styling, simple_form) I quite speedily dropped AA in favor of building my own AA backend, which is not that hard...
AA consists out of a lot of stuff that you can just as easily put in your Gemfile.
like inherited_resources, has_scope, devise, cancan, kaminari in favor of AA's will_paginate, and ransack.
I'm currently happy not to be on AA, it seems it would have held a lot of development back. AA ties you down to a lot of stuff that might break in the future.
I think it's a great gem if you're starting with rails or need a quick admin backend of your models (when your site is mostly frontend). If you're looking for a true backend that needs some degree of custimization I woudn't risk it.
Me too. Luckily I was monitoring some lengthly database operations, nothing customer-facing.
Sometimes the streaming reply worked, sometimes it hung, sometimes it crashed. After a few days of pain I rewrote it in Node (which is a shame since the rest of the code is in Ruby). Worked 100% first try, no handholding.
I don't care whose fault it is. ActionController::Live should be turned off until it's more stable.
I imagine the Rails team wants to make this more robust but I think there's some bad design decisions in Rack that are preventing ActionController::Live from being as robust as it could.
Comments
For those curious as to how things go from Rails 3 to Rails 4.1, I've now built a few Rails 4 and 4.1 apps for clients and here's been my thoughts:
1) Turbolinks comes standard with Rails 4, and you will either love it or hate it. If you do use it, expect your javascript to break at one point or another. The jquery.turbolinks gem helps, but I've still had to debug a bunch of funky behavior with it.
2) Strong parameters takes a while to get used to from the old attr_accessesible way of doing things. That being said, I think it's worth it to learn it. It prevents a lot of conditional attr_accessible :blah, :as => :admin that goes on. The one thing I'd say is if you are going to use strong parameters, you might want to install a gem like Annotate so you can keep track of your attributes in the models. Sure you can just look in Schema.rb, but tabbing back and forth gets to be kind of a pain.
3) Secrets.yml is great, no more worrying about adding your config.secret_token to the .env file when generating every single project.
4) Mail Preview is nice, but for some reason I still seem to use Mailcatcher mostly to view / see how emails render out. Think this is mostly me sticking to my own ways.
5) ActionController::Live still feels pretty half baked. The fact that most examples / tutorials on the web still use the default example of:
Seems quite telling. It feels like they've given some of the pieces to get live streaming working flawlessly, but we are still missing a few tools here.----
The biggest problem I've had is that some gems that we used frequently would break because they weren't Rails 4 ready. We use ActiveAdmin pretty frequently in our client apps, and it's worked for a while, but it's always been on a custom branch and still had some issues that were just recently fixed. YMMV for gems that your app relies on in terms of what will break and what will work.
Yes, but I still prefer Figaro[1], which makes it super easy to configure an app on Heroku, especially when the app has multiple environments on Heroku:
[1] https://github.com/laserlemon/figaroI've used figaro but recently switched off in favor of a combo of foreman, dotenv, and heroku-config[1].
- Foreman is great because you'll get parity with how Heroku runs things (they use the same Procfile and read a .env file). Plus, if you have separate workers, then you can easily boot up your app.
- Dotenv is drop-in for Rails and supports .env usage outside of foreman.
- The heroku-config plugin is great because it works throughout your system and can also pull down the current config from Heroku.
[1] https://github.com/ddollar/heroku-config
I never understood why you would use YAML for storing settings. In fact, I observed that because of YAML devs are less likely to extract things into configuration settings, especially adding a setting seems to involve a manual server restart. I wrote a gem that's IMO much better:
https://github.com/jaroslawr/dynamic_configuration
Settings are configured in Ruby, split into separate files/groups, are easily overwritten per-Rails-env and per-particular-installation, in development environment they are reloaded automatically after a setting is added etc.
I think it's largely a case of cargo-culting a Rails core decision made somewhat arbitrarily before Rails was even released (ie. config/database.yml).
Theoretically I suppose YAML is supposed to be a human-editable data format, but after trying to get translators to translate app strings in YAML format I decided that YAML is worthless as anything except an interchange format, and even there, primarily for Ruby because of its rich semantics.
There's a typo in your README, I think the last exception mentioned should be MissingSettingException rather than MissingGroupException.
Yeah we use figaro for local dev and non-heroku production apps to override already sane defaults (extra cruft in config/ and initializers to do that), which the "variables" table can override and is app-admin configurable.
Anyone had any luck loading their secrets.yml file into heroku, figaro style?
Does Heroku even support the secrets.yml file at the moment?
How is adding config.secret_token to secrets.yml, which you're going to keep out of version control, so much better than adding config.secret_token to .env, which you're also going to keep out of version control? Both files need to be lugged around.
Secrets.yml is a one-toe-in-the-water solution. I hope next minor release we will just have dotenv in Rails for real.
Secrets.yml is in .gitignore by default, while secret_token.rb is not, right? Most (beginner) programmers don't think to implement something like Foreman which handles their secret tokens / API keys and commit them straight into their code. With it being standard in the Rails app, gems can rely on sending their secret keys into a file they know will not be committed by default.
As is, you need to remember to dig through all your initializers and copy out all the tokens (Devise, Omniauth, etc) and put them in a .env file
That's fair. I can agree it is a nice optimization for the beginner Rails developer.
secrets.yml is not in .gitignore by default
Just checked -- you are right. I was using Rails Composer for one of the apps I checked, which does include it by default.
They also removed database.yml from the default .gitignore ... I don't understand why?
That makes sense, since database.yml is not going to contain any sensitive data anymore (passwords and usernames will be stored in secrets.yml), this file can be safely stored in repository.
I keep secrets in the DB. Only thing in the ENV that matters is DATABASE_URL. I'm surprised more people don't do this.
I like this approach but there is a trade-off - you're an SQL injection away from losing your secrets, as opposed to a RCE or file reading bug when they're stored in .env. SQL injection bugs are more likely.
We use figaro and have a table called variables that overrides the former. Also, we can restart the app from itself and see log files live.
Because secrets.yml is a better solution. A lot of rails developers have been using non-committed YAML files instead of .env anyway.
The environment variable pattern comes to most rails setups from Heroku (whether directly or inspired by it), not from the rails core team.
We've also built and upgraded a few projects on Rails 4.1 recently and it has been very smooth.
On a side note: we avoid ActiveAdmin like the plague for the very reason that you specify here; our experience upgrading it between Rails versions has been terrible. We use our own simpler admin 'scaffolding' instead - https://github.com/SquareMill/generic_admin_controller/tree/...
It depends. For initial work, AA is a quick hack to get something out there fast. It's akin to django admin. Anything more complicated than batch spreadsheet CRUD will benefit from non-AA, custom admin UIs. One thing that we've encountered is we'd like Disqus style comments, but AA's are flat without an ability to delete them. Yeah we had to use a whole raft of crap to get AA working on 4.1rc including pinning sprockets and sass-rails version. Overall, AA has its place but there's never been, nor will there ever be, a perfect tool for all seasons.
RailsAdmin works with Rails 4.1 and is a good replacement for ActiveAdmin. I have RailsAdmin working in https://github.com/starterkits/rails4-starterkit if you need a reference for config.
I've had many more problems with AA in the past. (Like Styling, simple_form) I quite speedily dropped AA in favor of building my own AA backend, which is not that hard... AA consists out of a lot of stuff that you can just as easily put in your Gemfile. like inherited_resources, has_scope, devise, cancan, kaminari in favor of AA's will_paginate, and ransack.
I'm currently happy not to be on AA, it seems it would have held a lot of development back. AA ties you down to a lot of stuff that might break in the future. I think it's a great gem if you're starting with rails or need a quick admin backend of your models (when your site is mostly frontend). If you're looking for a true backend that needs some degree of custimization I woudn't risk it.
It is very half-baked. I put it into a production system and had tons of headaches.
Me too. Luckily I was monitoring some lengthly database operations, nothing customer-facing.
Sometimes the streaming reply worked, sometimes it hung, sometimes it crashed. After a few days of pain I rewrote it in Node (which is a shame since the rest of the code is in Ruby). Worked 100% first try, no handholding.
I don't care whose fault it is. ActionController::Live should be turned off until it's more stable.
I imagine the Rails team wants to make this more robust but I think there's some bad design decisions in Rack that are preventing ActionController::Live from being as robust as it could.
Yep, cf. "I firmly believe Rack is shackling progress for Ruby on the web." - @tenderlove
https://twitter.com/tenderlove/status/443893529010393089
it's pretty hard to do something better with the current status of Rack
slaps head I was doing that by hand - lol.
Another alternative is keep a rails console open during development and just type the class name of the Model or Model.column_names
My weekend project will be updating https://github.com/steakknife/rails41rc_plus_hacks_and_threa...