Sergio Pereira

Android App From Idea to Market In a Few Hours

2010-12-07T04:11:00Z

I had been playing a little bit with Android development but not really worried about creating any useful or commercially viable application yet. I believe I'll end up creating a handful of small apps, some for personal use and some for fun. It will not hurt if a fraction of those yield some profit, but that isn't a realistic goal for now.

Maybe I'm wrong, but judging from what I've done professionally up to this date, I think any money that I eventually make with mobile apps will come from custom built LOB apps.

Nevertheless, the app I'm going to walk us through in this post is a free and for-fun project. You can find the complete source code at the bottom.

The Idea

Just the other day on Twitter I was poking fun at D'Arcy Lussier, then Don Belcham came up with a funny comment that triggered this colossal waste of code.

Fast forward to later that day, the app was ready for download.

The Lessons

Since this app is really a glorified Hello World and I had never let any other Android app leave the confines of my emulator, that's the perspective I'm hoping to share.

I'll try to show what's involved from when your first app is ready to fly to when it's finally available for download in the Android Market.

The Prerequisites

There are tons of compentent introductory articles to Android development, and I'll do everybody a favor and not rehash all that here. Suffice to say you can assume I went through some of those articles and have my development machine ready to go, with:

JDK (not just the JRE)
Android SDK
Eclipse IDE
Android Development Tools for Eclipse (ADT)
At least one virtual device (AVD) created (the emulator)

As you probably know, you don't need to use Eclipse but I think it makes your life easier if you're a total Java n00b like myself; most of the Android tutorials and Q&A out there refer to Eclipse.

The Code

In case I haven't said it enough, this is a very simple application, so I chose to target the lowest SDK version that I could, which in my case is the absolute lowest one available: SDK version 3 for Android 1.5 (Cupcake.)

To create the blinking 12:00 text I figured the easiest way would be to use two separate image files and alternate between them using a very basic animation. The animation is preferred over (animated) GIFs.

Images are embedded in your application as resources, under your project's res/drawable directory.

I used a pair of PNG images with transparent backgrounds. One of them is seen below.

Animations are defined in another type of resource. They are XML files with the animation specification. They support a nice range of tweening parameters but we'll only need a straight forward frame-by-frame animation. Here's the clock.xml file that I created inside that same drawable directory. Note the two image files drawable resource names that are the file names minus the extension.

<?xml version="1.0" encoding="utf-8"?>
<animation-list xmlns:android="http://schemas.android.com/apk/res/android"
  android:oneshot="false">
  <item 
    android:drawable="@drawable/dashes_red_alpha" 
    android:duration="500" />
  <item 
    android:drawable="@drawable/numbers_red_alpha" 
    android:duration="500" />
</animation-list>

Now we need to make that animation show up in the center of the screen. The application has only one activity (activities are the Android term for screens, windows, dialogs, etc.) That appearance of that screen is defined by the layout file main.xml, in the project's res/layout directory. If you're familiar with other XML based GUI layout formats like XAML or XUL (and even XHTML and ASP.NET webforms to some extend,) Android layout syntax is fairly reasonable. The sad part is that there isn't a good editor for them (there are some attempts out there but nothing worth praising yet.)

Anyway, here's the layout I used in main.xml. The animation will be displayed by that ImageView view (views are the individual elements or controls like textboxes and buttons, etc.) You can see that the image is centered in the layout (the layout_centerInParent attribute.)

<?xml version="1.0" encoding="utf-8"?>
<RelativeLayout 
    ...
  >  
  <ImageView android:id="@+id/digits"
    ...
    android:layout_centerInParent="true"
    android:background="@drawable/clock"
    />  
</RelativeLayout>

All that's left now is telling our activity to use the above layout and start the animation when the app gains focus (we need to wait until the app gets focus otherwise it might be too early to start and it will not do anything). The main activity class in this project is called Home, seen below

public class Home extends Activity {
  /* snip */

  @Override
  public void onWindowFocusChanged(boolean hasFocus) {
    AnimationDrawable frameAnimation = 
	  (AnimationDrawable) findViewById(R.id.digits).getBackground();

    if (hasFocus) {
      frameAnimation.start();
    } else {
      frameAnimation.stop();
    }
  }
}

And that's all there's to this application. We can start it in the AVD emulator and see it in all its blinktastic glory.

Package it up

Having an app running on the emulator or in your own phone is nice but it doesn't make the world a better place. We must push this application to the Android Market so everyone can have it.

At this point I should be telling you how a responsible developer would test his app in different AVDs, maybe different real devices, screen orientations, etc. But guess what? No siree, Bob. <sarcasm>In true Android developer fashion,</sarcasm> we're going straight to the Market and there's no stopping us.

Build it

The first step in packaging the app is to simply build the release binaries. Yo can do that in Eclipse by right-clicking the project in the Package Explorer and choosing Android Tools -> Export Unsigned Application Package and choose a directory to save it. You application .apk file will be created there.

Sign it

We can't simply send that file as-is to the market. To be accepted in the market, our application needs to be stamped with something that tells everyone who built it. This is akin to the strong naming keys that are used in .NET.

To stamp, or sign, our app we first need to create our own private key and certificate, which will live in a keystore file. If you already have one such file, you can obviously use the existing one instead. We can use the keytool.exe utility to do create it. In my box I have keytool in the JDK installation directory, so I'll run this command (one line):

C:\[JDKHOME]\bin\keytool.exe -genkey -v 
  -keystore your_secret_file.keystore -alias YourAliasHere -keyalg RSA 
  -keysize 2048 -validity 10000

When you run it, it'll ask you for a few identification parameters for the certificate and also a password that you'll need to remember later. Just like the SN key files in .NET, make sure you keep the produced keystore file in a safe place.

Time to use another tool to sign our .apk file with the information in the keystore file. Use this command.

C:\[JDKHOME]\bin\jarsigner.exe -keystore 
  your_secret_file.keystore YourApp.apk YourAliasHere

The above command will prompt you for the password again.

Optimize it

The last step in the .apk preparation is an optimization process to realign bytes in the file for faster reads on the device. You'd be surprised to know that there's another tool to do that. Not surprised? I thought so. Here's the command. You'll find the utility in your Android SDK installation directory. It will write the optimized version to another .apk file, which I'm choosing to name with the version number 1.0.

C:\[ANDROID_SDK_HOME]\tools\zipalign.exe -v 4 YourApp.apk YourApp_1_0.apk

Now to the market we go.

Publishing an app

The Android Market is where the vast majority of Android users go to find apps for their devices. You definitely want to have your application listed in there.

In order to upload an app to the market, you'll need to purchase a developer account, which at the time of this writing will cost you USD 25.00.

We're almost done here, I promise. Next we only need to logon to the market with our newly minted account and upload the application. The upload form will ask you for a couple of screenshots, a 512x512 high-res icon (?) and a bunch of other unsurprising fields.

Hit Publish and pat yourself on the back. You're officially an Android developer. I hope your first app isn't as lame as mine and that I could have helped you go through the process quicker than I.

Money flows in. Oh, wait

Okay, I can't promise an early retirement to anyone. That's on you to create the next viral app. But I can leave you with some good examples of successful apps.

Source code

Although there isn't really much to it, you can also download the source code of this app.

Have you met arguments.callee?

2010-09-10T23:36:00Z

