
Monday, March 31, 2008
Friday, March 28, 2008
I knew it! I'm a Guinness!
And now I have the proofs:
You Are Guinness |
![]() You know beer well, and you'll only drink the best beers in the world. Watered down beers disgust you, as do the people who drink them. When you drink, you tend to become a bit of a know it all - especially about subjects you don't know well. But your friends tolerate your drunken ways, because you introduce them to the best beers around. |
Looks like I am a colon
That's curious enough... I always saw myself as the asterisk in the party joke...
You Are a Colon |
![]() You are very orderly and fact driven. You aren't concerned much with theories or dreams... only what's true or untrue. You are brilliant and incredibly learned. Anything you know is well researched. You like to make lists and sort through things step by step. You aren't subject to whim or emotions. Your friends see you as a constant source of knowledge and advice. (But they are a little sick of you being right all of the time!) You excel in: Leadership positions You get along best with: The Semi-Colon |
Etichette:
fun
Wednesday, March 26, 2008
A bad citizen in Javaland
I just read this wonderful post on the use of setters and getters in Java classes... that's a very good metaphore which explains why they really break encapsulation, as they actually expose the internal structure of a bean this leading to, er, "interesting" results.
Do I hear someone say "How can I then build an object if I don't have all the mandatory informations I need from the start?"? Well, to begin with that's what Builders are for. If you feel this is an issue you're probabily storing the data in the wrong class.
OOD is about collaborations, not about structures. If you stick with structures, there's some procedural programming lurking under your OO language: you're not asking services, you're instructing slaves. Slaves of which you know everything. Doesn't it smell? You have "sad" objects, as Francesco Cirillo calls them, mere value objects in disguise. That doesn't mean "Transaction Script is evil", but surely means "Transaction Script can be really evil"; it all depends on the domain and on the application you're working on.
That can sometimes lead to another common objection: "data survive applications, so that's the focal point around which everything must revolve". Curiously enough, the way data is persisted is just an implementation detail - and I'm not saying it's easy, as a matter of fact there are a lot of issues and patterns about how to deal with them on the subject. But it's not the main concern in OOD, even if generates a lot of boilerplate code.
Do I hear someone say "How can I then build an object if I don't have all the mandatory informations I need from the start?"? Well, to begin with that's what Builders are for. If you feel this is an issue you're probabily storing the data in the wrong class.
OOD is about collaborations, not about structures. If you stick with structures, there's some procedural programming lurking under your OO language: you're not asking services, you're instructing slaves. Slaves of which you know everything. Doesn't it smell? You have "sad" objects, as Francesco Cirillo calls them, mere value objects in disguise. That doesn't mean "Transaction Script is evil", but surely means "Transaction Script can be really evil"; it all depends on the domain and on the application you're working on.
That can sometimes lead to another common objection: "data survive applications, so that's the focal point around which everything must revolve". Curiously enough, the way data is persisted is just an implementation detail - and I'm not saying it's easy, as a matter of fact there are a lot of issues and patterns about how to deal with them on the subject. But it's not the main concern in OOD, even if generates a lot of boilerplate code.
Tuesday, March 25, 2008
Estimating in Ideal days
When it comes to estimating you have different options to pick from; two of the most common are ideal days and story points, each of which has its own strenghts and weaknesses. One of the worst weakness of the ideal days method is that an "ideal day" means very different things to different people; moreover, different team members give very different estimates depending on their relative skills, so you can have a very wide range of estimates for a single item to deliver (call it use case, user story, feature, you name it).
If you're used to ideal days estimating and decide to stick with it, there are some tips that can help you to reduce the risk associated with the method.
The first (and obvious? unluckily not so much...) tip is to let who will actually develop the software do the estimate. Managers do not have enough informations, so they must trust the team. After all, a great slice of management work is to select collaborators, so if a manager trusts himself (and you bet she does) she must trust the people she has chosen as well.
Moreover, more than a single member should estimate the same item; actually the whole team should do it, thus exposing - early - different points of view; more often than not, if somebody estimated an item much less than other members she forgot something or did not considerate all the implications of the item: the key to effectiveness of this practice is the constructive dialogue between developers. A particular way to do it is planning poker: all developers have a deck of cards, each of which indicates a valid estimate; a moderator reads an item from the list to be estimated and each developer choses a card, then everyone turns up their card at the same time. If the estimates are more or less alike there is a short conversation and an agreement is reached, otherwise there can be a deeper discussion, after which there is a new turn.
A deeper problem emerges when developers are differently skilled: they might agree on the relative size of the items, but their estimates will differ greatly; an item which would take an experienced developer two days could require ten from an inexperienced one. On the contrary, if all developers in a team have more or less the same skills they can ignore the problem. If that is not your case (and surely - and unluckily - it is not mine) you have to deal with the problem of scheduling also: if you estimate on the experienced developer's words you have to assume that she will do the work, but you cannot have the guarantee that when the time comes she will be available, so you'll have to spend ten days but you can bill for only two of them; if you choose to take the estimate of the inexperienced developer the customer could complain because your team costs too much. In this cases I normally estimate somewhere in the middle and do all I can to have the two developers pair on the item to leverage knowledge and experience.
Last but not least, ideal days are different for different people: someone consider ideal days as "eight hours focused on a single task", someone else as "six hours focused on a single task, plus a couple of hours on different things". Obviously that brings to different results, and the bigger the project the worse the outcome. That also clashes with scheduling, because people should manage their time but that is not always easy, particularly regarding how to deal with (internal and external) interruptions. To deal with this risk you have to know the velocity of your team members and of your team as a whole, so that you can translate their estimates into sufficiently reliable schedules.
Most of the advices are also useful for estimating with story points.
If you're used to ideal days estimating and decide to stick with it, there are some tips that can help you to reduce the risk associated with the method.
The first (and obvious? unluckily not so much...) tip is to let who will actually develop the software do the estimate. Managers do not have enough informations, so they must trust the team. After all, a great slice of management work is to select collaborators, so if a manager trusts himself (and you bet she does) she must trust the people she has chosen as well.
Moreover, more than a single member should estimate the same item; actually the whole team should do it, thus exposing - early - different points of view; more often than not, if somebody estimated an item much less than other members she forgot something or did not considerate all the implications of the item: the key to effectiveness of this practice is the constructive dialogue between developers. A particular way to do it is planning poker: all developers have a deck of cards, each of which indicates a valid estimate; a moderator reads an item from the list to be estimated and each developer choses a card, then everyone turns up their card at the same time. If the estimates are more or less alike there is a short conversation and an agreement is reached, otherwise there can be a deeper discussion, after which there is a new turn.
A deeper problem emerges when developers are differently skilled: they might agree on the relative size of the items, but their estimates will differ greatly; an item which would take an experienced developer two days could require ten from an inexperienced one. On the contrary, if all developers in a team have more or less the same skills they can ignore the problem. If that is not your case (and surely - and unluckily - it is not mine) you have to deal with the problem of scheduling also: if you estimate on the experienced developer's words you have to assume that she will do the work, but you cannot have the guarantee that when the time comes she will be available, so you'll have to spend ten days but you can bill for only two of them; if you choose to take the estimate of the inexperienced developer the customer could complain because your team costs too much. In this cases I normally estimate somewhere in the middle and do all I can to have the two developers pair on the item to leverage knowledge and experience.
Last but not least, ideal days are different for different people: someone consider ideal days as "eight hours focused on a single task", someone else as "six hours focused on a single task, plus a couple of hours on different things". Obviously that brings to different results, and the bigger the project the worse the outcome. That also clashes with scheduling, because people should manage their time but that is not always easy, particularly regarding how to deal with (internal and external) interruptions. To deal with this risk you have to know the velocity of your team members and of your team as a whole, so that you can translate their estimates into sufficiently reliable schedules.
Most of the advices are also useful for estimating with story points.
Etichette:
estimating,
project management,
scheduling,
time management
Bike's back
My motorbike has been repaired... only the fuel tank has a small scratch, which I think I'll cover with a bigger tank pad than the one I'm using now. For the indicators I used the ones I got from my old '89 Kawasaki GPZ500 (not the original ones, I changed them about a couple of years ago) so I saved some money and have some fancier indicators as well. It didn't even cost me as much as I feared, even if <irony>being I a zillionaire I don't care about money at all</irony>. I'm happy to have it back almost as good as new.
Etichette:
motorbike
Thursday, March 20, 2008
A bad day
What do you call a motorbike with just the side-stand? I think that "a menace to my wallet" is a pretty good description, as yesterday (bloody rotten luck) my Suzuki SV650 decided to take a nap. And SVs don't sleep like horses do, but they want to lie on the floor. So, while I was locking the gate, I heard a sort of a "CRANCK!" and... I will not delve into details, but today my mechanic will be asking me a heap of money for:
The icy on the cake came yesterday night, when a wasp stung me on the neck while I was training... WTF!!!
- fixing the top of the fuel tank, which has reported a deep scratch just a few inches down the opening
- changing the broken gearshift lever
- changing the front left arrow (but I still have a custom couple from my old GPZ, so maybe this will come for free)
- changing the left handlebar balancer
The icy on the cake came yesterday night, when a wasp stung me on the neck while I was training... WTF!!!
Etichette:
motorbike
Phantom Keystroker
Wow check this out! Ever experienced your pc behaving just like it had a brain of its own? Sometimes I have, and it always turns me mad. This little device randomly generates mouse movements and/or keystrokes, so if you want any of your beloved (...) colleagues to go cuckoo it should be worth a try. If they were a little less expensive I'd surely buy a couple... better to have a backup, should somebody find it under the desk!
Etichette:
electronic gadgets,
fun
Wednesday, March 19, 2008
Wales wins another Grand Slam


