Chris Oliver

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.

That's progress! Sounds like you tried to create a subscription or charge without a credit card token.

On Heroku, you'll want your production section to load from ENV variables like you set. So you'll want your production section of your secrets.yml to look like this:

production:
  stripe_api_key: <%= ENV["SECRET_KEY"] %>
  stripe_publishable_key: <%= ENV["PUBLISHABLE_KEY"] %>

Double check that they're actually getting site then. So use the Rails console on your server to make sure you can access those keys in production from your secrets, and then print out the "puts Stripe.api_key" to make sure that it was set as well. There's something missing there that's probably small but important.

Hey! Sounds like you're just missing your keys in the production environment. Make sure you put your live Stripe keys in your secrets.yml file and that should fix that problem for ya!

Psh, that only happens like once every... day. 🤓

Similar to the Hacker News thread, I thought we might start up a thread for anyone looking to hire a Ruby / Rails freelancer or if you're a freelancer looking for work.

Please lead with either SEEKING WORK or SEEKING FREELANCER, your location, and whether remote work is a possibility.