Just the other day I had a need to use arguments.callee and I realized that's not something you really see every day in JavaScript. Maybe I could talk about it a bit.

Anonymous functions everywhere

It's not news to anyone reading this blog that one of JavaScript's workhorses are anonymous functions. Callbacks, strategies, deferred execution, event handlers, etc. They just seem to be all over the place — and for a good reason; they can be convenient and reduce the pollution of a bunch functions that are only called from a single spot.

Another nice thing is that, once your eyes are trained to ignore the little bit of noise that they add to the code, the code is really readable and, dare I say it, expressive.

Yet another contrived example

Let's say we are really into reinventing the wheel and with our understanding of anonymous functions we create a revolutionary map function:

function map(array, compute){
  var result = [ ];
  for(var i=0; i < array.length; i++){
    result.push( compute(array[i]) );
  }
  return result;
}

This function, as you can hopefully see, transforms each element of the given array into something else and returns the array of the transformed elements. Two simple uses are shown below.

//apply discount
var prices = [1, 2, 3, 4];
var discount = 0.1; // 10% off today, w00t!
var newPrices = map(prices, function(price){ return (1-discount)*price; } );
//==> [0.9, 1.8, 2.7, 3.6]

//compute areas
var squareSides = [1, 2, 3, 4];
var squareAreas = map(squareSides, function(side){ return side*side; } );
//==> [1, 4, 9, 16]

I warned you the examples would be contrived, didn't I?

Now your product manager comes and asks for a page where the users can enter a list of numbers and get the factorials for each of them. You immediately think your friend the map function will save the day. You start and...

//return the factorials
var userNumbers = [1, 2, 3, 4];
var factorials = map(userNumbers, function(number){ 
  if(number <= 1) { return 1; }
  return number * ????????(number - 1); // ooops! I need to recurse here.
} );

You see, there's this thing with anonymous functions. They don't have a name, d'oh. As I said in the beginning, we typically use them in situations where they are called only once so we can inline them and forego the need fora name. But now we're kind of wishing they had a name.

Anonymity won't hide you from me

Well, if the post tittle didn't already give it away, we can achieve that with arguments.callee. Using arguments.callee inside a function gives us a reference to the function itself. So now we can finish our code.

//return the factorials
var userNumbers = [1, 2, 3, 4];
var factorials = map(userNumbers, function(number){ 
  if(number <= 1) { return 1; }
  return number * arguments.callee(number - 1);
  //or if you were using "this" in the function you'll probably want to:
  // return number * arguments.callee.apply(this, [number - 1]);
} );
//==> [1, 2, 6, 24]

A more real world scenario

I won't leave you without at least a reference to a real use case for this feature. The example I'll show comes from Nicholas Zakas. In a blog post a while ago he showed how we can break up long running tasks with smaller timed/deferred chunks, improving the browser's responsiveness.

Here's the function from his blog post, which process chunks of an array for 50ms, then stops and call itself back to process the remaining items soon after that — giving the browser a chance to breathe and take care of its interaction with the user

//Copyright 2009 Nicholas C. Zakas. All rights reserved.
//MIT Licensed
function timedChunk(items, process, context, callback){
   var todo = items.concat();   //create a clone of the original

  setTimeout(function(){

    var start = +new Date();

    do {
       process.call(context, todo.shift());
    } while (todo.length > 0 && (+new Date() - start < 50));

    if (todo.length > 0){
      setTimeout(arguments.callee, 25);
    } else {
      callback(items);
    }
  }, 25);
}

I hope this shows you a little new trick.

Chrome Extension Development

2010-06-29T03:20:00Z

Do you like JavaScript? Have you been looking for a reaon or an idea to learn and start using HTML5? Google Chrome extesions are a great way to get into HTML5 and all its new APIs with bite sized applications.

Anatomy of a Chrome Extension

A Chrome extesion is nothing more than a tiny website that runs hosted inside Chrome. Like any website, it consists of regular web components. Grossly simplifying it is just a directory full of files, such as JavaScript, CSS, images, HTML5, and anything else you usually add to a web page.

Because it runs inside the browser, you have access to things like browser events, browsing history, and open tabs.

Essentially, your extension gets loaded as an HTML page called background.html where you can put any common/global functions and variables. This page is never visible and even if you don't provide a background.html in your extension, Chrome will load an empty one for you. All other pages in your extension can access the background page's functions.

Here's a diagram of a common scenario.

Today's Brew

Our sample extension will be something simple but that at the same time will let us explore interesting aspects of extensions development, namely local storage and cross-domain requests.

The sample is also a hat tip to the valuable work Chris Alcock does with his The Morning Brew, collecting some of the best links for all of us.

What we will do here is create an extension that will show us his latests links at the click of a button.

Introduce yourself

The extension needs to inform Chrome a few details about itself, such as name, default icons, along with any permissions it requests to access privileged browser features. This is done through the manifest file, which is just a JSON document. Here's our manifest file, aptly named manifest.json.

{
  "name": "Today's Brew",
  "version": "1.0",
  "description": "Latest links from The Morning Brew.",
  "icons": { 
    "48": "icon48.png",
    "128": "icon128.png" 
  },
  "browser_action": {
    "default_icon": "icon.png",
    "default_popup": "popup.html"
  },
  "permissions": [
    "http://feeds.feedburner.com/",
    "tabs"
  ]
}

What you can do

Extensions can perform several different jobs, like showing notifications, providing new themes, changing some of the default Chrome pages, etc. One other thing they can do are the browser actions, which basically means adding a button to the toolbar that acts independent of what page is being shown, as if it were just another browser feature.

If you look at our manifest file you'll notice we declared a browser_action, with its icon and the page it opens wen clicked.

Our extension does not have a custom background page, we will just rely on the default one Chrome will give us and put all of our logic in the popup page that we will open.

What you need to do that

Here's how our extension will look like when we're done.

In our extension, other than manipulating our own extension's HTML dynamically (which doesn't require any special permissions) we will need to fetch the RSS feed from Feedburner and eventually open new tabs as the user clicks on the links.

That's what you can see in the permissions section of the manifest file above.

Getting down to business

To create our extension we start by creating an empty directory and adding our manifest.json file and all the icon image files that we mentioned in that manifest file.

Then we create our popup.html file, which will be pretty empty and will be populated with the content we will retrieve from the RSS feed. Here's that file.

<script type="text/javascript" src="jquery.js"></script>
<script type="text/javascript" src="popup.js"></script>
<div id="main">
  <h1></h1>
  <div id="content">
  </div>
</div>

As you can see, we will be using jQuery so we should also add that file to our directory. We will leave all the beautification of the popup in the popup.css file, which I won't bother showing here; you can download it along with the rest of the code at the end of this article.

The other file referenced by the HTML is popup.js. That's where all the action happens.

$(document).ready(function(){
  SERGIOPEREIRA.samples.todaysBrew.init();
});

