Chris Oliver

Nothing so far unfortunately on sqlite. This is what I'm watching right now: https://github.com/sparklemotion/sqlite3-ruby/issues/195

That's a good question. I'm not sure why. I've setup fonts before like in the tutorial you linked and that works well. It seems pretty common of a feature, but I'm not sure why they don't include that by default.

Then again, there are a lot of people like me that use Google Fonts or TypeKit in order to just include the fonts from somewhere else without actually including them in the app. Maybe that's common enough they don't include the fonts folder.

Great questions. I've only used Elasticsearch in production on Heroku where they take care of the security for you. As for securing your own instance, I don't believe that you need a VPN in order to secure it properly, but you will definitely want the authentication and firewall. There are some other suggestions out there about adding in SSL and some other things as well, for example: https://brudtkuhl.com/secur...

I'm not an expert on this stuff and I've only used their legacy SSL setup, so unfortunately I don't know that I have any advice for you on this one. Hopefully someone else can weigh in here for you or you can check with Heroku support on it!

You basically need to just copy paste the module and class into a file in your app (say config/initializers/receipts.rb) and then override the methods you want to change inside the class. You can also copy and paste the entire file there into your app if you want to modify all of it.

So there aren't really any differences from my videos for individual charges, just that you create a Charge instead of a Subscription object basically.

As for moving code from controller to model, the only thing that changes is the context. On the controller, your variables and things that are available are all the params and controller stuff. When you move it into the model, you're inside the record itself, so you need to pass in the params you're going to use. That's an important difference, but not too significant.

Maybe an idea for figuring this out (and you may have done this already) would be to create a new app, test this stuff out from scratch and then see if you can get a simple version of this working standalone, and then try to take that and apply it to your actual app. I build lots of throwaway apps to prove out ideas like this and it helps when I can't wrap my head around a problem. Start incrementally, only attempt making a charge, then add a quantity to it, and then once you've got that working add it to your app?

Also don't feel like you need to migrate code into the model yet if you're not ready. You can do all this in the controller if it helps wrap your head around it. At the end of the day, a working app is better than anything else.

It shouldn't. They lock your account to whatever was the most recent version of the API when you signed up so that you'll have seamless integrations and their docs will show you what's available from the version you're on as long as you're signed in.

You can upgrade but it won't likely affect anything for you. What's the latest? Have you narrowed down what's going on?

This is coming soon! APIs are the next series after file uploading. I've been doing some work with iOS / Swift and React Native on the side which will tie into the APIs content as well so we can talk about doing native mobile apps but also Turbolinks-iOS and the like. Basically this is just taking some more time to research all the things I want to cover and so I'm filling in with some file uploading, transcoding, video processing things.

Really good question. The main tradeoff going that route is that while you might reduce the number of records at the beginning, you won't in the long run because you'll need to save the read timestamps for each of those users. You'll also complicate the initial query for notifications because you now have to search multiple tables (forum threads, episodes, etc) to figure out which ones you should notify the user about.

So if you're going to be creating those records anyways, why not just save them as a Notification record at the beginning? You can create them in a background job that will speed up creation of them at the beginning without overcomplicating your app just yet. Once you hit massive performance problems, you can optimize it then because you'll know exactly where the bottlenecks are. Trying to optimize before you know where the bottlenecks are is always where engineering problems tend to make things really tough.

Make sure you're using these helpers for your static assets: http://api.rubyonrails.org/...

A bit counterintuitively, that actually makes things more complex if you treat direct messages that way. By doing that you complicate the database significantly because now you can't simply join tables since you're using polymorphic assocations. Plus your direct messages no longer have a Chatroom object meaning all your messaging code on the frontend and backend need to account for the different types and treat them differently.

By treating DMs as a special Chatroom with only 2 users, you can run the exact same Javascript and server-side code without modifications. The only rules you need to set in place (like we did in the episode) are to specify that Direct Message channels are only between two users. That's the only difference between a direct message channel and a public channel making this a lot easier to maintain.

Hey Darren!

Normally I would recommend you just put them on the user model directly. The reasons to split it up are normally when you want a user to have multiple addresses (shipping and billing for example) and not so much worrying about a table being bloated. If you were talking 100 columns on one table, then sure that sounds bloated, but an address is no big deal.

On the other topic of routes, when you're doing a has_one you actually want to do a resource :profile instead of the plural resources :profiles because that will create routes like /profile instead and you don't need to specify the ID. Since there is only one profile per user, it doesn't make sense to pass the ID into the URL like you've probably noticed. :) A singular resource route will let you say @profile = current_user.profile without looking anything up by IDs, just associations.

I would probably say, start easy and just add them to the user model and add the fields to the edit registration page at the beginning. No real big sense in breaking out the profiles yet unless you have something that requires it to be split.

Already did! :) https://gorails.com/episode...

I would recommend using this: https://github.com/platafor...

You're welcome! 🎉

Fixed! 3 minutes. Not too bad response time. 🍻

You're welcome!

That is correct! I'll be covering that in the future, this is more just the basic introduction. S3 will be coming shortly.

I had a couple people confirm things were working. Still haven't upgraded my laptop yet, but pretty excited to!

Hey Aaron,

That all sort of depends on what information is being sent to your webhook. Where is it coming from? What do the params look like? Have any example stuff we can take a look at to get you headed in the right direction?