Tag Archives: Computing

Accidental Empires: How the boys in Silicon Valley…

Introduction

This is neither a new book nor a new purchase for me, so why am I reviewing it? Bottom line: it’s a book that I’ve enjoyed a lot over the years and one that I feel the need to recommend to as many people as possible.

What’s in it?

The obvious format for a book on the personal computer industry would be chronological, but as he points out early on in the book, things just aren’t that simple. Instead he uses what, on paper, might look to be a random arrangment of anecdotes, jumping from Apple to Xerox Parc to Microsoft and IBM in the matter of a few pages. But that’s just the nature of the beast.

What’s good

Cringelys writing is easy and engaging to read. It would be very tempting to just sit down and read the entire book from beginning to end. It’s friendly, chatty and full of interesting little anecdotes about all the main characters, from Bill Gates to Steve Jobs.

He freely admits that he’s not been a true historian. He’s missed out some arguably important stuff, but it would take a long, dull book to get all that information in. The charm of Accidental Empires is the fact that it’s easy to read.

Conclusion

When I do reviews, I normally have a section on the bad stuff. I don’t have one here. That’s not because the book is flawless, but because it achieves perfectly what it set out to do.

If you’re at all interested in how the PC industry came to be, this is the book for you.

The facts

Author: Robert X. Cringely

Cost: ?6.99

ISBN: 0887308554

Minolta Dual Scan II

Introduction

Oddly, the main reason I’m writing this review is that I feel that the Minolta Dual Scan II has been harshly treated in the media. Most magazines seem to skip over this, the entry level, model and move on to the Scan Elite. On photo.net all are singing the praises of expensive Nikons and Canons, and complain about the lack of ICE on this model.

In a sense they are right, but everything is a compromise. Here’s why the Dual Scan II is a compromise that works for me.

What is the Dual Scan II?

Flat-bed scanners have plummeted in price over the last few years. Just seven years ago the only way most people could own a scanner was by getting one of those hand-held ones that you manually dragged across your document. They were quite neat, but getting a good scan was tricky. You needed a steady hand and lots of patience.

Fast forward to the present day and you can get good and cheap flat-beds for reasonable prices. You don’t need a steady hand, just the patience — much less than used to be the case too — and a computer capable of accepting large image files. Most of the pictures you can see on the site have come from a very cheap flat-bed, so why did I go and buy a new one?

I have only very occasionally scanned anything other than my own photos. At first glance, a flat-bed seems ideal for the task: simply place the print on the glass and scan away. What’s wrong with that?

Image quality. Each stage the image goes through loses information. By taking the picture rather than looking at it directly with your eyes, you lose information. Scanning it in loses more and printing it onto photographic paper does too. So scanning from a print loses more information than scanning directly from the slide or negative.

Many flat-beds have a transparency adaptor, but I’m not impressed. Most scanners operate at between 600 and 1200dpi, which is great (too much really) for prints, but slides and negatives are much smaller so you’ll need to enlarge them to print. And negatives come out a funny colour. Much better, I thought, to get a scanner dedicated to scanning the originals.

Hence the Scan Dual II. It scans at 2820dpi, which is nearly three times the resolution that I could expect on a reasonably prices flat-bed. It’s much better than a digital camera, too. That resolution is roughly equivalent to a ten mega-pixel digital. Don’t bother looking in the shops for one of those just yet.

It’s designed especially for the task I’m interested in, meaning that you can automate some of the process. I can do up to six negatives or four slides in one go. It’s smaller than any flat-bed and conveniently connects to my iBook’s USB port (many other scanners in this price range are SCSI, which is difficult with a laptop). And it comes with software for the Mac, albeit only MacOS 9, which is another major consideration!

I see what they mean

I spent so much time in image editing software trying to correct the colours of my scans that buying a new scanner was worth the effort. To my eyes, the colours produced by the Minolta are fantastic. It’s able to find details in the negatives and slides that you can’t see in the prints.