var SERGIOPEREIRA = {
  samples: {
    todaysBrew: {
      state: { },
      feedUrl: 'http://feeds.feedburner.com/ReflectivePerspective?format=xml',
      todaysUrl: '',
      maxAgeHours: 12, // keep it for 12 hours
      
      init: function(){
        $('#content h3').live('click', function(){
          $('#content ul:visible').slideUp();
          $(this).next().slideToggle();
        });

        $('#content li a').live('click', function(){
          $('#content ul:visible').slideUp();
          chrome.tabs.create({url: this.href});
        });

        $('h1').click(function(){
          chrome.tabs.create({url: SERGIOPEREIRA.samples.todaysBrew.todaysUrl});
        });
        
        if(typeof chrome != 'undefined') {
          this.state = localStorage.getItem('latestBrew');

          if(this.state){
            var now = new Date();
            var minTimestamp = new Date();
            minTimestamp.setHours(minTimestamp.getHours() - this.maxAgeHours);
            minTimestamp = minTimestamp.toJSON();

            if(this.state.timestamp > minTimestamp) {
              this.renderLatest(this.state.latestData);
              return;
            }
          }
          this.refresh();
        }
      },
      refresh: function(){
        console.log('will get feed data...');
        $.get(this.feedUrl, function(xml, status, xhr){
          SERGIOPEREIRA.samples.todaysBrew.update(xml);
        });
      },
      update: function(feedXml) {
        var latest = this.getFirstItem(feedXml);
        this.state = { };
        this.state.latestData = latest;
        this.state.timestamp = new Date();
        localStorage['latestBrew'] = JSON.stringify(this.state);
        this.renderLatest(latest);
      },
      renderLatest: function(latest){
        $('#main>h1').text(latest.title);
        $('#content').html(latest.content);
        this.todaysUrl = latest.url;
      },      
      getFirstItem: function(feedXml){
        var items = feedXml.evaluate("//channel/item", feedXml, 
                                 null, XPathResult.ANY_TYPE, null); 

        var item = items.iterateNext(); 
        if (item) {
          return this.createItem(item);
        }
      },      
      createItem: function(postXml) {
        return { 
          title: this.readElementText(postXml, 'title'),
          url: this.readElementText(postXml, 'feedburner:origLink'),
          content: this.readElementText(postXml, 'content:encoded')
        };
      },
      mapElements: function(contextElement, path, map){
        var result = [ ];
        var items = contextElement.ownerDocument.evaluate(path, contextElement, 
                                this.namespaceResolver, XPathResult.ANY_TYPE, null); 
        
        var item = items.iterateNext(); 
        var i = 0;
        while (item) {
          result.push( map(item, i++) );
          item = items.iterateNext();
        }

        return result;
      },      
      readElementText: function(contextElement, path){
        var results = contextElement.ownerDocument.evaluate(path, contextElement, 
                                   this.namespaceResolver, XPathResult.ANY_TYPE, null); 
        var first = results.iterateNext(); 

        if (first) {
          return first.textContent;
        }
      },      
      namespaceResolver: function(prefix) {
        if(prefix == 'content') {
          return 'http://purl.org/rss/1.0/modules/content/';
        }
        if(prefix == 'feedburner') {
          return 'http://rssnamespace.org/feedburner/ext/1.0';
        }
      }

    }
  }
};

Wow, that's a lot of JavaScript at once, right? Hopefully you'll notice that most of it is just to parse the RSS xml.

Only a few parts of this code deserve commentary. The refresh method (line 45) is the one that retrieves the RSS data. It uses the jQuery.get method to do so. Once the data arrives, it will invoke update, which will use the parsing methods to get an object representing the latest news item in the data.

      update: function(feedXml) {
        var latest = this.getFirstItem(feedXml);
        this.state = { };
        this.state.latestData = latest;
        this.state.timestamp = new Date();
        localStorage['latestBrew'] = JSON.stringify(this.state);
        this.renderLatest(latest);
      },

The above code also shows the use of two important APIs that Chrome implements. The localStorage is a way to persist information that lives in the client machine and lasts even after the browser closes. We use it to remeber our last results and avoid fetching and parsing the RSS each time the popup is opened.

The other API is the native JSON object that can replace any dedicated library we are used to have in cross-browser websites. We need to stringify the data because we can only save strings in the local storage.

With the parsed data at hand we just need to replace the content in those empty html tags in popup.html with the information we have.

Adding some life with events

The last piece of this puzzle are the jQuery event handlers that we created in the init method. They make some of the elements clickable, including the links, which open new tabs using chrome.tabs.create(). Also note starting on line 29 that if we find recent local data we use that instead of refreshing the content from the RSS feed.

Let's load this thing up

Now we just need to run it and see how it goes. Go to the extesions page, expand the Developer Mode area and click Load unpacked extension....

Then simply browse to your extension's directory and select it. The extension should now be listed as seen below.

While you're developing your extension you can debug it using the developer tools included in Chrome. To do that, right click the extension button and select Inspect popup.

You can download the code for this extension and play with it all you want. I'm still early into learning this so feel free to give me pointers or ask questions.

More on blocked files

2010-06-24T03:26:00Z

I've written about this before. You download a file to use in your web application, like a JavaScript library or an image file but the browser just can't seem to load it. You spend hours looking for a typo or broken link until you find out about that Unblock button and you realize that it's IIS that isn't serving the file. The file had been there; you had the correct URL all along; it's just disallowed.

I actually developed the reflex to right click and unblock each an every file I download now. It's stupid, isn't it? I should have imagined there was a way to disable that Windows feature instead of just learning how to live with the problem.

Well, no more. Here's how you can disable it. Credit goes to this article.

Run gpedit.msc (the group policy editor)
Go to User Configuration/Administrative Templates/Windows Components/Attachment Manager
Find the setting named Do not preserve zone information in file attachments and enable it
Log off then log back on, or update the current policies with: Gpupdate /force in any command prompt.

Note: If you're using Chrome it looks like there's some bug that may or may not be taken care of as you read this. Chrome doesn't seem to honor the policy setting and always mark the downloaded files as unsafe.

Now I just need to add this to the list of tasks anytime I get a new machine or repave one of them.

The Ground is Shaking Again. Get Mobile.

2010-06-17T05:08:00Z

A little over two years ago I commented how surprising it was that VisualBasic was still more popular than C# in the .Net world. Back then I checked the TIOBE Index and saw that VB (in all its flavors) enjoyed almost 11% of relevance while C# wasn't even at the 4% level.

When we look at the June 2010 rank below we see that C# has finally caught up with VB, and it's safe to say C# is now the most popular .Net language (remember, the VB index is not made up of just VB.NET.)

1	Java	18.03%
2	C	17.81%
3	C++	10.76%
4	PHP	8.93%
5	(Visual) Basic	5.87%
6	C#	5.20%
7	Python	4.27%
8	Perl	3.20%
9	Objective-C	2.47%
10	Delphi	2.39%
11	JavaScript	2.19%
12	Ruby	2.07%
13	PL/SQL	0.79%
14	SAS	0.70%
15	Pascal	0.70%
16	Lisp/Scheme/Clojure	0.65%
17	Lua	0.59%
18	MATLAB	0.59%
19	ABAP	0.58%
20	PowerShell	0.53%

Again, anyone can debate the importance of this ranking system, but at least it has been there for a while and to me it seems to represent the pulse of software development quite well.

Movers and shakers

But this post is not about C# vs. VB.NET.

This time around what caught my attention was the impressive rise of Objective-C (up 36 positions in one year). Now, no matter how more common Macs have become in the last few years, no one will convince me this increase in Objective-C is due to native OSX application development :)

Of course we all know it's caused by the surge in mobile and device app development (iPhone, iPad, and anything that they decide will run the iOS, like the AppleTV in the future, who knows?)

If you look at the trending chart on the TIOBE page you'll see that Objective-C started to gain significant steam around June of last year, coincidentally (maybe not?) when the iPhone 3GS was announced.

