05 Sep 2009
A while back I organised a coding session during an internal training day at work. The aim of the session was to introduce practices from the Clean Code book, to make code a little bit cleaner and practice the boy scout rule. I’ve tried to include the important points from the book, though everything in the book is equally important.
I’m sharing the slides and the code. Feel free to use it and improve on it. The code is a Sudoku solver from the Programming In the Small session at SC ‘09. I’ve converted the Java code to C#. The code includes acceptance tests, so you can fearlessly refactor without breaking it.
https://github.com/hibri/presentations
The session was planned for 90 minutes. It includes slides introducing clean code concepts, with coding exercises to practice them. I recommend 10-15 minutes for the coding exercises.
30 Aug 2009
Sometimes (most of the time) when looking at a piece of un-clean code, it’s not clear what path to take to make the code that little bit more better. The easiest first refactoring to do is extract method. Use extract method ruthlessly. Attempt to get and get many smallest methods. Repeat till these methods become smaller and smaller as close as possible to one line of code in a method.
Patterns emerge when creating more and more methods. The methods start to show groupings and responsibilities. When the methods obey the Law of Demeter, they can be moved around to other classes and also create new classes. It becomes easier to see duplication.
Methods are the smallest building blocks of a piece of software. These small and granular building blocks are more flexible. They give more ways to build things and allow greater reuse. When these building blocks are available, the code becomes much clearer. The big refactorings are made possible.
27 Aug 2009
I like the idea of running unit tests continuously as I type and save code. I read
about Autobuild .Net recently. This is easy to setup and use.
Grab the code from http://code.google.com/p/autobuildtool/ build it by running the default.build script.
When this is built successfully, the build process creates the tool in the output directory.
Copy the contents of this output directory to the project where you want autobuild to work on.
Autobuild .Net runs a nant build script each time a file is saved in a specific path being watched.
Change the autobuild.build script with the path to the solution file and the path to the unit test assembly.
Next in autobuild.cmd , change the first argument to the directory to watch for changes. The second argument is for the path to autobuild.build. This is the nant build script that autobuild will execute. You can replace this with an existing Nant build script.
Run atuobuild.cmd . That’s it. Type some code, save it and watch the window go red because it didn’t compile. Make it compile and watch it go green.
Write a failing test and see it go red, make it pass and see it go green. Fun eh ? 🙂
10 Jun 2009
The NHibernate Profiler is a pretty cool tool. If you are using NHibernate and want to see how your application/website uses NHibernate this is what you need.
But, why wait till you use the whole application to start using the profiler. Why not use it when writing writing tests , while building your mappings and when building your NHibernate queries. It’s really easy to do this.
First, get the NHibernate profiler from www.nhprof.com. Extract the contents to a location. From your test project, add a reference to HibernatingRhinos.NHibernate.Profiler.Appender.dll in the NHProf package.
This is my small test class.
[TestFixture]
public class EpisodeTests : BaseTest
{
[SetUp]
public override void SetUp()
{
base.SetUp();
ActiveRecordStarter.Initialize(typeof(Episode).Assembly, new XmlConfigurationSource("activerecord.xml"));
}
[Test]
public void CanPersistTitle()
{
Episode episode = new Episode();
string expectedTitle = "Dr Who and the Daleks";
episode.Title = expectedTitle;
episode.Save();
Guid savedEpisodeId = episode.Id;
episode = ActiveRecordBase<Episode>.Find(savedEpisodeId);
Assert.That(episode.Title, Is.EqualTo(expectedTitle));
}
}
</p>
</p>
I’m using Castle ActiveRecord (which uses NHibernate behind the scenes) to demonstrate this. To enable NHProf to profile the test, add a static constructor to the super class , BaseTest. In the static constructor, add the following code.
HibernatingRhinos.NHibernate.Profiler.Appender.NHibernateProfiler.Initialize();
Go to where you extracted NHProf and run the profiler exe. Run the test and watch the magic.
NHProf is now profiling your integration tests. You can leave this running in the background while you are working on the tests.
You get immediate feedback NHibernate best practice violations, and you can_ fix them while writing tests._ You don’t have to wait till deployment to profile your code. Although this doesn’t give the whole picture of how your application is using NHibernate , you still can fix many things early. I highly recommend running NHProf while running automated acceptance test scenarios.
Technorati Tags:
NHibernate,
TDD
04 May 2009
</p> </p> </p>
Recently I facilitated an Appreciative Retrospective for my team. An appreciative retrospective focuses on the positives “What did we do well? What worked ?”, instead of the usual “What went wrong, What can we do better” tone of retrospectives. This style of retrospective uses Appreciative Inquiry to identify what went so well. There is no blame or negativity, and builds on the Prime Directive, that everyone in the team did the best job they could possibly do.
Appreciative Inquiry builds on the positives, and attempts to amplify the good things we have done, and ensure that what makes us good is identified and refined. We usually end up loosing sight of what works for us in retrospectives, as we focus on the problems to fix.
I followed retrospective plan described here Retrospective using Appreciative Inquiry. The goal for the retrospective was to find “Where and how we added value during the past sprint”
Setting the stage. (5 minutes)
To set the positive tone, ask each member of the team to write on a post-it, a note of appreciation to someone else on the team. When everyone has written their notes, go around the table and have them read it out loud.
Gather data (5 minutes)
This is a brainstorming exercise. Distribute post-its of 3 colours. On each coloured post-it, have everyone write the team’s successes, strengths and events during the past iteration. Use one colour for each. Write as many as possible. Stick these up on one section of the board.
Generate Insights
Brainstorm the future (10 minutes)
This is similar to the previous exercise but needs more creativity. Have the team time travel to the end of the next iteration. Imagine what their successes, strengths and events would be in the not so far future. What would they achieve if they keep doing the best they can.
Write these on the same coloured post-its as the previous exercise and stick them up on another part of the board.
Affinity Mapping (15 minutes)
Get the team to the board. Group the different post-its. It is ok to mix up the post-its. Look for common groups and themes, pull these out. Group them into their own sections on the board and circle and label them.
_thumb.jpg "photo (1)")
Dot voting (5 minutes)
Have the team think about what groups/themes they want to sustain. Each member has two votes. Pick two groups with the most
votes.
Decide what to do (15 minutes)
Ask the team, based on what they have identified as their future successes, strengths and positive events, what actions can they take do achieve them. This could be in the form of “do more of, keep doing” actions. Pick two to three actions but not more.
Close the retrospective. ( 5 minutes)
I closed the retrospective with a Activity +/delta exercise.
_thumb.jpg "photo (2)")
My team found it very refreshing to focus on the brilliant work they’ve done, instead of being reminded of the few negative things that affected us. Variety in retrospectives was welcomed. Although the team wanted not to loose sight of negatives.
I recommend this style of retrospective, when the team is doing a lot of good things. However, make sure that any pressing issues during the past iteration are addressed. We had a post retrospective discussion about our stand-ups.
Try it for your team.
_2.jpg "photo (1)")
_2.jpg "photo (2)")