sfeldman.NET

While we are not yet in the era of "Minority Report", a regular White Board and stikies are good enough. This is how we started on our current project - the classic way. An interesting observation I've made while going through several attempts to track the progress of a project at several companies - an attempt to "modernize" stickies and get rid of the board. Ways are multiple, from virtualization of the board, to going back to a file based tracking (Excel/Word).

From what I can see right now - non of those are as effective as the classic way. Reasons?

1. Trying to capture progress not visually leaves out gray areas. When project is big, partition it, but don't rely on files or scrollable screen in an application - doesn't really work.
2. Time estimate is a separate concern - progress for developers makes sense in stickes that are in "done-done" column, and the flow from left to right.
3. The process should be simple, if it requires extra effort, it become rather an impediment, than an assistance, and eventually will be abandoned.
4. Board is something that is a couple of steps away at worse, and a head turn at the best. File based solutions are failing this, applications require windows switching (context change) or worse, load time.

By sticking to the KISS principle with stikies, it is obvious what the status after just a week.

Have fun with stickies! :)

Being a developer for 8 years, I went through the classic path of a green newbie knowing nothing, to a more mature developer aware of the flaws, till the current stage where I realize that I wasted too much time on too many things that are not important, when important things are not new and shiny, but old and proved by the time. Waterfall, Spiral, Agile – all titles, what I want to share is the experience I had for the past a year+.

Agile or not, as a developer you quickly realize that there’s a good code, bad code, and smelly code. The first two are simple to distinguish. The last one, smelly, is not. Personally, I had absolutely no idea how to determine smelly code, besides just ‘sensing’ it.

I started my career as a single developer with pre-designed and assigned to me tasks. Thanks goodness that was short. Right after that, I worked in pair. Well, at that time I didn’t know I was pairing, since it was more ‘master’ and ‘teacher’ arrangement of things. Now looking back it made total sense – I had a chance to “learn how to shave on someone else’s beard”. Knowledge transfer, team effort, mutual design and implementation. The theory I have is that, thanks to that start, I was able to continue and constantly question myself “am I doing the right thing in the right manner”.

Journey into Agile for myself started at the end of 2007, when I took the Nothing But .NET training course and got exposed to the methodologies and concepts that are not floating a lot in the traditional mainstream development. I learned and realized that software is there to resolve real life problems, and it’s a tool, not a privilege. The “developer-centric” world collapsed for me, and the new world of the “business-centric” has taken place. I must admit, that I am not entirely converted, yet know that going the right way. How? Again, same feeling that led me to realization that pair-programming is a better model for development, that having confidence in the code is as important as the code itself (aka tests), that team is all about individuals and not just progress, and much more.

Latest project I am currently involved in is a remarkable opportunity to get to the next level. Working along with 3 brilliant developers (David Morgantini, Jason Lindermann, and Mike Hesse), implementing agile in practice makes me realize and understand better what I was reading all the way along, but was not capable to experience. Pairing, pragmatism, continuous design decision making, refactoring, trade-offs, testing, self-organized team, done-done, and much more – it all comes alive once you actually do it. “The Art of Agile Development” book authors said that first you have to entirely embrace agile methodology, and once you know it (rather that interpretate what it should be), only after that you can mix and match methodologies. But first be committed to know agile. Anyone knows what agile is? A-a-a-a-a-a!

Agile, IMHO, is an echo system. Developers, management, business people, all related and interconnected. To know how to balance it all, provide the maximum value from the resources that are available, with constant intention of improvement implemented rapidly in reality – all together represent just one of the Agile sides. Many other sides to learn remain. Realization of that is the right step in the right direction. My recommendation would be:

- Strive to self-improvement

- Surround yourself with people you want to be with

- Challenge what you do and how you do it

- Be honest to yourself and others on what you understand and don’t

- Don’t be afraid to learn – it is not weakness, but strength

- Go with your feeling – if it feels right, it cannot be wrong, but when it feels wrong, it obviously is

