Programmer Musings

Review of Micro-ISV: From Vision to Reality

Micro-ISV: From Vision to Reality
Bob Walsh
Apress, 2006.

This is not the sort of book I would normally read. I'm usually more interested in the technical side of software than the business side. I found this book to be particularly difficult going partly for that reason. But, before I get into what I didn't like about the book, let's look at the positives.

Walsh manages to give the most complete overview that I've ever seen on what you will need to start a small software business. I'm an unabashed techie. One reason I've never attempted to start a business is that I know that I have big gaping holes in my skill set where business skills are concerned. Walsh's approach is the only one I've ever seen that gave me some reason to believe that I might actually be capable of starting a business. It also gave me a good idea why I probably never will.

Instead of pithy phrases and advice, Walsh focuses on explaining what sorts of information a technical type will need to learn to start down this path. He also gives plenty of information on where and how to track down the information you need. Instead of attempting to spoon-feed us the business information we need, he shows how to learn business skills just like any other skills we have learned throughout our careers. In other words, this book does appear to be focused on helping technical people (who basically learn for a living) to see what they will need to learn to start a business. This seems to be a much more reasonable approach than others I've seen.

Despite the intelligent approach, I found the book to be an incredibly hard read. It was not the writing, which was quite clear and readable. It was the subject. I found it very hard to focus on the material. If I were more interested in starting a business, that might not have been an issue. I also had some difficulty with Walsh's reliance on interviews for many of his points. In a smaller quantity, I think it would have been helpful. But, at some points, it felt more like the testimonials you see in informercials. I am just not normally convinced by that approach. I would have been more comfortable with a few more numbers and a few less stories of people who are succeeding in this field.

The second to last chapter was really difficult because of the sheer number of interviews focusing on Microsoft business support services. It's nice to know that those services are available, but there were enough of those interviews that it began to feel more like a commercial for Microsoft than I would have preferred. Fortunately, that was mostly concentrated in part of one chapter. Most of the interviews seemed more informational than that set.

The final interview of the book was also a little overdone in my opinion. Walsh interviewed Joel Spolsky for an amazing 10 pages of text. In addition, Joel did the foreword for the book. Now, I find Joel's insights to be interesting and he's a good writer. But this was a significantly bigger chunk of text than any of the other interviews. Frankly, if I wanted Joel's opinions, I can get them in many other places. It did not seem necessary to devote quite so much time to them here.

Despite my criticisms, I think this is probably a really good resource for any technical person who is thinking about starting a software business. This will either give you a leg up on the information you will need to know, or convince you that you are not cut out for this kind of life. Either way, the information may be exactly what you need.

Review of Perl Best Practices

Perl Best Practices
Damian Conway
O'Reilly, 2005

This book is hard to summarize. There is much good advice in this book. Unfortunately, there's also some advice that I found questionable. Conway covers some of important Perl and general programming best practices, including consistent formatting, use of strict and warnings, and the use of version control software. Unlike my standard book on best practices, Code Complete, Conway does not provide much independent support for his assertions. On the obvious best practices (meaning those you agree with), this is not a big issue. However, I did find it difficult to accept suggestions to change coding practices I've developed over almost two decades without any supporting evidence.

Without that evidence, I found some of Conway's arguments to be less than convincing. For example at the beginning of Chapter 2, he states that consistent layout is important, but which particular layout style you use does not matter at all. So far I agree with him completely. Then, he goes on to spend over 25 pages describing his preferred layout style, listing each point as a best practice and spending time justifying his choices. If the particular layout style does not matter, shouldn't we have had one best practice, use a consistent layout style instead of 22 individual layout suggestions elevated to best practice status?

I was also interested to find that more than 10 of the recommended modules were written by Damian Conway. Some of these appear to have been updated on CPAN relatively recently. That makes me wonder how they have had time to become best practice.

Some of his rules appeared to be somewhat contradictory. For instance, we shouldn't use unless because it is not as familiar to many programmers and it is harder to understand complicated boolean expressions in an unless. But, we should use redo to restart a for loop without incrementing the variable when we need more complex flow control. And we should prefer \A and \z in regular expressions, because

They're likely to be unfamiliar to the readers of your code, in which case those readers will have to look them up, rather than blithely misunderstanding them.

Although these suggestions may be good practice and may actually help in writing maintainable code, I find it impossible to detect an underlying philosophy driving this particular set of suggestions.

If you've read this far, you probably have gotten the impression that I hated this book. That is very far from the truth. Damian Conway is a prolific Perl programmer with loads of experience. Much of his advice parallels my own philosophy in writing code, in Perl and in other languages. As I was reading the book, I installed several of his suggested modules and have even modified a few of my Perl programming practices based on his arguments. However, I would be uncomfortable suggesting that a new Perl programmer use this book as the reference on how to program in Perl.

In general, I believe that my biggest problem stems from the expectations I had from the title. If it had been called Damian Conway's Recommended Practices for Perl, I would have been a bit more forgiving. However, by setting itself up as the book on Perl best practices, I feel that the practices in the book need to be more than Conway's recommendations. Supporting evidence or studies would have made it easier to swallow his suggestions where they disagreed with my own practice. Less inconsistency between different rules would have made me more comfortable that he has an underlying strategy instead of listing the part of the language that he, personally, likes. Better disclosure about the modules he wrote and their age, would have made the book feel less like an infomercial in spots.

All in all, I think I would recommend this book to more senior Perl programmers or senior programmers coming to Perl. I would be a little leary of recommending it to novice Perl programmers without some strong suggestions that they take this as one person's view. The really frustrating thing is that I really wanted a book to be the standard I could use to counteract the myth of write-only Perl. Unfortunately, I don't think this book will do that.

All that being said, there is a large amount of good advice in this book. As long as you take the advice with an appropriately-sized grain of salt, this book could improve your Perl code.

Review of Waltzing with Bears

Waltzing with Bears
Tom DeMarco & Timothy Lister
Dorset House Publishing, 2003

The authors of Peopleware are back to tackle the topic of risk management. Given their earlier works, you would expect DeMarco and Lister to provide good insights into the topic and clear explanations. In that, you will not be disappointed with this book.

The book explains why you should do risk management, how to do risk management, and how to test the management you are doing. Surprisingly, the book also tells you when you might not want to do risk management and some of the politics that can surround this topic. The authors describe many facets of some corporate cultures that work to defeat the management of risk. They also explain why taking risks is critical to success and how to judge acceptable risks from foolhardy ones. As you would expect, the authors are clear in their explanations and instructions.

The book references an accompanying website that lists various risk management tools including an risk simulation tool supplied by the authors. This tool may be used to map the uncertainty in your project's estimates. Understanding this uncertainty is the heart of risk management.

The only complaint I have with the book is in the area where I feel I am the weakest. The authors acknowledge that many of the problems in risk management are problems with corporate culture or attitudes of the various stakeholders in the project. Unfortunately, their advice on dealing with these issues is extremely vague compared to the more technical aspects of risk management. I understand that this is the part that is the hardest to quantify, but it may be where we need the most advice. I suppose that actual project managers may have a better idea of how to deal with these issues and do not need more instruction. But, for me, this seemed to be an area where the book was lacking.

In general, I feel this is a great book for anyone who must manage a project or who needs to track the risks on a project. If your focus in most projects is purely in the area of code, you may not get as much out of the book. However, if you need to lead a team or manage a project, this book is a great way to become familiar enough with risk management to possibly succeed. I would definitely recommend the book to senior developers and junior to intermediate project managers. More senior project people may already be aware of the issues covered in the book, but may benefit from the fresh treatment.

Review of Secure Coding in C and C++

Secure Coding in C and C++
Robert C. Seacord
Addison-Wesley, 2006

One very real problem in software today is the rise in security exploits of one kind or another. Gone are the days when we can just assume that no user of our software will try to break it, or use the software to compromise an entire system. The more immediate problem is that most of us have no training in preventing security vulnerabilities in our code.

This book does a fairly good job of covering a number of sources of security problems and explaining how they can be exploited. Using this information and the recommended practices in the book, you can make your code much more secure. The book has a chapter devoted to each of several vulnerabilities. The author examines the reason for the problem, how it is likely to manifest, and the kinds of exploits that can be applied. He then makes suggestions for tools and techniques to use to reduce these problems.

The book covers topics such as strings, integers, dynamic memory, and formatted I/O, as well as others. In each case, the book carefully explains where the potential problems lie. In some cases, the author shows actual examples from code that was in live use. Although the delivery can be a bit dry at times, the material itself is sometimes scary in its implications.