It’s kind of obvious in retrospect, but now I find that I’m still spending time in Photoshop (much less through). The problem now is dust. When the source is so small, even small motes of dust look huge. I guess this is why people are happy to pay another few hundred pounds getting a scanner with ICE software. I’ve still not found a 100% reliable way of cleaning my negatives yet, so please let me know if you know of one!

But, as I said, it’s all a compromise. I could have brought a pretty good flat-bed scanner for half the price of the Dual Scan, so I stretched myself getting it. Spending more for ICE just wasn’t an option.

The software that comes with the scanner seems to be quite powerful, but does stop some way short of real image editing software. They supply Adobe Photoshop LE for that purpose, which is getting on a bit. It’s a cut-down version of Photoshop 5. Since we’re now on version 7 it’s rather ancient, and, like the scanning software, is not OS X native.

Conclusion

Slide scanners are very expensive compared with flat-bed scanners. Not only are they tasked with scanning much smaller sources, but far less people buy them. This means that in the broader scanner market, the Dual Scan II is horrendously expensive.

But as far as slide scanners are concerned it’s great. There are cheaper scanners, but they work at much lower resolutions and are only able to work on a single exposure at a time. The more expensive models tend to have image enhancement software which, while useful, is not worth the extra for someone with my (lack of) artistic abilities.

The bottom line is that if you’re on a limited budget, or would rather spend more money on camera equipment rather than computer peripherals, then I consider the Dual Scan II to be a good buy. However, the ICE software on the next model up are quite possibly worth the money.

Note: Some time ago I emailed Minolta technical support to ask them about a MacOS X version of their software. I was surprised when they said that they were not going to produce one. I was, therefore, even more surprised when I recently found said scanner software in a native MacOS X flavour. Ed Hamrick’s Vuescan shareware application is still a viable option, especially if you want to scan negatives (on which it does a far better job out of the box) but I think I’ll be sticking with the “unavailable” Minolta software.

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

Dreadful Thoughts

Introduction

I have a terrible confession to make. I am not a spiritual man so, rather than seek penance through the church, I shall document my reasoning here on the web and you can make your own conclusions.

Please go easy on me.

My confession: I can see myself buying a Macintosh later this year.

To some, that may not sound like something to be ashamed of but it’s all a matter of perspective. By trade and education I’m an engineer or scientist; I have short hair, no piercings and virtually no artistic ability (I present the evidence of that here on this web site!). My computer of choice tends to have a barren, baroque user interface. Let’s be honest here, it’s Unix.

The Macintosh and Unix sit virtually on opposite ends of a spectrum. It’s usually called usability, but I think it’s even more precise than that. The Mac makes it easy for people to learn how to use it. Apple make things easy to use and they sacrifice power and flexibility in order to do that.

One of the best examples if this extreme position is the mouse. In Unix you tend to have three buttons. Windows originally had two but now seems to have spawned wheels and more buttons than a Space Shuttle. In each case although it only takes a short time to realise that the left button does most of the useful stuff, Apple decided that one button was less confusing. They’re right, of course. But it does limit your options as far as, say, short-cut menus are concerned.

Unix is the opposite. It has a huge learning curve, but an expert can quickly do just about anything. After spending a lot of time on that curve, I’d actually say that Unix was more usable than a Mac. I’m under no illusions, though, that it’s more difficult to learn.

I guess these extremes, to some extent, explain the success of Windows. Ignoring Apples mistakes and the fragmentation of the Unix market in the early nineties, we can see that Windows is easier to use than Unix but much less so than a Mac. It has the Start menu, Wizards, pop-up help and often hides information rather than bombard the user with difficult, unnecessary detail. On the other hand, it does have rough and ready multi-user facilities, solid TCP/IP networking and a command-line interface (for the brave). It fits the middle ground doing neither task especially well.

The battle ground

That’s how they stand right now, but six months from now things may be very different.

