After much trial and error I finally gave up and asked Ayende what he uses to post to his blog.  His posts are always nicely formatted - including code snippets in Google Reader

It's that code snippet part that I have problems with, so I'm going to give the Syntax Highlighter for WLW that Ayende uses a shot.  If it works for him, it should work for me. Lets give it another shot shall we?

[TestFixture]
public class UnitOfWorkTests
{
    [Test]
    public void Should_return_same_instance()
    {
        var c = new Customer { Address = new Address(), CustomerID = 1, Name = "Sneal" };

        UnitOfWork uow = new UnitOfWork(new StubDataStore());
        uow.Save(c);

        Assert.AreSame(c, uow.Single(new Customer { CustomerID = 1 }));
    }

    [Test]
    public void Can_save_instance()
    {
        var c = new Customer { Address = new Address(), CustomerID = 1, Name = "Sneal" };

        UnitOfWork uow = new UnitOfWork(new StubDataStore());
        uow.Save(c);       
    }
}

Well that was nice, and boy does this thing support a lot of programming languages (way more than I know).

I've been using Windows Live Writer for a while now and would never go back to directly posting via a webform, WLW is just too easy.

I brought the topic of code comments up the other day at lunch to get some other's opinions about method level and class level comments, more specifically C# XML comments.  I brought the subject up because we have a policy at work to comment all methods, public and private, which I'm a bit dubious about.

It was interesting to see how widely opinions varied on the subject, from everything should be commented to produce nice CHM files to my position that comments are a last resort to explain the code to the next developer.

The best code needs no commenting at all.

public string ConcatStrings(string lhs, string rhs)
{
    return lhs + rhs;
}

That's good code.  Why?  Because I finally figured out how to join to strings together!  That may be part of it, but I deem this method pretty decent for the additional following reasons:

1. Fluent name, the method name describes exactly what the method does.
2. Short method.  The method name describes everything the method does because its small.

I think one of the best and easiest techniques to producing self documenting code is to use the extract method refactoring.  Take some code, extract a well named method out of it, and the readability goes up.

Fluent interfaces and DSL's take readable code a step further, and I think that's why they've become so popular. That, and its so damn easy to write an internal DSL in the cool popular dynamic languages like Ruby.  Why write comments buried in source code when you can write beautiful code instead? 

Have you seen developers obsessed with comments to the point of idiocy?  I know I have where I began to suspect the developer actually enjoyed writing comments more than code, or maybe writing code was too difficult for them so they focused on the low hanging fruit of comments?  Have your secretary comment your code, we as programmers should focus on writing code, good code.

Comments are not for documenting who made changes or when.  Heard of source control comments?  Heard of blame?  No?  Go learn them now.  In my experience DBA's are the worst offenders of this horrible practice, there must be something in their paranoid nature that makes them do this... obsessively.  There's absolutely no reason to litter beautiful code with code change comments, doing so only muddles the clear waters of code.

Back to my original point, I wait until I'm ready to checkin to add my comments.  In fact adding comments is one of my checkin practices.  Adding comments before then is often a waste of time.  How often have you written a method, an entire class, or even an entire namespace that never sees the light of source control?  I've mercilessly axed more JavaDoc comments and classes than I care to remember... more than I probably ever checked in.

And then the other day Jeff Atwood had a blog post about comments, and he said very concisely what I was thinking at lunch.

When you've rewritten, refactored, and rearchitected your code a dozen times to make it easy for your fellow developers to read and understand -- when you can't possibly imagine any conceivable way your code could be changed to become more straightforward and obvious -- then, and only then, should you feel compelled to add a comment explaining what your code does.

If there ever were a take away about a discussion around code comments, that's it.  Well put Jeff.

If you wait until you're happy with a piece of code, when its truly done enough to checkin you'll write less comments and better code.  Remember code comments can be a code smell.

I'm trying out a new Live Writer code formatting add in. I've had mixed results with the others I've used.  It seems I can't find one that is:

1. Easy to setup and use.  Copy, paste, done.
2. Works on my blog page.
3. Also works in RSS readers like Google Reader.

Lets see how the Insert from Visual Studio addin works...