Possibly the most important chapter in the book is the final one Recommended Practices. This chapter covers more than just techniques for solving a particular kind of pointer bug. This is the chapter that covers overall strategies, such as threat modeling, data sanitization, and defense in depth. If you have any background in computer security, these concepts will probably be familiar. If not, they are the most important things for you to learn from the entire book.

This book should be a requirement for anyone who develops software that will be used by more than just his co-workers. This includes software available over the web.

Review of Perl Testing: A Developer's Notebook

Perl Testing: A Developer's Notebook
Ian Langworth and chromatic
O'Reilly, 2005

This is the first book I have read from the new O'Reilly Developer's Notebook series. Although the style of these books probably won't work for every topic, it works particularly well for a book on testing. Each chapter is organized as a set of labs. These labs walk through some portion of the topic with the goal of developing practical skills.

Each lab revolves around a task. They don't delve into theory, they focus on describing how you perform the task. Unlike O'Reilly's Cookbook series, this is a directed set of tasks. Much like labs in a class, the labs in this book start with basic testing skills and work to build more advanced testing skills. The goal of this set of labs is to help you become proficient in the skills needed for doing quality unit testing of Perl code.

I have been doing testing with Perl for some years now, so the first few labs were review. But, the labs swiftly escalated to more advanced topics that I was either light on or had not explored at all. In addition to labs about Test::Simple, Test::More, and Test::Harness, the book covers:

• testing the POD documentation in your modules
• coverage testing
• testing exceptions generated by code
• testing warning generated by code
• building testing libraries to simplify testing
• mocking objects
• overriding system calls
• testing databases
• testing websites

and many more topics related to testing. This little book is packed with practical information and labs that help you improve the skills you need to build quality testing for your Perl code.

I really don't expect this book to become a well-worn reference book that stays near my desk at all times. However, I don't expect to let it get far away. Since few of us need to use all of our testing skills on every project, some skills become rusty over time. Anytime I find some of my testing skills have gotten rusty, I expect to grab this book and run through the appropriate labs to sharpen the skills I need.

If you want to know why you should be unit testing your Perl code, there are many books out there that will explain. If you are looking for an explanation of Test Driven Development, this is not the book to read. Once you have decided that testing is important to you and your projects, this is the book you need. I would not say that there are no other resources for learning this material, but this may be the fastest way to build the appropriate skills that I've seen.

It also helps that the authors have a very relaxed style that helps you feel more like they are working along side you than lecturing at you. The titles of the sections are very casual (How do I do that?, What just happened?, etc.) This makes it easy to read the next part and get back to working on the meat of the lab.

I would recommend this book to anyone writing Perl code. We all need to be doing testing to improve our code and our designs. The key difference between good testing and bad testing is the skills to make every test count. This book teaches those skills.

Review of Beyond the C++ Standard Library

Beyond the C++ Standard Library
Bjorn Karlsson
Addison-Wesley, 2006

If you've been programming in C++ in the past few years you've probably heard of the Boost library. Boost is a large peer-reviewed set of classes and libraries designed to augment the C++ standard library. Beyond the C++ Standard Library serves as an introduction to some of the classes and libraries available through the Boost project.

Although the book does not cover every library developed by the Boost community, it does introduce many of the most generally useful. Several of the libraries covered in this book have already been accepted by the C++ Standard committee as official extensions to the standard library under Technical Report 1 (TR1). So these libraries will soon be coming to a C++ compiler near you.

Almost every chapter began with two important sections:

• How Does the X Library Improve Your Programs?
• How Does the X Fit with the Standard Library?

The first section shows the benefits that you and your programs will gain from using this library. This section serves to describe the library's reason for existence. In some cases (like the shared_ptr classes), the purpose of the library is to replace hundreds of slightly incompatible, possibly broken, shared pointer implementations with a set that really work. In other cases (like the Lambda library), the purpose may be to provide you with functionality that you may not have even believed was possible in C++.

The second section shows how the library integrates with or enhances the functionality in the standard library. This may be the biggest difference between the Boost libraries and those written in your average programming shop. Many of the people that work with the Boost project were part of the C++ standards process. This means that they truly understand the library. These sections describe difficulties with the standard libraries that the library is meant to overcome or ways where the standard library can be improved with the benefit of almost a decade of real-world use.

These two sections are probably the most important part of each chapter. The rest of each chapter provides an overview of the library and some examples of usage. The overview lists the important members of each class with descriptions. The examples are generally useful and clear.

This book is definitely more than a rehash of the documentation at the Boost site. Each library is covered with enough information and examples to get you started working with the library.

If you are thinking about using the Boost libraries in any of your projects, I would recommend this book. I would also recommend the book if you are interested in becoming familiar with the TR1 additions that will soon be part of the standard.

Review of Code Reading

Code Reading
Diomidis Spinellis
Addison-Wesley, 2003

I have had this book on my list of books to read for some time. Although I have been reading code for years, everything I had heard about this book suggested that it would help improve my reading skills. Unfortunately, halfway through the book I was mostly disappointed. This is not to say that the book had not covered loads of useful information, it was just stuff I had already found on my own.

As I progressed through the book, however, I found more and more useful tips and suggestions. Although a few were things I had never seen before, many were techniques I had not used in a while and had forgotten. By the end of the book, I am firmly of the belief that this book is a must-read. Even if you find parts of it to be obvious, there is enough material to extend almost everyone's understanding.

The book starts off with basic techniques, recognizing language constructs and coding idioms. It then moves on to data types and more advanced control flow. Eventually we pass through documentation and architecture, on our way to tools that help your code reading. A few of the pieces of advice are more useful for more junior code readers. Such as, pointing out that

for(i = 0; i < len; i++)

should be read as loop len times. You should be able to recognize this without actually parsing the code. The author also spends time unraveling boolean expressions and showing how changing the whitespace in a complicated expression may make its meaning more obvious.

It also covers more advanced advice like reminding you not to expect a single over-arching architecture in a piece of code. You may spend time trying to find something that is just not there. The book also covers the important trade-offs involved in using documentation attached to the code. There are also wonderful maxims like

An hour of code reading can save you a minute of reading the documentation.

and

Documentation may often provide a misleading view of the source code.

In addition to documentation and the code itself, Spinellis supplies advice on using comments in the code and the change logs under version control to help understand the code. He does not suggest that the comments and change logs should be taken as the truth. However, he does point out that they may help to clarify the purpose or intent of the code.

One of the most fundamental points made by the book is that how you read code depends on what you are trying to do with it. If you are trying to repair or modify a small piece of a large body of code, you don't need to understand the whole thing. I know that I am personally guilty of trying to get deeper into code than is necessary. On the other hand, the book shows examples of needing to dig further when your understanding does not match the program.

The book includes a relatively extensive list of references that might be worth reviewing to extend your knowledge of this field further. The book comes with a CD containing a reasonably large body of open source software that you can use to practice your code reading skills. The exercises in the book are geared toward using that code base.

This book is a must read for any junior or intermediate software developer. If you need to maintain anyone else's code, this book gives lots of strategies to make your work easier. Despite my initial impression, this book provides an good refresher for more senior developers. It does a very good job of reminding you of techniques that you may not have used or may not have used recently.

Review of The Best Software Writing I

The Best Software Writing I
Joel Spolsky (editor)
Apress, 2005

Despite plenty of examples to the contrary, there is actually some good writing out there on various software subjects. Even though most of what you can read on the subject (on and off the web) is not particularly well-written, there are some gems out there. In this book, Joel Spolsky attempts to show how some good examples would look.

Joel and the team at Apress have collected together 29 articles from various authors writing on software subjects. These essays show the qualities that Joel believes embody good writing. Joel introduces each essay in his own ... unique style. Although I have disagreed with some of Joel's arguments in the past, I have to admit that he did a great job of finding well-written articles.

The topics range from technical articles on programming topics to the business of software to the human side of the business, and many points in between. As with any diverse body of work you may find, as I did, that you don't agree with some of the positions taken by the authors. However, each article was so well written that even if you don't fully agree with the author's position, you will still learn quite a bit by reading it. With so many different authors, you are also exposed to a large number of styles, from cartoons to essays. But each one is easy and enjoyable to read.

If you are looking for purely technical articles, containing nothing but language tricks and programmign techniques, you might want to take a pass on this book. Many of the articles cover some of the non-technical aspects of software development. In many ways, that caused me to enjoy the book more. I have loads of books on the technical side of software development, but good articles that help us understand the business side of things seem to be more rare.

In addition, I found a couple of the articles introduced me to new weblogs that I plan to follow for some time to come. (Thanks, Joel. As if I needed to lose any more time to extraneous reading.<grin/>)