- Realize, that even as a software developer, you are a unit to function in a social environment and learn to deal with that

This is political, skip it if it’s not what you normally would like to read.

Today I learned about Baha’i leaders in Iran being charged for spying in favor of Israel, insulting religious sanctities and propaganda against the Islamic Republic. My reaction was – what a bull. Besides the fact that the country is running like a show, this type of accusation is just ridiculous. Where’s the logic? If someone would spy in favor of Israel, would they spread propaganda against the Islamic Republic? Don’t think so…

Personally, I can clearly see what Iran is up to and what they are trying to provoke. The game is old, and everyone knows its’ name. Sadly, I am no longer surprised about how weak and incapable of deeds the modern society is, when it comes to situations like this.

Base classes are a touchy subject. Some might advocate for it, some will against it.

Personally, I am not a big fan of base classes. There are several reasons for that, but most important to me, is the baggage you get to carry around once extend a base class. Saying this, I’ve noticed, that a “light-weight” base classes make sense for a very specific and narrowed scope job. To be short, an example – we started to leverage Fluent NHibernate to do our mappings. It’s simple and nice, but extremely repetitive. A typical mapping would look like this:

   1: public class AttachmentMap : ClassMap<Attachment>, IMapGenerator

   2: {

   3:     public AttachmentMap()

   4:     {

   5:         BuildMap();

   6:     }

   7:  

   8:     public void BuildMap()

   9:     {

  10:         Id(x => x.Id)

  11:             .WithUnsavedValue(-1);

  12:         Map(x => x.Filename)

  13:             .WithLengthOf(100)

  14:             .Not.Nullable();

  15:         Map(x => x.Data)

  16:             .Not.Nullable();

  17:         References(x => x.TrpMessage);

  18:     }

  19:  

  20:     public XmlDocument Generate()

  21:     {

  22:         return CreateMapping(new MappingVisitor());

  23:     }

  24: }

Where IMapGenerator was introduced to enforce Generate() method, that would allow us quickly to see what’s the generated XML (HBM) looks like.

You can definitely see that code is going to repeat itself for each entity and template is obvious. Plus, creating a constructor just to invoke BuildMap() can be omitted by mistake easily. The concept “if the process cannot allow mistake then it won’t be made” is true here as well. This is where the “light weight” base class is a good thing to have.

   1: public abstract class BaseEntityMap<EntityType> : ClassMap<EntityType> where EntityType : Entity

   2: {

   3:     protected BaseEntityMap()

   4:     {

   5:         BuildMap(); 

   6:     }

   7:  

   8:     protected abstract void BuildMap();

   9:  

  10:     protected virtual XmlDocument Generate()

  11:     {

  12:         var mapping = CreateMapping(new MappingVisitor());

  13:         Trace.WriteLine(Regex.Replace(mapping.InnerXml, ">", ">\r"));

  14:         return mapping;

  15:     }

  16: }

BaseEntityMap<EntityType> as a base class is responsible for one and only thing – enforce definition of BuildMap(), and remove repetition of code for Generating XML.

The new mapping code looks simpler and base class is not a “heavy beast to deal with”:

   1: public class AttachmentMap : BaseEntityMap<Attachment>

   2: {

   3:     protected override void BuildMap()

   4:     {

   5:         Not.LazyLoad();

   6:         WithTable("Attachments");

   7:  

   8:         Id(x => x.Id)

   9:             .WithUnsavedValue(-1);

  10:         Version(x => x.Version);

  11:         Map(x => x.Filename)

  12:             .WithLengthOf(255)

  13:             .Not.Nullable();

  14:         Map(x => x.Data)

  15:             .Not.Nullable();

  16:     }

  17:  

  18:     protected override XmlDocument Generate()

  19:     {

  20:         return base.Generate();

  21:     }

  22: }

Lines 18-21 are not necessary, and we only override Generate() when we want to see the generated XML. And even then, we are not duplicating the actual code. As for the BuildMap(), by extending BaseEntnty class, we are forced to have BuildMap().

