Chris Oliver

The old episodes are still there. This is just a new series digging deeper into designing API clients. 👍

Try setting it to use host: 127.0.0.1 in database.yml.

By default, it's going to look for the Unix domain socket, which means a file on the linux system and not the port from your Windows PostgreSQL server.

The number_to_currency helper is useful for this and I highly recommend the money gem.

To start redis now and restart at login:

brew services start redis

Errors are definitely a bit of a pain. I liked this approach from StackOverflow: https://stackoverflow.com/questions/5370697/what-s-the-best-way-to-handle-exceptions-from-nethttp

ALL_NET_HTTP_ERRORS = [
  Timeout::Error, Errno::EINVAL, Errno::ECONNRESET, EOFError,
  Net::HTTPBadResponse, Net::HTTPHeaderSyntaxError, Net::ProtocolError
]

begin
  your_http_logic()
rescue *ALL_NET_HTTP_ERRORS
  …
end

A constant is faster to lookup since it's saved, but a method that returns the string would work fine too.

Also we just published the generators episode!

He's always causing a ruckus or being lazy. Nothing in-between! 🐈

You'll want to do that for your actual integrations, for sure.

These are just some tests to make sure we've implemented the generic HTTP calls correctly. That way our real API clients don't have to worry about testing the underlying HTTP methods, they can focus on everything else.

Glad to hear it! I've been trying to make a point to cover that in videos more often because I think that's the biggest superpower you can learn as a developer. 💪

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.