Keep your eyes on the ball

Are you playing with Mobile yet? Have you:

Started reading about mobile development?
Developed a Mobile web site?
Written and tested a native app against a device emulator/VM (iPhone, Android, WebOS, WP7)?
Written and deployed an app to your own mobile device?
Published an app on the market?

It's not like you will find yourself out of a job if you don't get into mobile but for many developers, from software shops to corporate environments, sooner or later a request for a mobile product or a mobile version of an existing one will swing by your desk.

It's an exciting time. Once again you have the chance of taking the lead and play an important role in your team by staying ahead of the game. Remember when you started seeing request for Ajax and fancy UI's in your web applications. Remember how you were one of the few that knew anything about it in your team? Same thing here. Only much bigger.

What I'm looking into

There are two different fronts that interest me in mobile development: Native Android apps and Mobile Sites. I'll explain.

The time I spent in Objective-C and XCode in the past was enough for me to know I'd be grinding my teeth and blowing off steam every single day if I wanted to develop for the iPhone (it's probably just me, I can live with that admission.) Besides, I don't like the idea of an approval process before I can give away or sell my apps.

Windows Phone is something that I'll have to wait more and see what kind of traction it gains. It also has the approval process issue. The big plus will be the development tools, which I think will better than iPhone and Android.

All that, combined with the enormous momentum that Android has, made me start coding for Android when it comes to native apps.

Don't forget Mobile Web

Native mobile development is fun and rewarding but let's not kid ourselves. History shows that businesses will favor the simplicity of web development.

I went through that transition period when custom desktop application development quickly lost market to web applications. And that happened in a world where Windows was virtually in every workstation that mattered.

Now imagine the mobile scene, where there's more than one big player, none equivalent to what Windows was back in 1998. Do you really think anyone will want incur the cost of maintaining 3 or 4 different native versions of each mobile application that we will start cranking out like we do web apps today? Native apps will probably be the minority, for environments where you have the luxury of dictating your end-user's choice of mobile device.

Didn't we just spend the better part of the last 10 years trying to get out of a certain single-browser paradigm? Do we want to repeat that mistake?

Moving to HTML5

Why is HTML5 so important in Mobile and not as much in the standard Web yet? Well, for one there is a greater percentage of HTML5-capable browsers in Mobile than on the desktop browsers. Android, iPhone, WebOS (and soon BlackBerries) have WebKit browsers.

With things like richer forms, offline support, canvas, video and the Geo-Location API (not really HTML5 but present in those WebKit browsers) we can build really capable mobile web apps. Not just small screen versions of the regular web apps.

To be very straight forward about it, the way I personally see it is that HTML5 is where the bulk of the mobile development will happen in the Enterprise and consumer-facing applications.

Maybe something like Flash, AIR, or Silverlight makes a run for their mobile money too but with all the bullying from Apple and diverging opinions everywhere, that's not something I'm spending time on right now.

Native or Web?

Both. But definitely much more of the Web kind.

Events do not a community make

2010-06-15T13:17:00Z

It's a recurring theme. The relationship between the .Net developers community, the community leaders, Microsoft products, and Microsoft itself is an endless debate.

These last couple of weeks I've seen it come back again, strong, with the usual rants, departure notices, and rebuttals (which are getting fewer and further between).

The Microsoft .Net User Group Leaders

I run a small .Net UG in Chicago and when I have a chance to talk with other user group organizers, no matter how truly dedicated and valuable they are, I invariably come to the same sad conclusion.

The majority of the UG's act as mere outlets for showing off introductory talks on whatever is the shiny new technology from Microsoft. I wonder if all user groups have a clear (or even unclear) mission statement.

There's nothing intrinsically wrong with providing 100-level content about new products. The problem I see is that this doesn't really contribute much to build any kind of community and we can't make our UGs be restricted to just that.

In many UGs there's a lot of emphasis put in "Microsoft" and ".Net" but almost none in "User" or "Group." I think this is completely backwards. The UG leaders should have their focus on their members 100% of the time, thinking how the UG can be used to truly benefit their members, making all of us better developers, not just better .Net developers (Microsoft or ALT) and much less better MS developers.

The .Net Developer Community

We all know this community isn't exactly like other developer communities. I'd even go out on a limb and say that the use of the word community is a bit of a stretch, it's more like a demographic.

We grew up simply waiting what comes out of One Microsoft Way and attended MS-produced events and conferences. I think there are very few occurrences of organically formed community manifestations in .Net, like the Code Camps and ALT.NET.

That's something that can't be changed by just talking about it. As community members there are things we could do.

Look for developer events even if you weren't forwarded one of those MSDN emails (there's Community Megaphone, Meetup, EventBrite, just to name a few).
Attend non-MS user group meetings. Seriously. If you're a web developer, look for a JavaScript or Flash UG. If you're curious about the Windows Phone, check out the iPhone and Android users groups too. There's a lot to learn and much networking to be done.
Attend Code Camps, even if costs you a small road trip. There's no way you'll ever regret doing this.

We will only be a community when we start acting as such.

Microsoft

At least in my region Microsoft does a very commendable work in trying to connect the .Net developers with non-.Net ones. More and more I see MS interested in leaving the community organization to community itself, providing some level of infrastructure, access to good speakers and sponsorship when possible.

I'm not convinced MS knows how to measure the health of .Net communities. For me, even looking from MS' standpoint, a successful community is one where a novices have easy access to experts and where knowledge and opportunities are exchanged. It doesn't matter that you have tens of thousands of .Net developers in your region if you don't know where to find them for a question or business proposition.

Microsoft Products

Like any other technology company, Microsoft releases products that range from tremendously successful to niche applications to complete failures.

We can never dispose of critical eyes when analyzing a new product. The community members invest their time when attending meetings and events. We need to always demand perspective in addition to purely technical content.

Here I want to draw the line and separate developer tools from core technologies. As a developer I'm ok to be seen as a consumer of developer tools, like Visual Studio and Blend, but when it comes to the platform technologies, like IIS, SQL Server, Azure, Silverlight, etc I much rather be treated as a coworker that is trying to create high quality software with these products. Forget that there's money to be made by both of us in this process when we talk about core technologies.

Can we fix this?

I used to be more optimistic about this situation. I still hope we can stir the will to participate, produce, and consume all things .Net.

The one thing I know for sure is that I won't sit and watch until it happens. I try to do the tiny bit I can but I like this stuff too much and I have no problem in carrying my energy over to another platform.

But the question stands — Is there a way to make it work?

Careful with those enumerables

2010-05-09T16:20:00Z

Ever since .Net 2.0 introduced the yield keyword for creating enumerators, and even more after the introduction of LINQ in C# 3.0, I've seen more and more APIs return IEnumerable<T> instead of IList<T> or ICollection<T> or their older cousins the ArrayList and the array object.

That makes sense most of the time, especially for collections that aren't meant to be modified, and choosing between those different return types is not what I'm about to discuss here. You can find endless articles and threads about that.

The caller's perspective

What has caused me some trouble recently was being caught off guard by some unexpected performance penalties when using one of those IEnumerable<T>.

Not that IEnumerable<T> has any performance issue by itself but the way we deliver it can misguide the caller. Let me try to make that statement a little clearer with a small example.

Consider this ProductCatalog class that basically wraps a collection of Product objects.

