I’ve said before that I like badges, especially ones that take real effort to achieve. While it may be my first “gold-level” badge on Stack Overflow, I can’t really say it took skill, just dogged persistence (and liberal use of Slack’s /remind command):
Recently I was attempting to set up automatic payments with a utility company via their website. I dutifully entered my bank’s routing number and my account number, but when I tried to submit, I was told the routing number was invalid. I double-checked it with the bank’s website, but I still got the error.
Being something of a nerd, whenever I run into trouble like this on a website, I open up Chrome’s dev tools to see what’s going on. Turns out the UI was sending the routing number to an API endpoint that ensured it belonged to a real bank before submitting the form. For whatever reason it appeared this API didn’t have my bank in its database.
Which made me wonder if I could twiddle the site’s Javascript to skip this API call and submit the form anyways. Lucky for me they didn’t perform any minification, and it was straightforward to bypass this verification step. When I did so, the form submitted just fine and told me automatic payment setup was complete. I suppose I’ll find out on my next billing cycle if it worked, but I bet it will.
Three takeaways from this little adventure:
Every branch that bears fruit, he prunes it so that it may bear more fruit.
– John 15:2
Deleting code feels so good, especially when it’s code I’ve written. It’s an emotion predicted by the Creator’s Curse, and it also make sense under the lens of this article, which challenges developers to write code that’s “easy to delete”.
Too often, especially in academic settings, or with inexperienced engineers who don’t have the experience of the dirty hacks required to keep an actual real-life system running, there’s a view that good software engineering practices are like the Ten Commandments, never to be violated. But for every rule, there’s any number of exceptions, and I loved the way the author laid out these tensions.
A popular discussion topic these days is how society will change due to the COVID-19 pandemic. One obvious likely outcome is even more will be accomplishable online, for example, the AWS certification exam I took from the comfort of my armchair this past Saturday morning. I thought I’d share my experience, and a few specific recommendations (in bold).
The process started with the normal scheduling workflow via the AWS Training website. Once that was complete and I paid the fee, I got an email with a link to instructions on how to run a system test. The recommendation was to do this right away, which I did. This involved installing a local application, verifying my laptop’s webcam and microphone worked, and testing my Internet bandwidth. Given that the application will completely take over your machine, and you must close all other running processes, I’d recommend using a personally-owned computer for this, and not a work computer (especially if you don’t have local admin).
Also as part of the above process, I had to take a picture of my face, my driver’s license (both sides), and four photos of the location where I’d take my exam, one from each of the front, back, left and right. A link sent to my phone via SMS guided me through these steps (so have your phone handy); it went quicker than I expected, and the photos were automagically submitted. Nice!
The day of the exam, about 15 minutes before my scheduled time, I closed everything on my personal laptop, and launched the client app. And here’s where I had my first hiccup: the app required that I upgrade to the latest version. This meant re-downloading and re-installing, which was annoying; I wished the app could have streamlined that process. Once the update was done, I had to go back through the entire system test process (including taking all the photos mentioned earlier). This was annoying, and made me wonder if the earlier test was even worth taking. At minimum, you want to be sure to get started at least 15 minutes before your scheduled start time in case you run into issues.
Once I got upgraded and back through the system test, my webcam became active and indicated I was being recorded. From this point you cannot leave the room (or move out of view of the camera), or open any other applications. I had to wait in this state for about 5 minutes before I was put in contact with a proctor, first via chat, and then via phone call. Be prepared to sit in silence for a bit while you wait. For a final verification I had to do a sweep of the room with my webcam to show it was empty of both other technology and other people. Be sure at this point that everything and everyone is out of the room. I even unplugged my extra monitor, just in case.
As I tried to launch the actual exam, I hit another problem. The app detected instances of chrome running in the background, even though I thought I’d closed everything. I had to go into activity monitor and kill them all before the test would launch. So, it’s worth looking through activity monitor right before you start to avoid this hangup (though the proctor was friendly and patient with me, which I appreciated).
(Oh, and speaking of things to do right before you start, use the restroom and get a drink of water right before you settle in; absolutely no breaks or food or drink are allowed).
Finally I could load the exam and begin. It’s a bit nerve-wracking to be video-recorded, but after a few minutes I tuned it out. You do need to be conscious not to look around the room, else the proctor might ping you to hold still (this didn’t happen to me, but I read about it). The test interface itself was pretty much like the in-person experience, with the ability to skip ahead, flag questions for review, etc.
Once I completed the exam, there was a survey, just like the in-person experience, and I was given the results (I passed, woot). Then the app closed and I was done. Piece of cake.
Even given the gotchas, I’d say the experience is easier and more convenient than scheduling a time with an in-person testing center, driving there, etc, if for no other reason than the available time slots for online proctoring ranged across all days of the week, and nearly all hours of the day (want to take your exam at 3am? knock yourself out). I’ll definitely use this online proctoring again, probably exclusively, as long as I have option to do so.
Have you been thinking about getting AWS certified? If so, I’d encourage you to go right now and get a date on the calendar. You’ve nothing to lose, and it’s now easier than ever.
I wrote yesterday’s post almost a full day in advance, which hadn’t happened before in the (admittedly short) history of this blog. It felt really nice when my daily 9am writing reminder went off to simply click “Publish” and get on with my day, instead of hitting snooze and hoping I get back to it later.
It brought to mind my sophomore year of college, where I learned the value of discipline. My fiancée was at a school ten hours away, and I had a randomly assigned roommate with whom I had nothing in common (and despite his pedestrian physical appearance managed to have three simultaneous girlfriends for most the year, but that’s a different story). I also had a class schedule that finished by 2pm every day.
Since I had little reason to get back to my lonely little dorm room so early in the day, I got in the habit of hanging out in the library studying until dinner. I quickly discovered that this routine completely freed my evenings and weekends of schoolwork. And that was awesome. I wasted gobs of time playing video games during those hours, and didn’t feel the slightest bit bad about it, because my work was done.
The past couple of days I wrote about the dangers of providing too much functionality. In a fit of cognitive dissonance I now want to contradict myself and demand dangerous power when it suits my needs.
I’ve been working the past week to get a particularly gnarly application running in a set of docker containers. There are over a dozen services, plus a Rabbit queue and a database. Many of the services do not handle database connection failures in a robust way. During my testing I wanted a simple way to ensure they waited a bit before trying to connect, as the database container needs a minute or so to seed itself and get ready for connections.
Unfortunately,docker-compose does not have any form of manual startup delay feature. This is by design, as the Docker team (rightly) argues that having services intolerant to connection failure is a bad thing. However, it’s frustrating to not have the power to do the wrong thing in the short term.
Then again, it turns out it wasn’t too tough to augment my compose file with a depends_on clause that includes a health check, which is a more reliable solution anyways.
Yesterday we looked at how theology can inform software development, today we consider physics. The second law of thermodynamics states:
The total entropy of an isolated system can only increase over time.
This statement has a specific technical meaning which is worth investigating on its own merits, but the general principle is that systems tend towards decay. Software systems are no exception to this rule, variously described as software entropy or code rot. Anyone who has worked with software for any length of time knows firsthand how clean code quickly devolves into spaghetti.
How can one combat this seeming inevitability? The key lies in the second law and the little phrase “of an isolated system”. Essentially entropy can be held steady or even reversed in a system if it is properly influenced from outside that system. In the world of software this means that every time a change is made, one should not just do the minimum required to implement the change, because any edit likely increases entropy. Instead the developer must go further to leave the code better than she found it (what Uncle Bob described as the Boy Scout Rule). The best developers work to make this second nature.
Yes this takes more time in the short run. But it’s essential to the long-term health of a software system.
Yesterday I was speaking with a fellow engineer about the state of our new user interface implementation. We’d crossed a major functionality threshold, but there were still several obvious bugs. I argued that the significance of the functions that were working merited deploying to our integration server for others to see, but he resisted saying that he’d rather wait until a couple of the blatant problems were ironed out.
The above is a common conundrum for developers. Put your work out there for others to see too soon, and they’ll be quick to point out all the flaws. Wait too long, and managers start breathing down your neck because they’re not seeing tangible results.
Personally, I think the wise manager understands the idea of a work in progress, and should appreciate seeing said progress without getting overly critical of early blemishes. It’s a bit like posting photos of a newborn baby. Obviously everyone loves their little nugget, but reality is most newborns aren’t super cute in their first couple of days. But would anyone ever dare point that out to proud parents? Let’s surely hope not! The birth of a child is a momentous event to be celebrated; there’s plenty of time later for the kid to grow into his adorableness.
Likewise a software application. Publish early, and let that baby grow!
Don’t think I’ll normally write on weekends, but thought it worth stopping by to say so, lest my throngs of anxious readers go wondering.
“The making of things is in my heart from my own making by Thee.” – J.R.R. Tolkien
Hi, I’m Jud. It’s been several years since I’ve blogged consistently, but having been inspired by John Sonmez’s Soft Skills, I’ve decided to get back in the game.
The blog title comes from the story of the creation of the dwarves by Aulë in Tolkien’s The Silmarillion. I love the idea that as God’s image bearers we are to called to be sub-creators in the universe He has made. Though we often fall short of His ideals, somehow He still graciously accepts our work.
Specifically I see my calling in the area of software craftsmanship, and thus I expect topics here to hew fairly close to the world of programming, though I’m not promising there won’t be a few rabbit trails from time to time. Hopefully what I write here will be useful to some, or at least mildly entertaining.
And with that, time’s up for today. Tomorrow expect my first “real” post, on why I love Python.