Polishing the Golden Shovel

My senior year of High School I took AP English. I hated that class, but I have to admit I did learn a little about writing. One thing I learned was you got a higher grade if you included your own insight and opinions into your "book review" type papers.

My junior year of College I took History of Aviation to fulfill the last of my History credit requirements. It was a horrible class. The material was interesting, and the books we used were decent, but our professor was… well, boring. And the tests and assignments were simply a waste of time. It was quite literally like going back to freshman year of High School with "chapter summary" 1 page papers in 5 paragraphs due every week.

I can’t recall exactly what grades I got on the first few papers, B- or C comes to mind though. The professor had underlined roughly half of my essay (not to indicate anything, I think she was just one of those people who underlines as they read so they don’t loose their place...). Then she’d scrawled, "more examples" or something to that effect on the top. I was kind of peeved. I’d read the material, and I thought that was obvious given the content of my "essay." And like I’d learned in AP English in High School, I’d added in a lot of my own personal take on what the reading had taught me and how it applied to whatever idiotic prompt we’d been given that week. That was clearly not what the professor was looking for.

It took me a few papers to finally realize that this was a class where it didn’t matter what I was learning, or how well I was writing. This was a class where I had to figure out what the professor wanted to see in those papers. It didn’t matter if what she wanted to see made sense, or was good or bad, or furthered my education... It only mattered that she wanted to see it.

So I developed a method for writing those papers. I would look at the prompt we’d been given. Then I’d skim through the material we were supposed to read. When I found a sentence or paragraph that applied to the prompt somehow, I’d underline it and add a mark at the top of the page so I could find it again. When I’d finished skimming the material, I’d go back through and find everything I’d underlined. I’d summarize the sentence and put the page number. Then I would number each quotation 1-n in an order that would sensibly answer the prompt. Finally I’d write my paper. The introduction would restate the prompt. The rest of the paper would be direct quotes (or sometimes paraphrased quotes, always referenced) with transitions between them. The conclusion would restate the prompt. Each of my little 1 page essays would include about 8 to 12 quotes.

Let me drive that home. I literally wrote NOTHING except to transition between quotations. I’m not overstating this, that’s all I did. And while I think I did a decent job masking it with my transitions, it was still quite obvious.

I got As on every paper for the rest of the semester.

My dad once taught me a term which summarizes what I was doing here wonderfully. When I would tell him about some stupid paper I had to write he would say, "Polish your golden shovel!" This referring to all the Bull Shit you’re about to shovel into your paper and attempt to masquerade as golden writing.

Of course, usually when you’re putting your golden shovel to work it’s not as blatant as my History of Aviation story. In fact, in normal use it’s a very valuable skill to have. Sometimes you have to sharpen the saw, and other times you have to polish the golden shovel.

SQL Server 2005 Service Broker

Service Broker is a very nice feature of SQL Server 2005. Like most things, it’s quite simple after you’ve figured it all out, but when you’re first learning, it can be quite daunting. When it comes to learning about SQL Server the main problem is that all the words Microsoft uses to describe things are so overloaded it’s easy to get confused. Everything is an "application" and everything is a "service"... This rapidly becomes confusing... "Which application are they talking about now? Their’s? Mine? What service? My service? The service broker service? That stored procedure?"

It also becomes confusing because SQL Server has so many different "technologies" built into it. A lot of them seem to do the same thing, but in fact they’re different, some more than others. For example, there is Notification Services, Service Broker, Event Notification, Internal Activation, External Activation, etc. And then it gets even more confusing because some of these "technologies" are just combinations of other "technologies." External Activation, for example, is really just Event Notification applied to Service Broker and it uses Service Broker Queues to deliver its messages.

In this post I’m going to briefly go over some of the things I’ve learned about Service Broker. If you’re completely new to Service Broker and you want a quick detailed overview with code samples you may want to go read this tutorial or browse through MSDN’s service broker articles.

So then, what is Service Broker? It is simply a queued message delivery system. A message sent from one person to another is guaranteed to not only arrive but arrive in order, and in the event that something goes wrong, not be lost. Of course there are a lot of details to describe exactly how it behaves, but that’s really all there is to understanding it.

What would you use it for? Lots of things! The uses I’m most concerned with are "Asynchronous triggers" and "Large-scale batch processing." In other words you can drop a message into a queue and then forget about it, continuing with your own work and ultimately completing. In the background, you know that your message will at some point be received and handled. In this way you can offload work from stored procedures or triggers to be performed asynchronously.

So here is the big question, if we’re sending messages from person A to person B, who or what are these people? They are anything which is capable of executing SQL commands. Thus it can be a stored procedure, a C# application using dynamic SQL, a Windows Service, anything. Notice that any of these things can be either the sender or the receiver!

Here’s a simple example. The sender can be a stored procedure which you invoke. This stored procedure will simply execute the needed commands to send a message from himself to the receiver. The receiver can also be a stored procedure, but a slightly unusual one. This stored procedure will be configured to start when SQL Server starts and it will run infinitely in a loop, periodically checking for new messages. If this is beginning to sound a lot like Socket programming to you, then you already understand Service Broker.

Where is the queue in this example? Well, actually, there are two of them. The sender has a queue and the receiver has another. Why? So far I’ve been describing this as a dialog. Person A always sends messages to B who always receives them. B never sends anything to A. But, in fact, that’s not the way Service Broker works. Service Broker always assumes a dialog in which A and B are both sending and receiving messages to and from each other. That doesn’t mean you have to carry on a dialog, in fact when I’ve used Service Broker I’ve only had a monolog. But that’s simply in the way I’ve written the applications that are using Service Broker. I didn’t do anything different in the way I setup Service Broker to make it work that way.

Back to our example, since we have two stored procedures, could we put them in two different databases? Indeed we can! In fact, that is one of the main uses of Service Broker. You could put them in two different catalogs of the same server, or you could put them in two completely different servers. Now you can effectively have two different databases talk to each other.

Having a stored procedure that is always running and monitoring the queue in a loop works just fine and there is really nothing wrong with that approach. However, Service Broker comes with another option for receiving from a queue called "Internal Activation." Basically, SQL does the looping in the background for you and when a message arrives on the queue it invokes a stored procedure. This stored procedure pulls the message off the queue and does whatever it wants to do with it. Usually the stored procedure is written to then enter a loop where it pulls messages off the queue until the queue is empty, at which point the stored procedure ends. Internal Activation will also invoke multiple instances of your stored procedure if the currently running procedures aren’t able to keep up with the number of messages arriving at the queue. In this way Internal Activation can help your message handling scale based on demand.

When I first heard about this a little red flag went up in my brain. I thought to myself, "Self! I thought messages were guaranteed to be delivered in order with Service Broker. If Service Broker is going to launch multiple "handler" stored procedures in parallel, how is it that the messages will be handled in order?" It turns out the answer lies in another Service Broker concept I haven’t mentioned yet called a conversation. Messages have to be sent on a conversation. Messages within the same conversation will arrive AND be handled in the order they were sent, guaranteed. But messages between conversations can be handled in parallel. This behavior is performed magically in the background without you having to do anything. It happens because whoever receives a message on a new conversation automatically obtains a lock on that conversation and they will only be able to receive messages from that conversation, until the conversation ends. But again, if no one had told you, you’d scarcely be aware of it at all.

If there is Internal Activation, there must be External Activation as well, right? Right. Internal Activation launches a stored procedure inside SQL Server, External Activation is for launching arbitrary programs outside SQL Server. .NET programs, C++ programs, Ruby programs, whatever. At least, that’s what you’d expect. In fact it’s kind of a misnomer. The Internal Activator launches the internal stored procedures. Internal Activation refers more to when the activator should do its work. The same is true for External Activation. The difference is that SQL Server 2005 doesn’t come with an External Activator. So you have to write your own. You can do this, because SQL Server 2005 does have External Activation, which tells you when a Queue has been activated.

