Tag Archives: Computing

Opinion

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

Opinion

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

Opinion

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.

Opinion

What About Free Documentation?

Introduction

There’s a lot of free or open source software on the net, and much been written about both that software and the process that drives it. Eric Raymond, of course, is currently the main anthropologist although Steven Levy beat him to it and there are many others.

There is also a significant amount of free documentation. One only needs to take a look at the GNU web site (their definition of a free operating system includes free documentation) or the Linux Documentation Project to see that. However, there doesn’t seem to have been a “Cathedral and the Bazaar” for free documentation, or even anything similar.

That’s kind of what I want to do here, but I’m not going to go into as much detail. Instead, I’m going to write about my own experience writing free documentation (my Oracle 8i Installation Howto), the trial and tribulations, the ups and downs, the good times and the bad… You get the idea.

Starting off

I guess the first thing to note is that I didn’t write the HOWTO to ‘scratch an itch’ — I already knew how to install Oracle! Instead, I noticed that many people were having difficulties and that I was spending quite some time replying to the same questions on newsgroups and Oracle Technet. You could say that I wrote the document in order to be just as helpful but without being quite so intensive on my time! (So my itch could have been to save time.)

Another motivator was ‘to put something back into the community.’ Sounds a little pretentious, but it’s true. I’ve been using Linux since 1994 and, although an able developer, have never contributed any code to any free software. This was my chance! I suppose I naively thought that writing English would also take less time than C. As we’ll see later, that didn’t turn out to be the case.

I think that this is an important difference between free software and free documentation. No-one will ever write free documentation to “scratch an itch” (as Eric Raymond so eloquently put it). This takes away, quite possibly, the greatest incentive to create something and may explain why, generally speaking, text is very much a second class citizen to code.

Release early; release often

The first decision I really needed to make was tools to use. My first thought was to add a few new pages to the web site that you’re currently reading. And then I got lazy. I decided to base my new work on the then current Oracle HOWTO, which meant that I had to get to grips with SGML and the SGML-Tools programs. At this point I wasn’t thinking in terms of getting it into the Linux Documentation Project, I just wanted to get a head-start. Once I’d actually started, it didn’t take me long to figure out that the structure of the old document didn’t match what I needed and, more or less, started again from scratch. I did, however, keep the same tools.

Having just read the Cathedral and the Bazaar, I consciously decided to issue my document before it was complete. I quickly wrote the introduction, prerequisites and installation sections and added a number of place-holders for the remaining sections. I then announced it in a message to Oracle Technet and a couple of newgroups.

Very quickly I got some excellent feedback. People were asking for clarifications and new questions, and others were pointing out factual errors. As with software, I quickly added these fixes and thanked the contributers both by email and in the document itself.

I was very pleased that this approach worked. Normally I would have ‘finished’ my work before making any issue, but by releasing early I was able to help more people early on and elicit — I’m guessing here — more useful comments. (I figure that’s true because I think I’d be less inclined to contribute to a finished document than a work-in-progress.)

Maintenance

Around version 1.5, a couple of weeks after my initial release, it was more-or-less complete. All sections were filled in and I managed to complete a successful installation just by following the steps I’d written about.

The first issue was the people didn’t follow my advice — how dare they! Oracle is a big and complicated application and, even on Solaris, you just don’t change things unless you have to and you always use a ‘certified’ operating system. This is an alien mind-set to many Linux developers, who tend to thing “newer is better” and is not helped by all the weird and wonderful devices that you can connect to an Intel-based PC.

The first questions I received that deliberately weren’t answered in the HOWTO were problems with different distributions. People were trying to get Oracle running on just about anything with a Linux kernel!

I didn’t fancy wiping my PC clean and attempting the install with as many different distributions as I could find, I just didn’t have the time. Fortunately, the same community on the Internet that helped me complete my first version added to my knowledge base.

I started to add more and more detail to the HOWTO. If you’re using RH6 do this, with Debian do that… It seriously affected the “flow” of the document for everyone. Given my Oracle (conservative) background, this is just not a problem I originally considered.

When Oracle released 8.1.6 I made the decision that the HOWTO was for RH6 and Oracle 8i R1. It would make the occasional nod to later releases of both the database and the distribution, but fundamentally the focus would be on one version of Oracle and one version of Linux.

