Kids pictures

I don't post persona stuff too often so forgive me on this one.  But we just got my kids school pictures done.  (that and I interested to see how Windows Live Writer hands pictures).

Best Practices Discussions and Debates

I think I have learned something today that I was previously unaware.

Starting a discussion about software development best practices is akin to talking about parenting techniques with a group of mothers.  Most will patiently listen, but at least one will get super defensive and tell you in detail about why that wouldn't work with their baby.

I have relatives who are also very argumentative, in that they just love to argue.  The funny part is that they will argue about things THEY AGREE WITH!  Unfortunately, they are too bent on arguing that they don't care that they agree.

I see this happen on blogs all the time.  And while I think that blogs are great ways to spur discussion, they are not great ways to HAVE a discussion.  User groups, phone calls, and hallways are all vastly superior environments for a discussion.

In my case, I have a commenter on my blog post about best practices that is doing a wonderful job of arguing some of my points, all while telling me I'm wrong.  We disagree on one point: Developers should have their own copy of the database they are developing against, and developers should have access to all source code and software need to do their job.

I think the reason the anonymous poster and I are not able to agree is because we really aren't able to talk to each other about the ideas.  Plus, I have a strong feeling we are separated by a common language (we have different definitions of the same words).    More than likely we agree on the software, we just don't agree on the terminology.

As far as the database part: there are a ton of ideas hidden in that statement that are not easily expressed.  There are scripts that extract the meta-data out of a database, source control that houses that script, continuous integration for verifying all of the changes work to both code and database scripts, creation of development data, etc.  

Then the kicker: 90% of that is automated.  I really don't thing the anonymous submitter saw that point.  In fact that should be a blog post in itself.  He/she saw it as another backbreaking task the developer would have to maintain by hand.  But if you do it right, it isn't.  Updating the database scripts is as simple as running a batch file.   And not updating the batch file and then running it, no -- just run it.  The batch file creates the scripts for creating the entire database.  This should take 5-30 seconds.  Then you are ready to go.

As I said, there are a lot of aspect to this that were not mentioned in this post or the previous post.  But blogs are there to START discussions, not to have them.

Elegant Code expands

I'm hoping this is the start of a new vibrant community, as is it is comprised of some of the best and brightest that I know anyway.

ElegantCode.com is expanding beyond a one man blog. Now included is a group of managers, Scrum Lords, coding architects, non-coding architects (the most dangerous type of architect), and top notch developers.

I'm excited to see if this takes off.

Rob Conery (SubSonic) is joining Microsoft

This is great news, Rob Conery has been hired by Microsoft.

Even better news: Microsoft hired him to work on SubSonic. 

Better news still: SubSonic is staying open source.

I'm trying to find a negative here...and failing at it.

Cheers.

Rhino Mocks 3.3 Released

Straight from Ayende, Rhino Mocks 3.3 has been released.  The peasants rejoiced.  Well, I rejoiced anyway.

New features:

• Adding support for calling void methods using Expect.Call
• Adding remoting proxies.
• Made IMethodOptions generic. Allows compile time type safety on Return. 
• Adding a PublicFieldConstraint

The biggest change for the day to day developer: you can now use Expect.Call on methods that return void.  This wasn't a big problem per-say, but it did cause a lot of confusion.  You would see code mocking a function call like this:

Expect.Call(mockObject.MyFunction()).Return(1);

Then your method returning void would look like this:

mockObject.MyMethod();

Not the most consistent API.  Now that should be fixed.  So mocking a method will now look like this:

Expect.Call(mockObject.MyMethod());

Ayende's post

Download here

Rhino mocks is on my list of source code to read as soon as I'm finished going through SubSonic.

Have you thanked Ayende today?

Software Development Essential Practices

I was in an interesting discussion last night: what software development practices do you consider essential? 