External Activation is performed with SQL Server Event Notification. In the parlance, you’d write an external application which receives the external activation event (called the Queue Activation event). Okay... So how does the external app "receive an event?" Through Service Broker! That’s right, you create another Service Broker Queue and the Queue Activation event is placed in that queue as a message. Then you write an external application that monitors this new queue and creates new application processes which behave just like the activated stored procedures from Internal Activation. I’m not going to go into more details of how this works. It is a bit more complicated of course. However, Microsoft does have a sample.

How does this external application monitor the Service Broker queue? Exactly the same way as our first example stored procedure did. It just sits there in an infinite loop waiting for messages to arrive on the Queue. In other words, it just executes a SQL statement inside a loop.

So, what’s the difference between using an External Activator and just writing an application that monitors the actual queue in question (not the "queue activation" queue)? The only difference is that the External Activator will spawn off multiple handlers applications and therefore scale better with demand. Just writing a monitoring application will only handle one message at a time (unless you get fancy, which could get you into trouble in some circumstances due to conversation queuing as mentioned earlier). However, there are circumstances where this is all you need. In fact, all the ways I’ve used Service Broker to date have worked this way.

This is partly because all my Service Broker "applications" have been monologs and the processing they have performed wouldn’t really go any faster if it were done in parallel. In fact, I have never used more than one conversation. So far, I always create a single conversation. I cache the conversation handle in a database table so I can reuse it whenever I send a message. This is because most of the performance impact when using Service Broker comes from creating a conversation. That makes sense since the conversation is actually the unit that has guaranteed in order message delivery. By caching the conversation and never ending it or starting a new one, you improve the performance. This is discussed in an article called Reusing Conversations. You have to consider some scalability concerns before deciding to use exactly one conversation. For me however, I felt that was good enough (not to mention simple).

For me, the receiving application is a Windows Service written in C#. It creates a background thread that loops indefinitely issuing a WAITFOR( RECEIVE ... ) command to SQL Server with a half second or so timeout. This setup allows me to send messages serially and receive and handle them serially as well. If I needed to send messages in parallel I’d have to use more than one conversation. I believe I could still receive the messages serially, but I’d have to be very careful with when the conversation lock was released, as discussed in this msdn article, Conversation Group Locks.

Hopefully this summary has shown how flexible and powerful Service Broker is. And also how easy it is, despite the fact that the learning curve is pretty high and the setup curve is pretty high too (you have to create at least 6 different new database objects at the bare minimum to get a service broker conversation going). With luck SQL Server 2008 wont deprecate all this information.

Unit Testing and TDD

Unit Testing and Test Driven Development have been around for quite awhile. However, they're still just beginning to really become a commonly seen practice in industry programming, partly because of the influence of Agile Programming and Dynamic Languages.

A unit test is very simple (and it has nothing to do with any manor of human body part). From a code perspective a unit is a public class with public properties and methods. From a design perspective a unit is a "high level" function or behavior or task or object. A unit test is a method that tests a certain behavior of the unit. Thus one unit will have many unit tests, each one testing a different part of its behavior.

Sometimes unit tests are written by "QA" people after the developers have finished writing the code. Other times, unit tests are written by the developers themselves after the code has been written. Both of these approaches are terribly boring, inefficient, and ineffective.

Test Driven Development is the practice of writing unit tests BEFORE production code. It goes like this:

1. Write a list of things to test
2. Pick a test and write it before you've written the production code
3. Write the minimum amount of code needed to pass the test
4. Refactor the production code AND test code, if needed
5. Repeat

This is typically referred to as the Red/Green/Refactor pattern. It’s very festive and Christmas appropriate. First, you write up a list of tests. Then you decide what test you want to code first. Being a lazy computer geek who would rather IM the guy in the other room than actually get up out of your chair and (*gasp*) walk, you pick the easiest test first. Since you haven't written the code that the test is supposed to test, your test probably won’t compile. So, you write the minimum amount of code needed to get it to compile by defining the class you invented out of thin air in the test and any properties or methods you may have whimsically pretended it had. Now you run the test and it fails since none of those methods or properties actually do anything yet (red). Now that you see red, you can actually write some code. You write the minimum amount of code needed to get the test to pass (green). Then you survey your code and your tests and refactor as needed, re-running the tests when you're done. At this point you enhance your list of things to test, in case you thought of something new, and pick another test.

Every line of code you write is directly driven by a unit test (or a refactoring): Test Driven Development.

If you think I’m over emphasizing the minimum concept above, wait until you read your first TDD code sample. The first one I saw tested a Queue’s IsEmpty method. The test was that when the Queue is first created, IsEmpty returns true.The code they wrote to pass this test was:

public bool IsEmpty()
{
return true;
}

So when TDD people say do the minimum, they really mean it.

It sounds quite simple and for the most part it is. However, there are some guidelines which will help make the unit tests more useful.

1. Tests must be fully automated requiring no external input or setup that is not performed by the tests themselves.
2. Don't write code unless you have a failing test. Your tests define the code's requirements.
3. Each test should test as little as possible. That is, be as specific as possible and test exactly one feature of the unit. Then, when a test fails, you know exactly what is wrong.
4. Tests should exercise only the unit being tested and not any of that unit's dependencies (ex: database, other units, etc). This is accomplished through dependency injection and mock objects.
5. Test code is not a secondary citizen; it is just as important as production code and should be treated as such.

The main question to ask about Unit Testing and TDD is: does it help? Well, help with what? Bugs? Time to develop? Maintenance? Code design?

Here are some of the pros I’ve seen while doing TDD:

1. Fewer bugs: Thinking through what tests to write, and actually writing them, frequently reveals other test scenarios I would have missed. This is partly because I’m not doing "gunslinger" development and partly because you are using your classes before you’ve written them.
2. Regression testing: Worried that code you wrote three months ago still works? Run the tests. Worried you forgot something during your code refactoring? Run the tests. Worried you broke your public interface by accident? Run the tests.
3. Easier debugging: The test tells you exactly what is wrong and you can frequently tell exactly what LINE of code is wrong.
4. Improved code design: Because you need to test one unit at a time, you naturally design your code into smaller, “DRY”-er, more orthogonal, and more composable units. You also tend to design around algorithms instead of UIs.
5. Increased confidence: Because everything is tested and tests are fast and easy to run, you KNOW your code works. When your boss asks, "Does this work?" you don’t have to say, "Last time I checked..." The last time you checked was immediately after your last build. "It works."
6. One development style: Whether you’re writing new code, or prototyping, or debugging, or adding features, or working on someone else’s code, it’s the same process: Red/Green/Refactor.
7. Feeling of "making progress": You’re constantly finishing small units of work in the form of tests and getting instant feedback that the work is correct. This means you don’t have to go days hacking on some deeply embedded code, hoping you’re getting it right.

What are the cons?

1. At least twice as much code: Tests require lots of code. You have to write it, there is no avoiding it.
2. Tests take time: Writing all those tests takes time.
3. Test Maintenance: You have to keep that test code up to date if you want it to be worth anything.
4. Dependency Injection can get ugly and it can be hard to know where to draw the line, as I discussed earlier.
5. Some things can’t be tested: You can’t test GUIs. There are also things that are just too hard to test. Asynchronous timing issues for example.
6. Code has to written to be tested: You can’t test any arbitrary code. You can test parts of it in some cases, if you’re willing to deal with dependencies it may have. But to test it "properly" it has to be written with testing in mind.

So is it worth it? Do the pros out weigh the cons? So far, I think they do. I even think that in the long run, writing unit tests may actually save time because they make it so much easier to update code and verify that code is working correctly months and years later. They also make it easier for multiple developers to work on the same code at different times. Also, if you’re doing proper TDD, then maintaining the tests isn’t an issue. And you can address old code that isn’t tested by refactoring it and testing the refactored portions little by little as you fix bugs and add features. And while you may not be able to click a button on a form, you can call the method that the button’s click event handler would have called.

All that being said this is still computer programming.There is no silver bullet. But TDD seems to get between 70% and 80% of the way there, and that’s certainly better than randomly clicking around your Forms...

