Category Archives: Code

Debug logging sucks

I’ve seen a bunch of production killers caused by debug logging.

Why does debug logging suck?  Because it’s debug, stupid:
1) It’s usually extremely verbose.
2) It opens you up for potential security violations.  Who know what that contractor put into a debug statement?
3) It’s not meant to be performant.  In other words, it’s slow.  Like sloth-slow.

The only time you should ever use debug logging is during development. Even then, debug logging just means “I was too lazy (or proud) to step through my shitty code in the debugger”. It’s logging overkill. Most of the problems I’ve seen are caused by different threads all trying to access non-threadsafe code at the same time.

Either way, logs fill up with useless crap.  That crap fills up your disk, etc.  It marginalizes the stability of your software.  So following are few quick pointers.

  1. Never let your users know it’s available. Once you do, it’s on forever.
  2. Better yet, just don’t create debug log messages.  Do one of these instead:
  • Create a no-op method for your debug messages in production.  Use a “Production” configuration tag to determine when your code is in a production environment.  Don’t log when in production mode. [Good]
  • Create a single logging class and always use it. Compile out the debug messages when building Release software. [Better]
  • Create integrated performance counters in your code that instrument key metrics like methods calls /sec and average method call execution times. Identify and instrument the key methods in your software. This way, you can track your software performance in real time, regardless of your environment. [Best]

Tenets of a Performant Development team

Our customers are very important to us.  We will do everything reasonable to make our customers happy.  If we cannot satisfy or customer, they will fire us.  If our customer is unreasonable, we will fire them.

Our software is not overly complicated;  it is easy to understand.  If the architecture takes an hour-long meeting to explain, it’s wrong.

We operate as a team.  We communicate.  Occasionally, we will argue (respectfully) because we all have different opinions.  That’s ok. We are not offended by it.  If someone on my team needs help, I readily volunteer to help.  For you manager types, read this article of stages of team development to help your team get to the Performing stage.

We commit completed, tested, demonstrable code.  What does that mean?

  • We don’t break features up into a bunches of unrelated stories.  We are committed to getting the feature done by the end of our development cycle (iteration/sprint).
  • We don’t commit half-assed ideas to the trunk in lots of little piece.   Every source control system out there has a way to save your bits and pieces off to the side (branches, forks, shelvesets, etc.) while they are not complete ideas.  Your feature should be committed to the trunk in a single piece.
  • There are automated tests around as much of it as possible (i.e. all of it).
  • We can show it to the customer and they can understand it easily.

We write software.  If our automated builds/test are broken, then we are no longer writing software, we are writing bugs.  Therefore a properly functioning, successful (green) build is a priority.  We regularly monitor our builds and fix them.  Our software is tested automatically;  we do not accept broken software.

Write better JavaScript code using JSLint

For those of you that may not be familiar with lint, lint is a programmatic process that seeks out common programming mistakes.   Lint was originally written decades ago for C code.  JSLint and other tools like it were developed to do the same for your JavaScript code.  JavaScript is an extremely intricate language that allows you to write really bad code.  These JavaScript linters will highlight hundreds of common JavaScript programming errors.   

If you are developing an application that uses JavaScript, you should have a linting tool in your development toolbox.  Below, I’ve evaluated a few.

Option 1: Use Web Essentials

At a minimum, you should install Web Essentials.

Then you get a JavaScript linter for free.  http://vswebessentials.com/features/javascript. 

You also now have cool menu options under Web Essentials to edit your ‘*int’ configurations (JSHint, TSLint, CoffeLint, and JSCS).

You’ll need to play with them, because out of the box, Web Essentials only finds the most grievous errors. 

Your JavaScript errors will show automatically in the Messages tab of the Error List:

clip_image002

Option 2 – JSLint.Net Add in

The best integration with Visual Studio and Web projects seems to be with The JSLint.Net add in

Once installed, you get new context-sensitive menu options by right-clicking a project or .js file. 

Project settings are integrated with the web project via a JSLintNet.json file, so they can be checked in and shared with other developers.

In the example below, I right-clicked on my web project and selected

1) Changed the ‘Output Errors As’ setting to Messages so that lint errors go to the Messages tab in the Error List window.

2) Checked ‘Run on save’ and ‘Run on build’

3) Previously ignored a bunch of .js files that I didn’t write.

clip_image004

On the JSLint Options screen, added a few Predefined Globals.

As we refer to them all too frequently in our code, I don’t want to see errors on these objects.

clip_image006

Option 3 – JSLint add-in for Visual Studio

If you want to take it a step further, you can install the JSLint add in for Visual Studio.  It has A LOT of functionality that you can play with, but is a little harder to configure.   Be sure to set the linter to JSHint, which is a little bit less restrictive than JSLint.

clip_image008