Welcome to the Guardian, Simon! I only wish I'd still be there when you started, but I'll be gone by then. :-(

I don't think I'll be able to make QCon, London this year - my current employer doesn't really see the point of conferences. Which is a shame, 'cos it could have been designed for us. There are an uncanny number of speakers relevant to us: Jeff Sutherland ('cos we Scrum), Gavin King ('cos we use Hibernate), Rod Johnson ('cos we use Spring), and Alex Russell ('cos we use Dojo), plus movers and shakers like Martin Fowler, Werner Vogels, Kylie, and Dave Thomas. I might be lying about one of those, though.

Never mind - there's always PyCamp!

And who knows - I might win a ticket. ;-)

We've not automated our functional tests in the past - I know, I know - but we are really trying to pick up our game in our currenty project, so manual functional testing is another of our bad habits that we are consigning to the dustbin of history. With a bit of a steer from Sam, I looked at a number of functional test tools, but Selenium really stood out from the rest. It's just powerful enough, it's really simple, and it runs in your browser, so you can test browser compatability. Take a look at the demos to see how simple it all is.

In essence, your test script is just an HTML table, each line of which is either an action or an assertion. There's even a tool to record your actions to give you a hand building regression tests.

Now I just need to work out how to integrate it all with Cruise Control. Anyone done this?

Oh yes, and I need to find a way of testing our web services, too. Is there no end to the array of tools that you need to build a web application these days?

JavaScript : Hiding Email Addresses presents a nice simple way of including your email address on a web page wiile hiding it from spambots.

Yes, Mum, you need this. But don't worry, I'll sort it out for you. ;-)

Hmmm. A bit of rather nasty DHTML for you. See it here, or run it here.

Run this in Firebird, and all is well. Since your browser window wasn't opened by JavaScript, it can't be closed by JavaScript. (Note that the onbeforeunload event is an IE special, so the 'navigate away' link doesn't even try to call the doclose() function under Firebird.)

But under IE, it's different. Both the links execute the doclose() function. Which is fair enough. But, scarily, in both cases, your browser window ends up getting closed. Clearly, the assignment to the top.opener property has fooled IE into thinking that the window is a pop up, that that it's safe to close it. Yuck!

What I don't understand is: Why do you see the alert box more than once?

Tested with: Firebird 0.7 and IE 6.0 SP1.

Very professional looking - Revenge of the Menu Bar.

Via magpiebrain.

More bloody clever JavaScript stuff from Stuart Langridge - JavaScript Event Sheets allow you to apply event handlers to elements without explicit JavaScript tags.

Sortable tables in pure DHTML. Cool stuff.

Trawling through the DHTML and Javascript category of Simon Willison's Weblog yielded many fabulous things.

• Jesse's Bookmarklet's Site
• Auto-complete text boxes
• Matt Kruse's JavaScript Toolbox
• Popup Windows
• Better image rollovers
• Unobtrusive DHTML, and the power of unordered lists

So, if I'm going to be using JavaScript and bretheren, I'm going to need a unit test framework. So, is JsUnit the standard?

The past couple of days' JavaScript training from Lumia was good. We covered a lot, and had plenty of hands on exercise. I've supported JS before, but I was in at the deep end, souring the manual. Now, I think I'd be happy to know what I was doing, and to develop new stuff from scratch.

With the manual in hand, of course. ;-)

What was missing from the course was any mention of OOP, or of exception handling. Both of these should have been covered, IMHO, especially given JS's somewhat idiosyncratic treatment of the former. This would definitely have pushed the course into three days, though.

OK, Andy, EMCA Script then. ;-)

It turns out that the JavaScript Training is pretty good, and the trainer is coping pretty well with the disparate needs of my disparate team. We covered a bit of CSS and DOM as well as JS yesterday. By end of play today, I reckon we'll all know enough to achieve most of what one might want to do, and know where to go to find out the rest.

Dan and I are tearing through the examples, while the others are proceeding a little more slowly, but we are keeping together fairly well in terms of subject matter. I knew pretty much all of this stuff in theory, but practise is a little different, of course.

Bob, the trainer, and I have made a few discoveries along the way, mostly to do with the way that IE handles CSS. I had put a !DOCTYPE into all my HTML files, pretty much without thinking. This put IE into standards mode, and some of the examples didn't work. Nor did they work in Firebird. Took a while to work that one out, but having done so, it was useful stuff to know.

Once again, I tried to get in early this morning. Once again, chaos ensued. Sigh.

I was getting in early 'cos I'm on another training course today. Two days of JavaScript. It'll be interesting to see how the trainer deals with the range of experience he'll find in the attendees - we range from me, with extensive experience in various scripting and OO languages, and some real world JS experience, to Tracey, who has barely programmed at all.

This could be handy - RegExLib.com.

Also handy if you are working with JavaScript - Test Your own JavaScript regular expresssion.

A post over at c.l.py steered me towards this - Building user interfaces for object-oriented systems.

It has some interesting, if perhaps somewhat controversial, things to say on the nature of object orientation.

You may have read in a book somewhere that an object is a data structure of some sort combined with a set of functions, called methods, that manipulate that data structure. Balderdash! Poppycock! First and foremost, an object is a collection of capabilities. Very true, this. The important thing about an object is what is does, not what it has. The latter is an implementation matter.

Classes are irrelevant -- they're just a convenience provided for the compiler. Also true. This was pointed out to me while looking at JavaScript recently. Its rather, uh, idiosyncratic OO model does away with 'classes' as such. Instead, you just define a construction function, and add methods to its prototype. Look, Ma, no classes. (I don't really like this approach much - it makes subclassing rather clumsy if nothing else. But it does work after a fashion.)

All data is private. Period. (This rule applies to all implementation details, not just the data.) get and set functions are evil. (They're just elaborate ways to make the data public.) I like Python's approach here. No data is really private (see The principle of least privilege for why), but you can intercept any references to this data if you want. So, you just refer to object.attribute, and it's the object's business whether that just accesses the data attribute or calls a method. No need for get and set methods here.

All objects must provide their own UI. What? Is he serious? The presentation object should always be separate from the business object! Some business objects don't need any presentation layer, and some may need several. (The persistence layer should also be separate.)

I'm off to Amsterdam next week to support one of our clients, who have a lot of JavaScript. Which I've never used.

Anyone know a good tutorial? ;-)

I've just got a funky new laptop, so I should be online OK. We'll see.

aqTree2: explorer-style trees from unordered lists

What a cool little widget!

JavaScrip, yes, but everything still works with JavaScript off, so that's OK. Honest.