Finally, if you're completely new to this stuff you're going to want to check out nunit for unit testing and nmock or Rhino.Mocks for creating mock objects, all of which are free.

And now we’ve reached the part of the post where I ask what you think about Unit Testing and TDD. Do you agree with my take on it? Do you have stuff to add?

Dependency Injection

Dependency Injection is an "object oriented design pattern" for creating loosely coupled objects. It has nothing to do with needles, and if it makes you think of the Breakfast Club that's not my fault.

Lets say you're writing a class whose job is to find a certain configuration file. Its going to look in a predetermined expected location, and if it doesn't find it there it will ask the user to select it. This object is dependent on the user. And in code, it is dependent on some kind of UI for asking the user for the file.

If we're in C# you can write this object so it creates an OpenFileDialog (which doesn't have the same Memory Leak causing behavior as a regular form, by the way) and displays it to the user. However, this would not be a loosely coupled design. What if you wanted to change this to use the Vista open file dialog? Or what if you wanted to make it force the user to select a valid file by continually asking them until they select one? You'd have to edit the main class. And you'd have to be careful that the user prompting logic didn't become intertwined with the rest of the class' logic.

What can we do? Let's inject our class. Let's inject it with dependencies. Or more accurately, classes that take care of its dependencies for it.

Create an interface like IPromptUserForConfigFile which contains a method that returns the path the user selected as a string. Now modify the constructor of your main class to accept an instance of an IPromptUserForConfigFile class. The main class simply calls the method on this interface, all the details of how the user is prompted are abstracted away. Plus you can change how the user is prompted at any time by simply passing in a different class that implements IPromptUserForConfigFile.

Dependency injection seems pretty simple. It gives you loosely coupled objects, which are very orthogonal, and possibly best of all it makes it easy to unit test with the help of a library like nmock.

What are the downsides? You now have an interface and a class that you otherwise probably wouldn't have created (since you haven't actually had any practical DEMAND for loose coupling yet). And you also have to construct a class that implements the interface and pass it into the main object's constructor. There are libraries to help with that part, like Spring.NET. I've never personally used them, but they exist. Actually, when I've used this pattern I've built in a default implementation of the interface to the main class and instead of passing in the interface object through the constructor I allow you to override my default with a property. This clearly violates some of the loose coupling, but to be honest I'm really not using this pattern for the loose coupling, I'm using it so I can Unit Test.

The biggest downside here would seem to be that the size of your code base has increased. And this has happened to enable loose coupling, but mostly to allow for Unit Testing. Is this a good thing?

When I first started learning about Unit Testing my biggest worry, apart from how much more code I'd be writing and maintaining, was that I would start writing strangely designed code just so I could Unit Test it and not because it was the right design for the situation. You can imagine all kinds of terrible things. Classes with all public methods. Classes with only a single static method that is only used by one other class. Classes with tentacles and suction cups and slimy oddly named and mostly irrelevant properties.

However, I was surprised at how often my design changed for the better due to thinking about testing. My first few unit testing attempts didn't result in any tentacles or other horrible things. That is, until I encountered dependency injection. "Look! I'm making my code loosely coupled!" I thought to myself, "That's a good thing! This Unit Testing really works!"

But dependency injection is a very slippery slope. After all, the majority of classes you write are riddled with dependencies. Things like databases, framework code, web services, user interfaces, other code libraries you've written, etc. Should you seriously create a class to wrap each one of these and then pass those classes into other classes that apply the "business logic" and "glue" between how those dependencies are used? Imagine how huge your code base would be then! And you certainly can't create static classes if you're planning on passing them into another class through a constructor. And of course now that you've created all these objects that wrap various dependencies, you're going to want to reuse them. In .NET that means putting them in their own assemblies. Are we going to end up with 500 assemblies with complicated dependencies? Where do we draw the line?

An object mocking framework like TypeMock (not free!) would help alleviate the need for all the "injection" going on here just for the sake of testing, though you'd still need to create many objects. I need to look into that product more to decide if its worth the cost (its quite expensive). If it is, then the line can be drawn with a question, "Do I need this to be loosely coupled?" If it isn't, then the line needs to be drawn with a different question, "Do I need to mock this for testing or to have it be loosely coupled?" The first question is pretty easy to answer. The second one... maybe not so much.

Lets end with a string of questions. Do you unit test? Do you mock objects? What mocking library do you use? How does dependency injection make you feel?

Connect4

In college I took an AI class. For the most part I was pretty disappointed in it. I wanted to learn about techniques to make computers learn (Neural Networks and Evolutionary Computation and so forth) but intro to AI is mostly just A* and Alpha Beta search. Given, those are clever algorithms, but at their core they're just brute force, so I didn't find it all that interesting.

However, our final project in the class was to develop a program to play Connect 4. The class broke into teams of 4-6 people. Then we had a big tournament between all the teams to see who's connect 4 program would win. Our professor gave us a heuristic to start us off which she told us wasn't very good. We were supposed to develop our own heuristic and then any kind of UI (or not) that we wanted.

Heuristics are pretty boring. Basically you just spend a lot of time trying to figure out how to decide, given a certain board state, if the board is good or bad. So you do all the work of figuring out the game, code it into a heuristic, and the computer just brute forces its way through all possible game moves trusting that your heuristic is smart enough to tell what is good and bad.

My team didn't really want to work on the Heuristic. Instead the majority of them went off and created a pretty sweet OpenGL UI where the Connect 4 board would spin around and the pieces would fly off the stack and into the board...

We just used the Heuristic our professor had given us, but a friend and I optimized the crap (memory usage) out of our Alpha Beta search, board state representation, and heuristic evaluation. Because our alpha beta routine was so much faster than the other teams' we were able to search about 2 levels deeper into the game tree.

We tied for first place.

Even though our Heuristic wasn't supposed to be very good, the fact that our search algorithm was so much more efficient meant we looked further ahead than everyone else and that was all it took.

At the time, we also had access to a room full of computers. We considered creating a client/server program to use all those computers to evaluate the game tree in parallel but after we did the math we realized that adding 12 more computers would only get us one level further down the tree because the number of nodes in each level of the tree doubles. We didn't think one more level was worth the effort, so we didn't bother.

PowerShell Example

Here's a real quick Windows PowerShell example I just used.

I've been experimenting with .NET's Window's EventLog support. There's a class in System.Diagnositics called EventLog which lets you query the event log and add entries and so forth.

I had a C# program which created an event source on the Application Log like this:

if( !System.Diagnostics.EventLog.SourceExists("TestSource") )
System.Diagnostics.EventLog.CreateEventSource("TestSource",
"Application");

and I needed to change it so that the event source was on a new custom log like this:

if ( !System.Diagnostics.EventLog.SourceExists("TestSource") )
System.Diagnostics.EventLog.CreateEventSource("TestSource",
"CustomLog");

To do this, I needed to delete the old event source, otherwise I would get an error because I was trying to use the event source with the wrong log.

I was about to write a tiny little C# program to say:

System.Diagnostics.EventLog.DeleteEventSource("TestSource");

And then I thought, "PowerShell!"

PS C:\> [System.Diagnostics.EventLog]::DeleteEventSource(
"TestSource")

Copping Out With Consistency

Computer Software is so virtual that it is very hard to determine why one thing is "better" than another. Is it better to have buttons run along the button of a grid horizontally, or along the right of a grid vertically? What exactly does "better" even mean? Easier to read, easier to understand, better looking, more extensible, easier to code, ...? You can apply all the Theories of Software Usability you want to and its still going to be hard to determine.

The same issues come up in object oriented design. Should this be one object or two? Should it contain state or not? Should it use inheritance, or delegates, or dependency injection?

Its very difficult to prove that one way is better than another in cases like this. To combat this problem, programmers and designers use some common rules of thumb. One of these is that consistency is a good thing.

If you choose to lay out your UI in one way somewhere else, its a good idea to do it the same way here. If you've designed your objects to behave a certain way somewhere else, its a good idea to make them work similarly here. It makes sense. If everything is "consistent" users don't have to constantly learn new things. Learn it once and it applies all over. This was one of the things that impressed me about Windows Powershell. Its structure makes all its commands very consistent.