[TestFixture]
public class UnitOfWorkTests
{
    [Test]
    public void Should_return_same_instance()
    {
        var c = new Customer { Address = new Address(), CustomerID = 1, Name = "Sneal" };

        UnitOfWork uow = new UnitOfWork(new StubDataStore());
        uow.Save(c);

        Assert.AreSame(c, uow.Single(new Customer { CustomerID = 1 }));
    }

    [Test]
    public void Can_save_instance()
    {
        var c = new Customer { Address = new Address(), CustomerID = 1, Name = "Sneal" };

        UnitOfWork uow = new UnitOfWork(new StubDataStore());
        uow.Save(c);       
    }
}

If nothing else, at least it looks pretty from Live Writer.  Lets see when it gets out in the wild...

Specifically ID and CLASS attributes are case sensitive when it comes to CSS.  If you take a look at the HTML 4 spec you'll notice that both ID and CSS have [CS] annotation for case-sensitive. 

Although this has always been the case, very few developers know this as a fact.  Its obvious Microsoft missed this in the first few HTML 4 compatible versions of IE.  In fact it wasn't until IE 6, when run in strict mode, would IE in fact honor the case sensitive nature of the CLASS and ID attribute.

I think its because of the early IE 'quirks' mode implementation that very few developers actually know that ID and CLASS are in fact case sensitive. They may guess correctly, but very few actually know this from experience.  A simple quiz at work today confirmed my suspicion.

Well after today, I know from experience that CSS is case sensitive.  <div class="msg-Error"/>  is not the same as  <div class="msg-error"/>.

So in summary if your CSS is not getting applied as expected you might want to check the casing between your HTML and your CSS.

I committed an example class library (utility) which drives some JsUnit tests and gathers the results.  This is handy if you want the results inside of a C# application or an NUnit test.  Basically the JsUnit webform is posted to an ASHX handler running under the .NET 2.0 webserver. 

Its not real pretty or that usable in its current form, but it has some good starting points. I'm not sure it actually works since I lost the original source code and had to decompile it using Reflector.  It at least compiles...  Do whatever you like with the source, its available in my SVN repository here.

You may or may not know that for the past year I've been working for a small startup, GalleryPlayer.  For the most part I'm glad to have had the opportunity to work there, I was able to touch a lot of new technology and learn a lot all while delivering business value.  Overall I was able to learn and grow while there, so I'll chalk that up as a win for me.

Unfortunately as with a lot of startups GalleryPlayer hit a rough spot. We'll leave it at that...

As of July 14th I'm now working with a lot of really great people at Daptiv.  I'm excited to work with a team who are not only smart and driven, but understand the value of agile development and TDD.  There's no convincing that needs to happen, no cowboys that need reigning in, everything is already setup and ready to rock.

Its refreshing to be able to walk into a well organized team and not have technical debt frustrating you at every turn.  This has had a huge impact on keeping my overall stress level at an all time low for being a FNG.  Yes, there is still technical debt (there always is), but the fundamentals are already taken care of, and that makes me very happy.

Perhaps I'm exaggerating a little bit, but if you look at the claims Gallio makes you might be tempted to agree with me. 

The Gallio platform seeks to facilitate the creation of a rich ecosystem of interoperable testing tools...  they should present consistent interfaces to the world so that they can easily be integrated into the systems and processes of the enterprise.  At present Gallio can run tests from MbUnit versions 2 and 3, MSTest, NBehave, NUnit, and xUnit.Net.  Gallio provides tool support and integration with CCNet, MSBuild, NAnt, NCover, Pex, Powershell, Resharper, TestDriven.Net, TypeMock, and Visual Studio Team System.

That's a lot of integrations!

The UI runner that comes with Gallio is pretty and for the most part functional - remember this is an alpha!  I did have some issues when I tried loading several thousand tests into the UI.  Things got slow and a little wonky while it scanned for tests in my assembly. A couple of times it crashed on on me after reloading the assembly after a recompilation. Then again I'm not sure if NUnit is any better in this type of scenario.

Gallio sounds like a real benefit for organizations using MSTest that are looking to upgrade to a real xUnit framework.  At the very least you can ditch the lackluster MSTest runner in favor of a better runner like ReSharper, which is what I'm currently trying to do.  Unfortunately there's an issue with Gallio that makes all the tests report back a status of 'skipped.'  Luckily this is an OSS project with public source code...