public class ProductCatalog
{
  private readonly IInventoryService _inventoryService;
  private List<Product> _products;

  public ProductCatalog(IInventoryService inventoryService)
  {
    _inventoryService = inventoryService;
    _products = new List<Product>();
  }

  public void Populate()
  {
    //imagine this will populate from a database
    _products.Add(new Product {Id = 1, Price = 12.34m});
    _products.Add(new Product {Id = 2, Price = 11.22m});
    _products.Add(new Product {Id = 3, Price = 7.99m});
    _products.Add(new Product {Id = 4, Price = 3.49m});
	//...
    _products.Add(new Product {Id = 10000, Price = 75.99m});
  }

  public IEnumerable<Product> Products { get { return _products; } }

  public IEnumerable<Product> AvailableProducts
  {
    get
    {
      return Products
        .Where(product => _inventoryService.IsProductInStock(product));
    }
  }
}

And here's the code using it.

var catalog = new ProductCatalog(new InventoryService());
catalog.Populate();

var available = catalog.AvailableProducts;

foreach (var product in available)
{
  Console.Out.WriteLine("Product Id " + product.Id + " is available.");
}

var priceSum = 0m;

priceSum = available.Sum(product => product.Price);
Console.Out.WriteLine(
  "If I buy one of each product I'll pay: " + priceSum.ToString("c"));

The InventoryService is something like this:

public class InventoryService : IInventoryService
{
  public bool IsProductInStock(Product product)
  {
    Console.Out.WriteLine("Expensive verification for prod id: " + product.Id);
    //imagine something a little more complex and lengthy is happening here.
    return true;
  }
}

It seems trivial enough, but let's look at what the output gives us:

Expensive verification for prod id: 1
Product Id 1 is available.
Expensive verification for prod id: 2
Product Id 2 is available.
Expensive verification for prod id: 3
Product Id 3 is available.
Expensive verification for prod id: 4
Product Id 4 is available.
Expensive verification for prod id: 10000
Product Id 10000 is available.
Expensive verification for prod id: 1
Expensive verification for prod id: 2
Expensive verification for prod id: 3
Expensive verification for prod id: 4
Expensive verification for prod id: 10000
If I buy one of each product I'll pay: $111.03

See? If I didn't know how ProductCatalog.AvailableProducts was implemented I would be stumped by this behavior. Looking at this from the caller's point of view, I was just trying to use an object's collection property twice, probably thinking the return value would be the same collection of objects each time.

Well, they were the same individual Product objects in each call but they most definitely were not packaged in the same collection structure, and I don't know about you but I would never, in a million years, think that accessing that property would cause the collection to be rebuilt each time.

What's an API designer to do?

My suggestion in situations like the above, where the collection is closer to an object feed than a fixed list, is to implement that member as a method, not a property. Callers are more likely to associate a method call to something expensive than in the property access case.

Properties carry a historical expectation of being cheap to use and consistent. If your property's design includes the chance of not honoring this expectation, like in my example which depended on an injected IInventoryService, then use a method instead.

If you can't use a method for whatever reason, try to at least lazy load or cache the returned collection.

The last thing you want is requiring your callers to know implementation details of all your collection-returning members to decide how they should use the collection.

So this is not about the return type, huh?

As you may have noticed, the problem I went into had nothing to do with IEnumerable<T>, it could have happened with any of the other mentioned types — they're all enumerable anyway. I could certainly convert my example to IList<T> and still have the same problem.

The reason I called out IEnumerable<T> more explicitly is that it seems to happen more with it than the other ones. Maybe that's because the LINQ extension methods return IEnumerable<T> or because an IList<T> property backed by a fixed List<T> collection is a very common implementation choice.

ANN: The Second Chicago Code Camp

2010-03-22T17:26:00Z

After a successful first Chicago Code Camp last year, we're back to announce the second edition of this unique technical event.

The Chicago Code Camp 2 will happen on May 1^st. In this event we are addressing one obvious and recurring feedback: Make it closer to the city.

We're thrilled to announce that our Code Camp will take place at the IIT Campus, just South of downtown Chicago, easily accessible by car and public transportation.

What is the Chicago Code Camp?

Just like last year, we want to host an event where any platform or programming language can have its space, as long as there's community interest in talking and hearing about it.

The code camp is a great opportunity to learn about and network with developers of different walks of life and technologies. Last year we had diverse topics such as .NET, Python, iPhone, Ruby, XUL, JavaScript, Scala, etc. We hope to have even more this time around.

To ensure the numerous technical communities are fairly represented, we are inviting all local technical community leaders to get involved and provide speakers and attendees.

The event is free to attend but everyone needs to register. ~~Registration will open soon~~ Registration is open and it's limited due to the venue capacity.

Call for Speakers

The Chicago Code Camp website is up and ready to receive talk proposals.

The Code Camp Manifesto calls for sessions that privilege code over theory or slides, but it doesn't mean a good presentation will be immediately turned down because of that.

Stay tuned

We will have more exciting news and announcements to share about this event. We will do so as soon are they are confirmed.

Keep an eye on the website (or this blog) to learn about registrations, volunteering, and getting involved.

dotTrace 3.1 64-bit disabled inside Visual Studio 2008

2010-03-12T18:15:00Z

I work on a web application and I use dotTrace when some profiling is needed. The problem is that I cannot fire off doTrace directly from inside Visual Studio 2008 because the commands and toolbar icons to launch it are permanently disabled. Well, not anymore.

Background

The web application I work on is a 64-bit application. I use a 64-bit version of Windows (namely, Win2008 x64). I installed the 64-bit version of dotTrace 3.1 and it does work stand-alone but it never worked integrated with VS 2008, which is a shame because it contains some neat features like it's enabling the ReSharper test runner to run the chosen test(s) directly under dotTrace profiling. The screen shot below shows how it should look like but on my box these dotTrace commands were simply disabled.

The fix

After much disappointment with the missing features, my fellow Devlicio.us blogger Hadi Hariri put me in contact with Oleg Stepanov.

The first suggestion was trying the 32-bit version of dotTrace, which wasn't an option for me because, as I said, my application and all the supporting utilities are 64-bit, it runs under a 64-bit process, so that's ultimately how I need to profile it.

Then Oleg explained that the problem is that VS is a 32-bit application and it was looking for a registry key in the wrong place, not finding it, and then it was assuming dotTrace wasn't available.

Hmmm... That sounded eerily familiar, didn't it? Once again the little annoyances of developing 64-bit code with 32-bit tools come to bite us.

To fix the problem, just like the other time it happened, we just need to copy the right registry key to its corresponding place under the Wow6432Node key.

Open the Registry Editor and go to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ key. One of its GUID-named subkeys will contain the dotTrace information. Just search for dotTrace and find the right subkey. Now just copy (or export/edit/import) that key under HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\ and you're ready to restart Visual Studio and see all the integrated dotTrace features come alive.

[ANN] Chicago ALT.NET shows Rake and Albacore

2010-03-09T23:35:00Z

I haven't mentioned our meetings here in a while but our group has been going strong and enthusiastic all this time.

Tomorrow, March 10^th our topic will be build scripts for .Net projects using Rake and Albacore. I've been using Rake and a little bit of Albacore in my own projects and I'm ready to say that it will take a very serious event to make me go back to NAnt or MSBuild.

Introduction to Rake with Albacore.NET

