Clemens rails about technology overload with .NET (via larkware).

Meanwhile…

David Heinemeier Hansson discusses the success of Ruby on Rails and it’s minimalistic approach (via Scoble).

I read these back-to-back today, and I thought the juxtaposition was interesting. While Microsoft has been busy adding so many features to the .NET platform that no single developer can possibly know it all, ruby on rails has achieved success simply by focusing on a core set of functionality that helps real developers create the scaffolding to build clean applications quickly.

Now, don’t get me wrong here. I’m not bashing Microsoft, as I think they are doing what is necessary to meet the needs of a large and diverse set of developers and technology problems, and I love the .NET framework. I also know that the comparison is sort of apples to oranges, but I think the success of rails among many hardcore developers highlights something that may be missing from the VS.NET toolsets - or perhaps just misdirected with the mindset of drag-and-drop database connections and passing around datasets.

I think it highlights that perhaps more effort should be spent around creating rails-like scaffolding (read frameworks that are pattern-oriented and sensible) in targeted areas like web applications, but also around web services, windows apps, etc so that developers don’t have to be experts in every area to create “quick-and-clean” applications, but, yet, the experts feel comfortable with the scaffolding being used as well. That’s the draw of rails to me….that it creates a framework that is simple, object-oriented, and pattern-based (MVC) – but clean, meaning I don’t look underneath the covers and go, ‘blech’. I don’t want to write all the yucky code every time, but I want to know that it’s being done right.

I do think the patterns and practices group is doing some great work already to help cut down on the riff-raff with the Enterprise Library blocks (although they certainly don’t seem to believe in the rails idea of “convention over configuration”, heh) and especially with their work on the GAT. I’m interested to see how these converge either through the direction of the p&p group or others (maybe myself -why not?). I see no reason why these couldn’t be used in conjunction to create a scaffolding framework every bit as powerful, clean, and easy to use as ruby on rails, but with a .NET twist.

For those of us that aren’t Photoshop gurus (or just don’t have that kind of cash)…

I was recently upgrading my blog to the latest version of dasBlog and doing some touch-up and I found this great online RSS button generator that will let you enter options about the text and colors and then generate the button on the fly for you. See screencap below (or see the feed links on the left side of my blog homepage):

Link: http://www.feedforall.com/public/rss-graphic-tool.htm 

Enjoy!

Over the past couple of years I’ve helped different people with website hosting and in the last year put up my own website to host my blog. In the span of 5 years, I’ve been with 4 different hosting companies –

one too expensive (I think I was paying upwards of $60/month at one time),

one fraudulent (I actually had to file fraud claims because they would not quit charging my credit card each month a year after I cancelled hosting)

one lacking in solid support for .NET / SQL Server

and now, webhost4life.

I have to say that in the 14 months that I’ve used them, I have been more than pleased with my experience. On the whole, they are:

Cheap: I pay $9.95/month for a plan that includes .NET & SQL Server database hosting and unlimited bandwidth. They have even cheaper plans, starting at $5 or so if you just need something basic.

Easy to use: I’ve found their hosting panel to be the easiest I’ve used of the companies I’ve been with. With it I’ve been able to perform most all the setup and configuration tasks that I’ve needed to do without bugging technical support. Also, I host multiple domain names using the same space, and I’ve found this to be super simple to setup and manage.

Responsive: This is the one that makes me so willing to recommend them. Check out these resolution times when I’ve opened tickets with technical support:

Ticket #1: 2 hours 22 minutes
Ticket #2: 1 hour 13 minutes
Ticket #3: 1 hour 20 minutes
Ticket #4: 40 minutes
Ticket #5: 6 minutes
Ticket #6: 9 minutes

Most of these were very low priority tickets, with only #3 being due to an outage. I just find that to be phenomenal!

Now, I will caution that I’m not hosting any sites that are blowing the roof off any stat counters or anything, and if you are, this may not be the place for you as this is shared hosting and I can occasionally tell  - although they do offer some semi-dedicated and dedicated plans, but you’ll pay for ‘em, trust me.

