Chris Oliver

Haha no worries man, it's not a noob mistake, definitely one that I'd be like huh that's weird and have to do some digging to make sure it was all configured right myself. Run into those things all the time.

Hmm, looks right. Also double check you've got a belongs_to :user on the model I guess. I'm not sure what else it might be. That's odd.

Sorta! This will permit it if it's submitted, but your form is automatically generated by your database columns. If your migration didn't include a user_id column, then you won't have that in the form. Check that and make sure you added one, if not you can rollback and edit or add a new migration for it. I think that's probably the culprit.

Did you add the user_id column to your Post model?

None that I've done, but you can upload videos or songs using Shrine, Carrierwave, etc just like you would with pictures. Then from there as long as you've got Video.js or something, you can feed the url of the upload into that pretty much the same way you would take the upload url and embed it with an image tag. It would just go into a video tag instead.

As far as ffmpeg, you can do all kinds of cool stuff with it. I've used it with Shrine to process uploaded videos.

This example shows using ffmpeg to extra some video metadata out: https://github.com/janko-m/shrine#custom-metadata

And this example shows processing a video to transcode it and take a screenshot for a thumbnail: https://github.com/janko-m/shrine#custom-processing

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/