51–60 of 68 posts
I wrote industrial control software that bumped a very expensive piece of equipment against the wall because I miscalculated the encoder position. Since then, special limit switches were added, colloquially known as anti-EVa5I7bHFq9mnYK switches.
As a dotcom kid who founded and wrote the core systems for several payment processing companies over the decades I recall 2005 when a company using one of our partner banks was breached. This was CardSystems, the largest publicly known breach at the time, and I was tasked to perform a full code review of their systems to find any issues. The payments gateway contained a valid crc nontest card number compiled into authorization logic that had no deployment switching control and recorded no transaction information when that card number was used. Any merchant using CardSystems under this payment gateway suffered unknown losses from approved transactions that were never recorded into any system. I postulated who had done this but federal law enforcement around the breach buried this and other key discoveries I had found since the company was being dissolved and my findings were therefore deemed immaterial.
Earlier quoted context omitted.
Not to defend that, but the question is how quickly would they be able to set that dev up with a test-bank account? In the orgs I know this would probably take a month or so. So taking your own account during early development can make sense. Leaving it in is probably a bad idea tho.
Its my opinion, but you shouldn’t need a bank account or even internet connection to work on the code at all. Instead its better to mock it out in development.
Are all these articles this "lightweight" and short on details and sound like a made up coding morality tale? Just the style here throws me.
I have briefed Register journalists 100+ times and this is is absolutely their editorial style. If you go technical, they do their best to translate what you've said into analogies that mid-market IT managers will understand. It was embarassing because my fellow engineers would often read an article and be alarmed that I may not understand our technology because of this. The issue is that you can't not brief The Regi…
Earlier quoted context omitted.
This is not a true story because as a merchant you cannot "refuse chargebacks". In fact too many chargebacks will result in a loss of your merchant account. You should really stop making things up.
I read this person as using “chargeback” to mean refund. However, merchants do have an opportunity to respond to a chargeback request. Providing plausible evidence that the request is in bad faith will often result in the bank not performing an actual chargeback.
Refusing chargebacks and not issuing refunds are two very different things with distinct language. And if you don't issue refunds for a case like the GP described, where thousands of customers were incorrectly billed, you certainly would be flooded with chargebacks and likely put your merchant account in jeopardy. (Most of the big processors would close your account if they get evidence you are fraudulently billing customers and actively resisting making it right.)
It's clearly a made up story by someone with no experience actually managing credit card payments for a real business.
Then I have a bash script that runs on the raspberry pi board that has a speaker installed, something of this sort to play the doorbell chime:
while [ true ]; do
mosquitto_sub --exit-after-first-message /my-topic
play_wav my-file.wav
done
I worked for a large retailer on their iPhone app and our test environments were terribly slow so we tended to do most of our development against production. This retailer is pretty old and had issued their own credit cards that didn't have any sort of checksum validation. This made making test orders easy because any sequence of numbers for that credit card type would let the "checkout" call succeed, and then the or…
I worked on a large makeup website for a while, and it was common for us to place test orders and subsequently cancel them. The dev doing it usually put their name and the office address as the shipping address. One day, we got a big box of makeup at the office - turns out their warehouse had gotten so fast that in the time it took us to cancel the order they had already picked & shipped it. After that we put "TEST D…
now that's a true end-to-end test.
Earlier quoted context omitted.
I worked on a large makeup website for a while, and it was common for us to place test orders and subsequently cancel them. The dev doing it usually put their name and the office address as the shipping address. One day, we got a big box of makeup at the office - turns out their warehouse had gotten so fast that in the time it took us to cancel the order they had already picked & shipped it. After that we put "TEST D…
One day, we got a big box of makeup at the office now that's a true end-to-end test.
A couple of years ago, I lived in an apartment and made a doorbell repurposed from an Amazon Dash button. Basically I have a daemon that sends a message each time a button press is detected to my homebrew mqtt server. Then I have a bash script that runs on the raspberry pi board that has a speaker installed, something of this sort to play the doorbell chime: while [ true ]; do mosquitto_sub --exit-after-first-message…