Chris Oliver

That was my bad. I realized I hadn't been making commits while recording but I'll try to do that in the future.

I'll probably do a screencast on Sidekiq (and other background workers) in the future. For now, you might want to check out this post http://chrisdyer.info/2013/...

That sounds like your compiler is too old maybe. I'm not sure the best solution there. What version of your OS are you on and what version of Ruby are you using?

Interesting. I haven't had trouble with that gem before. Did it give you any more text for the error?

Sounds like it's having trouble reading from your Git repo. I'd guess none of that has changed, but you might want to double check it. You can also do the ssh forward agent option if you want to use your local ssh keys to check out the repo in case that is causing the problem. Other than something related to that, I don't know what's wrong.

Done!

Sweeet! I'm going to start using this from now on. Thanks for sharing!

Are you using rbenv, rvm, or something else? That'll help determine what you need and then your ruby version just kind of replaces part of a config line for that.

Make sure your passenger_ruby line in nginx.conf points to the right location. I think if that fails, it probably falls back to whatever is in your PATH which could be an older version like REE.

Oh yeah! Forgot about the bundle console command. I'll be sure to use that more often in the future. Thanks! :)

Mostly just because it's very simple and easy to get up and running. From some recent benchmarks I read, it also performs comparatively to Unicorn and some other solutions out there. Seemed to be a good mix of convenience to learn and performance.

Congrats Anthony!! :) After what seemed like a ton of issues, I'm glad you finally got it all running. I'm sure it will be way quicker next time!

It's like you know what's going through my mind. I'm making a dedicated screencast for div_for. ;-)

Absolutely! The authentication is definitely important and one of the next on my list to cover as a follow up pro episode. I'll send you an early copy to review it. :)

Well, the point about using secrets.yml is that you don't need to put them in the ENV anymore. Just make sure the file is not in your repository.

Create secrets.yml on the server in the shared directory like you did with database.yml and then write your keys in it directly. Then add the file to your config/deploy.rb to make sure it gets symlinked on deploy.

After that, you can use those secrets without having to go through ENV. They did this so that you wouldn't have to deal with this annoying system configuration and you can manage it a lot easier!

If you use secrets.yml, you don't access them through the ENV anymore. Instead you want to use Rails.application.secrets.key_name to retrieve your values.

Take a look here for a blog post on it: http://richonrails.com/articles/the-rails-4-1-secrets-yml-file

I'll also be sure to do a screencast on this topic because I think it's not documented too well. :)

You could do that as well. The only thing to keep in mind is if you ever plan on changing the implementation, you'll want to bring it back out into its own method again.

If you're using Rails 4.1, you can use secrets.yml to set these variables or you can set them in the nginx configuration: https://www.phusionpassenger.com/documentation/Users%20guide%20Apache.html#about_environment_variables

You'll have to make sure your assets are loaded properly and the icons display elsewhere.

Sometimes it won't display right away because your icon font isn't loaded until you click the button and it takes too long to load.

You can accomplish that using string interpolation here because it's Ruby code inside the ERB tag.

<%= f.button 'Log in', class: 'btn btn-success', data: { disable_with: "#{icon('spinner')} Logging In..." } %>