But if you just need a good, cheap, place to host your blog or for grandma’s knitting business, and you don’t want to sacrifice quality service, then give webhost4life a try.

http://www.WebHost4Life.com/default.asp?refid=curryr

* Disclosure – I don’t work for webhost4life or anything, but by clicking on the link above as is and signing up for webhost4life hosting, I would stand to receive some sort of referral bonus. If I am your sworn enemy, you hate guys with goatees or girly names, or you just plain don’t feel like giving me financial props, then simply remove the refid from the link. No skin off my back.

Ok, so I recently made the analogy that in the code metrics world, vil is a knife (good for slicing and dicing) while NDepend is the utilitarian fork. I was going to try to fit SourceMonitor into the world of eating utensils as well, but I think that analogy is just about played out.

So how about this instead…

If you were going on blind dates with these tools, I’d tell you that SourceMonitor is a “looker”, while NDepend has a “nice personality”. In the end, both of them are gonna show you a good time, and NDepend may arguably provide more stimulating conversation, but SourceMonitor is the one you are telling your buddies about in the locker room. Not a knockout per se, but pretty enough to brag about.

Put simply, SourceMonitor provides most of the information you need in a very refined and attractive package.

For instance, here’s a screenshot to whet your appetite:

Like what you see? Ok, so let’s add it to CruiseControl.NET…

1. Create the NAnt target.

This target will:

a. Write out an input file with the commands that SourceMonitor will call. The first command generates the project summary; the second spits out the details. Also, note that the commands specify a SoureMonitor project file (.smp) – if this file doesn’t exist it will generate one, but if you wanted to, you could reference a permanent one and it will track your code metrics data over time using the checkpoint name (or date) that you provide.

b. Call the executable that will read in the input commands file.

2. Copy the xsl transforms to the ccnet\webdashboard\xsl directory.

I’ve created several modified transforms based on some that come as part of an Ant example with the SourceMonitor distribution:

sourcemonitor-group-by-file.xsl
sourcemonitor-group-by-metric.xsl
sourcemonitor-summary.xsl (for use on your summary build report if desired)

Note that these should play nice within the ccnet dashboard without jacking with existing dashboard styling unlike some of the other xsl files I posted previously (which I’ve since gone back and fixed).

3. Add the xsl report plugin entries to the dashboard.config.

4. Add the output files to merge into your project’s entry in ccnet.config.

Summary:

It turned out that this tool was pretty easy to integrate into my builds - not nearly as messy as I’d imagined, and the results are crisp and applicable. Another upside – SourceMonitor analyzes your source rather than the IL, so the results tend to be a more accurate reflection of your code.

Ok, so here’s the downside – no kiviat diagrams. This is the main thing that attracted me to SourceMonitor in the first place, but currently there doesn’t seem to be any support for generating these from the command line, so if you want’em, you’ll have to run the SourceMonitor client. Bummer, but I still really like the what SourceMonitor is giving me. Concise and attractive - you can’t go wrong with that. Here’s some screenshots of the finished product…

Final Result:

Alright, so good luck, and enjoy your “hot date” with SourceMonitor. (Ok, I need to get out more.)

Forks are good. Most of the time when I eat a meal, I get by on just a fork. They can stab, scoop, cut, and generally get the food to my mouth without making too much of a mess. Some meals though call for other tools such as a spoon (for soup) or a knife (for steak), or maybe even chopsticks (for impressing family and friends - certainly not because they do a better job than a fork or spoon, but I digress).

What does this have to do with anything you ask? Well, the way I see it, vil is the knife to NDepend’s fork.

While NDepend is just fine for getting most of the meal from the plate to my mouth, vil is there for the special task of cutting things up and making them manageable. It’s a slicer and dicer. And a fairly powerful one out that. It’s like one of those Miracle Blade knives you see on that infomercial at 2am.

See, vil has these great command line switches for creating filtered code metric queries. Let me show you what I mean.

Here’s a NAnt task for returning all methods with a Cyclomatic Complexity > 7:

