Symphonious

Many people think that because Java has garbage collection, that memory leaks aren't possible - this is totally and utterly wrong. One really good way to introduce leaks into Java programs without blatantly holding on to object references is to create a new thread and then not use it. Once you create a thread, it is added to the list of runnable threads. I'm not sure why, but even before the thread is actually started, Java treats it as a running thread and holds on to it. Obviously threads that are currently running shouldn't be garbage collected, but it seems like an unfortunate side effect that newly created threads also can't be garbage collected. Once you know about it, the solution is simple - only ever create a thread immediately before you call its start method.

Today however, I learnt another unusual way to introduce memory leaks - start a javax.swing.Timer instance and don't keep a reference to it. The person who originally wrote this piece of code obviously thought that the Timer defaulted to firing once. It doesn't. Timer's default to spawning a new thread and continuing to fire the action until you call its stop method. This wouldn't be so bad if it weren't for the fact that the ActionListener passed to the timer was an internal class and thus brought along references to the rest of the system.

On the plus side, out of this ordeal I've managed to set up a simple way to profile our applet rather than just profiling the bean. The codebases only differ by one or two classes, but this memory leak was one that only appeared in the applet (and then only in a specific situation). I probably should document the pain I went through to get it working at some point, but not tonight.

For a couple of years now, Ephox has been very successfully using a wiki to provide communication within the company and helping to bridge the gap between our two offices on opposite sides of the pacific. Central to the success of the wiki has been the successful integration and configuration of EditLive! as the editor. It certainly helped that we have a high quality editor with lots of attention to detail but the most important aspect was the amount of attention we paid to correctly configuring the editor.

The first key configuration option was to use HTML as the markup for wiki pages, but preserving the ability to use wiki markup for links. This meant that the full functionality of the editor was available, but the ability to easily link to other pages was preserved. It was still possible of course to use standard HTML hyperlinks and for external links that was quite common. For internal links though, it's difficult to beat the efficiency of putting square brackets around a phrase to make it a link. When you use a WYSIWYG editor, don't be afraid to preserve non-WYSIWYG functionality where it makes sense. The aim of the editor is to reduce the learning curve as much as possible without reducing efficiency in the long term.

The next key benefit was using the editor to encourage specific behaviors. We wanted people to add their comments to pages so we added a custom button that inserted a simple comment template with the date and the user's name - taken from their wiki login. This meant that not only was it easy to comment, inline, on content on the wiki, but it was easy to see the comments and know who they were from.

The other good idea we had was to put a bug report button right there in the editor. The original intent was to capture feedback about our editor so that we could improve it, but it has actually allowed us to identify and relieve user complaints about a range of different things from wiki configuration and other problems to new configuration options to set in the editor as well as quite a few bugs that we managed to get fixed before any of our users saw them. There's a huge benefit in giving users a highly visible channel for providing feedback. Our biggest problem with the current feedback system is that it often feels like a black hole for users - we don't have a dedicated sysadmin to make improvements so they can often take a while to come through and often the original request is forgotten by then so they don't notice when the changes are finally made. If we devoted a little more time to making the feedback system more advanced, it could better tie in with our ticketing system and the user would be informed of progress.

Another really cool feature that we've actually had in our editor for many years but goes unnoticed half the time, is the ability to pop the editor out into a separate window. When you want to make larger edits, it can be really useful to be able to maximize the editor window and just focus on what you're writing. This allows more detailed content to be developed on the wiki instead of being written in Word and then possibly copy and pasted or possibly just forgotten. Another common behavior is to attach documents to the wiki but people are far less likely to download and open the attachment just to browse the content to see if it's really what they're after. In the end that information just winds up being ignored. If you can get it to be developed right there in the wiki, it can be edited, commented on and get all the other benefits of content on a wiki.

