Skip to main content

An Electric Racecar Drives Upside Down

3 months ago
Formula One cars, the world's fastest racecars, need to grip the track for speed and safety on the curves — leading engineers to design cars that create downforce. And racing fans are even told that "a Formula 1 racecar generates enough downforce above a certain speed that it could theoretically drive upside down," writes the automotive site Jalopnik. "McMurtry Automotive turned this theory into reality after having its Spéirling hypercar complete the impressive feat..." Admittedly, the Spéirling's success can be solely attributed to its proprietary 'Downforce-on-Demand' fan system that produces 4,400 pounds of downforce at the push of a button... For those looking to do the math, Spéirling weighs 2,200 pounds. With the stopped car's fan whirling at 23,000 rpm, the rig was rotated to invert the road deck... Then, the hypercar rolled forward a few feet before stopping while inverted. The rig rotated the road deck back down, and the Spéirling drove off like nothing happened. The McMurtry Spéirling, as a 1,000-hp twin-motor electric hypercar, didn't have to clear the other hurdles that an F1 car would have clear to drive upside down. Dry-sump combustion engines aren't designed to run inverted and would eventually fail catastrophically. Oil wouldn't be able to cycle through and keep the engine lubricated. The car is "an electric monster purpose-built to destroy track records," Jalopnik wrote in 2022 when the car shaved more than two seconds off a long-standing record. The "Downforce-on-Demand" feature gives it tremendous acceleration — in nine seconds it can go from 0 to 186.4 mph (300 km/h), according to Jalopnik. "McMurtry is working towards finalizing a production version of its hypercar, called the Spéirling PURE. Only 100 will be produced."

Read more of this story at Slashdot.

EditorDavid

A Single Mortgage

3 months ago

We talked about singletons a bit last week. That reminded John of a story from the long ago dark ages where we didn't have always accessible mobile Internet access.

At the time, John worked for a bank. The bank, as all banks do, wanted to sell mortgages. This often meant sending an agent out to meet with customers face to face, and those agents needed to show the customer what their future would look like with that mortgage- payment calculations, and pretty little graphs about equity and interest.

Today, this would be a simple website, but again, reliable Internet access wasn't a thing. So they built a client side application. They tested the heck out of it, and it worked well. Sales agents were happy. Customers were happy. The bank itself was happy.

Time passed, as it has a way of doing, and the agents started clamoring for a mobile web version, that they could use on their phones. Now, the first thought was, "Wire it up to the backend!" but the backend they had was a mainframe, and there was a dearth of mainframe developers. And while the mainframe was the source of truth, and the one place where mortgages actually lived, building a mortgage calculator that could do pretty visualizations was far easier- and they already had one.

The client app was in .NET, and it was easy enough to wrap the mortgage calculation objects up in a web service. A quick round of testing of the service proved that it worked just as well as the old client app, and everyone was happy - for awhile.

Sometimes, agents would run a calculation and get absolute absurd results. Developers, putting in exactly the same values into their test environment wouldn't see the bad output. Testing the errors in production didn't help either- it usually worked just fine. There was a Heisenbug, but how could a simple math calculation that had already been tested and used for years have a Heisenbug?

Well, the calculation ran by simulation- it simply iteratively applied payments and interest to generate the entire history of the loan. And as it turns out, because the client application which started this whole thing only ever needed one instance of the calculator, someone had made it a singleton. And in their web environment, this singleton wasn't scoped to a single request, it was a true global object, which meant when simultaneous requests were getting processed, they'd step on each other and throw off the iteration. And testing didn't find it right away, because none of their tests were simulating the effect of multiple simultaneous users.

The fix was simple- stop being a singleton, and ensure every request got its own instance. But it's also a good example of misapplication of patterns- there was no need in the client app to enforce uniqueness via the singleton pattern. A calculator that holds state probably shouldn't be a singleton in the first place.

[Advertisement] Utilize BuildMaster to release your software with confidence, at the pace your business demands. Download today!
Remy Porter