Unlike most of the books I review here, this book makes a pretty good book to unwind with. Instead of forcing more technical material into your brain, take a look at this one and give yourself some time to relax.

Review of C++ Common Knowledge

C++ Common Knowledge
Stephen C. Dewhurst
Addison-Wesley, 2005

The subtitle of this book sums it up nicely, Essential Intermediate Programming. If someone has not mastered, or at least understood, the material in this book, he or she is still a junior C++ programmer. Although this material is necessary, it is not sufficient to make someone an intermediate-level C++ programmer.

As explained in the preface, Dewhurst wrote this book partially to save himself from explaining these same topics every time he deals with a new set of programmers. He also explains that he has not covered every important topic in the book. In order to make the book more usable, it has been reduced to 63 core points that are either central to your understanding of C++ or often misunderstood.

Although he does not go into extreme depth on every one of these subjects, Dewhurst does capture enough of the details to help you understand why the point matters and why it works the way it does. I have read almost all of these items in other books, sometimes in more detail. But, there were still a few points that I feel I understand better after his explanations.

Dewhurst begins with some topics that any one who programs in C++ should be at least somewhat familiar with: "Data Abstraction", "Polymorphism", etc. and works up through "Template Argument Deduction" and "Generic Algorithms". None of these chapters can be considered the definitive, be-all-end-all explanation of its topic. However, each is concise and covers the minimum you need to understand about that topic.

The only reason I found this book to be less useful than many of the books I've read recently is because I already understand most of the topics well. There are a few of the template chapters that I felt extended my understanding a bit, but the rest were covered in more detail elsewhere. That being said, I can see this book being of real use to any junior or intermediate level C++ programmer. If you are a senior level programmer, you might find this book useful as a reference for the more junior programmers you work with. I also think this book helps a more senior programmer recognize some of the points where a junior programmer is likely to have problems.

Review of Exceptional C++ Style

Exceptional C++ Style
Herb Sutter
Addison-Wesley, 2005.

Once again, Herb Sutter provides us with a set of problems that teach important lessons in C++. Each problem in the book covers some problem that a C++ programmer might see in a particular program or design. As Sutter solves each problem, he gives insight into the concepts surrounding the problem and the pitfalls that may trip up an unwary programmer.

As usual for one of his Exceptional C++ books, Sutter spends time covering some areas of C++, like exceptions, memory management, and templates, where programmers often have problems. But, unlike many books that teach the syntax of the language, he goes deeper to improve your understanding of how various features work and why. His explanation of exception specifications and why you should not use them is extremely well done. Sutter also explains why the standard streams could be considered a step backward from printf, but that there is hope on the horizon for solutions that support the best of both worlds.

Sutter ends the book with a critique of the std::string class, showing how it could have been better designed based on what we now know of C++. For many programmers, this section alone should be worth the price of the book. The author goes through many of the design tradeoffs with an eye towards simplifying the interface without loss of functionality or efficiency. It is rare that you get a chance to sit with an expert programmer and get him to explain the design of a non-trivial class.

In addition to hard-core technical information, there is a fair amount of style advice and fun examples (how many '+' characters can you write in a row in a legal C++ program). All of which give you more insight into this powerful language. And throughout the whole book, Sutter's interesting humor lightens what could otherwise be a very heavy read.

If you are trying to improve your understanding of C++, this book will explain parts of the language that were never quite clear. Although I would not recommend this book for a novice C++ programmer, I think any intermediate to senior C++ programmer would be well-served by reading it. I plan to recommend it to the C++ programmers I know.

Review of Joel on Software

Joel on Software
Joel Spolsky
Apress, 2004

This book collects some of the best entries from the Joel on Software website. Joel has an interesting view of the software industry based on three years at Microsoft, time spent at Juno, and now with his own company. This is a guy with quite a bit of experience and some interesting insights.

The essays in this book cover a large portion of the fuzzy part of developing software. Joel doesn't spend much time on algorithms or methodologies. Instead, he focuses on the real process of developing software. If you don't believe programs need a functional specification, you need to read what Joel has to say. If you are not sure how to estimate projects, read on. If you would like to know how to hire great programmers (or would like to know why you should), Joel has some answers.

In reading these essays, I often found myself surprised by Joel's opinions. His explanations are clear, and his ideas are interesting. Although I do not always agree with his conclusions or interpretations, many times I feel he is right on target. Some authors make you feel that they are the authority on a subject. Joel sounds like a guy who has been in the trenches and has his own views of how things work. Even when I don't agree with him on a particular subject, the essay gives me another viewpoint to compare to my opinions.

Sometimes he seems to be thumbing his nose at conventional wisdom just to stir up an argument. In some of his essays, Joel takes a position against rewriting bad code, for the not invented here syndrome, against incentive pay, and for bloatware. Each of these essays is bound to tick someone off. But, in each case, his arguments are lucid and force you to re-examine the question in a new light. In the end, you may still not agree with him, or he may have changed your mind. Either way, he will have made you think about the issue more than you probably have before.

I would recommend this book to anyone who has been in software development for a while. I think new programmers are less likely to really get what Joel is trying to say. If you need to manage programmers, you also need to read this book. For those who have been here a while, it's an interesting and entertaining read.

Review of Effective C++, Third Edition

Effective C++, Third Edition
Scott Meyers
Addison-Wesley, 2005

I was really excited when I found out that Scott Meyers was releasing a new edition of Effective C++. The first edition provided a major step on the path for many of us from writing code in C++ to actually programming in the language. What surprised me was the fact that this edition was a complete rewrite of the original. As Meyers puts it, the things that programmers needed to know fifteen years ago to be effective are not the same things we need to know now. Many of the items from the original are no longer new or different, they are the accepted ways to program in C++.

As always, Meyers provides practical advice and sound explanations of his reasoning. Meyers also has an extremely readable writing style that does not get boring after the first chapter. In the first edition, some of the advice went against standard practice of the day, but Meyers did such a good job of explaining his rationale that you had to consider his position. In the latest edition, I found less of his advice to be surprising, but every bit as important. Even though many others have explored some of this territory, I see lots of examples of programmers who violate many of these rules and later regret them. Like the earlier editions, Effective C++, third edition serves as a great description of best practices for C++. Furthermore, if you haven't seen these best practices before, or you were not convinced by seeing some of this elsewhere, Meyers will make a good attempt to convince you.

As with the earlier editions, each item covers a specific aspect of programming in C++ that you must be aware of in order to make effective use of the language. Although it would be possible to gain some of this information by carefully reading the standard reference works, it would be hard to beat the clarity and focus of this book.

One of my favorite items in the book is number 1 where Meyers describes the richness of C++ and some of the pain that comes from dealing with the different facets of this complex language. He suggests treating C++ more as a set of related languages than as a single entity. In the process, he manages to reduce some of the syntactic and semantic confusion by showing consistency within each sublanguage. I am not doing his description justice, you need to read Meyers' version to be properly enlightened.

Meyers does not just focus on usage of the C++ language, he also touches upon important idioms applying to the standard library. He also spends some time on classes expected to join the standard library in the near future, like the Technical Report 1 (TR1) extensions. He also suggests checking out the classes available on Boost.org as a way to see where the language is going.

Another point that impressed me about this book is the level of professionalism in the editing. Lately it seems that spelling and grammar errors have become the norm in technical books. Personally, I find these kinds of errors distracting. I found one typo in the entire book and only a couple of spots where I needed to reread the text to understand what Meyers meant. In today's environment of hundreds of computer books coming out in a year, it is particularly nice to see this kind of attention to detail.

If you program in C++, you need to read this book. Unlike you might have expected, it is not a simple rehash of the earlier editions. Instead it is more of a completely new book in the series. Novice programmers can learn the correct ways to use the language. Experienced programmers can gain better arguments for best practices they are trying to establish and insights into practices they may not be as familiar with.

I can't possibly recommend this book too highly.

Review of Perl 6 Now

Perl 6 Now: The Core Ideas Illustrated with Perl 5
Scott Waters
Apress, 2005

I had mixed feelings about reading this book caused by my current views of Perl 6. Some of what I have heard about Perl 6 is exciting and I really can't wait. Other things I have heard fill me with dread. I can't believe Larry Wall (and the cast of thousands) would want to do these things to Perl. Like many people using Perl, I find the reports coming from the development of Perl 6 are a source of mixed emotions.

What I was hoping to get from this book was a little better clarity on the whole Perl 6 issue. Surprisingly, that's exactly what I got. Scott Walters very clearly covers some of the significant changes from Perl 5 to Perl 6. He introduces several modules that can be used to mimic Perl 6 syntax and functionality now. He also carefully explains which of these modules are not appropriate for production code.

