Chris Oliver

CSRF tokens are generated for each user, which is why they should not be cached. The CSRF tokens are specific to each user and request so that you can determine whether or not it was the user taking this action or malicious code.

To solve this you have 3 options:

1. Don't cache the form
2. If you're fragment caching, use Javascript to include the CSRF token. See here: https://coderwall.com/p/0sctaa/forms-csrf-authenticity-token-and-fragment-caching-in-rails
3. If you're doing full-page caching, use one of these mthods: https://www.fastly.com/blog/caching-uncacheable-csrf-security

Hey Aime,

I don't believe there was much (or any?) CSS in that episode that I wrote. All the source code for that episode should be here: https://github.com/gorails-screencasts/gorails-episode-78

Atwho.js does include some CSS with the library to style the mention box: https://github.com/ichord/At.js/blob/master/src/jquery.atwho.css

Yep, shouldn't have a problem. You can always check out their GitHub if you run into issues.

Rake isn't deprecated, they just added a way for you to call it with the rails command so it's less confusing when to use rake vs rails commands. It still functions exactly the same, just simpler now. 🙌

I mean to reply last week but lost the browser tab. :)

Absolutely love these suggestions and I'm going to record a video on advanced counter caches for sure. Please keep the suggestions coming, these are all fantastic and a welcome addition to all the beginner screencasts I often get requests for.

Lots of options. Depending on how long it takes you might want to do this every 4 hours or something instead. You might want to do a live replica database for realtime backups to another server and then archive a copy of it nightly.

You're welcome! Let me know if you have any suggestions on other topics like this you'd like to hear explained. it's easy for me to take these things for granted these days so ideas for topics are always welcome!

Make sure you're not requiring the active admin css file in your application.css on accident (probably with a require_tree). Their CSS is made to be compiled separately into another file out of the box and so you don't want to include their CSS with yours. That's probably happening with a bad require or import in your application.css at the top.

That's pretty neat. I know I've seen SimpleDelegator mentioned before in but never looked into it. I'll have to fiddle with it now!🤘

That's awesome to hear. Thanks Nick! :)

Hehe 😎 I actually saw that earlier when I was poking around the offline web app stuff on MDN when we were talking about ServiceWorkers. I haven't done a whole lot with stuff though, just dabbled.

Unfortunately AppCache was deprecated in favor of Service Workers due to some poor design they discovered on more complex apps. https://developer.mozilla.o... has the deprecation warnings at the top there.

Cross posting this from Slack:

I think your setup looks alright. Any books where the bought_by is nil means it’s not been sold. When you do checkout you can charge the user and then assign the ID there and it can go off the market.

If someone else was in the process of buying the book at the same time, you can wrap that in a transaction so that when the assign of the ID fails, you can refund the purchase or vice versa. Assign the id first and attempt payment, then undo the ID if the payment fails. Probably that second way would make the most sense (checkout the transactions video I did recently for more on those rollbacks) not having inventory means you get a LOT of simplicity which you wouldn’t otherwise.

Another thing here is that you don’t need an “Order” model or a cart or anything because you can use the book itself for all that information. So you buy it, and the seller ships it and wants to add tracking, you can then just put it on the book if you wanted or associate a shipping record to that book.

Yeah Turbolinks is not designed for mobile apps that need to work offline. It has basic fallbacks but it's intention is never to make fully offline mobile apps.

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.