DaedTech

Stories about Software

By

Keep Your Codebase Fit with Trend Metrics

Editorial Note: Thanks to everyone who voted for a Developer Hegemony Cover.  I’ll tabulate the official results soon, but it looks like the dark cover is the clear favorite!

Second Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, take a look at the new version of NDepend.

A while back, I wrote a post about the importance of trends when discussing code metrics.  Metrics have impact when teams are first exposed to them, but that tends to fade with time.  Context and trend monitoring create and sustain a sense of urgency.

To understand what I mean, imagine a person aware that he has put on some weight over the years.  One day, he steps on a scale, and realizes that he’s much heavier than previously thought.  That induces a moment of shock and, no doubt, grand plans for gyms, diets, and lifestyle adjustments.  But, as time passes, his attitude may shift to one in which the new, heavier weight defines his self-conception.  The weight metric loses its impact.

To avoid this, he needs to continue measuring himself.  He may see himself gaining further weight, poking a hole in the illusion that he has evened out.  Or, conversely, he may see that small adjustments have helped him lose weight, and be encouraged to continue with those adjustments.  In either case, his ongoing conception of progress, more than the actual weight metric, drives and motivates behaviors.

The same holds true with codebases and keeping them clean.  All too often, I see organizations run some sort of static analysis or linting tool on their codebase, and conclude “it’s bad.”  They resolve only to do a better job in a year or two, when the rewrite will start.  However good or bad any given figure might be, the trend-line, and not the figure itself, holds the most significance.

Trend Metrics with NDepend

In that last post, I touched only on the topic, but not the specifics.  Here, I’d like to speak to how NDepend helps you with metrics.  I suspect that a lot of people know NDepend for its memorable visualization aids and its code rules and queries.  I don’t see as much discussion about the valuable trend tools, perhaps because they were release comparably recently.  In either case, I want to talk today about those tools.

Read More

By

Some Visual Studio Tips and Tricks

Editorial Note: I originally wrote this post for the SmartBear blog.  

Last month, I wrote a post about integrated development environments (IDEs).  As mentioned in that post, developers commonly debate the relative merits of lightweight text editors against heavyweight IDEs.  But I suspect just about everyone can agree that if you do plan to use an IDE, you should maximize its utility.  In other words, as long as you’re incurring the overhead, you should reap the benefits.

I work a great deal in the .NET space, which means that I spend a good bit of time using Visual Studio, an extremely heavyweight IDE.  In the interests of full disclosure, I will admit to loving to work with Visual Studio.  But that love has grown out of years of exploring it, tinkering with it, and learning to maximize my efficiency with it.  If not for all that, it would seem only a glorified text editor that takes a lot longer than Notepad++ or Sublime to start.

Today, I’d like to offer some suggestions for getting more mileage out of Visual Studio.  By no means is this an exhaustive list; that would require books and books, rather than a single blog post.  Visual Studio has tons of capability.  Rather, today, I’ll offer some tips and tricks you might not have seen previously.

Read More

By

Managing Code Analysis Statistics with the NDepend API

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  Also, NDepend just released a new version that addresses tech debt extensively — check it out while you’re there!

If you’re familiar with NDepend, you’re probably familiar with the Visual Studio plugin, the out of the box metrics, the excellent visualization tools, and the iconic Zone of Uselessness/Zone of Pain chart.  These feel familiar to NDepend users and have likely found their way into the normal application development process. NDepend has other features as well, however, some of which I do not necessarily hear discussed as frequently.  The NDepend API has membership in that “lesser known NDepend features club.”  Yes, that’s right — if you didn’t know this, NDepend has an API that you can use.

You may be familiar, as a user, with the NDepend power tools.  These include some pretty powerful capabilities, such as duplicate code detection, so it stands to reason that you may have played with them or even that you might routinely use them.  But what you may not realize is the power tools’ source code accompanies the installation of NDepend, and it furnishes a great series of examples on how to use the NDepend API.

NDepend’s API is contained in the DLLs that support the executable and plugin, so you needn’t do anything special to obtain it.  The NDepend website also treats the API as a first class citizen, providing detailed, excellent documentation.   With your NDepend installation, you can get up and running quickly with the API.

Probably the easiest way to introduce yourself is to open the source code for the power tools project and to add a power tool, or generally to modify that assembly.  If you want to create your own assembly to use the power tools, you can do that as well, though it is a bit more involved.  The purpose of this post is not to do a walk-through of setting up with the power tools, since that can be found here.  I will mention two things, however, that are worth bearing in mind as you get started.

  1. If you want to use the API outside of the installed project directory, there is additional setup overhead.  Because it leverages proprietary parts of NDepend under the covers, setup is more involved than just adding a DLL by reference.
  2. Because of point (1), if you want to create your own assembly outside of the NDepend project structure, be sure to follow the setup instructions exactly.