Finally, we're beginning to discover that there is a lot of power in having track changes available on a wiki. At this stage we haven't really worked out how to leverage track changes as well as I can imagine we can. We'll have to keep an eye on how people are using it and see what ideas we can come up with to leverage the track changes data. Improved diffs seem like a pretty good starting point.

You've got to hand it to the Atlassian team - they are seriously clever. Wikipatterns.com launched recently to give people a place to go for advice on improving wiki adoption. The content is very useful to have in one place even if what's there right now won't be new to most people using wikis. It is undoubtedly useful and Lars Trieloff from the Mindquarry team has already linked to it (Mindquarry develop a soon to be opensource wiki that's integrated with a bunch of other cool looking stuff). I'm sure other wiki vendors will be linking to it over time as well.

The really clever bit is that at the bottom of each page is:

Wikipatterns.com is sponsored by Atlassian Software, creators of JIRA, Confluence, Bamboo and Crowd.

It is of course quite reasonable that since they did all the set up work and are paying the bills they should get to be sponsors. From a marketing point of view though it's brilliant - their competitors will be linking to an instance of their wiki complete with links to Atlassian on every page. What I love most about it though, is that while it might frustrate some of their competitors, it is undeniably a really, really good thing to do for their users and users of any type of wiki. Kathy Sierra would be proud.

Now I'm not sure which section it would fit into, but my best advice for driving wiki adoption is to make sure you have a really good WYSIWYG editor in there. Learning wiki markup is a major barrier to entry for people that just isn't needed anymore. I'd add it somewhere myself and let the WikiGardener find a spot for it, but given my obvious bias I'm concerned it would just look like spam. I've previously hinted at our success in adopting a wiki by integrating our editor (we started off just using wiki markup), but haven't actually told the whole story - probably should do that at some point.

According to our stats, yesterday I deleted over a thousand lines of code - sounds like a productive day to me. Hopefully today I'll find another thousand lines to delete. It's amazing how unused methods can build up without you noticing. Eclipse will tell you about unused private methods, but not about public ones that aren't used anymore. Most of them had unit tests even, just that the entire functionality had become unneeded. There's probably some duplication in there as well that will let us delete more lines of code.

Just another example of why you shouldn't judge programmer productivity based on the number of lines of code they write (which Ephox has never done for the record).

There were a few interesting comments on my last post. Firstly from Hen:

People are attached to their editors and not their markup. If Maven had moved from xdocs to apt-gui for their site creation, I doubt there would have been many takers.

It's true, people are very attached to their editors, but you don't have to force them to change, it's also not a reason to write customized mark up languages. In Maven's case, the documentation winds up being published as HTML so that's really the best format to use, people can use whatever editor they want to edit the HTML and it allows people to choose to use a WYSIWYG editor because they exist. This is similar to what Tim O'Brien said:

Part of the reason why Maven docs are so bad is because there is no way to integrate this customer format with great tools like Ephox.

Thanks for the plug Tim, but there are plenty of good HTML editors that would have done the job and a standalone program probably would suit most developers better in this particular case.

TimC also made an interesting point:

Actually, please don't speak for all authors. The best way I have found of authoring scientific works is with LaTeX. Most definitely not wysiwyg. Fudging around with mice and equation editors is teh suck when you can simply say $\int^\inf_0 \frac{1}{x^2}= …

This is definitely a case where wysiwyg isn't the best option, but it's also certainly not a case where they have simplified the markup language - LaTeX makes HTML look like child's play. I'm not sure TimC would be so keen on have to use ASCII art to draw his equations like Tim O'Brien had to for tables in Maven's markup language. I'm certainly not one to advocate WYSIWYG in every situation, my point was that you should use the most suitable mark up and then use the editor to make it easy and intuitive.

Dumbing down the mark up just limits what you can do and forces you to learn a new syntax. Using a standard mark up like HTML or LaTeX allows authors to leverage their existing knowledge and you can simplify it by providing or recommending a good editor. Sometimes that editor will be WYSIWYG, sometimes it will just be a plain old text editor.