DaedTech

Stories about Software

By

APIs and the Principle of Least Surprise

Editorial note: I originally wrote this post for the Monitis blog.  You can check out the original here, at their site.  While you’re there, have a look at some of the other authors for their blog.

I remember something pretty random about my first job.  In my cubicle, I had a large set of metal shelves that held my various and sundry programming texts.  And, featured prominently on that shelf, I had an enormous blue binder.

Back then, I spent my days writing drivers and custom Linux kernel modules.  I had to because we made use of a real time interface to write very precisely timed machine control code.  As you might imagine, a custom Linux kernel in 2005 didn’t exactly come with a high production quality video walking users through the finer points.  In fact, it came with only its version of the iconic Linux “man pages” for guidance.  These I printed out and put into the aforementioned blue binder.

I cannot begin to tell you how much I studied this blue binder.  I pored through it for wisdom and clues, feeling a sense of great satisfaction when I deciphered some cryptic function example.  This sort of satisfaction defined a culture, in fact.  You wore mastery of a difficult API as a badge of honor.  And, on the flip side, failure to master an API represented a failure of yours.

Death of “Manual Culture”

What a difference a decade makes.  No longer do we have battleship gray windows applications with dozens of menus and sub-menus, with hundreds of settings and thousands of “advanced settings”.  No longer do we consider reading a gigantic blue documentation binder to be a use of time.  And, more generally, no longer do we put the onus of navigating a learning curve on the user.  Instead, we look to lure users by making things as easy as possible.

Ten years ago, a coarse expression described people’s take on this responsibility.  I’ll offer the safe-for-work version: “RTM” or “Read the Manual.”  Ten years later, we have seen the death of RTM culture.  This applies to APIs and to user experiences in general.

Read More

By

Manual Code Review Anti-Patterns

Editorial Note: I originally wrote this post for the SubMain blog.  You can check out the original here, at their site. While you’re there, take a look around at some of the other posts and at their offerings.

Today, I’d like to offer a somewhat lighthearted treatment to a serious topic.  I generally find that this tends to offer catharsis to the frustrated.  And the topic of code review tends to lead to lots of frustration.

When talking about code review, I always make sure to offer a specific distinction.  We can divide code reviews into two mutually exclusive buckets: automated and manual.  At first, this distinction might sound strange.  Most reading probably think of code reviews as activities with exclusively human actors.  But I tend to disagree.  Any static analyzer (including the compiler) offers feedback.  And some tools, like CodeIt.Right, specifically regard their suggestions and automated fixes as an automation of the code review process.

I would argue that automated code review should definitely factor into your code review strategy.  It takes the simple things out of the equation and lets the humans involved focus on more complex, nuanced topics.  That said, I want to ignore the idea of automated review for the rest of the post.  Instead, I’ll talk exclusively about manual code reviews and, more specifically, where they tend to get ugly.

You should absolutely do manual code reviews.  Full stop.  But you should also know that they can easily go wrong and devolved into useless or even toxic activities.  To make them effective, you need to exercise vigilance with them.  And, toward that end, I’ll talk about some manual code review anti-patterns.

Read More

By

DaedTech Now Brought to You Over SSL

I’ve had an item on DaedTech’s Trello board for a good, long time now.  Switch over to using SSL.  And, fear not those of you who enjoy this blog!  You can now browse confidently, without worrying that some impostor is feeding you misinformation about expert beginners, journeyman idealists, and other random neologisms that come out of my twisted mind.  Take that, internet evildoers.  I can almost sense everyone’s relief from here.

What Does This Actually Mean?

I started to call this header, “How SSL works,” but I got bored before I even finished typing that sentence fragment.  You can read a primer about it, if you’re so inclined.

