Had they had unit tests, this would never have gotten that far.
Have unit tests!!
Could you do other things with those credits, like use them in the cafeteria or resell them? Why were they so frantic to close the loophole?
Twenty five thousand dollars of funny money
51–60 of 175 posts
Re: Twenty five thousand dollars of funny money
#52Had exactly that bug in production, was using ruby on rails & active merchant, and some version change in ActiveMerchant switched from cents to dollars for one of the integrations. Our test harness didn't catch it (weird combination of reasons, too long ago for me to remember the details) & it rolled out. Shortly thereafter I get an anxious customer call that we'd charged their debit card $2500.00 instead of $25.00 a…
>internal video camera pulling back poltergeist-style
That cinematic technique is called a "dolly zoom" and it's totally dramatic, if used correctly!
Re: Twenty five thousand dollars of funny money
#53Earlier quoted context omitted.
Seriously, since everything I work in is denoted as "cents" from backend to frontend, I personally had never understood the need This matches my experience. Obviously actual strict typing has its benefits, but as far as developer ergonomics are concerned, IME you can get about 95% of the benefits just by following a convention of including unit names in identifier names. It's easy to see why this Ruby code might fail…
Easy! # not happening unless developer consumes a large number # of drugs distance_miles = 42 launch_rocket(distance_km: distance_miles*1.6) Aaaand we're off by 0.3924km. Enough to fit 4 football fields with a few meters left over. Oopsies Units are hard. Never under-estimate the ability of programmers to think they're converting but get it slightly wrong.
[deleted]
Re: Twenty five thousand dollars of funny money
#54Earlier quoted context omitted.
Yep. But that function will accept type RobotUuid = string; const bar: RobotUuid = “abc…”; foo(bar); This is what duck typing is and specifically my curiosity about being able to de-duck on demand.
Yeah just means you have to rely on linting and your ide to catch those errors. And hopefully the rest of your team does the same thing. Tho I suppose if it is really important you can put an assert there but I'm not familiar with that wrt typescript, maybe the transpiler would kill that? I've done the occasional type checking in that way in similar languages, it is kind of self documenting too. 90% of the time duck…
If robot0 name is AAA and uid Is BBB, and robot 1 name is BBB and uid AAA, and you call the function checkRobot('AAA'), what sort of assert exactly could differentiate between a name and a uid?
Re: Twenty five thousand dollars of funny money
#55I'm gonna be honest, I had never understood the "strict type" argument until right now. Seriously, since everything I work in is denoted as "cents" from backend to frontend, I personally had never understood the need so I'm part of today's lucky 10,000th.
This bug could easily happen in a typed language though. function deduct(int cents) { ... } int dollars = ... deduct(dollars); You need something like (Apps) Hungarian notation [1] as a minimum - or even better, subtypes of primitives like in Go to represent units in a typesafe way. [1] https://en.m.wikipedia.org/wiki/Hungarian_notation
You should define separate types for “cents” and “dollars”. And, probably operations to convert between the types.
Re: Twenty five thousand dollars of funny money
#56One of the things I really like about f# is thar you can tag even raw numbers with types. And even multiply/divide on those types. https://learn.microsoft.com/en-us/dotnet/fsharp/language-ref...
Nim as well, they even have an example[0] with currencies.
[0] https://nim-lang.org/docs/manual.html#distinct-type-modeling...
Re: Twenty five thousand dollars of funny money
#57I'm gonna be honest, I had never understood the "strict type" argument until right now. Seriously, since everything I work in is denoted as "cents" from backend to frontend, I personally had never understood the need so I'm part of today's lucky 10,000th.
Seriously, since everything I work in is denoted as "cents" from backend to frontend, I personally had never understood the need This matches my experience. Obviously actual strict typing has its benefits, but as far as developer ergonomics are concerned, IME you can get about 95% of the benefits just by following a convention of including unit names in identifier names. It's easy to see why this Ruby code might fail…
> [follow] a convention of including unit names in identifier names.
appending units to identifiers helps, but it relies on a developer's eyeballs to spot any errors. It would be infinitely preferable if the type system would simply enforce this for you and developers not have to expend cycles reasoning about this stuff themselves.
Re: Twenty five thousand dollars of funny money
#58Had they had unit tests, this would never have gotten that far. Have unit tests!! Could you do other things with those credits, like use them in the cafeteria or resell them? Why were they so frantic to close the loophole?
Maybe we are misinterpreting the urgency of the messaging. I could just as easily read it as, "Hey guys having a problem with the pseudo-money credit. Shutdown until further notice."
Re: Twenty five thousand dollars of funny money
#59I'm gonna be honest, I had never understood the "strict type" argument until right now. Seriously, since everything I work in is denoted as "cents" from backend to frontend, I personally had never understood the need so I'm part of today's lucky 10,000th.
You don't need "strict typing" to handle money; in the old (COBOL) days, we used BCD to represent monetary amounts with arbitrary precision. When they took away BCD, we were stuck, if we wanted to build a system that could represent a large sum correctly in both dollars and yen. COBOL was pretty good for dealing with money.
BCD doesn't really make it easier. Fixed point can, but that's ultimately a typing thing that works just fine in binary as well.
Re: Twenty five thousand dollars of funny money
#60I'm gonna be honest, I had never understood the "strict type" argument until right now. Seriously, since everything I work in is denoted as "cents" from backend to frontend, I personally had never understood the need so I'm part of today's lucky 10,000th.
You don't need "strict typing" to handle money; in the old (COBOL) days, we used BCD to represent monetary amounts with arbitrary precision. When they took away BCD, we were stuck, if we wanted to build a system that could represent a large sum correctly in both dollars and yen. COBOL was pretty good for dealing with money.
Could you expand on BCD? What made it good for multi-currency work?
(a quick google did not help, managed to lead to examples of COBOL manipulating the first five letters of the alphabet ...)