If you've visited RossCode.com (not in a news reader), you may have noticed that it's a bit cleaner - fewer ads, and only in the sidebar. Well, that's because I was recently accepted into the .NET Small Publishers Room in The Lounge, an ad network run by James Avery. The room is filled with high profile bloggers, such as Dave Donaldson, Steven Harman, Jim Holmes, Michael Eaton and others. From James' announcement:

Joel Ross is another great developer who I have gotten to know much better through twitter. I also have a chance of finishing in the top 3 of his bracket group if UNC makes it all the way.

Amazingly, I'm still in The Lounge, despite UNC losing to Kansas, which is what I was rooting for! Also, note the plug for twitter. That seems to be a theme lately.

And if you're reading this in a feed reader - business as usual. No ads in my feed.

I'm very happy to announce that version 3.0 of the NuSoft Framework has been released and is now available. This release has been a long time coming, and we've had many, many internal debates about how we wanted to implement certain features, which resulted in large portions of implementations being added and subsequently removed.

But all of that is behind us now, and the release is done. So what did we add? Well, we pretty much stuck pretty close to the road map we laid out a while back. Here's the big ones:

• Validation Support: We added validation of properties to determine if fields are required and that strings are less than the max length. This is extendable through overrides and events, so you can add your own validations pretty easily. This needs a ton of documentation, and I plan to write about this more in the future.
• Logging Support: This was one of those things we struggled with. We didn't want to add a dependency in the framework to a particular logging framework, so instead of adding logging support directly, we added the hooks so you could log what you wanted to log. Most of what we could come up with had to do with logging SQL queries, so we made the SqlHelper a partial class and added a base class, so you could add the logging by overriding OnExecuting and OnExecuted. Again, samples are needed to really clear it up.
• Database-based Paging and sorting: We've added a bunch of overloads to Get[Entity]() methods to allow you to page at the database level.

We also fixed a few bugs that were brought to our attention, but those aren't a big deal. As you can tell, documentation is a bit lite right now, but we're working on it!

If you've noticed a slowing of posts here, there's a reason for that: Twitter. Instead of posting short posts here about something I find interesting, I usually throw that on Twitter. Questions I need an answer to? Twitter is real time and so far, has brought great answers much faster than a blog post does - as an example, I posted a blog post the other night and was shocked to see a comment just seven minutes after the original post. On twitter, if you go seven minutes without a response, you're probably not going to get one - and most of the time, you've already gotten two or three responses.

So I've left my daily blogging habits behind and jumped into the micro-blogging scene whole heartedly. Where does that leave RossCode.com? Well, for the most part, my posts will have more answers than questions and will be longer and more in-depth then they have been. Of course, that means they take longer to write and more effort to create. Or simply put, I post less!

