Still Google/search kind of flattens the namespace a bit. Now you're going to get lots and lots of Java Spring framework hits on any Ruby Spring google searches.
Exactly. Except they could have used Springloader or something as a shorthand for it (rather than Spring) and it wouldn't have been as much of an issue.
It reminds me of when Wordpress gave one of their milestone releases the code-name Django. They actually changed it to "Rheinhardt" after the initial release because of the confusion it was causing.
In this case it's even worse. Giving a component of a web framework the same name as a different, in a sense competing, framework is just plain silly.
Agreed. I'm a big Ruby fan, but some of the community naming choices are just annoying. In addition to spring: rack, sequel, devise, unicorn, faraday... I could keep going.
Having mailer previews built in is pretty awesome. I pretty much use a gem for that on every project nowadays.
The variants thing is interesting ... I'm assuming its an alternative to rendering a responsive/mobile-first view (on a view-by-view basis). I'm sure there are plenty of use-cases but I don't like the prospect of having to update yet-another-set-of-layouts-and-views.
Responsive views only go so far. Trying to shrink an app designed for a desktop browser down to a 4" phone is a fool's errand. Much easier to go with different templates in that case.
My company is still on Rails 3.2. We had been waiting for the first minor release of Rails 4 to give folks a chance to work out issues, so maybe now it's time to look at upgrading.
Anyone have major issues going from 3.2 -> 4? I've heard horror stories about 2 -> 3, but I didn't pick up Rails myself until 3.x so I don't have firsthand experience.
The biggest change I see is attr_accessible to strong_parameters. Does that mean I need to go through and rewrite all our models and controllers before we can update?
I spent most of my time updating app config. For several of my 3.2 apps, I started using strong_parameters, so it wasn't a leap for me. Another app I have on 4.0 is using the https://github.com/rails/protected_attributes to retain the existing attr_accessible behavior until I get time to update.
It's a way smoother upgrade - exactly as you mentioned really the only major change is from attr_accessible to strong parameters however you can still include the protected attributes gem for a quicker/easier upgrade path (https://github.com/rails/protected_attributes)
It does not, you can actually pull in a gem[1] to use attr_accessible just fine with Rails 4. If you want to transition to strong_parameters, you can include the gem in your Rails 3 project and begin migrating to it, though that's a tough sell on most Rails codebases I've seen as it requires you to update every action in your app.
I have not personally migrated any of my code to Rails 4 from 3.2 yet but the transition will be far smoother than 2.3->3 was.
Depending on how your test suite is set up (if you have one) there may need to be some sweeping changes there. When we migrated we had to switch from our should syntax to the expect s syntax.
I can't remember anything else that was super crazy.
Also be wary of your projects Gems, we just finished a 3.2 to 4.0 upgrade and though rails itself was pretty easy, there were quite a few problems with things such as Solr, Formtastic plugins (some FormTag internals changed in rails4, which broke some stuff).
So yea, the biggest problem was upgrading to Rails4 and getting the Gems to work- many of which had large structural changes in the Rails4 versions. For instance, Devise changed how they handle tokens in the Mailers, etc.
We have a very large App and it took us about 2 months part-time work to migrate fully to Rails4 - of that I'd say about 70-75% of the work was a combination of rewriting strong_parameters/attr_accessible stuff and updating/monkey patching Gems to get them working. But we did go really far, we removed all the stuff that generated deprecated warnings and removed all the "migration helper gems" like "protected_attributes". So if your project doesnt depend on many gems it could be really easy especially if you dont care about using the helper gems like protected_attributes until you get around to rewriting things.
It went comparatively smooth for us. 2 to 3 was a nightmare, 3 to 4 wasn't too awful. Some of the things that bit us:
* Strong parameters means you're going to have to figure out what everything needs for params or break down and call permit! where acceptable. If anyone got crazy with attribute metaprogramming bullshittery, you're in for fun.
* The deep_munge part of strong parameters has some strong opinions about how it should do its job. The code is there to prevent attacks where unusual user input is handed directly to ActiveRecord and interpreted by it. One special case to look out for is that it will rewrite a (JSON-supplied) empty array into nil, which makes life fun if your API happens to put some semantic meaning on nil vs. empty arrays.
* The new restrictions on routing verbs are good stuff, but I can almost guarantee that something was getting away with using the wrong verb before.
* XML parameter parsing has been extracted to a plugin. For some reason XML generation wasn't, but if people are sending you XML data you'll need this: https://github.com/rails/actionpack-xml_parser
That's all I can think of off the top of my head.
In response to this:
> Does that mean I need to go through and rewrite all our models and controllers before we can update?
Not really, no. As a first step we rewrote all of our attr_accessible usage into model class-level constants we could run through strong_parameters. Eventually those moved out of the model, but it was good enough to get going. Example:
I recently upgraded a 3.2 application to 4.0. At a high level, the necessary refactoring to make 4.0 work wasn't bad. It was upgrading gem dependencies, and sometimes switching out deprecated gems, that was a much bigger pain.
Interesting, I looked through it, and his other repos, and he seems to be a really solid rails guy. Looks like a promising kit, especially considering how much of a pita setting up CanCan with Rails 4 can be.
Thanks ch4s3. I released the starter kit after bashing my head in on a few configuration tasks with various gems. I haven't looked far and wide, but I think it's one of the more complete Rails 4 starter apps. I needed it for my own projects, but hopefully it can save some other devs configuration time.
If you know of other solid starter app projects, I'm happy to fork them and make them discoverable in https://github.com/starterkits. It's meant to be a community project. I just haven't had any time to promote it.
Hi. This looks great. I'm new to rails and this looks like it will be fun to mess around with tomorrow and learn what the commons gems etc are. Seriously - Thanks very much for making this. Anything I should know as a noob or shall I just dive in and have a play around?
You should be able to just dive in. Rails is pretty friendly that way. The starterkit app is just a basic Rails 4.1 app with all the gems. So anything you find in Rails 4.1 tutorials should work just fine.
If you run into any issues, just open an issue on the project and I'll do what I can to help.
Neat. The problem with templates in general they lose an ability to hack on and recreate them because they depend on code generation and manual tweaks that have already been done (and lost). As such, I'm refactoring https://github.com/steakknife/rails41rc_plus_hacks_and_threa... into generators that will add the right things to a bare Rails app. So if you need omniauth + devise + cancan but not X, it's a `rails g` away. Rails has an amazing app generator DSL built-in.
Yeah, it's "production ready" in the sense that the starterkit project was pulled from a couple of production apps and properly configured with a nice selection of gems.
Most starter kit apps help get developers up and running in a development environment but leave a big gap between dev and production. Sometimes this is good, but a lot of web apps are very similar.
I got tired of rewriting authentication systems, configuring gems, and repeating the same tasks for each project. Even if you use Devise and similar gems, you still have to do a lot of work to create a good UX and integrate OAuth. And then you have to dig through each gem's documentation to make sure it's configured properly for a production environment.
The rails4-starterkit is basically my dumping ground for tips, tricks, and production tuning settings for Rails 4.1. You'll still need to make adjustments for your own app, but it's a much better starting point for cranking out weekend or freelance projects.
I'm also open sourcing my node starter kits, but they're much earlier on in development and better node projects already exist.
I think there's some pretty substantial ActiveRecord changes under the hood in Rails 4.1, so likely one of your gems are fighting with it and borking your test suite.
Larger apps end up being more SOA than monolithic, I suppose. Rails can usually play a part in these, but in my experience it's usually a win to start fragmenting an app into services once it gets beyond a certain size and complexity.
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.
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.
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.
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.
> 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.
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:
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.
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.
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.
1. It saves values as integers in the database, meaning that removing properties involves explicit setting, and reordering them requires custom migration code.
2. "Avoid using the same names inside different enums in the same class! Doing so will leave Active Record very confused!"[1]
That's right, we can't use the same enum name to two different fields because ActiveRecord might get confused. That's kind of poor, isn't it?
3. Having to pass a macro that'll return the right integer instead of the symbol itself? Really?
This all seems really unwieldy, especially in the face of Enumerize(https://github.com/brainspec/enumerize). It's got none of these caveats. Is there some strength to the Rails enums that Enumerize doesn't capitalize on, other than size constraints by using Int instead of String?
Mailer previews will literally shave hours of time off of my email testing workflow — no more mail-to-a-test-account-and-wait garbage. And that's one of the minor features.
premailer is also useful. Even with the new Rails 4.1 email previews (available in development env), sometimes it's useful to be able to preview in production. https://github.com/fphilipe/premailer-rails
Unless you really need to be checking network deliver that much, mailers have long been testable, getting the last email sent from ActionMailer::Base.deliveries.last
How will it 'preview' the sent mail?
E-mail clients behave differently when it comes to layout.
When I'm doing such testing, I still verify the mail in at least the top 90% tier e-mail clients (web and desktop).
Am I the only one who thinks the `Module.concerning` thing is silly?
Concerns never did anything for reducing real complexity in the first place, except improve code geography, and now we don't even have to bother with that. Yay.
The only thing I noticed, aside from secrets file and cookies etc that is outline in the notes, is that SimpleForm stopped working. Since project I was upgrading was small, I just removed it, but that is not option for bigger projects.
95 comments
[ 3.3 ms ] story [ 134 ms ] threadIt reminds me of when Wordpress gave one of their milestone releases the code-name Django. They actually changed it to "Rheinhardt" after the initial release because of the confusion it was causing.
In this case it's even worse. Giving a component of a web framework the same name as a different, in a sense competing, framework is just plain silly.
The variants thing is interesting ... I'm assuming its an alternative to rendering a responsive/mobile-first view (on a view-by-view basis). I'm sure there are plenty of use-cases but I don't like the prospect of having to update yet-another-set-of-layouts-and-views.
That's why, when you design a responsive website, you're supposed to think / work out mobile first.
Hoping to detect all mobile devices out there based on their http request is no wiser.
After working on responsive websites for about 2 years now, I feel that variants is the way to go with Mobile designs.
You flesh out something lightweight for mobile and then another for tablet + desktop + whatever.
Otherwise your mobile display is needlessly large.
Anyone have major issues going from 3.2 -> 4? I've heard horror stories about 2 -> 3, but I didn't pick up Rails myself until 3.x so I don't have firsthand experience.
The biggest change I see is attr_accessible to strong_parameters. Does that mean I need to go through and rewrite all our models and controllers before we can update?
The upgrade guide is pretty solid, and I imagine it mostly applies for Rails 4.1 as well: http://guides.rubyonrails.org/upgrading_ruby_on_rails.html#u...
I spent most of my time updating app config. For several of my 3.2 apps, I started using strong_parameters, so it wasn't a leap for me. Another app I have on 4.0 is using the https://github.com/rails/protected_attributes to retain the existing attr_accessible behavior until I get time to update.
Hope that helps!
But, you can in theory use the Protected Attributes gem to aid migration with less rewrite.[1]
[1] http://edgeguides.rubyonrails.org/upgrading_ruby_on_rails.ht...
I have not personally migrated any of my code to Rails 4 from 3.2 yet but the transition will be far smoother than 2.3->3 was.
[1] - https://github.com/rails/protected_attributes
Google fu yields http://stackoverflow.com/questions/17371334/how-is-attr-acce...
Depending on how your test suite is set up (if you have one) there may need to be some sweeping changes there. When we migrated we had to switch from our should syntax to the expect s syntax.
I can't remember anything else that was super crazy.
http://railsdiff.org/diff/v3.2.17/v4.1.0/
So yea, the biggest problem was upgrading to Rails4 and getting the Gems to work- many of which had large structural changes in the Rails4 versions. For instance, Devise changed how they handle tokens in the Mailers, etc.
We have a very large App and it took us about 2 months part-time work to migrate fully to Rails4 - of that I'd say about 70-75% of the work was a combination of rewriting strong_parameters/attr_accessible stuff and updating/monkey patching Gems to get them working. But we did go really far, we removed all the stuff that generated deprecated warnings and removed all the "migration helper gems" like "protected_attributes". So if your project doesnt depend on many gems it could be really easy especially if you dont care about using the helper gems like protected_attributes until you get around to rewriting things.
Extracted here:
https://github.com/steakknife/rails41rc_plus_hacks_and_threa...
* Strong parameters means you're going to have to figure out what everything needs for params or break down and call permit! where acceptable. If anyone got crazy with attribute metaprogramming bullshittery, you're in for fun.
* The deep_munge part of strong parameters has some strong opinions about how it should do its job. The code is there to prevent attacks where unusual user input is handed directly to ActiveRecord and interpreted by it. One special case to look out for is that it will rewrite a (JSON-supplied) empty array into nil, which makes life fun if your API happens to put some semantic meaning on nil vs. empty arrays.
* The new restrictions on routing verbs are good stuff, but I can almost guarantee that something was getting away with using the wrong verb before.
* XML parameter parsing has been extracted to a plugin. For some reason XML generation wasn't, but if people are sending you XML data you'll need this: https://github.com/rails/actionpack-xml_parser
That's all I can think of off the top of my head.
In response to this:
> Does that mean I need to go through and rewrite all our models and controllers before we can update?
Not really, no. As a first step we rewrote all of our attr_accessible usage into model class-level constants we could run through strong_parameters. Eventually those moved out of the model, but it was good enough to get going. Example:
# Rails 3.2
class Foo < ActiveRecord::Base
end# Rails 4.0
class Foo < ActiveRecord::Base
endHere's a Rails 4.1.0 starter kit that's production ready and full featured: https://github.com/starterkits/rails4-starterkit
I thought the Rails 'starter kit' was `rails new my_app_name`
If you know of other solid starter app projects, I'm happy to fork them and make them discoverable in https://github.com/starterkits. It's meant to be a community project. I just haven't had any time to promote it.
If you run into any issues, just open an issue on the project and I'll do what I can to help.
Open an issue or pull request when you get your generators working, and I'll happily link to your project. Always good to give people options.
Most starter kit apps help get developers up and running in a development environment but leave a big gap between dev and production. Sometimes this is good, but a lot of web apps are very similar.
I got tired of rewriting authentication systems, configuring gems, and repeating the same tasks for each project. Even if you use Devise and similar gems, you still have to do a lot of work to create a good UX and integrate OAuth. And then you have to dig through each gem's documentation to make sure it's configured properly for a production environment.
The rails4-starterkit is basically my dumping ground for tips, tricks, and production tuning settings for Rails 4.1. You'll still need to make adjustments for your own app, but it's a much better starting point for cranking out weekend or freelance projects.
I'm also open sourcing my node starter kits, but they're much earlier on in development and better node projects already exist.
Edit: Actually easier than I thought; about 10 minutes to figure out the cause and remove a surplus gem, and we're all green. Cool.
Larger apps end up being more SOA than monolithic, I suppose. Rails can usually play a part in these, but in my experience it's usually a win to start fragmenting an app into services once it gets beyond a certain size and complexity.
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.
It is very half-baked. I put it into a production system and had tons of headaches.
https://twitter.com/tenderlove/status/443893529010393089
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.
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/...
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.
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
The environment variable pattern comes to most rails setups from Heroku (whether directly or inspired by it), not from the rails core team.
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/figaro- 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
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.
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.
Does Heroku even support the secrets.yml file at the moment?
slaps head I was doing that by hand - lol.
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.
1. It saves values as integers in the database, meaning that removing properties involves explicit setting, and reordering them requires custom migration code.
2. "Avoid using the same names inside different enums in the same class! Doing so will leave Active Record very confused!"[1]
That's right, we can't use the same enum name to two different fields because ActiveRecord might get confused. That's kind of poor, isn't it?
3. Having to pass a macro that'll return the right integer instead of the symbol itself? Really?
This all seems really unwieldy, especially in the face of Enumerize(https://github.com/brainspec/enumerize). It's got none of these caveats. Is there some strength to the Rails enums that Enumerize doesn't capitalize on, other than size constraints by using Int instead of String?
[1] http://brewhouse.io/blog/2013/12/17/whats-new-in-rails-4-1.h...
[1]: https://github.com/ryanb/letter_opener
Colors, fontsizes, margins, etc. on preview to get it right - then email clients to perfect it.
A massive thank you to the Rails team for their time and commitment towards making the best web framework on the web even better!
http://learn-rails.com/learn-ruby-on-rails.html
Also, there are 5 starter apps for Rails 4.1 from Rails Composer:
http://blog.railsapps.org/post/79115273530/5-starter-apps-fo...
Concerns never did anything for reducing real complexity in the first place, except improve code geography, and now we don't even have to bother with that. Yay.