However, I've found that people all too often use Consistency as a convenient cop out. "We have to do it this way! Its more consistent!" Okay sure, rule of thumb, consistency is good, got it. Is it always true? Of course not! Sometimes the benefits of doing something a different way are better than the benefits of being consistent. Other times, being consistent can be down right bad. If you're forcing A, which isn't in any way similar to B, to behave similarly to B, you're probably doing something wrong. And of course, if the consistent way has problems, or if a better way has indeed been found, then forcing yourself to be consistent is just keeping you from making any forward progress.

I know, this seems obvious. But its such an easy trap to fall into and it happens all the time. Its just easier to say, "lets make it consistent," than it is to think about if that might actually be the best choice. After all, software is so virtual, its hard to determine if one thing is "better" than another.

Check in Comments

My first approach to check in comments was not to use them. "You're just going to have to diff the code to see what really changed anyways!" I would have said.

My second approach has changed a bit. I still think you're going to have to diff the code to see what really changed. Like I talked about in Code Documentation, meta data is a bad substitute for reading code. However, check in comments can help answer the following questions:

1. What did that dude change?
2. Which files do I need to diff?
3. Could this change be of interest to me?
   

The key is you have to write your check in comments to be helpful in answering those questions and leave the details to the diff.

1. If you didn't really change anything, don't leave a comment. If you're checking in a file and all you've done is change the spelling of a variable, or the capitalization of a method, or the wording of a comment, don't bother with the check in comment. No one is ever going to need to diff or read your changes for that version, so save me the time in reading your comment just to figure out that you didn't change anything, and don't leave a comment. If you're required to leave a comment, just put "none" or something equally simple.
   
2. Title what you changed. Pretend you're trying to give the diff between your version and the previous version a Chapter Title. It should summarize the changes you've made at a high level.
3. Be as brief as possible. Don't write a book. Don't even use full sentences. How few words can you use to describe the changes you made?
4. Group check ins by change. If you're checking in 10 files which have had 5 mutually exclusive changes made to them, don't check them in all at once. Do 5 check ins of two files each. Each check in gets its own comment describing only the changes in those files.
   
5. Check in one change at a time. If you're frequently writing check in comments that say, "Did this and that," could you have done "this" and checked in, then done "that" and checked in?
   

One example of a bad check in comment I frequently see is a list of everything that was changed, written in one run on sentence. For example, "Updated the <class> to have 3 new public methods, and broke <method> into two different methods, one for <a> and the other for <b>. Also changed the parameter types of the methods from <x> to <y>." There are a number of things wrong here. First, why should the check in comment document the purpose of the methods? I'm going to assume there are comments in the code you're checking in that does that. Second, why tell me about the actual parameter types you changed from and to? It's probably enough just to say the parameter types changed. Third, do I really need to know the class, and method names? And finally, this is too long to help me figure out if I want to look at this version of the file. You could convey all the information needed by saying "Refactored public interface" or if the refactoring has added new capabilities, "Supports a, b, and c."

A check in comment should convey what changed at a high, abstract, level. To figure out how those changes were accomplished: diff. To figure out if those changes might be causing a bug you just found: diff. To figure out how to use the changes: diff. You're better off looking at code to answer those kinds of questions anyway. The check in comment is just a guide to help you figure out where to look.

Managing Projects

This is a follow up to a previous post, To Estimate or Not To Estimate.

I've been doing a lot of reading and learning and experimenting since that post and I now have a much clearer idea of what I'd like to see in a project management application.

I'll start with what kinds of questions I want to be able to answer:

1. Who has too much work, who needs more work? (Developer Workload)
2. How much work have we done, how much work is left (Iteration Status)
3. Is our scope slipping, are we getting things done, are we converging on a completion date? (Iteration Progress)
4. Are certain high level tasks slipping or eating more time than others, or more than expected? (Project Item Progress)
5. What are people working on/what should they be working on?
   

My current thoughts are structured like this:

• Project - top level
• Project Items - high level "tasks", or "features" that make up a project. These are assigned to one or more individuals. Estimates are added at this level in terms of complexity or actual hours.
• Features, Tasks, and Bugs make up Project Items.
• Tasks and Bugs are assigned to developers and estimated in hours (<=16 hours)
• If actual time spent is going to be tracked, enter it at the Project Item level.

There are a couple of important things to note here. First, from an estimation standpoint, it makes no difference how much time the developers have actually spent versus how much time they estimated. All that matters is how much time they think is left. With that information you can create a "burndown" chart. That chart will answer my Iteration Status, Iteration Progress, and Project Item Progress questions (assuming I can filter it appropriately). That information would also make it possible to build a work load chart similar to this one. All of this can be accomplished without worrying about actual time. We can also display a list of all the Project Items a certain developer is assigned to, or a list of all the developers assigned to a given Project Item. No more wondering what people are working on.

Now you have some nice and simple burn down charts. But are they accurate? No. You know your developer's estimates are not correct. You also know that some devs are better estimators than others. So you can't accurately predict a ship date from this data. You can get a rough idea, and you can see that the project is in good shape and is progressing nicely, but you can't determine a date.

If you want to be able to predict an actual ship date, then you need to track time, and you need Evidence Based Scheduling and you need FogBugz. Can EBS account for the fact that working with a third party scan library will take 4 times as long as what a developer usually works on? Kind of, but not really. Can it predict that a ton of redesign and new features may need to be added to the application after the client sees a demo? Kind of, but not really. So even though EBS is way more accurate with the data it has, it's still just giving you a rough estimate because it doesn't know what data may arrive tomorrow.

So the question becomes, how accurate do we need to be with this stuff? Are we satisfied knowing that our work is trending toward completion? Or do we need to know WHEN completion will actually happen?

From my current thoughts above you can tell that, right now at least, I think it's enough for me to know we're trending toward completion. Unfortunately, I'm not the only person in the equation. My boss needs to do two things I don't. First, he needs to guess before we even start a project how long the project will take. I call this a "blind estimate" and it's clearly impossible, but he still needs to do it because the client isn't going to hire you otherwise. Second, he needs to keep the client updated on when we're going to ship, because that is all a client cares about: when we'll ship, and how the budget looks (only some of them care if the app is any good).

Clearly, actual time matters a lot to him. And not just time spent working on tasks, but all "billable time." Time spent in design meetings, time spent with clients, time spent writing documentation, time spent researching tools, etc. Thus any time entry system which is going to be at all useful for integrating with billing has to allow me to enter time on things other than tasks or project items. It should allow me to just enter time and not require it to be "on something."

Furthermore, now that we're entering time, that time can be used to help with future "blind estimates." How long did it take to do x last time? It's likely to take a similar amount of time this time. That's why I think it makes sense to track time at the Project Item level. It's high enough to be "reusable" but low enough to be semi-accurate. Also, since we're estimating at the task level, and tasks are linked to Project Items, we can see how the remaining estimates and actual time spent compare to the original blind estimate and the budget.

I suppose the final question must be, is there a tool that will do all this? Not all of this, at least, not that I'm aware of. I know that a lot of this is very similar to Scrum. But the Scrum tools I've seen don't capture all of it (Scrum for Team System, escrum), especially not the time entry portions. Also, FogBugz comes pretty close, but it lacks the Project Item concept and doesn't have any burn down style reports. So if you were hoping I'd end this by recommending a tool, I'm sorry to disappoint. If I find one, or can make one work like I want, I'll let you know. And if you know of one, please let me know.

Code Documentation

At work I've worked with a lot of people who are either just out of College or still in College. There has been an interesting trend in their code's documentation: they like a lot of it.

I'm guessing that they were taught that code had to have comments and they were probably deducted points if they didn't have any. However, they weren't deducted points if they wrote bad comments and they weren't granted points if they wrote good comments. My guess is no one ever told them what the difference between a good comment and a bad comment was. So usually one of the first things I try to teach is what my guidelines for comments are.