And a task for returning the top 15 most complex methods:

 
And, here’s one that will get you all of the methods with more than 5 local variables defined:

 
You can sort on any field you like, return only the top or bottom n items, limit the scope to classes or methods or even down to just constructors, and you can pick and choose any number of metrics in which you are interested. (see the docs for more). I told ya – Miracle Blade! And this one won’t even cost you $39.95.

As far as integrating vil into the build – compared to NDepend, this tool is much simpler to get going with. The CruiseControl.NET documentation already includes instructions, and since vil gives you plenty of command-line control over the input and output, and since there are no images to integrate, you should be able to get this up and running on your builds cleanly and quickly without much addition from me.

I will add this though…

The latest build of CCNet comes with a vil stylesheet, but it’s pretty plain-Jane (my apologies to any readers named Jane). I elected to go with a slightly modified version of the alternative vil stylesheet found at the Community Contributions page for XSL Transforms (contributed by Willie Tu). It spruced up the colors a bit and was generally more readable, but I had to muck with it because it included some xsl commands for sorting alphabetically, which interfered with my already-sorted queries (get my version here: vil-alt.xsl). The really nice thing about this stylesheet that I liked though was the ability to define thresholds for different metrics that will cause warning highlight colors to be applied to the report to help you spot trouble quickly.

(When defining or adjusting your thresholds, remember to keep in mind that vil, like NDepend, analyzes the IL rather than the actual source, so metrics like Cyclomatic Complexity and Lines of Code may be a bit inflated compared to what you may be used to).

 So, I set my thresholds, added in my NAnt task, updated the ccnet.config and dashboard.config,

And…

The Final Result:

Pretty great huh? Can’t wait to put it in your continuous integration build right?!

Well, now that I’ve got you all worked up, let me give you the potentially bad news…

The version of vil that I downloaded last week from www.1bot.com will only analyze assemblies or sets of assemblies with less than 100 types (classes, structs, interfaces, etc) before complaining that it needs a license key. Now, I say this is potentially bad news because the website documentation says that you can email the contact email address to get a key (with no mention of this key costing anything), but my attempts to get a response have so far been met with silence. This may or may not be a problem for you depending on the size of your codebase.

The other bit of bad news is that I can’t think of a simple way to use vil to perform and report on more than 1 filtered query on my code. This is because all of the information from multiple queries would get merged into the main ccnet report xml, and the xsl would apply templates to the whole set of generated output.  So, if I wanted, say, a list of the most complex methods AND a list of the methods with the more than 5 locals in separate reports, this wouldn’t be easily doable. I suppose I could somehow wrap the results in an outer grouping tag, and then create modified xsl transforms to look at each specific group separately, but this is more hacking than I want to do for now. Maybe down the road. Or maybe a helpful reader will do it or figure out a better way and save me the trouble (hint hint).

For now, I’m content to use vil to isolate a specific set of metrics and highlight specific areas that might need refactoring, while letting NDepend get the rest. I’m thinking I will actually use the cyclomatic complexity query similar to the one above that returns the top n methods in my main build report summary and then use other code metrics tools for additional analysis.

So now I have a fork (NDepend) and a knife (vil). Will SourceMonitor be the spoon that completes my table setting? Find out in the next part of this series on Code Metrics and Code Metrics Tools….

Update: Good news! I got a response about a key. The key gives you license to use the current version of vil (or any updated version within the year) in an unrestricted manner now and forever. No cost. No type limit. Slice and dice away.

In my post Code Metrics and Code Metrics Tools, I discussed several tools that could analyze your source code and generate a report that could possibly be integrated into an automated build cycle. In this post, I’ll talk about how I integrated one of those tools, NDepend, into a CruiseControl.NET / NAnt Continuous Integration build.

 1. Define an input file to tell NDepend what to analyze.

The directory definition can be set to a local project path if needed, as we will worry about making it relative to the build working directory in a later step.

2. Create a target in your NAnt build script to run the NDepend executable.

This target will need to:

a. Copy the input file to the directory you want your output to end up. NDepend will generate output xml files in the same directory as the input xml file.
b. Change the directory information in the input file so that it points to the proper bin directory relative to the build working directory.
c. Call the executable.

3. Copy the xsl report stylesheets into the ccnet\webdashboard\xsl directory.

