Feed for tags in Blogger

Should you need to provide feed to just to some particular posts with a specific tag in Blogger, all you have to do is to use the address http://${yourblog}.blogspot.com/feeds/posts/default/-/${tag} e.g http://andreamoz.blogspot.com/feeds/posts/default/-/NetBeans.

There are many more possibilities, as you can find googling around, but if you just have to get your blog on Planet NetBeans that should be enough (at least I hope so).

NetBeans and libraries

I just upgraded my NetBeans to version 6.7, and being quite lazy I didn't want to recreate all previous libraries and references, but obviously I need them. Yes, I might have decided to keep all settings from the previous version(s), which I regularly backup, but my interface had something strange and the dimensions of some widgets were quite quirky and my knowledge of the program does not go that far.

Anyway, after restoring the project I'm working on, NetBeans informed me of some missing references, just as expected.

Happy as a clam, I took the previous build.properties file, restored the lines that referred to my libraries (libs, sources and all) and... NetBeans stabbed me in the back! Still, it couldn't see the libraries!

After some restartings of the program and of the system (hey when you're working with Windows you get used to it... isn't it sad? and it often it works... isn't it sadder?) NetBeans still ignored my cries. It turned its back on me, despite all my affection steadily grown in all these years.

I gave up and recreated the libraries manually, but immediatly thereafter I checked the latest modified files in the .netbeans directory and found out what was missing... what I was missing, so actually NetBeans didn't stab me in the back so we're still in love. Yes, if you're wondering it, I had to apologize, but it happily welcomed me back.

Anyway, romances aside, when you create a library NetBeans not only adds the references in your build.properties file, but it also create an xml file in the config/org-netbeans-api-project-libraries/Libraries directory.

Should you need it... now you know!

As a sidenote: apparently NetBeans doesn't always allow the removal of different plugins at the same time, and it took me several tries to disable the profiler (actually I had to remove it, as I didn't manage to just disable it). More on the new version will probably follow, up to now I just can say that my peer likes the new colors of the splash screen.

While you wait, go get it yourself!

Goodbye Pedro

After winning four Italian titles, after playing with the Italian National Team, after many satisfactions Pierpaolo Pedroni has been - way too early - summoned to play in the selection of rugby legends in the most beautiful stadium over the rainbow.

When my friend Pancho gave me the news I couln't believe him, as I had just met Pierpaolo, who was only 45 years old, less than a month ago in Cernusco, where he won the Vets cup with the Alcolizzati.

Somebody says that rugby players never die, at the most they hand the ball. Goodbye Pedro, we'll meet at the fourth half.

NetBeans and Frameworks

NetBeans seamlessly provides an integration with the most common frameworks, e.g. GWT, jMaki, Spring Web MVC, JSF, Struts, Hibernate.

When we create a new project we are asked whether we want to use any of these frameworks in our application. Should we need to add them later it is very easy to do so: from the project properties you select the Frameworks category, click the Add... button, select the framework(s) you need and you're done, as NetBeans takes care of (almost) everything, e.g. if you add the Hibernate framework NetBeans will add the necessary libraries and references and create a hibernate.cfg.xml file.

What I never managed to realize is how you get rid of a framework, as there are no Remove buttons whatsoever. That's where a versioning system comes useful (disclaimer: this is definitely NOT the only reason for which you should use one). If you have your whole project under versioning (including NetBeans administrative files) as we do, after committing everything on the repository you can simply add your framework and ask your versioning system to show you the changes and use a simple diff on each modified or added file and save the differences for future reference: in this way you can pretend you know the NetBeans internals like the back of your hands, while you just used a sleight of hand.

If you want to remove the framework now you can just revert all modifications and delete added files, but if you want to remove it after some other coding you can always go back to your reference files.

I'm sure there's a way to automate all this at least a little bit, but for now I'll be content with this.

Testing an interface in JUnit4

How do you test an interface? Obviously, there is no way to instantiate it directly, so you have to write a test for each different implementation. I feel shivers down my spine even as I write it... that awfully smells like duplication, which - should you ask - is bad. Nevertheless, I'd like to test every possible implementation.

As JUnit Recipes reports, this is quite simple:

1. Start from the test case for one of the implementation (I assume you have them, don't you?)
2. Create a new abstract test case in which you will define the expected behavior
3. Have your test case extend the abstract test case
4. Move the code that instantiates the object under test into a separate method, storing the object as a reference to the interface and not the implementation.
   
5. Adjust the rest of the code referring to the interface behavior accordingly
6. Create an abstract creation method for each concrete creation method
7. Move all tests for the interface to the abstract test case

At this point in the test cases for the implementations there should be only implementation specific behavior, not related to the interface.

I tried it all in JUnit 4... and it didn't work, as when I ran the tests for all the project I got a wonderful java.lang.InstantiationException (actually several of them) for the abstract test case.

After some personal tries and a bit of googling I found that all I needed to do to have everything run smoothly was to add the @Ignore assertion to the abstract test case. Now we have no excuses!

Don't comment bad code

Don't comment bad code - rewrite it.

The quote belongs to Brian W. Kernigham and P.J. Plaugher (and I'm sure to many others). It might sound simple... yet I perceive it as so powerful! It puts your back to the wall with the choice to devote yourself to leave your campfire slightly better than you found it... or to simply turn your head.

Uncle Bob has a similar opinion on the subject:

"Ooh, I'd better comment that!" No! You'd better clean it!

Commenting bad code derives from the fear to actually modify it. But beware:

Fear is the path to the Dark Side.

Get rid of modifiers

When you are performing queries you sometimes want to treat modified letters like their corresponding unmodified ones, e.g. è should be treated just like a plain e.

The first algorithm that comes into your mind is probably a long switch of modified characters, which is horribly ugly. The second one could be a map, slightly better but still ugly. Both approaches require quite an amount of work, and I didn't (I still don't) like them.

After investigating a little and asking some friends I was more or less resigned, until Gabriele pointed me to what I was actually looking for: the java.text.Normalizer, that lets you transform an ugly string into a neat one with just a single line of code:

result = Normalizer.normalize(myString, Normalizer.Form.NFD);
return result.replaceAll("\\W", "").toUpperCase();

Now, that's what I call quite good...