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?

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.

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.

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.

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.