We mix expertise and a passion for continuous process improvement practices with in-depth technical know-how. We drive, implement and guide optimal, measureable change within businesses. This is what we are best at.

We are pleased to offer these services to support customers of Appian’s leading enterprise, mobile and cloud-based BPM solutions. Centrum and Appian will work together to deliver the right people, practices, operational framework and technology in a pragmatic and collaborative partnership with our customers.

View Press Release

Neo Technology delivers the world’s leading high performance, scalable graph database and Centrum is excited to be supporting businesses that are leveraging this technology in the Australian marketplace. We can see that master data management issues, the strategic importance of social networking and the increasing complexity of enterprise networks all call for a re-think of how customers handle their growing volumes of inter-connected, ever-changing data.

We will bring our experience implementing enterprise systems solutions combined with our deep, Java-based technical know-how and passion for achieving quality business outcomes to a wider group of customers to help address these challenges in partnership with Neo Technology.

Bug Fixes

The following defects have been resolved. Remaining defects are visible from the google code issue tracker (http://code.google.com/p/build-pipeline-plugin/issues/list).

Documentation

The documentation is available from the Hudson and Jenkins wikis.

The Talk

Completing the circle: Automated web tests, ATDD and Acceptance Tests as a team communication tool

Acceptance Test Driven Development, or ATDD, has proven to be a very effective technique, both for driving and guiding development, and for enhancing communication between developers and other project stakeholders. But why stop there? Well designed Acceptance Tests can also act as a formidable documentation source and communication tool. Indeed, when written in a narrative, BDD-type style, Acceptance Tests have the potential to document in detail how the user interacts with the application.
In this talk we will look at the role of automated Acceptance Tests not only for testing, but also as part of the whole development lifecycle, from writing the user stories right through to deploying the application. We will also look at ways to make your automated acceptance tests more expressive and how to use them more effectively as a communication, reporting and documentation tool.
Finally, we will present and demonstrate a new open source library that helps developers and testers write automated acceptance tests for web applications using WebDriver/Selenium 2. This library also produces clean, narrative-style reports illustrated with screenshots that effectively describe the application’s functionality and behaviour, as well as any regressions or pending features.

The Speaker

CEO of Wakaleo Consulting, John is an experienced consultant and trainer specialising in Enterprise Java, Web Development, and Open Source technologies. John is well known in the Java community for his many published articles, and as author of Java Power Tools, and Jenkins: The Definitive Guide.
John helps organisations around the world to improve their Java development processes and infrastructures and provides training and mentoring in open source technologies, Test Driven Development (TDD, BDD and ATDD), Automated Web Testing, SDLC tools, and agile development processes in general.

The Begging

A fascinating subject that should give you some great ideas and techniques to take back to your team.
This is our first joint event and we’d really appreciate your support. We’ve booked a big room and need to fill it! PLEASE BRING YOUR FRIENDS…

When

Thursday, June 23, 2011 from 5:00 PM – 8:00 PM (GMT+1000)

Where

Combined Services Club (upstairs)
5-7 Barrack Street
(Cnr of Clarence, next to Officeworks)
Sydney, New South Wales 2000
Australia

Registration

So complete the free registration at: http://bettersoftwarebriefing.eventbrite.com

NEW FEATURES

1. Retry Failed Jobs

If a job in the pipeline fails, the job will now display a “Retry” button. This allows the user to retry this job, with the parent build remaining as the trigger and continue the build pipeline.

2. Restrict the Trigger Button to the Latest Build

When configuring a build pipeline view a new option “Restrict Trigger to the Most Recent Build” has been added.
If set to “Yes” it will only allow the most recent build pipeline to display a “Trigger” button.
If set to “No” all builds displayed on the view will have a manual trigger button.

BUG FIXES

The following defects have been resolved. Remaining defects are visible from the google code issue tracker (http://code.google.com/p/build-pipeline-plugin/issues/list).

DOCUMENTATION

The documentation is available from the Hudson and Jenkins wikis.

New Features

1. Build Parameters Inherited by Downstream Jobs

If the parent job has parameters defined, those parameters are passed down to all subsequent child jobs for manual jobs.  Note: an automatically triggered downstream job should use the parameterised trigger plugin to achieve the same…

Bug Fixes

The following defects have been resolved. Remaining defects are visible from the google code issue tracker (http://code.google.com/p/build-pipeline-plugin/issues/list).

Documentation

The documentation is available from the Hudson and Jenkins wikis.

Agile Australia is going to be packed with case-studies of how leading businesses are adopting an Agile approach to stay ahead!   As well as Agile dignitaries Alistair Cockburn and Martin Fowler, international Agile guru Jean Tabaka, and celebrated Australian industry author Rob Thomsett

• Learn how to respond quickly to change, minimise overall risk, improve quality, and enhance project outcomes
• Discover compelling examples of innovation and business value achieved through Agile

Please come to our stand and say hello…

Most mature software development companies or departments define their coding standards.  The intentions is simple; ensure all code looks alike to ease reading, writing, maintaining and communicating code.  As a first effort, these coding conventions may be expressed in some form of standalone document, but conventions that are not being enforced are simply a waste of time.  In the Java world, various tools have existed for some time now, helping us to enforce and adhere to coding standards; Checkstyle, Eclipse and Sonar.   Until fairly recently, it has been laborious to make those tool work together and help us achieve code consistency.  Thankfully, as the mentioned tools matured, it is now possible to define and enforce coding standards effortlessly and the synergy between these tools may even be surprising.

Recap

Lets quickly state the purpose of each tool before we move on.

Checkstyle

Checkstyle is a development tool to help programmers write Java code that adheres to a coding standard. It automates the process of checking Java code to spare humans of this boring (but important) task. This makes it ideal for projects that want to enforce a coding standard.

Eclipse formatter

The Eclipse formatter is a set of rules that defines how code will be formatted.

Eclipse clean up

The clean up utility helps to apply formatting rules and coding conventions to a single file or to a set of files in one go.

Eclipse save actions

Save actions are similar to clean up and they define what should happen to the code when a file is saved.  For example, save actions can ensure code is formatted, unused imports are removed and arguments are set to “final” right before the file is saved.

Sonar

Sonar is an open platform to manage code quality.

A common situation

It would be quite common to define coding standards using Checkstyle and including it as part of a project.  Then Eclipse formatter, clean up and save actions would be configured manually to match the Checkstyle rules.  In addition, Checkstyle would run as part of a build to publish the code violations report to a file or to Sonar.  Some better integrated teams would also use the Checkstyle Eclipse plugin in order to see the violations in their code and as code would change and adhere to standards, the Checkstyle Eclipse plugin would reflect that.

Shortcomings

The common situation outlined above is a decent setup but it has some shortcomings.  If the coding standard rules change, that sends a ripple through all the tools.  The Eclipse formatter needs to reflect the new coding standard rules, as well as the clean up and the save actions.  Furthermore, Sonar needs to be updated with the new rules.  In addition, sharing the Checkstyle file between projects and teams can become a choir.  There are ways to define a remote coding standard file used between teams but that does not address the lack of synchronisation between all the tools … until recently.

Harmony

Checkstyle, Sonar and Eclipse have been around for a long time and as these tools matured they developed great integration between them.  By aligning these tools it is possible to establish one central coding standard rule set and reflect those in the development environment automatically.  Furthermore, once configured, changes to coding standards are propagated automatically and developers are always informed about up to date coding standards and apply them as they code.

Example

Lets look at an example on how to best utilise Checkstyle, Eclipse and Sonar.  In addition, to give the example more relevance, lets start with an existing “legacy” project where coding standards have not necessarily been respected.

Assumptions

The example assumes the following:

• Java project
• Maven build
• Checkstyle file expressing the coding standards
• Sonar
• Eclipse
• Eclipse checkstyle plugin
• Eclipse sonar plugin

Initial coding standard report

We’ll start from the point where an initial Checkstyle configuration has been uploaded to Sonar and a Sonar report has been produced for our existing project.

View and reduce violations in the IDE

Next, we’ll configure Eclipse to see those violations closer to the code.  In order to do so, we’ll need to configure the Eclipse Checkstyle plugin with the same rules as Sonar and apply the configuration to the projects.

1. A link to the Checkstyle configuration
   
   
   
   
2. Reference to the Checkstyle rules in eclipse (Window > Preferences > Checkstyle > New)
   
3. Configure Checkstyle for a project (right click project > Properties > Checkstyle).  Please note the Write formatter/cleanup config checkbox.  This is the part that synchronises the coding standards with the Eclipse formatter and clean up.  You can also right click on your project > Checkstyle > Create Formatter-Profile to achieve the same thing.  This kind of synchronisation alleviates the painful manual synchronisation between Checkstyle and Eclipse; brilliant!
   
4. Once Checkstyle has been configured and enabled for a project, notice that violations are annotated by the code
   
5. Now that Eclipse has been configured with the coding standard rules and formatting profiles have been updated, we can bulk clean up existing code and go a long way to ensure the code adheres to standards.  After pressing Next > (to review upcoming changes) or Finish, Eclipse would do what it can to help the code to adhere to standards.
   
   
6. After republishing a code standard report to Sonar, we can see a reduction in violations
   

Save actions

Once the Eclipse formatter and clean up profiles have been updated, don’t forget to update save actions so that as many coding standards are automatically applied as soon as possible (before every save).

Eclipse Sonar integration

Similarly to the Checkstyle Eclipse  plugin, there is a Sonar Eclipse plugin that will annotate code with the violations as seen in Sonar.  In addition to showing Checkstyle violations, the Sonar Eclipse plugin would show Findbugs and PMD violations (all static code analysis tools configured).  The integration is quite simple.

1. Install the Sonar Eclipse plugin
2. Identify your Sonar installation
   
3. Associate your Eclipse  projects with their Sonar equivalents (notice that your project has to have at least one Sonar report published)
   
4. Once the configuration is complete, you can see the violations as published to Sonar annotated in your code
   
5. Please note that the code has been annotated with the violations as it was found in Sonar.  If code changes are made, those violations will remain and get out of sync.  Alternatively, you can choose to rerun the checks locally and refresh the violations view.
   

The usefulness of the Checkstyle Eclipse plugin

Although the Sonar Eclipse plugin may make the Checkstyle Eclipse plugin look superfluous, remember that it is the latter that updates the Eclipse formatting rules as well as the clean up profiles.  If or until the Sonar Eclipse plugin fulfils the same duty, the Checkstyle Eclipse plugin remains very useful.

Not everything can be automated

Please note that although a lot of coding standards can be applied retroactively and automatically, some violations cannot be automatically eradicated.  Nonetheless, Checkstyle, Eclipse and Sonar can identify the problematic code and guide developers towards coding standard compliance.

Conclusion

Coding standards are a preoccupation for most software development teams.  Defining coding standards is one things but enforcing them effectively is another.  Thankfully as Checkstyle, Eclipse and Sonar matured, coding standard definition and enforcement can be a straightforward and a sustainable activity.

The popular open source continuous integration server, Hudson, forked a few months ago.  Its creator, Kohsuke Kawaguchi, along with a larger part of the open source community forked Hudson and created Jenkins. As for Hudson, it is now under the Oracle and Sonatype umbrella.

In the meantime, we at Centrum Systems were writing the build pipeline plugin.  Not wanting to take sides, we decided to release the plugin to both Hudson and Jenkins.  Having released version 1.0.0 of the plugin and receiving a lot of positive and constructive feedback, we wanted to correct some problems with the plugin, while adding some requested features.  I’ll try and summarize our experience of releasing the plugin to either platform.

Hudson

1. Publish the plugin using the same mechanism we used to publish 1.0.0
2. Realize the old process changed since the plugin was deployed to the same repository but it would not appear in Hudson’s update center
3. Read the new release process and comply to it
4. Create a JIRA user
5. Miss a few points and ask Oracle for some help
6. Create a JIRA ticket expressing our willingness to publish the plugin
7. Wait for someone to address the ticket and give us rights to publish to the staging repository
8. Change the build to ensure the artifacts were signed as per the following instructions
9. Publish the plugin using release:prepare, release:perform (and the corresponding deployment management configuration as described in step 3)
10. Log on to Sonatype’s Nexus instance and “close” the deployment (some verifications were performed on the plugin)
11. The verification failed and I needed to publish our public key to a keys server (actually, the error message was really clear and helpful)
12. “Release” our plugin within Sonatype’s Nexus workflow (a single click, similar to step 10)
13. Comment on the original JIRA ticket to ask them to release the plugin for real (to the maven 2 repo)
14. Wait a while for the JSON file listing all Hudson plugins to be updated and show the availability of a new version

Elapsed time: About 6 working days

Jenkins

1. Publish the plugin using the same mechanism we used to publish 1.0.0 (create an account, add the distribution management information in the pom file, update the settings.xml file with the server information)
2. Wait a few hours for the JSON file listing all Jenkins plugins to be updated  and show the availability of a new version

Elapsed time: A few hours

Conclusion

I can certainly appreciate the steps to sign the plugin and the extra validations ensuring the plugin has all the right elements, but the Hudson process felt a bit heavy.  Hopefully the next release will not be as tedious since we learned quite a bit during the exercise.  Finally, I would like to thank Winston from Oracle since he was helpful and responsive and all other people involved in the process.  I would also like to thank the Jenkins people since the publishing process was nice, streamlined and uneventful (in a good way).

The fact that Jenkins has had 11 new versions whilst Hudson has had only 2 since the fork is indicative of the different approaches.

BUG FIXES

The following defects have been resolved. Remaining defects are visible from the google code issue tracker (http://code.google.com/p/build-pipeline-plugin/issues/list).