Chris Oliver

You got it Josh! I just added Braintree to the GoRails checkout process so I can make a screencast showing those steps for you as well.

That's a bit longer of a process that I haven't dove into just yet, but it's not too bad. Basically you'll need to add an extra step at the beginning to onboard your "SubMerchants". You'll ask for some information on them, send it over to Braintree and save the response. It'll give you some extra information that you can use for every transaction to make it processed on the sub-merchant's account. This is nice because it doesn't make you have an escrow feature and can happen directly on their account. They outline a lot of this here which is pretty similar to what I covered in my videos, but you'll have to build a couple things from scratch like the onboarding form for submerchants. https://developers.braintreepayments.com/guides/marketplace/overview?_ga=1.80046359.1408912539.1449506584

If you do need to have an escrow feature, you'll probably have a bit more work to do. You'll be the one accepting all the money and then paying things out from your bank account. I'm not sure about all the details on this but I'm sure you could also do this with Braintree. It might make your accounting a bit more complex, but is also very doable.

Yeah! I will do that. Generally with an individual server you want to set the number of workers equal to the number of CPUs on your VPS. Digital Ocean will show you how many CPUs you have on your machine in their dashboard and you can configure that workers variable and restart nginx to make that work.

I'll make a video on this in the future!

Hmm, I've had this a few times before. I think typically it is caused by an error in your application. Check your nginx and rails log files to see if you find any errors listed.

Oh definitely! I had an account with a trivial password get hacked recently that made me think about how good a two factor auth tutorial would be for GoRails. Gonna get on that!

Also, do you know if this gem uses Twilio for a backend or is it generic in that it could support anything? I haven't looked at this much.

That's a really good question. As far as I know, you can't extend it or create a hold for a longer period of time.

Kickstarter simply saves the card to be charged at a future date and does not create holds on the cards. This is also bad for your customers because they can't actually use that money on their credit card in the meantime. You also don't necessarily know if the project will get fully funded, so it doesn't completely make sense to reserve that money from your users. The only downside to this is you'll see a portion of those pledges get declined when the project is fully funded. Kickstarter provides a "Fix payment" process when the pledge gets declined that you can read more about here: https://www.kickstarter.com/help/faq/backer+questions

Generally I'd say for crowd funding, you'll want to stick with Kickstarter's approach and not apply holds. You can then spend your time designing the failed pledge process so that that is really smooth when a card fails at that time.

Yes! I've actually had this on my list to cover really soon. I'm going to try to squeeze it in after the Rails 5 videos I want to cover. This is becoming so common, it'd be really important to have a video on it!

Yeah! That would be much better I think. You can write a rake task to do the sync and then use the whenever gem to schedule that to run on a nightly cron. https://gorails.com/episode...

You might be needing to add a before_action for the destroy action called set_comment to set the @comment variable. It's saying that @comment is nil there so that would be it. You can just set @comment = Comment.find(params[:id]) in the before action and you should be set.

Woot! :D

Hey Melanie!

For deleting comments, it might be useful to add a "resources :comments" to your routes that isn't inside another resources block. Then you can create a regular CommentsController with a destroy action like normal. That way you can delete any comment as long as you know the ID of it and not worry about whether it's a film or actor comment because that doesn't really matter when you're deleting a comment.

To add the delete link to each comment in the view, you can say: <%= link_to "Delete", comment, method: :delete %> and that will make a DELETE request to the /comments/1 url, which will trigger the destroy action.

That should do it! If you want to go over and above, you can also make it as a "remote: true" link so that you can return some JS to remove the item from the page to make it AJAXy and nicer to use.

Yeah, if it's in the Attendance model where the scopes are, you can just use those methods directly without having "attendances" first so just planned_leave.

If you do it in the AttendanceSheet model, you'll need to preface the scopes with the attendances association attendances.planned_leave.

Ah, so those methods should actually be class methods!

def self.ps
  (attendances.planned_leave.count + b.attendances.maternity_leave.count)  / b.attendances.count.to_f * 100
end

Note the self. there in the name. That makes it a class method which makes it work like a scope would.

This lets you do this:

@attendance_sheet.attendaces.ps

The reason being is that when you access a has_many association, it returns a Relation object that functions more like the model class instead of an individual record.

You can access the scopes through the attendances association if that's what you're asking. It should look like this:

# First we need a sheet
@attendance_sheet = AttendanceSheet.first

# Give me all the present attendances for that sheet
@attendance_sheet.attendances.present

Yeah, so by default your CSS for that div probably needs to be "display: none" so it's hidden. Then when they submit the form, you "display: block" or whichever makes the most sense. As long as you're doing a regular form submit, it'll disappear because of the page load.

If you want the form to be an AJAX form, you can simply hide it after the AJAX request gets a response back.

That should do the trick! Plus this will be a good starter project for using jQuery. :)

You probably could actually. You'd need to probably do some hacky things for that CSS, but it could work. However, if you're doing something more complicated than just changing the button text, I might encourage you to just use regular old jQuery to listen to the click or form submit and do the work there. Then you can put your loading-indicator div anywhere you like on the page and your CSS can be relative to its parent div.

Hmm, I'm not sure about that. I've had that in the past, but usually it's due to some bad column setup on your database table. You might need to fix your profiles table if it doesn't have an ID column for example. http://stackoverflow.com/qu...

This is exactly what I want to talk about in a future episode (basically deploying breaking changes to production).

You have a bunch of options:

A hacky way to do it would be to create a new migration or edit the friendly_id migration to re-save all the profiles. This will do the trick with only one deploy. You shouldn't have any downtime with this approach, but you're heading into territory that can break migrations if you don't do it right. Future you might get frustrated with this hack, but it's certainly the easiest solution.

Another way to do it would be to create a rake task that you can run with Capistrano that runs the profile save. Or simply SSH into the server and run that code in the Rails console after deploy.

The ideal solution (if you need absolutely 0 downtime) is to figure out how half-deploy the update. Basically migrate the database and make save all records (and any new ones) with the new slug code but don't update the controllers to use the new IDs just yet. Once you've deployed that code safely and all the records now have a friendly_id, you can then do a second deploy that changes the URLs everywhere to use the new ones. This is obviously much more involved, but a common practice when you're doing things in production that can't have any downtime.

Get as complicated as you would like to with it, but you're probably fine just deploying the changes and running the save in an SSH rails console if you don't mind a few seconds of possible broken links. That's usually what most people do until they have tons of traffic.

I think most of the time you'll need to do about 3 things:

1. Share the ?ref=LKSJDFLKJSDG in the url where that's some unique code per user saved on the User model
2. When someone visits the page, just stash that in a cookie, preferrably the session so it can't be tampered with
3. Upon registration/checkout, check that cookie by looking up the referral user to see if you can find one that matches. If so, record the referral and whatever else you want to do with that.

How do multi-tier programs work?

I can definitely make a video for you on that. I'm moving in a about 2 weeks, so I'll put that on the schedule to record shortly after I get settled! :D

That would be cool. I've had to build a basic affiliate program in the past several times. I'll usually make it from scratch, but there might be some gems for it.

Ever seen this one? https://github.com/alexlevin/rack-affiliates