Chris Oliver

Hey Ted,

If you upgraded, you probably need to uninstall the gem and reinstall it so that it compiles with the new Mojave libraries.

If you have trouble installing it from scratch, see this thread: https://github.com/brianmario/mysql2/issues/1005#issuecomment-424786695

Filter chain halted as :doorkeeper_authorize! rendered or redirected

That means that your API key was not passed over or not valid.

This would be slightly slower, but what if instead of opening the modal on page load, you make an AJAX request to retrieve the value of @show_modal, and then depending on the response, you open the modal?

That way you're not trying dealing with any cache related things at all.

Try adding some JS to hide the modal on the turbolinks:before-cache event so it doesn't ever get saved when open.

Yeah, and I recommend using cookie auth for in-browser API authentication. You might as well take full advantage of the browser's security if you've got it.

Correct, I did exactly as I said in the video at that timestamp:

All I did was run the Rails scaffold generator for Tweet rails g scaffold Tweet user:references body:text

Added Api::V1::TweetsController, with doorkeeper authentication and had it render the same views. As seen here: https://github.com/gorails-screencasts/oauth-api-authentication/blob/master/rails-oauth-provider-app/app/controllers/api/v1/tweets_controller.rb

You say you "created all of the files manually" but it says that the Tweet class is uninitialized. You either didn't create the Tweet model or you have something like Spring caching that hasn't reloaded it.

Something I'll probably add a some point soon now that Puma ships with Rails by default.

Puma is great too, but this tutorial is intended for beginners and Puma requires you to setup, run, manage, and monitor a separate process on the server independent of NGINX. It's just a lot less beginner friendly in production so that's why Passenger is the default. It's much easier to get up and running to learn the ropes and once you've done it successfully you can swap over to Puma if you like.

Hey Sebastian,

If you're using sqlite3 in production, you'd need to make sure the database file is stored in a shared directory and symlinked every deploy. You can do that pretty easily by adding to the symlink stuff in Capistrano.

Every deploy creates a new folder with your code in it, so you need to link the database to each one so they share it. This setup allows you to rollback deployments to previous releases if there is a problem.

MySQL or Postgres is definitely recommended for production though. They're designed for performance and having many users read and write to the database quickly. Sqlite is a file on disk so it is significantly slower and not something you'd want to run in production.

Event sourcing seems to be sort of similar to logidze, audited, and paper trail. Is that correct? Basically trying to record changes to a record?

Ah yes, that would break it too!

A small refactoring would be:

class UserValidator < ActiveModel::Validator
  def validate(record)
      site_users = record.sites_users.select { |su| su.marked_for_destruction? == false }

    if site_users.count < 1
      record.errors.add(:site, "must have at least one site available")
    end

    if sites_users.select(&:is_default).count != 1
      record.errors.add(:site, "must have exactly one site selected as default")
    end
  end
end

Hey Daniel,

Looks like there's just a temporary issue with Passenger's package as of last night. They're fixing it but here's a workaround: https://github.com/phusion/passenger/issues/2122#issuecomment-423355568

We ran into the same thing on Hatchbox and the workaround fixes it.

Yep, you can put your database credentials in there and reference them in your database.yml I think.

The fetch environment is useful because when you run cap production deploy it'll use production from there. And then it seamlessly supports cap staging deploy if you add a staging environment. 🙌

And yeah, it installs the gems inside the app folder, that way if you had multiple apps on the server, you wouldn't crash one if removing the other accidentally removed gems or something.

I still have the issue of adding new gems, but I haven't looked too hard to find a solution for it myself.

Probably the same issue.

Remember that count, size, and length in ActiveRecord are all different. Count always queries the database if I remember right. Size uses the counter cache if it can, but will count the in-memory items if they're loaded. Length always counts them in Ruby in-memory.

You probably want to use either size or length there to make sure you're counting the Ruby array, not the db query. (It would also probably be good to comment these nuances alongside the code so when this changes in the future you remember why you did these seemingly weird things.)

Reference:
https://mensfeld.pl/2014/09/activerecord-count-vs-length-vs-size-and-what-will-happen-if-you-use-it-the-way-you-shouldnt/

I think you need to use Capistrano's rake helper. Try replacing your execute line with:

        with rails_env: "#{fetch(:stage)}" do
          execute :rake, "db:create"
        end

They have a bunch of docs, but there's some details on the nuances here: https://capistranorb.com/documentation/getting-started/tasks/

Hey Thomas,

The main issue here is your default_site method I believe. Here's the problem:

Your default_site method issues a database query.

When your form submits, you actually are modifying the record (and nested records) in memory. When your validation runs, it needs to check against the in-memory nested records that you're submitting, not the ones in the database.

class UserValidator < ActiveModel::Validator
  def validate(record)
    if record.sites.count < 1
      record.errors.add(:site, "must have at least one site available")
    end

    if record.sites_users.select{ |su| su.is_default }.count != 1
      record.errors.add(:site, "must have exactly one site selected as default")
    end
  end
end

Changing it to this will do a check against the sites_users in-memory. You can leave your database query for default site as it does some extra loading for performance elsewhere I'm assuming.

Hey Philip,

Capistrano just runs bundle on the server. You can see it in the logs.

Gems can be installed in different folders, and Capistrano will cache the gems in a shared bundle folder in your repo's folder on the server. It can also load gems from outside that like the vendor folder or gems installed on the user or system level.

For some reason, I'm getting the same issue with Capistrano. If I add a new gem, it'll run the bundle command but it won't be installed on the server. I don't know why that is. It's caused GoRails to crash a couple times because of that.

We probably need to poke around the issues on Github to see if there's anyone else mentioning the issue: https://github.com/capistrano/bundler.

Also on the server, your gems won't necessarily be in your PATH, so you may have to run bundle exec rails c to run the Rails console.

I'd just throw some console.logs into your JS and see what's getting called and what's not. Then you can figure out what you are missing.

Hey Sebastian,

Your error is:

/home/deploy/apps/Blogapp/shared/bundle/ruby/2.5.0/bin/rake: No such file or directory - java

So maybe you have a dependency that needs Java installed. It looks like it's required for Yui compressor.

Make sure Java is installed on your server.

It looks like you spelled polymorphic wrong which might be why it threw that error.