Throughout the book, he explains the differences in syntax and semantics between Perl 5 and Perl 6. To make the concepts clearer, he illustrates most of them with Perl 5, Perl 5 with Perl6 modules, and with (the proposed) Perl 6 syntax. In the process, Walters explains each change and some of the implications. He clearly lays out the points where the examples are pretty solid and where the Perl 6 definition is still in flux.

Sometimes Walters spent quite a bit of time on an aspect of Perl 5 modules without telling you up front about the relation to Perl 6. The example that is fresh in my mind is the long section in Chapter 7 about the Perl Data Language (PDL). In this chapter, he explains the PDL module and many things you can do with it.

To drive his points home, he has a very interesting (and long) example on manipulating audio in the MOD file format. This example is relatively extensive and does a good job of exercising the PDL module. I feel that I got a much better grounding in PDL than I had previously. But, through this entire section I kept wondering what does this have to do with Perl 6. Eventually, we discover that Perl 6 will support this kind of functionality natively and a separate module will not be needed.

Except for that example and the discomfort I'm still feeling for some of the changes proposed for Perl 6, I can't really think of anything bad to say about this book. Overall, I enjoyed it. There are a few features that Walters explained that I am now really looking forward to. (There are others I'm still not happy about. We'll see how it all shakes out in the end.)

If you are looking to get an understanding of Perl 6 and you can't just absorb information directly from Larry Wall's Apocalypses, this book will give you a bit more of the flavor of Perl 6. If you are perfectly happy with Perl 5 and don't know why anyone would change it, this book will not change your mind. If you are new to Perl, this is not the book to start with. But, if you are interested in Perl 6 and want to know more, or would like to see how people are pushing Perl 5, this book is definitely a treat.

Review of C++ Primer (Fourth Edition)

C++ Primer (Fourth Edition)
Stanley B. Lippman, Josée Lajorie, and Barbara E. Moo.
Addison -Wesley, 2005.

Every now and then, someone asks me to recommend a book for learning C++. Until very recently, I didn't have a good answer. The book I learned C++ from went out of print years ago (and would be horribly out of date by now). There are lots of books that teach beginning C++, but I hadn't read one in years.

That has all changed. In the last few years, there have been two books with a new approach to teaching C++ that I have actually liked. The first was Accelerated C++. That book provides a good way to get your feet wet in C++. Unfortunately, the C++ language is so big and rich that it was not able to really do the subject justice. Now, the fourth edition of the C++ Primer comes out and uses a similar teaching technique and strives to cover the whole language. Amazingly enough, I think it succeeds.

The approach to teaching C++ that I learned was to start with an understanding of C. We start with the C way of doing things and introduce the C++ features on that base. Eventually we replace C features with C++ and the training is complete. This book takes a different approach. Since the authors are teaching C++, the C way of doing things is ignored from the beginning.

We get std::iostreams and std::strings almost from the very beginning. When we first need to collect multiple items of the same type, we are introduced to std::vector. C-style strings and arrays are discussed much later in the book, as relatively minor features of the language. In fact, when arrays are eventually introduced, the authors spend a fair amount of time describing their deficiencies when compared to vectors.

The readers of the book are also introduced to the use of classes and objects the same way they are introduced to int and floats. Time is spent explaining how to use the library classes with plenty of exercises and examples long before the reader is shown how to construct their own classes. I feel this approach does a much better job of acclimating the new programmer to objects than the older approach which began by trying to build classes.

In addition to the different style of teaching, this book also has relatively complete coverage of the language and libraries. Some of the sections on the standard containers and algorithms actually made me think about those tools in new ways. This is despite my having used those classes for a large number of years. The book also includes a few sections on more advanced topics that might not be appropriate for the C++ beginner. But these sections are well labeled and the reader is warned to skip ahead until some of the earlier material is completely mastered.

In a book this size, it would be hard to get everything exactly right. I found a number of minor editing errors, as well as a few style issues that I thought might not serve a junior programmer well. Other than that, my only complaint is that it is a big book (weighing in at 885 pages including index).

All in all, I plan to recommend this book to anyone wanting to learn all of C++. This is a terrific introductory book that covers enough of the language to keep someone learning for quite a long time. It also covers enough best practice sort of information to make certain that a novice programmer is steered away from some of the worst mistakes.

Review of Eric Meyer on CSS

Eric Meyer on CSS
Eric A. Meyer
New Riders, 2003

Styling web pages with CSS allows for a very good separation of structure and presentation. In this book, Eric Meyer focuses on the design aspects of using CSS. Many other books describe individual features of CSS and even show how to generate particular effects with CSS. This book walks through a series of projects and shows, step by step, how a real design expert lays out a site.

In the process, Meyer shows how many CSS attributes should be used. He shows some of the tradeoffs involved in using different features and effects. As you follow along with the exercises, you get more than just the mechanics of changing styles with CSS. You get a sense for how someone who really knows CSS and web design goes about applying his craft.

I found this particularly helpful. I have more than a basic grasp of CSS, but I don't really grok the design aspects. Although I'm not ready to trade in my programmer hat for a web designer hat, this book has given me a better feel for generating a good-looking design.

I would definitely recommend this book to anyone trying to really design nice looking web content. I also can't wait to get a chance to read the sequel to this book.

Review of Hardening Linux

Hardening Linux
James Turnbull
Apress, 2005.

I've read several books over the years focused on increasing the security of a Linux system. I think Hardening Linux may be the best example I've seen of a practical book on the subject. Turnbull walks through a number of potential security vulnerabilities and gives specific advice on locking them down.

The book includes the expected grounding in basic security principles like denying access by default and strong passwords. Even though Turnbull spends most of the book on securing individual vulnerabilities, the book is not just a checklist of things to change. He also explains the reasoning behind the changes and some of the side effects that you should be aware of. This explanation is probably the most important feature of the book. If you need to set up a bastion host, secure a mail server connected to the Internet, or just want to know something about the dangers of providing services to the Internet, this book gives you a strong grounding in the issues that determine the security of a server.

As a good example, I have read several articles and books that tell you how to configure a firewall. But, I don't think I have ever seen a better description of why you make some changes and not others. I particularly liked Turnbull's discussion of the issues with configuring a firewall remotely. Anyone who has accidentally locked themselves out of the system they are configuring would appreciate his advice.

I especially liked the the chapter on securing FTP. Turnbull firmly states that FTP is extremely hard to secure. He covers the various reasons why it is hard to secure. He states firmly that in the interest of security, you should not run an FTP server. Then, he goes step-by-step to show how to provide as secure an FTP server as possible if you really have to have one. This stands in stark contrast to an academic approach of ignoring systems that can't be made secure. Turnbull does a great job of making that point, and then bowing to the necessity that some people will need the service anyway.

Although I really enjoyed the book, it did have a couple of flaws. One is inherent in the topic: this is a really dense book. If you don't do serious system administration on a daily basis, you may find this book to be slow going. I sure did. However, this material is well covered despite being dense. Working through the material is worth the effort. The other problem has to do with editing. I found a relatively large number of minor typos, grammar errors, and mistakes in examples. Although it was still possible to understand what the author was saying, I feel that these errors made the task of working through the book a little more difficult.

Overall, I would definitely recommend this book to anyone who needs to secure a Linux server for any reason. If you are interested in what needs to be done to secure a mail server, DNS server, FTP server or any other public server, this is definitely a book you need to read.

Review of Randal Schwartz's Perls of Wisdom

Randal Schwartz's Perls of Wisdom
Randal L. Schwartz
Apress, 2005

Randal Schwartz has been writing about Perl since the first edition of the Camel Book. This book collects articles that he has written for a number of magazines into one place, organized (loosely) by topic. These articles span almost a decade of writing on the topic.

In any book by Schwartz, you can expect lots of Perl code, clear explanations, and a bit of humor. In this book, you also get to see how some ideas have evolved over time. Different articles from different time periods on similar topics showing how Schwartz's understanding has changed. He also often provides some insight into why the code is written the way it is or the subtle meaning of some of his idioms.

This is the kind of information that is missing from most books on programming. Why do you choose to write the code this way rather than that way? This book gives you some of that from a veteran in Perl. I've been programming in Perl for over a decade, and I found several tidbits that I either never knew or had forgotten. Schwartz introduced modules that I hadn't used yet, and techniques that I had.

If you are doing any programming in Perl, I would definitely recommend this book very highly.

Review of Code Complete, Second Edition