If you want the images to display, you’ll also want to see my post on Integrating Images Into Custom CruiseControl.NET Build Reports.

4. Add the xsl report plugin entries to the dashboard.config.

I discovered from the CCNet Community Contributions Wiki page for xsl transforms, that Freek Felling had already created some NDepend report xsl’s for use in a CCNet build.

As I’d mentioned before, I liked that NDepend generated a lot of bang for the buck, but the amount of info it provides is almost too overwhelming, so I decided to break this report up so that I could pick and choose which pieces I might want to include in my build. I did this by separating out each section of the ndependreport-ccnet.xsl into it’s own xsl, which you can download as you like from here:

ndependreport-ccnet.xsl (modified from CCNet Contrib version to include image support)
ndependsummary-ccnet.xsl (same as CCNet Contrib)
ndependreport-ccnet-ApplicationMetrics.xsl
ndependreport-ccnet-AssembliesMetrics.xsl
ndependreport-ccnet-AssembliesDependencies.xsl
ndependreport-ccnet-InfoWarnings.xsl
ndependreport-ccnet-TypesMetrics.xsl
ndependreport-ccnet-TypesDependencies.xsl

Here’s an example with all the plugins listed, but you should be able to filter these down to just the ones you care about:

5. Add the output files to merge into your project’s entry in ccnet.config.

Same thing applies here. You should be able to include only the ones necessary for the reports you choose to use.

Final Result:




In the next episode of this series, I’ll talk about the steps required to integrate vil into your CI builds. Keep watching. Don’t touch that dial.

As a precursor to my soon forthcoming follow-up posts regarding adding code metrics tools to an NAnt / CCNet automated build, I thought I would discuss one of the techniques I used to overcome a major hurdle – lack of image support in CruiseControl.NET build reports.

I’m a visual guy. Most of my coworkers know that I can barely talk for more than a few minutes on a topic before I start drawing pictures on a whiteboard. So, naturally, when I start digging into code metrics, I gravitate toward the pretty pictures. I like how pictures can concisely convey a covey of information, and then if I see something amiss, I can delve further into the numbers.

Much to my dismay, however, I quickly discovered that the nice pictures that some of these metrics tools generated were going to go to waste in my build reports since the architecture for the display of custom reports for CCNet wouldn’t support including images on a build-by-build level – at least not easily.

See, all information that you want included in a CCNet report must be either written to a build log or merged into the log from external files. Each log is placed in a single directory. To create a custom report plugin that will display in the web dashboard, you add an xsl stylesheet to apply templates and transform the relevant data from the xml log. The problem is that there’s really no place for external resources or enclosures (like images) to go that the xsl could easily include them in the report since the log directory is flat, and the xsl is applied from the main directory with no knowledge of which build the report is for.

From perusing the CCNet mailing lists, I believe this problem is currently being addressed and will be resolved in a permanent way in a future release, but I’m not one to wait, so I came up with a solution in the meantime…

What I did was create an ashx file to handle images such that I could pass in a ccnet project name, ccnet build label, and the name of the image. Like so:

image.ashx?project=MyProject&label=2.1.1&name=SomeReallyImpressiveGraph.png

The ashx traverses the path to the proper artifact directory and renders the requested image. The relative or absolute path to the build artifacts can be specified in the web.config file, or it can use a default path that I hardcoded. The path should include the tokens “{0}” and “{1}” to represent project and build label respectively. See below:

