A long time ago I was taking flight lessons and I was going through the takeoff checklist. I was going through each item, but my instructor had to remind me that I am not just reading the checklist - I need understand/verify each checklist item before moving on. Always stuck with me.
A few times a year I have to remind my co-workers that reading & understanding error messages is a critical part of being in the IT business. I'm not perfect in that regard, but the number of times the error message explaining exactly what's wrong and how to solve it is included in the screenshot they share is a little depressing.
> how do we get large text to scale at a lower rate than body text. It's great that the body text can scale up from 16px to 32px, but does heading text need to scale up from 32px to 64px? It's already huge. If you have any thoughts, please do let me know!
Android 14 has this in non-linear text scaling -
> To prevent large text elements on screen from scaling too large, the system applies a nonlinear scaling curve.
I wish Android apps were better citizens when it comes to accessibility. My friend has very poor eyesight and I set his phone up to make things bigger for him, but most of the apps are a horrible janky mess of overlapping everything.
(Also "light mode" apps are painful for him to view, and most of the major apps have skipped out on offering dark mode)
I used to dread this approach (it’s part of why I like Typescript monorepos now), but LLMs are fantastic at translating most basic types/shapes between languages. Much less tedious to do this than several years ago.
Of course, it’s still a pretty rough and dirty way to do it. But it works for small/demo projects.
Each layer of your stack should have different types.
Never expose your storage/backend type. Whenever you do, any consumers (your UI, consumers of your API, whatever) will take dependencies on it in ways you will not expect or predict. It makes changes somewhere between miserable and impossible depending on the exact change you want to make.
A UI-specific type means you can refactor the backend, make whatever changes you want, and have it invisible to the UI. When the UI eventually needs to know, you can expose that in a safe way and then update the UI to process it.
This completely misses the point of what sharing types is about. The idea behind sharing types is not exposing your internal backend classes to the frontend. Sharing types is about sharing DTO definitions between the backend and the frontend. In other words, sharing the return types of your public API to ensure when you change a public API, you instantly see all affected frontend code that needs to be changed as well. No one is advocating for sharing internal representations.
IIRC, the grocery chain I worked for used to have an offline mode to move customers out the door. But it meant that when the system came back online, if the customers card was denied, the customer got free groceries.
IIRC, the grocery chain I worked for used to have an offline mode to move customers out the door.
Chick-fil-a has this.
One of the tech people there was on HN a few years ago describing their system. Credit card approval slows down the line, so the cards are automatically "approved" at the terminal, and the transaction is added to a queue.
The loss from fraudulent transactions turns out to be less than the loss from customers choosing another restaurant because of the speed of the lines.
The POS I work on also has this feature. Line busters take the order and payment but we have a toggle where you can immediately “approve” and queue it up. If the payment fails then the person handing you your food will see it on the order and ask you for alternative payment. It helps prevent loss and speeds up the line overall.
Yea, good old store and forward. We implemented it in our PoS system. Now, we do non PCI integrations so we arn't in PCI scope, but depending on the processor, it can come with some limitations. Like, you can do store and forward, but only up to X number of transactions. I think for one integration, it's 500-ish store wide (it uses a local gateway that store and forwards to the processors gateway). The other integration we have, its 250, but store and forward on device, per device.
In many places it's also possibly just a left over feature from older times. I worked at a major UK supermarket in the mid-00s, and their checkout system had this feature. But it was like that because that's how it was originally built, it wasn't a 'feature' they added.
Credit card information would be recorded by the POS, synced to a mini-server in the back office (using store-and-forward to handle network issues) and then in a batch process overnight, sent to HQ where the payment was processed.
It wasn't until chip-and-PIN was rolled out that they started supporting "online" (i.e. processed then and there) card transactions, and even then the old method still worked if there was a network issues or power failure (all POSes has their own UPS).
The only real risk at the time was that someone tried to pay with a cancelled credit card - the bank would always honour the payment otherwise. But that was pretty uncommon back then, as you'd have to phone your bank to do it, not just press a button in an app.
I was shopping at a mall with a visa vanilla card once. I got it as a gift and didn't know the limit. No matter what I bought the card kept going -- and I never got a balance of what was on the card. Eventually, later that day it stopped. I called customer support and asked how much was left on the balance. They told me they had no idea my balance - but everything I bought was mine.
I remember that banks will try to honor the transactions, even if the customer's balance/credit limit is exhausted. It doesn't apply only to some gift cards.
I used python on a large code base for quite a while. Many team members did not like type hints, and a codebase that doesn't maintain type hints makes it harder to use them.
However, if I had a choice, rather than use typehints in python, I would much rather just use a statically typed language. Short, tiny scripts in python? Sure. Anything that grows or lives a long time? Use something where the compiler helps you out.
reply