DaedTech

Stories about Software

By

Improving .NET Application Performance

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 the application monitoring options you can take advantage of.

First of all, make sure that you use StringBuilder when concatenating strings.  You see, the “+” operator — just kidding.  I mean, that’s not bad advice.  Rather, I’m kidding in that I just don’t want to offer this style of tip today.

Often, advice about application performance comes at you with the staccato of rapid fire tips.  “37 Ways to Shave Nanoseconds off of Your Overnight ETL Process.”  I exaggerate for comedic effect with that title, perhaps.  But the point remains.  Authors serve up advice for optimization with many tips that matter only inside of tight loops.  And it’s hard to keep all of those in your head.

I’d like to take a different tack here today and offer fewer suggestions in the hope that they’ll stick with you.  But I differentiate my message in another crucial way as well. I want to offer performance tips for .NET programming that will also help you write clean, readable code.

All too often, these concepts stand in opposition to one another.  Performance tips often demand changes that produce the desired effect while making the code harder to read.  This phenomenon gives rise to the iconic wisdom that “premature optimization is the root of all evil.”  Implementing them might bring relatively insignificant marginal gains in performance while creating confusing, hard-to-read code.

But it strikes me that readable and performant sometimes overlap.  And, since tips for that serve two purposes, they are definitely worth filing away.

Read More

By

Is Your Code Hard to Understand?

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

I’ve heard a bit of conventional wisdom in the software industry.  It holds that people will read a given line of code an order of magnitude more times than they’ll modify it.  Whether that wisdom results from a rigorous study or not, I do not know. But it certainly squares with my experience.  And it also seems to square with the experience of just about everyone else.

Accepting this wisdom as axiomatic, code readability becomes an important business concern.  If you optimize for ease of writing at the cost of ease of reading, your business will lose money.  Better to spend some extra time in writing your code to ensure that future readers have an easy go of it.  And easy for them means that they understand the code.

You know of obvious ways to promote reader understanding in code.  Don’t give variables cryptic names or names that cannot be pronounced.  Don’t write gigantic methods and classes.  Limit method parameters and local declarations.  Read through the code out loud to see if it seems clear.  These guidelines will bring you a long way toward readability.

But other, subtle concerns can also chip away at your code’s readability.  I’ll list some of these here, today.  These are generally C# specific, but some are more broadly applicable than that.  What all of them have in common is that they constitute sources of confusion for readers that may not seem immediately obvious.

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

Avoid these Things When Logging from Your Application

Editorial note: I originally wrote this post for the LogEntries blog.  You can check out the original here, at their site.  While you’re there, sign up for the service and check it out.

It seems almost strange to talk about avoiding things while logging.  After all, logging is your last line of defense or your salvation in many cases.  Some crazy bug in the field that shows up every third full moon?  An external auditor looking at your app’s runtime behavior?  Logging to the rescue.

So naturally, is stands to reason that you would want to log just about everything your application.  Whenever there’s any doubt, slam a logger call in there and let log level sort out the details.  You can always filter logs, but you can’t magic stuff into them after the fact.  So why, then, talk of avoidance?

wizard

Well, it turns out that, while logging may be a highly inclusive activity in terms of what should be included, there are ways to create problems.  You want to be liberal in terms of what you log, but judicious and wise in terms of how you log it.  You don’t want to indulge in a feckless free-for-all when it comes to the calls you make to your application’s logger.

So what are these problems, and how to avoid them?  Let’s take a look at some things that can come back to bite you.

Read More