6:00 pm
Pizza and networking time

6:30 pm

How would you to write your build scripts using a scripting language instead of XML? In this month's meeting we will see how the ease of programming in Ruby can be used to create a much more pleasant and extensible build script.

Rake isn't just for Rubyists or Alphageeks anymore. Albacore helps bring the power and expresiveness of the Ruby language to the world of .NET build automation. Using Rake it's never been easier to handle build automation, test execution, continuous integration and just about any task you need to automate for your build.

Michael D. Hall has been developing software on the Microsoft platform for over a decade. He's been an Alt.NETter for years and is really enjoying the exposure to different ideas and concepts beyond the safe confines of the .NET world. Currently he's a consultant working with Obtiva and has started a Cloud Developer's Group that meets monthly in McHenry county.

Rule "Previous releases of Microsoft Visual Studio 2008" failed

2010-03-07T10:43:00Z

Today I was trying to install SQL 2008 on my box and the setup stopped after checking a bunch of rules. The error message was the title of this post.

A quick search on the internet revealed that somehow the installer didn't believe I had VS 2008 SP1 installed, which I did. The recommendations in the KB article were kind of insulting. There's no way I'd spend hours of my day uninstalling and reinstalling VS and SQL — sorry, no chance. I also could not accept not installing the Management Tools, for example. I also did not have any Express version of VS or SQL installed in this box.

A little snooping around with ProcMon led me to the following registry key:

HKLM\SOFTWARE\Wow6432Node\Microsoft\DevDiv\VS\Servicing\9.0\IDE\1033

In that key I noticed the suspicious values:

"SP"=dword:00000000
"SPIndex"=dword:00000000
"SPName"="RTM"

Without quitting the SQL server installer validaton screen, I changed these values to what you see below, crossed my fingers and rerun the installer validation, which passed!

"SP"=dword:00000001
"SPIndex"=dword:00000001
"SPName"="SP1"

Now, I didn't really guess those values. I looked in a sibling registry key (...Servicing\9.0\PRO\1033) and saw that it contained those new values, then I copied them.

I think I didn't break anything. So far all seems to be working. But, as usual with anything related to manual registry hacking, you have to be really insane to change your settings because you read on a random blog on the 'net. I'm just saying... Don't come crying if your house burns down because of this.

jQuery Custom Element and Global Events

2010-02-21T18:09:00Z

This last week I learned a new thing about jQuery custom events, particularly the ones of global nature. There's good documentation and examples about custom element events, but not much for the global ones.

Why do we need custom events?

Custom events make it easier to keep complex pages under control. They are a pillar for loosely-coupled UI scripts. Let's start with a simple example.

Suppose we have a fairly complex and dynamic page where many elements are Ajax-editable, using in-place editors or any other approach that posts updates to the server. Depending on how quickly the server responds to the request, there's a chance the user can start another simultaneous request before the first one finishes, maybe even seeing inconsistent results, by clicking a button too soon.

In our example — a fraction of what a real complex page would be — what we want to do is disable some of these buttons while the data is being changed, and re-enable them once we hear back from the server.

Click the field to edit it:<br>

<input type="text" readonly="readonly" id="email" name="email"
   value="joe@doe.com" style="background-color: #eee;"/> 

<input type="button" class="userOperation" id="sendButton" value="Send Message">
<input type="button" class="userOperation" id="summaryButton" value="Summary">

Custom Element Events

Let's tackle this problem first with the custom element events. Below is a summary of how these custom events are used.

$('#publisher').trigger('eventName');

$('#publisher1').bind('eventName', function() {
   //eventName happened. React here.
   $('#subscriber1').doStuff();
   $('#subscriber2').doOtherStuff();
   // more...
});

In this case we will make the elements being edited announce that they entered edit mode so that any other element can act on that announcement.

$('#email').
click(function(){
	$(this).removeAttr('readonly').css({backgroundColor: ''});
	$(this).trigger('editStart');
}).
blur(function(){
	$(this).attr('readonly', 'readonly').css({backgroundColor: '#eee'});
	$.post('/updateEmail', $('#email').serialize(), function() {
		$(this).trigger('editComplete');
	});
}).
bind('editStart', function(){
	// "this" is the #email element
	console.log('edit started, this =  ' + this.id);
	$('.userOperation').attr('disabled', 'disabled');
}).
bind('editComplete', function(){
	// "this" is the #email element
	console.log('edit complete, this =  ' + this.id);
	$('.userOperation').removeAttr('disabled');		
});

$('#sendButton').click(function(){
	//code to send a message
	alert('Message sent');
});

$('#summaryButton').click(function(){
	//code to generate summary
	alert('Summary created');
});

This approach works well in the beginning but gets really ugly as more elements need to publish their own similar events or when other new elements need to do somethings with these events too. We will need to bind handlers to all these element's events and the code inside these handlers will start getting longer and probably too far from the rest of the code that relates to it.

One step forward with page level events

Since the events we are producing here really reflect the document state more than any individual field's state, let's move that event to a more top level element, namely the body element:

$('#email').
click(function(){
	$(this).removeAttr('readonly').css({backgroundColor: ''});
	$('body').trigger('editStart');
}).
blur(function(){
	$(this).attr('readonly', 'readonly').css({backgroundColor: '#eee'});
	$.post('/updateEmail', $('#email').serialize(), function() {
		$('body').trigger('editComplete');
	});
});

$('body').
bind('editStart', function(){
	// "this" is the body element
	console.log('edit started, this =  ' + this.tagName);
	$('.userOperation').attr('disabled', 'disabled');
}).
bind('editComplete', function(){
	// "this" is the body element
	console.log('edit complete, this =  ' + this.tagName);
	$('.userOperation').removeAttr('disabled');		
});

$('#sendButton').click(function(){
	//code to send a message
	alert('Message sent');
});

$('#summaryButton').click(function(){
	//code to generate summary
	alert('Summary created');
});

Now we're getting somewhere. We reduced the number of event sources to just one, so guaranteed less duplication. But it still has some shortcomings.

The code is still bound to a different element than the one we want to operate on. What I mean by that is that the event handlers are in the context of the elements publishing the event and the code in the handlers is typically geared towards the elements that need to react to that event, that is, the this keyword is less useful than in most of your common event handlers.

The pattern of these page-level events is:

$('body').trigger('eventName');

$('body').bind('eventName', function() {
   //eventName happened. React here.
   $('#subscriber1').doStuff();
   $('#subscriber2').doOtherStuff();
   // more...
});

But wait, jQuery has real global events too

I had settled down with using the above style of global events until someone at work pointed out that there's another way of doing this, which unfortunately isn't as well discussed: the custom global events.

Here's our code using global custom events:

$('#email').click(function(){
	$(this).removeAttr('readonly').css({backgroundColor: ''});
	$.event.trigger('editStart');
}).blur(function(){
	$(this).attr('readonly', 'readonly').css({backgroundColor: '#eee'});
	$.post('/updateEmail', $('#email').serialize(), function() {
		$.event.trigger('editComplete');
	});
});

$('.userOperation').bind('editStart', function(){
	// "this" is a .userOperation button
	console.log('edit started, button: ' + this.id);
	$('.userOperation').attr('disabled', 'disabled');
}).bind('editComplete', function(){
	// "this" is a .userOperation button
	console.log('edit complete, button: ' + this.id);
	$('.userOperation').removeAttr('disabled');		
});

