Slashdot Mirror
Pragmatic Project Automation
The first 2 (or possibly 3) books are Pragmatic Version Control with CVS and Pragmatic Unit Testing (which is available in Java and .NET flavours).
Pragmatic Project Automation is the latest book in the series and, interestingly, this book wasn't actually written by either Dave Thomas or Andy Hunt, but by Mike Clark (contributor to the 'Bitter EJB' book, editor of the JUnit FAQ, and responsible for the JUnitPerf and JDepend tools). Mike does a great job of ensuring this book fits in with the overall style of the other books in the series.
Up front, in case you're a "cut to the chase kind of guy," this book (and the others in the series) are must-haves and as a consultant with ThoughtWorks I'll have a set ready to distribute whenever I start working with a new client team.
Content The book helps the reader build a Java project slowly over the chapters, starting with a manual build-and-deploy process and automating a new aspect of it, chapter by chapter, until by the end of the book the software compiles, archives, deploys and configures itself multiple times a day. In addition, the build tools notify you of success or failure in a variety of interesting ways including email, SMS messages and different colored lava lamps.
The first chapter provides a good introduction to the different types of automation available to projects. It also introduces the acronym 'CRISP' to help the reader remember the desirable characteristics of an ideal build process: Complete, Repeatable, Informative, Scheduled and Portable.
Chapter 2 gets you Repeatable by using ANT to bring together all the various steps you currently perform on your project into a single, one-click build. Chapter 3 works to turn the one-click build into a no-click build using tools as simple as cron as well as more complicated tools like the ANT scheduling tool CruiseControl. By the end of these two chapters your software can be compiling and testing itself automatically each time changes are checked into the version control system. But this is only the beginning.
Chapters 4 and 5 address the "Complete" and "Portable" portions of the CRISP model discussing how to include packaging, release management and deployment into your scheduled build. The last chapter addresses "Informative." How to monitor the build for success or failure, how to notify members of the project team using email, SMS, RSS or even the red and green Lava Lamps I mentioned above.
Summary This book, and the others in the series, provide a much needed set of manuals for getting a good set of basic practices up and running at the start of a project. Unlike the Unit Testing book, there's not a lot of programming in this one, but it's a worthwhile read for any programmer, regardless of experience level.
Many people are becoming interested in eXtreme Programming and Agile methods for software development. These books help to support some of the key ideas of those methods - extensive unit testing and continuous integration.
The main flaw in the book doesn't affect its usefulness, only its readability. Of all the files used in the sample project, the only one covered in any detail is the build file. The source and manifest files that we're writing the ANT file to build are never discussed or described - we are left to guess at what the sample project might contain (unless we download the code from the website). While this didn't change what I was learning (how to manipulate the project files with ANT), I like to understand all the details and this omission did occasionally leave me a little irritated.
You can purchase Pragmatic Project Automation from bn.com. Slashdot welcomes readers' book reviews. To see your own review here, carefully read the book review guidelines, then visit the submission page. If you are interested in the Pragmatic Programmers, see also this interview linked earlier from Slashdot.
The Pragmatic Programmers seem to be doing a great job with their new publishing efforts. They're able to get new titles out much more quickly than some of the more established publishers by following their own advice about automation and applying it to publishing. I recall reading on one of their blogs that they were able to go from idea to actual book in under six months.
I can't wait for their upcoming Ruby book.
...is right here.
It uses Java to talk to the serial port... seems like a good application for ruby-serial, too...
The Army reading list
Probably most of us already know what these are, but for those who don't:
Extreme Programming.
Agile software development.
That's also the home page for the book with downloaded code samples and so on.
thanks!
I did XP in extreme C++ for about a year (by extreme C++, I mean boostified, Alexandrescu'd C++). We used CppUnit for our test framework.
I'm not especially satisfied with the currently available C++ unit testing frameworks. CppUnit and Boost's both have trade-offs. I suspect they'll both get better, though.
The Ant-Contrib project's cc task works pretty well, in my limited experience. I was playing around with it just this weekend. I've yet to set up a tinderbox build process, but I don't see why this wouldn't be easy with either Cruise Control or good ol' cron.
In my mind, the two biggest hurdles with doing XP in C++ are build speed and developer prejudice. You can tackle build speed with a combination of ccache, distcc, good programming principles, and cash. Tackling developer prejudice is harder. A lot of C++ programmers like to write low-level, unsafe, old school C++ code. Modern C++ mostly lets you discard unsafe coding practices without sacrificing efficiency. Whether you can convince an old C++ programmer of this is another matter; it depends on the person. I've had decent success taking Java programmers and teaching them modern C++ via pair programming.
Using Boost helps, indirectly. You write safer code, which gives you a faster development cycle. All in all, I think the basic tools are there. It might be a little harder to get fancy lava lamp integration going with C++, but there's no reason why you can't have a good build process. It's just that a lot of C++ projects haven't evolved (I think this is due, in part, to the fact that the C++ community is late to the internet; a lot of C++ programmers just don't know what's, out there.
cheers,
Jon
On my current project, we've used Cruise Control for continuous integration and to run our suite of Junit tests (2500 tests and counting now) for the last 20 months or so..on a largish J2EE app (800+ ejbs, 30 developers, 3 distinct client builds), it makes sense and helps keep in check the stability of the app..
I like this book and the review is good, but take the review with a grain of salt. The reviewer is a Thought Works consultant. The book spends some solid time on CruiseControl which is a Thought Works donation to the open source community. That he likes it isn't too much of a surprise - particularly since the book, in fact, is quite good.