Code Complete
Steve McConnell
Microsoft Press, 2004

Ever since I learned that a new edition of Code Complete was to be released, I have been looking forward to it. The first edition has been one of the most comprehensive books on the actual practice of writing code. We see a large number of books on methodologies and the high-level aspects of software development. But, if there is to be any software at all, someone must write it. This book covers that part of the process.

The second edition manages to update the information from the first edition to present practice. Many practices have emerged in the ten years since the first edition, and McConnell covers them extensively. Unlike a lot of books in our field that are filled with opinion and generalities, McConnell backs up what he says with hard numbers where possible and loads of research in any case. If you are looking for an authoritative reference, the bibliography of Code Complete fills 21 pages including several hundred references that span almost fifty years of research.

In the book, McConnell not only gives rational explanations for his recommendations, he also tells you where to look if you wish to dig further. While this is not unusual in academic literature, it is definitely not the norm for our field. McConnell covers a large percentage of best practices in the field. He is also not too proud to admit mistakes. In a few places in the text, he points out recommendations from the first edition that he says did not work out as well as he would have liked in the intervening years. He also points out a few mistakes, as well as changes in the industry that require modifications to his older advice.

Although I don't necessarily agree with everything McConnell says, the points we disagree on are so minor as to not warrant discussion. If I could only recommend one book to a new or intermediate-level programmer, this would be the book. I would be willing to live with the minor disagreements, if the programmers I work with would learn and apply the rest of the book.

If you are learning to program, get this book and read it. I realize that it is huge (over 900 pages), but learning the lessons in this book will greatly improve your skills and knowledge in software development. If you are a senior developer and haven't read the first edition, this book will still help you improve your skills. If you read the first edition, this book is still worth a read.

I don't think I could recommend this book too highly.

Review of Software Exorcism

Software Exorcism
Bill Blunden
Apress, 2003

I was really looking forward to this book, having spent a fair number of years maintaining legacy code in different languages and environments. This made the disappointment even more acute when the book did not live up to its subtitle: A Handbook for Debugging and Optimizing Legacy Code.

The beginning of the book looks promising. The author begins by looking at some of the non-technical forces that influence the success of a software project. He covers the need for sign-off and the importance of a paper trail. He talks about scope creep and complexity. This seems like a really good introduction to the parts of software development that most developers don't think about nearly enough.

The last chapter of the book ties back to these concepts, extending the list of non-technical challenges that hamper getting work done. Topics like fashionable technology, the lack of privacy at work, marketing hype, and other issues that we technical types tend to ignore have a huge impact on your ability to get work done. This chapter does a decent job of making you aware of each of these issues without digging into too much depth. Some of these issues are touched in other parts of the book as well.

Unfortunately, the author does not develop these points further in the book. These topics would be a wonderful education for people coming into software development. It would also serve as vindication for those of us who have seen more of this and realize how much these issues overwhelm the technical issues. What really bugs me is that this isn't the material the book claims to cover.

Starting in the middle of chapter 1 and extending through chapter 6, is what should be the meat of the book. The author's discussion of coding techniques and tools is weak. The book contains technical errors. Some of the source code has major flaws, like refactorings that generate code that is as bad as the original. The best is the memory pool example in chapter 5 that doesn't even use the pool code he wrote.

The author regularly states his opinions as fact without supplying any proof or hard statistics to back up these claims. I was amused by the assertion that the original developer would know enough to make changes to the project without having to relearn everything, but they are never around. He also points out that there wouldn't be bugs in the programs if the original developers had just done things correctly. Actual experience does not support these claims.

I think my favorite unsupported claim is the suggestion that virtual memory is an anachronism, that is unnecessary now that we can get machines with 2GB of RAM. He seems to be forgetting that modern multi-tasking operating systems would be pretty much useless without virtual memory.

In chapter 1, the author develops a logging library, a unit testing library, and a profiling tool. Yet, he spends no time talking about free tools that already fill these needs. He focuses a significant number of pages in the book to constructing some rudimentary debuggers to show how debuggers work, but spends almost no time discussing features of real debuggers that could actually help a maintenance programmer solve problems.

His debugging advice was relatively straightforward. The best of his advice is covered more completely by other books (like Code Complete or The Pragmatic Programmer), some of which have been out for many years. His optimization advice is better ignored. After suggesting that minor tweaks are a bad idea, he spends around a hundred pages telling how to save 5 machine instructions here and 10 over there. After all of these he mentions the concept of picking better algorithms as a quick fix.

All in all, the book does not do a very good job at what it claims to do. The debugging and optimizing information just isn't there. It does have some good information about the non-technical challenges of development; but I can't see wading through the rest of the book for these nuggets. Hopefully, the author will combine the first part of chapter 1 with chapter 7 as the core of a really good book on the non-technical part of development.

I really hoped I would be able to recommend this book, but I can't.

Review of Practical Subversion

Practical Subversion
Garrett Rooney
Apress, 2005

I have worked with several version control systems over the years. But my system of choice for the last decade has been CVS. For the last year, I've been looking at Subversion and I like a lot of what I've seen. I've read the book Version Control with Subversion, which does a good job of covering the program, but the information wasn't quite complete. This book answers most of my outstanding questions.

The writing style is quite readable and the examples and explanations are well done and helpful.

However, the book does suffer from a kind of split personality. On the one hand, it wants to be a good handbook; something that you can use to get up and running with Subversion quickly. On the other hand, it wants to be a reference book; where you can go for all the details of setting up and using Subversion under any circumstances. It is possible to do both in one book. If a book covers the basics up front and saves the reference for later, the reader can tell immediately which section he needs..

Unfortunately, Rooney did not take that approach.

The first two chapters are great handbook material. They help familiarize a novice user of Subversion with the tool. These chapters introduce concepts and commands in a very practical fashion. The trouble begins in chapter 3, where the author suddenly changes from the handbook style into a definitive reference of the administration details of Subversion. This reference-style continues for three chapters, before suddenly changing back to practical information with the Best Practices chapter. Then, in the middle of the next chapter, we go back to reference style.

While both the handbook and the reference are necessary, I think it would have been easier on the reader if the two styles had been separated into two separate sections of the book. Changing back and forth makes the book harder to read than necessary.

That being said, I still think this is a very good book that complements the earlier work on Subversion quite well. The reference material on the different server types, programming to the API, and the conversion programs were definitely lacking from the earlier book. Practical Subversion does a great job of filling that lack.

The real highlight of the book for me was the chapter on best practices. Over the years, I had to discover most of these the hard way. It is great to see them written in such a clear and usable fashion. Time and time again, I have seen programmers misuse version control systems because they lacked the wisdom displayed in this one chapter. This chapter should be required reading for every programmer.

Despite the criticisms above, I still found this to be a very good book. I recommend it to anyone who is using Subversion or who plans to use Subversion in the future.

Review of Hackers & Painters

Hackers & Painters
Paul Graham
O'Reilly, 2004

I was really looking forward to reading this book. I had read a few of Graham's essays in the past and found his ideas to be thought-provoking. I expected some to find more of the same.

Instead, this book ranged over a lot of topics, not all of them big ideas. Some of the chapters did make me think, some insights were definitely worth considering. Unfortunately, some of the chapters were based on extremely simplified views of the past couple of decades.

Graham's chapters on business and making money ignore the cut-throat business practices that many companies thrive on. He suggests that CEOs really are worth 100 times as much as the average employee, because they direct the company as a whole. Unfortunately, all you have to do is look at the news over the last few years to see that belief is flawed. He describes Microsoft as being run by a brilliant and lucky technologist. In the process, he ignores the way they have often used legal clout and monopolistic practices to stay on top.

Graham's assertion that all applications will move to the web and all data will reside on the servers also seems a bit premature. He asserts that servers will be better maintained, backed up, and protected from viruses. We have seen plenty of cases where that wasn't true. He also dismisses the security implications of someone else owning your data as if it were a minor annoyance.

Graham is obviously enamored with Lisp. I agree it is a powerful language, but I'm not sure that it is the most powerful language as he suggests. I find it funny that that he says the ability to provide code for read-time, compile-time, and run-time is a feature in no other language except Lisp. But, I used that ability for years in Forth. He also makes the mistake of assuming that the power of a language is a single dimension, without taking into account that some languages are more powerful than others for a particular job.

All in all, I found this book to be a disappointment. If you were already interested in Graham's views, I wouldn't try to convince you not to read the book. But, I'm afraid that I would not recommend the book.

Review of C++ Coding Standards

C++ Coding Standards
Herb Sutter and Andrei Alexandrescu
Addison-Wesley, 2005

