Content and opinions

Thee parts, three views how what debugging actually is.

The first is the pragmatic debugging: reproduce your bug, diagnose it, fix it, and make it definitely go away. Each step is actually not mandatory done by a debugger, and in fact the book advocates the TDD approach. Making it go away is in fact thinking about what this bug meant: was it a design issue, a feature, and if it is a bug, how can all the consequences be erased?

The second is managing your bugs. The main action is to have a bug database that is healthy, meaning it must be taken care of. As the book is about a pragmatic approach, one may think the advice are pure logic, and that no one would not follow them. If this book serie has so much success, it is because those advice are in fact not that obvious for everyone!

Finally, the first two parts are in fact the theory. Practice is always a little bit different. What do you do of leagacy releases? Of third-parties libraries? Of bugs that you need to fix in a hurry in parallel? Tests is another facet of software closelly related to debugging. Once you’ve debugged something, you want your tests to assert that it won’t come again unless you see it. How can you be sure that you will have enough information when debugging your software? Finally, there are some pitfalls in software that hinder debugging. As those anti-patterns, this part is about concrete actions that must be implemented in every software project.

Conclusion

Pragmatic Bookshelf has the habit of having a lot of experience feedback in their books, and this one is not an exception. Sadly, there are mainly present in the first part of the book. Still, it’s not the main value of the book. I think the main value is placing debugging in the new landscape of agile software. Too many times, the word debugging is missing in agile books, replaced by only testing. They are the two sides of the same coin. The last part has its virtues as well. Debugging is not a simple workflow, there are differences for each software project.

As usual, the publisher has an excellent book on a practical subject that answers practical questions on debugging.

Debug It!: Find, Repair, and Prevent Bugs in Your Code
Price: $29.88

Debug It!: Find, Repair, and Prevent Bugs in Your Code (Pragmatic Programmers) (Paperback)
by Paul Butcher
ISBN: 193435628X

Price: USD 23.07
38 used & new available from USD 12.94

| 4.5 | 8

Content and opinions

The first part is dedicated to the reasons why a software project can fail. It starts with 12 reasons of why software is different than other fields. This implies some assumptions that can differ from the usual project management. The last chapter is a simulation of what a failing software project is. All in all, the main message passes, but I think it is too harsh. The underlying idea is that software is different than all the other fields, but in fact, it may be all the same (at least on the points that were underlined): building a bridge is something we know how to do through usual management, but it can still run late/too expensive/… Besides, the example is overdone. It cumulates all the typical mistakes that we know now how to avoid.

The second part gives the pieces of advice to fix what the first part uncovered. Three agile processes are explained, then tools to budget with one of these processes. the last is the example of the first part reloaded with agile methods. I agree that agile methods are an answer to the software management project, but each time software management is really opposed to usual management. There are issues that are still really different in software projects: defining the needs of the users. When you build a bridge or when you build a house, you know what you want. You know the number of ways, or the number of doors/windows/rooms, … In software projects, you don’t know how many doors you need. Another issue is that people think that software is easy to do, so it’s easy to add something else (mainly because it is mandatory… or not).

Conclusion

If the book is really easy to read, there are some shortcuts that did bother me: the two examples are caricatures of reality (not even a real example where things went well or really bad, they are a story), and software management is also exagerated compared to project management. Perhaps the real conclusion is this one: exageration. Software project management is too difficult to be explained by a caricature: it may lead to the opposite effect.

Software Project Secrets: Why Software Projects Fail
Price: $49.49

Software Project Secrets: Why Software Projects Fail (Expert’s Voice) (Hardcover)
by George Stepanek
ISBN: 1590595505

Price: USD 49.49
41 used & new available from USD 5.61

| 4.5 | 6

Today’s accelerators are not there yet. The tools are not ready yet (code translators) and usual programming practices may not be adequate. All the ecosystem will evolve, accelerators will change (GPUs are the main trend, but they will be different in a few years), so what you will do today needs to be shaped with these changes in mind. How is it possible to do so? Is it even possible?

Available code translators

Code translators are the easiest path to solution. I know two of them.

The first is the PGI compiler. It only supports CUDA and the Fortran and C99 language. I didn’t use it yet, also I plan of testing it in the near future. It is based on pragmas, and the compiler generates the CUDA microcode.

The second solution is HMPP. It supports more than just CUDA (also CAL/IL or OpenCL) and Fortran/C (also Java now). As the PGI compiler, it is based on pragmas, and a excellent thing is that it detects the available accelerators and launches the correct kernel (if you authorized it) or the original code. You can also modify the generated code to put your own (you can tune the code for instance, which may give you an additional x2 factor). Unfortunately, it is not possible to call functions inside the parallelized kernels, which means that only simple or badly-written (too many lines or duplicated code) kernels can be called. I think this is the same for the PGI compiler.

