Caffeinated Coder

It’s been a few weeks since I’ve taken the Jean-Paul Boodhoo’s Nothin’ But .NET training course and I’ve had enough time and recuperate and reflect more on the experience.

Although I really enjoyed the course and am glad I took it, it seems wrong to just give a blanket endorsement of the course.

I just don’t think that any training course can or should even try to be well suited for every type of person.

With that in mind, I tried to come up with a few helpful criteria to help someone who is thinking of taking the course make their decision.

You may want to take the course if…

1. You are somewhat comfortable with 3.5 .NET syntax, but really want to geek out on Predicates, Actions, Funcs, and the angle bracket cesspool where they intersect with Generics.
2. You like using natural language API’s like Fluent NHibernate and are curious about how to construct an internal DSL of your own.
3. You are a Test Driven Development fanboy, but are looking for cleaner and more innovative ways of writing maintainable tests.
4. You think design patterns are just swell and wouldn’t dream of writing a Hello World app without at least a dozen classes, but would like to see these principals in practice by someone who really knows his stuff.
5. You prefer a code-centric approach to learning and want to spend most of your time either coding or watching someone else code rather than simply listening to concept-laden lectures.
6. You wouldn’t mind a little motivational kick in the butt.

You may want to run away screaming from the course if…

1. You don’t due well with sleep deprivation.
2. You are deeply cynical and motivational tangents cause you physical pain.
3. You view design as hopelessly subjective and are fast to dismiss any additional layers of indirection as over-engineering.
4. Although you might be interested in learning how to use MVC Frameworks and IoC Containers, the thought of creating your own implementations as a learning exercise seems downright ludicrous to you.
5. You are NOT someone who is ‘convention promiscuous’ and the thought of doing things like naming_methods_with_underscores immediately sends you into Rain Man mode.
6. You get frustrated easily whenever you don’t immediately understand what is going on. JP is of the ‘push yourself past your limits’ and ‘learn by immersion’ school of thought when it comes to teaching. Unless you are in the top 5-10% of programmers, you’re probably going to feel pretty lost at various points of the course. If you are someone who can’t deal well with that feeling, then this course is probably not be for you.

Great Big Fat Disclaimer – I get the feeling that the content of JP’s courses tends to change pretty dramatically from month to month. This is a testament to his own talent and discipline when it comes to being a continual learner. However, it also means that you should probably take characterizations of the course (like this one) with a grain of salt.

Some Essential Preparation Tips For Those Crazy Enough to Take It- For those of you that have decided to take the plunge and sign up for a future Nothin But .NET course, I highly recommend that you take the course preparation seriously. At the very least, you should do the following:

1. Watch all of his DNR TV design videos – JP demonstrates design principals continually throughout the course, but doesn’t really take the time to explain them up front. It is helpful if you have a good grounding in these to begin with.
2. Learn and Practice R# short-cuts – JP is a true ReSharper Jedi and therefore his coding demonstrations can be hard to keep up with if your brain isn’t already used to taking the mental shortcuts that R# allows you to take.
3. Practice using his BDD Library Extensions – I feel pretty comfortable with TDD and am used to BDD-style naming conventions, but the fluent interface style BDD library that JP wrote and uses in the course through me for a loop at first. I wish I would have taken the time to get used to it more before the course.
4. Sleep extra the week before the course and consider staying in the hotel even if you are local – In the words of a good friend of mine, “No amount of Starbucks makes you smart at 2:00 am”, at least not after 17 straight hours of intense training. It didn’t help that I only got a few hours of sleep the first night because of a sick baby at home, but I definitely would have been better off if I had tried to get extra sleep the week before.

That’s my two cents.

Any alumni out there want to offer a dissenting opinion?

Popularity: 1% [?]

What are Subversion hooks and why would you use them?

Hooks are extension points that allow you to add behavior at various stages of the commit process through an executable file.

The most useful one is the probably the pre-commit hook because it allows you to prevent a commit from occurring, thus providing a way to enforce whatever policies that can dream up to help your development process run more smoothly.

We use it to ensure that developers enter a valid Jira key into the commit notes, which is a crucial step in making our code review process as painless as possible.

How do pre-commit hooks work?

All you have to do is create a console application or script named pre-commit and copy it in the hooks directory of your repository. Subversion will automatically execute any application following this convention before each commit.

