Chris Oliver

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! :)

Hmm, well then it isn't as easy of a solution. ;) Which line of the view is it tripping on then? What's your stacktrace look like?

Your first collection_select for @team, is that variable an array? Only arrays (or enumerable objects) have a map method. The map method is called internally inside the collection_select, so if that happens to be just a team record, then that could be the problem.

You'll either want to make that variable an array or adjust that accordingly to how you want it to work I think.

Unfortunately, the current_period_end will be the end of the year, not the end of every month on a yearly plan. You won't get that attribute updated each month to enable your users to have a subscription that acts monthly but is actually yearly.

I think both of those webhooks will fire at the same time for subscriptions. The invoice is generally better because it's tied to the subscription, but the charge attributes might also link to it.

I forgot how expensive Baremetrics was. That's kind of ridiculous. I've been using BeStunning for GoRails and it does a pretty decent job (if you can overlook it's terrible design). :)

And yes, it'll listen to the failed charges via webhooks. You could pretty easily build your own solution and save some money. That's probably my plan for things in the future.

That's a good question. I've never actually checked into that. You should ask on the Github Issues for Devise. They'll definitely know the answer to that.