It seems that code translators still need work:

• only few accelerators are supported (CUDA, and sometimes CAL/IL or OpenCL),
• almost no langage (Fortran/C/Java, a lot of Virtual Machines should be able to use them natively, without developers using specific tools),
• only one function can be parallelized at a time.

The last point is currently the biggest issue. You need to cut your function int pieces to have clean code and a good portability/evolutivity for the future.

This is why one still need to program a lot for those accelerators, and so we need to adapt our programming practices, develop in the accelerators’ native langages (even if we know that they may disappear in a few years).

Developping your own “tool chain” for accelerators

For accelerators, there are a lot of things that needs to be done each time: copying some data, computing and getting some data back. These are the steps that code translators automate, in fact it is a common practice to use tools to automate stuff. The issue is that complex kernels are not supported by those translators. So what?

Creating automatic functions that will copy the data you need is in fact very common in metaprogramming. Coding the kernel on an accelerator is in fact not that difficult: the manufacturers provide the needed compilers (that’s what nVidia does and the success of the tool chain cannot be denied), and this is really the cornerstone. One has to write more code, some parts are less portable (because they are written in one of the accelerator’s languages), but in the end, with metaprogramming, the code can be better tuned, enhanced and read. This is the leverage of the accelerators.

Conclusion

Why do we care developing for accelerators? We know that they will go away. Before they do, they are the only way of speeding up our software. Code translators are the best tools to develop in a portable way, but they need time to support more accelerators, languages and method of programming. When CPUs will be on a par with accelerators, their progress will help compilers to target them correctly. It’s just a matter of time.
Meanwhile, metaprogrammin is the next best solution to automate processes that code translators cannot support yet.

Content and opinions

The book has three main parts: a general introduction to Distributed Version Control Systems (DVCS) and Git, using Git everyday and what is called administration.

The introduction covers the different choices made by Git relative to Version Control. Without the actual commands, it is a gentle introduction, and if the choices does not suit you, well, you can walk away here. Its mainly an introduction to DVCS, but with a Git biais. If you find the book in a real library, you can browse this single chapter first. Then, another chapter helps you install the software package on Linux, OS X or even Windows.

The actual fun part comes next. How do you actually use Git to add and commit changes? Git has some some specifics in that matter compared to Bazaar or Mercurial. What are branches and how can they be used, how they should be used? What is the purpose of history and how it can be changed (fundamentaly changed)? Git is one of the few VCS that can actually rewrite history. There are of course enough warnings because this can be dangerous. Once history is known, it can be shared through remote repositories, and then how should a repository be organized? Finally some additional tools are presented. It’s really easy to follow the evolution, and it draws a small picture of the commands you will use every day.

The last part is abut migrating from CVS and SVN, and then how to set up a Git server. The connection between the commands in SVN and CVS is also described when you switch to Git. Of course, you will need more than CVS and SVN knowlegde to really use Git to its maximum power, the book is not about the theory of VCS, only about how to use Git. You will find a good introduction, but you will have to learn by other means the complete philosophy behind DVCS.

Conclusion

I didn’t know much about Git before reading the book, and the approach proposed here is efficient (although simple): from the basics to advanced workflows. You need to know a little about version control, as the Git specific parts are well explained in the book.

Pragmatic Version Control Using Git (Pragmatic Starter Kit) (Paperback)
by Travis Swicegood
ISBN: 1934356158

Price: USD 23.07
46 used & new available from USD 16.00

| 4.5 | 20

Content and opinions

TDD is about testing while developing, so it is of no wonder that the first part of the book which expose the methodology is done with the help of an example. Small steps, one of the main ideas behind TDD, in the explanations result in a lot of small chapters that explain how to do one thing.

The second part is about the main tol for TDD: xUnit. Its goal is to provide a standard tool for all languages.Well, in fact, it is different implementation, but some are not as easy to use as JUnit, the Java implementation. Some languages are more easy to cope with TDD than others.

The third part is a formal list of patterns to efficiently develop with TDD. What do you need to test something completly? What do you need to go from a test to the actual associated solution? This is the kind of questions the patterns try to answer.

Conclusion

There are a lot chapters with simple ideas in each one. What bothers me is that they could have been hierarchized a little bit more, but really, this is not an issue here. TDD is something that everyone should do, but there are some domains where it is more difficult than in other. For instance, hw would you test a complex stochastic scientific module? This is a question that remains open at the end of the book. For general IT, it answers every question on testing though.

Test Driven Development: By Example
Price: $44.99

Test Driven Development: By Example (Paperback)
by Kent Beck
ISBN: 0321146530

Price: USD 40.53
54 used & new available from USD 24.99

| 4 | 34