Chris Oliver

It definitely can take a while sometimes. Depends on how powerful your computer is and stuff.The good news is you rarely need to do it so once it's done, you will be set for quite a while!

Jacob,

You should be fine putting it in RegistrationsController, my mistake. The main reason why they suggest ApplicationController being that not everybody overrides the RegistrationsController, so it's easier. It can definitely go in RegistrationsController too because that's really where it's being used.

I don't know about combining it, other than setting the arguments to a variable and passing in just the variable into both.

Yeah, I think normally the devise_paramter_sanitizer stuff has to go in ApplicationController. Not entirely sure why but I guess because it's common and that doesn't require people to override the RegistrationsController.

I don't have a video on it, but that's a good topic. My Guides link in the navbar is actually like this.

What you want to do is setup a before_action to set your instance variables so you can use them in your partials that you include on every page. That will set it up so that you always have them available and can display them on every page.

I'll have to make a screencast on this as well!

Awesome to hear! :)

Great point Rick! That's probably a common problem for anyone trying this. Thanks for sharing that. 👍

I'm going to be doing a series on deployments coming up soon.

In the meantime, check out this episode: https://gorails.com/deploy/...

I ssh into the production machine and create the secrets.yml which we symlink on every deploy so your production secrets are kept separately and only the server.

I spent a bunch of my day yesterday learning iOS so I think we'll be able to make some great little example apps in some episodes soon. :D

All you have to do is add a controller for it and then you can loop through current_user.likes.each do |like| and print them out on the page.

I'm not sure that it does. The only gem version that looked compatible was the very first release of it. Probably isn't worth using.

I'm not familiar with it, but it sounds like somethings up with your config there if your environment variables aren't being set. I'd double check all that stuff for production with dotenv because that seems to be your culprit.

My approach is usually to create a separate secrets.yml that only lives on production servers instead of using Dotenv.

Hey James, are you using Figaro for the .env file?

Really awesome idea for a series. I definitely want to do this as there are just so many things to cover and even if I just introduced the various things, it would be helpful. I'm going to make sure this is on my list to prioritize.

That makes sense. You may want to make Brand a separate table so it can have all its own fields separate from Company.

It feels separate logically, and probably would be safest to separate out instead of saving them both to the same table. It also helps make the relationship easier where a Company can have many Brands. If you did them as a single table, you'd have a lot of self-referential stuff going on and I'm not sure that'd be good.

The only downside to separating them is that sometimes you might have a Company that only has one Brand and it's basically the same details for both.

Ah, so Company and Brand are effectively the same thing. That's interesting to know. You might check out STI (Single Table Inheritance) for those. It lets you use the same table for two different types when they share pretty much all the same fields.

Venues makes sense as a different table. You'll probably want some more for Products as well.

Definitely draw it out on paper. I often will do that and it helps you figure out what types of things you can and can't do with your data structure that way.

I think you're on the right track Alan. Do Venues sell all the Brands of a company or just specific ones? You might want a relationship between those two as well.

Good to hear! This has to be frustrating.

Seems they've been making some changes to it, one of those being it's not a login shell, so you'll have to do "bash --login" for now. Still other outstanding issues. Maybe they'll get some of them fixed soon.

Makes sense with the login shell. I wonder why they changed that, because I don't think that was how it used to be. Going to frustrate a lot of people if they keep that as the default.

What we setup earlier was Devise so that you can login and since WebSockets share the same cookies a web request does, when you connect to the WS, it will log you in with Warden (devise's underlying authentication layer) and let you use the WebSocket. Then we have access to the current_user method inside ActionCable just like we do in a normal web request.

On the frontend, you can add a current-user meta tag keep track of it in your JS so that you can customize your frontend to handle things differently if you're not logged in, etc. Check out this episode for more on that: https://gorails.com/episode...