Etichette:
Grand Slam,
rugby,
Six Nations 2008
Tuesday, March 18, 2008
To agile or not to agile?
Today I really feel the urge to quote what Uberto said in the JUG Milano mailing list - and forgive me if something gets lost in the translation process - the original had a deeper stroke on people's imagination.
"Blockheads, agile or not, will never produce good code, just as even if you can produce the best software in the world but you don't understand the domain your project is doomed: technical success is a foolish illusion."
"Blockheads, agile or not, will never produce good code, just as even if you can produce the best software in the world but you don't understand the domain your project is doomed: technical success is a foolish illusion."
Etichette:
agile,
domain-driven design
Monday, March 17, 2008
Better late than never

Meanwhile, Paterson completed his perfect kicking Six Nations at 100% just like in the World Cup.
England won 33-10 over Ireland; youg Cipriani, picking up Wilko's number 10 shirt, played a very good match - even if I still prefer Johnny Wilkinson; another great performance was the one offered by the Man of the Match Jamie Noon. I am not sure whether this match can change Ashton's future, which I see quite doomed.
Etichette:
rugby,
Six Nations 2008,
wooden spoon
Friday, March 14, 2008
A Very Quick Wiki
Yesterday I read about JUG Milano's intentions to get more and more involved in the VQWiki project. As I've been searching for quite a time for the easiest of Wikis to just drop in my servlet container and start to edit, I decided to give it a try.
As a matter of fact setting up VQWiki is really straightforward: download zip, unzip, upload war and boom you're it. I haven't even started to scratch the surface, but what I've seen so far serves my purpose of having a site for the project we've just started - the simplest thing that could possibily work... well it works!
If you're a newbie with Wikis and want to experiment, VQWiki is a really nice start.
As a matter of fact setting up VQWiki is really straightforward: download zip, unzip, upload war and boom you're it. I haven't even started to scratch the surface, but what I've seen so far serves my purpose of having a site for the project we've just started - the simplest thing that could possibily work... well it works!
If you're a newbie with Wikis and want to experiment, VQWiki is a really nice start.
Wednesday, March 12, 2008
PMD rules for test classes
This is the updated version of the PMD ruleset we use for test classes:
<?xml version="1.0"?>
<ruleset name="my_pmd_test_rules"
xmlns="http://pmd.sf.net/ruleset/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://pmd.sf.net/ruleset/1.0.0 http://pmd.sf.net/ruleset_xml_schema.xsd"
xsi:noNamespaceSchemaLocation="http://pmd.sf.net/ruleset_xml_schema.xsd">
<description>
All the rules except the ones we don't like
</description>
<rule ref="rulesets/basic.xml"/>
<rule ref="rulesets/braces.xml"/>
<rule ref="rulesets/clone.xml"/>
<rule ref="rulesets/codesize.xml"/>
<rule ref="rulesets/controversial.xml">
<exclude name="AtLeastOneConstructor" />
<exclude name="UnnecessaryConstructor" />
</rule>
<rule ref="rulesets/coupling.xml"/>
<rule ref="rulesets/design.xml">
<exclude name="UncommentedEmptyConstructor" />
<exclude name="UncommentedEmptyMethod" />
</rule>
<rule ref="rulesets/finalizers.xml"/>
<rule ref="rulesets/imports.xml"/>
<rule ref="rulesets/j2ee.xml"/>
<rule ref="rulesets/junit.xml">
<exclude name="TestClassWithoutTestCases" />
</rule>
<rule ref="rulesets/javabeans.xml"/>
<rule ref="rulesets/logging-java.xml">
<exclude name="SystemPrintln" />
</rule>
<rule ref="rulesets/naming.xml"/>
<rule ref="rulesets/optimizations.xml">
<exclude name="LocalVariableCouldBeFinal" />
</rule>
<rule ref="rulesets/scratchpad.xml"/>
<rule ref="rulesets/strictexception.xml">
<exclude name="SignatureDeclareThrowsException" />
</rule>
<rule ref="rulesets/strings.xml"/>
<rule ref="rulesets/sunsecure.xml"/>
<rule ref="rulesets/typeresolution.xml">
<exclude name="SignatureDeclareThrowsException" />
</rule>
<rule ref="rulesets/unusedcode.xml"/>
</ruleset>
Some of the rules, e.g. UnnecessaryConstructor, were excluded only because of the IDE generates test classes.
<?xml version="1.0"?>
<ruleset name="my_pmd_test_rules"
xmlns="http://pmd.sf.net/ruleset/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://pmd.sf.net/ruleset/1.0.0 http://pmd.sf.net/ruleset_xml_schema.xsd"
xsi:noNamespaceSchemaLocation="http://pmd.sf.net/ruleset_xml_schema.xsd">
<description>
All the rules except the ones we don't like
</description>
<rule ref="rulesets/basic.xml"/>
<rule ref="rulesets/braces.xml"/>
<rule ref="rulesets/clone.xml"/>
<rule ref="rulesets/codesize.xml"/>
<rule ref="rulesets/controversial.xml">
<exclude name="AtLeastOneConstructor" />
<exclude name="UnnecessaryConstructor" />
</rule>
<rule ref="rulesets/coupling.xml"/>
<rule ref="rulesets/design.xml">
<exclude name="UncommentedEmptyConstructor" />
<exclude name="UncommentedEmptyMethod" />
</rule>
<rule ref="rulesets/finalizers.xml"/>
<rule ref="rulesets/imports.xml"/>
<rule ref="rulesets/j2ee.xml"/>
<rule ref="rulesets/junit.xml">
<exclude name="TestClassWithoutTestCases" />
</rule>
<rule ref="rulesets/javabeans.xml"/>
<rule ref="rulesets/logging-java.xml">
<exclude name="SystemPrintln" />
</rule>
<rule ref="rulesets/naming.xml"/>
<rule ref="rulesets/optimizations.xml">
<exclude name="LocalVariableCouldBeFinal" />
</rule>
<rule ref="rulesets/scratchpad.xml"/>
<rule ref="rulesets/strictexception.xml">
<exclude name="SignatureDeclareThrowsException" />
</rule>
<rule ref="rulesets/strings.xml"/>
<rule ref="rulesets/sunsecure.xml"/>
<rule ref="rulesets/typeresolution.xml">
<exclude name="SignatureDeclareThrowsException" />
</rule>
<rule ref="rulesets/unusedcode.xml"/>
</ruleset>
Some of the rules, e.g. UnnecessaryConstructor, were excluded only because of the IDE generates test classes.
Etichette:
PMD
Monday, March 10, 2008
France not done for yet
Les Bleus defeated Italy 25-13 and they're still in for the victory of the tournament; we are all looking for the clash against Wales, as all the premises for a great and spectacular match are present. The French suffered against the Italian scrum, from which came a wonderful try by Castrogiovanni after an unstoppable maul, but walked over the backs, who probably thought tackling to be an optional. Well here's some piece of news... it is not.
Very nice try in the beginning by Floch, the first signal of the inability of the Italian backs to properly cover the field. Despite a good match by the forwards, the remaining French tries tell the story, and only a great save by Bergamasco saved Italy from a heavier gap.
Wooden spoon here we come...

