Chris Oliver

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?

Trying printing out the errors on the object after the valid? to see what validations are failing. That might help you figure out what's up with that stuff and get you onwards towards the bigger fish. :)

Great! Well I will possibly do both, but that's good to know. I think that's the more important thing, so long as the libraries support what you want!

Refile actually provides a Sinatra app that will let you do this. https://github.com/refile/refile#processing

Using something Shrine, I imagine you can build a plugin to do that similarly.

Be awere that you're definitely going to want to cache this to a CDN because you do not want to have to process an image every single request. That's way too much unnecessary work, so you want to do it the first time and then have it cached in the CDN.

Another option would be to generate say 5 different sizes and let the user specify the dimensions, but use CSS to resize the image in the browser and grab the smallest size that fits those dimensions.

Dropzone will let you do that too. They're pretty equivalent in functionality. The trick is how you handle the uploads. For example, you can make Dropzone work (and look) exactly like jQuery file upload: http://www.dropzonejs.com/b...

The multiple uploads is pretty easy, you send each over to the server, and it'll attach them to the Blog record by creating an individual "Media" record for each of your pictures, videos, etc. You have a one to many relationship server side to handle that stuff.

jQuery file upload is one of the most confusing libraries to work with, so it was on my list to figure out for a while back when I first used it. Dropzone is actually a lot easier so I might use that one instead unless you're tied to jQuery file upload. The nice part about it is that the API is easier, and it doesn't care if you have jQuery or not so you can use it independently.

Yes! They're on my list! Also going to do video uploads with transcoding and taking thumbnails of them.

If it's not getting called at all, check that your route is getting called and the action as well. Your Javascript looks like it will submit the form which should go to the create action of the events booking controller.

The thing is that if it jumps straight to your else statement in the action, then it definitely ran the reserve method. Are you sure that your record is valid? The first line of the reserve method doesn't attempt to process the booking unless it is valid which means it terminates and returns instantly if the booking doesn't have a valid set of attributes. That's probably your issue (gotta even check those little tiny things) if it's terminating before it gets to your other code.