" /> Bill de hÓra: September 2003 Archives

« August 2003 | Main | October 2003 »

September 28, 2003

How to write a tutorial

Excellent: RIFE's Users Guide.

[overseer: supermoves]

September 27, 2003

Struts and Webwork

biv.blog-city.com

I guess I'm looking forward to comparing WebWork and Struts for an application I'm building

Me too. There's something about Struts... I can't put my finger on it. A colleague put it this way - 'it has a learning curve', but I think I'm more concerned about maintaining/evolving a Struts solution than building it in the first place.

I looked at Tapestry last weekend. And after writing a simple app came to the conclusion I'm too stupid or lazy to 'get' it without (up to date) documentation and examples. It just didn't gel with me, even after digging in the code to find out how the bindings worked.

Onto webwork.

[foo fighters: low]

IDEA: space invaders

Keep looking... you'll see them. Anyway, anyone want to interpret the state of my code?

space-invaders

[the vapors: turning japanese]

September 26, 2003

Migrating to Subversion II

A few months back I mentioned I was migrating some projects to Subversion. I've been using it regularly, if not day in day out. I'm of the mind that Subversion is light years ahead of either VSS or CVS, the two tools it will inevitably be compared with. There's no doubt - transitioning fully to Subversion is the way to go.

I'll be blogging more about Subversion, for now I want to mention some of the upfront differences between it and CVS/VSS.

There are some 'conceptual' hurdles anyone moving from CVS (or VSS) might have to overcome:


  • tagging/labelling is very different now
  • the entire repository is versioned on checkin
  • you can move files safely and easily

The way Subversion works with tags and branches is simpler than either VSS and CVS, but different enough to be confusing. To tag something in Subversion you perform a copy command, ie you physically copy it - a tag is not a marker on some conceptual timeline that the VCS will recompute for you, it's a named physical snapshot. To turn a tag into a branch you commit to the tag - now you're managing two codebases. To remove a tag or a branch you delete it. One advantage of this is that you can examine the labelled history of repository with a web browser instead of visually examining the output of a status or history command - this is since Subversion can make all files visible via a web server. Another is explicitness - it's obvious what's going on in the repository especially if the repository is degrading into a branch-fest - something that can happen without anyone really noticing in CVS or VSS, until the day comes to merge everything together. The notion of branching off branches, something that in reality is almost always a bad idea, but very common in less well organized code-bases, feels in Subversion well... dead wrong, as opposed to being intellectually improper - I take this as a very good sign.

When you commit some files in CVS you commit each file separately not as a transactional unit; modelling a commit as a unit of work is something you have to manage manually. The overhead of doing this in CVS is high enough that I'd never bother and I don't know anyone who does. Subversion is utterly different - the entire repository gets reversioned using a simple incrementing number. What's unsual about this is that most people use a single CVS repository to host multiple projects, often architecturally and conceptually unrelated. If you did this in Subversion you'd find your Java testing framework being versioned along with your ASP.NET wiki, which will seem odd. There isn't a simple way around this; again Subversion is being explicit about code management. You will have to think about how your code bases are conceptually and physically intertwined along with embarking on setting up repositories - but you're doing that already, right? [Antipattern hint; CVSROOT/modules is filled with filters and cross module joins]

Perhaps the most appealing thing about having atomic commits and global versioning is that it makes moving files around trivial. All history is kept. Not being able to move files around is something most Java programmers and ex-VSS weenies justifiably dislike about CVS. Best of all is that Subversion won't silently remove files from an old version (remember tags and branches are copies, not computations). Anyone who's ever been unable to reconsitute a historical version from VSS because it silently destroyed the version will appreciate this. The more subtle point is that it we aren't forced to agonize about getting the repository structure right first time; we can always change it later. Personally I've caught myself in the past putting off reorganizing a Java package structure or a heavy refactoring because I knew it involved fooling around with the CVS repository or that it might possibly destroy an old version in VSS. Any agile team using VSS or CVS which feels the repository is getting in the way should look to get onto Subversion.

[system of a down: prison song]

September 25, 2003