<%@ webhandler language="C#" class="ImageHandler" %>
using System;
using System.Configuration;
using System.Data; 
using System.Data.SqlClient; 
using System.Drawing;
using System.Drawing.Imaging;
using System.Globalization;
using System.IO;
using System.Net;
using System.Web;
using System.Web.Caching;
 
 
public class ImageHandler : IHttpHandler
{
  public bool IsReusable  { get { return true; }  }
 
 
  /// <summary>
  /// Processes the request.
  /// </summary>
  /// <param name="ctx">CTX.</param>
  public void ProcessRequest(HttpContext ctx)
  {
    try
    {
      string name = ctx.Request.QueryString["name"];
      string project = ctx.Request.QueryString["project"];
      string label = ctx.Request.QueryString["label"];
      string cacheKey = string.Format("{0}|{1}|{2}", name, project, label);
 
      if ( name != null && name.Length > 0)
      {
        Byte[] imageBytes = null;
 
        // Check if the cache contains the image.
        object cachedImageBytes = ctx.Cache.Get(cacheKey);
 
        // Use cache if possible...
        if ( cachedImageBytes != null )
        {
          imageBytes = cachedImageBytes as byte [];
        }
        else // Get the image from the project/build directory.
        {   
          // Determine the base path from config file if provided.
          string imagePath = ConfigurationSettings.AppSettings["imagePath"];
          if ( imagePath == null || imagePath.Length == 0 )
          {
            // If not provided, default to:
            imagePath = @"..\server\{0}\Artifacts\buildreports\{1}";
          }
 
          // Replace tokens in the provided path with the project and label.
          imagePath = string.Format(imagePath, project, label);
 
          // If the path is relative, combine with the current base directory.
          if ( !Path.IsPathRooted(imagePath) )
          {
            imagePath = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, imagePath);          
          }
 
 
          try
          { // Get the image stream from the provided path.
            using ( FileStream fs = new FileStream(Path.Combine(imagePath, name), FileMode.Open, FileAccess.Read) )
            {
              using(Image inputImage = Image.FromStream(fs))
              {
                using(Image outputImage = new Bitmap(inputImage))
                { 
                  using(MemoryStream stream = new MemoryStream())
                  {
                    outputImage.Save(stream, ImageFormat.Jpeg);
                    imageBytes = stream.GetBuffer();
                  }
 
                  ctx.Cache.Add(cacheKey, imageBytes, null,
                    DateTime.MaxValue, new TimeSpan(2, 0, 0),
                    CacheItemPriority.Normal, null);   
                }
              }
            }
          }
          catch ( Exception )
          {
          }
        }
 
        ctx.Response.Cache.SetCacheability(HttpCacheability.Public);
        ctx.Response.ContentType = "image/jpg";
        ctx.Response.BufferOutput = false;
        ctx.Response.OutputStream.Write(imageBytes, 0, imageBytes.Length);
      }  
    }
    finally
    {
      ctx.Response.End();    
    }
  }
}

I placed the image.ashx file in the CruiseControl.NET webdashboard root directory, and then made sure that any images generated by metrics tools or otherwise ended up in an Artifacts directory stored by build label – copying them over in the build script.

This allowed me to replace image references in the xsl stylesheets with something like this:

 
Note that I also needed to create a file upon each successful build (using the nant.onsuccess property to call a OnSuccess target) that contained the project/build information and merge it in to the main ccnet log so that I could reference it from the xsl (the $project and $label variables above). See NAnt excerpt below. (And, yes, I know that project name is already included in the main log, but I couldn’t divine the magic xpath query to access it, and it was 1am, so it was easier just to include it):

And the end result:

Mmm. Pretty.

One of the topics of discussion at the XP workshop I went to on Tuesday was code metrics, and, subsequently, tools that could be used to obtain said metrics. Here’s a quick summary of some of the metrics we talked about:

CC (Cyclomatic Complexity) – Basically, this is the # of decision paths in a given method. More decision paths mean more possible points of failure and more required test scenarios.

Ca (Afferent Couplings) – This refers to the # of types directly depending on a particular other type. Types with lots of dependencies are considered to have high responsibility. I like to remember this one as the Type A Coupling – as in, a type with a high Ca has a Type A personality and is highly responsible.

Ce (Efferent Couplings) – This refers to the # of types a particular type directly depends on. A type that depends on lots of other types is highly dependent. I remember this one as the Everybody Coupling - as in, a type with a high Ce depends on Everybody. (just humor me ok)

I (Instability) – A # based on a ratio of Ca and Ce indicating an item’s resilience to change.

A (Abstractness) –  A ratio of the # of abstract types to types.

D (Distance) – This is a measurement of how far from the ideal I + A something is.

LOC (lines of code) – Uh, lines of code (although, surprisingly, this can cause controversy).

