Chris Oliver

There are a bunch of ways you could tackle this. One of the neater ones is actually with ActiveResource where you can treat a remote Rails app as if it were in the database (for the most part). It got extracted to its own gem that still seems maintained. It's pretty slick if you use it, but you gotta follow the Rails conventions which not everyone wants to do.

Another option could be building 3 separate Rails apps that all use the same database server and database. Each one could then point to that and consume it as if they were inside the same Rails app. You would share your model files across the apps migrations would be accessible to each one of them. Basically for this you'd just simply share the model files and the database.yml between apps. That's about it. This is probably the easiest option, but you'll have to be aware of some of the annoyances of copying over validations for a model into every app. You could of course extract the models to a gem you share and require that gem in each app as well. Or as a git submodule so you wouldn't have to mess with gem updates.

And of course, the custom API for this is the last option. You'd hit that API from your apps instead of the database. It could be the sole place connected to the db to control any changes and the other apps could consume content from it. They might have their own ancillary databases to store extra stuff in that the others would never need. This one is probably the most work of them all, but could give you the most flexibility between them all.

The good thing is you can definitely start easy here with 3 separate apps that connect to the same db and as you grow migrate your way into an additional API service if you want. I would definitely start simple with this at first and start expanding it as you need.

Yeah, good ol' CORS. You can add rack-cors to your gemfile and create this initializer to take care of it:

# config/initializers/cors.rb
Rails.application.config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins '*'

    resource '/assets/*',
      headers: :any,
      methods: [:get]
  end
end

Basically what's happening is you're including now your stylesheets from a different domain (cloudfront's domain, not yours anymore) and the browser won't allow it unless you tell it that it's okay.

Yeah, you could do that, but also coffeescript does much more than adding classes to Javascript. It added a lot of other things that ES6 has now come to include (like finally a decent way for string interpolation) so ES6 what people will generally be using these days over coffeescript anytime. Mind you this video is 2 years old.

I've been meaning to do a screencast on this at some point.

This tutorial is pretty good for walking through all the steps needed to setup Cloudfront: https://www.happybearsoftware.com/use-cloudfront-and-the-rails-asset-pipeline-to-speed-up-your-app.html

For the most part it's super easy with Rails since all you need to really change is the asset_host config option. Rails will still serve up assets so that Cloudfront will always get the latest copy. It works really well.

Well, the reason is because that is not supported in any browsers right now. See: https://developer.mozilla.o...

You can only use modules if you're using a transpiler like babel / webpack to convert it to code the browser can understand today.

I'm not up to speed with much of the json(b) column indexing. This talks a bit about it briefly: https://blog.codeship.com/unleash-the-power-of-storing-json-in-postgres/

Ah ha! So EAV is what that's called. I had always known about this but never know what to call it. :)

It looks like the eav_hashes gem might be worth a shot since it's been updated relatively recently. There might be a fork that's been created more recently that has some other fixes or new features with someone maintaining it.

One alternative that I'd suggest looking into is actually the json or jsonb columns in Postgres. They are similar to the serialized text columns, but they're fully queryable. It's a little different but may be worth checking out as a solution as well.

I need to read up on EAV a little bit more myself.

Do you know if there were any recent changes with times and dates in Rails 5? I think for the most part this stuff should be the same as it has been.

You'll have to check your Rails logs in production to see what the error is. There error isn't necessarily related to this code, but it could certainly be. Whatever error is in the logs will give you insight as to what's going wrong.

There's nothing special to these gems especially considering jquery-rails shipped with Rails every single release between like 3.1 and 5.0. GoRails itself uses that and the bootstrap-sass gem.

Yep, you're spot on. Basically what you did was replicate the setup from Rails 5.0 or earlier to a T. With jQuery being a dependency of the Bootstrap JS, you just include jQuery ahead of the bootstrap JS.

You don't need the jquery_ujs file because that's for handling the remote: true things which is done with the new Rails ujs that doesn't need jQuery. It doesn't really make much difference in this case, but using the new rails_ujs will be better going forward.

Until Bootstrap removes jQuery as a dependency, this is pretty much the way to go.

Hey Ernesto, yeah it sounds like the JS is running on document ready, but not turbolinks load (which is run every single time you visit another page since turbolinks fakes those second page requests).

This is the case from the example because of this code:

jQuery ->
  new Notifications

The jQuery -> is a function for saying when the document is ready, then run this code.

If you change it to this it will work on every turbolinks page:

$(document).on 'turbolinks:load', ->
  new Notifications

Hmm, hard to say. I would start by inspecting the HTML and then stepping through the JS code line by line and making sure those are working as expected. You'll figure it out pretty quickly if you break it down and find the spot that's not working like you want it.

Doh. I still got notified. It ain't done yet! :)

Awesome. I just muted this thread so next post in here I shouldn't receive an email...feel free to post a reply to test it. :)

Alrighty, it's live (and hopefully all working!).

You can find it on the left side underneath the categories. I should probably put it in a better spot, but hey, I'm no designer yet. 😜

Agreed, this is something I've been meaning to build for a long time. At this point I question whether or not I should have just used Thredded instead, but it's fairly late now. :P.

I think I'll be adding the ability for you to both subscribe and unsubscribe from threads. Since you're kind of automatically subscribed by posting in a thread, it'd be nice to unsubscribe as well.

Agreed. :) I'm going to update the list to include the durations shortly.

And yeah, my ideal length is 15-20 minutes, but because the audience is a wide range of beginner to advanced Rails devs, it's hard to cover everything in that time. I should probably start splitting episodes up into two parts to handle that better.

Makes sense. Well if you're using friendly_id, the only ID that users will see will be the slug, not the database ID. As long as you don't have a count as part of your slug you'll be fine. You can even have it generate a random string for the slug if you want.

Yep, something like that could work. That should print out true or false in the data attribute (you can inspect the html to verify) and sure give you back a Javascript boolean you can use when you query for it.

Yeah I think you're correct.

From the Rails guides:

In order to run your tests, your test database will need to have the current structure. The test helper checks whether your test database has any pending migrations. It will try to load your db/schema.rb or db/structure.sql into the test database. If migrations are still pending, an error will be raised. Usually this indicates that your schema is not fully migrated. Running the migrations against the development database (bin/rails db:migrate) will bring the schema up to date.

If there were modifications to existing migrations, the test database needs to be rebuilt. This can be done by executing bin/rails db:test:prepare.