Tag Archives: books

Practical C Programming

Introduction

It sounded like just the kind of book that I was looking for. I wanted a refresher on C since I’d not used it for a while, and some pointers on ‘advanced techniques.’ The blurb on the back looked about right and the fact that O’Reilly published it clinched the sale.

“Practical C Programming” not only plans to teach you C, but also about style, debugging and the software life-cycle.

Content

The book is split into three sections: Basics, Simple Programming and Advanced Programming.

‘Basics’ introduces the language, leaving out much of the fluff and complex bits, but including much on style and ‘process’ — designing, building and maintaining your program. This part of the tutorial is well structured, only introducing new features of the language as and when they are necessary. It does not teach you how to program, rather how to write C. Since you must be able to program before you start the book, I consider the pace to be much too slow. If you already know how to program, why should you have to wait until chapter six before introducing the if statement?

‘Simple Programming’ finishes off what the last section started. It adds most of the more complex bits such as scope, bitwise operators, pointers, floating-point numbers and the C Preprocessor. Of course, the boundary between basic and simple is not well defined, but I would consider the for statement to be basic. This section also includes information on optimising programs which you might have thought would fall under the ‘Advanced Programming’ section.

The final section is much more terse and reference-like than the first two sections. It includes topics such as the difference between ANSI and Kernigan and Ritchie C, more on pointers, portability and some of the more dodgy parts of C such as the 😕 operator and goto statement. It also includes a section on modular programming (again, I would consider this to be in the wrong section) and ‘Programming Adages.’ For the experienced programmer, it is probably this last chapter that is the most useful. Reminders such as avoid side-effects and never put an assignment inside a conditional seem to go against the grain of conventional C wisdom, but are, indeed, correct and very valuable.

Conclusion

‘Practical C Programming’ is not a bad book by any means. Scattered through its 400-odd pages are dozens of useful tips and heuristics, many of which I’ve not seen in print before. It also manages to clarify some oddities, and the example programs are mostly well thought-out and clear.

The C tutorial is not in enough detail to help a true novice and is too chatty and basic for some people, like myself, who just want the facts. The annoying part is that there is a lot of information in there that I didn’t already know, but I almost didn’t have the patience to read it.

It’s also unusual to find a chapter on software engineering in a C book. Oualline has a nice discussion of design, source control and configuration management but it does leave you wondering why it is there. Sure, it’s an important topic, but there are huge books dedicated to this subject. He can not (and does not) even begin to scratch the surface.

What the book lacks is a clear focus. Is the book for a novice programmer? Is it for someone that doesn’t know C? Someone that does know C? Is it a reference? A software engineering guide? The real answer is that it tries to do it all, but only partially succeeds. A nice try but not a must buy.

The facts

Author: Steve Oualline

Cost: Approximately ?24.50 or US$32.95

ISBN: 1-56592-306-5

Buy this book from Amazon.com of from Amazon.co.uk.

Oracle PL/SQL Programming

Introduction

The first point to note is that this book is published by O’Reilly. The second point would be that Steven Feuerstein is generally regarded to be one of the worlds leading PL/SQL experts.

Those two point, on their own, were enough to clinch the purchase just over eighteen months ago.

Content

The book is, to say the least, comprehensive. When I first started to use PL/SQL I would never have guessed that there was enough there to write a thousand page book, but there is.

It’s split into seven sections and twenty-six chapters, making it a good reference as well as useful to learn from. Section one, ‘Programming in PL/SQL’ talks about the history, block structure and style. I’m not entirely convinced that ‘programming style’ belongs in a book such as this, but it’s well written, useful and less intrusive than the similar treatment in “Practical C.”

Section two moves onto the ‘meat’ of the language and takes up over two-hundred pages in its own right — longer than the whole of some other texts! Feuerstein covers all this in detail and with great skill, mentioning not only how the language works but also, where appropriate, where it doesn’t work. This kind of honesty seems rare, especially in Oracle Press books!

‘Built-in Functions’ does exactly what you’d expect, and includes a thorough discussion on handling dates, a common area of confusion (I was pleased to find that it’s not just me…).

Parts four and five are, perhaps, the most clumsy sections. The first talks of ‘Modular Code,’ which I don’t see as being so advanced that it requires its own section. And part five discusses the ‘New PL/SQL8 Features’ which, again, don’t necessarily deserve a section on their own. I suppose it made writing the second edition easier…

The last section before the appendices is called ‘Making PL/SQL Programs Work.’ For those not familiar with server-side PL/SQL, let me point out that this isn’t as silly as it sounds. PL/SQL, until recently, had no debugging facilities to speak of. You can’t set break-points or single-step and even outputting trace statements to the screen is not trivial.

