Chris Oliver

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

That is a great idea. I've heard great things about Algolia and it's definitely easier to manage than running your own search service. I'll add that to the list!

Yeah this doesn't seem to have been updated in a few years.

Have you read Michael Hartl's Rails tutorial? It covers a lot of of the following aspects from scratch (which is what I'd probably recommend doing because it's fairly simple) This should be the chapter that covers that: https://www.railstutorial.org/book/following_users#cha-following_users

Normally you don't want to use the shovel << operator if you can help it. It's not entirely clear as to what it does, so I'd definitely suggest doing the alternate you mentioned.

    4.times { @attendance_sheet.attendances.build }

Build can also accept params, so you can pass in the user as you had in your original example if you wanted.

@team.users.each do |u|
  @attendance_sheet.attendances.build(user: u)
end

Awesome, good luck!

Hey Darion, sorry for the late reply! Got distracted with the holidays. :)

Devise overrides some of the URLs for /users like you mentioned (I think they do everything except index and show). You could just add the resources :users route because I believe Devise does not make a GET /users route so it would match with your resources and controller. You should be safe here as long as you're

The other option would be to namespace that route with something like /api/users which would be a way for you to separate out the two. It doesn't make for usable URLs in your app, but it might be a nice way to dedicate a controller entirely to the atwho behavior.

Thanks! I will be updating this to the official nodesource repo soon.

Yep! Just look up the button_tag arguments (can't remember them off the top of my head, but that will show you which arguments you need. It's really simple to migrate it.

You actually can't do this with submit tags because it generates an input field which doesn't allow HTML in the value. You must use a button, but it renders the same and also still submits the form so basically no difference.

I think you can just run "sudo apt-get remove passenger" for that.

Hey John,

You can absolutely make a method that adds the counts like that. You wouldn't be able to turn that method into a scope, because it's not returning a relation, but rather a number.

Also I'd suggest combining your where clauses for cleanliness:

# Convert
where(present: false) && where(reason: "Emergency Leave")
# to
where(present: false, reason: "Emergency Leave")