For more in depth discussion go here or here, or read Robert C. Martin’s book – Agile Software Development (Quick aside – this book is a MUST read for any developer. It is quite honestly the best software development book I have ever read. There. I’ve thrown down the gauntlet. If you haven’t read it, go get it right now. Tell’em I sent ya.)

While I’d read about these different coding metrics before, talking about them and then subsequently reading this blog post by Michael Swanson really showed me how useful these metrics might be in highlighting areas where problems might exist in a codebase, and spurred me into action to look into how I could integrate this analysis into our automated build cycle.

So I set out to research different code metrics tools. My main criterion:

1. At least hit the highlights such as Cyclomatic Complexity, Afferent Coupling, Efferent Coupling, and LOC.

2. Has to be Open Source and/or Free.

3. Has to be able to integrate into an automated build using NAnt (so, callable from the command line and able to spit out some output in the form of xml or some such).

Raymond had mentioned a tool called NDepend. In addition, I looked at Source Monitor based on Michael’s aforementioned blog post, and one named vil. (If anybody knows of more that meet the criteria, please let me know).

Source Monitor
What I liked
– LOC and CC analysis is based on the actual source code (rather than IL as some of the other tools). This, in my opinion, provides a more accurate assessment based on the original definitions of the metrics and makes it easier to judge the results based on industry recommendations.
– Examples showing how to integrate with a build (using Ant, so I’ll have to translate these to NAnt).
– Kiviat diagrams. An excerpt from Michael: 

The Kiviat diagram below is from some sample code I generated awhile back. I can quickly tell from this diagram that I should check to see if I've commented my code properly and take a look to see which method(s) are driving my complexity and depth outside typical limits (which are configurable). Fortunately, SourceMonitor makes it very easy to find and review the complex code.

What I Didn’t Like
– It looks like it may be fairly involved to get this going in my build script (although the Ant example will certainly help). Also, I’m not sure if I can get the Kiviat diagrams in my html reports yet - they may only be available in the client app as I didn’t see them in the example – which would be a bummer. I guess we will see. I will update this if this turns out not to be the case.

NDepend
What I Liked:
– Packs a lot of information in.
– Nice ability to configure which assemblies are included, and which are considered framework or outside of your control.
– Some really nice graphs such as the Assemblies Abstractness vs Instability and an Assemblies Dependencies Diagram (see below).



What I Didn’t Like:
– Analysis is based on IL rather than actual source files, so some of the numbers are a bit inflated – particularly the one for Cyclomatic Complexity, which the documentation suggest could be off by a factor of 2 or 3.
– No Configurability of what metrics get output as far as I could tell – so it’s all or nothing, which is ok, I suppose, but I’m not sure I want to use all the metrics at this point. I would’ve liked to have been able to specify the ones I’m interested in.
– Very little control of where the output gets sent to. 

vil
What I Liked:
– Highly configurable as to what types of things (i.e. classes, enums, structs, methods, etc) should and should not be analyzed, and what kinds of metrics should be output.
– Ability to filter the results based on criteria. The documentation is a little bit sparse on examples here, but I think this might allow someone to, say, spit out all methods that have a CC > 10, or something like that. If so, this could be really useful.
– A CruiseControl.NET xsl plugin has already been created for vil, along with an example of how to set it up in a NAnt script.

What I Didn’t Like:
– Again, analysis based on IL.
– I’m not sure if I’m not using it properly or what (although I tried almost every possible command switch combination), but when I ran the tool against some existing code that had approximately 50–60 classes, vil only displayed information about 4 of them. I plan to send an email to the support address and see if I can figure out what’s going on.

I decided that each had enough positives to warrant a shot, so I’d try to integrate each of them into my CruiseControl.NET/NAnt build and see how it went and see which ones were keepers. I’m about half way through this process now, so over the next few days I will post about my experiences with each. Stay tuned.

(Also, if anybody has any examples of their own of automated build integrations with one of these tools or others, I’d love to see them)

(Update) See the posts detailing how to integrate each of these into CruiseControl.NET here:
NDepend
vil
SourceMonitor