The 10,000 foot explanation is that it’s a mechanism for making your browsing a private conversation between you and DaedTech.  For instance, say that you were sitting in an airport a week ago, and you browsed to my blog.  Your HTTP request and DaedTech’s response would happen in plain text.  Anyone else in the airport sufficiently motivated to do so could eavesdrop on the back end forth and even execute a man in the middle attack.  As I said before, they could have deliberately fed you misinformation about expert beginners.

Or, perhaps more importantly, they could eavesdrop on your credentials if you had an account on my blog.  That’s really the idea of SSL — it aims to make communication private and not subject to these sorts of interposition and alteration schemes.  By installing SSL on my site, I have now prevented that from happening.  When you browse DaedTech, you now do so over HTTPS, all communication encrypted and my SSL certification verified.  This latter concern means an outside agency says, “you can believe that this is DaedTech and not an impostor.”

Contrary to the green locks and the “secure” wording in the URL bars, however, this does necessarily mean “you’re all good.”  Scott Hanselman summed this up well in a tweet.

Read More

By

A Look at the History of RDBMS

Editorial Note: I originally wrote this post for the Monitis blog.  You can check out the original here, at their site.  While you’re there, take a look at Monitis’s offering for all things related to website and networking monitoring.

If you had to pick a unifying technology to bring all developers together, then you could do worse than selecting the relational database.  Of course, no topic can truly unify all developers.  But most of us that have written code for any length of time, have at least dealt with a database in some capacity or another.

And, why not?  We could boil software down to two core components: data and behavior.  So, just as we all learn programming languages to express behavior, we also learn some means of recording and persisting our precious data.

When we put enough of this data together in some organized format, we have a database.  When we organize that database in a manner known as “relational,” we have a relational database.  And then, when we add functionality for managing and optimizing access to that relational data, we have a relational database management system (RDBMS).

No doubt you have some familiarity with these products.  They include such industry mainstays as Oracle, Microsoft’s SQL Server, PostgreSQL, and MySQL, among others.

In fact, they blend so seamlessly into the scenery that you can easily take them for granted.  But where did they come from and why?  And, how have they evolved over the years?  Today, let’s take a look back at the history of the RDBMS.

Read More

By

Static Analysis to Hide My Ignorance about Global Concerns

Editorial Note: I originally wrote this post for the SubMain blog.  You can check out the original here, at their site.  While you’re there, take a look at CodeIt.Right to help you automate elements of your code reviews.

“You never concatenate strings.  Instead, always use a StringBuilder.”

I feel pretty confident that any C# developer that has ever worked in a group has heard this admonition at least once.  This represents one of those bits of developer wisdom that the world expects you to just memorize.  Over the course of your career, these add up.  And once they do, grizzled veterans engage in a sort of comparative jousting for rank.  The internet encourages them and eggs them on.

“How can you call yourself a senior C# developer and not know how to serialize objects to XML?!”

With two evenly matched veterans swinging language swords at one another, this volley may continue for a while.  Eventually, though, one falters and pecking order is established.

Static Analyzers to the Rescue

I must confess.  I tend to do horribly at this sort of thing.  Despite having relatively good memory retention ability in theory, I have a critical Achilles Heel in this regard.  Specifically, I can only retain information that interests me.  And building up a massive arsenal of programming language “how-could-yous” for dueling purposes just doesn’t interest me.  It doesn’t solve any problem that I have.

And, really, why should it?  Early in my career, I figured out the joy of static analyzers in pretty short order.  Just as the ubiquity of search engines means I don’t need to memorize algorithms, the presence of static analyzers saves me from cognitively carrying around giant checklists of programming sins to avoid.  I rejoiced in this discovery.  Suddenly, I could solve interesting problems and trust the equivalent of programmer spell check to take care of the boring stuff.

Oh, don’t get me wrong.  After the analyzers slapped me, I internalized the lessons.  But I never bothered to go out of my way to do so.  I learned only in response to an actual, immediate problem.  “I don’t like seeing warnings, so let me figure out the issue and subsequently avoid it.”

Read More