Robert Tennyson

Recently I had a discussion with a colleague at work about a way to speak to future developers that join or take over our projects. The idea was that we could simply add a "developer's note" to the solution items so it would live with the rest of the code in source control. I personally couldn't think of a better place for a piece of documentation like this.

After our discussion he spent some time and mocked up a sample developer's note and sent it my way. The idea was that I would customize it to suit me because we came to the conclusion that these developer notes should be a bit personal and should come from the lead developer of the project in question and I happen to be the lead developer on this specific project. All good so far, but in the mock up he include a brief introduction that initially stated his (or a made up) personal development philosophy. Excellent idea I thought. As I started to write my personal philosophy I realized that I didn't have one! I kept writing different things I thought were good ideas only to delete them after thinking that they were just good ideas but didn't really make a very good philosophy. It dawned on me that I have never really sat down to define for myself what I truly believe is a good developer or what makes a good developer or what makes for a good development philosophy. I didn't have a personal mission statement, if you will.

So the research and soul searching began... and this is what I found and the conclusion I came to.

First, some nuggets I found while doing a bit of googling:
Hallmarks of a great developer
Why I’m a better software developer than you
Why Good Programmers Are Lazy and Dumb
How To Become a Better Programmer by Not Programming
Skill Disparities in Programming

The last two are especially good ones. Well, everything from Coding Horror is awesome in my opinion!

No then, where does all of this leave me? After reading those articles and many others, and after doing a ton of plain old soul searching, I think this should do it:

My personal development philosophy is simple: strive to accomplish the task at hand as well as you can given your current skill set and always strive to improve your skill set.

Now that I look at it, it seems more like a personal philosophy towards life rather than specifically a development philosophy. It also isn't a statement that would help a developer understand the code-base s/he was about to dive into. I guess I'll keep pondering and researching...

• Share This Post:
• 
• 
• 

This is just a quick follow up to my Mocking with Rhino Mocks post.

You can see the entire thread here, but the essence of it is this.

DynamicMock creates a mock where all unexpected calls are ignored with no error. So, if we were to create a dynamic mock and then set an expectation that a method on it is called twice, there would be a requirement for two calls, but a third cal would just be ignored rather than cause an error.

If we absolutely want the behavior of an exact number of calls, then use CreateMock instead of DynamicMock. Nice and simple solution :)

• Share This Post:
• 
• 
• 

Ok, myself and a couple of colleagues spent a ton of time today scratching our heads because of an odd behavior in Rhino Mocks. Basically, we set an expectation, set the expectation to repeat only once, and then were surprised to see a passing test when we knew the actual code was calling the expectation too many times. So we created the below example. The test in the example should fail, but it passes.

using NUnit.Framework;
using Rhino.Mocks;

namespace UnitTests
{
   public interface IMyTestInterface
   {
      void MyTestMethod();
   }

   [TestFixture]
   public class RepeatTests
   {
      [Test]
      public void Test()
      {
         var mockery = new MockRepository();
         var myMock = mockery.DynamicMock<IMyTestInterface>();

         using (mockery.Record())
         {
            myMock.MyTestMethod();
            LastCall.Repeat.Once();
         }
         using (mockery.Playback())
         {
            myMock.MyTestMethod();
            myMock.MyTestMethod();
         }
      }
   }
}

Now to do some searching and querying to figure out what we're doing wrong.

• Share This Post:
• 
• 
• 

I've really been wanting to get deeper into BDD, but I'm having trouble getting the opportunity at work. I think it's a combination of two primary problems (I'm sure there are others as well though). First, it has been freaking ages since I've been present at the very beginning of a project. It seems like I'm always pulled in well after development has started which means well after project style and architecture have been established. Second, my company still hasn't made the shift to Agile practices. The word is starting to be tossed around quite a bit, but we're still primarily a big up front design kind of shop. This is affecting my ability to do BDD because of the first problem - if I'm not there in the beginning to sway the way things are done, then you can bet that by the time I'm there a ton of analysis will have been done and I'll have a pile of functional specs waiting for me.

Now then, I do, despite all of this, do my best to take the functional specs that I'm given and turn them into well formed behavior driven style unit tests.  The problem is that I'm still very new to it and completely suck. On top of that, I'm expected to teach others at the same time (yes, the blind leading the blind). So I need practice. That's where this post comes in. I thought I'd come up with a bunch of quick and easy side projects where I could experience the entire development life cycle. It didn't take very long at all to get stuck trying to figure out what the next step would be if this were a real project at work. I could of course dig in and just get it done, but I'm much more interested in the process than I am the product at this point (otherwise I would have written these apps years ago!). Enough chatter though, on with something interesting...