However, although the stuff that Feuerstein writes is interesting and might be useful to some, it’s not all it might be. For example, in the section on tracing PL/SQL programs (chapter 26) he talks about Oracle tracing which, if you’ve ever seen, you’ll realise how useless it is much of the time. (If you’ve not seen it before, be warned that you’ll get thousands of lines of very low-level junk for even a simple program.)

Why did he not talk about a tracing library, say, that logs trace messages into the database with a pipe? I ended up writing one myself, based on the information in the book but I’d preferred not to have!

I thought you said you liked it?

If you said that the last section was very negative I wouldn’t be able to disagree with you. However, this is a book that I’ve been using for over a year, not something I got as a review copy and skimmed. I’m still using the book on a daily basis so it must have some merit. I would never have found many of the problems if the book hadn’t been an important and useful reference for all this time.

O’Reilly know how to publish a good technical book. They focus on telling you what you need to know and how it does, should or, indeed, does not work. Feuerstein’s Oracle PL/SQL Programming is one of the better O’Reilly books, so you should be able to guess how highly I rate it.

I first got my copy over a year ago and I’ve spent most of that time on Oracle projects. I have kept this book by my side at all times and only on a few occasions has it not been able to answer my questions. It’s now so well used and grubby that I may be forced to buy a new copy.

The facts

Author: Steven Feuerstein with Bill Pribyl

Cost: $46.95

ISBN: 1-56592-335-9

Buy this book from Amazon.com or from Amazon.co.uk.

Software Project Survival Guide

Introduction

For many people here, writing software is, if not a job, then a hobby. Our enthusiasm is a double-edged sword. Our technical knowledge is usually much greater than people who just develop software for a living. This sounds like a big advantage, but it’s not as large as you would have thought.

Let’s have a look in ‘Software Project Survival Guide’ (SPSG) to see what Steve McConnell, famed author of ‘Code Complete’ and ‘Rapid Development,’ has to say on the subject.

The most relevant bit I can find is in chapter two. It’s a project survival test. Out of thirty-three questions, only one (28: “Does the project team have all the technical expertise needed to complete the project?”) is directly related to our ability to effectively code.

That can’t be right, can it?

Content

While you’re still reeling over the consequences of that last paragraph, I’ll slip in some of the dull things that the book has to cover and finish with some of the more glamorous stuff at the end when you’re brain is back in gear.

Some of the most important stuff is ‘management.’ Whether it’s planning, quality assurance, tracking what’s been developed so far or checking on the number of defects, it’s not the ‘techies’ that are the most important.

At first this comes as a shock, but the more you think about it, the more it makes sense. Unless you know what’s going wrong, you can’t fix it. Unless the complete design is documented a team can’t effectively write the software quickly.

Think about Linux kernel development. It obviously work well, but it’s not terribly optimal. The same bug might get fixed several times and there’s not a huge amount of up to date documentation so people have to dive in at the code. For free software this works fine — since the time is usually free, but if you have deadlines and are under contract to deliver a working product on time you’re going to lose a lot of money.

Good bits

McConnell takes the three hundred pages to explain these past two paragraphs in detail. It sounds very dull, but he has a clear, friendly style that makes it, if not entertaining, then not as dull as it might have been.

He splits the project into stages, explains in broad terms what they are and documents each one in more detail in the later chapters. It’s all very clear and logical leaving you in no doubt what stage you’re currently at and what you should be doing for the successful execution of it.

Bad bits

‘Code Complete’ is a book that just about everyone that writes computer programs should read. ‘Software Project Survival Guide’ does not fall into the same category. The book should be read by “anyone who has a stake in a software project’s outcome” according to the preface, but that is only accurate once you define the type of project it covers.

To cut a long story short, if you write software professionally you should read it. It’s probably more use to managers and team leaders, but you can be a better developer if you know the kind of things that need to be done. Besides, almost everyone will be in charge of people at one point and will need a broader picture than merely what the other modules do. (Well where I work that’s true, anyway.)

It covers projects that have a customer whether that’s an internal customer, an external client or people that buy shrink-wrapped software. What it doesn’t cover are software projects like Linux, massive sprawling projects developed because someone is interested in doing it. This is not unreasonable. Half the challenge in a ‘normal’ project is tracking whether you’re running to schedule. If you don’t have a schedule and cost target it doesn’t matter. However, maybe we could take a few hints from the book to ‘streamline’ the process.

Overall

Steve McConnell has done it again. I don’t think that it will go down as a classic like ‘Code Complete,’ but SPSG is an indispensable book for any developer that has any interest in the process and not just lines of code.

The facts

