Sunday, January 31, 2010
In our new project, we've decided to use FitNesse with slilm. All in all, slim is an improvement over fit.
The thing I like most is the error messages when running tests. These are now much clearer than with fit.
The fixtures are now plain old objects (that's poo -- you can call them pojo, poco or even pono for all I care). So no dependency anymore on fit.
Slim is also supposed to run faster, but right now our project is not really big enough to notice the difference.
There's two things I don't like about slim.
First, when writing scripts (the old DoFixture) or queries (the old RowFixture), you have to tell that to the wiki by prefixing the table with the corresponding keyword (|script| or |query|). This adds a technical touch to a wiki page that should be customer facing. I like to think about the wiki pages as requirements that are being elaborated by examples and scenario's. These keywords are technical cruft that get in the way of getting the functional message across. There's a little trick to hide the first row of each table however. Just add a # in front of the row, and all these technical details are gone.
The second thing I don't like bothers me more. The query fixture is now harder to implement than the previous RowFixture. In fit, you could return a list of any arbitrary objects, the column names would magically match any property or field for the items in the list. Now you have to do that work yourself by providing a list of objects. Each item then has to hold a list of properties, which in turn are lists of two items: column name and string value.
After looking around, my co-presenter Pascal found an alternative that uses reflection. This is the API to use this utility.
var people = ...//get the list of results for the queryList<object> results = new List<object>();
foreach (var person in people)
{
results.Add(AddObjectToQueryResult(person));
}
return results;
Being the geek that I am, I couldn't resist the urge to try to improve this. I ended up with something like this:
var people = ...//get the list of results for the queryList<object> results = new List<object>();
return people.CreateRowFixture()
.AddColumn("FullName", dto => dto.FirstName + " " + dto.LastName)
.ToList();
Here is a link to the full code with tests on google code.
Wednesday, January 27, 2010
We're nearing the end of our second iteration on a new project. I started out by setting myself a few goals to explore. I'd like to write them down here, so I can come back in a few months to see what remains of them. You're welcome to comment on these goals.
Overall
- readable, intent revealing software
- DRY, YAGNI, BOYSCOUT et all...
Entities:
- IAggregate root has interface
- No ID (I'm not sure if I can pull this one off with NHibernate)
- No (public) setters except for things like name, description, ...
- State based tests
- Testdata: take a look at
NBuilderServices
- almost no logic
- infrastructure: queries, mapping, ...
- hosted in spring.net
- Behaviour based tests
Controllers
- no logic
- only view concerns
- choice of view to render
- navigation (redirect)
- forward call to service
- Behavior based tests
- hosted in spring.net
Repository
- only handles aggregate roots
- only the following methods: add/remove/query
Queries
- Separate query objects that get passed in the 'query' method of repository
- Preference in this order: LinqToNH, Criteria, HQL
- Integration tested
Security
- RhinoSecurity?
WCF
- Service hosting in Spring
Testing
- Heavy emphasis on readability
- Intent (test) Driven Development
- Fitnesse first (red), then unit test(R=>G=>R), integration test (R=>G=>R), Fitnesse green
Note to the one reader I have (Hi mom!): I accidently deleted this post, so this is a repost.
I’ve just started a new initiative in our company: a coding dojo.
I first saw this last week at the XP days, and I loved every minute of it. Emmanuel Gaillot introduced us to this idea with a simple challenge: compare poker hands. The implementation was written in Haskell from scratch, using TDD and Baby Steps. As Bob Martin mentioned: the beauty of this was that most of the attendees did not know Haskell, but they were able to follow what Emmanuel was doing, and make recommendations regarding the design. Most of us learned a little Haskell too.
I contacted a few colleagues to see who would be interested in this experiment, and 9 of us turned up. I brought enough beer for the group, and we got started. We first decided by dot-voting that the coding challenge should be the ‘classic’ bowling game kata. Each of us took turns behind the keyboard for a maximum of 5 minutes.
After the exercise, we held a retrospective. This is what came out of it:
What went well:
- Fun environment
- You have the right to fail. Tests will catch you, but no one will laugh at you.
- TDD with small steps
- Refactoring for readability
- Learned a few shortcuts in visual studio
What could have gone better:
- Let the driver and navigator do the work. The audience can comment, but if you want to argue, stand in line to code.
What would improve the coding dojo
- Try out new languages: java, ruby, groovy, haskell, F#, ook…
- Do this on a monthly basis
All in all this session was a success, as all participants will agree. Here’s the code we came up with. We do realize that this code isn’t perfect, but at least it works AND it’s readable.
using System;
namespace Dojo1
{
public class BowlingGame
{
private readonly int[] rolledPins = new int[21];
private int currentRoll;
public void Roll(int pins)
{
rolledPins[currentRoll] = pins;
currentRoll++;
}
public int GetScore()
{
var score = 0;
var rollNumber = 0;
for (var frame = 0; frame < 10; frame++)
{
if (IsStrike(rollNumber))
{
score += 10 + StrikeBonus(rollNumber);
rollNumber++;
}
else if (IsSpare(rollNumber))
{
score += 10 + SpareBonus(rollNumber);
rollNumber += 2;
}
else
{
score += FrameScore(rollNumber);
rollNumber += 2;
}
}
return score;
}
private int FrameScore(int rollNumber)
{
return rolledPins[rollNumber] + rolledPins[rollNumber + 1];
}
private int SpareBonus(int rollNumber)
{
return rolledPins[rollNumber + 2];
}
private bool IsSpare(int rollNumber)
{
return rolledPins[rollNumber] + rolledPins[rollNumber + 1] == 10;
}
private int StrikeBonus(int rollNumber)
{
return rolledPins[rollNumber + 1] + rolledPins[rollNumber + 2];
}
private bool IsStrike(int rollNumber)
{
return rolledPins[rollNumber] == 10;
}
}
}
Thursday, November 26, 2009
Pfew... our presentation at the
XpDays is done. You can find all the materials google code at this link:
http://agileacceptancetesting.googlecode.com/svn/trunk/.
The audience was great, and
Pascal and I enjoyed it. We'll probably be trying to find something new to prepare for next year.
Monday, November 16, 2009
Bob Martin is going to give a keynote at Devoxx in Antwerp on thursday. I invited him for a drink on wednesday (that's the 18th) in Antwerp at about 20:30.
I'm not sure where we'll be going, so any suggestion is welcome.
Anyone care to join?
Wednesday, October 21, 2009
JetBrains is releasing nightly builds of ReSharper since Monday. R# looks very promising so I installed it.
But my favorite tool just got easier to update. Scott Cowan just published a tool to upgrade ReSharper 5.0 EAP automatically. Just like the previous version of the ReSharper Updater, it just works.
Thanks Scott.
Monday, September 28, 2009
Martijn Boland
recently blogged about his first adventures with a new contract using EF. He compares notes with the original
Vote of No Confidence and realizes the fears from back then were right on the money. The thing that totally blows me away is one of the comments to his post:
EF might not have tons of features, but from what I’ve read lately,
performance is not one of its weaknesses, specially when compared to
NHibernate, am I missing something?
Here we go again... I heard NH doesn't perform well, so I'll pick EF.
My statement is: C# doesn't perform well, so pick C. Wait, no... let's go with assembler. Write your own compiler for better performance. And don't forget to bitshift when multiplying or dividing by 2. Cheek in tongue of course... or is it the other way around? ;-)
Seriously now. Don't talk about performance as if it were the holy grail of development. It's not. Think about other
equally important things: maintainability, total cost of ownership, readability, effort, time to market... If you were to ask a customer which of these values are most important to him, do you really think
performance will be the big winner?
Sometime yes. Like in big number crunching batch operations, real-time life monitoring systems or 3D gaming. And you'd be right assuming NH doesn't perform well enough for these scenario's. But let's face it. Most application don't have these critical 1ms per transaction performance requirements. Other aspects have to be taken into account with an equal amount of importance.
This performance argument is really getting boring.
Thursday, September 24, 2009
I was in awe before
the master himself. A week of absolute code bliss with Jean-Paul Boodhoo. It has really been a life changing experience. I know it has changed me and the way I look at code. My focus has changed radically. I now find myself being a nag with team members. Make it work first, then make it as humanly readable as possible. Or maybe it shoul dbe "Make it as readable as humanly possible"...
I just read the
five blog entries I wrote back then, and I'm amazed at the endurance that was required during the course. This was intended: "You only learn when you step outside of your comfort zone". I remember feeling tired on the second day, sleepy on the third, and a real zombie before the end of the week. More than 80 intense work hours squeezed into five exhilarating days.
I remember meeting a bunch of great like-minded people. I can't really say we keep in touch, but I regularly hear about some of them that are active members of the community. I read their blogs, and I hope they sometimes glance my way.
If you ever get a chance of following a
nothin' but .net bootcamp, DO IT! No excuses, no lame explanations, just do it.
Tuesday, September 22, 2009
Just a quick reminder to all interested.
Udi Dahan will be joining the alt.net beers night next Wednesday in Mechelen.
If you also want to be part of it, drop me a mail or add a comment on the google group thread. I'll take care of it.
Look at our
google user group for more info.
Friday, September 04, 2009
Gmail was down a few days ago. That's a big deal, right? Or was it?
Shamelessly reproduced from
http://www.modelmetrics.com/reidcarlberg/four-reasons-i-dont-care-that-gmail-went-down/. It's a bit outdated with this recent outage, but the idea behind the post renders exactly how I feel about it.
Gmail experienced an outage in Europe overnight. There’s some handwringing and frustration about it. But you know what? I don’t care. Here’s why.
1. The last significant Gmail outage looks to have been in August. Four months ago. My old email provider, which cost about $25,000 more per year than our enterprise Google account (which includes a whole lot more), used to “have some issues” (as we put it) about once every four weeks.
2. Google’s Gmail ops team is working on this. Correct that – they worked on it and it’s already fixed. I didn’t have to do anything. I didn’t have to submit a ticket. I didn’t have to call. I didn’t have wonder if anyone else was having the problem. It’s fixed.
3. No matter what the problem was, I’m not going to have to go out and buy a new server or install a patch. I’m not going to have to do anything other than wait a few minutes and try again. Awesome.
4. No matter what the problem was, I’ll bet you $100 I didn’t loose any data and that you didn’t either. The sum total cost of the problem was inconvenience. Although that can feel significant, it’s so much better than incurring substantial actual real dollar costs.
So that’s it. Gmail is back up and all that’s left to do is complain. But I’m going to ignore the complainers on this one. This is definitely no big deal.
Wednesday, September 02, 2009
Yippee, I will be speaking at the upcoming
XP days in Mechelen. This is a first for me, and I'm really excited about this.
Pascal Mestdach and myself have submitted a session on Agile Acceptance testing with FitNesse. It just got approved.
Monday, August 31, 2009
Since the beginning of July, I've been working on a java project. The language is very close to C#, although it has some minor irritating differences, like the lack good generic support, extension methods and closures. The big difference however is not in the language, the tools, the libraries or the utilities. One of the big differences I've seen is the
community.
I've been on many projects that have worked exclusively with Microsoft tools, libraries and (god forbid) examples. When the subject is raised of alternatives like an open source ORM or IoC container the response is predictable. It's a raised eyebrow stating clearly that non-MS solutions couldn't possibly be better than libraries like the EF, EntLib and such. Oh, and were you suggesting using anything else than stored procedures for data access?
Your idea won't scale...
Your idea won't perform...
Your idea won't be secure...
Your idea will be buggy...
Have you thought about the maintenance ...
Let's look over the wall now, shall we? If you announce proudly that you're going to work on a java project with hibernate and spring, you get a blank look from your fellow devs. "Duh! Of course! What else?". This best of breed approach took some years to mature but is way ahead of the default .net crowd.
The alt.net movement, the NHibernate mafia and all those alternative folks who don't adhere to the true MSDN way of doing software development are actually very close to this. The difference is that we are there by choice and by experience. The java guys are there, almost by default. This means that the mainstream java dev knows and understands things like IoC, AoP, ORM. He might have forgotten (or doesn't know) why these practices were introduced, but he's been using them daily for some years. Just like we forgot about writing our own compilers and practicing bit shifts to divide by 2.
I think it is our responsibility to enlighten our colleagues, one at a time, for the rest of our professional lives. To try and bridge that gap between alt.net and the mainstream .net development. And ultimately, as a community, help Microsoft on the course it is taking to embrace open source.
Quoting a fellow alt.net colleague I value greatly:
How on earth did it ever get this far in our industry for this mindset to be considered alternative?
Sunday, August 23, 2009
I was just browsing around and stumbled on this nice site called www.mysterytopia.com. It lists different categories of mysteries, ranging from the classic ancient mysteries to spac
e and astronomy. The first page I hit was "It's official: cows point norht". That's when my eye caught the Belgian flag in the ads rectangle.
I realized this was a live traffic feed telling the world who was watching the site at this time, and that I was on top sporting "Vilvoorde, Brabant: It's official: cows point north". Silly really, until I realized what the favorite topic was of US/Canadian viewers.
Sunday, August 09, 2009
I'd like to compare the java language to .net as I'm experiencing it. First of all, I'd like to point out that the differences are less than the similarities. Purely seen from a syntax point there really are no differences. Except of course if you're used to .net 3.5. This is irritating at first, but after a while you're just resigned to it. Take the simple properties we're so used to in .net
Compare these two identical pieces of code:
java:
private int counter;
public int getCounter(){
return counter;
}
public void setCounter(int value){
counter = value;
}
.net:
public Counter{get; set;}
I know we didn't have them before .net 3.5, and I realize the dangers of overexposing members, but I love the conciseness of automatic properties. For 7 properties I have 7 lines of code in .net and 70 lines of code in java.
Other things you don't get in java are anonymous methods, so that's no lambdas or LINQ either. No extension methods, so bye bye to simple readability like
1.February(2005). Access modifiers are slightly different but that's just something you accept and move in. All in all it's like having to go back to .net 2.0, which a lot of us have to do from time to time.
However, the thing that the .net platform really nailed, compared to java, is generics. I'm going to illustrate this with an example.
.net:
public T Get<T>(int id)
{
return session.Get<T>(id);
}
This is just not possible in java. For example, you cannot ask the type of T at runtime like this
typeof(T)). Generics are just a little syntactical sugar at design time and as a compiler check.
In java, your code will look like this:
<T> public T get(Class<T> clazz, int id){
return (T) session.get(clazz, id);
}
Which makes every caller look like this:
repository.get(Person.class, id);
The cast to T might even fail at runtime if the type returned by
session is not of T.
Primitive types are also something to get used to. In .net, you can easily do
1.ToString(). No such luck in java.
new Integer(1).toString() is the way to go, since
1 is not an object. To me, java seems a more technical language where it is harder to express
intent without giving in too much into technical implementation.
I might sound a little whiny in this post, but all things taken into account, I enjoy this journey into a new, albeit a similar language. I can't wait to get an offer to try Ruby on Rails ;-)
Thursday, August 06, 2009
For many developers, the one-language notion is a sign of lack of professionalism. This is best exemplified by the Pragmatic Programmers' advice to learn a new language every year. The point here is that programming languages do affect the way you think about programming, and learning new languages can do a lot to help you think about solving problems in different ways.
From Martin Fowler’s at http://martinfowler.com/bliki/OneLanguage.html
I got the opportunity to participate in a java project since July. I’m going to share the pleasure and pain this brings to a .net developer. There are interesting differences in language, conventions, tools, application servers, IDE, … Since all I’m doing in the next weeks and maybe months will be java, you’ll hear that from me.
Too bad Martin fowler ended his paragraph with:
It's important to learn languages that are quite different in order to get the benefit of this. Java and C# are too similar to count.