Posted Tue, 27 Mar 2007 11:35:00 GMT
This is the first one from the SPA conference that I write about. Don’t know why, just seemed to impressed me and I made a few notes during it, so here they come. These are actually my observations, not all of them were discussed in the session, but it prompted them.
When estimating stories, it is quite important that the right precision is used. Eg. if the minimum estimating period is one day, and many stories only take a fraction of the day, when you sum the thing up, you’ll be easily tripling the actual estimate.
People always find a way to over-complicate things and assume there’s more that needs to be done. I reckon that’s a psychological need to overcompensate, because as kids people (parents, teachers) were never satisfied with us, so we always assume there something more that is required from us.
When stories are presented as a group, people assume associations between them. Like, “oh but I already did story X, which gives me A, so don’t need to do it here”. Not sure if this is good or bad, but what if story X gets deprioritised - we’ll have to revise estimate, well, there’s some interference between them, can’t quite figure out what…
You can’t really estimate a story without actually picturing the system, yet many people try. A guy gave a great analogy - a skier or boarder plans his route. Has some idea what and where he’s going to be in x, y, z minutes. There’s a big difference if you know what you’re actually going to do.
Anyway, it was a really good session, and the guys did a few experiments with us without us knowing and then gave us the results to demonstrate the anchoring effect of the presence of numbers in specs and the size of the spec’s dependence on the estimates.
no comments | no trackbacks
Posted Tue, 20 Feb 2007 13:22:55 GMT
It seems that if a Spring context contains a class (A) and its superclass (B), the autowire by type for the superclass (B) fails.
That’s because when it does the lookup for beans of type B, the context returns both B and A. It’s not wrong in any way, it’s probably exactly the right thing to do, but it somehow makes it a bit trickier to do tests well, for me now anyway….
Or, may be one should never instantiate classes which are not leafs of the hierarchy tree. Should may be all classes that can be extended be abstract?…. All non-final classes abstract…hm… weird thoughts, don’t pay too much attention…..
no comments | no trackbacks
Posted Mon, 19 Feb 2007 11:43:00 GMT
Wouldn’t it be nice if you could say something like?
Map measures = new Map ( "Height" -> 175, "Weight" -> 69 )
as you can do in Perl, or even :
Map measures = new Map ( new MapEntry("Height", 175), new MapEntry("Weight", 69) )
….yes, it would be nice…
no comments | no trackbacks
Posted Sat, 17 Feb 2007 20:05:21 GMT
I loved this little package - Unxutils - http://unxutils.sourceforge.net/ - it contained ports the most useful unix commands, such as which, tail, etc for Windows. I used to just unpack them and drop them in system32 and then I could use them from a DOS prompt.
Unfortunately the zip is not there anymore and can’t find it available for download anywhere.
no comments | no trackbacks
Posted Fri, 16 Feb 2007 07:23:00 GMT
Opera is the best browser. It does not hang, it’s fast as lightning and its memory footprint is a fraction of the the others’. OK, there aren’t so many widgets as plugins, but given the size of the user community they’re doing quite well.
It’s annoying that a lot of Google tools don’t support Opera. Some do, but not officially. It can’t be that difficult to make Google docs support it.
Today I considered using another online document package, because I really like Opera - http://writer.zoho.com/jsp/home.jsp. What I’ll be missing though is the ease of sharing that I have with Google docs - it’s all become very integrated now and my friends are all on it, and it’s just so easy when everybody is already on it.
Google seem to have been fast enough and vocal enough with these tools to get everyone on board and achieve a bit of a vendor lock…
no comments | no trackbacks
