DaedTech

Stories about Software

By

The First DaedTech Digest

I mentioned this idea in a post I wrote the other day, the idea of a digest style of post.  So today, I’d like to give it a try.

You see this sort of thing a lot, all over the place.  So-called planet sites have been around for a long time, aggregating community-related articles into a single place.  Examples include one of my personal favorites, the Morning Brew.

There’s just one difference in what I’m proposing.  Instead of gathering stuff that others have written, I’m going to digest the stuff that I’ve written.  In the last year, we’ve turned my paid blogging for other sites into a tech content business, taking blogging from a side hustle and hobby to a professional gig.  So, I write a lot of blog posts.

Historically, I’ve simply cross posted these with canonical linking, leading in with “editorial note: I originally wrote this post for…”  But I’m thinking of taking DaedTech in a bit of a different direction than just generalized software-oriented blog posts.  More on that later.

The point here is that, instead of pushing one of these cross posts out per day, I’m going to do a single digest post per week containing posts that I’ve made.  I have about 90 backlogged drafts in my folder, so at first it’s going to be posts I made some months back.  But sooner or later, I’ll catch up and give the posts I’ve published in the last week.

But anyway, without further ado, here’s the digest.

Some Posts to Check Out

  • This is a piece that I wrote for the Monitis blog.  It’s about threat modeling and the woes of being an e-retailer and guarding yourself against criminals and ne’er do wells.
  • I wrote a post for TechTown that was a primer about unit testing in C#.  It gives you a back to basics explanation, the value proposition, and the simplest imaginable examples of writing unit tests.
  • This is another post that I wrote for Monitis. It’s about the C# IEnumerable construct and how, if you misunderstand it, you can kill your site’s performance.  This has to do with how IEnumerable can encapsulate deferred execution, and that it only promises a strategy for obtaining items, rather than giving you those items.
  • I wrote this post for SubMain.  It’s about how something that’s seemingly inconsequential — spell checking your code (specifically, C#) is more important than you might think.  There are subtle things to consider that you might not have considered.
  • This post is actually going to become part of Microsoft’s official documentation!  Seriously, no kidding.  Bill Wagner wrote to Patrick and I about this post, and it’s now in their documentation build on Github.  Anyway, I wrote it for NDepend, and it’s a walk back through past major version of C#, reflecting back on nearly 2 decades of the language.  It was a fun journey down memory lane.

And, that’s it.   Happy reading, and happy Friday!

By

Unit Testing: Basics and Best Practices

Editorial Note: I originally wrote this post for the Stackify blog.  You can check out the original here, at their site.  While you’re there, have a look at their tools to help you track down and fix production issues.

A couple of year ago, I wrote a book about unit testing.  Now, I didn’t just sit down one day and decide to do it, and no big publisher commissioned me to do it.  The book started from humbler origins and grew somewhat organically.

It started as a series of presentations I did for groups new to the practice.  With more feedback and requests, it then grew into a blog post series and longer presentations.  Eventually, due to even wider demand, I made it into a book.

What was it that made this particular content so appealing, when no shortage of authors address this topic?  I feel pretty confident that it was the lead into the topic.  “You still don’t know how to unit test, and your secret is safe with me.”

When I started in this industry, only an avant garde fringe wrote automated tests for their code.  Over the last 15 years, however, that number has exploded, and the practice has become mainstream.  But “mainstream” does not mean “universal.”  Plenty of folks still do not have comfort with, or even exposure to the practice.  And yet, a form of peer pressure causes them to play that close to the vest.

So I reached out to these folks to say, “hey, no worries.  You can learn, and you don’t even have to climb too steep of a hill.”  I’d like to revisit that approach again, here, today, and in the form of a blog post.

Let’s get started with unit testing in C#, assuming that you know absolutely nothing about it.

Read More

By

.NET Code Documentation So Easy It’s an Afterthought

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 GhostDoc if you want automated documentation for your API.

Though I’ll talk today about .NET code documentation, I want to start further back than that. And by “that,” I mean further back than .NET. I realize that may date me somewhat, but please bear with me.

Most things in the programming world date back further than you’d think. For a dramatic example of this, consider functional programming. All the rage today, it actually dates back to the 60s in practice and 30s in theory. Speculating about the reason for temporal myopia would go beyond the scope of this post, but understand that this tendency toward myopia does exist.

With that in mind, let’s talk about some GUI builders.

A Tale of Two GUI Builders

Now we get to the part that predates .NET. I’m going to reach back into my early career and compare my relatively simultaneous experience with two GUI building technologies.

First, I encountered Swing, a Java GUI toolkit. While Swing did not include a GUI builder at the time, my project packaged it with one. I cannot remember its name for the life of me, but this thing was a train wreck. Moving controls around on a form caused the spewing of improbable amounts of code into my Java classes. Attaching handlers to GUI events only half worked, requiring wire up by hand. I had such struggles with it that I gave up and just hand-coded everything in Java.

Shortly after working on that project, I found myself saddled with a VB6 application. At the time, .NET actually existed, but nobody had ported this thing to it. So I used VB6. And I loved it.

That probably sounds as weird to hear as it feels to type, but there it is. Compared to my experience with Swing and its nightmarish GUI builder, this was a refreshing summer breeze. I could move controls around to my heart’s content, wire up events easily, and get stuff done.

Read More

By

Getting Started with Behavior-Driven Development

Editorial note: I originally wrote this post for the TechTown blog.  You can check it out here, at their site.  While you’re there, have a look around at the different training courses they offer.

You’ve probably heard of behavior-driven development (BDD).  However, if you’ve never practiced it, you may perceive it as one of many in a nebulous cloud of acronyms.  We have BDD, TDD, DDD, and ATDD.  All of these have a “D” standing for “driven” and another one standing for either “development” or “design.”  Apparently, we software developers really like things to drive us.

I won’t engage in a full “DD” taxonomy here, as this post concerns itself with behavior-driven development only.  But we will need to take a tour through one of these in order to understand BDD’s motivations and backstory.

Behavior-Driven Development Origins and Motivation

To understand BDD, we must first understand test-driven development (TDD).  Luckily, I wrote a recent primer on that.  To recap briefly, TDD calls for you to address every new thing you want your production code to do by first writing a failing test.  Doing this both verifies that the system currently lacks the needed functionality and gives you a way to later know that you’ve successfully implemented it.

With TDD, you deal in microtests.  These distinguish themselves by being quite specific and granular.  For instance, you might assert that you get a null reference exception when invoking a method with a null parameter.  You’ll pardon non-technical project stakeholders for a distinct lack of interest in these microtests.

BDD evolved from asking the question, “Why don’t we do this for tests that the business might care about?”  It follows the same philosophical approach and logic.  But instead of worrying about null parameters and exceptions, these tests address the system’s behavior at the capability or feature level.

Behavior-driven development follows the TDD cadence: express a current system deficiency with a failing test. But this time the failing test is, for example, when I deposit money into my checking account, I can see the reflected balance.  Work then proceeds on that feature until the test passes.  At this time, the team considers the card complete.

Read More

By

CodeIt.Right Rules, Explained Part 5

Editorial note: I originally wrote this post for the SubMain blog.  You can check out the original here, at their site.  You can also read a lot more, both on that blog and in their documentation, about CodeIt.Right’s analysis rules.

Today, I’ll do another installment of the CodeIt.Right Rules, Explained series.  This is post number five in the series.  And, as always, I’ll start off by citing my two personal rules about static analysis guidance, along with the explanation for them.

  • Never implement a suggested fix without knowing what makes it a fix.
  • Never ignore a suggested fix without understanding what makes it a fix.

It may seem as though I’m playing rhetorical games here.  After all, I could simply say, “learn the reasoning behind all suggested fixes.”  But I want to underscore the decision you face when confronted with static analysis feedback.  In all cases, you must actively choose to ignore the feedback or address it.  And for both options, you need to understand the logic behind the suggestion.

In that spirit, I’m going to offer up explanations for three more CodeIt.Right rules today.

Read More