For many programmers, the term coding standard generates a gut-level response. We all know that someone is going to be pushing the one, true brace style or the proper way to indent code. This subject is probably the best way to generate instantaneous rebellion among a group of programmers.

The first "standard" in C++ Coding Standards wipes all of that away with their first rule:

0. Don't sweat the small stuff. (Or: know what not to standardize.)

In one quick entry, Sutter and Alexandrescu sweep all of the indent-level, brace-placement, CamelCase/underscores holy wars into a single category and give a useful bit of advice: Be consistent. The authors point out that any professional programmer should be able to read and write in any of these styles. The differences are basically a matter of personal preference.

From this point on, we get to see a coding standard that is focused on best practices and proven techniques for improving code. Almost every item is explained with examples. Some have exceptions, with an explanation of when (and if) the exception should override the rule. All of the rules contain references to other sources to read for further explanation,

The rules cover such general topics as 1. Compile cleanly at high warning levels and 3. Use a version control system to specifics like 73. Throw by value, catch by reference. Some of the items could be considered common sense if it weren't for the fact that I've seen them regularly violated by people who claim to be professional. Others are based on knowledge of the language and implementation details that most of us never need to care about.

There are even a few rules that violate my personal list of "best practices." Like all of the others, the advice in the book is authoritative enough and backed by good reference. So even on the issues that I disagree with, Sutter and Alexandrescu argue their case well enough that I plan to go back and reassess my views.

If you are a new C++ programmer, this book will help you learn to be a much better programmer. If you are an experienced programmer, this book will help improve your skills and give you a reference to use to help keep more junior programmers in line. If you manage C++ programmers, this book is a good starting point for a coding standard to improve the work of all of your programmers. I don't think I can recommend this book too highly.

Review of CSS Cookbook

CSS Cookbook
Christopher Schmitt
O'Reilly, 2004

This has become my new favorite book on CSS.

For quite some time, the only way to learn to use CSS in website design was search the web for references, keep CSS: The Definitive Guide by your side, and experiment. The problem is that the interactions with the different browsers is a mess and not everybody thinks in the CSS model.

This book helps on both fronts. The recipes in the book each have a section in the discussion that describe various browser incompatibilities and their workarounds. There is also a full chapter devoted to the workarounds. More importantly, the author handles each recipe by telling you how to solve your problem correctly, and then explains how to make the minimal changes necessary to deal with browser incompatibilities.

Unlike a few books I've seen in the cookbook style, the CSS Cookbook does it right. Each recipe starts with a problem you might want to solve on your site and walks you through solving that problem. Some of the recipes give multiple solutions and describe some tradeoffs, so you can decide which is right for you.

The book isn't perfect, I found a couple of grammar mistakes that should have been caught in editing and the last figure of chapter 8 is missing. Overall, it seems to be a really good effort.

If you are doing any web design work, I would highly recommend this book. I plan to be using some of the recipes to clean up a few things on my site that I didn't get quite right.

Review of The Little Schemer

The Little Schemer
Daniel P. Friedman and Matthias Felleisen
The MIT Press, 1996.

One of my wife's friends recommended this book for learning Scheme. He's a big proponent of Scheme and has even done research into teaching Scheme to kids. He is quite knowledgeable in his field. On the other hand, I have never written a line of Scheme; although I did some coursework with LISP during my master's degree. Although I don't normally choose to work in LISP(-based) languages, I can appreciate some of their power.

I realized that this book was going to require a bit of suspension of disbelief in the preface, where I found this gem:

Most collections of data, and hence most programs, are recursive.

I agree that there are many useful collections of data that are recursive. I would even agree that many programs apply recursion. But I find the assertion that most are recursive a little strong. In fact, the only way I could see this is if the language the writers were working in treated almost everything as recursion. And, of course, this is the case.

The other real problem I had with the book is the style. The book is written as a series of questions and answers that lead you to the conclusions that they wish. Some of these question and answer sessions became quite strained; such as trying to explain how a complicated function works. In other spots, the authors asked a question that there is no way the reader could have begun to answer. The authors would then respond with something like:

You were not expected to be able to do this yet, because you are missing some of the ingredients.

I found this style very jarrng. I've learned a dozen or so languages from books (including LISP), and I've never had this much trouble understanding a computer language. The style may work for someone else, but it did nothing for me.

From the comments above, you might decide that I have nothing good to say about the book. That's actually not the case. I found the Five Rules and the Ten Commandments to be very effective ideas. The Five Rules basically define some of the most primitive operations in the language. The Ten Commandments state some important best practices.

I was also surprised at times by really sweet pieces of code and understanding that would come after some prolonged pseudo-Socratic Q&A sessions. Some of the insights and commandments are well worth the read. But, overall I found it difficult going.

Since it is considered one of the classics for learning Scheme, you should probably consider it if you are needing to learn Scheme or LISP. If all you've done is code in C or Java, it might be worth reading to introduce yourself to another way of looking at problems. But, I find it very hard to recommend this book to anyone else.

Programming Magazines

This is not really a book review. But, due to my recent change in commuting, I've been able to begin catching up on past issues of the programming magazines that I read. Due to one thing or another, I've gotten behind in my magazines over the past few years. But, I'm making up for that now.

Here is a list of the programming magazines that I read regularly. (At least the ones I read right now.)

C/C++ Users Journal

I've been reading CUJ for a long time (since it was the C Users Journal). I consider it to be a wonderful source of information about the C and C++ languages. It also covers related languages such as Java and C#.

Dr. Dobb's Journal

This is, of course, a classic. I've been reading DDJ for longer than I've been reading CUJ. I like the coverage of general programming trends and topics that impact our industry indirectly, as well as the more technical coverage. I also enjoy the various columns. I don't always agree with what they have to say, but I always like reading it.

Linux Journal

I rely on the Linux Journal for information on all things Linux. In addition to the advocacy, this magazine provides hardware and software information for anyone interested in Linux.

The Perl Journal

I have thoroughly enjoyed the Perl Journal over the years, even though they have gone through some hard times. I followed them from the original print magazine, through their stint as a section in SysAdmin Journal, and into their current incarnation as a web-published magazine. The magazine has ongoing articles from some of the names in Perl and usually manages a light-hearted view of everything. Although that has not been as evident as it was in the beginning.

The Perl Review

Recently, I rediscovered the Perl Review, another online magazine. In many ways, the Perl Review reminds me of what first attracted me to the Perl Journal. It contains good, solid information about solving problems with Perl. Unlike many magazines, it does not take itself too seriously. This combination of useful information and light-hearted attitude makes it a joy to read.

There are several others that I have read over the years. But, given the constraints of time and money, these are the ones I've settled on for the moment.

Review of Compiler Design in C

Compiler Design in C
Allen I. Holub
Prentice Hall, 1990

I decided to take a break from the relatively new books I've been reviewing and hit a real classic.

Over a decade ago, I saw Compiler Design in C when I was interested in little languages. A quick look through the book convinced me that it might be worth the price. I am glad I took the chance. This book describes the whole process of compiling from a programmer's point of view. It is light on theory and heavy on demonstration. The book gave an address where you could order the source code. (This was pre-Web.) All of the source was in the book and could be typed in if you had more time than money.

Holub does a wonderful job of explaining and demonstrating how a compiler works. He also implements alternate versions of the classic tools lex and yacc with different tradeoffs and characteristics. This contrast allows you to really begin to understand how these tools work and how much help they supply.

The coolest part for me was the Visible Parser mode. Compilers built with this mode displayed a multi-pane user interface that allowed you to watch a parse as it happened. This mode serves as an interactive debugger for understanding what your parser is doing. This quickly made me move from vaguely knowing how a parser works to really understanding the process.

Many years later, I took a basic compilers course in computer science and the theory connected quite well with what I learned from this book. Although the Dragon Book covers the theory quite well, I wouldn't consider it as fun to read. More importantly, nothing in the class I took was nearly as effective as the Visible Parser in helping me to understand the rules and conflicts that could arise.

Although this book is quite old, I would recommend it very highly for anyone who wants to understand how parsers work, in general. Even if you've read the Dragon Book cover to cover and can build FAs in your sleep, this book will probably still surprise you with some fundamentally useful information.

The book appears to be out of print, but there are still copies lurking around. If you stumble across one, grab it.

Review of XML Bible

XML Bible
Elliotte Rusty Harold
IDG Books, 1999

As computer books go, this book is old. However, it does a spectacular job of handling all of the nitty-gritty details of XML. I first stumbled across this book when it was new. The only really definitive information you could find on XML was the W3C recommendation itself. This book does a very good job of explaining most aspects of the XML recommendation in a more conversational style.