Code must be commented

Seen on extremeprogramming:

The best comment I ever saw was at the top of a truly hideous c program, including several 3 and 4 hundred line functions. It said /*This is the code I wrote to pay for my trip to Paris*/

- Steve Ropa

XMLPP (jabber) to become an IETF standard

In last call: XMPP Core

September 24, 2003

Text uber alles II: 404, archive kaput

Damn it.

Anyone who has ever linked to one of my posts is up to get 404'd. The archive numbers are out of whack with the reimport (actually, I haven't even checked that MT imported everything). I'm going to start by hacking on the trackback record.

This is going to take time.

Type "help", "copyright", "credits" or "license" for more information.
>>>

September 23, 2003

Text uber alles: mt backed by db goes kaput

So, Berkeley DB was corrupted beyond repair. I've had to reinstall MT, recreate the blog from scratch, import all the old entries. I'm using a MySQL account to back the blog this time round. Now all I have to do is recreate the templates.

I never kept backups of db, but did export the blog from time to time. The import went really well, up to June or something, but it stalled. Let's see... ah, they're flat files not binary goo. I can fix that (Cx-Cf, clack clack clack, Cx-Cs). And away we go. But db is binary goo and wasn't fixable; the best I could do was throw it away and start over. xml-dev, if you're reading this... what price binary?

My subversion server is backed by db. I'm concerned.

September 12, 2003

OpenOffice exporting RDF

First cut, looks promising...

German
English

Quote of the week: Ross Judson

Ross Judson: Spiral Dive


Let's look at the simple equation:

C + Unrestricted Access + Buffer Overflow = You Will Never Be Secure.

Windows machines are fundamentally flawed, at the core. It can never be fixed. You either need a VM (which provides a relatively secure environment), or an operating system that uses a variety of techniques to prevent a process from doing anything it's not supposed to do.

I wonder this is will always be true. It's no secret that Microsoft are working like mad men to lock down Windows - though I'm not sure whether they're taking a stategic approach or simply firefighting at the moment. Of course though ripping out the heart of your OS is a great incentive to push for an upgrade, I wonder if Redmond have the stomach to start over. It'll be interesting to see how it plays out.

Data complexity

Diego:

What I realized today is: there's a huge side effect that the format has on content access: monopolizing the market for access becomes easier the more complex the content format is.
My point: This should give pause to anyone in the "go-Atom-crowd", including me.

I think most of the go-atom crowd get this, at some level. I'm also certain that every body and organization involved in WS standards gets this, maybe more than most of us. Lock-in through more-complicated-than-it-needs-to-be (in marketing terms, 'rich') data is an old, old strategem. Same for APIs and software processes (try and tell me the CMM is as simple as it can be).

September 11, 2003

New RELAX/XML mode for emacs

Awesome. nXML is new XML and RELAX NG mode for Emacs from James Clark. There's a good overview of the features on xmlhack.

W3C XML Schema will disappear

I just ran across Jame's Clark's year old, but still excellent criticism of W3C XML Schema. If anything, it's gotten better with age.

If you're working with W3C XML Schema, it's time to take stock. Then read the RELAX NG tutorial and ask yourself what technology you'd rather be working with. As the mainstream of web services developers run and not walk away from RPC-encoded toward REST, Doc/Lit and SOA systems, RELAX NG looks certain to become the de facto schema language.

Third Doctor

Which Incarnation of the Doctor Are You? - Quizilla

The Third Doctor
You are the Third Doctor: Charming, commanding,
physically competent and more than a little bit
vain. You share the Second Doctor's amiability
and the First Doctor's lack of patience with
small-minded idiots. Your urge to take care of
the entire universe often leads you to
arrogance, but you're dashing, self-
sacrificing, and brilliant when a crisis
erupts.


Which Incarnation of the Doctor Are You?
brought to you by Quizilla

Damn, I wanted to be Tom Baker.

September 04, 2003

Working in Chiswick

Jorgen Thelin: The End Of An Era

Wow. Until March of last year, I used to work down the road, in the Agfa building. I should've taken some pictures :)