DaedTech

Stories about Software

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

By

Improve Your Code Review Game with NDepend

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  If you like posts about static analysis, have a look around while you’re there.

Code review is a subject with which I’m quite familiar.  I’m familiar first as a participant, both reviewing and being reviewed, but it goes deeper than that.  As an IT management consultant, I’ve advised on instituting and refining such processes and I actually write for SmartBear, whose products include Collaborator, a code review tool.  In spite of this, however, I’ve never written much about the intersection between NDepend and code review.  But I’d like to do so today.

I suppose it’s the nature of my own work that has made this topic less than foremost on my mind.  Over the last couple of years, I’ve done a lot of lone wolf, consultative code assessments for clients.  In essence, I take a codebase and its version history and use NDepend and other tools to perform extensive analysis.  I also quietly apply some of the same practices to my own code that I use for example purposes.  But neither of these is collaborative because it’s been a while since I logged a lot of time in a collaborative delivery team environment.

DevOpportunityCost

But my situation being somewhat out of sync with industry norms does not, in any way, alter industry norms.  And the norm is that software development is generally a highly collaborative affair, and that most code review is happening in highly collaborative environments.  And NDepend is not just a way for lone wolves or pedants to do deep dives on code.  It really shines in the group setting.

NDepend Can Automate the Easy Stuff out of Code Review

When discussing code review, I’m often tempted to leave “automate what you can” for the end, since it’s a powerful point.  But, on the other hand, I also think it’s perhaps the first thing that you should go and do right out of the gate, so I’ll mention it here.  After all, automating the easily-automated frees humans up to focus on things that require human intervention.

It’s pretty likely that you have some kind of automation in process for enforcing coding standards.  And, if you don’t, get some in place.  You should not be wasting time at code review with, “you didn’t put an underscore in front of that field.”  That’s the sort of thing that a machine can easily figure out, and that many, many plugins will figure out for you.

The advantages here are many, but two quick ones bear mentioning here.  First is the time-savings that I’ve discussed, and second is the tightening of the feedback loop.  If a developer writes a line of code, forgetting that underscore, the code review may not happen for a week or more.  If there’s a tool in place creating warnings, preventing a commit, or generating a failed build, the feedback loop is much tighter between undesirable code and undesirable outcome.  This makes improvement more rapid, and it makes the source of the feedback an impartial machine instead of a (perceived) judgmental coworker.

Read More

By

How to Analyze a Complex Solution

Editorial Note: I originally wrote this post for the NDepend blog.  You can check out the original here, at their site.  If you enjoy posts about code quality and static analysis, add the NDepend blog to your feed.

I’ve made no secret that I spend a lot of time these days analyzing code bases as a consultant, and I’ve also made no secret that I use NDepend (and its Java counterpart, JArchitect) to do this analysis.  As a result, I get a lot of questions about analyzing codebases and about the tooling.  Today, I’ll address a question I’ve heard.

Can NDepend analyze a complex solution (i.e. more than 100 projects)?  If so, how do you do this, and how does it work?

Singularity

Can NDepend Handle It?

For the first question — in a word, yes.  You certainly can do this with NDepend.  As a matter of fact, NDepend will handle the crippling overhead of this many projects better than just about any tool out there.  It will be, so to speak, the least of your problems.

How should you use it in this situation?  You should use it to help yourself get out of the situation.  You should use it as an aid to consolidating and partitioning into different solutions.

The Trouble with Scale

If you download a trial of NDepend and use it on your complex solution, you’ll be treated to an impressive number of project rules out of the box.  One of those rules that you might not notice at first is “avoid partitioning the code base through many small library assemblies.”  You can see the rule and explanation here.

We advise having less, and bigger, .NET assemblies and using the concept of namespaces to define logical components.

You can probably now understand why I gave the flippant-seeming answer above.  In a sense, it’d be like asking, “how do I use NDepend on an assembly where I constantly swallow exceptions with empty catch blocks.”  The answer would be, “you can use it to help you stop doing that.”

Read More

By

Put a Little NDepend in your Visual Studio

Editorial Note: I originally wrote this post for the NDepend blog.  Check out the original here, at their site.  If you like posts on the topics of static analysis and software architecture, check out the rest of the posts while you’re over there.

The software development world is filled with what I think of as “Coke-Pepsi” debates. This is how my brain categorizes debates over preference that are almost entirely subjective. There is no right or wrong answer to “is Coke or Pepsi better?” The answer is, “whichever one you like better.”

Examples abound in the software world. Should you use a heavyweight IDE or a lightweight text editor? Which OOP language is ‘the best?’ And, speaking of OOP, should you use an OOP language at all, or should you use a functional one? Pascal casing or camel? The list goes on, but these sorts of things generally boil down to the comfort and preferences of the person or team.

It would be tempting to paint NDepend Standalone versus NDepend’s Visual Studio plugin with this brush. And, while I think you could make a pretty legitimate case that this too, is simply a matter of preference, I’d like to do a thought exercise today in which I lobby in favor of the integration approach. In my opinion, there are enough advantages that I might be able to sneak this one out of the Coke-vs-Pepsi realm.

pepsi-v-coke1

What’s The Difference?

First of all, I should probably explain a bit more about the difference. NDepend standalone runs like any standard, windows desktop application. In order to use it, you’d launch it and use it to query your code base, run reports, visualize your architecture, etc. If you wanted to modify your code and use NDepend simultaneously, you would have two open Windows that you would alt-tab between.

As a plugin, NDepend runs as if it were a part of Visual Studio itself. Visual Studio has a plugin-supportive architecture that allows third party tool authors to write plugins that behave this way. To users of the plugins, the integration is totally seamless. So for all intents and purposes, NDepend’s Visual Studio plugin makes NDepend a first class part of Visual Studio. Thus everything you do with NDepend and your code all happens in the same place: Visual Studio.

Why Is This Better?

I’d imagine the first thing that occurs to you is the lack of needing to alternate between two windows. And I submit that this is, in fact, an advantage, though this advantage only scratches the surface. Logistically, there is less friction in use when you don’t need to constantly context switch between two windows. And, even if you prefer to separate the concerns out into multiple windows (say, if you have multiple monitors), you can still do this inside of Visual Studio.

Read More