Chris Oliver

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")

You might just need to add a float: right to the label with some CSS which may do the trick.

The other alternative I can think of would be to just mix and match your simple form and normal form html tags. I usually do this when I want most of a form to be simple form styled but one field needs to be custom. It's usually easiest to just write up the form html like I would with a regular form_for and simple_form will let you mix and match like that. That could be another approach that would do the trick.

Subdomains are definitely great if you want them separate. If you're building something public, you could do basically what you posted originally, although it's sometimes nice to also set the schools module as well. That will just help you organize your controllers and views nicely.

resources :schools do
  resources :forum_threads, module: :schools do
    resources :forum_post, module: :forum_threads
  end
end

And this would generate urls like /schools/my-school/forum_threads/i-have-a-question with /forum_posts tacked on the end as a route that you'll mostly just interact with through forms.

Apartment is definitely awesome if you want to separate out everything (so it's not as easy to just switch schools in the url). The way this would work is that you can use subdomain helper with Apartment. It would select the right database schema for you and keep everything separated out at the database level. You wouldn't need school_id on your forum threads or anything with that and your routes would simply be:

  resources :forum_threads, module: :schools do
    resources :forum_post, module: :forum_threads
  end

Thanks Ryan! I can't remember if I covered it in-depth enough in this episode, but I should do another Vim related screencast going a bit more into it all.

Yeah, with the new token system, this might be a piece of data you can get somewhere. I'd ask on the Refile Github issues and see what you find out. If you find a solution, let me know!

I would love that! :)