Chris Oliver

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.

That's interesting with regards to scopes. I think that doesn't have any bearing on your issue though, because the Apartment gem is not using scopes to separate out your tenants, it's using postgres schemas (you're using pg right?) which makes the records in the other schemas unqueryable entirely because they aren't even visible unless you're in the global tenant. Does that sound right?

You can set up the association on the user to has_many through:

class User
  has_many :brands
  has_many :articles, through: :brands
end

And then you can access them directly and it will be auto-scoped for you:

current_user.articles

The performance on that is probably similar to writing and committing records one by one on a csv import vs writing a transaction and committing everything at once. You'll have a lot more speedups writing everything in bulk.

Are you sure that the scope thing is actually going to solve your problem in Rails 5? I thought we determined that wasn't going to help as it wasn't related to your tenant issue?

Jacob's the one that did the hard work though. I just had to tweak his answer a little bit. ;) He's the one that deserves cake 🍰.

I believe you want @articles = Article.where(brand_id: brand_ids).includes(:brand) which will load that association. Pretty close to what Jacob said, but you need to reference the association in the includes.

Then when you print out the articles, you can say

<% @articles.each do |article| %>
  <div>
    <%= article.brand.name %>
  </div>
<% end %>

This should be efficient because it will make two queries and preload the brand association on each article.

I don't believe there are any necessary changes for Heroku. You should be able to just deploy it, making sure that your allowed request origins match the domain you're running on.

Yeah, you'll probably want to crop the pictures to a standard size in the processing phase.

The problem with using only CSS is that your user might upload a 10MB image and you don't want all your users having to download that, so it's best to always crop to a few standard sizes to prevent that from happening so your site can continue being fast.

You can set like a standard avatar size (say 100px x 100px) and then resize it with CSS so the image can be displayed at various sizes but reused from the browser cache.

React stuff is coming soon! :)

Like Janko said, you can do uploads to your server or to S3 with Shrine just like you would with Carrierwave. Shrine can do everything you could do in Carrierwave (and better in my opinion) so I would recommend using it for everything.

My recommendation would be to never setup your files to upload to your server's filesystem unless it's a hobby project. You'd have to migrate the files once your harddrive is full and that's no fun.

With S3, you have two options:

1. You can upload your files to your Rails server and Shrine will send them over to S3.
2. You can directly upload files to S3 like I showed in this video.

The first option is simpler because you just have to configure Shrine to do the upload to S3.

Direct uploads use your user's browser to upload straight to S3 and it skips your server. That means the direct uploads are faster, but they're a fair amount more work (like you see in the video).

The simplest and best option to get started is to simply use S3 (#1) for both the cache and store for Shrine. You don't have to build any of the Javascript stuff right away and all your uploads will be saved to S3. When you're ready, you can add in the Javascript portion for direct uploads in order to make them upload faster. Since you'd already be using S3, it's a simple change this way.

It's missing setting the last_read_at when you join a new channel. Should be in the chatroom_users controller.