Chris Oliver

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.

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.