Boodhoo Voodoo

Last week I had the absolutely pleasure of attending JP Boodhoo’s Develop With Passion Bootcamp at my company’s office in Regina.

The title of the course has recently changed from Nothing But .NET because it was misleading, and JP stated so several times during the week.  While we learned a lot about .NET, design patterns and test-driven development, the real goal of the course is to teach developers the skills for learning on their own and opening their minds to alternative programming methods.  So many developers rarely look outside of their own little circle of development for new ideas.  It’s comfortable in their circles and looking elsewhere is something foreign to them.  JP teaches the skills required to make those leaps outside of your comfort zone and be able to continually expand the boundaries of your skillset.

For some courses it is viable to send one person and have him bring back his learnings to the team.  This is not one of those course.  It has to be experienced first-hand.  JP is extremely passionate about development and that passion is infectious.  His ability to inspire developers and make people want to become better programmers is second to none.  The course is carefully designed to guide each developer through a personal journey that cannot be replicated by someone else.  JP has a special talent for inspiring people to strive to be better developers, and coupled with his ability to teach the skills to continue learning is a unique combination that has to be experienced in person.

This is definitely a course where you get out of it what you put into it.  JP really challenges you and forces you outside of your comfort zone.  I can say with certainty that every single person in attendance was quickly forced out of the comfort zone that they were used to being in when coding.  What happened next was up to the individual.  Those who chose to embrace that awkward feeling and challenged themselves to learn something new got full value out of the course.  They learned a lot about patterns and different coding techniques and, more importantly, learned the skills required to keep the momentum of learning going.  They not only became better developers in that week, they have set themselves up for continuing that rapid growth for a long time to come.  However, those who chose to fight the discomfort and actively tried to get back into their developer rut, likely didn’t learn much and won’t have a very positive reflection on the course.

I highly recommend this course for developers of all levels.  There is nothing more valuable in a developer than an active engagement and desire to continually improve their skills.  I have been involved in the developer community for over 10 years and I know several other people who have taken this course.  They couldn’t say enough good things about it and used the skills they learned to launch their careers to new heights.  Having now taken the course myself, I can honestly say that this course is a great way to propel your skills to the next level.

The Report of ALT.NET’s Death Was an Exaggeration

I spent last weekend in Redmond at ALT.NET Seattle 2011 and it was an amazing experience.  This is the 3rd ALT.NET conference that I’ve attended and they’ve all been unique experiences.

A New Breed

There were very few of the original ALT.NET leaders at the conference, but it was awesome to see so many new people picking up the torch.  There was a significant change in the atmosphere from previous ALT.NET conferences too.  The theme of the conference was “practice don’t preach” and it was reflected in the attendees and conversations.  I had so many great conversations with people based on their experiences and practices that they actually use.

James Shore gave an excellent keynote speech about cargo cults and how it’s important to understand the substance of an idea.  This concept was solidified for me in a session about CQRS, which many believe is a cargo cult, but it was the most pragmatic conversation about CQRS that I’ve ever had.  There was as much talk about when not to use it as there was about its benefits.  All of the proponents of CQRS warned about the pitfalls and downside to it and provided a lot of experience based expertise.  I didn’t hear a lot of talks with this kind of tone at previous ALT.NET conferences and it really struck me how the community has evolved.

Not Satisfied

One of the most thought provoking sessions happened near the end of the second day where a great discussion about learning occurred.  If this conversation would have occurred at the first ALT.NET conference that I attended, it would have focused on TDD, Agile and pair programming.  This time around those topics are accepted and we talked about pushing those techniques even further and incorporating organization learning techniques.  It’s great to see how those early topics have been accepted and new ideas can be discussed to raise the bar even higher.

I had so many conversations with people who didn’t care about buzzwords and rhetoric and just wanted to find better ways to develop software.  It wasn’t about who the big names were, just about sharing ideas.

ALT.NET Lives On

ALT.NET isn’t dead, not by a long shot.  Just because most of the original ALT.NET leaders have moved on, a new generation of ALT.NETers have picked up the torch and are running with it.  It may not be as in-your-face as it used to be, but those involved in the community are still pushing the .NET community as a whole forward.  The ALT.NET community has evolved and it continues to provide a huge amount of value to the .NET community as a whole.  It was a fantastic experience and I can’t wait to apply all of the new things that I learned.