Wooden spoon here we come...
Etichette:
rugby,
Six Nations 2008,
wooden spoon
Back in black


In a bad collision Balshaw literally broke Rory Lamont's face, and the winger will probably require a surgery even if he's recovering quite well from the concussion. Lamont's action was a very courageous one to do, while I think Balshaw knew he would never get that ball anyway, even if I'm sure he intended no harm to the Scot.
Looks like the Scots have avoided the wooden spoon... or have they? what we know for certain is that next week Italy will have to suffer. A lot.
Etichette:
rugby,
Six Nations 2008,
wooden spoon
Here comes the Triple Crown
Another great match by the Welsh who outruled Ireland, gaining the Triple Crown. Now only France stands between the Dragons and the Grand Slam. Way to go Wales!

They will have to avoid sin bins as they got two, and if in the first one they managed to hold Ireland's pace during the second one they underwent a six points comeback which brought Ireland just a point short. A pointless violence on Ryan Jones caused the referee to award a penalty with which Hook secured another three points that blew the Irish out of the match.
Shane Williams, who performed another great match, scored another wonderful try, while Shane Horgan missed for just a few inches thanks to a very-last-second/very-last-inch tackle, even if his action was a very good one.
Unluckily Brian O'Driscoll suffered a hamstring tear which will cause him to miss next week's clash against England.