The repository path and transaction id associated with the commit will be passed in as the first two arguments, thus allowing you to look up relevant information about the revision before making the decision about whether or not to allow the commit to occur.

To prevent the commit from happening, all you have to do is exit with a ‘1′. You can even display an explanatory message to the user (at least in TortoiseSVN) by writing to Console.Error.

Using SharpSVN to Avoiding Command Line Parsing Hell

During my first attempt at implementing a hook, I programmatically spawned a process and executed svnlook.exe to extract the information I needed about the revision.

This worked fine for simple cases, but quickly began to require some serious Command Line Parsing-Fu in order to accomplish what I wanted. At that point my “There-has-to-be-an-easier-way” alarm went off in my head, so I began to search around for a pre-built API to simplify the task.

I soon found SharpSVN, a stable open source project that is used by AnkhSVN and SharpDevelop.

Aside from a few annoying testability issues that forced me to create wrapper classes in order to do unit testing, I had a good experience with the framework and would definitely recommend it over rolling your own.

Integrating with Jira

Jira exposes a large portion of their functionality through web services that you can access by simply turning the “Accept Remote API calls” option on in the General Configuration area of the administration page.

We use the key parsed from the comment to query the Jira web service and verify that the referenced issue is in an opened state and has a fix version that has not already been released.

Downloading the Code

I zipped up a sanitized version of our pre-commit hook that you can download and either use as a learning sample or modify for your own use.

Popularity: 3% [?]

As part of the Nothin But .Net training experience, JP Boodhoo encouraged us to try out a few non-standard naming conventions that has adopted recently.

The one that intrigued me the most was his convention for naming interfaces.

Rather than taking the Microsoft sanctioned approach of adding an I prefix to all interface names, JP adopted the convention used in the Java world of reserving the unadorned name for the interfaces and instead adding an Impl suffix to the end of the concrete classes that implement the interface.

Actually, this was actually not the first time I’ve been exposed to this convention.

I have a vague recollection of Dru Sellers making a similar case for using this convention a few years ago when I worked with him. However it didn’t make nearly as much of an impression on me at that time because I wasn’t in the habit of using interfaces except when I wanted to achieve polymorphic behavior and I had already used up my base class.

Since then I started using interfaces for almost everything except entity classes. I first went down that path out of necessity because it was a requirement of Rhino.Mocks, but after I started reading about the SOLID principals and getting a better understanding of the benefits of loose coupling I adopted the approach as a de facto design guideline.

Now that interfaces play a much more central role in my code, it makes perfect sense to me that they should take precedence over concrete types when striving to create names that make my types more readable.

It also strikes me as odd that the naming standard for interfaces is clearly a vestige of the days when Hungarian notation (e.g. strName, intAge) ruled supreme. If Microsoft actively discourages the use of Hungarian notation in the case of every other type, then why should this one be any different?

When I first considered the possibility of going against the Microsoft standard, I worried about the confusion it would cause for future developers.

However, my experience in the course was that it was only confusing for the first day and then I actually grew to like it once I internalized the convention and started relying more on my color scheme of my IDE to immediately distinguish interfaces from classes.

I especially liked how the new convention served as a constant reminder of the central role that interfaces should play in my design.

Is anyone else out there using this convention?

Is it folly to swim against the stream in this regard?

Popularity: 4% [?]

Here’s a fun productivity enhancing tip that I picked up from JP at the Nothin But Net course I just took.

If you’re much of a gamer, then Typing of the Dead, an old Sega game that was released in 1999, will probably make you wince due to the poor graphics and absurd storyline. In fact, it appears to have won the dubious honor of being runner up in one of PC World’s top 10 worst games list.

Nevertheless, I’m hooked.

It could be because I’m one of the only men under 40 that I know who doesn’t own a gaming system and therefore have incredibly low standards when it comes to games. In fact, the last one I remember owning was an Atari back in High School.

It might just be because I have a soft spot in my heart for zombies every since I read World War Z: An Oral History of the Zombie War.

Whatever the reason, I’ve been dismembering hoards of zombies in the last week and hopefully increasing my typing speed in the process.

If you’ve already mastered a tool like ReSharper and are looking to eek out some more productivity by simply increasing your typing speed, then I recommend downloading a copy of the game here and giving it a try. It installs through a simple setup bat file.

