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.
Not really an offtopic question (at least as far as it relates to general pragmatism vs. an idealistic "every bit must be polished to a mirror-like hue" development approach). However... all software exists to "do stuff". If it's not there in time, then it's just wasted disk space and it inconveniences the hell out of the other folks that were depending on that software to do their thing. Therefore, on-time delivery is not always just a nice-to-have, and being pragmatic about architecture and feature sets can produce better code in the end.
Less is more.
This book seems like a good one for all developers to read. I'm honestly only about half way though it, but I've skimmed the whole thing.
The big thing that jumps out at me is that he promotes how cool CruiseControl is for automating builds, but uses cron for his release builds. Generally, I would want to use the same tool to create my continuous integration, nightly and production release builds. I was under the impression that there were ways to make that happen in CruiseControl.
disclaimer: I help write a product that does do this, so maybe I'm just projecting biases.
The section on diagnostics also looks quite interesting, but I'm not that far yet.
>I found the best recommendation from my shelf to be "Computer Hardware Theory" (1972 University of Illinois) and "Fundamentals of Signal Theory" (1960).
Two books from 30 years ago on computer hardware and one is on Signal Theory?
Unless I'm doing assembly, could you explain why these books would be good for me, a programmer?
The surprise isn't how often we make bad choices; the surprise is how seldom they defeat us.
I thought he was joking. Maybe he was and the moderators didn't get it. No way is "Art of Computer Programming" a book about "applying code to real-world situations". Interesting academic information, yes, but not exactly mainstream stuff.
The fact that it got modded up is alarming.
mt
What other wheels have you re-invented?
Simple tools for nearly everything you mentioned already exist.
Comparing Pragmatic Programmer to The Art of Computer Programming is like saying that raisins are just like prunes because they both make you go to the bathroom if you eat enough of them.
Don't get me wrong, I absolutely love Pragmatic Programmer and would consider it a classic, but TAOCP clearly has more, ummm, fiber.
Do you really think that your book is "focused on kind of the same area" as _The Art of Computer Programming_? I have read both books, and really don't understand how you could consider this to be the case. I do consider your book to be one of the two best in the area it covers though, and reccomend it highly.