LoGiCaL mE

I've moved this blog to http://hugo-palma.blogspot.com

I'll keep this alive for a few days but new posts will only go into the new blogspot home.

I've just finished the first chapter of my Mike Cohn book marathon. Well, not really a marathon as it's only two books, it's more of a 200 meters hurdles.

Anyway, i decided to first go through User Stories Applied and then to Agile Estimating and Planning. It seemed that this was the correct order to read the books and after finishing the first one and having already started the second i think i made the right choice.

Now, the book itself. I expected the book to start slowly with some more theoretical talk about agile development but instead it cut right to the chasse. By page 6 i was already seeing real life examples of user stories and getting very practical advices on guidelines for writing good user stories. This is great. Actually, it was only when i reached the end of the book that i realized that i hadn't skipped a single page either because i thought it wasn't interesting or simply because it was boring. Not many books have the "no skipping" trophy.

This book mainly tries to enlighten you about this two things:

• How to write good user stories.
• How to manage and develop projects that use user stories.

All this is done is a very simple and practical way, most of the time by using real project examples. What more could one ask for ?
A sign or warning though, this book isn't about explaining Agile frameworks like XP or Scrum. There's many literature about those, and if you're looking for that this isn't the book for you. This book focuses on a practice  recommended by a lot of Agile frameworks that is user stories, although there's a chapter at the end that talks about Scrum and a little about XP it's really only to provide some context to the whole user story thing.

Putting it short, i think this book is a must have for anyone that is or wants to use user stories.

I've recently asked this same question on the Ubuntu forums and i got some really annoyed answers. Apparently for some Linux users it's perfectly fine to endure the following process to create a screencast:

1. Record the video and audio with RecordMyDesktop.
2. Import the generated file to Kino video editor.
3. Figure out why the imported video got it's quality so degraded that you can barely see what's going on.
   
4. After you read thousands of posts in forums of other people screaming for an easy way to do this, figure out how to use command line tools like ffmepg with it's 100s of parameters to convert the generated ogg file into an avi file.
5. Open the avi file on Kino.
6. After a while trying to figure out how to do simple things like adding a callout, finally realise that you can't do that with Kino and you'll probably have to loose more time looking for another application to do that.
7. Give up, use the limited Wink Linux version or fire up a Windows VM and use Wink for windows.

There was a really promising project called ScreenKast that seemed to deliver. Unfortunately, the project seems to have died.
I love Linux, and i use Ubuntu 99% of my time, but it's because of stuff like this that i still have to have the good old Windows VM for the rescue.

Take a quick look at this piece of code:
 

public class Test<T> {
    public T getSomeT() {
        return null;
    }
 
    public List<String> getStringList() {
        return null;
    }
 
    public static void main(String[] args) {
        Test test = new Test<Integer>();
 
        String a = test.getStringList().get(1);
    }
}

It should compile just fine right ?
Well, it doesn't. Instead you get an compile error like this:

incompatible types
found : java.lang.Object
required : java.lang.String

So what's wrong ?
It seems that when one uses a type in raw fashion, all generic parameters used in the type get removed from the compiler.

So what this means is that just by introducing a parameter to your class you can break all your code where some method that uses a generic parameter is being used.

Just so you know, this is not a bug, it works like this by design!!

As you might know by a previous post here i'm using Hudson for continuous integration. If you read that post you'll also notice that pointed out some things that were still missing in it, quite important things like proper Maven2 integration.

Well, i must sadly say that none of what i consider major issues with Hudson have been resolved since then. Instead, it seems that they have been releasing a new version almost every week with small bug fixes and new localization and things like that.

Who really cares that there's a Japanese Hudson now if none of the major Hudson plugins work with the Maven2 style project ?

Who cares if the login button didn't show up in some remote conditions if the people that contribute to a failed build don't get any email warning them about that ?

Who cares if there's a password confirmation field if i have to duplicate every single configuration of my project just to configure a hourly and a nightly build ?

I know that this is an open-source project and all, but usually the reason for not getting things done is the understandable "we have to make a living in our day job so we don't have that much time to dedicate to the project". I understand a respect that. But here it's different, there's a new release coming out every week so there's no time problem here, in my opinion, just bad task prioritization.

I really hope that the project comes around and starts delivering more user value instead of focusing on smaller things.