Success at the Fault of Exceptions – InApps 2022

This one day, back in the early 2000s, is still burnt into my memory as an exemplification of all that is programming. Everything I was working toward had ground to a halt because of some unspecified error. Whatever weird CMS templating language I’d been forced to use (that idiot who’d had the job before me had adopted it, you see) gave me an error without specifying what or where the error was. All I really knew was that the code was broken and in the end, it was my duty to find it and figure out why. I spent much of the day focusing on the logical structure of the code and what it was doing, but in the end, it was something else entirely. It was almost as if, only once my brain and eyes had tired enough from looking for the problem was I able to finally see it.

About 30,000 lines of code and hours of hand-wringing concentration later, I finally found the culprit — a missing semicolon.

Ever since that day, I’ve felt that this is near to the true nature of coding; coding is all about considering all cases and finding the exceptions. Consider all of the possibilities — especially those you’ve previously failed to consider. It can be the tiniest detail to take everything down and leave you with a fault exception where before you’ve only experienced success.

We’ve written about this general idea before, but this week two more articles find their way to popularity dealing again with a similar theme. First, developer Tom Wright offers up his musings on how Anglocentrism broke his tests and how ignoring localization — accounting for the different data formats and practices of different locations — should only be done at your own peril.

“I’d written a load of conformance tests that included example output,” Wright writes. “What I hadn’t factored in was how many of these were dependent on my locale. These would potentially fail on computers with different locales.”

Wright goes on to describe how a test that had been working just fine for himself and several others for over a year suddenly broke when, you guessed it, someone from elsewhere used it.

“It all went wrong when we were joined by a Slovak developer, Marek. Slovakia, I discovered, is one of the many countries where they don’t use a full stop (“period” to my American friends) as the decimal separator,” he explains.

Of course, that’s just one example of an exception to the rule. The second article this week comes to us from developer Andrei Cioara, who advises others to use AdBlocking in your dev environment.

“I used to turn off all browser extensions while developing Web Apps locally to avoid unintended code injections into my pages,” Cioara explains. “However, a few months ago, while I was writing an integration for a client […] I started receiving bug reports that some of the images on our page are not loading. Strangely, everything worked fine for me…”

Spoiler alert, but it was the ad blockers everyone else was using at fault here, which Cioara had intentionally avoided running. “It is your job as a Web Developer to make sure that you deliver the best possible experience to as many of your users as possible, regardless of whether or not your business is supported by ad-related revenue,” Cioara writes, noting that the rules of ad blockers are always changing so the only real solution is to actively run one in your testing to ensure they don’t break your product.

Of course, with any of these cases, you could attempt the exact opposite approach, right? Force the user to meet your requirements. Require commas over decimals. Force users to turn off ad blockers. What have you. Chances are, however, there’s another exception waiting around the corner.

This Week in Programming

• GitHub Reconsiders: One final bit on the topic of exceptions, GitHub seems to be finding exception with its past thinking this week, as two announcements offer some amendments and adjustments to previous decisions. First, the company has offered an update on brownouts and updates on GitHub Services, which it had initially said it would brownout for a week. “After a lot of thought and discussion, we’ve decided that a week-long brownout would be too disruptive for everyone. Instead, we are going to do a gradual increase in brownouts until the final blackout date of January 31st, 2019,” the company writes in a blog post. Make sure to click through for specific dates of note if you happen to use GitHub Services. Meanwhile, GitHub also posted about its plans to postpone stricter validation, which it had previously announced. Specifically, the plans were for stricter validation in its REST API and after “careful consideration” the company says it has “decided to not roll out stricter validation at this time.” Nonetheless, GitHub says it still believes that “stricter validation would have a positive impact on our REST API overall and [they] are looking for alternative ways to introduce it.”
• AI Hub and Kubeflow Pipelines: Google says it is trying to make AI “simpler, faster, and more useful for businesses” with the introduction of AI Hub and Kubeflow Pipelines. The two tools, Techcrunch writes, are “designed to help data scientists put the models they create to work across their organizations.” According to the article, “pipelines are essentially containerized building blocks that people in the machine learning ecosystem can string together to build and manage machine learning workflows,” while the AI Hub is “as the name implies is a central place where data scientists can go to find different kinds ML content including Kubeflow pipelines, Jupyter notebooks, TensorFlow modules and so forth.” According to Google, “although there are approximately 20 million developers worldwide, there are only 2 million data scientists.” These tools, the company says, are intended to help them work more efficiently. Currently, AI Hub is available in Alpha, while Kubeflow Pipelines are available immediately.

• Shrinking Code is GR8 with R8: Google also announced this week the availability of R8, the new code shrinker in Android studio 3.3 beta. R8 helps developers shrink APK size by “getting rid of unused code and resources as well as making your actual code take less space.” As JAXEnter notes, R8 “shrinks, desurgars, and dexes in one step […] faster than Android’s current standard, Proguard, with a more efficient output size. Basically, it detects and removes unused classes, fields, methods, and attributes from your packaged app. It even goes through the included code libraries to sift through unused files, making it easier for developers to get around the 64k reference limit.” R8 is currently available in preview.
• Sometimes, It’s the Little Things: And finally this week, an announcement of non-monumental proportions — GitHub says that the latest release of GitHub for Visual Studio is now saving drafts of comments. We include this because we know no greater pain that crafting the perfect comment, only for it to disappear into the ether. Just click on the blog post and watch the wonderful little animations of when they click on the back arrow, then the forward arrow, and the comment remains. Offering more details than you might expect, they explain that “as they are written, comment drafts are saved to a SQLite database and displayed when a user comes back to them later. Now, in-progress comments will never be lost again.” Hallelujah.

Feature image via Pixabay.