The Unix side probably isn’t going to change much. Linux, especially, will continue with its vast range of incremental upgrades. distributions will eventually come on-line with the new 2.4 kernel, and improvements will continue in both the KDE and GNOME environments.

In the same time-frame, the next desktop version of Windows, XP, will be unleashed on the world. The beta’s are currently doing the rounds and people seem generally impressed. The interface is easier, more consistent and more aesthetically pleasing, and its built on the Windowds 2000 core which has generally been well recieved.

Normally it might have been enough for me to upgrade from my old copy of Windows 95. But for two things: you can’t, you can only upgrade from Windows 98 or above; and MacOS X.

It would be an obvious choice to buy a new PC preloaded with Windows XP since I’ve had a small succession of similar machines over the last ten years, but I find the improvements in MacOS X to be so compelling than I’m considering moving to a completely new architecture. In a sound-bite those reasons are power and user-friendly in one.

MacOS X is based on a BSD Unix kernel (called Darwin and available under an Open Source licence) and has an enhanced Macintosh user interface grafted on top. This is truly the key. You have the complex internals available from a command-line when you need it and a state of the art GUI when you just need a word processor.

In conclusion

There is only one other operating system that supports such a neat combination of Unix and User Friendliness (the BeOS) and that has many problems: I have tried it on three machines and all have had some device that is unsupported, so this can hardly be a unique scenario; and the software support is worse. I may prefer not to use Microsoft Office, but I need to be able to exchange files with people that do.

No other operating system will have quite that level of flexibility. Microsoft won’t be adding more Unix like functionality to Windows and the open source community just can’t compete with the many years of experience that Apple have designing computers for people who don’t write code.

C

Introduction

Talking about C is not easy. Almost all professional programmers have used it at some point and many have a strong attachment to it. I don’t want to start by saying that it’s a poor language, alienating much of my audience, but I figure I’m going to end up doing that anyway so I may as well get it out of the way at the beginning.

Compared to many languages that have come since, and even some that came before, C just isn’t a very good language.

There, I’ve said it.

History

Perhaps more than almost any other language since, C has a rich and famous history. It’s almost impossible to discuss it without also talking a little about the history of Unix.

In 1969, Ken Thompson finally got hold of a PDP-7 and decided to write an operating system for it. (It happened more often than you’d think back then.) That operating system was Unix.

A few years later, Dennis Ritchie designed and built a language based on B (itself based on a language called BCPL) and, creatively, called it C. Unlike its immediate ancestors, C had types and a number of other useful bits and pieces.

C was so useful that Unix was quickly rewritten in it. These days that sounds obvious, but until that point operating systems had always been written in assembler or machine code. This is an important part of computer history.

Utility

C became popular largely because it filled a very useful niche. At one extreme you have all the ‘real’ languages. At the time, real computer scientists would have used Algol68. Structured and clever, Algol was a great language but you couldn’t do anything very low level with it.

At the other extreme there is assembler which people had to resort to if they wanted to do anything close to the hardware. Assembler is only one step removed from machine code which makes writing reliable, bug-free code very difficult, especially when you’re building something as large and complex as an operating system.

C fits in the middle. Described by some as a high-level assembler, it allows you to do low level coding, accessing particular memory addresses and the like, and use high-level constructs such as functions and types.

The following books and papers helped me learn to hate C.

Practical C Programming” by Steve Oualline.

Writing Solid Code” by Steve Maguire.

Code Complete” by Steve McConnell.

Hello world. How many nasty ways can you write “Hello World” in C?

Pointers

Key to C’s ability to mix high- and low-level constructs are pointers. Most ‘serious’ languages have some concept of a them. Some call them references, some call them links, but they all, basically, refer to something that identifies a chunk of memory. Most other languages only use them when you have to, but they are C. No pointers, no language.

You want an array? That’s really a pointer. Pass by reference? A pointer. Strings? Ah, they’re arrays! (Which are pointers.)

