Tech Talk with Toni

One of these things are not like the others Today's post is inspired by a minor problem I encountered in an automated solution. An unaccounted-for scenario arose, much like the winds that famously brought down the Tacoma Narrows Bridge, leading to an unexpected result. After examining the input values used in the calculation, I pinpointed the cause of the error. This experience made me appreciate what my university lecturers were trying to instill in us: always account for edge cases. A friend of mine had a motto—he aimed to make his code 'monkey-proof,' ensuring that even nonsensical input wouldn't break his program. I believe that building resilient solutions should always be the goal, especially for systems intended for reuse. By considering as many edge cases as possible from the outset, you'll make your solutions far more maintainable in the long run. Now, here are some ways to find edge cases: Know Your Ranges What is the expected range of values for your data...

  This error's name originated from Room 404 At first, I saw error messages as coding villains, ready to ruin my day with red underlines. As soon as I see one, I panic and do everything humanly possible to get rid of it. But now, I view error messages as superheroes here to help me debug my code. The inspiration for this week's post comes from a problem I encountered on the job with code. The Problem Errors were introduced into SQL queries that were needed to generate a crucial report due to updates I made.  However, I didn't know exactly where to start the debugging process, as all the scripts were being executed dynamically.  Whenever one of these queries failed, the entire process would throw a generic error message that did not specify where the error occurred. The brute force approach of combing through dozens of scripts to find a handful of syntactical errors would have been stressful and time-consuming. The Solution Instead of manually looking for the problem, I wa...