So we’ve got a new internal system that we’ve built on top of JCR. Currently we’re using Jackrabbit as the repository, but eventually it will be ported over to something like IBM Portal or something like that. Unfortunately, right now we’re deploying the app to a pretty limited server – both in terms of CPU and RAM.

It turns out that using Jackrabbit with the Derby persistence manager in that kind of situation is a horrible, horrible idea. Everything works great on systems with modest amounts of CPU and RAM but once we deploy to that poor little virtual server in the sky page load times skyrocket and the whole thing becomes unusable.

Ken Coar complains about some of the changes in FireFox 2.0 and mentions:

My basic plaint is as usual: when changing the user interface, don’t violate the Principle of Least Astonishment and force the change on the user. Make it the default, perhaps, but always provide a preference option that lets the user keep the old UI behaviour. The user should be in charge of changing his work habits, not the software.

If ever there was a problem that just wouldn’t die it has to be inter-project dependency management. If your code depends on external libraries, it’s pretty simple to pick whichever solution you prefer – either grabbing a version from a repository or checking jars into your source control. However, if you depend on a project that you control, it gets so much messier.

If the projects are small, it’s probably a good idea to just set up the build system to build them all together – effectively making them separate projects even if for development purposes you can just build this bit or that bit and utilize precompiled versions of the dependencies.

That permanent generation had better provide some pretty damn amazing optimizations or I’m going to add it’s inventor to my list of people to track down and torture at next JavaOne. It turns out you can only reload a Tomcat webapp so many times before the PermGen space fills up and everything dies. That’s annoying enough in development but it means I can’t upload a new WAR file to our test server regularly without also bouncing Tomcat. Right now our continuous integration server (Bob the Builder) is doing just that after every commit so the server isn’t staying up all that long.

It took forever, but I’ve finally how to stop Tomcat adding a Pragma: no-cache header to any resources in a secure context. You need to set disableProxyCaching to false, so if you’re using basic authentication you need a valve like:

<Valve className="org.apache.catalina.authenticator.BasicAuthenticator"
  disableProxyCaching="false" />

That needs to go within the definition for your web-app. So, within the META-INF (some sources say within WEB-INF?) create a context.xml file like:

<Context>
<Valve className="org.apache.catalina.authenticator.BasicAuthenticator"
  disableProxyCaching="false" />
</Context>

I found deploying as a WAR didn’t work (it seemed to ignore the context.xml), but deploying the exploded files did work and that’s fine by me.

Apparently Sun has finally decided to give some love to the Swing text APIs with the addition of a removeElement method. What the linked article fails to mention is that in the particular example given, you can remove the list item with a simple document.remove(e.getStartOffset(), e.getEndOffset() - e.getStartOffset());

When you get into trouble with the swing text apis is when there are two elements that start and end at the same point – ie: a list as the only child of a table cell:

I’ve spent a fair bit of time writing articles for LiveWorks! lately – posting weekly isn’t as easy as it seems, particularly when you have three weeks leave coming up. Most of the articles include some kind of code, be it JavaScript or Java and an explanation of what the code does, why it does it and how you might use those techniques in other ways. As I go through writing the article trying to explain my code it really highlights how nonsensical my original design decisions are. Even when I’ve gone back over code and carefully refactored it to be clear, when I come to write the article I almost always rearrange things again.

For quite a while we’ve lamented the lack of whiteboards in our office and talked about getting some in. A week or two ago Brett actually arranged it and so I’ve wound up with a lovely big whiteboard above my desk that I happily draw all over. I’ve always been a big fan of whiteboards for problem solving or brain storming sessions, even if I’m working alone. Something about the big open space and ease of erasure makes it so much better than paper.

I discovered one of our client’s company blogs1 tonight because they mentioned they’d just upgraded to EditLive! 6. Reading through the backlog I discovered they’ve found a clever way to reduce the impact of form spam that I hadn’t come across before2 – only accept the submission if it uses multipart/form-encoding not just a plain post. Like most techniques it won’t work if everyone does it but it’s another interesting way to differentiate.

When an engineer can reproduce a bug they get excited because it means they can be sure to fix it.

When a manager can reproduce a bug they get annoyed because it means they keep running into it.

This is currently the most frustrating part of the transition from engineer to manager. I have in fact submitted a patch on one occasion – it was rejected because it didn’t have tests. Sigh.

One of the challenging practices in XP is daily deployment – it requires your development team to have a very low defect rate and completely automated build and deployment tools. In an off the shelf software scenario it has the additional challenge that you can’t actually get your customers to upgrade every day.

At Ephox we’ve adhered to this practice pretty well in the past by automatically deploying builds to all our internal systems, including our corporate wiki, website CMS and even this blog. Of course, that’s still just a small subset of the kind of environments that we’re actually used in and it’s not actually getting out to real customers. To take the next logical step, we need to make those builds available to any customers who feel like checking out what’s new – maybe not every day, but between all our customers hopefully regularly enough to give us good feedback.

It turns out the root cause of the problems I was seeing with Safari on Windows is that it simply doesn’t support signed applets. That’s pretty sad really. Apple seem to have implemented their own Java plugin instead of using the one that Sun provides (they’re using the Sun JRE via their plugin) and of course it’s missing most of the features you’d want from a Java plugin.

I’ll report it to Apple officially just as soon as someone fixes the bug reporter – it’s currently down. Perhaps there are too many people logging bugs against the new Safari and Leopard builds….