The advantages of using pointers for just about everything in the entire language are mainly one sided: it makes writing compilers easier. For the poor souls that actually end up using the language all is not so rosy. As Steve McConnell puts it, “pointers are one of the most error-prone areas of modern programming” (Code Complete, section 11.9).

Some of the side-effects of using pointers are not immediately apparent, either. In most languages, arrays have bound-checking (the ability for the language to raise an error if you try to access an element that doesn’t exist). But C doesn’t really have arrays, it has pointers and a little syntactic sugar that makes it look like it has arrays. Pointers don’t know how much memory is being pointed to so you don’t get bound-checking. If you’re lucky your program causes a segmentation fault, if not you might corrupt other data or, on some operating systems, your program.

It takes all types

Another one of C’s biggest problem is it’s typing. As most people will already know, C allows you to put numbers into character variables, integers into floating points and any number of other nasty combinations. To C they’re all valid, but what they do are not always well defined or consistent. Even the same compiler sometimes does different things depending on the level of optimisation in use, the phase of the moon, etc.

The odd thing is that a weakly typed language doesn’t allow you to do more than one with strong types, it merely allows you to do the wrong thing more easily. For a language used for large-scale software engineering projects the risk of poor code is just too great and weak typing should be outlawed.

I’m sure that people are going to mention the myriad of warnings that modern compilers are able to produce, or that ‘lint’ has been available for nearly as long as the language has been. My counter-argument: I don’t see why you should have to add extra tools or read through pages of warnings in order to correct deficiencies in the source language!

The good bits

If C was truly as appalling as I’ve made out so far, no-one would actually be using it. The main ‘win’ for C, as far as I can see, is that it is small, well defined and widely available.

All three merits are in many ways different sides of the same coin (if you can imagine a three sided coin). To make the language well defined, it helps if it’s small. If lots of people are to use it, it needs to be simple enough that they aren’t put off (Ada anyone? Thought not.). Small and well-defined make it easier to write compilers too, meaning that it’s available on everything from the lowliest PC right up to mainframes.

The theory also goes that your programs should recompile on this range of machines too, but that’s not as true as we’d all like to think. If it was true, we wouldn’t need Java or hundreds of ‘#ifdefs’ throughout. My code tends not to be that low-level, but I wouldn’t like to make any promises about its portability. However, that doesn’t make C’s wide availability useless. Even if your program isn’t cross-platform, the skills required are. A C programmer can quickly write code for just about any machine.

Summary

I’ve probably written more lines of C code than just about any other language, so when I say that I don’t like it I hope that you can see that I’m not being narrow-minded or prejudiced.

As I’ve mentioned above there are some things that I like about C, it’s just that there is so much to hate about it and, even at the time it was written, there wasn’t an excuse for it!

The languages main features are its weak typing and over-use of pointers, both of which allow developers to make truly horrendous coding errors with ease.

If those were C’s only problems I might be able to forgive it, but they aren’t. C has more ways for both experienced and novice programmers alike to hang themselves than any other language I can think of (with the possible exception of Intercal). Even if it didn’t have the ‘=’ and ‘==’ operators to confuse, there’s still the wonderful ‘?:’ and a whole host of spectacularly error prone API calls (does all your code check the value that ‘malloc’ returns?)

No, C, as a language, is a dinosaur. It deserves to whither and die. If you write anything other than an operating system kernel and use C, switch to another language. You’ll be far more productive when you start battling the problem rather than the language.

Output

Introduction

PL/SQL is good for many things. It has a structured, Ada-like syntax and can have SQL statements seamlessly embedded in it. Although not compiled right down to machine code, it’s even fairly quick.

But one thing that most people initially have difficulty doing is displaying information on the screen. The first thing I did was to enter what I wanted into a temporary table and use SQL*Plus to select from it. This works well for reports at the like, but it doesn’t work at all if you want to display something independently of a transaction or halfway through a function.