1. Meta data is a bad substitute for good readable code
2. Write future proof comments. Don't write a summary comment that says what each step of your method will be. This is guaranteed to be out of date when someone else changes your method's code and forgets to update the comment. Now your comment is a lie.
3. Tell me what your methods, properties, or objects will accomplish for me. Don't tell me how to use them. I can determine how best to use it once I understand what it does.
4. Only current code matters, what the code did in the past is not important. Don't document history in your code files.
5. Add line comments if the line is confusing or needs clarification. If it's clear on it's own, don't clutter it up with a comment.
6. Break code into methods instead of using large or intricate commented sections.
7. The shorter the better
   

Two things drive all these guidelines:

1. The goal is readable code
2. Its better to read code than to read meta data
   

If your code isn't readable, you're going to be afraid to read it, and that's a problem because its better to read code than to read meta data (and comments are just meta data). Why? The meta data may be out of date, or it may not accurately represent the code. In the end, it doesn't matter what you think the code does, it matters what the code actually does. The best way to determine what it actually does? Read it. That doesn't mean you can get rid of all meta data, because you can't. But you can be very careful with what meta data you create and what content it contains.

The main purpose of summary comments is to clarify what code is meant to accomplish when the name may not be sufficiently self explanatory. This will help people (including you) figure out how they should use that code. If they want to really understand what it does, they'll have to read it, but if the summary and name are written well enough they should understand enough to take advantage of its functionality.

The main purpose of line comments is to clarify code that may be harder to understand for some reason. This could be to describe why something is necessary (like a hack). Or to explain the effect a line will have on a line somewhere else (like to cause a loop to break).

There are cases where you may need to not follow these guidelines, that's why they're guidelines. However, in most cases they've served me well and helped me produce cleaner and more easily understood code.

IEnumerable, not just for simple collections

In C# IEnumerable is what lets you say foreach( string s in someListOfStrings ) {}
In C# 2.0 you can create objects that can be enumerated over very easily using the very Ruby-like "yield return" keyword. Here's a dumb example:

private List strings;
public IEnumerable Strings
{
get
{
if ( strings == null ) yield break;
else
foreach( string s in strings )
yield return s;
}
}

The compiler will take care of all the magic of managing the state of your loops or recursion or whatever.

Pretend that the code above was in a class called ExampleStrings. I could write this code:

foreach( string s in exampleStrings.Strings ) {}

Like I said, that was a dumb example, but now you've seen an example of how easy it is to make something Enumerable. And because of how easy it is, I'm a big IEnumerable fan. I've found two cases where I really like to use it:

• When a library needs to return a bunch of "stuff" but doesn't know exactly how the consumer wants to use it
• When some non-trivial work needs to be performed to determine what the next element to be returned should be

Take the first one first. Suppose you're writing a library which needs to return the name of all the scanners attached to the computer. You could write this to return a List, but what if the consumer needs a DataTable? You'll build your list and return it, then the consumer will loop through your list and build a DataTable. If you return IEnumerable instead of List you make this O(n) instead of O(2n). You also delay whatever calls need to be made to find out what scanners are connected to when you actually start looping through them. That's because your IEnumerable code doesn't execute when the property is referenced. So in the following code a break point placed in the get of our Strings property wouldn't hit until the last line:

IEnumerable strings = exampleStrings.Strings;
if ( strings == null ) return;
List l = new List( strings );

So maybe O(n) vs O(2n) isn't that big of a deal. And the fact that you don't have to create a List object isn't too huge either. Its still nicer, cleaner, and totally easy to do though, so why not do it?

As usual, its the second bullet that really makes taking a look at IEnumerable worth while. I've used this pattern in two actual projects too. One I referenced in an early post, Fun With Circles. The other I've used when I was manually performing some data paging.

In fun with circles I used IEnumerable to abstract away the calculation that determined the Point where the next dot in my circle should go. That way I completely separated my drawing code from the math to determine where to draw.

In the data paging example I created an IEnumerable DataFetcher. All the consumer had to do was tell the DataFetcher where to start and what direction to go in (start, end, specific record ID and forward or backward) and then simply foreach through the resulting rows. When the consumer had enough rows to fill its page, it would simply break out of the loop. If the data source ran out of data first, then the loop would end on its own. With this in place the consumer was completely isolated from when the data was being retrieved and how it was being "stitched" together. This also made it incredibly easy to add new data fetching behavior to the DataFetcher class as needed. Then by simply setting a property on the class you could change its underlying behavior without the consumer updating any other lines of code.

Of course, IEnumerable isn't required for any of this. You can accomplish the same thing with a GetNext() method. IEnumerable just adds some very nice syntactic sugar to both the consumer's code and the source's code.

Windows PowerShell

If you haven't heard of PowerShell, its a windows command line shell which uses .NET objects for everything, and I'm a fan.

For example, in cmd or bash or whatever, when you type dir or ls you get a text display of a directory's contents. The command outputs formated text. In PowerShell if you type dir you get System.IO.DirectoryInfo and System.IO.FileInfo objects. That's right .NET objects. By default, those types get displayed to the screen in a table format. Wanna change how the output is formated? Pipe it to one of the format commands: dir | format-wide

There are three incredibly cool things here:

• The command outputs .NET objects
• The display is independent of the command
• The pipe command inputs .NET objects from one command to another

This is leaps and bounds better than any other command line shell I've ever used. You don't have to do a bunch of text manipulation to get at the information you want, just call the property. Or call a method. If it's .NET you can do it. And that means you can use your own .NET objects from the command line too. Also, you don't have to learn the formating behavior of many different commands. They're all consistent because they all output .NET objects which are formated with the three format-* commands.