Gallio makes working with different open source projects very easy from my point of view.  Now I can use a common interface (ReSharper 4.0 test runner) for all my testing needs regardless of the OSS project's test runner... no need to fire up MBUnit GUI or NUnit or whatever.  It all just works and doesn't interrupt my flow.  I imagine the number of testing frameworks and tools for Gallio will almost certainly grow over time. 

This is definitely one of the more useful testing tools I've seen recently.  Why?  Because it reduces friction.

I think Jeff Atwood hit the nail on the head when he said:

It's an open secret in the blogging community that the comments are often better than the original blog entry itself. Would you browse Amazon without the user reviews? No? Then why would you willingly choose to run your blog that way?

Don't be afraid of comments. Embrace them. Moderate them. The community will respect you for it, and your blog will be better for it as well.

Not only are comments sometimes interesting potentially offering differing points of view, but more than once I've had someone find my blog and leave a comment which solves the issue I was having.  How cool is that?  Even better, the next person having the same issue might be led to my blog by Google and find the answer right there in the comment.

Comments are valuable, which made me realize I need to do everything I can to help encourage comments.  The default setup for leaving comments in dasBlog is too much work IMO and overall isn't a great experience.  So last week I decided to improve the comment experience on this blog.  Here's a summary of what I did:

1. Turned off CoComments which implied an extra form to fill out to submit a comment.  I think this just annoyed people and kept them from commenting. I know I didn't like the extra step.
2. I added Gravatars, which are global recognized avatars (i.e.they work on any site that supports them).  I think this really helps people identify the comment author and makes the comment a touch more personal.
3. I enabled comments to always show on a post entry.  Previously an extra click was required to see comments... which discouraged people to read or add comments.  Now comments always show because comments are important.  I find it almost silly that dasBlog warns against enabling this setting - granted it says for high volume sites (which isn't me).
4. Email addresses are now hidden on the blog post entry.  I think most people don't really like their email addresses showing up even if they are somewhat obfuscated on the blog post page.  From now on your email address will not show, but will still allow me to reply back to you via email.  When I reply to a comment I will post it to this blog and then reply to your email with my comment so that you know I've responded.  Unfortunately I couldn't find a way for dasBlog to automatically do this for me.

I'm hoping these changes will make my blog a bit more comment friendly for everyone.  So, try it out and let me know what you think... by leaving a comment ;)

Last week there was an interesting discussion about coding samples on /.  As if technical phone interviews weren't enough, some companies would like or even require you to submit a coding sample for their review.  These come in various flavors, but I've encountered 3 variations of this:

1. Random code sample of your choosing.
2. Code you write on site while interviewing, usually on a whiteboard.
3. Take home test where you complete a specific assignment.

Of the 3, the first one is pretty liberal and for the most part I would expect any decent programmer to be able to come up with some pithy example.  Sure, not all of us spend a significant part of our time writing code outside of work, but you should have something. 

I think OSS contributions are the best way to answer this type of request - even if you're the only one who uses it.  Its a very simple matter to setup a public OSS Google code playground.  Better yet, submit a patch for your favorite OSS project.  This shows not only you know how to code, but that you can work with existing code on a large project with other people - something you will not likely learn in college classes.

To me, these type of requests are nothing more than a starting point of a discussion between you and a prospective employer.  Which also means, any code you find that is public domain could be turned in.  Is this valid in this context?  I think so, because the code should be a discussion topic and not a test.  You should be able to talk about patterns used, coding standards, and most importantly... what would you do to improve this piece of code.  Clearly you must understand the code to be able to do this.

Writing code on a whiteboard (#2) is a bit different than one or three.  Its real time coding.  Coding under pressure without the aid of intellisense, IDE, or other technical reference.  Everything is based on your recall which only happens through experience, or at least good memorization.  More on this topic later...

Number three is interesting.  Often time the assignment is very particular and requires your to solve a particular problem, often times academic in nature.  This basically means homework; something you won't do in real life, nor something you have laying around already coded.

I think these type of coding samples are particularly useless for several reasons.

1. Good coders often won't waste their time tackling these problems unless they are really interested in the position.
2. They aren't real world and won't likely come up in real life.
3. These type of tests take time.  Why would a highly sought after engineer waste several hours with a home work assignment?

There are probably more reason than the three I stated, but that's more than enough reason for most good candidates to forgo application.

My question is why do companies do this?  Last I checked neither Microsoft or even Google do anything like this.  Perhaps to filter out the truly dedicated?  Maybe...  but perhaps its because someone non-technical is reviewing these tests?

Companies that do have a programming test of sorts like this are just lazy.  They are unwilling to take the burden of weeding out the good from the chaff, so they put the burden on the candidate with these tests, I mean hoops.  To me, these type of tests are a red flag. Perhaps this works for a small minority, but I surely wouldn't want to work somewhere like this.

A good software company should use code as a starting point for a discussion about software and systems.  Particular design decisions made in a complete vacuum are irrelevant without context.  Its all about the context, and that should just be the starting point of a bidirectional discussion, because that's where the real discovery comes from.

Looking for a new job can be an intimidating proposition, especially for developers who haven't changed jobs in a few years.  Are my skills current?  What kind of horrible interview trivia questions are popular these days?  Luckily the initial phone screen is the easiest part of the interview process, especially if you do your homework. 

Despite this, it amazes me how many candidates completely flounder the phone screen regardless of how senior their resume says they are.  I've found that a large majority of candidates don't pass the phone screen.  Yet, its doesn't have to be this way.  Don't rest on your laurels, do your homework!

Most phone screen questions are very superficial and don't go into any depth, you either know the answer or you don't.  If you've been coding every day for the majority of your time then you will generally find the questions very easy.  If you're fumbling for an answer, then that's definitely a bad sign to the interviewer because most of these questions they expect you to just know the answer as if it were reflex.  Its usually better to give answers promptly that are shallow than in depth answers that take a while to get out. 

And if you don't know an answer, just say so - don't try and BS your way through it.  Its disrespectful and you will get negative points, but having said that you should also follow up with a guess if you have one.  Here's an example. 

Interviewer: Is XML case sensitive? 

You: I don't know, but I always pretend it is when I write out my tags.

Beyond that, what kind of stuff should I do to prepare?  I'm glad you asked.  Find interview questions online and spend some time brushing up your skills.  Maybe even take a BrainBench test to help solidify your knowledge, the C# one used to be free.  Eventually you will notice a pattern to the interview questions.  Some of the most common that I've asked and/or answered are below.

General C#

• Brush up on the basics: and, or, xor, bits, bytes, hexadecimal, max size of data types, etc. etc.
• Learn the collection types. How does a stack differ from a queue?  What's a linked list?  What collection types are available in .NET 2.0?  How do you find something (quickly) in a given collection?
• What is the heap?  What is the stack?  You should know how .NET manages memory.  What is System.GC.Collect()?
• IDisposable.  Why does IDisposable exist?  What does using have to do with IDisposable in C#?  What's a Finalizer? How is a Finalizer different from a C++ destructor?
• What is the GAC?  What problem does it solve?  What is sn.exe?
• In .NET is a string a stack or reference type?  Is the .NET string class immutable?  Why does StringBuilder exist?
• What is an interface?  Abstract class?  Virtual method?  Does C# allow multiple inheritance?
• What is recursion?  Why would you use/not use recursion?
• Exception handling. How many catch blocks can a try block have? When does the finally block run? How do you rethrow an exception without killing the stack trace?
• What's a thread?  What's a process?  Compare contrast a thread and a process.  What's the lock keyword in C# do?  What's a deadlock?
• What does Debug.Assert, Debug.Trace, Debug.Write do?  Why would you use these?
• What an event?  What's a delegate?  When/why would you use them?

ASP.NET

• ASP.NET page lifecycle.  I know, I know... but learn it!  You will be asked this question!
• What's a postback?  What is Page.IsPostback? 
• What kind of controls exist in ASP.NET?  What's a user control?  What's a master page?
• What are several ways to maintain state in ASP.NET?  Where is session stored?  How does having a web farm affect this?
• How can we secure an ASP.NET application?  Your answer should cover coding as well as infrastructure.
• How can you debug an ASP.NET app?  How about with IIS?  How about with a remote IIS server?
• Does POST or GET mean anything to you?  How do they differ?  What is Fiddler?  What's a cookie?
• What's an http module?  What is an ASHX file?

SQL Server

• What types of joins exist in SQL Server?  Compare contrast the different types.
• Learn your indexes and how they differ. How does SQL Server store data?
• What's a primary key?  What's a foreign key?  What's a candidate key?  How would you model a many to many relation?
• When would you use GROUP BY and HAVING clauses?  How would you write a query that finds all the duplicate rows in a table?
• Sprocs and functions, how to they differ?  What advantages/disadvantages do they have?  What are the different ways of returning data from a sproc?
• What's a transaction?  How do they work?  When would you use one?  What's optimistic concurrency?
• What's a SqlConnection?  What's a connection pool and why are they useful?  What's a trusted connection?

I'm not sure this is true, but it seems to me that the better employers will ask a few basic comp sci questions (like 1 & 2 above), while the crappier ones skip this area and focus more on ASP.NET or SQL.

Sometimes you'll actually have a class that needs to read and parse files on disk.  This is pretty easy to do with the FCL StreamReader, but the problem is how do we test a class that is accessing resources on disk like text files?

Most devs first reaction is to create a file on disk in the test project and read that in.  This is often better than nothing, but has some problems associated with it.  Your test assembly now requires physical files on disk which are probably not in the current running test directory, or maybe you've moved the entire assembly to a different location then the test expected.  The real issue is that the class under test controls where the data is read from, not the test.

In short, these external files make your tests brittle, slower, and less intention revealing.  Not only that, but the external dependency really makes the test an integration test and less of a unit test.

The normal solution is to hide the external dependency behind a facade or interface that is mockable.  Unfortunately this is difficult because access to files on disk normally is very short lived.  A StreamReader instance often only lives for the duration of a method call, if even that.  The typical usage pattern  is: construct/open, read, close.

   1: using (var reader = new StreamReader(@"c:\file.txt"))

   2: {

   3:     fileType = reader.ReadLine();

   4: }

We really can't just inject a StreamReader instance into our class under test because the StreamReader opens the file via its constructor.  The problem is that the class under test is responsible for the entire StreamReader life cycle.

The simplest way around this is to use a factory class to create StreamReader instances which allows us to control the instantiation of the StreamReader, which is important when we go to unit test.

   1: public class StreamReaderFactory : IStreamReaderFactory

   2: {

   3:     public StreamReader CreateReader(string path)

   4:     {

   5:         return new StreamReader(path);

   6:     }

   7: }

   8:  

   9: public interface IStreamReaderFactory

  10: {

  11:     StreamReader CreateReader(string path);

  12: }

With that interface in place we can then inject a StreamReaderFactory implementation into our class when running in production. The factory couldn't be any simpler, its just a simple wrapper around the new statement. 

Now when we unit test we'll swap out the very simple factory implementation with a mocked one using RhinoMocks.  This mocked factory will return a predefined result which is located at the beginning of the test, keeping everything located in the test.

   1: [Test]

   2: public void Should_parse_resource_type_from_first_line()

   3: {

   4:     using (var content = CreateStream("F4", "some text resource"))

   5:     {

   6:         var streamReaderFactory = MockRepository.GenerateStub<IStreamReaderFactory>();

   7:         streamReaderFactory.Stub(x => x.CreateReader(@"resource.dat"))

   8:             .Return(new StreamReader(content));

   9:  

  10:         var classUnderTest = new ResourceParser(streamReaderFactory);

  11:         classUnderTest.ParseResources();

  12:  

  13:         Assert.AreEqual("F4", classUnderTest.ResourceType);

  14:     }         

  15: }

  16:  

  17: private static Stream CreateStream(params string[] lines)

  18: {

  19:     string rawContent = string.Join(Environment.NewLine, lines);

  20:     return new MemoryStream(Encoding.UTF8.GetBytes(rawContent));

  21: }

If we had a really complicated external file I would more than likely stick it into an embedded resource text file, but that's only if the file was complicated or a pain to create in code as a string.  The point is with the factory in place the test controls where the data comes from, not the class under test.