I was frustrated that there wasn’t a better way of feeding back information to end users. I was wrong to be frustrated: there is a better way.

Hello world!

The best example I can think of doing is the world famous “Hello, World!” program, so here goes:

CREATE OR REPLACE PROCEDURE hello_world AS
BEGIN
     DBMS_OUTPUT.PUT_LINE ('Hello, world!');
END hello_world;
/

In SQL*Plus you can run that procedure by typing “exec hello_world” and pressing return.

You may be surprised to see that it says “PL/SQL procedure successfully completed.” and nothing else; there’s no “hello world” text. Surely it’s lying, it hasn’t successfully executed anything, has it?!

As with most things Oracle, things are not quite as simple as they first appear. In this case you need to tell SQL*Plus that you’re going to use the DBMS_OUTPUT package. To do that, you need the following command:

set serveroutput on

You might want to put this in your “login.sql” file so that it gets executed every time you log in. You can also add the “size” parameter to the end to indicate how much output you’ll be producing. The most you’re allowed is around 1Mb so I usually type “set serveroutput on size 1000000”.

If you try executing the procedure now, you’ll find that it works correctly.

A longer example

For our second and final example, we’ll use one of the tables that Oracle installs by default. It’s called EMP and should be in the SCOTT schema (password TIGER). The important fact here is that there are a number of different columns types, NUMBER’s, VARCHAR2’s and DATE’s.

On to the example:

CREATE OR REPLACE PROCEDURE example2 AS
     CURSOR emp_cur IS
         SELECT e.empno, e.ename, e.sal, e.hiredate
         FROM   emp e
         WHERE  e.sal > 2500;
    BEGIN
     FOR current_employee IN emp_cur LOOP
         DBMS_OUTPUT.PUT_LINE ('-------------------');     -- string literal
         DBMS_OUTPUT.PUT_LINE (current_employee.empno);    -- number(4)
         DBMS_OUTPUT.PUT_LINE (current_employee.ename);    -- varchar2(10)
         DBMS_OUTPUT.PUT_LINE (current_employee.sal);      -- number(7,2)
         DBMS_OUTPUT.PUT_LINE (current_employee.hiredate); -- date
         DBMS_OUTPUT.PUT_LINE ('Year: ' ||
                               TO_CHAR(current_employee.hiredate, 'YYYY'));
     END LOOP;
 END;
 /

This code should be pretty much self-explanatory. We first start a loop over a table. Inside the loop we output the content of it. The first PUT_LINE statement shows that you can output a string literal (we know this as ‘Hello world’ is one too). The second shows that you can output numbers without first converting them to a string — the function is overloaded and will accept most standard types.

Following that theme, the third, fourth and fifth lines output a string, a different number and a date, in all cases using the default format string. The last PUT_LINE statement shows that you can output expressions, but note that it all needs to be of the same type (so in this case I convert a date to a string so I can concatenate it to another string).

On my machine, the output is as follows:

SQL> set serveroutput on
SQL> exec example2
 -------------------
 7566
JONES
2975
02-APR-81
Year: 1981
-------------------
7698
 BLAKE
2850
01-MAY-81
 Year: 1981
-------------------
7788
SCOTT
3000
19-APR-87
 Year: 1987
-------------------
7839
KING 5000
17-NOV-81
Year: 1981
-------------------
7902
 FORD
3000
03-DEC-81
Year: 1981
PL/SQL procedure successfully completed.
SQL>

Conclusion

As we’ve come to expect from Oracle over the years, simply outputting a little text to the screen isn’t quite as easy as you might wish for.

And it’s not without it’s problems. If you want to send more than a megabyte to the screen, you’re still going to have difficulty and all the playing around with “set serveroutput” is just plain tedious.

However, the important point is that you can do it and, programatically, it’s (basically) just a single command.

If you want more information on this kind of thing, have a look in chapter 6 of Oracle Builtin Packages, a whole book dedicated to this kind of thing.