Powerball Management

This is the first app that I could think of. I've played the same lotto numbers for years and still after all this time go out and check manually every drawing. So, I thought I'd automate that. Below are the requirements that I could think of written in the "As a, I want, So that" style.

Now this is where I'm stuck. This doesn't seem to me enough information to get started, but acting as the end user, I can't think of anything else I want to say about it.

The initial requirements:

• As a player
  I want to be notified of whether or not I've won after every drawing 
  So that I don't have to check manually
• As a player
  I want to know how much I've won if I did win
  So that I'm not curious and have to go check manually
• As a player
  I want to be notified when I need a new ticket
  So that I don't have to remember
• As a player
  I don't want to have to re-type numbers on new tickets if they're the same
  So that I can save time

I'm going to elicit a bit of help on this and will definitely do a fair bit of reading. I'll post my progress and a link to where I end up putting the code.

Happy coding!

• Share This Post:
• 
• 
• 

I wanted to capture this in case I ever find myself trying to present this concept again and am failing to come up with a simple example that works. It's about exception handling in C#. I've known about this issue for quite some time and tried to present the problem to an internal user group where I work. Unfortunately the example I came up with didn't provide the expected result and we spent the whole presentation floundering around with the damn thing. Kudos to a buddy of mine for taking the time one weekend to come up with this working version (Thanks Paul).

Basically, when you catch exceptions, the way you re-throw them has a very important impact on the stack trace of the exception when it is caught later. Below is the code in its entirety. I'm mostly putting it here for reference, but would be glad to answer any questions you may have.

using System;

namespace ThrowSpike
{
   class Program
   {
      static void Main()
      {
         try
         {
            Console.WriteLine("ThrowOnly...");
            ThrowOnly();
         }
         catch (Exception ex)
         {
            Console.WriteLine(ex); // See a good stack trace
         }

         try
         {
            Console.WriteLine("ThrowCaughtException...");
            ThrowCaughtException();
         }
         catch (Exception ex)
         {
            Console.WriteLine(ex); // See an bad stack trace
         }
      }

      private static void ThrowOnly()
      {
         try
         {
            ThrowException();
         }
         catch
         {
            throw;
         }
      }

      private static void ThrowCaughtException()
      {
         try
         {
            ThrowException();
         }
         catch (Exception ex)
         {
            throw ex;
         }
      }

      private static void ThrowException()
      {
         throw new ApplicationException("This is a test");
      }
   }
}

• Share This Post:
• 
• 
• 

Welcome,

I thought I'd use my first post to set expectations. This is as much for my benefit as it is for anyone who might stumble across my blog.  It's amazing how the act of writing something down really forces us to solidify the idea.

My current intention for this blog is to use it as a place to occasionally come and capture some kind of thought that I either want to share or remember.  Either way, I want that thought to be available to anyone who might also be interested.

The funny thing right now (as I'm writing this) is how many versions of that sentence I've gone through.  I kind of wish I had kept them all!  I would capture an intention and start writing a bit about it to kind of further or clarify it.  Then I would realize that I could just alter the sentence and not need the clarification.

I would like to draw attention to two specific points in the intention though:

"My current intention..."

That means exactly what it says – current.  This may be what I was thinking going in, but there's nothing that says my focus won't completely shift at some point.  I would expect, however, for it to remain fairly consistent as this seems to me a reasonable intention for one's blog.  The main thing that might change is the next thing.

"... occasionally ..."

I don't currently have any intention of regularly updating the blog.  It seems like many people have a metric they shoot for like X number of posts per month or week or something.  I only intend to use this is a medium for capturing thoughts that I want to share or remember.  And that's only the thoughts that I feel strongly enough about to take the time to write them down in some kind of meaningful manner.  I have a lot of trouble with time management currently between family, career, gaming (WoW currently), and reading.  I really don't want to add an additional item to the mix right now.  There's something to be said for "Quality over Quantity" and I seem to be walking a fine line between the two already – mostly because of the gaming is my thought.

Well, that's it for now.  I feel like writing this post was a great start because it really caused me to nail down my thoughts around why I bothered to create a blog and what I hope to get out of it.

Happy coding!

• Share This Post:
• 
• 
•