Interview: John Ferguson Smart, Author of Java Power Tools
Java Power Tools which will be released around Match 2008, covers 30 open source tools designed to improve the development practices of Java developers. As per O'Reilly each chapter includes a series of short articles about one particular tool -- whether it's for build systems, version control, or other aspects of the development process -- giving you the equivalent of 30 short reference books in one package. Javalobby had the opportunity to talk to John and find out more about his book.
1. John, can you tell us a bit about yourself and your work?
I'm a freelance consultant specialising in Enterprise Java and Open Source Java technologies. I've been programming since I convinced my father to buy me a TI-99/4A back in 1982. On the academic front, I have a PhD in Maths and Computer Science. I've worked in many companies over the years, as a developer, project manager, trainer and solutions architect, on a wide range of projects. I started off with C++, and have been working with Java since 1999. I'm a strong proponent of development best practices, such as coding standards, automated testing, continuous integration, and version control. Currently, I can usually be found helping large companies or government organisations on Enterprise Java projects, and in particular using open source technologies such as Spring and Hibernate. In the process, clients often ask me to help them optimize their development practices and infrastructure, to set up a continous integration environments, and to provide coaching, mentoring and training in open source technologies and agile development methods.
2. Why did you decide to write a book on open source tools?
These are tools I use every day, and in my experience, knowing about them and using them well is a great way to improve the quality of your code, and also to make your life as a developer much more satisfying. Once you introduce a well-tuned set of SDLC tools in a project, there's no turning back. It is really a revolutionary change in the way you work. It's like moving from snail-mail and faxes to email, IM and video-conferences. Or from fighting a war with swords and shields to using tanks and jets.
And the best thing is that often, the tools are free!
Don't get me wrong, there are some good commercial tools out there. But nowadays, you don't have to spend a lot of money to get a good set of development tools.
So I thought other people might be able to benefit from my experience in this area.
3. Who is your target audience?
First of all Java developers who want to improve their skills by adding new tools and techniques to their repertoire. Also, team leaders, project managers, solutions architects and the like, who need to come up with a good set of tools and recommended practices for their project or organisation.
4. What are the open source tools you are covering in this book?
There are quite a few. The book covers most of the software development lifecycle, at least from a developer's perspective. It starts off with a section on build scripting tools, where I cover the two big players, Ant and Maven 2. Then I move on to version control software, with CVS and Subversion. With these two bases covered, we come to Continous Integration. This is a big section, and one of my favorites, with four of the more interesting open source CI tools: CruiseControl, Continuum, LuntBuild and Hudson. And since team communication is important, we also look at how to set up an IM server with Openfire.
Next, we look at testing, and cover JUnit 4 and TestNG for unit testing, Cobertura for test coverage, as well as a swath integration and performance testing tools, including StrutsTestCase, DBUnit, JUnitPerf, JMeter, JConsole, the Eclipse profiling tools, SoapUI, Selenium and FEST.
We also look at two issue management tools: Bugzilla and Trac.
There is also a section dedicated to improving code quality. This section discusses static analysis tools like Checkstyle, PMD and FindBugs, but also covers Jupiter, a tool that facilitates code reviews, and Mylyn, which help you work more efficiently in Eclipse. Another chapter looks at Qalab and StatSVN, which help keep track of project metrics over time. Another section looks at how to generate decent technical documentation, both using Maven and using other tools such as SchemaSpy, Doxygen, and UmlGraph.
In all, the book looks at 30 or so tools.
5. Why did you decide to include these tools?
Choice is good, and there is no one-size-fits-all solution for software development. So, in each section, I try to give an overview of the best open source products around for a particular job, so that readers can decide for themselves what stack suits them best. And I try to cover all of the main areas in the development process where open source tools can help your average developer. Version control, build scripting, automated testing, continous integration, issue tracking, coding standards and best practices, automated code documentation: you need to take care of all of these areas well so that the developers can get on with their main job: coding.
When you set up a development environment, it's also important to have products that integrate well. In the book, I spend a fair bit of time discussing how to get the various tools to work smoothly with each other. For example, one nice trick is using Subversion triggers to integrate Trac with Subversion, so that when you mention a Trac issue number in a Subversion commit message, the issue is automatically updated in Trac with a reference to the modified files. Then, taking this one step further, you can use Mylyn change sets to keep track of exactly what files have been modified for a particular bug fix.
6. Are these the most popular ones?
Usually, yes. One of my selection criteria was that tools should have a large enough user community to be sustainable in the long term.
7. Is each of these open source tools covered in great detail?
I do tend to go into a fair bit of detail, yes. At around 880 pages, it's certainly not just an overview! Of course, some are more detailed than others. Maven 2, Ant, and Subversion get around 100 pages each. Other tools typically get about 30 pages each. Each chapter is much more in the spirit of a practical reference manual, rather than just a short overview of the tool.
8. How long did it take you to write this book?
A lot more than I thought it would! I only kept roughly on schedule by working lots of very late nights and sacrificing weekends. Equinox, and in particular Roger Dalgleish and Paul Ramsey, also helped enormously, who gave me time and material support for the book when it was really needed. The whole thing took a little over a year, plus another 6 months or so for the corrections and publication process.
9. Which is your favorite tool and why?
OK, just one? At the moment, I'm pretty impressed with Hudson. It is very easy to use, has a slick user interface, and you can set up a very usable Continuous Integration environment fast and with a minimum of effort. And all the plugins make reporting a breeze!
10. Can you give us some useful tips and tricks?
There's an old Maori saying which goes "He aha te mea nui? He tangata, He tangata, He tangata." Which translates to something like "What is the most important thing? It is people, it is people, it is people". I think this is true when you try to improve the software development process in an organisation. You really need to get team buy-in when you choose tools, especially ones that impacts the way developpers work on a daily basis. Make it a collaborative process, and make sure everyone involved understands what the tools are for and how they should be used. It's usually a slow process, since people are often reluctant to change their old habits, but it pays off in the long run.
11. Are you using each of the tools you have mentioned above in your projects?
Pretty much. A big part of my day job is to help organisations improve their software development process, and this involves proposing and installing tools, and teaching people how to use them. Of course, I have my preferences, and you have to make choices at some stage. For example, I've used CruiseControl, Continuum and Hudson in real projects for different clients over the last few years, but for a particular client, you only need one Continuous Integration tool.
We even used some of the tools while writing the book. The book was written directly in docbook format, and stored on a Subversion repository. The editor, some of the braver technical reviewers and (not leastly!) myself also used Trac to keep tabs on changes being made to the manuscript, to plan the review process, to let reviewers know when a chapter was ready for review, and so on. So we were eating our own dog food, so to speak!