Chris Oliver

Yeah, there's a lot of changes, I'll be announcing it all shortly!

@Alan, I added a reactions feature so you can give kudos to other people just like on Github issues. :D

I think you're generally going to struggle optimizing the number of allocations in this because your operation happens on every single user balance. It's going to allocate a ton of objects no matter what you do since you're loading every active one.

One optimization you can make is to pluck the active user IDs and query by that rather than loading up all those objects. I would also test to see if the in place mutation methods improve performance like so:

def self.all_users_gold_balances
  gold_gateway_id = Gateway.find_by(currency: "GLD").id
  active_user_ids = active_users.pluck(:id)
  user_balances   = Balance.where(gateway_id: gold_gateway_id).includes(:user).where(user: active_user_ids).pluck('balances.amount', 'users.account_number')

  user_balances.map! {|balance| array << {account_number: balance[1], gold_balance: balance[0].truncate(3)} }
  user_balances.sort_by! {|hash| hash[:account_number]}
  return user_balances
end

Yeah that should work. What cache key is that referencing in your logs?

You could include the filter and role in your cache key and save them as separate caches.

I would be somewhat careful with that because if you have a lot, then you're just filling up the cache storage with stuff that's likely to get blown away and you won't get any benefits from caching. Compiling a list of small cache snippets is super fast, so you might consider just not caching the list, but cache each individual item instead. The compilation of everything will be fast enough and can save you on some cache storage space if you notice bloat saving all the different copies.

If you've got a real Actionmailer config setup to hit a real smtp server, you can have it send real emails in development. If they aren't arriving, then you will want to double check your configuration to make sure that it's authenticating correctly and you see the emails being sent from your email provider logs.

Yup, you can either use JS to hide / show functionality or you can also include the role in the cache key if you want. That will create caches for each role meaning you'll use more cache storage, but can cache each version separately. I'd still recommend using JS to hide / show things so you only have one cache per item.

You have to make sure that you symlink the paperclip uploads folder each deploy so your files don't get lost. They create a folder on your server and then every deploy the Rails app is deployed to a new folder, meaning you lose those old files.

Add this to your config/deploy.rb and it will symlink the directory each time so your files won't disappear.

set :linked_dirs, fetch(:linked_dirs, []).push('public/system')

I may or may not cover Sidekiq in that episode. The trick is as long as you use ActiveJob, there's no difference if use sucker_punch or Sidekiq to power it. They'll work exactly the same except that with Sidekiq you just need to make sure the Sidekiq process is running. ActiveJob provides that nice abstraction layer on top so that your code is exactly the same and you can swap background workers easily.

Nothing too special, just toss them in a Bootstrap modal and that's it. :)

LOL! It might have been cached or something, awesome that it's working now! :D

Haha no worries! Want to upload the file for me to look at what you've got?

@Jacob, the markdown preview is different than the server side renderer so things are slightly different sometimes.

Yeah, that's my bad on these. They have -part-X appended to the end of the filename instead of updated numbers on the beginning because I did a weird exporting process on these compared to my normal ones.

The missing semicolons are okay, the browser handle that just fine. The missing ) doesn't sound right, because that would actually cause the JS to break if that were the case. That could be breaking your code by adding that in, or you've got an extra opening ( somewhere.

I updated the file with the semicolons for ya: https://github.com/gorails-...

Agreed Jacob!

And yeah you're right about the HABTM table name. The thing about HABTM is that you don't get to ever interact with that table in the middle...so imagine you needed some meta data, like a quantity of the product in each venue...well you're SOL with HABTM. If you have an explicit model as a join table, and do has_many through, then you can add extra columns in like a quantity and do a whole lot more with it. In most cases I find it's better to be explicit about that join table than using HABTM for that reason. Guess I should do an episode on this!

Oh I gotcha now! Yeah that makes sense. So then you are correct having both the venue_id and product_id on that table. The naming I believe is what threw you off because you actually need a bunch of records of the BackBar per venue.

class BackBar < ApplicationRecord
  belongs_to :product
  belongs_to :venue
end

class Product < ApplicationRecord
  has_many :back_bars
  has_many :venues, through: :back_bars
end

class Venue < ApplicationRecord
  has_many :back_bars
  has_many :products, through: :back_bars
end

# controller
@products = @venue.products

Yeah, for a many-to-many relationship, you'll actually need a join table and has_and_belongs_to_many will use that to connect everything. Thats the only way for your backbar to have many products and your products to belong to many backbars.

Yeah, sounds like your relationship is backwards in the database where a BackBar belongs_to :product, when it should actually be a Product belongs_to :back_bar.

Depending on what you want to do now, you can use something like this to work with their API: https://github.com/gimite/google-drive-ruby

You'll just pass in the access token you received from omniauth into this library to hit their API.