Chris Oliver

You bet! I am planning to do one on notifications to specific users as an example.

Hey Drew,

You'd just create a model like ConnectedAccount to store the details and associate them with your Shop model.

Monday's screencast actually walks through this a bit using OmniAuth params. You can pass the Shop's SGID to OmniAuth and then look it up in the callback controller.

<%= link_to "Connect Facebook", authorize_facebook_path(shop: @shop.to_sgid(for: :connecting)) %>

Then your controller will look that up:

class OmniauthCallbacksController < ApplicationController
  def create
    sgid = request.env['omniauth.params'].fetch("shop")
    shop = GlobalID::Locator.locate_signed(sgid, for: 'sharing')
    shop.connected_accounts.create!(
      # omniauth.auth details go here
    )
    redirect_to @shop, notice: "Connected!"
  end
end

If you use an Ubuntu repository for it, then it will install security updates automatically and bugfixes when you configure your server (which you should do on a regular basis like once a month).

Yep! Hatchbox will automatically set PORT different for each app. 👍

Shouldn't be any extra setup. Are there any specific setup things you're thinking about?

Moving from 1 server to 2 servers requires you to move DNS and your database to the new server. So you will probably have some downtime, but it's not hard to do. You can put the app in maintenance mode while you do it so that users know you're migrating.

Hey Ali!

It's up to you really. If you want to save money, deploying to the same cluster is the way to go.

If you plan to scale the apps up independently in the future, you would want to start with 2 servers and deploy the apps separately. That way you can add more servers to one cluster, but not the other.

That's usually how I decide if I want 1 or 2 different clusters. Does that make sense?

The invisible_captcha github repo's README has instructions. 👍

Hey Dan!

I would pretty much do the exact same thing. The only change I would probably do is use ActionText for the posts instead of a text column. That way we can take advantage of Rails's built-in rich text fields.

If you don't need / want that, then I would do the same as it was basically.

Wonderful example in the wild. Thanks for sharing!

I didn't know about this. That is super cool!

The enterprise_script_engine executable ingests the input from stdin as a msgpack encoded payload; then spawns an mruby-engine; uses seccomp to sandbox itself; feeds library, input and finally the Ruby scripts into the engine; returns the output as a msgpack encoded payload to stdout and finally exits.

I will have to try this out sometime. Thankfully you've got Shopify to help lock this down because it sure seems like it could be dangerous!

It's really simple, so you won't have any issues with it on Heroku or Cloudflare. There's no Javascript or anything to worry about.

Under Feature Preview, you can enable "New Code Search and Code View (Beta)"

Check out this: https://github.com/railsadminteam/rails_admin/issues/2990

You should be able ot put this in ~/.irbrc

IRB.conf[:USE_AUTOCOMPLETE] = false

Or you can open the rails console / irb with --noautocomplete

rails console --noautocomplete

irb --noautocomplete

https://gorails.com/deploy/ubuntu/22.04

Renews at the same price. 👍

You should be able to just modify the esbuild command in package.json to run twice.

esbuild app/javascript/application.js --bundle --sourcemap --outdir=app/assets/builds --public-path=assets && esbuild app/javascript/admin.js --bundle --sourcemap --outdir=app/assets/builds --public-path=assets

In no particular order:

• Fly.io
• Render.com
• Hatchbox.io (I built this! 🤓)
• DigitalOcean Apps
• Railway

Hatchbox.io is a bit different because it runs on your server(s) and you only pay for servers. If you deploy 2+ apps on a single server, you save money because most hosts charge per-app fees.

We use Wistia. It's expensive and probably cheaper done with S3 or similar.

Check out the Ruby on Rails for Beginners course and then the Series pages to learn specific Rails topics.