$('#sendButton').click(function(){
	//code to send a message
	alert('Message sent');
});

$('#summaryButton').click(function(){
	//code to generate summary
	alert('Summary created');
});

What is great about this type of event is that they are in the context of the subscribing elements, as if these elements were the publishers of the event, much like the majority of the event handling code we write.

They also allow us to move more code next to the other event handler for the subscribing elements, and even chain them all together. As an example, let's modify the event handlers of the #sendButton element to add some different behavior when the editStart event happens.

$('#sendButton').click(function(){
	//code to send a message
	alert('Message sent');
}).bind('editStart', function(){
	// "this" is the #sendButton button
	this.value = 'Send message (please refresh)';
	// change the click event handler.
	$(this).unbind('click').click(function(){
		alert('Sorry, refresh page before sending message');
	});
});

And here is the simplified representation of the global events code.

$.event.trigger('eventName');

$('#subscriber1').bind('eventName', function() {
   //eventName happened. React here.
   $(this).doStuff();
});

$('#subscriber2').bind('eventName', function() {
   //eventName happened. React here.
   $(this).doOtherStuff();
});
//more...

Conclusion

Event-based programming is the usual way we write UI code. By understanding the different types of events that jQuery provides we can allow our UI to grow without getting into a messy nightmare of event handling code scattered all over the place.

Code coverage reports with NCover and MSBuild

2010-02-09T18:11:00Z

I've been doing a lot of static analysis on our projects at work lately. As part of that task we added NCover to our automated build process. Our build runs on Team Build (TFS) and is specified in an MSBuild file.

We wanted to take code metrics very seriously and we purchased the complete version of the product to take full advantage of its capabilities.

Getting NCover to run in your build is very simple and the online documentation will be enough to figure it out. The problem comes when you begin needing to create more and more variations of the reports. The online documentation is a little short on this aspect, especially on how to use the MSBuild or NAnt custom tasks. I hear they plan to update the site with better docs for the next version of the product.

NCover Complete comes with 23 different types of reports and a ton of parameters that can be configured to produce far more helpful reports than just sticking to the defaults.

For example, we are working on a new release of our product and we are pushing ourselves to produce more testable code and write more unit tests for all the new code. The problem is that the new code is a just tiny fraction of the existing code and the metrics get averaged down by the older code.

The key is to separate the code coverage profiling (which is done by NCover while it runs all the unit tests with NUnit) from the rendering of the reports. That way we only run the code coverage once; and that can sometimes take a good chunk of time to produce the coverage data. Rendering the reports is much quicker since the NCover reporting engine can feed off the coverage data as many times as we need, very quickly.

Once we have the coverage data we can choose which report types we want to create, the thresholds for sufficient coverage (or to fail the build), which assemblies/types/methods we want to include/exclude from each report and where to save each of them.

Example

To demonstrate what I just described in practice, I decided to take an existing open source project and add NCover reporting to it. The project I selected was AutoMapper mostly because it's not very big and has decent test coverage.

I downloaded the project's source code from the repository and added a file named AutoMapper.msbuild to its root directory. You can download this entire file but I'll go over it piece by piece.

We start by just importing the MSBuild tasks that ship with NCover into our script and declaring a few targets, including one to collect coverage data and one to generate the reports. I added the NCover tasks dll to the project directory tools/NCoverComplete.

<Project DefaultTargets="RebuildReports" 
  xmlns="http://schemas.microsoft.com/developer/msbuild/2003" >
  <UsingTask  TaskName="NCover.MSBuildTasks.NCover" 
        AssemblyFile="$(ProjectDir)tools\NCoverComplete\NCover.MSBuildTasks.dll"/>
  <UsingTask  TaskName="NCover.MSBuildTasks.NCoverReporting" 
        AssemblyFile="$(ProjectDir)tools\NCoverComplete\NCover.MSBuildTasks.dll"/>

  <PropertyGroup>
    <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
    <BuildDir>$(MSBuildProjectDirectory)\build\$(Configuration)</BuildDir>
    <NUnitBinDirectoryPath>$(MSBuildProjectDirectory)\tools\NUnit</NUnitBinDirectoryPath>
  </PropertyGroup>

  <Target Name="RebuildReports" DependsOnTargets="RunCoverage;ExportReports" >
    <Message Text="We will rebuild the coverage data than refresh the reports." 
          Importance="High" />
  </Target>

  <Target Name="RunCoverage" >
    <!-- snip -->
  </Target>

  <Target Name="ExportReports" >
    <!-- snip -->
  </Target>
</Project>

Now let's look closely at the target that gathers the coverage data. All it does is tell NCover (NCover console, really) to run NUnit over the AutoMapper.UnitTests.dll and save all the output to well-known locations.

<Target Name="RunCoverage" >
  <Message Text="Starting Code Coverage Analysis (NCover) ..." Importance="High" />
  <PropertyGroup>
    <NCoverOutDir>$(MSBuildProjectDirectory)\build\NCoverOut</NCoverOutDir>
    <NUnitResultsFile>build\NCoverOut\automapper-nunit-result.xml</NUnitResultsFile>
    <NUnitOutFile>build\NCoverOut\automapper-nunit-Out.txt</NUnitOutFile>
    <InputFile>$(BuildDir)\UnitTests\AutoMapper.UnitTests.dll</InputFile>
  </PropertyGroup>

  <NCover ToolPath="$(ProgramFiles)\NCover"
    ProjectName="$(Scenario)"
    WorkingDirectory="$(MSBuildProjectDirectory)"   
    TestRunnerExe="$(NUnitBinDirectoryPath)\nunit-console.exe"

    TestRunnerArgs="$(InputFile) /xml=$(NUnitResultsFile) /out=$(NUnitOutFile)"

    AppendTrendTo="$(NCoverOutDir)\automapper-coverage.trend"
    CoverageFile="$(NCoverOutDir)\automapper-coverage.xml"
    LogFile="$(NCoverOutDir)\automapper-coverage.log"
    IncludeTypes="AutoMapper\..*"
    ExcludeTypes="AutoMapper\.UnitTests\..*;AutoMapper\.Tests\..*"
    SymbolSearchLocations="Registry, SymbolServer, BuildPath, ExecutingDir"
  />
</Target>

Of special interest in the NCover task above are the output files named automapper)-coverage.xml and automapper-coverage.trend, which contain the precious coverage data and historical trending respectively. In case you're curious, the trend file is actually a SQLite3 database file that you can report directly from or export to other database formats if you want.

Also note the IncludeTypes and ExcludeTypes parameters, which guarantee that we are not tracking coverage on code that we don't care about.

Now that we have our coverage and trend data collected and saved to files we know, we can run as many reports as we want without needing to execute the whole set of tests again. That's in the next target.

