APIFest08:Report
From APIDesign
| Line 6: | Line 6: | ||
The [[APIFest08:TaskX|judgment round]] is in fact the start of the real competition. However it is also much more difficult than the first four rounds. Instead of looking into own solution, one needs to dig into solutions provided by others and seek for left compatibility problems which is different and time consuming. Still I am glad that two participants, '''Petr Šmíd''' and '''Jan Žák''' did not give up and sent me their hacks showing [[BackwardCompatibility]] evolution problems in many solutions. | The [[APIFest08:TaskX|judgment round]] is in fact the start of the real competition. However it is also much more difficult than the first four rounds. Instead of looking into own solution, one needs to dig into solutions provided by others and seek for left compatibility problems which is different and time consuming. Still I am glad that two participants, '''Petr Šmíd''' and '''Jan Žák''' did not give up and sent me their hacks showing [[BackwardCompatibility]] evolution problems in many solutions. | ||
| + | |||
| + | === Problems in Solution 04 === | ||
| + | |||
| + | Both guys managed to find a problem in solution 04. There were multiple problems as demonstrated by [http://source.apidesign.org/hg/apifest08/file/2ae6e4aa7aef/taskx/psmid/against-solution04/test/apifest/CurrencyTest.java Petr], however the most obvious one was source incompatibility caused by the addition of new method into a subclassable interface as shown by [http://source.apidesign.org/hg/apifest08/file/621462e58e22/taskx/ked/against-solution04/test/apifest/CurrencyTest.java Jan] and [http://source.apidesign.org/hg/apifest08/file/2ae6e4aa7aef/taskx/jtulach/against-solution04/test/apifest/CurrencyTest.java me]. The lesson to take is that if one is seeking for 100% [[BackwardCompatibility]] one needs to prevent modifications to classes that can be subclassed. | ||
Revision as of 06:57, 26 October 2008
The celebration of 10 years of NetBeans releases is in progress and that is why it is also time to celebrate all those who contributed to the NetBeans architecture, and design practices which makes NetBeans platform the most stable Java rich client application framework.
The best way to have fun is to play games. The best way to learn is to play as well. The best way to teach is to organize such game. When me and CZJUG lead Jakub Podlešák realized that, we decided to organize similar game as described in Chapter 17 of TheAPIBook. It is a game to teach, learn and have fun while designing architecture and APIs and practising backward compatibility principles in software interfaces.
There were four base rounds ([[APIFest08:Task1.5|1], 2, 3, 4) in the APIFest08. We started with fourteen participants. However as the competition advanced further and further, only those who really eager to win managed to finish all four design tasks. Still, six solutions advanced to the final judgment day/week.
The judgment round is in fact the start of the real competition. However it is also much more difficult than the first four rounds. Instead of looking into own solution, one needs to dig into solutions provided by others and seek for left compatibility problems which is different and time consuming. Still I am glad that two participants, Petr Šmíd and Jan Žák did not give up and sent me their hacks showing BackwardCompatibility evolution problems in many solutions.
Problems in Solution 04
Both guys managed to find a problem in solution 04. There were multiple problems as demonstrated by Petr, however the most obvious one was source incompatibility caused by the addition of new method into a subclassable interface as shown by Jan and me. The lesson to take is that if one is seeking for 100% BackwardCompatibility one needs to prevent modifications to classes that can be subclassed.
Follow
