We’ve begun testing out Hamachi at work as a substitute for our defunct VPN and it’s showing a lot of promise. It sets up a peer-to-peer VPN which is quite clever and simple to get working. When combined with installing Bonjour on the Windows boxes (Macs have it pre-installed) and tweaking the DNS settings to add .local to the search domains, the DNS look-up works brilliantly cross-platform as well.
Useful tool for writing performance tests: Japex. Must remember to use that when we do our next round of profiling. Doug’s suggestion is that once we identify a bottleneck in the code, we write a performance test for it with Japex then try to optimize it until we reach the desired performance level. I’m not sure that our codebase is likely to see performance regressions in the same area again (I can’t ever recall having to reoptimize the same section of code), however having the test would be able to quantify how much of a performance benefit we get which would be a useful metric to know.
I’ve been developing some custom views (javax.swing.text.View subclasses) in the last few days. These are right up the alley of GUI code that people tend to find difficult to test but I’ve been pushing forward with test driven development with a fair bit of success. The main approach I’ve been using is to mock out pretty much everything the view interacts with and test it’s logic more than it’s actual rendering. In fact, this particular view doesn’t do any rendering of it’s own, but it does do a lot of layout of child views etc.
I’ve discovered why I’m lacking motivation for our Software Design Document at work. It’s tedious. It isn’t the creative part of the effort. It’s boring!
The trouble with boring design documents is not just that they’re boring to write, they’re boring to read as well – so noone does.
In our most recent round of design documents at Ephox, we took some advice from Joel on Software and started injecting humor into the docs. So instead of just anyone inserting a table into a document, now it’s Miss Piggy creating a table of Kermit’s good and bad points – complete with a picture of Miss Piggy and Kermit. At one point we actually had half the engineering team rushing off to read the specification documents just so they could laugh at the stories.
Jensen Harris: Help Is For Experts
One of the most interesting epiphanies I’ve had over the last few years seems on the surface like a paradox: “help” in Office is mostly used by experts and enthusiasts.
How can this be? I think my biased assumption was that experts know how to use the software already and eager novices would be poring over the documentation trying to learn how to be more effective using it.
Jonathan Boutelle talks about how he made a wiki work with his software developers:
So, so true. The first two could be a little more generalized: Start with a reason to use the wiki and make it easy. Making it easy encompasses insisting on Wysiwyg but the editor is the most important touch-point of a wiki that it’s worth stating separately.
If you’re looking for a job in sunny Brisbane, Australia, and the job description below sounds appealing, send me a resume at adrian@ephox.com.
Senior Software Engineer
Ephox, a world-leading, content-authoring software provider seeks to employ a Senior Software Engineer for its Paddington office in Brisbane. The position responsibilities include writing technical specifications, collaborate in design/architectural recommendations of overall systems, implement software QA practices and be the technical lead in the Ephox development team. The position offers the opportunity to work with leading technologies and software vendors including content management providers. The successful applicant may be expected to provide professional services directly to customers or partners both on and off site. They will also be expected to actively participate in other areas of the business including requirements gathering for new and existing products, mentoring and pre-sales support.
I pulled the big red lever on CVS this morning and converted over to Subversion at work. It’s gone pretty smoothly though one of the engineers is complaining that Eclipse is now freezing up a lot. Not sure if that’s related to the Subversion change of if something else is going on but it’s something I’ll have to investigate some more.
It’s interesting to watch our press release about the release of EditLive! for Java 5.0 flowing around the various news agencies via a Feedster search. I really should circle back with the guy pushing out the notifications to see which ones he actively submitted and which ones it flowed around to by itself. It’s pretty amazing what you can track these days.
For the past few weeks I’ve been investigating and planning a move from CVS (CVSNT actually) to Subversion at work. Hopefully this week I’ll be able to do the actual conversion and see what mess it makes.
The main thing that’s missing from Subversion is an exact equivalent for CVS’s meta-modules. Subversion’s externals are good but need to support relative URLs so that branching is simple. Even so, it’s not that hard to go back and re-edit the externals property after branching and it can probably be automated with a small script. It might actually be a good opportunity to automate adding new branches to our automatic build setup as well so whenever we create a new branch the build machine (affectionately known as Bob) automatically starts building it.
I noticed Evan made a side-comment about Ephox licensing which I wanted to clarify and since he doesn’t have comments enabled but does have trackback on I’m posting it here. Ephox products are available both in limited seat licenses as well as on per-server terms with unlimited users. The server licenses make it much easier to deploy in big organizations as you don’t have to deal with the overhead of ensuring you have enough user licenses etc (which is what Evan was originally talking about).