Finished reading "C# in Depth" by Jon Skeet. Good reading, especially if you have to  catch up from C# 1.0 or 2.0 to the latest 3.0. The other one I would like to read now will have to be a mix of this book (without 1.0/2.0 materials) and the excellent "CLR via C#" by  Jeffery Richter.

Until that mix is out, I am switching back to Domain Design/Modeling. "Domain Driven Design" by Eric Evans is the only one I read, loved, was confused with, and have to re-read. But what is missing is the practicality (the modeling part?). Would love to hear about the Domain Modeling books you have to recommend (and they don't have to be necessarily in .NET neither C#).

Several last projects I used a simple IoC container, leveraging Activator.CreateInstance(type). The main reason - simplicity. Once there was a need to go to a higher level, I would switch to Windsor Container. One of the projects used Unity. The only issue was that I would always have to do some customization to my container (or DependencyResolver), which is nothing but a static gateway.

What I have decided, is that I do not want to invest effort in something that was working before just because the underlying implementation of container has changed. The container engine might be changed, but my code should not (OCP?). Therefore, DependencyResolver had to be coded slightly different. To make it possible, I decided to go with the LINQ Expressions. It allows to pass code in data structures, and thus allows to manipulate how to execute the code.

For demonstration purposes, I will only demonstrate the simple case, more complex cases are feasible as well.

   1: public interface IService

   2: {

   3:     void DoSomething();

   4: }

   5:  

   6: public class ServiceImpl : IService 

   7: {

   8:     public void DoSomething()

   9:     {

  10:         Console.WriteLine("ServiceImpl");

  11:     }

  12: }

DependencyResolver (which is static gateway) is

   1: public static class DependencyResolver

   2: {

   3:     private static IDependencyResolver instance = new LambdaDependencyResolver();

   4:  

   5:     public static void InitializeWith(IDependencyResolver resolver)

   6:     {

   7:         instance = resolver;

   8:     }

   9:  

  10:     public static void Register<ContractType>(Expression<Func<ContractType>> func)

  11:     {

  12:         instance.Register(func);

  13:     }

  14:  

  15:     public static ContractType Resolve<ContractType>()

  16:     {

  17:         return instance.Resolve<ContractType>();

  18:     }

  19: }

By default, LambdaDependencyResolver is going to be used. Registration is done by passing in an Expression<Func<ContractType>> that is nothing but a function that returns a ContractType implementer. The idea to wrap it with Expression, so that the instance (a particular dependency resolver implementation) would take care of the details based on how it works.

IDependencyResolver code

   1: public interface IDependencyResolver

   2: {

   3:     void Register<ContractType>(Expression<Func<ContractType>> func);

   4:     ContractType Resolve<ContractType>();

   5: }

LambdaDependencyResolver code

   1: public class LambdaDependencyResolver : IDependencyResolver

   2: {

   3:     private Dictionary<Type, object> dictionary = new Dictionary<Type, object>();

   4:  

   5:     public void Register<ContractType>(Expression<Func<ContractType>> func)

   6:     {

   7:         if (dictionary.ContainsKey(typeof(ContractType)))

   8:         {

   9:             throw new InvalidOperationException(typeof(ContractType).FullName + " was added already to container.");

  10:         }

  11:  

  12:         dictionary.Add(typeof(ContractType), func);

  13:     }

  14:  

  15:     public ContractType Resolve<ContractType>()

  16:     {

  17:         if (!dictionary.ContainsKey(typeof(ContractType)))

  18:         {

  19:             throw new InvalidOperationException(typeof(ContractType).FullName + " was not found in container.");

  20:         }

  21:  

  22:         var expression = dictionary[typeof (ContractType)];

  23:         var compiledLambda = ((Expression<Func<ContractType>>)expression).Compile();

  24:         return compiledLambda.Invoke(this);

  25:     }

  26: }

The usage

   1: DependencyResolver.Register<IService>(() => new ServiceImpl());

   2: var service = DependencyResolver.Resolve<IService>();

   3: service.DoSomething();

It's working, great. Some time later, we need to switch to some 3rd party container, and we don't want to change our code that relies on DependencyResolver. This is where Expressions are handy. I have used Unity container, but that could be StructureMap, Windsor Container, or anything else.

   1: public class UnityDependencyResolver : IDependencyResolver

   2: {

   3:     private UnityContainer container = new UnityContainer();

   4:  

   5:     public void Register<ContractType>(Expression<Func<ContractType>> func)

   6:     {

   7:         var newExpression = (NewExpression)func.Body;

   8:         container.RegisterType(typeof (ContractType), newExpression.Type, new InjectionMember[] {});

   9:     }

  10:  

  11:     public ContractType Resolve<ContractType>()

  12:     {

  13:         return (ContractType) container.Resolve(typeof(ContractType));

  14:     }

  15: }

Bolded code in LambdaDependencyResolver and UnityDependencyResolver is simply leveraging LINQ Expressions to make it all work. You can definitely make it more sophisticated and elegant as needed.

In the previous post I talked about running test in Resharper vs. TestDriven.NET

This time I will compare Visual Studio .NET 2008 (VS) with TestDriven.NET (TD.NET) for another functionality - quick code execution for evaluation purposes.

VS was shipped with a feature called Object Test Bench. The idea was to be able to instantiate an object of a class in order to execute it's methods for quick evaluation. Great idea. The steps to have it going were multiple.

Step 1 - Open Object Test Bench

Step 2 - Class View

Right click on the class

Step 3 - Create Instance

This will create the temporary object in Object Test Bench space.

Step 4 - Invoking Method

Step 5 - Getting Result

Step 6 - Finalizing

Note: to see the result stored under string1, you have to mouse over.

Not the same thing with TD.NET

Step 1 - Point to the method to invoke

Step 2 - See the result

Don't know what about you, but for me it's an obvious difference. Multiple steps in VS vs. single* step in TD.NET. Thanks David for showing this one.

So the right tool for the right job. Do you have any samples? Show it! Heck, why just to limit ourselves with VS only. We can do more than that. How about replacing RDBS with OODBS as the right tool? Sky is the limit.

* If you set your VS to show Output window automatically, it will popup on it's own. Otherwise that will be 2 step process. Still ALT-V, O should make it a step and a half :)

Seems like there's a bug in Rhino.Mocks 3.5 in regards to stubbed dependency (stubbing property getter and a behavior in certain order). Anyone knows something about it?

PS: have posts at both Rhino.Mocks usergroup and stackoverflow, but still no clue what's wrong.

My team is off the spike project we had, and I wanted to share a bit about exploratory tests.

The idea is to spike let's say some 3rd party component. Just spiking is good, but not always enough. How to ensure that we transfer the knowledge we acquired during the spike to the coming generations of developers? Or how to document what we know about the particular version of the 3rd party component, so it can be verified with any other potential versions it (component) will have?

The answer is simple - exploratory tests. These not just document in the best manner how to use the component, but also verify it behavior. In our case we used a component, where it's documentation stated certain default values, and in reality it had different values. What will be capturing it the best way and allow to verify for next versions that the bug was fixed and our code doesn't have to work around the issue? Yes, the old good exploratory test.

Bottom line, explore, test, document - all comes in one.

PS: I still don't like RosettaNet ;)

I used R# as a test runner tool. Nice UI (see my older posts), nicely integrated with Gallio. Just one issue - unrealistically slow when compared with a non-visual tool. And then our team member David showed us old-and-forgotten TestDriven.NET.

Oh boy, what a difference. It's so much faster, than we jumped on it (almost) right away, leaving R# unit testing tool behind (though, not the R# itself :).

One weak side of TD.NET - executing all tests in solution or selective tests execution grouped, it's not there. Yet, this is not an issue, for that we should leverage automated build scripts, right? :D

Moral of the story - use the right tool for the right job.