dlegr250's Profile

@shazebq, this is a little old topic but it's still applicable (and debated!) today. Heroku operates on ENV variables expected in the ENV namespace. It is used by Heroku itself for deployment as well as the 3rd-party plugins that Heroku provides (email, additional DBs, etc...).

Storing env variables in config/application.yml and reading them via code in your application.rb is only useful if your production environment can do the same. As you pointed out, you can't (easily) dynamically add the production-ready application.yml into Heroku's deployment process. Thus, using application.yml is not a good idea for Heroku deployment.

If you use Heroku (as I do for several projects) I recommend using the dotenv gem. In your local development, you have a .env file that stores environment variables. So your app code expects and uses the ENV namespace.

But you have to manually set those ENV vars on Heroku. Currently you can login to your Heroku app and they provide a clean interface to alter your ENV variables. Put your production-ready secrets and keys into that interface and your app will use them when it's deployed.

This way each developer can have their own local .env file with particular configs, yet the production system will always be consistent. The only "gotcha" is when you need to add a new env variable that you have to remember to add it everywhere.

What I have started doing is keeping application environment configs in another repo named "REPO_NAME-environments" where I have folders for development/test/staging/production and applicable config files there. This keeps them versioned and is a single place for them to exist. Goes without saying, but make sure this is a private repo.

Hope you or anyone else reading through these great comments finds this helpful! I recently did a major overhaul of some app configs myself and wanted to throw in my 2 cents.

Ryan, definitely have to agree with some of the others that you have a very uncanny knack for always going over issues I'm working on right now. I had a simple signup form that created an account and user which works but the code isn't as "elegant" as I would like. However, I think a form object would be more complex for my simple use case.

But this gets me thinking in that fashion; instead of throwing it all into one big object because it's all "related", I'll now be thinking about ways to separate logically-related chunks of code into separate objects. Did like the fact that you could "enforce" strong parameters by individually assigning values...it's something I innately knew but didn't fully realize until you pointed it out.

Really enjoy the casts on refactoring/organizing code. They help me a lot as I tend to write it for a deadline, and then maintain it later.

@tpy,

Just in case you were still wondering, Rails creates these IDs when you use the <%= form_for ... %> helper. It knows that you're creating a new record so it defaults to a form ID of "new_model". It does the same thing for the IDs for various inputs.

This is just amazing...I found the dataTables plugin a while ago and was trying to figure out all out for a few hours. So I come to railscasts to see if Ryan had anything similar, and lo and behold...he's got an episode on the exact plugin I'm using. This has happened so many times it scary - I'm trying to figure out how to use something and Ryan has an episode on exactly what I'm doing. Railscasts is well worth every dime! Thanks for your awesome work, Ryan.

It's just uncanny how every time I'm looking at something Ryan does a railscast on that very topic. This has happened at least 5x in the recent months...

Looking forward to seeing if my thoughts about Bootstrap match up with Ryan's!

After watching the video, I'm slightly confused. It seems that presenters more or less add another layer of complexity to the view concept. Is there some convention that if your controller and view are below a certain complexity level that a presenter isn't a best choice? When would I want to use a presenter vs leaving the show action with a little more data in it?

Also, are presenters main-stream or becoming main-stream? I've heard little about them until recently. Are they something that will most likely stick and become a standard convention?

Looks like something worth learning more about, but not sure I'm fully convinced they are very useful, but that's probably just my lack of experience with them speaking.