Software Developer Résumé Tips

I’m currently in a situation where I’m part of a hiring team for two different companies.  I’ve been up to my eyeballs in developers’ résumés and I have to say that I’ve been less than impressed.  The problem is that very few developers put anything in their résumé that distinguishes themselves from others.  For the most part I’ve seen long lists of tools and technologies used, lists of places the applicant has worked along with more lists of tools and technologies they’ve used, and a short list of their education.  None of this makes the applicant stand out as a developer.

Here are some tips that will help your résumé stand out and will get you to the next stage in the hiring process.

Passion

Tell me that you actually like doing what you do.  Tell me about the books that you’ve read, the user groups you attend, the blogs that you read and the podcasts you listen to.  It’s even better is you can link to your own blog and the open source projects you work on.  Tell me why these things are important to you and how they help make you a better developer.  I need to know that you’re not just coasting through your career and that you’re constantly trying to improve your skill set.  I guarantee you that the job you’re applying for is not exactly the same as the one you have and I need to know that you will be able to adapt and thrive in a new environment.  I want to know that you bring fresh ideas to the team and will help the team take advantage of changing technologies.

Champion Change

Tell me about how you’ve driven change in your development team to make it more productive, raised the quality of the code or reduced the bug count.  Tell me about a pain that your team had and what you did to fix it.  I want to know that you care about your team and that you care about the products your team produces.  I need to know that you will be an asset to the team and will take action when you see a need.

Stand Out

Remember that you’re certainly not the only qualified candidate applying for the position and you must make your résumé stand out.  Think about what’s on your résumé and how unique it makes you look.  Ask yourself if it highlights what makes you the best candidate for the position.

Work Experience

Yes, work experience is important.  The problem is that I’m learning way more about the companies you’ve worked for than I’m learning about you!  Don’t just give me your company’s elevator pitch, your job description and a list of tools.  Tell me about a valuable skill that you learned.  Tell me something outstanding that you did to make the project succeed.  Tell me how this experience has made you a better developer and how you will be able to apply those skills at your new job.

Think about what makes you stand out as a developer and ask yourself if that is reflected in your résumé.  Make sure that your strongest assets are highlighted and will stand out to the person reading it.  If you follow this advice you will have a much greater chance of moving to the next stage in the hiring process.

ADO.NET Query Causes SQL Server to Ignore Primary Key Index

*Disclaimer* I am not a DBA. I'm just a poor, humble developer. I just happened to be the guy standing closest to the server when the DBA quit.¹

The Story

I came across a performance bottleneck today that had me stumped for a while.  A query to the database, for a single record, by the primary key, was taking 3 seconds.  Let me say that again, by the primary key, for a single record, taking 3 seconds.  How could this possibly be?  I pulled the query out into Management Studio and ran the query again after turning on the option to display the actual query plan. (Query –> Include Actual Execution Plan)  I was quite surprised when the query plan was not using the primary key index at all.  To make a long story short, SQL Server didn’t use the primary key index because the generated query supplied the parameters as NVarChar while the actual columns were VarChars.

The Cause

The query was generated by an open source tool, so I was able to dig in to find out how it crafted the query.  Basically it came down to this code:

IDbDataParameter parameter = command.CreateParameter();
parameter.ParameterName = paramPrefix + name;
parameter.Value = val ?? DBNull.Value;
command.Parameters.Add(parameter);

This is pretty standard code for ADO.NET but the key isn’t in what’s there, it’s in what is not there.  The parameter’s type is not specific which causes the .NET framework to use it’s own mapping of .NET type to SQL Server type.  The value that was being passed into this piece of code was a string and automatically got mapped as an NVarChar, or System.Data.DbType.String.

The Solution

To get around this default I needed to use my own mapping to use the non-unicode string type.

parameter.DbType = DbType.AnsiString;

With this additional line of code, this query executed infinitely faster; I’m not kidding.  It went from taking around 3 seconds and now consistently measures at 0 milliseconds.  How often can you claim an infinite performance optimization in your system?

¹ This story is not true. It's a lie, made up.  There’s has never been a DBA here, and if there had been, I would not have set foot anywhere near the server just to avoid such a situation.  However, in many cases I am the Accidental DBA and I find myself struggling through problems just like this one.

