Chris Oliver

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.

Yeah exactly. I would create my own controller and pass over the user_id which can then look up the user and associate them. Since the user might already have an account, you might just send them an email notice saying they now have access rather than an invite since they already have an account. You could also do an approval process there before it's finally accepted, kind of up to you.

Getting closer and taking a walk always helps! :)

I'd just double check in your Rails console that the ENV vars are set like you want and then make sure your S3 config is set to use them after that. Possibly one of the two is slightly misconfigured.

1. Those folders are automatically created in your bucket when you do a file upload. I was doing testing before the episode to make sure everything works so you might notice some differences. No problem if they aren't there, as they will be made for you.

2. I left a note and included a link in a new comment to the regions you have to specify. Each of them has a name, but then the region piece is the one you need to use here to configure. The one for Syndney looks to be "ap-southeast-2" so make sure you've got that set and that should work.

3. I didn't include the cached attachment data plugin in this episode. It's a separate module you can include: http://shrinerb.com/rdoc/cl...

Hope that helps! :)

Here are the list of AWS regions if you are running into errors with the invalid "region" option: http://docs.aws.amazon.com/...

For Syndey, you should have that set to "ap-southeast-2" I believe.

Ohhhh! My bad! Hahaha I was assuming you were using apartment. This all makes a ton more sense now!!

It's an easy one to overlook so I'm glad I could help! :)

It's hard to say. It could be that it's not actually working on localhost how you thought, that's usually what happens. You should double check to make sure that a credit card token is being sent over from the JS and confirm that you can see it server-side in the logs. It sounds like something is missing there.

You're doing alright. As for the error, I'm not sure, could come from a bunch of different things. I would try creating a new user and trying to checkout in production just so you have a fresh user to work with. If it doesn't work then there's probably a bug in your code somewhere.