As a kind of half-way-house, I started to add extra pages to my website detailing some of the idiosyncrasies of different Linux distributions or newer versions of Oracle. I’m still not completely happy with this approach but I’ve not heard of a better solution yet.

Feedback

Having “completed” my document, what keeps me editing? If I’m writing software, my motivation is adding cool new features. Or maybe adding new stuff for other people and waiting for their praise?

As I mentioned earlier, things are very different for documentation writers.

I’ve got an awful lot of mail about Oracle and Linux since late 1999 when I first published the HOWTO. The email I get seems to have gone through a number of phases. When I first issued the document, I got an almost fifty-fifty split between “thank yous” and suggestions for improvement. Almost all was positive, constructive and friendly.

Without it I would almost certainly have stopped writing. At this point I suppose my motivation was to increase the ratio of thanks to suggestions. I turned a stream of emails into a challenge!

As the HOWTO started to get into wide circulation, the number of helpful suggestions started to drop and the number of questions started to rise dramatically. Some I saw as suggestions as I didn’t cover those details, but most were just from people who clearly couldn’t be bothered to read any further than the front page and my email address.

I can’t count the number of messages I’ve received saying “it didn’t work, what should I do?” (in as many words). How should I reply to that without being rude?! I’ve also received emails from people giving me their “root” password and other confidential details.

The next stage was when Oracle released a newer version and RedHat decided to go with a new version of GLIBC for version 7 of their distribution.

By this point, my motivation was mainly trying to reduce the number of messages I was receiving. Sure, I felt like being rude but I rarely was. I tried to answer all the most common questions in the document, but this point was definitely the low point. Although the updates were helpful, I was doing them for the “wrong” reasons, and the number of messages saying “thanks” had dropped to virtually zero.

More recently I’m only getting the occasional question. It’s difficult to know whether that’s because my HOWTO covers just about everything it needs to or because I’m just not promoting it as much as I used to or because the cutting edge in Oracle is now with 9i. Or maybe I was rude and people are too scared to talk to me..?

In conclusion…

If my original intention was to save time, it failed miserably. I’ve spend even more time replying to emails and maintaining the document than I would have done occasionally adding comments to discussion groups.

Towards the end of this piece I’m sounding very negative, but that’s a bad way to finish as generally speaking it has been very enjoyable. Getting a Linux distribution with your work on is quite a buzz and it’s always nice to get a friendly message or offers of free CDs and books from strangers.

Opinion

Engineer or Hacker?

Eric Raymond would have us believe that everyone that develops software for fun is a hacker. I know that historically this has always been the case, but that doesn’t necessarily make it the right thing. All good, and bad, things come to an end.

I doubt that it will happen any time soon, but I think that ‘hacker’ is a term that should whither and die.

The first problem, and this is the obvious one, is the public perception of it. Yes we all know that hackers write code while crackers break into computer systems, but how many people ‘outside’ know that? How many professional software developers, i.e., those who do it just for a living rather than for fun, know that?

If even professionals don’t know the difference, how can the rest of the population have a chance?

Of course there’s always the fanatical wing, those that claim that we should hit the problem face-on. We should call ourselves hackers because we know that we’re right and that everyone else is wrong.

It’s actually a very politically correct way of doing things, but I remain unconvinced that it works. Richard Stallman continues to insist on the term ‘free software,’ even though most people find it more confusing than ‘Open Source.’ None of this is about changing ideals or opinions, it’s just about the correct marketing of the term.

The second problem I identified is much more subtle. What does the term ‘hacker’ mean? My dictionary defines it as follows:

hack‘ vt cut, chop (at) violently;

It goes on, but that’s the important part. My objection comes from the lack of precision that the term implies. You get a program and violently cut and chop it around until, by chance, you get something out at the end that seems to work okay.

I hope you don’t develop software like that, I certainly don’t. Any half-decent developer follows a process, no matter how ill-documented. When you debug software you don’t just dive in adding ‘print’ statements all over the place, guessing where it goes wrong. Instead you make a hypothesis and test, modifying your original until you get a good idea what’s wrong, then you start with the ‘print’ commands or your debugger.

Does that sound uncontrolled and violent?

All that planning and precision, all the experience that it takes to be able to make a reasonable and accurate hypothesis sounds more like engineering of some kind.

And that it why I call myself a Software Engineer rather than a hacker, even when I write code in my spare time.

Opinion

Minolta Dual Scan II

11 Comments

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.