Archives for February 2009

The Joy of Mathematics

2009/02/09 By Rob 8 Comments

The Wall Street Journal recently had an article on the best and worst jobs in the U.S., based on a mix of criteria including pay, stress level, work environment and employment outlook.

Any guesses for the best jobs?

The top 5 are:

Mathematician
Actuary
Statistician
Biologist
Software Engineer

The top three places reminds me of a line in an old episode of The Simpson’s where a space shuttle crew is described as consisting of “a statistician, a mathematician, and another kind of statistician.”

Interestingly, “Philosopher” came in very high on the list. I would have expected it to have a low stress level, no demands from the boss, “I need some epistemology ASAP and a first draft of aesthetics on my desk by the end of the week, or else the Miller account will take their business to the non-Western philosophy firm!” But I didn’t know the pay was good.

The worst jobs, of the 200 surveyed? Lumberjack, followed by Dairy farmer and Taxi Driver. I don’t know any lumberjacks, but my uncle is a dairy farmer in Wisconsin, and he seems happy and peaceful in his work.

Drowning in Data

2009/02/09 By Rob 12 Comments

Bob Congdon writes on something we’re all living through — the decline “hard media” (paper, LP’s, even CD’s, etc.) and the prevalence of digital media.

From a green perspective, getting rid of all of this hard media is a good thing. Why print out documents when you can read them on your computer? Why should publishers print hundreds of thousands of copies of a newspaper each day to be read once and tossed out? The same with weekly and monthly magazines. Why produce millions of CDs that just end up in landfills?

I agree that the trend is here to stay, but I, personally, am scared to death. I think we’re headed for disaster. The problem is that few of us have an adequate back up regime for all of this data. When disaster hits, and a single disk drive holds all of our downloaded commercial software, our e-books, our electronic documents, our financial data, our music, our photographs, etc., then we’ve lost everything. So what used to require a devastating house fire now will hit unprepared users every time their hard drive fails. We tend to have all our eggs in one basket now and a single failure has now a greater impact.

Sure, we could back everything up. I used to do that. Floppies, ZIP drives, tapes, CD-ROM, DVD-ROM, external drives, online backup services, I’ve done them all over the years. The problem is that my data needs keep on increases. Back in 1990 my entire data needs, a few dozen WordPerfect files, could fit on a single floppy disk. Today, a single photograph, in RAW format, can take 10x that amount of storage. Add to this music files (at high bit rates), video files (now in Hi Definition, of course), and so on, and I’m nearing a terabyte of data at home. Forget about backing up to 125 double-sided DVD-R’s. Forget about online backups — the latency would make a backup take a month. We’re not going to change the speed of light so that option will never scale. All I can really do is archive to a portable hard drive, and even then I have only space for the most recent snapshot, not a history of recent backups. This is fine for recovering from a system failure, but I’d be in trouble if I suffered serious data or file corruption and that made it into my backups before I noticed.

So, yes, we use less paper. But my unread ebook folder gets larger and larger. My unlistened to play list is longer and longer. My unwatched shows on Tivo continue to accumulate. I have no assurance that I will catch up before data disaster hits. I know I should be feeling green, but instead I’m feeling blue. I could sure use some quantum storage right around now.

The 21st ODF Toolkit Scenario

2009/02/06 By Rob 4 Comments

Back in 2006 I gave a short in talk at a KDE conference in Dublin on the topic of “A Standard ODF Object Model”, essentially laying out my thoughts on why we needed an “ODF Toolkit”. As part of that presentation I listed “20 Prototypical App Dev Scenarios”, my attempt to enumerate all the fundamental patterns of use for ODF. I did a blog post on this list later that year.

I’d like to augment that list with a new pattern of use, a clever idea suggested to me by Jomar Silva in an email quite a while ago, but an idea which I just recently warmed up to. I believe this technique could be quite powerful and should take its place as the 21st scenario for any ODF Toolkit.

It goes something like this:

If you have a toolkit written in a language, say Java, and the toolkit has API’s which you can use to both read and write ODF documents, then you can write a program that will read an ODF document and write out the Java code that would be needed to re-create that same ODF document. So it is a code generation pattern. Java code reads ODF and writes source code for Java program that can then be compiled to write ODF.

This is very useful in a number of situations. For example, you can design your document in a familiar tool, like your word processor. Get all of the styles and layout correct and then run the code generator to generate the Java source file. Then hand-edit the source code to make changes, such as substitutions, insertions, looping to copy content down a row, etc. You could even adopt a place-holder convention in your original document, to make it easier to find the areas that you wanted to replace. For example “REPLACE-FNAME” and “REPLACE-LNAME” might be be a good place-holder.

Of course, this idea is of general applicability, not just limited to ODF. It could be applied, and for all I know has been applied to HTML, etc.

I love the smell of ODF in the morning

2009/02/05 By Rob Leave a Comment

I have a short ODF trio to share with you today.

First up, Jomar Silva brings us the happy news that Venezuela now mandates the use of ODF, joining Uraguay, Brazil and 14 other national governments that have adopted the International Standard for office documents.

BrowserShots.org has been part of my web design toolkit for some time now. It allows me to easily test a web page to see how it renders on a wide range of browsers and platforms, without having to personally maintain a dozen different machine and configurations on my desk. You enter a URL and click off which of 50+ different browser versions you want your page rendered on. The system then queues up your requests, farms them out to various machines that render the pages and return screen shot images (PNG format) of the results. You get some results almost immediately, while others might take 30 minutes.

I’ve recently received news that this same concept is now being applied to ODF documents in a new project called OfficeShots. Funded by the Dutch government and the OpenDoc Society, this project (not quite yet ready for beta) will:

[H]elp you make a better choice by letting you compare the output and other behavior of a wide variety of applications. Does your corporate style – the technical basis for many documents – actually look consistent across the board of applications – from OpenOffice.org 3.0, Adobe Buzzword and Symphony 1.2 to Microsoft Office 2000 with the ODF addin from Microsoft – or the one from Sun Microsystems? And how does it look on Mac OS X in iWork? When you are in an acquisition phase, officeshots.org will help you do a reality check if that fancy new open source suite or that productivity package you can get a bargain deal at – actually does what it says. On the spot.

This is a great idea and I look forward to seeing it in operation.

Finally, if you also have some ODF project ideas, then be sure to note that the NLnet Foundation has named ODF as one of its two focus areas for 2009 and that they are accepting project proposals for funding. So get out that digital pencil and start writing down ideas.