Chris Oliver

Most of us prefer the Pundit gem for that. There's an episode on it as well. 👍

Not quite yet! I'm still working on it but keep getting distracted with other things. I'm hoping next week I can dedicated a lot of time to getting it all figured out and then re-record the course after that.

Moving a database isn't so easy. You typically incur downtime, or you have to setup streaming replicas and things that are complicated.

1. You can either pay for DigitalOcean's managed load balancer, or let Hatchbox create one. You probably just need a $5/mo server for that.
2. If you use their managed database, it's not a server you'll have in Hatchbox, so it doesn't count. They also have managed Redis now too that you could use if you wanted. Having managed databases that you don't have to worry about is really really nice. Hatchbox doesn't do managed yet (and we might never need to if these services keep popping up), so those are worth looking into.
3. The number is however many servers Hatchbox creates and runs for you.
4. Depends on how many background jobs you plan on running, but yes, seems good.

Not currently, but I'm actually working on one! What's your knowledge about web development so far? Have you learned anything else or are you starting completely new with Rails?

Check out this series: https://gorails.com/series/embeddable-javascript-widgets-with-rails

Looks like I accidentally changed the naming scheme for that episode. 🧐

Pretty much has to be an external service, since you want it running independently of your app. And, so you don't have to also monitor and run your own uptime monitoring, most people just pay for something.

I like and recommend HoneyBadger.io will do uptime checks, check-ins, and error monitoring all-in-one. Nice to have those features together in the same app rather than paying for multiple things. They have a free solo-dev option that comes in handy.

You've also got tools like Pingdom that will do performance / uptime. Lots of other options out there too.

Since it says your comments table has no post_id column, you should check your migrations and make sure you didn't forget to add the column. :)

Just to re-iterate here, we had a brief discussion of this on Twitter.

For GoRails, I simply removed links to the old plans when pricing changed. I created the new plans in Stripe and linked to them on the pricing page in the app. Existing customers stayed on the old plans and new customers could only subscribe to the new plans.

Everyone gets grandfathered in that way, and any special cases where I might need to set someone up on the old grandfathered plan can be done manually in the backend.

The payments library we're using for Jumpstart Pro, Pay, doesn't handle marketplaces right now. You'd need to implement Stripe Connect yourself instead.

At some point in the future, we'd like to support that, but we're upgrading everything to be SCA compatible first. Then we will probably look into marketplaces, but since we support both Stripe and Braintree, that's a bit harder to make them both work similarly, especially for marketplaces.

There are a couple options called discard_day and discard_month that you could set to true to hide them and only display the year. All the options are listed here: https://api.rubyonrails.org/v5.2.1/classes/ActionView/Helpers/DateHelper.html#method-i-date_select

I would add a validation to the TeamMember for that.

class TeamMember
  belongs_to :team
  validate :team_has_owner

    def team_has_owner
      error.add(:base, "Team must have at least one owner.") unless team.team_members.where(role: :owner).exists?
    end
end

Hey Louie, you may need to explain more of what you're trying to build. Typically you don't want to have multiple Devise models, just a single User with roles instead. It's much easier to work with.

I don't think a whole lot has changed. They have instructions for using it with Webpacker now, but it seems mostly the same to me. Are you talking about anything specific?

RestClient is pretty good for accessing an external API, although sometimes people have built an wrapper around the API to make it easier to work with. You might check rubygems.org to see if you can find an API wrapper gem.

Then once you get the information back from the API, you probably want to save it in your database.

And to render it in Open Street Maps or something similar, you'd use their Javascript APIs to load in the routes.
https://wiki.openstreetmap.org/wiki/Routing

I'm doing this in a table in the form:

 <% I18n.t('date.day_names').each_with_index do |day, wday| %>
            <td class="day">
              <div class="form-group">
                <%= form.select :"#{day.downcase}_opens_at", time_select_options, label: "Open Time", include_blank: "Closed" %>
              </div>

              <div class="form-group">
                <%= form.select :"#{day.downcase}_closes_at", time_select_options, label: "Close Time", include_blank: "Closed" %>
              </div>
            </td>
          <% end %>

That creates selects for each time of day. I have this helper for those times.

module ApplicationHelper
  def time_select_options(step=15)
    tod = Tod::TimeOfDay.new 0
    times = []
    96.times do
      times << [tod.strftime("%l:%M %P"), tod]
      tod = tod + step.minutes
    end
    times
  end

Then it gets serialized by Time Of Day gem in the model.

class Business
  serialize :sunday_opens_at, Tod::TimeOfDay
  serialize :monday_opens_at, Tod::TimeOfDay
  serialize :tuesday_opens_at, Tod::TimeOfDay
  serialize :wednesday_opens_at, Tod::TimeOfDay
  serialize :thursday_opens_at, Tod::TimeOfDay
  serialize :friday_opens_at, Tod::TimeOfDay
  serialize :saturday_opens_at, Tod::TimeOfDay
end

Here's some quick psuedo code:

class Fleet
  has_many :cars
  has_many :trucks

  validate :same_type

  before_create do
    self.fleet_type = "Car" if cars.exists?
    self.fleet_type = "Truck" if trucks.exists?
  end

  private

  def same_type
    if cars.exists? && trucks.exists?
     errors.add(:base, "All items in fleet must be of the same type")
    end
    end
end

Not built-in. You could set it before_create and check the first child model type and use that, and also validate that they're all the same type.

I would probably just add a fleet_type column to the fleet that keeps track of which is allowed: Train Car, etc. Then you can use it for validation against the associated models to make sure they're of the correct type.