If you've spent much time with a command line you should be starting to see how powerful this is. Here's an actual example. I needed to find out what file extensions people were putting into the document management application here at work. My first thought was to write a Ruby script that would iterate through all the files under a given directory (including subdirectories) and add the extension to an array (if it wasn't already added), then display the array to the command line. Pretty simple script.

Then I thought, I bet I could use PowerShell do this.

dir -recurse | select-object extension -unique

select-object is a command that pulls out a given property from an object. dir | select-object extension will show you the extension for every file in the current directory. Adding the -unique flag will remove duplicate extensions, showing you each extension exactly once.

I wont turn this into a PowerShell tutorial, for that you can refer to Scott Hanselman on PowerShell or just download it and read the documentation it comes with, which is actually quite good. Then start diving into the help, which is also quite good.

Personification in Software Design

When you're in a design meeting and people are throwing ideas around it's easy to get confused. People have this funny habit of not fully specifying their subjects. For example, "It wont store versions." What is "it"? The website? The application?

This really does happen all the time, it doesn't matter who you're talking to. Its really hard to avoid. When you're the one talking, you have a mental picture in your head. You're just trying to convert that to words so other people will see it too. But the people you're talking to don't have the same mental picture, so "it" could mean something completely different to them.

You're really trying to shape their mental picture to match yours while continuously updating yours to reflect theirs, so you have to be very specific until you can settle on some common terminology to represent that picture.

I like to use Personification to make this go smoother.

the attribution of a personal nature or character to inanimate objects or abstract notions, esp. as a rhetorical figure

I like to take this one step further and make the people I'm talking to represent the various components of the system. Person A is the database, person B is the website, person C is the application, and I'm the Document Management system. I've found that this works really well. Now I can say "You wont store versions, but I will" instead of "The website wont store versions, but the Document Management system in the application will."

Not only does this make the sentence shorter but it makes it easier for our mental models to jive and its funny. "Maybe you wouldn't have performance problems if you weren't written in Javascript!" See?

Keyboard follow-up

In Tools of the Trade: Keyboard I talked about the importance of keyboards as well as some of the models I was looking into.

Shortly after, I ventured out into the wild world of consumerism where I visited Micro Center, Circuit City, and Best Buy trying out the various keyboards. I decided to start with the Microsoft Natural Ergonomic Keyboard 4000. Turns out, that's where I'm going to end too. This is a fantastic keyboard.

It has one flaw: the space bar. If you push the space bar near the top, it gets kind of stuck. It's also the only key that's loud and "clack-y." I was able to get used to it, but it is less than ideal.

I was willing to get used to it because this keyboard has a lot going for it. Its most distinguishing feature is that it is raised from the back and slants down away from you. This is in contrast to most models which have feet in the back causing them to slant down toward you. Having it slant away is actually a lot more comfortable. I find that I rest the back of my hands on the wrist pad and allow my fingers to dangle down onto the keys. This seems to keep some of the stress off my wrists.



I also love the touch and spacing of the keys. They require more pressure and travel distance than some keyboards today, but not enough to make it annoying. Its a good balance.

I bought it from Micro Center. They sold me an OEM model that came in a simple brown unmarked box for half what Best Buy and Circuit City had it for.

Do It And Report Back

Object Oriented programming is simultaneously easy and hard. It's easy because when done right things have a way of just falling into place. It's hard because it can be difficult to know if you're doing it right until things don't fall into place...

This is a pattern I run into all the time: I want to write a class which will perform some routine. The routine will consist of many steps which have to follow a certain work flow. By putting all this behind a method call I can abstract the details of the work flow and how the steps are done. However, after all is said and done, I need to know what happened. When the method is simple this can often just be a single return value, GetString() returns a string. If it returns null, there was no string to get. But when your method has many steps to perform this can get more complicated. It may need to return different information depending on what happened. I need the method to report back more than just a single value, I need a status report.

Let's look at an example. Suppose you're given a file path and you want to "scrub" it. Pretend you want to make sure the file type is not on some list of "excluded" file types. Then, if it's a shortcut you want to resolve to the target path. If it's a folder you want to expand the folder into all its files. There is some non-trivial work to be done here and it could be used in multiple locations, so it would be nice to abstract the whole process into a single call.

If we do this it could report back with:

• File okay (file path)
• File excluded (file path, file type)
• Shortcut resolved (shortcut path, target path)
• Folder expanded (list of file paths, list of excluded files)

Here is how I've been coding this sort of thing (in C#):

public enum ScrubResultType
{
FileOkay, FileExcluded, ShortcutResolved, FolderExpanded
}

public abstract class ScrubResult
{
public ScrubResultType Type
{
get
{
if ( this is ScrubFileOkay )
return ScrubResultType.FileOkay;
else if ( this is ScrubFileExcluded )
return ScrubResultType.FileExcluded;
else if ( this is ScrubShortcutResolved )
return ScrubResultType.ShortcutResolved;
...
}
}

public abstract bool IsError { get; }
}

public class ScrubFileOkay : ScrubResult
{
public string FilePath;
public override bool IsError { get { return false; } }
}

public class ScrubFileExcluded : ScrubResult
{
public string FilePath;
public string FileType;
public override bool IsError { get { return true; } }
}

public class ScrubShortcutResolved : ScrubResult
{
public string ShortcutPath;
public string TargetPath;
public override bool IsError { get { return false; } }
}

public class ScrubFolderExpanded : ScrubResult
{
public string[] ExpandedPaths;
public string[] ExcludedFiles;
public string FolderPath;
public override bool IsError { get { return false; } }
}

I've defined an enumeration which contains all the possible "return types." Then because each return type might need to carry back different information I've used polymorphism to create a class for each possible return type. With a system like this in place I can write code as follows:

ScrubResult sr = FileScrubber.Scrub( "..." );
if ( sr.IsError )
{
if ( sr.Type == ScrubResultType.FileExcluded )
{
ScrubFileExcluded sfe = (ScrubFileExcluded)sr;
MessageBox.Show(
String.Format( "File {0} of type {1} is excluded",
sfe.FilePath, sfe.FileType ) );
}
}
else
{
// handle result based on type
}

This is an actual example of something I was seriously considering doing. I ended up deciding that the User implications of such a situation were scary enough to not warrant adding this. At least not for now.

When the return types don't have different information to carry back then the different classes aren't required and a single class with a "Type" property that returns an enumeration value is good enough. I have used the simpler version in code.

I like this pattern, but I've never really seen it anywhere. Have you seen it? Do you like it? Have you solved the same problem in a different way?

Happy Viming

In Programming Meets Editing I mentioned that my favorite editor is gVim, and that I was considering buying ViEmu so I could use the Vim input model inside Visual Studio. Today I finally got myself in gear and bought ViEmu and installed it at work.

ViEmu shoutout: Its impressive. It can't be easy to make Visual Studio play well with the Vim input model, but ViEmu manages it flawlessly. It even has a pretty smart method of managing Visual Studio's keybindings. If you want to go in and out of "ViEmu mode" it will disable and enable conflicting keybindings for you.

If you've ever been interested in learning Vim, the ViEmu developer Jon has created some really nice "graphical cheat sheets" that make learning Vim quite a bit easier. He has also written some good articles on why Vim is so nice: "Why, oh WHY..." and "The Vi input model". Those articles will sum it up better than I can, so I recommend you check them out if you're at all interested.

But that's not going to stop me from throwing in my own 2 cents. What makes Vim great?

• It is comfortable to use
• It lets you say what you want to do
  

Its comfortable because your fingers hardly ever have to leave the home row. Just the fact that you can move the cursor around with out moving your hand over to the arrow keys becomes really nice. I'm serious! It seems like such a minor thing, but after you've used it that way for awhile, going back will annoy you. Its like when you have a badly designed UI where you have to type in a text box, then move the mouse to select the next box, then type more, then move the mouse, then type more, etc.

Another example is the "t" and "f" keys which are like mini searches. "t" means to and "f" means find. Type "fa" and it will move your cursor to the next occurrence of the letter a on the current line. "ta" will move your cursor to right before the next occurrence. "T" and "F" go backwards. Again this is nice because it replaces a string of keyboard actions that might look like "ctl+right,ctl+right,right,right,right" Not only is that simply more keystrokes, it also requires you to move your hands around and perform some control key acrobatics.

Both of these examples demonstrate how Vim is comfortable. The second also demonstrates how it lets me say what I mean. Instead of using a combination of meaningless movement keys to get to the letter a, I said "go to a." At first blush this doesn't seem like it would matter, but as the Vim commands become second nature you can start talking to your editor at a much higher level without thinking about it.

It lets you stay focused on what you're trying to do to the text and not how to do it.

Its important to note that these are just the simplest examples I could think of. Vim has A LOT more to offer. Its also important to answer this question: will it make you more productive? Maybe, I don't know, its hard to say. Does it matter? If it makes you more comfortable and less irritated (ctl+right,ctl+right,ctl+right,ctl+right,ctl+right...), isn't that good enough? After all, I'm going to guess you spend a lot of time typing into that editor of yours.

Finally, if you're interested in giving Vim a shot I would certainly encourage it. It does have a pretty steep learning curve, but the cool thing is you can still do all the "notepad" style editing things you're used to. So you can learn it at whatever pace you want to, one feature at a time. If you're in Visual Studio, ViEmu has a 30 day trial. If you're in Eclipse, there is a Vi plugin. And if you're just editing text there's always gVim.

To Estimate or Not To Estimate

I have recently been spending a lot of time with two different "project management" applications: FogBugz and Team Foundation Server. FogBugz originally attracted my attention because I read Joel Spolsky's blog, Joel on Software, and he's the CEO of Fog Creek Software which makes FogBugz. TFS attracted my attention because it includes a new Source Control system which is a-w-a-y better than Visual Source Safe. I have been evaluating these products and trying to figure out which I'd rather use, its a harder task than it sounds.

The new version of FogBugz, 6.0, mainly consists of Evidence Based Scheduling. I have to be totally honest and say that EBS is not only very cool but makes total sense and I believe it would totally work. However it requires two things: 1) time tracking and 2) work item estimates.

Joel Spolsky recommends keeping your estimates under 16 hours, anything longer than that doesn't stand a chance of being accurate. That means you need a lot of very detailed tasks entered in the system (ex: develop function foo). Once you have estimates at this level you can start to get good predictions of when you'll ship AND you can start to pick and choose what tasks you want to do based on how much time you have left.