Messing around with C# dynamic

At last night’s ALT.NET Vancouver meet up we were talking about the dynamic keyword in C# 4.0 and how it could be used for dispatching a message to the appropriate message handler.  The conversation with a look at Chris Nicola’s blog post on the topic.

The first test that he shows in the post fails. 

[Test]
public void cant_pass_base_class_to_function_dynamically()
{
    dynamic handler = new FooMessageHandler();
    IMessage message = new FooMessage();
    handler.Handle(message);
}

To me, this was expected.  Despite using the dynamic keyword for the message handler, the C# compiler is still going to use the same algorithm for method matching as it does on a static object.  To make this method pass we need to add our own method matching, and in C# dynamic, that means overriding the TryInvokeMember method.

public override bool TryInvokeMember(InvokeMemberBinder binder, object[] args, out object result)
{
    result = null;

    if (binder.Name == "Handle" && args.Length == 1 && args[0].GetType() == typeof(FooMessage))
    {
        Handle((FooMessage) args[0]);
        return true;
    }

    return false;
}

This code looks to see if the Handle method was being called and then checks if the argument passed in will satisfy the real method then calls then method. It's not the cleanest code, but the test does pass with this override. We can take it a little further and move the method to the base class so that we don't have to repeat the override for each message handler.

public override bool TryInvokeMember(InvokeMemberBinder binder, object[] args, out object result)
{
    result = null;

    if (binder.Name == "Handle" && args.Length == 1 && args[0].GetType() == typeof(T))
    {
        Handle((T)args[0]);
        return true;
    }

    return false;
}

One of the conclusions that we reached at the meet up was that dynamic is well suited to where reflection would have been used.  I have done message dispatching with reflection in the past and I think I like this approach better once I clean up the code a little more.

P.S. Also check out Cliff Hammerschmidt’s post on Graft-on Visitor in C#.

Inversion of Control: It’s All About Decoupling

I've been using Dependency Injection and Inversion of Control for a few years now and have always wondered why there is such resistance to the concept. I've heard the argument that it seems too complex and on a not-so-recent Dot Net Rocks episode, Richard Campbell was concerned that it would make debugging more difficult. To me, Dependency Injection and Inversion of Control are just fancy words for a technique designed to reduce the coupling in your system.

Coupling is one of those terms that everyone knows, but few pay much attention to on a daily basis. I can remember an exam I wrote for a second year Computer Science course that had the following multiple choice question on it:

Object-oriented code should exhibit these characteristics:

a) High coupling, high cohesion
b) Low coupling, high cohesion
c) High coupling, low cohesion
d) Low coupling, low cohesion

I knew the answer right away, but thinking back on it, I couldn't have gone into much more detail about what those terms actually meant, or more importantly, how to apply the principles to code. I’ve found that coupling and cohesion are concepts that most people take a long time to apply at anything more than an elementary level.

At one place where I used to work, the development team completed 360 degree evaluations of the each other. One of the characteristics that we evaluated each other on was that we wrote “quality object-oriented code that displayed a low level of coupling and a high level of cohesion.” Vague I know, but what was most interesting about it was that the developers who wrote the poorest code in this regard scored themselves the highest, and the developers who wrote the best code, scored themselves the lowest. I interpreted this to mean that the developers who fully understood what it meant to write loosely coupled code were able to remove much of the coupling from their code, but were also keenly aware of the coupling that they left behind.

The argument that IoC makes debugging more difficult doesn’t hold any weight to me.  The argument is that you don’t know exactly which implementation is being called when a method is called because the call is to an interface or an abstract class and not a concrete dependency.  Now listen up people, cause I’m going to let you in on a little secret, THAT’S CALLED LOW COUPLING!  You’re only coupled to the interface, not the implementation, that’s what object orientation is all about!

So the next time someone tries to argue against IoC because it’s too complicated, just remind them about the foundations of object-oriented programming.

Agile Vancouver 2010 Tutorial Materials

As promised, here are the materials from the Domain Patterns Big & Small tutorial.  Chris has posted his material on his blog.

Domain Patterns Big and Small.pptx

Samples (Before).zip

Samples (After).zip