Author: Steve McConnell

Cost: ?22.49

ISBN: 1-57231-621-7

Buy this book from Amazon.com of from Amazon.co.uk.

Open Sources

Introduction

This is a very strange book by almost any criteria. Firstly, much of the content is available on the web in one form or another. This includes an appendix which is literally a Usenet discussion printed. Secondly, most of the writers are techies first and writers second. You don’t get that kind of admission from most writers, even when it’s obviously true.

Content

There are fifteen essays by eighteen writers. I’m not going to go through all of them, but I shall note some of the highlights.

The style prize, without doubt, goes to Larry Wall for ‘Diligence, Patience, and Humility.’ It’s one of the longer essays, has dozens of useless-looking diagrams and for much of the time seems to go nowhere. You keep reading, though. You may not see where it’s going, but you’re intrigued. And it’s worth it — despite initial appearances, it does go somewhere!

As a Linux-biased web site, I couldn’t miss out Linus Torvalds piece, ‘The Linux Edge.’ His simple message — Linux has survived by having a good design — is thoroughly investigated, but the best bit is that he criticises just about everyone else in the industry, often without much justification, and still comes out the other end smelling of roses! I’m not sure how he did it, but I know I’d hate Bill Gates more if he said pretty much the same things.

As always he comes across as very modest, and attributes many of the good ideas to other people.

I liked Marshall Kirk McKusick’s potted history of Unix too. I think I’ve seen much of that before, but not in one place.

Since he practically started the whole thing, I need to mention Richard Stallmans ‘The GNU Operating System and the Free Software Movement.’ It’s an interesting piece in that he contradicts some of what the other authors in the book have to say (as has been well documented, he dislikes that phrase ‘Open Source’ and demands that people call it ‘free’ software). It’s clear that he knows exactly what he wants and where he wants to go, but it’s equally clear that he’s going to put a lot of businesses off free software if he keeps going the way he is. RMS, I respect what you’re saying, but calm down!

The final mention goes to the two Eric Raymond essays. Raymond has been at the centre of the Open Source movement since the Cathedral and the Bazaar,’ and fully deserves the opportunity to write two pieces in Open Sources. The first piece ‘A Brief History of Hackerdom,’ describes the key points and people that gave rise to our current position. The second, ‘The Revenge of the Hackers,’ looks to the future.

Like much Raymond stuff, some is ‘personal’ and has a number of anecdotes about himself. It seems that many people hate this, but I feel that where it doesn’t get in the way of the message and while it’s still interesting and well written, it’s fine. The two essays are, indeed, fine.

Overall

I can’t really criticise this book. All the people in it are more influential than myself, better developers than myself, better writers than myself or, more commonly, all of the above. So while I like some of the writer more than others, and while I actually disagree with some of the assertions made, it is, at least, well written and thought provoking.

As a book intended to document the new-found popularity of the Open Source model, the book is a classic and a must-buy.

The facts

Author: Edited by Chris DiBona, Sam Ockman and Mark Stone

Cost: US$24.95

ISBN: 1-56592-582-3

Buy this book from Amazon.com or from Amazon.co.uk.

Oracle Builtin Packages

Introduction
Steven Feuerstein’s ‘Oracle PL/SQL Programming‘ book has, over the last couple of years, become my bible on the subject of writing sizable Oracle PL/SQL programs. As I said in my review, it’s useful because it covers just about everything, including the things that don’t work.

So if that book covers just about everything, why would anyone want to buy ‘Oracle Builtin Packages’?

Content

In fact, as the first chapter of the book explains, this entire book was origianlly chapter 15 of ‘PL/SQL Programming’ but Oracle complicated things by adding more to the PL/SQL programming language (all the pseudo-object oriented stuff in version 8 ) and many more new or enhanced packages. The result: either a single two thousand page monster, or two more reasonably sized tomes.

But like the first book, this is still a bit of a monster in its own right. It stands at 931 pages and there’s very little padding; if only all technical books had such a high signal-to-noise ratio!

It seems rather pointless to go into detail on the content of all the different sections…

The two chapters that I’ve used the most are those on DBMS_FILE, which allows you to manipulate operating system files, and DBMS_SQL. Just about everything I know about these modules I learned from this book. When I was originally writing the code, ‘Oracle Builtin Packages’ was by my side, open at the relevant page. When colleagues mistakenly thought I knew what I was talking about, this book was open beneath my desk giving me superiour bluffing ability.

The main critisism that I can think of is that some of the material is getting rather out of date. The DBMS_SQL package is no longer as necesary as it used to be — Oracle 8i introduced some new syntax to the PL/SQL language that largely replaces it.

Conclusion

