And it almost always DOES go wrong. Seriously 75% of the time when I'm done scanning and I press "pay now," it inexplicably says "calling for assistance" and refuses to do anything until an employee comes over. WHY?
And now assholes are intentionally taking alcohol through the self-checkout, deliberately taking up that one employee's time making him or her perform the workaround to check the items out.
And the 20+ years of "unexpected item in the bagging area" bullshit... just get rid of it.
Strangely that issue has almost vasnished for me in the last couple of years, here in New Zealand at least across the several supermarket chains I frequent (although they all seem to use the same self service POS supplier). Sure it was a big issue when these first came into stores but I think they've realised they need to increase the tolerances a bit (e.g. accept even if the weight is <1% off) and it all just works close to 100% of the time for me. I do however generally avoid adding bags to the weight area (as I've found these to trigger false warnings) and just load my shopping directly onto the weighted area and then once I've paid I'll just bag my shopping then. Works like a charm.
I do that, too (scan, pay then bag), but it's a tradeoff - you get smoother checkout experience in exchange for some speed. If everyone was throwing all their scanned stuff in a bag immediately, the checkout would be a lot faster.
But this was an obvious sham and a fraud that couldn't scale. I don't think its demise is sad at all.
What's sad is putting cashiers out of work, and even worse is replacing them with outrageously piss-poor alternatives. Self-checkout is a clinic on incompetent system design, and has been for DECADES now. It's mind-bogglingly bad, all to take jobs away from people. Fuck that.
Why is it a fraud? Did they ever tell you it was entirely computer-driven? I thought their value proposition was you could just ... walk out. This feels pretty inescapably the future. Why have people do bad jobs like cashier work when computers could do them instead? This is why UBI is going to be critical. We're moving to a world where we'll have more people than work, and that's not just ok - it's fantastic.
They're not wrong, they're just early. Which you could argue is the same thing on a micro scale, but not on a macro.
> Our checkout-free shopping experience is made possible by the same types of technologies used in self-driving cars: computer vision, sensor fusion, and deep learning. Our Just Walk Out Technology automatically detects when products are taken from or returned to the shelves and keeps track of them in a virtual cart. When you're done shopping, you can just leave the store. A little later, your receipt will be available and we will charge your payment method.
Targeting OpenAPI 3.0 is a bad idea. It wasn't until 3.1 that it became truly useful, if only because it fixed one glaring blunder: Pre-3.1, you inexplicably couldn't provide a description along with a $ref. This defeats one of the major purposes of OpenAPI, which is... documenting your API.
Example: If you define a structure called Rectangle and use it all over the place, you can't say what this rectangle means or that rectangle means when the structure is used in your API. How was that ever deemed acceptable? Widespread use of common structures (which one would certainly expect in a well-designed API) resulted in an API that couldn't be documented in OAS.
The OpenAPI code-generation landscape is truly abysmal. Not only do almost none of the tools support version 3.1 (which has been current for years), but the generators themselves are of widely varying (but mostly shitty) quality and scattered across a couple of apparent major repos. The documentation is likewise a confusing morass of conflicting and incomplete information from several sources. I flailed away trying to fix one generator for weeks, or write a new one. But I couldn't even find a concise list of the data structures offered to the template engine after an OpenAPI doc is ingested by OpenAPIGenerator. Isn't that a fundamental part of creating a new generator?
So it raises the question of whether OpenAPI is salvageable, or whether this new DSL is better... from design to code generation. Given the trashy state of OpenAPI code generators, why bother generating OAS at all? Just move on and write some competent generators using this new language.
The playground I posted has a description. They're pulled from JSDoc style comments. You can also use the `@doc` decorator, though that's usually reserved for more advanced cases like when you need string interpolation or something.
For what it's worth, we support 3.0 because as you note the ecosystem doesn't support 3.1 broadly yet. I'm personally interested to see if 3.1 becomes prevalent before 4.0 is released. Maybe the ecosystem will just skip 3.1?
We generate OAS because it's useful for many folks, including for us in Azure. But like you we didn't have very good luck getting high quality codegen from OpenAPI. Our latest client codegen tech doesn't use OpenAPI, we generate code directly from the TypeSpec, which offers a number of advantages that result in higher quality. Probably at topic for a blog of its own! Anyway, you might be happy to know that we are working on bringing our emitters into the TypeSpec project so anyone can use it with their TypeSpecs.
We're working on bringing it into the TypeSpec project as we speak. You can see an initial demo of it working in this repo: https://github.com/bterlson/typespec-todo.