Currently, most people who need to work with XML know (or believe they know) enough about it to work effectively. The W3C recommendation is still the place to go for definitive answers to clear up any confusion. But, if you need to be the expert, and you don't want to spend a lot of time reading the official version, this book will probably answer any question you have, without putting you to sleep.

Although the book is very complete on XML, it does not cover any of the more recent tools and specifications. This is understandable since it was written before they existed. In spite of that, I still highly recommend this book.

Review of XML in a Nutshell

XML in a Nutshell
Elliotte Rusty Harold and W. Scott Means
O'Reilly, 2001

This is a good overview of XML-based technologies as of 2001. If you are looking for a deep understanding of the uses of XML and related technologies, this is not the right book for you. However, if you are looking for a high-level overview or a book to refresh your memory, this is the book to read. It provides a good overview of the major technologies available, including XSLT, XPath, CSS, SAX, and others.

Unlike many books and articles I've read, this book looks at the two main philosophies of XML in a relatively dispassionate way. One section of the book is devoted to XML as documents, which they call Narrative-Centric Documents. Another section is devoted to XML as Data, which they call Data-Centric Documents.

Unlike many writers, I find many good uses for both approaches. This book treats both approaches equally and covers how some of the related technologies relate to each.

Review of Programming Pearls

Programming Pearls, Second Edition
Jon Bentley
ACM Press, Addison-Wesley, 2000

One of my favorite programming books of all time now has a second edition. I've got to say it's as good as the original. Many years ago, I stumbled across Jon Bentley's Programming Pearls. It is a great book on programming. It did not focus on the methodology or programming language of the day. Instead Bentley gave solid, fundamental information about programming. He explained that solving programming problems is about thinking and gave lots of problems to help you think about what you do. After reading Programming Pearls, I found More Programming Pearls, and read that one as well. These books really highlight the difference between a programmer and someone who just slaps code in place to get a paycheck.

The new edition carries on in that tradition. Most of the columns are updated. A few examples have been changed to make sense for today's computing. Most of the code examples are now in C++. But the core of the original information and the thrust of the book remain the same. Bentley's writing style is very entertaining and clear, and his insights are fundamental to the work we do. The examples and problems in the book provide a great opportunity to sharpen your skills.

Every programmer should read this book.

Review of Peopleware

Peopleware
Tom DeMarco and Timothy Lister
Dorset House Publishing Co., 1987

If you are a manager trying to get better work out of your programming staff, you need to read this book. If you are a project lead trying to be determine how to make your team more effective, you need to read this book. If you are a programmer trying to decide if there are any good managers out there, you need to read this book.

Peopleware is the best book I've ever read on the subject of managing programmers. The advice may actually apply to managing other kinds of workers, I'm not qualified to say. DeMarco and Lister really hit the nail on the head when dealing with programmers though.

All of the best managers I've ever had followed at least some of the advice in this book. Some just naturally managed that way, some changed their style after reading this book. On of my best managers once explained the relationship between the manager and team by saying Your job is to make me look good. My job is to give you everything you need to do your job. DeMarco and Lister are much more explicit about their advice, but it basically boils down to that.

As a manager or project lead, you should be focused on removing obstacles and getting your people what they need to do their jobs. This can mean information, or access to people who can give them what they need, or training. What many of the best managers I've had find is that good people will do almost anything if they've got what they need. As a side effect, the manager looks good, because his people are always productive.

This book is also describes the jelled team. Anybody who has ever worked with a team in this state will recognize it. This is the state where the team truly is more than the sum of it's parts. Almost everyone I've know who has been part of a jelled team would be willing to work on almost any project to be part of such a team again.

This book cannot be too highly recommended.

Review of Randomness

Randomness
Deborah J. Bennett
Harvard University Press, 1998

This book covers the subjects of randomness, probability, and statistics better than any other book for the layman I've ever seen. As a programmer, most of the books I've read on these topics are either heavily into the math and theory of the subject or focused on programming techniques. This book covers the subject matter in a way that is much more accessible.

The beginning of the book covers randomness and chance throughout our history. The author covers early randomizers like dice and lots. She also talks interestingly about how religions affected the perceptions of randomness and chance. Based on this background, she explains why people in general have extremely bad intuition regarding these subjects. Along the way we meet random sampling and the effects of random errors on the interpretation of tests. Late in the book, we finally come to the subject of random number sequences and comuter generation of such sequences.

This book is great for anyone who wants a better grasp on the concepts of randomness, probability, and statistics. It is also a relatively easy read.

Review of Perl for Web Site Management

Perl for Web Site Management
John Callender
O'Reilly, 2002

This book may be one of the best books I've ever seen for getting Perl used in a place where it is sorely needed.

Many people developing web-based applications are not programmers. They learned to use some HTML authoring tool and progressed from there. Many of them never quite get the idea of automating the grunt work of their jobs. This book tries to introduce these people to Perl as a labor-saving device.

If you are doing any form of web site maintenance, this book is worth a read. If you are a programmer working on web sites, you are probably doing most of what this book teaches. But, if your background is not in programming, this book will probably increase your productivity dramatically.

Review of Modern C++ Design

Modern C++ Design
Andrei Alexandrescu
Addison-Wesley, 2001

This book just blew me away. I've had access to compile-time programming in other languages and had worked pretty hard to understand templates. I felt I had a better than average grasp of how C++ templates work and are used. The techniques in this book were astounding. I have since found many sites devoted to these techniques, but I remain impressed with the way Alexandrescu explains the basics of these techniques.

Warning: This book is definitely not for everyone. But if you really want to push the limits of what you can do with C++, you need to read this book.

Review of The Logic of Failure

The Logic of Failure
Dietrich Döner
Perseus Books, 1996

This is a spectacular book on why people make mistakes. This book gives wonderful insight into design and troubleshooting that you won't get from any traditional book on programming.

A large portion of the book describes how very intelligent people make what seem like blindingly stupid mistakes. It shows how people stop thinking logically when there is a delay in feedback between cause and effect. It also shows how people react when the situation seems to be getting worse despite their efforts. You have probably observed some of these behaviors in people when things really begin to go wrong.

Amusingly enough, a friend of mine pointed out that this book would have been much more successful except for the mistake of focusing the title on failure. With that focus, obviously some of people avoided the book because the don't want to contemplate failure.

Although not a normal book on programming, I would recommend this book to any programmer who needs to do troubleshooting or development under the gun. It may not solve your problems, but it may help you understand when people including you start reacting to a stressful situation.

Review of Mastering Regular Expressions

Mastering Regular Expressions
Jeffery E. F. Friedl
O'Reilly, 1997

If you use regular expressions on a regular basis, or if you've used them a little but want to get better, this is a book you need. I had been working with regular expressions for over ten years when I first read this book. I was used to helping other people debug their regular expressions and thought I knew them very well. This book improved my regular expressions tremendously.

The book covers multiple regular expression implementations, including AWK, grep, Tcl, GNU Emacs and Perl 5 regular expressions. Friedl does a good job of covering basic regular expression concepts before going on to more advanced topics. Some of these include different types of regexp engines and their effects on the expressions you write, and greediness. He covers some regexp gotchas including regular expressions that may never terminate.

Throughout the book are a number of useful techniques that will improve your daily use of regular expressions.

Mastering Regular Expressions is highly recommended.

Review of Exceptional C++

Exceptional C++
Herb Sutter
Addison-Wesley, 2000

I had been working with C++ for a number of years before I read this book and I thought I knew the language.

This book provides 47 problems with included solutions. Trying to solve the problems is very important. Each one tests an area of C++ that some people find unclear. In some cases, I didn't realize that I was unclear on the topic until I solved the problem and finished reading the explanation. These problems will stretch your C++ skills and solidify your understanding of the language.

The second section of the book covers exception safety. In some ways, this may be the most important part of the book. Sutter really does a great job of converting gut-level intuition about exceptions into logical, useful knowledge. In this section, he covers different levels of exception safety and what each level guarantees. He then uses these levels and their guarantees to analyze and construct exception-safe code.

In addition to explaining why some things that work actually work, this book did a great job of showing when and where other good ideas will blow up in your face.

Exceptionally highly recommended.

Review of The Design of Everyday Things

The Design of Everyday Things
Donald A. Norman
Doubleday, 1988

I know this isn't a book on programming, but it is a very good book on design. Norman shows design mistakes in everyday items like door handles and stoves, as well as nuclear power plants and trains. He also introduces design principles that you can use when creating software. Some examples include