While opinions varied, I think there was some consensus on a few items.  In my list I also include some tools.  Some of these were mentioned by the group, but consider them my own additions.  Also, I am making this list specific to .NET, but the list applies to just about every language.

Universally agreed Practices

• Source Control (1)
• Subversion
• VSTS ($)
• Vault ($)
• Local Development -- Every developer should have everything on their computer to run the system.  This includes all of the software and all of the source code.
• Bug Tracking - nuf said.  There are to many tools available to list here.
• TDD - Test Driven Development.  There was a little bit of back and forth, but the general consensus was that this should be done.
• NUnit
• MBUnit
• Rhino Mocks (2)
• TypeMock ($) (2)
• NMock (2)
• ORM - Object-Relational Mapping
• NHibernate 
• SubSonic - My person favorite
• LINQ to SQL - not yet, but I feel this should be on the list.
• LLBLGen ($) - Not free, but I've heard many good things about it.
• More
• Continuous Integration - Simple process that sits on a server and waits for things to get checked into your source control system.  When it sees something new, it gets all of the latest source code, compiles it, and runs all of the unit tests.  If there are any problems anywhere in that process it alerts the users (email, desktop icon, wave red flag, etc). (3)
• CI Factory
• CruiseControl.Net
• One Step Build - it is unbelievably cool to be able to click one button and have your entire project compile, run all tests, and possibly create an install in one step.  Personally, I do like it, but with the current set of tools this is one of the hardest parts to setup.
• MSBuild
• Nant
• BooBS/Bake (Ayende please, please, please change the name to Bake.  As cool as a project named BooBs could be -- I don't want to start an HR nightmare)
• FinalBuilder ($)
• Visual Build Pro ($)

Highly thought of but non-essential practices

• IOC - Inversion of Control - Everyone seemed to agree it was a good idea...but not actually essential.
• Castle Windsor - DotNetSlackers has a nice series on using this.
• Spring.Net
• StructureMap
• ReSharper ($) - Not a best practice per say, but it sure does make life easier. (4)

I'm sure I have missed some tools in the list, but it is the practices that are more important anyway.  But if you put a comment about any tool that I missed I will add it to the list.

(1) Source Safe was notably not in the list.  While I don't like it either, it is better than nothing.  But if your team is greater than 5 people or you have multiple people working on the same project you really should look at one of the other products on the list.

(2) Not a unit testing library, but a Mock Object library.  Pick a unit testing libarary (NUnit, MBUnit, XUnit), then pick a mock object library (Rhino Mocks, TypeMock, NMock) to use with it.

(3) I really need to talk about continuous integration more.  But it is one of those things that leads you down a path.  First you add source control, then you start adhering to separation of concerns, then you start unit testing and mocking more, then you add continuous integration, and then one step builds are all part of the mix.  One best practice leads to another, but they don't make a bit of sense without some of the prior pieces.

(4) If you are a Code Rush person instead of a ReSharper person -- carry on, you are in good company.

($) The cost money - not just beer, but may have free version versions as well.

Testing for Exceptions with NUnit

I came across a testing situation where I had to:
a. Make sure an exception was thrown
b. After it was thrown, make sure nothing else happened.

This is what happens when you throw exceptions from SQL Stored Procedures.

The Problem

The standard way of checking for exceptions in NUnit are thus:
1. ExpectedException attribute on the test method
2. Have your own try/catch block in your test method.

The problem with option 1 is that no assertions can be checked after the exception. The code runs until the exception is thrown, then you are done. That isn't what I need.

The problem with option 2 is that it is ugly. Yes, I'm being a cry baby here. I think the try catch throws more code in the test than I think should be there.

My Solution

So I created a new method called ExpectException. Here is the code:

   1:  public T ExpectException<T>(MyMethod method) where T : Exception

   2:  {

   3:      try

   4:      {

   5:          method.Invoke();

   6:      }

   7:      catch(T e)

   8:      {

   9:          return e;

  10:      }

  11:      return null;

  12:  }

So now in my case, I have a stored procedure that throws an SqlException. I want to call the method and return the exception so I can check the exception for specific values (make sure the message is correct). Also, if any other exception is thrown, say a Exception -- not a SqlException, the test will fail.

Here is my new code:

   1:  SqlException e = ExpectException<SqlException>(delegate { ReplaceUnitCall(oldUnit, newUnit); });

   2:  Assert.IsNotNull(e);

So as long as you are familiar with anonymous delegates, this is a pretty nice solution -- to me.

Current favorite ReSharper shortcuts

I've been experimenting with ReSharper shortcuts again. Here are my new favorites.

Ctrl-- (control-minus): return cursor to previous position.
This is especially useful if you just had ReSharper create a field or do any number of other items that will automatically jump the cursor to some other place -- be it in the current class, or another file. Very useful. I seem to use this most when I'm creating properties.

Ctrl-Alt-V: Introduce Variable.
If I type:
System.IO.File.ReadAllLines(filename);

Then hit the Ctrl-Alt-V, it will create a variable for the return of the function. So you will end up with this:
string[] lines = System.IO.File.ReadAllLines(filename);

Ctrl-Shift-N: Find file by name
I'm used to using Ctrl-N, find type by name. But usually what I was looking for was find file by name. If your classes have the same names as your files, not a big difference, but there is a difference.

What I'm hoping for in the next version of ReSharper
Enhanced Interface support. If my class has an interface, I want to be able to right-click on a method that is not in the interface, and have ReSharper automatically add the method to the interface.

Update:
From my comments I see that this feature already exists, it just has an odd name and no short-cut. The feature is "Push member up".

So put your cursor on a method/property, right-click->Refactor->Push Member Up and you will get a dialog for adding the member to an interface.

The name is the odd part, but if you do think about all the implications, it does make sense. Anyway, the more you know... Thank you Ilya Ryzhenkov

MSDN Presentation and the Demo Gods

Everyone who has ever done a presentation in front of a large group of people, with a computer and powerpoint, will have some crack about appeasing the demo gods.

Yesterday I gave a presentation on LINQ for the MSDN Event here in Boise, and apparently I pissed the demo gods off something fierce.

I get up on stage, hook up my laptop, start everything up (powerpoint and VPC) plug in the projector's cable, and...
I hear a lot of beeping. I open Windows explorer and suddenly all of my icons start expanding to enormous proportions. My PowerPoint presentation will not move past the first slide.

I reboot. Restart PowerPoint and VPC. I hear beeping again. I'm supposed to have started 5 minutes ago. Not good.

I start talking anyway. LINQ has a lot to cover. Philosophy, data access, xml, objects, language enhancements, etc.

It is as I start talking, sans PowerPoint, that suddenly the crowd goes: "Ohhh", with a couple of faint "Doh!"s in the mix. My laptop had just Blue Screened.

The demo gods were not happy with me.

So, reboot again, and keep talking about LINQ. Needless to say I was a bit flustered this time, but I kept moving (I had a time limit). Luckily, my laptop booted just fine this time, everything loaded, I was able to breeze through a bunch of slides and get the VPC started and start the actual demo.

After that everything went mostly well. I covered all of my demos, and they all worked. I also knew which of my demos would take a long time to run, and used that time to ask the audience for questions -- and they had a lot. The biggest question to come up, repeatedly, had to do with the misconception that LINQ was only about database access. It isn't, LINQ is about data manipulation with ALL of your data.

The only thing I missed: each of my demos had two parts. Showing how things are probably being coded now, and then showing how they are done with LINQ. I skipped the first part, trusting the audience to believe me that they worked. I don't think that was a bad thing. They came to see new stuff, not old.

Anyway, I'll have to figure out what I need to sacrifice for the demo gods before I give another presentation.

And if anyone managed to get a picture of my blue screen, I would love to have a copy of it.

Start everything back up.