Blog Archive for / reviews /
Review of Patterns for Parallel Programming by Timothy G. Mattson, Beverly A. Sanders and Berna L. Massingill
Thursday, 01 November 2007
This book gives a broad overview of techniques for writing parallel programs. It is not an API reference, though it does have examples that use OpenMP, MPI and Java, and contains a brief overview of each in appendices. Instead, it covers the issues you have to think about whilst writing parallel programs, starting with identifying the exploitable concurrency in the application, and moving through techniques for structuring algorithms and data, and various synchronization techniques.
The authors do a thorough job of explaining the jargon surrounding parallel programming, such as what a NUMA machine is, what SPMD means, and what makes a program embarrassingly parallel. They also go into some of the more quantitative aspects, like calculating the efficiency of the parallel design, and the serial overhead.
Most of the content is structured in the form of Patterns (hence the title), which I found to be an unusual way of presenting the information. However, the writing is clear, and easily understood. The examples are well though out, and clearly demonstrate the points being made.
The three APIs used for the examples cover the major types of parallel programming environments — explicit threading (Java), message passing (MPI), and implicit threading from high-level constructs (OpenMP). Other threading environments generally fall into one of these categories, so it is usually straightforward to see how descriptions can be extended to other environments for parallel programming.
The authors are clearly coming from a high-performance computing background, with massively parallel computers, but HyperThreading and dual-core CPUs are becoming common on desktops, and many of the same issues apply when writing code to exploit the capabilities of these machines.
Highly Recommended. Everyone writing parallel or multi-threaded programs should read this book.
Buy this book
Patterns for Parallel Programming
Timothy G. Mattson, Beverly A. Sanders and Berna L. Massingill
Published by Addison-Wesley
ISBN 0-321-22811-1
Buy from Amazon.co.uk
Buy from Amazon.com
Posted by Anthony Williams
[/ reviews /] permanent link
Tags: reviews, threads, patterns, books
Digg This | Save to del.icio.us | Stumble It! | Submit to Reddit | Submit to DZone
10 Years of Programming with POSIX Threads
Monday, 29 October 2007
David Butenhof's Programming with POSIX Threads was published 10 years ago, in 1997. At the time, it was the definitive work on the POSIX thread API, and multi-threaded programming in general. Ten years is a long time in computing so how does it fare today?
New POSIX Standard
When the book was written, the latest version of the POSIX Standard was the 1996 edition (ISO/IEC 9945-1:1996). Since then, the standard has evolved. It is now maintained by a joint working group from The Open Group, the IEEE and ISO called The Austin Group. The new Standard is called the Single Unix Specification, Version 3 and the 2004 edition is available online.
The new standard has brought a few changes with it — many things that were part of extensions such as POSIX 1003.1j are now part of the main ISO Standard. This includes barriers and read-write locks, though barriers are still optional and the read-write locks have a slightly different interface. Programming with POSIX threads is therefore lacking a good description of the now-standard APIs — although Butenhof devotes a section in Chapter 7 to implementing read-write locks, this is now only of historical interest, as the semantics are different from those in the new standard.
Most things stay the same
Though there are inevitably some changes with the new standard, most of the APIs remain the same. Not only that, the fundamental concepts described in the book haven't changed — threads still work the same way, mutexes and condition variables still work the same way, and so forth. Not only that, but the rising numbers of multicore CPU desktop computers means that correct thread synchronization is more important than ever. Faulty assumptions about memory visibility that happened to be true for single core machines are often demonstrably false for multicore and multiprocessor machines, so the dangers of deadlock, livelock and race conditions are ever more present.
Still the definitive reference
Though it's probably worth downloading the new POSIX standard, or checking the man pages for the new functions,
Programming with POSIX Threads is still a good reference to the POSIX thread APIs, and multi-threaded programming in
general. It sits well alongside Patterns for Parallel
Programming — whereas Patterns for Parallel Programming is mainly about designing programs for concurrency,
Programming with POSIX Threads is very much focused on getting the implementation details right.
Highly Recommended.
Buy this book
Programming with POSIX Threads
David Butenhof
Published by Addison-Wesley
ISBN 0-201-63392-2
Buy from Amazon.co.uk
Buy from Amazon.com
Posted by Anthony Williams
[/ reviews /] permanent link
Tags: reviews, threads, POSIX, Butenhof, books
Digg This | Save to del.icio.us | Stumble It! | Submit to Reddit | Submit to DZone
Review of Fit for Developing Software by Rick Mugridge and Ward Cunningham
Monday, 22 October 2007
As the subtitle of this book says, Fit is the Framework for Integrated Tests, which was originally written by Ward. This is a testing framework that allows tests to be written in the form of Excel spreadsheets or HTML tables, which makes it easy for non-programmers to write tests. This book is divided into several parts. Parts 1 and 2 give an in-depth overview of how to use Fit effectively, and how it enables non-programmers to specify the tests, whereas parts 3-5 provide details that programmers will need for how to set up their code to be run from Fit.
Though I have been aware of Fit for a long time, I have never entirely grasped how to use it; reading this book gave me a strong urge to give it a go. It is very clear, with plenty of examples. I thought the sections on good/bad test structure, and how to restructure your tests to be clearer and easy to maintain were especially valuable — though they are obviously focused on Fit, many of the suggestions are applicable to testing through any framework.
Fit was developed as a Java framework, and so all the programming examples are in Java. However, as stated in the appendix, there are ports for many languages including C#, Python and C++. The way of structuring the fixtures that link the Fit tests to the code under test varies with each language, but the overall principles still apply.
The book didn't quite succeed in convincing me to spend time working with Fit or Fitnesse to try and integrate it with any of my existing projects, but I still think it's worth a look, and will try and use it on my next greenfield project.
Recommended.
Buy this book
At Amazon.co.ukAt Amazon.com
Posted by Anthony Williams
[/ reviews /] permanent link
Tags: reviews, fit, books, testing
Digg This | Save to del.icio.us | Stumble It! | Submit to Reddit | Submit to DZone
Review of Refactoring to Patterns by Joshua Kerievsky
Wednesday, 12 April 2006
The opening chapters cover the background, introducing both refactoring and design patterns, and the context in which the book was written. This gives the reader a clear overview of what is involved in Refactoring to Patterns, and paves the way for the refactoring catalogue which makes up the bulk of the book.
The catalogue is divided into chapters based on the type of change required — is this a refactoring to simplify code, generalize code, or increase encapsulation and protection? Each chapter has an introduction which gives an overview of the refactorings contained within that chapter, followed by the refactorings themselves. These introductions clearly illustrate the principles and choices which would lead one to follow the refactorings that follow.
Each refactoring starts with a brief one sentence summary, and before and after structure diagrams with reference to the structure diagrams for the relevant pattern in the Design Patterns book. The sections that follow then cover the Motivation for using this refactoring, step-by-step Mechanics, and a worked Example, relating back to the steps given for the Mechanics. Finally, some of the refactorings finish with Variations on the same theme. The examples are all pulled from a small sample of projects, which are introduced at the beginning of the catalogue section, and help illuminate the instructions given in the Mechanics section. The mechanics themselves are generally clear, and broken down into small steps — sometimes smaller steps than I might take in practice, but I think this is probably wise, as large steps can easily confuse. Finally, the Motivation sections do a good job of explaining why one would choose to do a particular refactoring, and any pitfalls to doing so — the "Benefits and Liabilities" tables provide a useful summary.
This book is well written, easy to read, and genuinely useful. It has helped me put some of the refactorings I do into a larger context, and given me insight into how I can integrate patterns with existing code, rather than designing them in up front. As John Brant and Don Roberts highlight in their Afterword, this is a book to study, the real benefit comes not from knowing the mechanics, but by understanding the motivation, and the process, so that one may apply the same thinking to other scenarios not covered by this book. If you are serious about software development, buy this book, inwardly digest it, and keep it by your side.
Highly Recommended.
Buy this book
Refactoring to Patterns
Joshua Kerievsky
Published by Addison-Wesley
ISBN 0-321-21335-1
Buy from Amazon.co.uk
Buy from Amazon.com
Posted by Anthony Williams
[/ reviews /] permanent link
Digg This | Save to del.icio.us | Stumble It! | Submit to Reddit | Submit to DZone
Review of Working Effectively With Legacy Code by Michael C. Feathers
Wednesday, 12 April 2006
A lot of the book is spent covering different techniques for getting nasty convoluted code under test. These techniques often focus on breaking dependencies, so you can instantiate an object in a test harness, or call a function without it sending an email or talking to the database. In many cases, these are sensible recommendations for improvements to the codebase, but in some cases, Michael recommends techniques you wouldn't expect to see in production code, such as defining preprocessor macros with the same name as functions to avoid calling them, or writing dummy implementations of API functions. This is not to say that the book recommends such techniques wholesale — Michael is keen to point out that these techniques should only be used to get the code under test, so that it can be refactored safely.
Chapters are helpfully named, with titles like "This class is too big, and I don't want it to get any bigger", and the book gives good advice on how to deal with the nastiest codebases. The key recommendation underlying it all is "get the code under test, so you can refactor safely", and this is borne in mind with those techniques that require changing the production code in order to get it under test — these techniques provide step by step instructions to help you make the required changes without breaking anything.
The content of this book is excellent, and the writing clear, so it is unfortunate that it is marred by numerous minor errors, such as spelling mistakes, or using the wrong identifier when referring to a code example. However, this minor niggle is not enough to stop me recommending it — every software developer should have a copy.
Highly Recommended. This book is a must-have for anyone who has to maintain code — which is pretty much every software developer on the planet.
Buy this book
Working Effectively With Legacy Code
Michael C. Feathers
Published by Prentice Hall PTR
ISBN 0-13-117705-2
Buy from Amazon.co.uk
Buy from Amazon.com
Posted by Anthony Williams
[/ reviews /] permanent link
Digg This | Save to del.icio.us | Stumble It! | Submit to Reddit | Submit to DZone
Review of Extreme Programming Adventures in C# by Ron Jeffries
Tuesday, 14 February 2006
The project is not just one big success story; Ron shares his mistakes with us so that we may learn from them. The book is interspersed with "lessons", where Ron reflects on the preceding section and tries to identify important points, either things that he felt worked well, or things the mistakes he made, and what he thinks could be done to try and avoid similar mistakes . Also throughout the book are sentences marked "sb", for "sound bite". These are short phrases which summarise a point, like "It's Chet's fault" (don't focus on finding who's at fault when things go wrong, rather focus on fixing the problem), or "You Aren't Gonna Need It" (focus on what needs doing now, rather than what you think you'll need for later). It is these lessons and sound bites which provide the "message" of the book — Ron's belief that incremental development, done test-first, with simple design, continuous refactoring and a focus on producing value for the customer is an effective method of producing high quality software.
If you like Ron's other writing you'll love this book. If you've never read Ron's stuff before and are interested in learning a bit about how he applies the principles of XP (and maybe a little C#), it's worth reading; you might even enjoy it.
Highly Recommended.
Buy this book
At Amazon.co.ukAt Amazon.com
Posted by Anthony Williams
[/ reviews /] permanent link
Digg This | Save to del.icio.us | Stumble It! | Submit to Reddit | Submit to DZone
Review of JUnit Recipes: Practical Methods for Programmer Testing by J. B. Rainsberger
Tuesday, 14 February 2006
The book is laid out into a series of chapters describing related techniques, such as "working with test data" and "testing web components", with each chapter split into a series of "recipes", each describing a particular technique. The layout of each recipe is good, with a problem statement, additional background, the details of the recipe itself, and further discussion. There are also references to other related recipes, that provide alternatives to, build on, or are relied on by this recipe.
The level of coverage is very comprehensive. Having read the book it feels like there is a recipe for testing just about everything you could write in Java, from simple classes, to XML generation code, database access code, EJBs, singletons, and JSPs. There are even recipes on managing your test suites, adding tests to hard-to-test classes, and the use of test implementations of other objects to allow testing objects in isolation.
Just because it focuses on Java and JUnit does not mean that this book is useless to anyone programming in another language. On the contrary, many of the techniques described can be applied in any Object Oriented language, though there are certainly some that are specific to Java. For this reason, I would highly recommend this book not just to Java programmers, but to anyone interested in improving the testing of their code.
Highly Recommended.
Buy this book
At Amazon.co.ukAt Amazon.com
Posted by Anthony Williams
[/ reviews /] permanent link
Digg This | Save to del.icio.us | Stumble It! | Submit to Reddit | Submit to DZone
Review of Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process by Scott Ambler
Wednesday, 08 February 2006
The book is divided into 5 parts. The first two parts cover the principles you should work to and practices you should be doing to say that you are doing Agile Modeling as Scott defines it. The values of Agile Modeling are the four values of eXtreme Programming, plus a fifth (Humility), and the principles and practices are then derived from applying these values to a modelling perspective. For example, the value of Courage leads one to Discard Temporary Models, and the values of Humility and Communication lead one to realise that Everyone Can Learn From Everyone Else, and that you should Model With Others. This description of the principles and practices forms the real meat of the book. Most (perhaps all) of what Scott says here is sensible advice which should be followed by anyone pursuing an Agile approach to software development.
The remaining parts describe the how Agile Modeling fits into XP and the Universal Process, with a discussion on introducing Agile Modeling into your process. This also includes a discussion of when Agile Modeling is *not* a good fit, as well as a check list of things you must be doing to say you are Agile Modeling, and a list of things which you must not be doing if you want to say you are Agile Modeling. The book finishes off with an appendix listing a host of modelling techniques to consider when the need arises; Scott is quite clear that you need to Apply the Right Artifact, and having a wide range to choose from makes this easier since you are not stretching a model beyond what it can easily cover.
If you are interested in modelling, and want to know how it fits into Agile projects, or you are looking to make your current process more Agile by reducing unnecessary modelling work, then this book is well worth a read; I just wish it was easier to read.
Recommended.
Buy this book
At Amazon.co.ukAt Amazon.com
Posted by Anthony Williams
[/ reviews /] permanent link
Digg This | Save to del.icio.us | Stumble It! | Submit to Reddit | Submit to DZone
Review of Agile Documentation: A Pattern Guide to Producing Lightweight Documents for Software Projects by Andreas Rueping
Wednesday, 08 February 2006
The title of this book is "Agile Documentation", but almost everything it says is applicable to documentation for any project, whatever methodology is used. Indeed, much of what is said is common sense if you think about it — but how often does anyone really think about it? Reading this book forces the issue, and hopefully encourages one to think about the purpose, readership and content of documentation a bit more in the future. However, some of the content is particularly important when trying to use an Agile development method, since it contributes to reducing the effort that is wasted on unused or unnecessary (or even unusable) documentation, whilst ensuring that the documentation that is produced is both necessary and sufficient for the project's needs.
The subtitle is "A pattern guide for producing lightweight doucments for software projects", which is quite apt. Essentially, the book consists of a set of patterns, divided into 5 groups, each of which describes a particular problem associated with documentation, and some discussion of the solutions. The key points are summarised in what the author calls "thumbnails" — a couple of sentences which appear in bold type in the pattern description, and which are then repeated in the "thumbnails" section at the back of the book. These enable you to browse through the book, reading each pattern heading and the corresponding thumbnail to get an overview of the pattern and determine whether it is applicable for your current situation, or jog your memory.
The patterns are not just presented on their own, they are backed up by experience reports from a number of projects that the author has been involved with. These are used both within the pattern descriptions, and in a separate section at the end of each chapter. They are not all positive, and are used to highlight the dangers of not following the patterns from the book, as well as the benefits of doing so. Overall, they give the advice a place of reference, and are the source of numerous examples.
One slight issue I had with the book was the number of typos, which was particularly unexpected given the subject matter. However, this did not detract too significantly from my overall impression: Highly Recommended
Buy this book
At Amazon.co.ukAt Amazon.com
Posted by Anthony Williams
[/ reviews /] permanent link
Digg This | Save to del.icio.us | Stumble It! | Submit to Reddit | Submit to DZone
Review of Lean Software Development: An Agile Toolkit, by Mary Poppendieck and Tom Poppendieck
Wednesday, 01 February 2006
The book divides lean thinking into 7 key principles, with 22 "tools" to help you adapt agile practices to your workplace. It also features a "try it out" section at the end of each chapter taking you through some simple steps that demonstrate how the particular techniques discussed can be applied to improve your software development process.
Some of these principles are obvious at first glance — "Eliminate Waste" for example — but this simplicity hides profound insight; in this case, the insight is that much of the "work products" of traditional software development processes are in fact waste, produced purely so the developer can "tick the box" and move onto the next task. Not only that, but the very process can itself generate waste — having analysts produce specs from customer requirements, which designers then turn into a high level design for coders to turn into software is very wasteful, because knowledge is lost at every stage; the very act of writing something down means that the understanding and background knowledge held by the author is lost, either permanently, or until the reader has acquired it for himself.
This book is aimed at project managers and lead developers looking for ways to improve their software development process, but I would recommend it to anyone who is serious about producing quality software. Whilst many agile practices require management buy-in (and if you can get your manager to read this book, it will probably help), others can be implemented by developers as part of almost any process.
Buy this book
At amazon.co.ukAt amazon.com
Posted by Anthony Williams
[/ reviews /] permanent link
Digg This | Save to del.icio.us | Stumble It! | Submit to Reddit | Submit to DZone