• Controls that do different things should look different.
• Make relevant parts visible.
• Give an action obvious and immediate feedback.

He also discusses affordances and uses the concept to explain why we push on doors marked pull.

This is a must-read book anyone who does any kind of design. If you are writing or designing software, this means you.

Review of Software Craftsmanship

Software Craftsmanship
Pete McBreen
Addison-Wesley, 2002

This book is clearly written by someone who gets programming. I'm not sure how well the current business climate would accept his idea of Software Craftsmen, but I'm certain programmers (good and bad) will see an idea they like.

The main premise of the book is that programming is less like an engineering discipline and more like a craft. As such, McBreen suggests that the way to improve applications is to follow a craft model more precisely. New programmers should be apprenticed to more senior programmers. We should encourage pride in one's work. A program should not be something you code and then toss to maintenance. He argues that this would help to develop skilled craftsmen, instead of just people who have passed a certification course.

The ideas in this book push back against the kind of software engineers who seem to consider actually building the software and making it work as being a minor detail that occurs after the real work is finished. This kind of software engineer would probably regard this book as glorifying the worst kind of hacking. But, I think he or she would be doing this book and their own abilities a disservice by dismissing the book and its ideas that easily.

I've seen mentored or apprenticed programmers become very good in a short time. I also agree that pride in your skills and work seems to improve the results. So, some of what McBreen says resonates with my experience. But, I'm not sure I agree with all of his conclusions. One of the best programmers I know, suggested that this book was a not very methodical or logical in it's presentation. I saw it more as exploring an approach rather than presenting a road map for implementing it.

I'm not sure I agree with all of what McBreen says, but this book is definitely recommended. No matter what model of modern software development you subscribe to, this book has some ideas worth considering.

Review of Questioning Extreme Programming

Questioning Extreme Programming
Pete McBreen
Addison-Wesley, 2003

This book starts off with the premise that XP is really not appropriate for many projects. However, far from being a bash XP session, it turns into a very hard-nosed look at many methodologies. He compares many of the strengths and weaknesses of the major development methodologies in a way that shows that none qualifies as the silver bullet.

The author does a very good job of skewering some of the hype about XP while simultaneously showing many of its strengths. If you are considering XP, you really need to read this book for his analysis of what projects can succeed with XP. I think the most important insight from this book was the evaluation of what is needed to stop doing XP.

If you have a strong opinion, either way, about XP, this book will make you question your position.

Review of the Java Cookbook

Java Cookbook
Ian F. Darwin
O'Reilly, 2001

In spite of the fact that it is supposedly written in the style of the Perl Cookbook, this book was a real disappointment. The cookbook format is intended for showing solutions to common problems. However, the author of this book appeared to be trying to force a tutorial and an API reference into a cookbook format. The result is not really a cookbook, or a tutorial, or a reference.

The chapter on threading was a particular disappointment. The author regularly misused the term deadlock and did not cover useful threading classes like Timer. If you know almost nothing about Java or are very rusty with the language (as I was when I read this book) it is possible to learn a few things from this book. However, I have to believe that it would be done better elsewhere.

Overall, I can't think of any reason to recommend this book.

Review of Book Darts

Although it's not a book and not directly related to programming, I am going to review one of the best reading tools I've ever seen, Book Darts.

If you read or deal with a lot of reference books, you need to look at these little wonders.

Several years ago, my wife bought me a pack of these little page markers on a lark. My reading has not been the same since. Basically, a Book Dart is just a thin piece of folded over bronze with one side shaped like a pointer. It slides onto a page in a book and point to an exact location on the page.

I have used them in two different modes. I keep a few for bookmarks in whatever book I'm currently reading. The main advantage over normal bookmarks is that I don't lose them. But, that is not the use that really makes them shine.

When you find a passage in a book that you want to come back to, place a book dart in position pointing exactly to the information you are interested in. Later, the passage is easy to find and the book dart is thin enough that you can close the book and not mar the paper. When I was in college, people used post-it notes with arrows drawn on them to point to an exact passage. But, the post-its looked ratty, didn't stay where you wanted them, and were not appropriate for long-term marking.

Book darts solve all of these problems. They are also inexpensive (Ten cents each in bulk). One warning, they are addictive. I have a large number of programming reference books with dozens of useful passages marked. (They also now come in different colors.)

Review of SVG Essentials

SVG Essentials
J. David Eisenberg
O'Reilly, 2002

A little over a year ago I bought and read SVG Essentials by J. David Eisenberg. At the time, I was moving from dabbling in SVG to beginning a contract which required the use of SVG.

This book provides a good working overview of SVG. I have seen several articles that showed how to produce specific effects or that explored a piece of SVG functionality. I've also read the W3C specifications. This book provides the practical information you need to actually use SVG.

One interesting point about the book is it's lack of spectacular graphics. The author states that this is by intent. Most of the pictures only illustrate one, or a small number, of features at a time. He also states that he doesn't want the pictures to overwhelm the novice SVG user that would be discouraged by not being able to produce beautiful work equal to the art in some books.

If you need a refresher on vector graphics or if you want to explore this new XML application, this book is definitely recommended.

Review of Slack

Slack
Tom DeMarco
Broadway Books, 2002

In Slack, Tom DeMarco takes a somewhat heretical position about how a business can succeed. He argues somewhat convincingly that companies need less efficiency and more slack in order to adapt to changes in their environment. DeMarco goes on to define slack as that period of time when you are 0% busy. While not as profound as Peopleware, this book is quite thought-provoking.

One real surprise for me was that, although I agreed with many of his points, I did not feel that he really proved his conclusion. He states that a lack of slack makes it harder to adapt to change, and then moves on. He states that the current fascination with efficiency is the cause of the lack of slack, and then he moves on. In some ways the book does more to make you think about the subject and then states a conclusion that he expects you to agree with.

Despite these complaints, Slack is a good book for anyone doing management or project management. It may not change your mind about the way companies should work. But, it does provide a different viewpoint

Review of MySQL CookBook

MySQL CookBook
Paul DuBois
O'Reilly, 2003

This book covers a large amount of material on using MySQL. If you are new to MySQL (or SQL), this book could be a tremendous help. There are only two bad things I can say about this book. One is that it is huge. If you don't read books like this cover-to-cover that may not be a problem. The second is that not all of its recipes seem to follow the cookbook style. Although much better than some of the cookbook-style books, it is not the best of the style. That being said, most of the book does do a good job of picking problems and showing you how to solve them in proper cookbook style.

Language Book Intros

In the past year, I've had to move my Java skills from recognize the language at twenty paces to professional Java programmer. In the process, I've been reading a number of books on the language. This has been my approach to learning every language I've ever worked with.

Almost all of the Java books have seemed to have a chapter or section in common that I haven't seen anywhere else. Does anyone know for certain if it is mandatory that every Java book has a bash the other languages chapter?

Maybe I've just had bad luck in picking books, but it does seem that almost every one that I have read has a chapter like this. They harp on obviously inherently insecure C, dangerous, convoluted C++, lowly scripting languages like Perl, and many other real or imagined flaws of other languages.

Now I do understand that programmers can become quite passionate about their favorite language. Ask almost any programmer about which language is best, or most powerful, and you can expect a lively discussion. But, I really don't recall this kind of diatribe in any other language books that I've read.

When I was first learning C++ (nine or ten years ago), some books devoted space to how C++ allowed for better abstractions and potentially more maintainable code than C. But, this information wasn't in every book and it was not an attack on C. It framed more as enhanced features for solving different kinds of problems.

When I was first learning Perl (over ten years ago), most of the books talked about ability to get work done and programmer efficiency. I do remember discussions of using Perl instead of combinations of AWK, SED, and shell scripting. But, I don't recall any attacks on other languages.

When I was learning C (over fifteen years ago), there was almost no mention of other languages in the books I read. There was a lot of talk of solving problems and a strong impression that you could solve any kind of program with C.

Even when I was learning Forth, there was a lot of talk in the books about the Forth way of solving problems, but other languages were not attacked.

The same hold true for every other computer language I have learned including FORTRAN, LISP, Basic, and x86 assembler. No books on any of these languages spent much time on the flaws of other languages, they focused on getting a job (or all jobs) done using this language.

One of my biggest gripes about this approach is the waste of space I end up paying for when I buy the book. If I'm buying a book on a particular programming language, I've already made the decision that I will be using the language (at least for the current project). At this point, I wish to learn syntax, idioms, tools, and approaches to solving problems with the language. I am not looking to be convinced that this language is the embodiment of the One, True Way to program.

I'm not looking for the One, True Way to program. I have many languages in my toolkit. I try to use the best one for each job.