It is no longer being sold, so there is no need to worry about pesky copyright laws.

Happy typing.

Popularity: 2% [?]

This is a screenshot of my current desktop.

I exported a snapshot from the ReSharper Default Keymap pdf and set it as my desktop background. I got the idea from Jean-Paul Boodhoo when I asked him how he had become so proficient at using ReSharper.

Popularity: 2% [?]

I woke up this morning in a semi-zombie state and just learned that tonight will be our “late night”, which means we’ll go until 2 or 3 am instead of midnight. Nevertheless, I’m still enjoying the course.

Here’s some thoughts about the second day of the course (yesterday).

1. Actions, Predicates, and Funcs…Oh My - We started the day with a wrap up of all the work we did with delegates from day one. This is when the lightbulb finally went off in my head on the differences between the Actions, Predicates, and Funcs types. They are just convenience wrappers for delegates with different signatures. If you need to pass around a method that returns a bool, then you’ll want to use a Predicate (filtering & matching). If you just need to store a void method, then pick Action. Otherwise, if you’re working with a method that returns a value, then Func is what you’ll need.
2. Imitate, Assimilate, Innovate – This is a model that represents the stages of learning. I realized that I spend too much time in the imitate stage (adapting googled code) and almost no time in the innovate stage. One of the first goals I selected for myself this week is to spend more time in the innovate stage. A long term goal is to eventually launch an open source project. Kudos to Dru and Rob, two former co-workers, who took this step already.
3. JP’s BDD framework – This is a fluent interface that replaces test attributes, asserts, and obscure mocking API’s with more a fluent interface that reads more like an English sentence. It disoriented me for a while, but the syntax is starting to grow on me after a few days of using it. Check out this post for a sample of the syntax.
4. Rewriting frameworks from scratch – The first day we implemented LINQ extension methods from scratch. Yesterday we wrote the routing portion of a basic MVC Framework. Today we’ll be writing an IoC container from scratch. These sound like an inane “reinventing the wheel” tasks, but they are meant to be simple exercises to help us practice good design. Not only did it help increase my conceptual understanding of the lower level infrastructure I’ve been using, but it was also very empowering to temporarily counteract the long term trend of consuming API’s and frameworks at that are higher and higher on the abstraction stack..
5. Coding Centric Course with no Lab Manuals – Most training courses that I’ve attended or taught have provided students with detailed instruction manuals on how to complete the lab portions of the course. By contrast, JP cuts you loose with minimal direction. It was frustrating at first, but then I saw the value as soon I noticed how focused I was when he finally showed us the solution. It made so much more sense than it would have otherwise once I had some context based on first hand experience.
6. Using Delegates to Test the Untestable – Probably the most memorable technical epiphany I experienced yesterday was when JP showed us a technique for testing methods that contain static framework methods or concrete framework classes without interfaces, both of which are unmockable when using RhinoMocks. By turning the methods into delegates that are private member variables, we were able to use interaction based testing to verify that the methods were invoked and that all the correct parameters.

Popularity: 1% [?]

I’m working on 2 hours of sleep last night thanks to my 17 month old, so I thought I would record some of my thoughts about my first day of training yesterday before they are completely lost in the haze of sleep deprivation and the blur of day two.

1. Delegates are like onions: there are many layers to peel back and prolonged exposure sometimes makes you want to cry.
2. Slamming a Mountain Dew at 9:00 PM to help to make it through the last few hours of class seems like a really good idea…until you get home and try to go to sleep.
3. JP codes hella fast. I really need to make a commitment to go mouseless and dig even deeper into R#.
4. Internal DSL’s are fun to consume, but creating them is like drinking day old Folgers coffee through your nose.
5. The branching and merging story in Git is way better than it is SVN, but you’re forked if you rely on everyone in the class being able to pull from GitHub through a hotel network.
6. Goals are powerful. I think I’ve been aiming way too low lately.
7. Unlearning is sometimes more difficult than learning.
8. Training should be as much about getting inspired and having your baseline expectations blown away than about learning specific content.
9. I wish I had taken JP’s course sooner and will recommend it to everyone I know.

Time to go refill my caffeine IV before class starts.

Popularity: 1% [?]