Chris Oliver

Yup, once you've gathered your categories that have products efficiently, you can preload them with includes as well.

Great idea. The google API is definitely not the simplest API to work with in Rails because it's so generic. I will definitely try to cover it soon.

For some help in the meantime, the main things you're going to need is to make sure that your scope is set properly for Drive authorization. That will make sure once you have keys you can access Drive with them. I would probably recommend using this library over the google one because this does the same thing but is setup nicely to work within Omniauth which Devise supports. Configuration is super easy and will save you a lot of time: https://github.com/zquestz/omniauth-google-oauth2

Thanks Matt! That means a lot. :D

Yep, exactly! You can also add an index on that table that includes those two columns in order to speed up the query this validation executes to check validity. That'd be the only other thing you'd probably want to add.

Just render them in your navigation snippet so that they're already there when the page loads. It adds query time which slows down your page load, but won't make them appear later. The other option is to just style your CSS with that space already taken up so the view doesn't shift and cause your eye to look at it.

One thing you could do is to set up a counter cache on Category so that you can store the number of products on it. Then when you query you can query for Category.where("products_count > 0") to improve your query and remove that if statement in the view.

Main reason is it's such a simple feature, no need to use a gem. Always great to have one less dependency, less likely to break on upgrading Rails versions, etc. And the benefit is I can customize it and use it exactly how I want.

Thanks man! Fixed that and glad you're enjoying the Shrine episodes. :D

You're making super good progress. And I know right? I started with GW-Basic, VB6, some C++, Java, back in my early days and it wasn't till I found Python that I felt like I could actually be productive and build full applications myself. Rails sped that up even quicker!

Haha! Doing my best to make GoRails do that. 😉 The trick is when you've made as many mistakes coding as I have over the years...eventually you know where to look really fast to fix things.

I believe you just want to use a plural resources on variants like so:

resources :products do
  resources :variants, module: :products
end

That will give you the urls for the individual nested objects so you can access and edit each of those separately.

Whoops, that shoulda been "rails generate devise Buyer" :)

Absolutely. That will work fine, just have to remember that is all. :)

That's a feature I was literally just starting to write tonight. :)

You would do "rails generate Buyer; rails generate Seller;" and so on. Then you'd wnat to use the devise scoped views generator which will make separate views for each type of user. They have instructions on that in their readme.

Great question! I would say that when you submit the search, you can just save the params to cookies. Something like this:

<%= check_box_tag 'genre', 'rock', cookies['genre'] %>

#controller
cookies['genre'] = params[:genre]

And then when you render the form again you can set the checked option to the value of the cookie (like you see here as the 3rd argument of check_box_tag).

You could also write to your cookies using Javascript if you wanted to keep it entirely in JS. You'd have to check the boxes using JS in that case.

Try this episode, I talk about my Vim setup here: https://gorails.com/episode...

If I'm understanding correctly, you have two options:

1. You can create 3 separate models with separate login pages. This is probably the easiest, but it requires users to register separately and they're treated as totally separate accounts (you could have an account registered with each one of those using the same email and they will be 3 separate records).

In this case, you would need migrations for each table in the db that people can register as.

2. You can create just one User model and use Single Table Inherintance to save the different types of users to one table. I believe this would only let you use an email once, but you could create an instance of the different types of users to give them features from those. People don't use STI that often, but it can be helpful sometimes.

This would only need migrations for the one table.

I don't agree with that. Code in your controller isn't magically a bad thing. It's only a bad thing when it becomes overly complex. Having one query in your controller is actually a requirement for this method. If you extract it out, you still have to save the query in the controller but now you've hidden away the actual query which actually makes this more complicated with no benefit. Making a method arbitrarily to "clean up the controller" isn't actually a good reason to do this.

A good reason to refactor is if if you are using this query multiple places in the app and want to keep them consistent with each other. In that case, then yes, you do get value from abstracting this because you can change the functionality of each use of it all in one place.

class Article < ActiveRecord::Base
  def self.with_brands(brand_ids)
    scoped.where(brand_id: brand_ids).includes(:brand)
  end
end

# controller
@articles = Article.with_brands(brand_ids)

You can inspect the JS response in the Network tab in the console and then copy paste that into the Javascript console. Might be a typo or something simple.