Chris Oliver

Oh this is an interesting one. I believe you'll have those tables in all the tenant schemas because of the way the gem works, but you'll be able to exclude the Mailboxer models so that they operate outside of the tenants like you would do with your User model for example.

Check out this section and see if that helps. I believe you'll want the migrations to run as they have already, then just add all the Mailboxer models to this config. https://github.com/influitive/apartment#excluding-models

Something like this? You'd basically create your own string to add to the CSV as the first column.

csv << ["#{user.name} #{user.email} #{user.coupon.code}", user.id]

Great question. So generally in a mobile app, you'll have to have that token stored somewhere. Basically if the token exists in the cache in your mobile app, you can then assume the user is logged in. If it doesn't exist, assume they are logged out.

There is an extra exception that sometimes tokens can expire and aren't permanent. If they do have time limits on them, you can store that in the mobile app along with the token to determine if it is still valid or not. If they don't, you can just request any endpoint and know that if it fails, you're going to need to request a new token.

Does that help?

Perfect! I was going to say, it sounds like your title method or something on the MissingArticle isn't accepting the number of arguments that the ActiveRecord model is. Glad you figured it out! :)

If you're using Turbolinks 3, it should be on by default. It only shows if the request takes more than a certain period of time I believe, so you may just not be seeing it in development. You might try tossing in a sleep 5 into your code to see if it shows up.

More info on it here: https://github.com/turbolinks/turbolinks-classic#progress-bar

Great question. I would actually remove the queues you listed and then Sidekiq will process everything by default. You don't really need to separate out queues until you have so much background work happening that it makes sense to separate and prioritize them.

@disqus_Uh95M6FOYo:disqus @disqus_4UMLsxjaNb:disqus Enjoy! https://gorails.com/episode...

Good work man! It looks like it turned out pretty clean and simple. :D

The free solution is alright. It provides a semi-secure connection. You're securely connected to Cloudflare, then the request gets forwarded to you, but at that point it is unencrypted. There is a possibility that someone could access the traffic coming from Cloudflare to your app that's unencrypted.

If you do need something that's fully encrypted, you'll want an SSL cert running on Heroku. That's the route I usually take because we want full encryption (and sometimes don't use Cloudflare).

Your cheapest option would be to use Cloudflare's flexible SSL. You wouldn't have to pay for the $20/mo for SSL hosting on Heroku that way. There are some other SSL options that Cloudflare provides but I think they cost money. https://www.cloudflare.com/...

Also most places require you to purchase an SSL certificate, but you may want to check out Let's Encrypt which let's you get a free SSL certificate. https://letsencrypt.org/

I think the has_many relationship seemed good. Anything more complex sounded like it would be overkill unless you've got some other requirements to add in there.

This seems alright to me. Have you looked into the cocoon gem for making the form?

Hey! Are you looking to do multi-tenancy based upon domain? If so the apartment gem is what you'll want. It can separate the database out by domain and provides some helpers for that. https://github.com/influitive/apartment

I did an episode on the Apartment gem using subdomains but you can modify that to use domains instead of subdomains. https://gorails.com/episodes/multitenancy-with-apartment

The readme for the gem shows all the relevant bits you'll need to change to support domains instead of subdomains.

As for making usernames at the root instead of on /users, you'll need to make a custom route.

resources :users
get ":username", to: "users#show"

The second route will take the /samsoft route and send it to the users show action. You'll need to make sure this route goes at the end of your routes file so that if you ever add something like /help it wouldn't think that "help" was a username.

Hey John!

If you're using Bootstrap, I sometimes use their collapse / accordion JS lib for this kind of thing: http://getbootstrap.com/javascript/#collapse
http://getbootstrap.com/javascript/#collapse-example-accordion

Thanks man! :)

I'll have to do an episode on jQuery.turbolinks soon. Also Turbolinks 5 as well since that should be coming out in the near future.

I'd recommend checking out jQuery.turbolinks. It's a gem that basically maps the jQuery ready function to the Turbolinks page:change function (and some others) to make all your jQuery code run as expected. It's one of those things that makes using Turbolinks a lot simpler and fixes some of the issues like this.

That should do the trick without having to write any extra code. Let me know if that works for you!

I would recommend checking out Liquid templates (which was made by Shopify!) for customizing the templates. http://liquidmarkup.org/

They've also got a bunch of other very helpful gems that they've open sourced which can really help. Take a look at their Github profile for those. https://github.com/shopify

I just was looking into Turbolinks 5 yesterday and it looks like they've ditched partial replacement because it's sort of trivial gains in comparison to the complexity it adds (their claim) and I kinda agree.

I'm curious, do you know if poltergeist is executing the JS? A previous project I was using ran tests with Firefox and that made it a bit easier to pause and debug what was going wrong with them. Often it was something like that.

And one other thing I thought of, is you can sometimes do a hybrid approach, where you don't really uses an instance of each class, but more the class as a singleton representing whatever the current object is, doing all of it's work relative to the event handler. You can have more generic React-like classes that way that end up being able to take advantage of both the class and the live handlers from jQuery.

Yeah, that's a great question. I generally take that first approach, or something like it. Sometimes rather than doing it on the response, I'll do this beforehand, but each time you'll need to instantiate the class for every record inserted. I didn't find it to be that much of an issue from building things like this, but it can be a little extra work. In any case, dynamically adding things like this without using something like React is going to usually entail some extra overhead like that.