Does that mean I think this site is going to die over time? On the contrary - since I started using Twitter heavily, I feel like the blog has come alive. The number of comments has gone way up, and I feel much more connected than I ever have. Since I started this blog in 2004, I've had 390 comments. Since October of '07, I've had 140 comments - a full 35% of my comments coming in the last 6 months of a 4 year run. Right now, as I'm writing this, my home page has 10 posts on it, and there are 59 comments. So less than 0.1% of my posts (I'm well over 1,000) has 15% of the comments. And when I look at where the comments come from, most are either people I follow on Twitter or my responses to them.

To me, that's "The Twitter Effect." Since I started using Twitter, I feel I'm much more in touch with the community of developers in Michigan and the Midwest. I've made some great connections with people that I think will last for a long time, and the more and more I get into Twitter, the more great people I meet.

I remember going to Tech Ed in 2005. It was a real eye opening experience for me. I had read a lot of blogs, and it was the first time I had a chance to actually meet some of them in person. I met a few people there that I'm still friends with, and I quickly realized that conferences were more about who you met than the content available. Well, so far, Twitter has been that same thing - only magnified. I've interacted with some bloggers that I've respected for a long time on Twitter, and I've had my eyes opened to people I didn't know but probably should have.

Anyway, if you're not on Twitter, you should give it a try. Start by following me. Then look at who I follow and go from there. You'll probably start to recognize names. And if you do give it a go, let me know - I've started to be more and more picky about who I follow to avoid overload, but if you're a reader here, I definitely want to follow you!

In a recent post, I laid out how I went about adding Dependency Injection to a particular class to give it flexibility and make it easier to maintain over time. At the end, I mentioned I'd never used a DI framework, mainly because I hadn't felt the need to do so. In the comments, Matt Blodgett mentioned that he'd like to see a simple example using a framework, and I agreed.

So last night, that's exactly what I did. I picked Castle Windsor, since that seemed to be a popular one, recommended by Michael Eaton and first on Scott Hanselman's list of DI frameworks.

All in all, it took about 30 minutes to get my existing code base to use it, and that included the time it took me to read the documentation to figure out what I'm doing. I'm obviously not an expert, and there's more I would like to learn, but I did get a basic example working.

For reference, here's our User class that we've been working with:

   1:  public class User

   2:  {

   3:     private IServiceAPI _service;

   4:     public IServiceAPI Service

   5:     {

   6:        get { return _service;}

   7:     }

   8:   

   9:     private string _userName;

  10:     public string UserName

  11:     {

  12:        get { return _userName; }

  13:     }

  14:   

  15:     public User(string userName, IServiceAPI service)

  16:     {

  17:        _userName = userName;

  18:        _service = service;

  19:     }

  20:   

  21:     public void SendMessageTo(string message)

  22:     {

  23:        service.SendMessage(String.Format("@{0} - {1}", this.UserName, message));

  24:     }

  25:  }

I realized after I posted my original post that I never showed what code to use this class would look like, but if you're not using a framework, it might look something like this:

   1:  IServiceAPI service = new TwitterAPI();

   2:  User user = new User("RossCode", service);

That's not really that complicated because we're just using one service, but if you start to get a few different services, you can see how complicated this could get.

To use Windsor, your code to instantiate the User class looks like this:

   1:  IWindsorContainer container = new WindsorContainer(new XmlInterpreter(new ConfigResource("castle")));

   2:  IDictionary parameters = new HashTable();

   3:  parameters.Add("userName", "RossCode");

   4:  User user = container.Resolve<User>(paramters);

We use a dictionary to pass any non-injected parameters - our User class expects a username and an IServcieAPI implementation. We know the username, so we pass that in directly. We let the framework inject the IServiceAPI implementation.

There's actually more code to do it this way, but here's the key - this code doesn't change if I want to use a different IServiceAPI implementation. In the first example, I would have to add or change the code to get another IServiceAPI implementation. With the new way, the code doesn't change - Just the configuration. There's a decoupling advantage that I'll touch on later as well.

I did everything through configuration. It doesn't have to be, but that's how I did it. Let's take a look at the configuration file:

   1:  <configuration>

   2:    <configSections>

   3:      <section 

   4:        name="castle" 

   5:        type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor" 

   6:      />

   7:    </configSections>

   8:    <castle>

   9:      <components>

  10:        <component 

  11:          id="business.user" 

  12:     type="Business.User, Business" 

  13:        />

  14:        <component 

  15:          id="service.twitter" 

  16:     service="Interfaces.IServiceAPI, Interfaces" 

  17:     type="Twitter.TwitterAPI, Twitter" 

  18:        />

  19:      </components>

  20:    </castle>

  21:  </configuration>

The first just sets up Castle as a valid configuration section. The key parts are in the <castle> section. I'm only using components - there's a lot more I could do here, but I don't need anything more than this. I've registered two components. The first (line 10) is the type I want to inject into, and the second (line 14) is the type I want to inject with. So, Business.User is the class that I want Windsor to construct for me. It'll look for a constructor, which in this case, expects a username, which we supplied, and an IServiceAPI-supported type. The second component has a service attribute, saying that it can be used when you need to find an IServiceAPI type. Then it specifies the concrete type to use - Twitter.TwitterAPI. So when Windsor tries to construct the first component (Business.User), it'll end up resolving the IServiceAPI parameter to Twitter.TwitterAPI. All of this happens with nothing more than some configuration settings!

Now let's say we want to swap out TwitterAPI for our ConsoleAPI class. Before, we'd have to modify the code to create a ConsoleAPI instance and pass it in. Now we just change our configuration to add a new service and specify which service to use:

   1:    <castle>

   2:      <components>

   3:        <component 

   4:          id="business.user" 

   5:         type="Business.User, Business" 

   6:        >

   7:          <parameters>

   8:            <service>${service.console}</service>

   9:         </parameters>

  10:        </component>

  11:        <component 

  12:          id="service.twitter" 

  13:         service="Interfaces.IServiceAPI, Interfaces" 

  14:          type="Twitter.TwitterAPI, Twitter" 

  15:        />

  16:        <component 

  17:          id="service.console" 

  18:          service="Interfaces.IServiceAPI, Interfaces" 

  19:         type="Console.ConsoleAPI, Console" 

  20:        />

  21:      </components>

  22:    </castle>

I've added a second implementation for the IServiceAPI service, and specified which implementation using the <parameters> element. the <service> element is what to pass in as the service argument in the Business.User constructor. In this case, I specified to use Console.ConsoleAPI, which would be another service that implements IServiceAPI. I can easily switch between the TwitterAPI and ConsoleAPI just by changing one config setting - no need to recompile. And I can add new IServiceAPI implementations in the future, add them as components, set it as the one to use for Business.User, and I'm ready to go - no code changes.

That last point brings me to another advantage I see: Decoupling. Before, my client code was tightly coupled to the TwitterAPI implementation. My User class wasn't, but the client using it was. Doing dependency injection by hand removed some coupling, but it couldn't remove as much as using a framework did. In the above scenario, I have five assemblies - Business, Twitter, Console, Interfaces, and Client (the only one not listed, but it would be the client code containing the Windsor code). Client doesn't need to have a reference to Console or Twitter, but can still use the classes inside of them. The assemblies just need to be dropped into the same folder as the executable. And if I ever add a Jaiku assembly, that just needs to be dropped in and configured, and suddenly my code can use it - without compilation.

One other thing to note, and then I'll wrap it up. My User class was unchanged. Some frameworks use attributes to specify where to inject to, but that would require changes to the User class. Windsor doesn't (or at least doesn't have to - I'm still learning!), so I'm free to use the class with a framework or I can do the DI by hand.

Overall, I'm really impressed with Castle Windsor, and I think I can see it's usefulness. To be completely honest, the recompilation (or more specifically, not having to recompile) isn't that big of a deal to me - I rarely am in a situation where I want to add functionality but recompiling the software is out of the question. But breaking a(nother) dependency is always a good thing, and being able to use configuration over code seems like a Good Thing to me.

Bottom line: I think I'll be looking at this a bit for future projects.

In my last post about Dependency Injection, I sort of just threw in a comment about using the Adapter Pattern to address a mismatch between existing classes and interfaces that those classes need to support. I didn't provide a link or any real explanation. It was late when I wrote it, so I didn't really think about it. After reading through it again today, it struck me that I should probably explain it and provide an example of that as well.

Actually, this is all just a ploy to write about as many design patterns as possible to prove to someone (who shall remain un-named for now) that patterns are worth it and useful!

The basic idea of an adapter is to allow a class (or set of classes) support an interface without modifying the class or the interface. There's a a couple of reasons you'd need to do this:

1. Your set of classes all do the same type of thing (post to a micro-blogging service, for example), but with a different API, and you want to write code to treat them all the same.
2. You have existing code that expects a certain interface. Your new class doesn't support that interface and it's not feasible to change that (for example, it's a third party library).

That all sounds good, but examples cement the idea for me. Let's take a look at an existing class (following on my example from the DI post).

   1:  public Class TwitterAPI

   2:  {

   3:     public void SendTweet(string message)

   4:     {

   5:        // Send tweet implementation

   6:     }

   7:  }

Now, let's look at the code that we want to use this. This code already is using DI and expects a class that supports the IServiceAPI interface.

   1:  public class User

   2:  {

   3:     private IServiceAPI _service;

   4:     public IServiceAPI Service

   5:     {

   6:        get { return _service;}

   7:     }

   8:   

   9:     private string _userName;

  10:     public string UserName

  11:     {

  12:        get { return _userName; }

  13:     }

  14:   

  15:     public User(string userName, IServiceAPI service)

  16:     {

  17:        _userName = userName;

  18:        _service = service;

  19:     }

  20:   

  21:     public void SendMessageTo(string message)

  22:     {

  23:        service.SendMessage(String.Format("@{0} - {1}", this.UserName, message));

  24:     }

  25:  }

Now, TwitterAPI doesn't support the IServiceAPI interface, so to make these two classes work together, we have a choice. We can modify the TwitterAPI class directly to support the IServiceAPI interface. But what if the TwitterAPI is a third party library or it's already in use in other places? Well, that's where the Adapter pattern comes in. We can wrap the TwitterAPI class with an adapter so it can be used in the User class. It'll look like this:

   1:  public class TwitterAPIAdapter : IServiceAPI

   2:  {

   3:     private TwitterAPI _twitter;

   4:     public TwitterAPI Twitter

   5:     {

   6:        get { return _twitter; }

   7:     }

   8:   

   9:     public TwitterAPIAdapter(TwitterAPI twitter)

  10:     {

  11:        _twitter = twitter;

  12:     }

  13:   

  14:     public void SendMessage(string message)

  15:     {

  16:        twitter.SendTweet(message);

  17:     }

  18:  }

Now we can pass in a TwitterAPIAdapter instance into User, and post to Twitter. The advantage of doing this is especially important for existing code bases. This allows these two disconnected pieces (User and TwitterAPI) to talk to each other but without modifying either class, meaning getting them to talk is less impactful to the overall system because neither original classes were changed.

This example is a simple one. But it does show the concept - to overcome the mismatch between the two classes and allow them to work together. In more complex situations, that may include pulling in information from other sources, pushing data to multiple locations, etc.

The adapter pattern is also a good way to encapsulate the functionality of a volatile piece of a system. For example, we have had issues with our HTML editor we use on Tourneytopia, and as a result, have changed it out a few times. The first time we did, it was painful because it's used in a few different places. The second time we changed it, it was easy because the first time, we created an adapter that sat between our application and the third party editor. Now we can swap editors out by just changing the internals of the adapter and our application never has to change.

Tonight, I was thinking about a side project I've been working on, and I realized that I had used Dependency Injection (DI). I'm pretty sure that DI is my favorite pattern, so I decided to share on twitter. Steve Wright responded:

I wonder what all the DI hubbub is about, do I even need it?  I keep asking, and I think it's time to figure it out

Seeing that, I figured I'd share how I used DI and what it accomplished for me. I'm sure Steve knows what DI is, but inspiration has to come from somewhere, right?

First, a little set up. I wrote some code that interacts with the Twitter API to send and receive messages. Without DI, it looked something like this:

   1:  public class User

   2:  {

   3:     private string _userName;

   4:     public string UserName

   5:     {

   6:        get { return _userName; }

   7:     }

   8:   

   9:     public User(string userName)

  10:     {

  11:        _userName = userName;

  12:     }

  13:   

  14:     public void SendMessageTo(string message)

  15:     {

  16:        TwitterAPI twitter = new TwitterAPI();

  17:        twitter.SendTweet(String.Format("@{0} - {1}", this.UserName, message));

  18:     }

  19:  }

This doesn't seem too bad at first glance. Yes, you could probably modify this a bit to make the TwitterAPI variable a class level variable and that would be a little better - you wouldn't have to instantiate it every time you wanted to send a message. But there's still a problem. What if you wanted to test this without spamming twitter? Or instead of twitter, you wanted to send messages to Pownce or Jaiku? Or your blog? How would you do that?

The issue is that the code above has a dependency on the TwitterAPI class, so you're pretty much stuck. What I've seen done (which makes me cringe) is to add switch statements where each case contains code to post to a different service. What happens when a new service comes out? Or you want to post to two services? You're stuck in a maintenance nightmare because this class has to change every time a new service comes out.

Luckily, dependency injection solves this problem. Instead of the User class having a dependency on TwitterAPI (or PownceAPI, JaikuAPI, etc.), it only depends on an interface, and the concrete implementation of that interface is injected into the class. In this case, the interface is pretty simple:

   1:  public interface IServiceAPI

   2:  {

   3:     void SendMessage(string message);

   4:  }

Then we can change our User class to use the interface, and have it injected into the instance through the constructor:

   1:  public class User

   2:  {

   3:     private IServiceAPI _service;

   4:     public IServiceAPI Service

   5:     {

   6:        get { return _service;}

   7:     }

   8:   

   9:     private string _userName;

  10:     public string UserName

  11:     {

  12:        get { return _userName; }

  13:     }

  14:   

  15:     public User(string userName, IServiceAPI service)

  16:     {

  17:        _userName = userName;

  18:        _service = service;

  19:     }

  20:   

  21:     public void SendMessageTo(string message)

  22:     {

  23:        service.SendMessage(String.Format("@{0} - {1}", this.UserName, message));

  24:     }

  25:  }

This effectively makes our User class service agnostic. I can now implement the IServiceAPI for Twitter, Jaiku, Pownce, an IM client, the console window - or any combination of those. Note that I changed the method name in the service from SendTweet to SendMessage. If you don't have control over your service implementations, then you can use the Adapter pattern to make that work.

The best part about using DI is that this User class can work with services that haven't even been thought of. As long as the service supports the IServiceAPI class (or an adapter can be written to simulate that support), then this class is already prepared to work with it.

I used this model so I could have all of the output to a console window instead of actually posting it, and I controlled which IServiceAPI instance to pass in via a config setting. In the actual implementation, I had a get method as well. The real one (against twitter) did XML requests, while my test one grabbed input from the console window. It made testing it very easy, and didn't require a lot of extra coding - especially using CodeRush to do some of the dirty work, like extracting interfaces, adding parameters to methods, etc.

I haven't used any formal DI frameworks, but that's mainly because I haven't come across a situation yet where I couldn't just code it up by hand. I've seen one in action, so I know they have their place, but I just haven't felt compelled to use one. Still, even with hand coding, Dependency Injection can really help write code that is flexible and resilient to changes in the future.

Back in November, Jeff Atwood put together a post about the two types of developers: The 80% and the 20%. The 80% are the 9-5 type developers - they may be great at what they do, but they don't have an overwhelming passion for it - it's a job, and nothing more. Once they leave the confines of their office, they don't think about writing software until they return to the office the next morning.

The 20% are the people who are passionate about software development and are constantly looking for ways to better themselves. They read blogs. They speak at user groups and code camps. They're active in the community and are constantly pushing themselves to learn new things and find better ways to do what they're already doing.

In reality, it's probably more like 95% / 5%, but the definition of the groups remain the same. The real question isn't what group you're in - if you're reading this, you're most likely in the 20%, The real question is at what point do you (or did you) transition from the 80% to the 20%?

I know it's possible. I did it. I used to come to work at 8 and leave at 6 - not quite 9 to 5, but the bottom line was the same - when I left the office, I didn't think about work until I came in the next day. Nor did I think about software development. I learned what I had to learn to do my job, but nothing more. I was putting in my time and taking home a paycheck. I was good at what I did, but I didn't really do anything to push myself.

I don't remember exactly when it happened, but it did. I started finding blogs when I did searches. I started to wonder what this whole blogging thing was bout, and I felt like I needed one. So I started one, and I started following a few blogs. The key to switching from the 80% to the 20% was when "following a blog" went from a bookmark in IE to a subscription in Newsgator.

Eventually, I started doing other "20%-ish" things. I was writing software for fun. I started a side business specifically to fill in some of the gaps in my experience. I started speaking (although infrequently) publicly at .NET user groups. I used the best tools for my projects regardless of what the Microsoft corporate line is. I still feel like I'm barely in the 20%, but I'm there. I made the transition.

One of the questions that keeps popping up is, "How do we reach the 80% and teach them the best practices and the best software to use?" What we should be asking is, "How do we get more of the 80% into the 20% so they have the knowledge to learn that for themselves?"

Think about college. How much of what you learned in college applies to what you do right now? For me, it's next to none (of course, I wasn't in any of Professor Elder's classes!). So does that mean I don't think college is worthwhile? Absolutely not. Going to college was great for me. Not because of what I was learning, but because of the process I used to learn it. College taught me how to learn, which is more important to me than what I learned.

The 20% would be doing the community a disservice if at the end of the day, the best they did was teach other developers the best practices for software development today. How many people thing NUnit will be the unit testing framework of choice in five years? Some would say MbUnit has already usurped NUnit. The 20% would be much better off to show them the process to learn that for themselves.

I don't see a lot of discussion about people moving from one group to the other. But remember, some of the developers in the 80% are very smart. While some are content with where they're at, there is a good percentage that just haven't been exposed to the community and aren't even aware there are other options out there. Once they're aware, they may jump in with both feet and have lots to offer, and in the end, we'll all benefit.

I don't have the answers as to how to affect that transition process. I won't pretend to. But I know that the focus on Us vs. Them is the wrong approach. We need to start thinking about how we as a community can grow that community as a whole, and push that 20% to actually be 20% or even more.

I wrote this post last night. For the first time since I started writing here, I considered not posting it. Yes, I've thrown away posts before, but those were because they no longer applied. I think this one still applies, but I struggled with posting it. Obviously, I decided to go ahead. Also, just because I feel like I should disclose where this is coming from, there is a post by Dan Hounshell that prompted me to write about some of these thoughts. His post is worth a read, as are the comments.

For the first time, I'm actually going to step back and enjoy myself during the March Madness tournament this year, and host my own pool. I'm inviting readers of my blog (that's you!) and the people I know on Twitter. And anyone else I can think to invite.

There's no prize - just the pride of knowing that you picked the teams better than any of the other geeks! Of course, after you enter my pool, you'll be shown the option to add your pick to the main pool - where there is a prize - a $50 Best Buy gift card.

Oh yeah. If you're reading this and thinking, "There's no point in me entering. I don't know anything about basketball." - it doesn't matter. I've heard countless stories of people who won a pool by picking teams by uniform colors! So don't let that hold you back. Submit your picks now!

As part of our recent transition from Tourney Logic to Develomatic, LLC, we've learned a few things about how to set up businesses. Some of them are worth sharing!

To start with, let me state that I'm not a lawyer, so if you're in this situation and wondering if this is the right solution for you, I claim no responsibility if you lose your house. Check with your own lawyers first. And remember, I'm in Michigan, so states may vary as well. And it's always possible I'm completely off my rocker to begin with!

Anyway, we recently learned the best way to organize our different entities. We have four major properties that we maintain - Tourney Logic, Tourneytopia, myPlayoffs.com, and Pay It Square. And I guess you could add Develomatic, LLC onto that as well, making five. While some relate, we track each separately and if the opportunity afforded itself, could sell them separately.

There's another side to this as well. In the event that something bad happened, we want the losses to stop at that entity. That is, if one of our entities got sued, we don't want that to have a negative impact on the other entities. Since we track them all independently, we know what kind of revenue or losses each one has.

So how can we accomplish that? Well, each entity is a separate LLC. So for our five entities, we have five LLCs. The LLC is a legal entity and will hold up in court to limit its liability to what it's made, so the losses wouldn't filter up to the rest of the entities and completely wipe them out.

Now, having heard this, my first reaction was "This is a ploy for the accountants get more money!" Five entities means five tax returns right? Well, as it turns out, no. The odd thing about LLCs is that they aren't technically recognized by the federal government - or at least not the IRS. No, to the IRS, the only thing that matters to them is if you have an EIN. If you have an EIN, you file a return. No EIN? No return. Now, that doesn't mean if you make money for an LLC that doesn't have an EIN, it's tax free. You still need at least one EIN. But for us, we can get an EIN for the "holding" LLC (Develomatic) and file a return under one EIN with all of the combined revenue of the separate entities.

Bottom line: Legal protection for each entity, but the tax simplicity of just one entity.

For a long time now, there's been talk inside of NuSoft Solutions (where I work) about bringing designers onboard. We use design services from a few local design firms on a good share of the public facing web applications we've developed, and we always thought it would be a good idea.

Well, late last year, we started doing just that. We also formed a new group within NuSoft called Kinetic IG (Yup - Silverlight - unless you don't have it installed, then it's flash), and that was publicly announced a couple of weeks ago at a nice event at Eve in The B.O.B. So far, things have been going a lot quicker than I thought they would - we're looking to add six designers in the near future.  We're getting a lot of interest in our services, as well as a bit of press coverage. By the way, one of the projects mentioned in those articles is one I'm still working on.

To be honest, I'm really excited about this change. From a day to day basis, it's not much different, but being able to work closely with designers is great. I'm looking forward to building a working relationship that can be much tighter than we get with outside firms. It'll be interesting to see where things go over the next year.