Three Things I Like
I like AWS. So much so, I decided to work for them.
I also like Python, as I’ve said many times.
If you want to learn them both in a beautiful amalgam, consider the Learn Python On AWS Workshop.
We’re All In This Together
I went far too many years into my career before truly trying to understand networking, despite it being an increasingly common source of problems. If I could give younger self some advice, I’d recommend taking some time to learn networking.
In that spirit I present to you How DNS Works, a “fun and colorful” comic that describes in detail the operation of the Domain Name Service. Enjoy!
Badges Badges Everywhere
I’m a sucker for gamification, so when I saw today’s announcement that AWS Certification badges could now be collected and published on a little profile page, I was all over it.
Nine certs in nine months so far, and I’m taking a tenth exam tonight. Wish me luck!
Tests In The Time Of Corona
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.
Two Days In A Row?
Back in my days working for a large defense contractor, it was understood that as a developer became senior she would get involved in writing proposals. At the time I thought it an odd expectation; shouldn’t developers stick to doing what they do best, i.e. writing code?
But now I see the wisdom in getting engineers more involved in the process of winning new business. For one thing, it forces them to write, which is not a bad thing, even though it isn’t always fun. Secondly, it helps build relationships between engineering and sales, two departments which are often at odds (this is probably worthy of its own post, stay tuned for that). Finally, it gives them insight into the kinds of features customers are asking for, and allows them to be a part of suggesting creative solutions for those features.
So yeah, I’m a proponent of proposal writing. And in a completely unrelated note, I’ve got a big spreadsheet of proposal questions I need to divvy up among the team for responses. Who’s with me?
Be A Polyglot!
A couple of days ago a colleague of mine was reading out loud some code he was debugging, and I could have sworn he was direct quoting from Execution In The Kingdom Of Nouns.
That story is one of my favorite warnings against the notion that software development is a “one size fits all” proposition. There’s great value in being fluent in a number of tools and approaches, and using the right tool for the job. Can this be taken to an unhealthy extreme? Of course, but in general the benefits outweigh the drawbacks.
Ain’t No User Here
Here’s a new one. I was debugging a problem with a web server that hadn’t been used in a while that was allowing users to log in, but failing to perform a number of other functions (gotta love an API that happily returns a 200 OK even though it’s clearly not working because there’s no data in the response). No one could think of anything that had changed, but clearly something had.
After some spelunking through logs, I found some DB permissions errors. Obviously some DB calls were working, so that was odd, as I knew credentials were only specified in one place.
Another hour of research later, I discovered that MySQL views run as the user who created them, not the user who queries them. This actually makes sense for use cases where you want to give controlled read access to parts of the DB to a less-privileged user. Logically then, if that user is deleted, the view fails to run. And in this situation that’s exactly what happened.
There’s a number of lessons to be learned from this situation:
- A user probably should fail to delete if it owns other objects in the database. Otherwise unexpected side-effects occur.
- Accurate error messaging is essential to debugging. When trying to run the view, I got a simple “user does not have permission” error, which told me nothing about the underlying problem, which meant another hour or two of research. This goes for APIs especially. Please know when to use a
4XXvs.5XXerror especially, and even better learn the subtle differences between502,503, and504, and when each should be used. - Don’t try to diagnose problems on Friday afternoons before holiday weekends. You’re asking for trouble.
Balance Of Probability
Back in college I co-authored a paper entitled “A Probabilistic View of Certain Weighted Fibonacci Sums” (available here). Looking back on it, I wonder if that particular combination of words had ever been used together before. Contrast that to a sentence like “Could you go to the store and pick up some milk?” Certainly that combination of words has been used many times.
All this was brought to mind after I uttered the following this morning:
“For the purposes of our system, both syntactic and semantic errors should cause input to be rejected as malformed.”
Do you think that sentence has ever been uttered before? What about your average everyday statement? How might we go about analyzing such a thing? It’s these questions that will kick off my first significant blog series, “The Tyranny Of The Finite”, which I hope to start next week.
Until then, today’s challenge is to go out and use a sentence that is unlikely to have ever been said before.
Like Eating Your Vegetables, But Better
Good software engineers read. And not just technical blogs or books on coding, but on all manner of subjects. Politics, mathematics, philosophy, science, history, and theology have much to contribute to the work of professional software development. But even more important to cultivating a healthy creative mind is the reading of fiction.
Maybe it’s just me, but I feel that a rich diet of fiction has fallen out of favor in our culture, especially in contrast to the consumption of technical information. That’s unfortunate, for stories have a unique power to shape the mind. For me, classic science fiction in particular has inspired me to consider how technology can be of benefit to humanity, and warned me of ways it might be a danger. No O’Reilly book is going to tell you that.
While I’m on the topic, can I say how much it bothers me that we categorize books as “fiction” and “non-fiction”? Those are horrible labels. Novels and other stories can communicate truth in a myriad of ways, and it’s quite possible for non-fiction to be either mistaken or outright false. If you tell me “I only want to read things that are real, not fake” I will absolutely make fun of you. Consider yourself warned.
Writing On A Saturday?
Show yourself grace, but get back on the horse as soon as possible, right? Fortunately I happen to have some free time this morning. Did the breakfast dishes while listening to some Pink Floyd, which took me right back to high school when I was an obsessive fan (circa “The Division Bell”). It got me reminiscing as well about the various kinds of software development I’ve done over the years. Here’s some significant milestones:
- Age 4: Dad buys our family its first computer, a TI-99/4A
- Age 5: Someone gives me a green paperback with a bunch of Basic programs; I spend hours typing them into the computer and figuring out how to print the American flag in ASCII characters, among other things
- Age 7: I’m a regular at the local library’s “programming” section, and start writing simple games (still on the TI computer, and still all in Basic)
- Age 9: My first upgrade: a Tandy 1000 TL/2 from Radio Shack; within a few days of having it at home I inadvertently format the boot disk, bricking the machine
- Age 10: Now having the ability to save programs to floppy disk, I get pretty into QuickBASIC, especially fiddling with the game Gorillas
- Age 11: We upgrade again, to a Tandy 386, with an internal hard drive and VGA graphics; somehow my parents think it’s a good idea to put the computer in my bedroom
- Age 12: I teach myself C, and begin memorizing powers of 2 (up to 65,536) and digits of Pi (3.14159265)
- Age 14: I take a correspondence course in Pascal, where I learn legitimate structured programming; lacking email or the Internet, I printed out code and mailed it to my teacher
- Age 16: Wanting to keep a secret journal, I write an encryption algorithm (a substitution cipher that would have worked reasonably well had I not used Pascal’s built-in pseudo-random number generator); but it was enough to keep my sister out
- Age 17: The Internet happens; “hijinks” ensue of which I will speak no more
- Age 18: Now running a Pentium 2, my dad comes home from work to find I’d completely disassembled the machine; he was not pleased, but I put it right back together again without issue
- Age 19: I take my first college course (C programming); it was interminably boring
- Age 20: VisualBasic comes so quickly to me that I finish the entirety of the class’s projects in a couple of weeks; I was so brazen I told the professor I had no intention of coming to class the rest of the semester except to take exams (still got an A)
- Age 21: Compilers, number theory, combinatorics, and linear algebra give me all kinds of new programming ideas; I spend gobs of my free time optimizing an algorithm to compute the largest possible determinant of an nxn binary matrix
- Age 22: I write a Monte Carlo Simulation to determine if there’s an advantage to having the first turn in Monopoly (spoiler alert: there is); I also get hired by TRW
- Age 23: My boss hands me a book on Ada and tells me I have 2 weeks to learn it; I do so by porting a bunch of my college work, in particular a Number Jumbler solver
- Age 24: During my time at graduate school I make side money doing LaTeX typesetting
- Age 27: Now back at Northrop Grumman, I build an algorithms doing terrain analysis and flight path optimization (still in Ada)
- Age 28: Ada goes the way of the dodo, and I’m porting stuff to C; I’m also starting to get into mapping software and learn the “right” way to compute distances on the Earth’s surface
- Age 29: I write my favorite single piece of code ever (ask if you’re curious)
- Age 30: My first visit to San Diego, where I give a presentation on my flight path algorithm
- Age 31: I spend way too much time working on a huge proposal that we end up not submitting
- Age 32: We move to San Diego and I get my first taste of technical leadership; I also start learning the basics of HTTP API design
- Age 33: Thinking of making a job change, I go to my first interview since college; it does not go well, and I decide to take a couple classes on web development at SDSU to beef up my resume
- Age 34: I convince my management to buy an 84″ touchscreen for our mapping application; we make the interns assemble the stand
- Age 35: After nearly 13 years, I take my second job at Everyone Counts who I somehow tricked into believing I knew Java (which I’d learned in college but hadn’t seriously used since)
- Age 36: I mistakenly reveal I took a class in Perl at SDSU, which I eventually use to become the technical lead for the company’s voting application
- Age 37: It’s a year of learning, as I get a Code School account and get smart(ish) on Angular, Node.js, and Docker, among other things
- Age 38: I revive this blog and decide to write a bulleted list of my history of software development
Well, that was fun (for me, at least); I probably could have doubled the length, but I’ve already spent too much time on it. If you’ve read this far, I thank you!