TFS doesn't really have any scheduling. It has Remaining Work and Completed Work fields (but only on the Task work item type, not on the Bug work item type...), but no reporting, no nice views, and no nice way to enter time (you have to subtract from the remaining work field manually when you add Completed Work...). The TFS developers seem unconvinced that estimating work at the level Joel recommends is at all worth while. Witness these articles on the Teams WIT Tools blog.

Personally I think estimating how long a task will take is a great idea. I think creating a list of tasks at that detailed level would not only help a developer think through what they're going to do before they dive into it but also help them get an idea of "where they're at" with all their work. I think it would make managing work loads a lot easier too. Not to mention the fact that the ship date estimates would make it possible for you to determine when your initial "blind" estimates were wrong or when scope creep is starting to get the best of you.

My question for all of you is, what do you do at your work? It doesn't even have to be programming work. Do you estimate work? At the detailed task level, or at a more abstract level? Is it helpful? And if you don't estimate work, do you wish you did?

UPDATE: I've posted a follow up post, Managing Projects

Use that computer!

If you're like me, you don't like Windows XP's start menu. You might like the pinning and the recently used programs section, but you despise the popout hierarchical menus. You also dislike the desktop, and find it more or less useless, much like Coding Horror says. I also wouldn't be surprised to hear that you really don't like the task bar, and find it so cluttered that you obsessively open and close all your windows all day long so that you never have more than 3 or 4 open at the same time.

This is where you may start to be a little less like me. I have searched for alternative UIs for launching programs and managing currently open programs for years. The list of things I have tried includes: Ashton Shell Replacement (win), KDE (linux), GNOME (linux), Enlightenment (linux), IceWM (linux), Xfce (linux), Fluxbox (linux), Symphony OS (linux), Rocket dock (win), Top Desk (win). At some point or another, for some reason or another, I gave up on all of those.

Here's my current setup: Launchy for launching programs and Task Switch XP for switching between running programs.

Launchy:


Task Switch XP:


Launchy runs in the background and is called forward with a configurable keyboard shortcut. I bind mine to alt + q. To use it you just type the name of whatever program you want to run. If that program is buried somewhere in your start menu, launchy will find it. The best part about launchy is that it learns. So if you have 4 programs that start with the letter "f," the first time you type f you'll see all 4 programs in the drop down. If you go ahead and type more letters so that it narrows the selection, "fire", it will select firefox and you can hit enter to launch the program. Next time you type "f", firefox will be the default suggestion.

Mine has trained itself so that this is all I need to type now:
f -> firefox
th -> thunderbird
v -> visual studio
wo -> microsoft word
ie -> internet explorer
sq -> sql management studio
gv -> gvim
cmd -> command line
not -> notepad
tom -> tomboy

The best part of that is that you're not memorizing some weird keyboard shortcut, you're just typing the name of the program you want, and boom, it figures out what you mean before you've even finished typing the full name.

Task Switch XP binds itself to alt + tab by default. It displays your running programs in a vertical list (must nicer than the horizontal list of the task bar) and includes screenshots of each program (much like tweak UI). However, where Task Switch XP sets itself apart is its "sticky" mode (in the configuration utility go to Hotkeys and check "Enable Alt-Tab 'sticky' mode"). With this turned on the window wont close when you release the "alt" key. This means you can call the window forward with alt + tab, then use the arrow keys, or the up/down keys, or the mouse, or the scroll wheel to select the program you want. I even have a button on my mouse configured to bring the dialog forward so I can switch windows without even using the keyboard. This is great because this dialog can support many more open windows before it starts to become cluttered than the Task Bar can.

So Launchy replaces the start menu and Task Switch XP replaces the task bar... As such, I've now configured my task bar to auto-hide.

The only thing I don't have here is the ability to type the name of a currently running program in Task Switch XP and have it filter down the list for me. I'd love to be able to do: "alt+tab fire" and have only firefox windows in the list, but Task Switch XP doesn't have this feature. I have written a program that will do this, but I haven't finished making it pretty yet. Alternatively, I may pull down the Task Switch XP source code and see if I could add the feature I want to it.

Do you use any interesting application management utilities?

Programming meets Editing

Editing text is a significant part of programming. Sure, you spend a lot of time thinking, and a lot of time scribbling on paper and white boards. But you do a ton of editing as well. The only way you can get out of editing is by getting out of programming.

It is interesting that, though editing is such a large part of programming, it is relatively ignored. In my Tools of the Trade: Keyboard post I pointed out that having a comfortable keyboard seems like it should be important given how much typing a programmer does. Along those same lines, it seems like having a good editor should be just as important, if not more so.

I think there are two kinds of programmers, those who have a favorite editor, and those who have never bothered to think about it. Most of the best programmers I know have spent a fair amount of time experimenting with different editors. As usual, wasting time messing with editors doesn't make you a good programmer, and I've known some extremely good programmers who never thought twice about it. On the other hand, generally the people who take the time to think about things like text editors are also the people who think about things like writing good code. I even think that would be a good interview question, "Do you have a favorite text editor?" You could learn a surprising amount about a person's background and actual coding experience through that question.

My favorite editor is Vim, gVim actually. I started editing in the Quick C DOS editor. Then later I used the Zeus editor. Then I stumbled on Vim. And of course, Visual Studio. I had friends in school who used UltraEdit, and recently I've read a lot of hype around Text Mate and the windows clone, E Text Editor. I have never personally used Emacs. I took some time to read about it not long ago, but I've never gone so far as to install it and spend time with it. I tried jEdit for a short period of time, but gave up on it because it took too long to start up.

In the search for an editor I find myself trying to figure out exactly what it is I'm looking for. What makes a good text editor. I think these factors are part of it:

• Expressivity
  How much can I say and how well can I say it? Ultimately I want to be able to express at a high level what I want to have happen to the text.
  
• Composability
  Are there a series of flexible commands which can be combined to perform more complicated operations?
  
• Psychic ability
  Does the editor know what I'm doing and help me do it by abstracting out the tedious details? For example, Intellisense, snippets, and auto word completion.
  
• Comfort
  Can I type commands easily, or am I performing acrobatic arts with my fingers on the keyboard?
  
• Speed
  Is it faster than editing in Notepad?
• Keeps me oriented
  Keeps me from getting lost in my files and directories

Interestingly these really divide into two categories, you have the strictly text manipulation issues such as speed, comfort, and expressivity. Then you have the more "management" and domain specific issues such as psychic ability and keeping you oriented. Vim is very good at the text manipulation parts, but weak in the management parts. Visual Studio on the other hand is very strong in the management parts.

Visual Studio with Intellisense and re-sharper's background compilation really is wonderful. Add the solution explorer to that and life is pretty good. I wouldn't use an editor that didn't have those features knowing that they exist in Visual Studio. Thus at work I use Visual Studio and not gVim.

Because of this I think I'm going to spring for a ViEmu license. I've used it for the trial period twice now, once on my old computer, once on my new computer. Each time I love having it, but its pricey so I haven't committed yet.

What editor do you use? What editor do you wish you could use?

The Fear of Doing

For a long time I suffered from the relatively common ailment of "The Fear of Doing." The symptoms can vary dramatically and change over time, but the root cause is the same.

I would come up with an idea, maybe for a piece of software, and I would design it and all its abstract elements. I would get right up to the point where I needed to write some code, or research a technology, or look up an api. Then I would stop.

Or, other times, I would be annoyed by something. Maybe something about Windows, like how hard it is to switch between windows, or how hard it is to start a program. Or it could be something in Visual Studio, like how the shortcut keys aren't setup right, or how there's no good way to find a file in a solution. In these cases I would complain about how annoying it all is, and grudgingly go back to dealing with it.

Or, on a few other occasions, I would be interested in something. Like what mechanisms .NET has for parsing XML. Or how the Ruby language differs from the C based languages. Or if one keyboard might be more comfortable to type on than another. When my interest would peak in these cases I would think to myself, "That would be interesting to learn," and then I would go watch TV.

