Skip to main content

A Single Mortgage

2 months 2 weeks 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

The EFF's 'Certbot' Now Supports Six-Day Certs

2 months 2 weeks ago
10 years ago "certificate authorities normally issued certificate lifetimes lasting a year or more," remembers a new blog post Thursday by the EFF's engineering director. So in 2015 when the free cert authority Let's Encrypt first started issuing 90-day TLS certificates for websites, "it was considered a bold move, that helped push the ecosystem towards shorter certificate life times." And then this January Let's Encrypt announced new six-day certificates... This week saw a related announcement from the EFF engineering director. More than 31 million web sites maintain their HTTPS certificates using the EFF's Certbot tool (which automatically fetches free HTTPS certificates forever) — and Certbot is now supporting Let's Encrypt's six-day certificates. (It's accomplished through ACME profiles with dynamic renewal at 1/3rd of lifetime left or 1/2 of lifetime left, if the lifetime is shorter than 10 days): There is debate on how short these lifetimes should be, but with ACME profiles you can have the default or "classic" Let's Encrypt experience (90 days) or start actively using other profile types through Certbot with the --preferred-profile and --required-profile flags. For six day certificates, you can choose the "shortlived" profile. Why shorter lifetimes are better (according to the EFF's engineering director): If a certificate's private key is compromised, that compromise can't last as long. With shorter life spans for the certificates, automation is encouraged. Which facilitates robust security of web servers. Certificate revocation is historically flaky. Lifetimes 10 days and under prevent the need to invoke the revocation process and deal with continued usage of a compromised key.

Read more of this story at Slashdot.

EditorDavid