<Target Name="ExportReports" >
  <Message Text="Starting Producing NCover Reports..." Importance="High" />
  <PropertyGroup>
    <Scenario>AutoMapper-Full</Scenario>
    <NCoverOutDir>$(MSBuildProjectDirectory)\build\NCoverOut</NCoverOutDir>
    <RptOutFolder>$(NCoverOutDir)\$(Scenario)Coverage</RptOutFolder>
    <Reports>
      <Report>
        <ReportType>FullCoverageReport</ReportType>
        <OutputPath>$(RptOutFolder)\Full\index.html</OutputPath>
        <Format>Html</Format>
      </Report>
      <Report>
        <ReportType>SymbolModuleNamespaceClass</ReportType>
        <OutputPath>$(RptOutFolder)\ClassCoverage\index.html</OutputPath>
        <Format>Html</Format>
      </Report>
      <Report>
        <ReportType>Trends</ReportType>
        <OutputPath>$(RptOutFolder)\Trends\index.html</OutputPath>
        <Format>Html</Format>
      </Report>
    </Reports>
    <SatisfactoryCoverage>
      <Threshold>
        <CoverageMetric>MethodCoverage</CoverageMetric>
        <Type>View</Type>
        <Value>80.0</Value>
      </Threshold>
      <Threshold>
        <CoverageMetric>SymbolCoverage</CoverageMetric>
        <Value>80.0</Value>
      </Threshold>
      <Threshold>
        <CoverageMetric>BranchCoverage</CoverageMetric>
        <Value>80.0</Value>
      </Threshold>
      <Threshold>
        <CoverageMetric>CyclomaticComplexity</CoverageMetric>
        <Value>8</Value>
      </Threshold>
    </SatisfactoryCoverage>

  </PropertyGroup>

  <NCoverReporting 
    ToolPath="$(ProgramFiles)\NCover"
    CoverageDataPaths="$(NCoverOutDir)\automapper-coverage.xml"
    LoadTrendPath="$(NCoverOutDir)\automapper-coverage.trend"
    ProjectName="$(Scenario) Code"
    OutputReport="$(Reports)"
    SatisfactoryCoverage="$(SatisfactoryCoverage)"
  />
</Target>

What you can see in this target is that we are creating three different reports, represented by the Report elements and that we are changing the satisfactory threshold to 80% code coverage (down from the default of 95%) and the maximum cyclomatic complexity to 8. These two blocks of configuration are passer to the NCoverReporting task via the parameters OutputReport and SatisfactoryCoverage, respectively.

The above reports are shown in the images below.

Focus on specific areas

Let's now say that, in addition to the reports for the entire source code, we also want to keep a closer eye on the classes under the AutoMapper.Mappers namespace. We can get that going with another reporting target, filtering the reported data down to just the code we are interested in:

<Target Name="ExportReportsMappers" >
  <Message Text="Reports just for the Mappers" Importance="High" />
  <PropertyGroup>
    <Scenario>AutoMapper-OnlyMappers</Scenario>
    <NCoverOutDir>$(MSBuildProjectDirectory)\build\NCoverOut</NCoverOutDir>
    <RptOutFolder>$(NCoverOutDir)\$(Scenario)Coverage</RptOutFolder>
    <Reports>
      <Report>
        <ReportType>SymbolModuleNamespaceClass</ReportType>
        <OutputPath>$(RptOutFolder)\ClassCoverage\index.html</OutputPath>
        <Format>Html</Format>
      </Report>
      <!-- add more Report elements as desired -->
    </Reports>
    <CoverageFilters>
      <Filter>
        <Pattern>AutoMapper\.Mappers\..*</Pattern>
        <Type>Class</Type>
        <IsRegex>True</IsRegex>
        <IsInclude>True</IsInclude>
      </Filter>
      <!-- include/exclude more classes, assemblies, namespaces, 
      methods, files as desired -->
    </CoverageFilters>

  </PropertyGroup>

  <NCoverReporting 
    ToolPath="$(ProgramFiles)\NCover"
    CoverageDataPaths="$(NCoverOutDir)\automapper-coverage.xml"
    ClearCoverageFilters="true"
    CoverageFilters="$(CoverageFilters)"
    LoadTrendPath="$(NCoverOutDir)\automapper-coverage.trend"
    ProjectName="$(Scenario) Code"
    OutputReport="$(Reports)"
  />
</Target/>

Now that we have this basic template our plan is to identify problem areas in the code and create reports aimed at them. The URLs of the reports will be included in the CI build reports and notification emails.

It's so easy to add more reports that we will have reports that will live for a single release cycle or even less if we need it.

I hope this was helpful for more people because it did take a good amount of time to get it all sorted out. Even if you're using NAnt instead of MSBuild, the syntax is similar and I'm sure you can port the idea easily.

How to detect the text encoding of a file

2010-01-27T01:18:00Z

Today I needed a way to identify ANSI (Windows-1252) and UTF-8 files in a directory filled with files of these two types. I was surprised to not find a simple way of doing this via a property of method somewhere under the System.IO namespace.

Not that it's that hard to identify the encoding programmatically, but it's always better when you don't need to write a method yourself. Anyway, here's what I came up with. It detects UTF-8 encoding based on the encoding signature added to the beginning of the file.

The code below is specific to UTF-8 but shouldn't be too hard to extend the example to detect more encodings.

public static bool IsUtf8(string fname){
  using(var f = File.Open(fname, FileMode.Open)){
    var sig = new byte[Encoding.UTF8.GetPreamble().Length];
    f.Read(sig, 0, sig.Length);
    return sig.SequenceEqual(Encoding.UTF8.GetPreamble());
  }
}

Maybe I just looked in the wrong places. Does anyone know a simpler way in the framework to accomplish this?

On ALT.NET and patience

2010-01-19T20:42:00Z

There ALT.NET bashing season is on full steam. Ian Cooper has a thorough post about it.

To my recollection, ALT.NET was formed by people that shared very similar tastes on what represents good development tools, practices, and methodologies. This group of people, just by the simple fact that they decided to get together under one roof to discuss these ideas, showed that they are constantly and decidedly trying to become better at what they do.

But when you take the step to form a new community or movement (or whatever else you want to call it) you can't easily control who jumps on board or who jumps ship - and you shouldn't even try to.

Inevitably the original idea started to attract many different kinds of participants, which I'm going to roughly distribute in the below four categories (I was tempted to use the term personas, but … never mind.)

I'm here to help
- I like to teach,
- to write,
- to contribute to OSS,
- coordinating UGs and events
Those who like to complain
A very minor percentage of those know how to externalize their criticism in a constructive way. Unfortunately the majority limit their contributions to rants and trolling.
That's probably the only group of people that I'd try to weed out if I could (but I can't; and we shouldn't).
Those who want to learn
- They want to hear about other ideas,
- to figure out how to bring better practices to their work,
- they have a specific problem and they're seeking opinions or answers.
Heliotropic migrants
The ones who want to be linked to (and hops on) every new, shiny thing for commercial reasons. There's always this type of people. They need to latch on to what could be the next big thing for the sake of their own livelihood. There's nothing wrong with that, by the way.

Some people just can't put up with the other types. Some folks go ballistic with people on #4, others can't stand the whiners in #2. Some don't tolerate repeated or trivial questions from folks that are just trying to learn.

In the midst of all this, it becomes hard to connect #1 and #3, which I think is the ultimate reason for ALT.NET existence.

Frankly speaking, I think I've personally danced around in all these four categories but I find myself most of the time in #3 and some other times in #1. I do apologize for my ventures in #2 – it's hard to avoid.

So, if you dabble in the ALT.NET waters, let me just ask you to exercise a little bit of patience. We all still have a lot to learn and there's very good indications that some of those lessons are permeating the .NET development community — from the individual developer to the big Enterprise, Inc.

Let's no try to change the world with a single swing of the bat. Changing one constructor method at a time will get us further. In the end, the idea is simply to more efficiently produce more maintainable and reliable software.