Chris Oliver

You're all good, easy to overlook those things sometimes! :D

Like the error mentions:

07:55:57 sidekiq.1 | Error connecting to Redis on 127.0.0.1:6379 (Errno::ECONNREFUSED)

Make sure you have Redis installed and running. Anytime you have a connection refused for any service like Postgres, MySQL, Redis, etc, it means it's not running. 

Thanks for the heads up! What a pain in the butt.

Since the models are shared with ALL uploads, if you extend say ActiveStorage::Attachment, all attachments will have that functionality even though they might not need it.

ActiveStorage is quite a different approach than the other file uploading tools like Shrine. Plus it's fairly early right now and some of the functionality only works well with images (namely the variants stuff) which gets annoying if you want to do things like extend AS to make for transcoding video easier or whatever.

Hey Aaron,

You just put the queues in your config/sidekiq.yml file. 👍

https://github.com/mperham/sidekiq/blob/master/examples/config.yml

Hey Lee,

You need to include the other lines as well after the error because that's what we use to debug what went wrong. Without it, we can't tell what happened.

Hey Aaron,

At a high level:

You'd need something to sort by. You could modify the ActiveStorage models and add a column to sort by.

Or you could just keep an array of the attachment IDs for those on your model.

Either way would work, but I would probably prefer the second option. Once you have the attribute to sort by, you just grab the attachments order by the sort order that's saved.

Hey Stephen,

So what I did was mimicked Github's Notifications section on Issues. You can see it on the forum here at the bottom of the right sidebar.

Here's what my model looks like. Basically, this tracks who opts in and who opts out. Then we can send the notifications accordingly. 

```ruby
# == Schema Information
#
# Table name: forum_subscriptions
#
#  id                :integer          not null, primary key
#  forum_thread_id   :integer
#  user_id           :integer
#  subscription_type :string
#  created_at        :datetime         not null
#  updated_at        :datetime         not null
#
# Indexes
#
#  index_forum_subscriptions_on_forum_thread_id  (forum_thread_id)
#  index_forum_subscriptions_on_user_id          (user_id)
#

class ForumSubscription < ApplicationRecord
  belongs_to :forum_thread
  belongs_to :user

  scope :optin, ->{ where(subscription_type: :optin) }
  scope :optout, ->{ where(subscription_type: :optout) }

  validates :subscription_type, presence: true, inclusion: { in: %w{ optin optout } }
  validates :user_id, uniqueness: { scope: :forum_thread_id }

  def toggle!
    case subscription_type
    when "optin"
      update(subscription_type: "optout")
    when "optout"
      update(subscription_type: "optin")
    end
  end
end
```

When sending notifications you'll want to build up the list of users like so:

1. All the users who posted in the thread
2. Add all the users who opted in to receive notifications for the thread
3. Remove all the users who opted out
4. Profit???

Hey Graeme, 

Did you see the Trello series? We cover moving between multiple lists in that. It'd be slightly different code since it's in Vue.js but the concept would be all the same. You would need a List model and association to keep track like you mentioned.

Try starting with the episode #1.

Bagus, it should be called "software-properties-common" now or "python3-software-properties". Making an update for that.

Great to hear Dan! Let me know if there are any other features like this you'd like to see!

Hey Abram,

Not really at the moment. Most people post ideas here, in Slack, or email me. That's something I should build though.

Have any good ideas to share? :D

Oh gotcha. Well I'd recommend using the Support tab in Hatchbox instead to file tickets so we don't accidentally share things publicly on the forum.

I'll take a look at your account.

I don't believe that your IP address can start with a 0. You should make sure you have the correct IP.

All you do is grab the signing secret from your Stripe account and set that variable like you would do with the other keys. Link to how to use it is here: https://github.com/integrallis/stripe_event#authenticating-webhooks-with-signatures

I'll do a quick episode on this shortly!

Welcome! 👋

I don't know of any tutorials that do exactly something like this, but it sounds kind of like survey software maybe?

A few of the details will depend on how you want the app to work. Do you want ot have free form text answers for the questions or multiple choice or something different?

Will the questions be the same for everyone? Will they be configurable (like you can add / remove questions dynamically or will they always be the same)?

For the user dashboard, are you looking to show the same questions and the user's selected answers? Or something else?

Let us know and we can guide you through what you'd need to do!

🙌 You're welcome!

As for the forms, you can just set the site in a hidden field. @page = Page.new(site: "google") for example.

Remember that your controllers don't have to directly map to models so you could have a controller for Google, separate from your Facebook one, and so on. Then you can have views that are unique so that you can have different designs, instructions, etc for each one.

Hey Rich,

I wouldn't worry too much about having a "messy" models folder. If you had 50 models, it might be a concern, but you don't currently have many and it's easy to move things around later.

What is the purpose of ReviewSite? It seems like an unnecessary model.

User
has_one :business

Business
belongs_to :user
has_many :locations
has_many :facebook_pages, through: :locations
has_many :google_pages, through: :locations
has_many :yelp_pages, through: :locations

Location
has_one :facebook_page
has_one :google_page
has_one :yelp_page
has_many :reviews

FacebookPage
belongs_to :location

GooglePage
belongs_to :location

YelpPage
belongs_to :location

Review
belongs_to :location
belongs_to :customer (or something)

ReviewRequest
belongs_to :customer
belongs_to :business (if you want to attach it to a business, could also be location)

As you can see here, the concept of a "page" seems repeated so you may still want to consider how truly separate they are.

Business
has_many :pages

Page
belongs_to :business
- site ("google", "facebook", "yelp")
- url
- number_of_reviews
- average_rating
- extra_data (json column, can be fully unique to each site)

Then you could just write other Ruby classes for handling the unique API situations. For example, to get the correct API client, you'd do something like:

def client
  case site
  when "google"
    GoogleApi.new(token)
  when "facebook"
    FacebookApi.new(token)
  end
end

This would be a more generic way of approaching things. You can have a json column to store any data that's unique to each business instead of making separate models for each.

Personally I would probably take this approach with generic pages. I haven't seen anything that seems to prevent taking this approach. This is how I handle the different APIs for Hatchbox.io btw. Servers on Hatchbox are like Pages and Reviews in your app. Sure they may be on a different service, but I can still store the generic information I care about in a single table and just keep track of which service it is. Then I write Ruby classes to handle the specifics and store the data on the model. Unless the data is vastly different, you will probably be best off with the generic Page like I'm doing with Servers. You can have a json column to store your extra information that may be unique to each site. If there is a lot of unique information for each Page, then definitely split up the models.

Hey Rich,

The best advice for these types of questions will always depend upon what you want to do in the future with your app. Will you be treating Facebook, Google, etc reviews as mostly the same thing? Sure, you'll need to know the site and page the review was on, but will you have specific integrations with each site?

If they will stay mostly similar, then I'd keep it as a single model and just store the site like "google" "facebook" etc as a column and the url for the page. Then if you ever do need to add some more specific things you can just say "okay this is a google review, let's create a Google API client and sync any changes".

If you plan on having different functionality for each review type, then separate models make more sense. You can then add functionality that's unique to each site (maybe they have a lot of different attributes you want to store).

So it'll depend upon what you want to do going forward. You probably know that best since you're designing the product which means you'll probably have a better idea of which one will be most fitting with your product.