Chris Oliver

I believe these gems are required to be in the production group because when the assets precompile command runs in the production env. Your assets.compile flag is only for assets that are referenced but uncompiled which isn't likely to happen because you should have them precompiled already.

Plus once the precompile is done, saving 3 requires in your gem will only save you a couple milliseconds on boot only, which only runs when you restart your app, not every request so you aren't likely to save any valuable time doing this anyways.

Hey Victor, please be constructive. Angry comments don't help anyone.

A common misconception like you have is that Rails API-only mode is how you should build all Rails APIs, which is flatly incorrect. In some specific cases where you don't want to render a website, you can use API-only mode to strip out most of the Rails functionality that's used for cookies and other web functionality but isn't needed for APIs. Since it removes a lot of Rails features, API-only mode should only be used when you know you really want to disable those features of Rails.

That's why it's not the default and why I'm not talking about it just yet. We will be covering this but it is not the "new way" of doing things as you claim. It is a way of doing things for a specific situation, not all situations.

So again, we're here to help each other learn these things, not shout angry comments at me about something that you believe is incorrect. It's not, and the whole reason I made this episode was to discuss how APIs are not a special thing like you claim. It's a common misunderstanding and one that we can fix if we talk about this stuff in-depth.

Next time instead of telling me I'm stupid, simply ask why I haven't talked about API-only mode and we can all have a much more constructive time together.

Yeah that's what I was thinking but just wanted to confirm it. Consuming pretty standard but there's few resources out there that actually talk about sending out webhooks and how to handle responses and exponential backoff and things. I think that'll be a fun set of episodes to do.

I wrote out a list of topics related to APIs and had like over 50 different episodes I could do. That's so many it could fill up the entire next year with only API content. Love it. :D

I believe mailers by default don't include helpers. This is by design I think, but it does seem like one of those things that would be included automatically.

You can add helper lines to your mailers in order to give them access to the helpers:

helper :application

Great work Scott, and props for coming back and sharing your solution! 👍

Like building webhooks for your customers to use or consuming other service's webhooks?

First auth video will be next week. Going to be recording it tomorrow. :)

@sites.currency.to_sym should work. 👍

DANG. That's a rough lesson to learn. Glad you didn't have to pay for any of that and I can't imagine how rampant that problem is for Amazon and other places.

And yeah, best long term solution for IAM stuff would be to have separate users for each bucket so nobody in development could accidentally delete your production files and vice versa.

You can still populate secrets.yml with environment variables so it doesn't matter either way you slice it.

production:
  aws_bucket: <%= ENV["AWS_BUCKET"] %>

Benefit of using secrets.yml is you can do both to keep everything consistent, especially when things like development environments often share test keys which don't really matter if they're in the repo or not.

Almost forgot to post an update. Looks like everything deployed just fine with no problemos! 😎

Because we set the bucket name in the secrets.yml, you can just change that for each environment just like you would do with any other secrets.

# config/initializers/shrine.rb
  bucket:            Rails.application.secrets.aws_bucket,

# config/secrets.yml
development:
  aws_bucket: app-development

staging:
  aws_bucket: app-staging

production:
  aws_bucket: app-production

Make sense?

Yeah you should be safe. I'm actually upgrading GoRails to 5.0.1 as we speak so I will report back if I have any issues.

I saw the announcement blog post last night on http://rubyonrails.org.

Github's build stuff is probably for master, not necessarily for the release unless you're looking at the tag for 5.0.1.

I'm not sure what all was included in it, but I know that Phusion talked about the slow client DoS they fixed in Puma for this release: https://blog.phusion.nl/2016/12/21/actioncable-under-stress-protecting-your-application-against-slow-clients-using-passenger/

The auth stuff is going to be fun. So many different methods.

Brilliant! :D

Thanks Matias! :)

That makes sense. I noticed Chrome doing this with videos recently so I figured it might be the same. Photoshop is pretty smart about detecting what you intended to shoot as and everything but Chrome can only do the basic orientation stuff that's set.

You should also be able to add a processor into Shrine to have imagemagick correct the orientation on upload as well. There's an "auto_orient" method you can use with MiniMagick to do that automatically.

I'm not sure if this matters (I know it does with video) but do your photos happen to have been taken at the other orientation originally? I'm not sure if the browser may be reading some metadata and rotating them automatically or not.