The back button has been a great challenge for a lot of modern web applications and WYSIWYG editors are certainly no exception. Way back before I can remember, someone had the fantastic idea of preserving content entered into text fields and restoring it if the user hit the back button to return to the page. Unfortunately, with the advent of WYSIWYG editors, this was generally lost because the browser reruns the JavaScript in the page again, providing no indication that the user was returning to the page. I could be wrong, and I’d love to hear of other examples, but I don’t believe there is a WYSIWYG editors available today that preserves content when the user hits the back button. I find it somewhat interesting that despite the huge amount of user angst this causes1, there doesn’t seem to be a lot of interest in solving the problem.

Since cruise control doesn’t use a bug tracker – it only provides email lists and I don’t currently have access to my email – I’ll just report this bug here and maybe someday along the way they’ll discover it and fix the problem.

Anyway, my beef is that the cruisecontrol webapp doesn’t work with lynx because it uses a ridiculous JavaScript system to trigger new builds. Now, normally I don’t use lynx as a browser because it tends to be pretty limited, but it would be nice to be able to trigger a build remotely without having to manually parse HTML files and find the URL to ping to get a build to start. At the time I was SSH’d through two machines and then using Hamachi to get access to the actual build machine so it was a little bit difficult to use a standard browser at a reasonable speed.

I haven’t fully investigated all the details and combinations, but it appears that if you use the cache_archive_ex parameter to specify the Jars for an applet and at least one of them has a specified version, any that don’t have a version get ignored. So for instance, if you have cache_archive_ex=“editlivejava.jar;6.0.0.1,footnotes.jar” editlivejava.jar will be downloaded and used correctly, but footnotes.jar will be ignored.

Additionally, any jars specified in the cache_archive parameter get ignored (probably unless they have a matching version in the cache_version parameter).

You know, until just now I’d always thought that getting the JRE installed was a 10 minutes process or so. It turns out that this computer didn’t have the JRE installed so when I went to write a blog post1, I got the missing plug-in box and the instruction to click to install the required plug-in. So click I did and in under 2 minutes not only is the JRE fully downloaded and installed, but the page has reloaded with EditLive! fully up and running, ready for me to write this post.

To Jonathan Schwartz,

The Ephox engineering team saw the really cool work you’ve done on project blackbox and we’ve come up with a marketing idea that would help you show just how portable blackboxes really are.

In essence, the idea is to take a blackbox on a travelling road show around to Sun’s potential clients to show off what it’s capable of. The trouble is, there’s no point in just dumping a container outside their door and saying “cool, huh?” – it’s got to actually do something cool when you put it there. That’s where we come in.

We’re coming up to that point in development again where we need to do up a change log for a release. Ephox has never really gotten this process down pat so it inevitably leads to trawling through a back log of subversion commit logs and bugzilla reports. It always feels like there should be a better way to do it, but it’s always too easy to forget to add something to the change log if you try to keep it up to date all the time.

Whoever thought that supporting free mailing lists by putting ads in each email was ever going to be a good idea? My spam filter consistently picks up emails from Yahoo lists as spam and because the ads keep changing it never seems to learn that their not.

It probably doesn’t help that Yahoo also includes a screenful of mailing list information at the end of each and every single post to the list.

After much hard work and gnashing of teeth, the beta of our next major release is finally out, including the new productivity pack and track changes. The internet Gods tried to stop us by cutting off our oxygen, er internet supply but the files finally made it across the pacific to our main servers. You can check it all out in the productivity pack section of Ephox.com. It’s a real beta in that we haven’t done any real testing on it and so it’s likely to have stability problems that we’ll iron out before the final release. We’re very keen to get feedback on the release, both in terms of any bugs you find and in terms of how to improve the UI, extra APIs to add for integrating it into backend systems etc.

I’ve found that doing TDD causes me to use, or perhaps just be more aware of using, some useful debugging and programming techniques. As a side note, it occurs to me that debugging and programming in TDD are essentially the same – in either case you’re trying to fix the failing test.

So while TDDing, I find myself asking “What’s different about this case?” in a way that I can’t ever recall before. It’s easier to think like this with TDD because you have a documented, repeatable set of situations to compare between. Sometimes a change you make to fix the latest test will cause others to break and it’s then that you need to determine what’s different about the new case that needs special handling. Developing without TDD, the question I’d tend to ask is “how should this work?” which is a lot broader and harder to comprehend. I still ask, “how should this work”, but it’s usually at the start of a story where I need to get my head around what needs to be done and get an overall view of the problem. Finding the answer usually means a bunch of scribbling on notepads or whiteboards going through the possible scenarios and determining what should happen. While programming, the scope is usually reduced enough that you don’t need to scribble on whiteboards, but I do find myself going over the various cases to narrow the question down to “what’s different about this case?”.
In the end, what it means is that TDD is documenting a lot of what I would otherwise do over and over in my head and getting me to the more narrowly focussed question more quickly. It doesn’t eliminate that mental process, but it does make it easier and provides a safety net for it if I miss a case.

We’re looking to move most of our servers into VMWare so that we can easily back up the entire system and restore it in case of hardware failure. We’ve moved our Jabber server and now buzilla into VMWare and the next most likely candidate is our Subversion server. I’m wondering if it makes sense to store large amounts of data in the VM directly or if we should look at putting the actual data store on the host machine, but all the configuration stuff in the VM.

One of the really core principles of XP is the idea of small, frequent releases. The most obvious benefit of this is that it allows users to see the product and provide feedback about what could be done to improve it. What’s not so obvious, but is part of the reasoning behind a number of XP principles, is that the developers benefit from this just as much, if not more than the users. Being couped up in an office somewhere slaving away creating software that no one’s using just isn’t fun. Getting your software out to users and having the feeling that you’ve achieved something is a big feel-good moment and it energizes the development team, allowing them to keep going full pace instead of getting tired and stressed.

In a comment on Software Teams Must Gel, James C. McPherson asks:

Given your brief description of the Ephox interview process, it would appear that you’re not in favour of people who work from home or are even more remote from your office. I’ve spent a long time working with remote management and geographically distributed teams.

There is, of course, no solitary correct solution, attitude or approach to building and gelling a successful software engineering or development team. I would be interested to find out what the Ephox perspective in on remoteness.