I’ll be brutal: in marked contrast to Feuerstein’s first book, if you regularly write PL/SQL code you can get by without reading this book.

But you will be more productive if you get it. You won’t be spending days writing code to do things that Oracle have kindly supplied a routine to do and you won’t give up on PL/SQL and write a program in Pro*C because you don’t realise, for example, that you can manipulate files.

No, this book is less vital than ‘Oracle PL/SQL Programming’ but it is still a thorough, well organised and useful book. It’ll quickly pay for itself many times over, and that’s a very high recommendation.

The facts

Author: Steven Feuerstein, Charles Dye, John Beresniewicz

Cost: US$46.95

ISBN: 1-56592-375-8

Extreme Programming Explained

Introduction

Naturally the key selling point of Extreme Programming — reduced risk and increased fun — appeal to me. I’ve worked on many projects that were either risky, no fun or both and any way to improve that would be a good idea.

However, most of the successful projects were run using fairly heavy-weight methodologies, CMM or ISO accredited, for example. Extreme Programming promises to deliver the benefits while still being simple. I was sceptical. This sounds a little too close to one of Fred Brookes Silver Bullets.

How does it work?

Extreme Programming sounds too simple to ever work. None of its components are new or especially controversial, some are even very common throughout the industry. What’s new is their application together. The key is that the strengths of one part paper over the weaknesses of others.

I won’t detail all the bits — that’s what the book is for — but there are a couple of things I want to talk about.

The one thing that came through in all other reviews of the book was the pair programming aspect. The idea is that whenever writing code, there are always two people sat at the computer. This sounds very wasteful of resources but is based on some very sound theories: reviewing code is good and sharing knowledge around the team reduces the dependency on any one person. XP takes it to the extreme (hence the name) by having, in effect, every line of code being reviewed by two people all the time.

I can certainly see the benefits, but I can imagine a client being very suspicious when you suddenly have two people appearing to do a job you previously only had one doing. He also proposes using a utilisation metric which documents that people are actually not doing genuinely productive work all the time.

Anyone that writes software will immediately recognise that a lot of time is spent helping colleagues, in design or review meetings and any number of other things that are not directly and visibly related to increasing the functionality of a program. Making it more visible sounds like a much harder “sell” than is suggested in the book.

Is it easy to understand?

Brock is clearly very enthusiastic about his methodology and this shows in his prose, which is clear, friendly and concise. It’s sensibly organised and it usually answers questions you’re thinking of in just the right place.

However, it only does all that if you remember what the book is trying to explain. It’s trying to explain Extreme Programming not how to implement it effectively. I had a little difficulty seeing how you could automate tests in some environments. We tried and failed with Oracle Forms (or whatever it’s called this week) for example. I don’t disagree with the principle, but there are some definite technical barriers that are not even acknowledged.

I’m not sure that the distinction between describing what XP is and how to implement it is a good one. It sounds like an excuse to sell two books when only one would suffice. Why would anyone be interested in learning the theory but not the practice of a simple methodology?

Disadvantages

Beck does not claim that Extreme Programming works in all circumstances. There’s an entire (albeit short) chapter on it, which is quite refreshing. Most people would claim that their baby was ideal in all circumstances!

I only thought of a couple of other problems that are not addressed, although neither are necessarily any more of a problem with XP than with other methodologies. (However, they are areas that are claimed to be addressed.)

Documentation is never kept up to date anyway, and in XP there is a much greater chance of at least one person knowing how it works. Couple that with a full set of tests, the ‘business’ person being on the team right from the start and, well, what’s my problem?

The problem is identified in Death March. Who are the stake holders on the project? Is it your team-member (the end user)? Is it their manager, who might want a bunch of reports? Is it the CTO who doesn’t actually care what the system does and just wants a success of some kind in order to get promoted?! The book and the Extreme Programming approach treat the problem of requirements as something that is eventually known and is fix-able given close enough interaction with the users. I wish that were true.

Beck might suggest that this ‘unknown’ is just another form of change than can be managed in the normal manner, but my guess would be that the magnitude of changes required by people that don’t have day-to-today access to the team would be too big and would break the process.)

Or perhaps this is just a size issue. With a system, with a small number of well-defined users there’s no reason it couldn’t work.

Conclusion

I think my initial and immediate dislike of XP stemmed from the fact that most of the projects I’ve ever worked on have fallen into the “won’t work” camp. Now that I understand its background I can appreciate it much more.

And it’s only fair to note that this appreciation comes solely from the book. It’s worth reading even if you don’t plan on implementing Extreme Programming.

The facts

Author: Kent Beck

Cost: $29.95

ISBN: 0-201-61641-6