A Use Case

I’ve spoken so far in generalities about the API.  If you haven’t already used it, you might be wondering what kinds of applications it has, besides simply being interesting to play with.  Fair enough.

One interesting use case that I’ve experienced personally is getting information out of NDepend in a customized format.  For example, let’s say I’m analyzing a client’s codebase and want to cite statistical information about types and methods in the code.  Out of the box, what I do is open Visual Studio and then open NDepend’s query/rules editor.  This gives me the ability to create ad-hoc CQLinq queries that will have the information I need.

But from there, I have to transcribe the results into a format that I want, such as a spreadsheet.  That’s fine for small projects or sample sizes, but it becomes unwieldy if I want to plot statistics in large codebases.  To address this, I have enlisted the NDepend API.

Read More

By

Logging the Lights in Your Home

Editorial Note: I originally wrote this post for the LogEntries blog.  You can find the original here, at their site.  While you’re there, check out the log aggregation service they offer and see if you could use some help storing and querying your log files.

It’s all the rage these days under the general heading of “Internet of Things” (IoT), but I have been a home automation enthusiast for more than 10 years now.  In the interceding time, I’ve done experiments and written about the subject.  I even published a Pluralsight course, in which I turned a Raspberry Pi into a RESTful server that lets you turn lights in your house on and off using basic X10 technology.  You can certainly say I have a lot of experience, both with newer techs and comparably archaic ones.

Because I’ve been in the game so long, you might think that I’m a strict constructionist, if you will, wanting to build everything myself from raw parts.  But I’m not.  Even though I enjoy assembling these systems from their components, I am a fan of the strides made by various vendors over the years, and I’m thrilled to see different players enter the space and expand home automation mind share in the general public.  In fact, I’m excited as a technologist that I can leverage already-assembled techs and services to achieve my home automation goals.

Introducing Wink

Against this backdrop, my mom recently gave me a Wink hub and companion lights for my birthday.  Wink is a service that does what I once quixotically sought to do in my spare time on weekends: it unifies disparate smart devices to allow centralized control over them.  The hub is synced with the Wink service in general, allowing control from anywhere, and the hub communicates over house Wifi with the satellite devices.  I can now turn on a couple of lights from anywhere in the world, with the workflow occurring as follows.

  1. I pop out my phone while vacationing somewhere sunny, open the Wink app, and tell it to turn on my master bedroom light.
  2. The Wink app phones home to the wink servers, communicating this request.
  3. The Wink servers pass the message on to my connected Wink hub at home.
  4. The Wink hub relays the message over Wifi to the light, which turns on.

It’s really pretty slick.  It also causes me a wry smile of amusement, since I just got a birthday gift that does out of the box something I worked for months to make happen.  But then I trade that smile for a genuine one when I think about how much more I can do in this landscape.

Read More

By

Enforcing Immutability in Multi-Threaded Projects with NDepend

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  While you’re there, have a look around at some of the features you get by downloading NDepend.

Early in the days of object oriented programming, we really got a lot of mileage out of the language and paradigm features.  For instance, if your memory extends back far enough (or your application is legacy enough), you’ll see really, really deep inheritance hierarchies.  Since inheritance was a language feature, it stood to reason that we should get our money’s worth, and boy did we ever.  We look back on that as an anti-pattern now with our 20/20 hindsight.

The same was true of application state.  The classic notion of object oriented programming was one in which objects of state and of behaviors.  For perhaps the most iconic early conception of this notion, consider the active record design pattern.  This pattern addressed the so-called impedance mismatch by presenting us with an in-memory, object-based representation of a database table.  The object’s state was the table and the behaviors were records that you could perform on it, such as saving or deleting or what have you.

While active record, particularly in some communities, has not been as roundly rejected as deep inheritance hierarchies, it no longer enjoys the favor that it did more than a decade ago.  And a big part of the reason that it, and other state-based patterns don’t, is that the object-oriented community has come to favor immutability, meaning that any data stored in an object is read-only for the lifetime of that object.

vendingmachine

Immutable objects are, first and foremost, easier to reason about.  Take, for instance, the humble object collaborator.

This may or may not work, depending on what people come along and do with TheService.  What happens if they null it out?  To make life easier, we move away from mutable state implementations in favor of approaches like this.

Now there’s no reason to worry about the service being valid.  At the time of object construction, we enforce any preconditions, and then we don’t need to worry that _service.GetMeABeer() is going to generate a null reference exception or wind up calling a different implementation than the last time it was invoked.  ServiceConsumer is now immutable with respect to Service.

Read More