Dive Deep – Page 6 – Making Of Things

Lions And Tigers And Permutations, Oh My!

By Jud | July 20, 2017 | Comments 1 comment

This blog is turning into a bit of a “debugging adventure of the day”, which wasn’t the original intent, but whatever. I’ll get around to meatier posts someday.

This morning’s adventure was debugging a pretty serious issue with a web application where selections would not save. Initially it only manifest itself on Windows machines, so we thought Microsoft was to blame. Oddly, though, Chrome failed to work but Edge was fine. Weird.

Wanting to check a few other variables, we grabbed another co-worker’s Windows laptop, and it worked fine in Chrome. WTF!?! Nearly identical hardware, same OS, same browser, and same browser version, but one machine worked, and the other didn’t. Cleared caches, rebooted, etc. Same results.

But did you catch the word “nearly” there? Turns out there was a difference between the two laptops. One had a touchscreen, and the other didn’t. Fast-forward through an hour of slogging through a bunch of hacked together JavaScript code to support drag-and-drop on a variety of devices, and sure enough, the “non-mobile yet touchscreen enabled” case had its own special snowflake handler that wasn’t working correctly in Chrome.

Why you ask? Well, in some browsers, touch events are delayed by 300ms (this is so things like double-tap and dragging can be detected properly). This causes the mouse click event to go first, and when clicking on a button that submits the form, the form gets processed before the touch event can fire that needs to run and configure the inputs to the form submission. If you touch the button instead of clicking with the trackpad (a condition that only makes sense on a touch-enabled laptop vs a tablet), it works okay.

That means this situation only manifest itself on a touchscreen-enabled non-mobile device, in Chrome, when the user clicks the submit button with the trackpad vs touching the button. Can’t hardly blame QA for not finding that one.

The Devil Is In The Details

By Jud | June 16, 2017 | Comments 0 Comment

Software development is not for the faint of heart.

The SQL DELIMITER statement is particular to the mysql client tool, so you can’t use a standard dump file to bootstrap initialize a new database instance using mysqld –bootstrap. Eight hours later I figured out a workaround, namely exporting stored procedures directly from the mysql.proc table.
A single stray character can entirely break a critical piece of system functionality; finding and removing it required a late night from multiple team members.

And that was just yesterday.

Balance Of Probability

By Jud | June 14, 2017 | Comments 0 Comment

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.

Docker Fail

By Jud | June 12, 2017 | Comments 0 Comment

One of my favorite truisms in software development is the following:

“When two things aren’t the same, then they’re different.”

I don’t care how hard you work to make development and production environments the same, I don’t care how portable you think your programming language is across operating systems, and I especially don’t care about claims made on a product’s marketing material. Case in point:

[Docker] makes for efficient, lightweight, self-contained systems and guarantees that software will always run the same, regardless of where it’s deployed.

No doubt the Docker team has worked incredibly hard to make the above statement true, but nothing in life is guaranteed with 100% certainty. Last week I discovered that the cron utility will not execute any crontab or script that has more than one hard link pointed at it (don’t ask me why not, it just doesn’t). And due to the way Docker’s overlay filesystem works, the operating system can report a regular file as having multiple links. At least it does when the container is running under Kubernetes. But not always! When running with docker-compose on my Mac the crontab only reported one hard link, and thus cron worked great.

Took me nearly a day of fiddling to determine why the container worked great locally but failed in Kubernetes. Argh.

Adventures

By Jud | June 9, 2017 | Comments 1 comment

Yesterday the team spent most of the day debugging an urgent production issue. The root cause: a seemingly innocuous change made to a custom storage library eight months ago. Lesson learned: changes may have unintended side-effects.

And today I’m back to decompiling Java bytecode from a production server. The original source is long gone. Good times.

Winging It

By Jud | May 30, 2017 | Comments 0 Comment

I keep a running list of topics, but today I’m ignoring it and shooting from the hip. A stream of consciousness post, if you will.

Yesterday evening I added a couple new features to an Ionic app. I’m really appreciating the improvements brought by Angular 2; it’s made the architecture quite a bit cleaner than before, and adding new capabilities is quick and painless. I still have a ways to go before I fully grok observables, but I’m getting there.

Was talking with a musician friend of mine on Sunday about the difficulty of making meaningful progress on a project without having at least 2 continuous hours of focused time to work on it. Half hours here and there don’t cut it. That’s an important truth both for us nerds who try to do side work in our spare time. It’s also an important reminder for non-nerds who feel the need to interrupt the nerds in their charge.

Speaking of interruptions, nearly 6 hours passed since I wrote that past sentence due to an urgent production bug. Who knew when I woke up this morning that by noon I’d be decompiling Java classes from a production server. Yay!

Numbers Do Lie

By Jud | May 26, 2017 | Comments 0 Comment

The Internet is a funny place. Yesterday was the first weekday in some time that I didn’t write a post, yet I had the most page views in a single day since I created this thing. Apparently someone (or some-bot) in Canada decided to read every single post I’ve ever written. A roughly similar thing happened a few weeks ago, when a post I spent quite a bit of time on got only a handful of views, while the filler I wrote the next day got three times as much traffic. I’m not complaining, just observing that it can be difficult to predict how consumers will respond to a product.

I think there’s a lesson there for aspiring software developers (and really creators of all types). Don’t get too hung up on numbers or popularity. Don’t think less of yourself just because your app didn’t blow up like Facebook or Instagram (those guys will tell you that was luck as much as it was hard work). Simply do the best work you can.

When I decided to revive this blog, I wanted to post daily for two reasons. I figured it would draw more traffic to have more content, but more importantly, my writing muscles had atrophied and needed regular exercise. Ultimately this whole thing is for my own enrichment, but if it helps others, great.

Like Eating Your Vegetables, But Better

By Jud | May 8, 2017 | Comments 1 comment

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?

By Jud | May 6, 2017 | Comments 2 comments

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)

Early code sample — Based on where I found this at my parents’ house, I’m guessing age 8

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!

The Fire In Which We Burn

By Jud | May 3, 2017 | Comments 7 comments

Everything takes time.

Reading and responding to emails takes time
Checking Slack takes time
Updating JIRA takes time
Peer reviewing code takes time
Writing documentation takes time
Managing versions and branches takes time
Meetings and discussions take time
Keeping a workspace organized takes time
Updating a computer takes time
Addressing HR concerns takes time
Performance evaluations take time
Eating lunch takes time
Going to the bathroom takes time
Mental breaks take time
Thinking takes time

Plan accordingly (which also takes time).