Chris Oliver

Well the turbolinks cache is designed to display the previous page quickly before refreshing it with the latest version. It's not designed for offline work, just to speed up the page.

Basecamp's mobile app basically just implements a "The internet connection appears to be offline" for pages and a reload button till the user is back online. ServiceWorkers in HTML5 are designed to help make offline functionality of web pages a bit better, but if it's a mobile app you may also want to build out some views natively so that they still function offline.

Some of these early episodes don't have the source code uploaded unfortunately. I was terrible at saving the code early on!

Hahah! Yeah it's a real pain in the butt. This is probably why people use Spree/Solidus for most complex ecommerce projects because it's already solved those problems for you. Doing this from scratch can end up with a whole lot of little gotchas which are almost certain to be addressed already by Spree/Solidus which is nice. Just looking at the sheer list of extensions they have gives you an idea of the complexity: http://extensions.solidus.io/

This is why Shopify is such a giant Rails app. I actually found reading their API docs thought provoking to see how they handle the various pricing options for variants and things. I don't think they even handle things like bulk discounts out of the box and you have to install it to your store: https://apps.shopify.com/bulk-discounts

Variants themselves are relatively straightforward in the sense that users will always see Products and always interact with variants aside from visiting the product pages.

As you might imagine, we could probably talk about the complexities of this for months given how big of projects/businesses ecommerce is these days. :)

Quick question first, are you going to be handling inventory? Like will there be X number of this book?

This is a great question. In most cases, I'll put these into the models folder because they really operate like models. It's nice to have them side-by-side because often times if you change the User model, you'll likely also need to modify the GuestUser to be compliant. I usually put it in app/models/guest_user.rb like you mentioned for simplicity at first.

You can always create folders inside your models directory as well so you could put it into app/models/user/guest.rb as well and name it User::Guest to keep it organized. This might be useful if you also include some User specific modules, they can fit in that directory as well.

Of course, you could even create an app/null_objects directory if you had a lot of these for various purposes and wanted to organize them all into a single place.

Since Ruby doesn't do multiple inheritance, I guess a BaseUser might end up being more of a module to include than a class to inherit from since the User model will have to inherit from ActiveRecord but the Null object will not. You probably wouldn't get a big benefit from this other than maybe enforcing some method existence.

PS: The urls are generated by friendly_id 🤘

Yeah I'm with David on this one. Using the mime type will be the best way to determine how to split these. They probably makes sense to be stored in a generic ProjectAttachment model and then filter then by scoping on the type.

If you combine the two models into a single attachments model, you'll want to update your uploader to be generic. I presume you'll be cropping images and obviously you can't crop documents. Your uploader will need to check the file type before doing the cropping so that only happens for images.

Alex's suggestion for #1 is exactly the right way to approach that.

For #2, I'm not quite sure I'm following. Are you wanting the sales_tax header to be just "S" or do you want each of the rows to have "S" as the value for the sales tax column or something else?

@poidog22 I definitely should! I've got a separate Stripe course (outside of GoRails) that I've been putting together over the last couple of months and one of the bonus sections towards the end is building a full shopping cart and checkout flow. It's not multi-step right now but that should be a reasonable addition to include in the course.

I'll be announcing that course in the next couple of weeks if all goes well as I finish up these videos.

I don't think I ever recorded any. Too many different topics to cover and it's easy for them to slip into the cracks haha. I wanted to make sure I understood it well enough before releasing a video, but the basics of using Turbolinks-iOS I can definitely do.

That's probably because when you do the destroy, Rails has no idea you have a local variable called "user" and therefore it can't update it to keep it in sync.

Typically people will store JSON Web Tokens in localStorage so they're persisted across requests in the browser. This has the (somewhat major) downside of tokens being stealable by any Javascript that runs on the page and why session cookies are still the right answer for 95%+ of apps. You're far less likely to screw up the security of sessions with the traditional approach.

Token authentication works best when you're using it for mobile apps because you aren't likely running anyone else's code. You can save the token in an encrypted place accessible only by the app using the native libraries and know your token is secure there. On the web, it's not so easy.

Here's some good food for thought on JWTs:

From this article: http://cryto.net/~joepie91/blog/2016/06/19/stop-using-jwt-for-sessions-part-2-why-your-solution-doesnt-work/

Go for it. Like it says at the top of the post, this is for documenting it for Bash on Windows, not other approaches like VirtualBox.

Well, the real worst-case scenario is that your JWT is out in the wild and still valid, then someone just changes your account details to their own and hijacks it from you without you knowing.

Obviously, letting people know that your email address has an account is not great, but it's no different than someone attempting to register a new account with your email and it saying "This email address has already been taken".

Nope, wrote it myself, but things are constantly changing with Bash on Windows so these instructions break often.

That's not much to worry about because if someone gets your token, they have full access to your account and can do anything they want. You've got much bigger problems in that situation because your JWTs should never be exposed.

Hmm weird, they changed that to be the default URL for Rails in 5 I believe so it shouldn't be necessary. The project I'm using in 5.0.1 doesn't have it and it finds ActionCable just fine. Not sure what's up there.

When you configure your database for the first time, you're asked what user and password owns it. This is how it gets protected. Almost all services you use that configure the database for you like Heroku, will have generated a username and password for it. That's inside the URL at the beginning before the @ and separated by a :. You just use the URL they give you but when you're using your own local database or whatever, you must use the username and password you set while setting up the database. You almost always want a password to lock it down so no random people can access your data.

For your own database, you'll just modify the database.yml to use those separate parameters instead of a url because it's easier formatting.

Hey Aime,

I'd probably recommend making a cron job for this case instead of scheduling jobs ahead of time. This way you can write a worker that runs every day or so, and checks for events that happen in the next 24 hours and sends out those email reminders.

By doing this you don't have to keep track of which events were canceled or rescheduled, and you're always looking at accurate data when the job runs so you don't have to worry about any of the cancellations or reschedules.

I made an episode on the whenever gem that you can use to build cron jobs that you might like to watch: https://gorails.com/episode...

As long as you followed all these instructions you should be fine. It sounds like you overwrote files inside a Rails app which should be fine. You can always try creating a new Rails app and seeing if that works. Then you'll know you're setup correctly.

That seems like a pretty decent solution cross-domain. Since you're sharing the database between the two, you can verify the token is only allowed for the user it was generated for and your expiration can be like 30 seconds so that the chance of that token leaking is very small.

You can also scope that AuthRequestsController to only allow admin users to access it as well so you get the same security around these tokens that devise masquerade does when it's only accessible from the admin.

Sounds like that'll work pretty nicely.