Or, in exceptional circumstances, I might even wonder about things that don't have anything to do with computers or programming! It does happen every now and then. But I'd usually end up leaving my activities at wonderment.

In all of these cases I was willing to think about, or be interested in, or wonder about things right up until the point when I would actually be required to go learn something. Actually, these are bad examples because these are, in reality, examples of things I did actually go learn something about. But not surprisingly, all the stuff I may have thought about but not bothered to learn about... I can't remember anymore, so I couldn't use them as examples.

I should mention early on that thinking about stuff and not "going and learning" isn't necessarily bad. In fact, its quite a bit better than thinking about nothing. Especially because you may very well learn stuff in the process of thinking. Truth be told, some of the best learning occurs when you learn from yourself rather then by "going and learning." However, there are a few things that simply can't be learned that way. And there are many other things that wont be learned that way efficiently.

That being said, there is only so much you can learn by just abstractly thinking about things. Eventually you just have to do something. However, it can be hard to convince yourself that its worth the time it will take to do something. You can always come up with reasons why you shouldn't do something: you might fail, you might get half way through and lose interest, you might start only to find out someone else beat you to the punch and has already done it, it might turn out to be a bad idea, you might finish it and then never use it... The list goes on.

I call this "The Fear of Doing." For me, I credit a project I called BoxVue as one of the first times I got over this. BoxVue was a Konfabulator, I mean Yahoo Widgets, widget that allowed you to organize programs, files, directories, shortcuts, or whatever into groups. Then you could click on the items in the groups, or use the search capability to launch the item with the keyboard. Basically, it was my version of the Windows start menu without the hierarchical pop up menus and with a convenient search. I wrote it because I'd never liked the start menu, never found a nice replacement app, and I was very interested in Konfabulator's programming model (which is a combination of declarative XML and Javascript). I spent quite a while in Photoshop creating the graphics and gVim looking at other widget's code and writing Javascript. I ended up with a product I was quite happy with and I used it for about a month. Then I discovered the Gnome Main Menu in SLED 10 and learned that XP's "pin to start menu" feature was actually pretty nice (I had always turned off the XP start menu and used the old style one) and I completely stopped using BoxVue.

This was one of the first times I'd actually taken the time to learn a new technology and develop a full application with it. And it resulted in failure, more or less. You would think this would only have reinforced my "Fear of Doing," but instead it set me straight. Although I no longer use BoxVue, I learned a ton of stuff from writing it that I do use today. First of all, I learned Javascript is a real language, and an awesome one at that, and I now understand what a "prototype" language is. I also got some decent exposure to a declarative UI style of programming. Shortly after I finished BoxVue, Microsoft starting talking about WPF and Xaml, which we have been looking into at work and which is a declarative UI style of programming, so that was a nice leg up.

Ever since then, every time I've taken the time to do something, its always benefited me later in more ways than I could have predicted before I started. Always.

So what I learned is, even if the "project" fails, the time I invest is totally worth it because it helps me get smarter and get more things done.

Tools of the Trade: Keyboard

As a programmer you spend at least 8 hours a day in front of a keyboard doing a lot of typing. Typing code, emails, design documents, blog posts… That’s a lot of key strokes. So it seems logical that having a good keyboard would be important.

About 6 years ago I shopped around for and bought my first “non-included with the computer keyboard”, a Logitech Cordless Freedom Pro. I still have and use that keyboard at home. However, at work I use the keyboard that came with my computer, a Dell keyboard. Now I’m wondering, since it’s been about 6 years since I last shopped around for a keyboard, if I should take another look.

Of course, the problem is deciding what defines a good keyboard. And also taking the time to actually go select one for yourself instead of settling for whatever came with your computer.

First feature: Ergonomic Design. The options here seem to be classic, split, curve, wave, and crazy (and crazier). Some people swear by the split design while other people either find it annoying or too hard to use. Personally I think I like it, but I’ve never been able to conclusively determine if it really made that much of a difference.

Second feature: Tactile Feel. My dad learned how to type on a type writer, so he prefers a touch that has some real resistance and some pretty long travel distance. He uses an Avant Stellar. However, most keyboards these days are soft and quiet by comparison. My favorite keyboard in terms of tactile feel is the keyboard on my IBMLenovo T60p. It has a very satisfying feel, not too light and not mushy. On the other hand, it’s light enough that I feel I can still "fly over the keys." And the last big point is that it’s quiet. I’m a pretty heavy typist so having a quiet keyboard is important so I don’t annoy everyone around me too much…

Third feature: Accessible Keys. Programmers use the home, end, delete, page up, and page down keys a lot, so it’s important that they’re easy to use. This can actually be kind of hard to find. I’ve seen keyboards where you have to press and hold a function key to use Home and End! On other keyboards that cluster of keys can be “mangled.” My Logitech Cordless Freedom Pro is mangled. I was able to get used it to pretty quickly, but it is definitely a less than ideal arrangement. Another really important key is the control key. The Avant Stellar keyboard swaps the Control key and the Caps lock key by default. I’m a huge fan of this arrangement, so much so that I modified my Windows registry to swap the keys for me on a regular keyboard. I’ll talk more about why I like this arrangement so much in a later post.

Standard Layout

Micosoft Mangled Layout

Logitech Mangled Layout


Fourth feature: Cordless. In college I was very happy I had a cordless keyboard. I would carry it over to my bed with me when I was studying to control Winamp or I’d put it in my lap while I was writing a paper. However, at work, I’ve never felt the need to move my keyboard at all.

Taking all these factors into account I’ve limited my options to the following keyboards:
- My Dell keyboard
- My Logitech Cordless Freedom Pro
- Microsoft’s Ergonomic Desktop 7000
- Logitech’s Cordless Desktop Comfort Laser
- Logitech’s Cordless Desktop Wave

The Dell has very nice tactile feel, not quite as nice as the Lenovo T60p’s keyboard, but I like it. Not only that, but if you watch the credits at the end of this demo of Fogcreek’s Fogbugz you’ll see that the majority of the developer’s pictured with keyboards are using the Dell… interesting.

When it comes to my old Logitech, I’ve simply always been happy with it. I’m completely unsure if the new Desktop Comfort version is any different other than the color and the wrist rest.

Microsoft’s keyboard looks great. It’s non-mangled and split. I have to try to find this one at the store to see how I like its feel.

The Wave is completely different if nothing else. I haven’t had a chance to actually type on it, so I really can’t say anything affirmative about it.

The last question to be answered is, do any of these features really matter? What keyboards do you use? Do you think the ergonomic designs really make a difference? Are they really more comfortable to type on?

Where is UserControl.Text?

Creating UserControls is a very simple process from a high level. But as usual, the devil is in the details. Recently I was going through many of our controls here at work when I noticed that they were all using the “new” keyword to override the BackColor and Text properties. Somehow we’d managed to get by without this causing any problems until now. To correct this I had to override the OnBackColorChanged and OnTextChanged virtual methods.

After this was done I noticed that the Text property was no longer visible in intellisense for any of our UserControls. After looking closer at the object model I learned that UserControl inherits from Control which contains the Text property. So how come I couldn’t see the Text property? You can’t remove properties through inheritance.

It turns out there is a special designer attribute called System.ComponentModel.EditorBrowsableAttribute. This attribute can be placed on a property or method to determine change the visibility of that property or method in the designer. The possible visibility values (EditorBrowsableState) are Never, Advanced, and Always.

UserControl marks the Text property with EditorBrowsable( EditorBrowsableState.Never ).

I have no idea why Microsoft did this. I imagine there is some strange way of thinking which makes it make sense, but I haven’t figured it out yet.

To work around this, I had to override the Text property on a base class that all of our UserControls inherit from. Fortunately we already had a base class, otherwise I would have been forced to create one just so we could use the Text property correctly.

And for the record, yes, the Text property can be overridden. Why was it using the “new” keyword in the first place you ask? I don’t know. I think because whoever wrote the controls just didn’t know it was a virtual property.