Now that the team I’m in has finished the first JEE6 application here, we are going to write the new JEE6 standard using our new shiny application as the muse to inspire us. So, instead of waiting for the end of the day to go and drown mi anguish I’ll go all Freudian and talk my problem out till I get some answers.

First, JEE6 is not an standard. JEE6 is set of technology specifications which build a platform to develop enterprise applications. Second, a technical standard is of free implementation but we want people to use it for good or worst, so we actually want a policy. Then, writing the JEE6 standard is plain wrong. It’s sound most likely we are trying to write the JEE6 Policy here.

Now, as suggested by a colleague, the limits within this policy is applicable must be drawn. OK, this policy is for applications with Web interfaces, both graphical and services. So, from now on everybody here writes Web applications with the policies described in this document. What about exceptions? Well, we can’t foresee all of them right now so we should add them one by one as an addendum as they appear. Who should dictate addendum in, addendum out? No, can’t be a policy. We already have enough bureaucracy.

All this policy thing makes me think people here can’t judge right from wrong, but they do. And actually, they are really competent. So how about writing some guidelines from our experience that we think might work on most situations and trust their judgment for the specific problem solving. This will make the number of thinking engineers overcome in number the soldiers awaiting for an order. The document could also grow in guidelines with the new experiences from this engineers solving problems on their own. It will be nice to have a wiki entrance with your name explaining how to solve a certain problem and add it to another where you have a different way to solve the same problem.

Sounds like a plan. So, “Guidelines for Developing with JEE6 in Here” it is, and it should be written in a wiki.

First thing to do is download the FitNesse jar file from the download page and save it with +x permissions where you want to execute it from.

Then, you need to create a fitnesse.desktop file in ~/.local/share/applications with the execution permissions (+x) and the  following content:
[Desktop Entry]
Name=FitNesse
Comment=The fully integrated standalone wiki and acceptance test framework.
Exec=/usr/local/lib/atdd/fitnesse.sh
Icon=/usr/local/lib/atdd/FitNesseLogo.gif
Terminal=false
Type=Application
StartupNotify=true
X-Ayatana-Desktop-Shortcuts=OpenNewTab;ShutDown
[OpenNewTab Shortcut Group]
Name=Open In Firefox
Exec=firefox -new-tab http://localhost:8081
TargetEnvironment=Unity
[ShutDown Shortcut Group]
Name=Shut Down
Exec=/usr/local/lib/atdd/fitnesse-shutdown.sh
TargetEnvironment=Unity

This creates the launcher and some right-click options. The “/usr/local/lib/atdd” path is where the FitNesse jar is and the image for the icon is FitNesse’s logo. The fitnesse.sh and fitnesse-shutdown.sh files are a few bash commands to start and stop FitNesse, shown below for completeness. Once this file is ready, open the ~/.local/share/applications folder and drag the fitnesse.deskop file and drop it into the unity panel. And that’s it to get your customized launcher.

fitnesse.sh

#!/bin/bash
fitnesse_home="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
port="8081"
clear
echo "Starting FitNesse in port $port"
echo "FitNesse home is $fitnesse_home"
echo "..."
java -jar $fitnesse_home/fitnesse.jar -p $port

fitnesse-shutdown.sh
#!/bin/bash
fitnesse_home="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
port="8081"
clear
echo "Shutting down FitNesse in port $port"
echo "..."
java -cp $fitnesse_home/fitnesse.jar fitnesse.Shutdown -p $port

Reference:

ask ubuntu, question 13758

Desktop file specification extension

Starting and stopping FitNesse

At our current project we have six to ten souls constantly pushing changes to the source version control every day which necessarily causes some builds to fail. Since code auditing reports are run in the same CI server’s job they get lacerated by these fails and drops the continuous line report causing statistics to be damaged -specially when it takes more than the next integration attempt to fix the problem.

Finding our statistics broken due to code that failed to integrate automatically smells like the job has more than one purpose, and as code, it shouldn’t. So, the obvious solution is to refactor applying a variation of extract class, called extract job. The mechanics are very simple, remove from the job’s goals the site goal, living the install goal alone, and rename if necessary. Then, add a new job which will run only if the former has completed successfully, even if unstable, with the site goal.

Once responsibilities are separated you’ll enjoy of statistics that aren’t harmed by failing integration jobs.

A couple of months ago our project entered in total-madness mode. We were weeks away from the release and some bugs were still pending – a few critical. So, the management solution was dictated: All of the resources (meaning the members of the development team) will work as long as 24 hours per day if necessary until the bugs list is reduced to zero.

This situation led to people trying to solve as many issues per day as possible. In this noble task of course unit test got in our way taking up to five seconds in running, but that wasn’t the worst of it, they sometimes failed! So facing such an uncooperative response from the unit tests, they were simply ignored and skipped. This caused the CI server to constantly whine by mail about unstable builds and not seldom even broken builds.

This situation went on for a week or so and more bugs started to show up, PMD and Findbugs reports started to rise and people couldn’t commit often because the code base was not to be trust anymore. WTF/minute rate was sky-high and all the effort was becoming counter productive. So, we realized the release was not going to be bug’s free because time was not enough to fix them all and that we needed to cool down our pace. We still worked many hours, but those hours went back to productive.

First thing we did, when thinking again, was to put those unit test back to operative. That, just that, fixed 25% of the current list of bugs which was huge move toward the goal. After that, new fixed bugs produced almost boomerang-free releases to QA. The release went live washed out of all the critical bugs on the application, the core module was released with zero known-bugs, and the total pending bugs was reduced to the 40% of the original list.

The release didn’t include a dream-like artifact, some even considered the project had failed, but a very decent one. It accomplishes its raison d’être very well and performs under the processing time restrictions. All thanks to working out our code regularly.

This makes you feel a little bit like for fifty+ years there have been many of us struggling with the same problems and several have succeeded in their quests and have documented their findings. Making a software bible out of the best titles doesn’t sound right. Just to propose choosing the “best titles” should unleash the Wrath of God. But we still need this one source where to concentrate knowledge and if there were someone to guide in the learning process… Dreamy.

These books you usually would read after you’re finished becoming an engineer. You know, after five years of preparing your brain to solve problems with Mathematics, Geometry and Physics, and, learning generalities on computing-related matters like networking, programming, IT auditing, etc, won’t get you too far on your first programming job when you discover you should not use JDBC but some JPA layer in the JEE architecture to make that query. Difficult.

Adding more years to school is not a solution. Actually everybody is trying to make it shorter and easier to become an engineer so more people want to be one, regardless of the sucky professionals they might spit out to the market. Plain irresponsible.

What if universities teach basics and generalities for three years and then you have to choose an specialization, let’s say on software development, so that you spend two years learning the many ways to point at and solve the right problem. This is not new, it’s what they do in Psychology. Mastering all about computers nowadays reaches far beyond the eyes can see and competitivity won’t forgive those who know a bit of everything. That’s knowing nothing.

Spending two years learning structural, object oriented, functional and more programming and how to test it will sure make a better programmer. Learn formal and agile methodologies to track your project growing will make you at least aware of the tools at your disposal. Learn TDD, BDD, specification by example and you will aim your effort to the right problem. Have a teacher assisting you in the learning process of something you chose to get good at and those two years will be a delightful journey.

What I mean is education on computing science at under degree level should rely on specialization during the last years.