They will have to avoid sin bins as they got two, and if in the first one they managed to hold Ireland's pace during the second one they underwent a six points comeback which brought Ireland just a point short. A pointless violence on Ryan Jones caused the referee to award a penalty with which Hook secured another three points that blew the Irish out of the match.

Unluckily Brian O'Driscoll suffered a hamstring tear which will cause him to miss next week's clash against England.
Etichette:
Grand Slam,
rugby,
Six Nations 2008
Web Service SOA Programming with Passion! Certificate
Thanks to Stanislaw Styszynski my certificate has arrived. Time to ask for a raise?
Etichette:
education,
Java,
SOA,
Web Services
Friday, March 7, 2008
PMD in NetBeans
PMD statically scans Java code looking for potential problems like unused variables, duplicated code, and a lot of other things. PMD is integrated with NetBeans, with the possibility to select the rules to apply and to have an online scan while coding.
PMD also offers an Ant task: we can add the following lines to the build.xml file:
<target depends="init" name="pmd">
<taskdef name="pmd" classname="net.sourceforge.pmd.ant.PMDTask" classpath="${libs.PMD.classpath}">
<pmd rulesetfiles="${pmd.dir}/my_pmd_rules.xml">
<formatter type="xml" tofile="pmd_report.xml"/>
<fileset dir="src/">
<include name="**/*.java"/>
</fileset>
</pmd>
</taskdef>
</target>
I have shown two different ways of referencing external files or libraries. For the PMD classpath I created a new library in NetBeans and used the variable libs.PMD.classpath that the IDE stored in the .netbeans/6.0/build.properties files in the user's home directory. For the ruleset files I added the pmd.dir property to the private/private.properties file.
Both approaches work, but the second is preferable if you have to build on a CI server, as the first method requires to add a library to the local NetBeans installation (you need to have one, as NetBeans build files use IDE-managed technologies); if you can only access the CI server via ssh this option is... not an option; you can always manually edit the build.properties files but IMHO it's a little awkward.
Modifying the private/private.properties files makes it easy to have different path on the developers' pc and on the CI server.
To define a set of rules you need to create an XML file as follows:
<?xml version="1.0"?>
<ruleset name="my_pmd_rules"
xmlns="http://pmd.sf.net/ruleset/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://pmd.sf.net/ruleset/1.0.0 http://pmd.sf.net/ruleset_xml_schema.xsd"
xsi:noNamespaceSchemaLocation="http://pmd.sf.net/ruleset_xml_schema.xsd">
<description>
All the rules except the ones we don't like
</description>
<rule ref="rulesets/basic.xml"/>
<rule ref="rulesets/braces.xml"/>
<rule ref="rulesets/clone.xml"/>
<rule ref="rulesets/codesize.xml"/>
<rule ref="rulesets/controversial.xml">
<exclude name="AtLeastOneConstructor" />
</rule>
<rule ref="rulesets/coupling.xml"/>
<rule ref="rulesets/design.xml"/>
<rule ref="rulesets/finalizers.xml"/>
<rule ref="rulesets/imports.xml"/>
<rule ref="rulesets/j2ee.xml"/>
<rule ref="rulesets/junit.xml"/>
<rule ref="rulesets/javabeans.xml"/>
<rule ref="rulesets/naming.xml"/>
<rule ref="rulesets/optimizations.xml">
<exclude name="LocalVariableCouldBeFinal" />
</rule>
<rule ref="rulesets/scratchpad.xml"/>
<rule ref="rulesets/strictexception.xml"/>
<rule ref="rulesets/strings.xml"/>
<rule ref="rulesets/sunsecure.xml"/>
<rule ref="rulesets/typeresolution.xml"/>
<rule ref="rulesets/unusedcode.xml"/>
</ruleset>
In this file I choose all the available rulesets and simply excluded the rules I don't mean to use; the syntax is straightforward.
If we wanted to check the test classes' sources it would suffice to add the following lines
<fileset dir="test/">
<include name="**/*.java"/>
</fileset>
to the pmd task, even if it would be better to define a new Ant target (e.g. pmd-testclasses) as test classes should be validated against different rules.
PMD also offers an Ant task: we can add the following lines to the build.xml file:
<target depends="init" name="pmd">
<taskdef name="pmd" classname="net.sourceforge.pmd.ant.PMDTask" classpath="${libs.PMD.classpath}">
<pmd rulesetfiles="${pmd.dir}/my_pmd_rules.xml">
<formatter type="xml" tofile="pmd_report.xml"/>
<fileset dir="src/">
<include name="**/*.java"/>
</fileset>
</pmd>
</taskdef>
</target>
I have shown two different ways of referencing external files or libraries. For the PMD classpath I created a new library in NetBeans and used the variable libs.PMD.classpath that the IDE stored in the .netbeans/6.0/build.properties files in the user's home directory. For the ruleset files I added the pmd.dir property to the private/private.properties file.
Both approaches work, but the second is preferable if you have to build on a CI server, as the first method requires to add a library to the local NetBeans installation (you need to have one, as NetBeans build files use IDE-managed technologies); if you can only access the CI server via ssh this option is... not an option; you can always manually edit the build.properties files but IMHO it's a little awkward.
Modifying the private/private.properties files makes it easy to have different path on the developers' pc and on the CI server.
To define a set of rules you need to create an XML file as follows:
<?xml version="1.0"?>
<ruleset name="my_pmd_rules"
xmlns="http://pmd.sf.net/ruleset/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://pmd.sf.net/ruleset/1.0.0 http://pmd.sf.net/ruleset_xml_schema.xsd"
xsi:noNamespaceSchemaLocation="http://pmd.sf.net/ruleset_xml_schema.xsd">
<description>
All the rules except the ones we don't like
</description>
<rule ref="rulesets/basic.xml"/>
<rule ref="rulesets/braces.xml"/>
<rule ref="rulesets/clone.xml"/>
<rule ref="rulesets/codesize.xml"/>
<rule ref="rulesets/controversial.xml">
<exclude name="AtLeastOneConstructor" />
</rule>
<rule ref="rulesets/coupling.xml"/>
<rule ref="rulesets/design.xml"/>
<rule ref="rulesets/finalizers.xml"/>
<rule ref="rulesets/imports.xml"/>
<rule ref="rulesets/j2ee.xml"/>
<rule ref="rulesets/junit.xml"/>
<rule ref="rulesets/javabeans.xml"/>
<rule ref="rulesets/naming.xml"/>
<rule ref="rulesets/optimizations.xml">
<exclude name="LocalVariableCouldBeFinal" />
</rule>
<rule ref="rulesets/scratchpad.xml"/>
<rule ref="rulesets/strictexception.xml"/>
<rule ref="rulesets/strings.xml"/>
<rule ref="rulesets/sunsecure.xml"/>
<rule ref="rulesets/typeresolution.xml"/>
<rule ref="rulesets/unusedcode.xml"/>
</ruleset>
In this file I choose all the available rulesets and simply excluded the rules I don't mean to use; the syntax is straightforward.
If we wanted to check the test classes' sources it would suffice to add the following lines
<fileset dir="test/">
<include name="**/*.java"/>
</fileset>
to the pmd task, even if it would be better to define a new Ant target (e.g. pmd-testclasses) as test classes should be validated against different rules.
Free Web Service SOA Programming with Passion! Online Course
The certificate will not be ready for another five days, but it looks like I've completed the wonderful (and free!) Web Service SOA Programming (with Passion!) online course. As always, Mr. Sang Shin has done a great job, so I cannot but invite you to attend the 4th session, which will start on May 1st, 2008.
This is Mr. Shin's second online course I've completed, and I'm actually taking the (free) Java EE (J2EE) Programming (with Passion!) course, even if I'm a little behind the schedule.
And, as always, Passion!
This is Mr. Shin's second online course I've completed, and I'm actually taking the (free) Java EE (J2EE) Programming (with Passion!) course, even if I'm a little behind the schedule.
And, as always, Passion!
Etichette:
education,
Java,
SOA,
Web Services
Thursday, March 6, 2008
My baby Hudson is growing...
We are starting a brand new project (er... that would actually be a third rework, as it is an inherited legacy application which had been already reworked twice from a previous group of developers) which will be the first real one on which we shall use a CI server; the selected product is Hudson, which I've tried a short time ago.
Installing on a separate server was a little more trickier than on my machine, on which I already had a fully working and customized version of NetBeans. Anyway, I was able to install and configure a bunch of features, e.g. access control and e-mail notification. I have also installed some plugins, like the Task Scanner plugin and the Violations plugin, configured to use PMD after quite a struggle - at least now I know something more about how NetBeans stores informations about libraries and build variables. More on this, including my temporary selection of rules, will follow.

Don't worry about the many broken builds, the project actually consists of a single class with a test class, and all the errors helped me experimenting :-)
Installing on a separate server was a little more trickier than on my machine, on which I already had a fully working and customized version of NetBeans. Anyway, I was able to install and configure a bunch of features, e.g. access control and e-mail notification. I have also installed some plugins, like the Task Scanner plugin and the Violations plugin, configured to use PMD after quite a struggle - at least now I know something more about how NetBeans stores informations about libraries and build variables. More on this, including my temporary selection of rules, will follow.

Don't worry about the many broken builds, the project actually consists of a single class with a test class, and all the errors helped me experimenting :-)
Etichette:
Continuous Integration,
Hudson,
PMD
Donate your blood
What are you waiting for? Become a blood donor! Yesterday I went to donate my blood, and all the staff was very professional, kind and nice - as it has always been in the past years. If you live or work near Milano you can find all the necessary informations on Padiglione Marangoni here.
Etichette:
blood service
Subscribe to:
Posts (Atom)