- Posted by liammclennan on October 16, 2009
Executable specifications are the holy grail of software development. The idea is to specify the behaviour of a system in some structured way that can be automatically verified. It is something that I am interested in so I have been keeping an eye on the options that are available for .NET.
Cucumber with IronRuby
Cucumber is a popular ruby tool. Specifications are written as plain text files and made executable by writing regular expressions for each line of the text file. Cucumber has a strong BDD flavour, encouraging users to write their specifications in the given, when, then style. I have not tried it myself but I know a number of people have indicated that getting cucumber to work in ironruby is difficult.
NGourd
NGourd is a native .NET project inspired by Cucumber and written largely by Mike Minutillo. Again, regular expressions are used to extract the parameters from the specifications, but this time the regular expressions are written as attributes. I contributed some code to this project to log its the output in a format that can be used by build servers such as Team City and Cruise Control .NET. NGourd is rudimentary but it does work and I have used it in some of my projects. As a developer, this type of tool is my first choice. I like that the specifications are plain text files that can be easily processed and versioned. However, if the aim is to have non-programmers working on the specifications then I fear that plain text may not offer them enough support.
StoryTeller
StoryTeller is a tool by Jeremy Miller, inspired by FitNesse. In StoryTeller, developers define a grammer for tests and then non-developer users can build specifications using a GUI. Because the GUI assists the user with the grammer StoryTeller is probably easier to use for non-technical people.
Executable specifications are an exciting idea, and I hope that one day it will be the way that we all build software. At this moment the tooling is rapidly improving. I like the text based tools for use by developers with BDD style functional testing, and I like StoryTeller for its improved support for customer involvement.
- Posted by liammclennan on October 8, 2009
Tonight was the first Brisbane Alt.Net Beers. I am sitting at Central station killing time before the Cleveland train arrives to take me away from the madness. The diggy billboard informs me that they can get me on the front page of Google guaranteed! Sweet.
The evening turned out nothing like the UK Alt.Net Beers, which are characterised by a fixed time limit and a single topic. Tonight was a group of nerds, ranging from mild to intense, drinking beer and discussing the failures and successes of their professional lives. For some it was enlightening, for some it was cathartic and I hope it was enjoyable for everyone. I think it is a good sign that Brisbane Alt.Net is alive and well. Lets do it again some time.
- Posted by liammclennan on September 17, 2009
I continue to be interested in the architecture of the plain, standard, web application. Each of the web application frameworks defines an architecture for the plain web application. Think of Rails and Django (MVC + Active Record), or sharp architecture and Codebetter.Canvas (Asp.net MVC + NHibernate + DDD). This is a starting point from which more advanced and specialised web applications can grow.
Damian Maclennan, or as these guys might say (2:50) 'some guy', presented a simple framework for web applications at Sydney Alt.Net. Damian's example mixes Asp.Net MVC, Fluent NHibernate and Structure Map.
The Good Parts
My favourite part is the way that NHibernate is configured with the IoC container. The author inherits from the Structure Map Registry class and creates a registry called NHibernateRegistry
internal class NHibernateRegistry : Registry
{
public NHibernateRegistry()
{
ForRequestedType<ISessionFactory>()
.CacheBy(InstanceScope.Singleton)
.TheDefault.Is.ConstructedBy(() => new NHibernateSessionFactory().GetSessionFactory());
ForRequestedType<ISession>()
.CacheBy(InstanceScope.Hybrid)
.TheDefault.Is.ConstructedBy(x => x.GetInstance<ISessionFactory>().OpenSession());
}
}
I think this is a neat way to group IoC registrations. The NHibernateRegistry registers NHibernateSessionFactory as a singleton, which is important because NHibernate requires that the session factory is at application scope. The scope for ISession is InstanceScope.Hybrid which means that the scope of an ISession is one HTTP request, exactly what is required for normal NHibernate usage.
The Missing Parts
It is usually desirable to begin a transaction for each ISession and close the transaction prior to the ISession being closed. If the example is extended to include database writes it will fail without transactions. NHProf recommends that transactions be used even for read-only sessions.
Security can be a challenge in Asp.Net MVC. I would like to see how Damian prefers to secure controllers.
The Repository<T> class currently only supports querying by Id. If a more complicated query is required where should it go? The two popular options are: specialised repositories (PostRepository : IRepository<Post>) with query methods and query objects where each query is encapsulated in an object.
Fluent NHibernate is nice but I wonder why auto mapping was not used. It would work nicely for the domain in the example.
Jerry's Final Thoughts
It's good to see the production of this kind of useful guidance. Someone new to the technologies could easily use Damian's example as a starting point for a well designed Asp.Net MVC application. It is certainly a much more helpful starting point than the Visual Studio template.
Until next time, take care of yourselves and each other.
- Posted by liammclennan on May 14, 2009
When a customer sponsors a software development project they want to know two things:
how much will the project cost and when will the project be finished.
The trouble with agile is that it cannot answer either of these questions with any degree of confidence. Put another way, the trouble with agile is that it exposes how difficult and costly estimation really is. The agile promise is that for the time and money the customer allows they will get the most value possible, but the magnitude of that value is not known in advance. Agile does not increase the customer's risk, but it increases their perception of risk.
Today I read cogentconsulting's Customer Brief. They talk about how agile should eliminate waste:
we don’t want anyone to spend too much time documenting details that turn out to be irrelevant, or writing down things that can be communicated more effectively by phone or face to face,
and how the customer must give up their fixed-price safety blanket:
you need to be comfortable with the concept that some things will turn out to be cheaper and easier than expected, and some things will turn out to be harder and more expensive than expected.
I was also intrigued by their careful handling of reported defects:
unfortunately, we don’t have an indisputable way of making that distinction [between a defect and a change], so instead we treat every change as simply that – a change.
In other words, the customer bears the risk of undiscovered, misinterpreted or incorrectly implemented requirements. Caveat emptor. That such a mature and respected company felt the need to write such a strongly worded disclaimer makes me think that I am not the only software provider dealing with this challenge. It reinforces the need to educate customers on their role in an agile environment.
I have found some hope reading about Kanban and lean. The refreshing change is that Kanban has removed all pretense of estimating project time and cost. It includes some vague forcasting but the customer is never given the impression that they can fix a feature/time/budget trinity. I like kanban because it is honest, however I doubt how well it will work for a commercial project.
