Using Your Wiki Effectively

We make pretty good use of Confluence at the office so it was interesting to read Frank Kelly’s take on wiki’s in the workplace.

To a certain extent I agree with his arguments. We’ve been using it as a storage repository for feature breakdowns, roadmaps and design reviews amongst many other things but it has been difficult to create (and maintain) meaningful information in an environment that essential boils down to a free-for-all (ie. “Do I create a new page for this? or Do I update an existing page to include this new information?). Basic navigation has sufficed to a certain extent but short of having to search for everything (tags and keywords) I’ll admit that it has been difficult to develop a consistent structure. At best we have focused on developing a few common spaces for content that otherwise has grown organically. With a goal of promoting authorship and ease of access to information, security around page (modifications included) is kept to a minimal. This has worked so far but is likely to be reviewed as overall wiki usage increases.

Fortunately Confluence allows us to fairly easily track ownership when changes are made to a wiki page. Templates would likely help out a bit structurally but we’ve yet to invest much time in that direction. A suggestion for anyone implementing a wiki in a small->medium sized organization would be to regularly sent out emails containing wiki modifications (just the links/sections that have been updated). Getting notices pushed to your inbox is infinitely nicer than having to regularly monitor selected pages of interest.

If you are looking for an enterprise wiki solution, I’d highly recommend Confluence. Despite the inherent problems involved with trying to organize organizational data consistently, we have seen a lot of successes stemming from our usages of a wiki. Confluence, itself, is an excellent tool and it’s promoted collaboration amongst the different groups (primarily development and product management) in a way that word documents cannot. It supports iterative document development and in an agile environment, that’s critical.

Above all us, keep things simple. Present the information that’s necessary and nothing more. Don’t try to get too fancy and most importantly, be consistent.

DoS’ing Virus Scanners : Can it be done?

A bit of curiosity here.

The amount of time to run a virus scan on my work laptop is now approaching 8 or 9 hours. It’s reached the point where there really is no convenient time of day to have it run. Our system administrator currently has them running automatically at 4:00am, but when I’m up and out the door at 7:00am it’s usually only scanned 700k of the estimated 2million files.

Sounds like a bit of an opportunity to game the virus scanner. A couple of possibilities off the top of my head:

1. I don’t know the logistics involved with scanning a single file or if the amount of time varies upon it’s makeup. Taking a brute force attack, the deployed virus could create a couple million files strategically placed to increase the scan time to the point where people start canceling scans early.
2. Write something that artificially increases system load and therefore system scan time. It should be possible to make such an app smart enough to only run when it’s detected increased load from the virus scanning process.

Rather simplistic but who knows? If nothing else, with ever increasing hard drive sizes, we’ll need some better heuristics to prevent linear increases in scan times.

Property Change Listeners : Adding and Removing

Quick lesson learned.

If you have a property change listener registered against a specific property name, you have to use removePropertyChangeListener(String, PropertyChangeListener) and not removePropertyChangeListener(PropertyChangeListener) when you want to remove it.

Basically, you cannot do the following:

PropertyChangeListener foo = new XXX();

public void enable()

{
    addPropertyChangeListener("SomeMessage", foo);

}

public void disable()

{
    removePropertyChangeListener(foo);

}

Truth be told it’s rather innocent looking code but I did spend a good day tracking it down through some fairly nasty table and panel hierarchies. The kicker is that by not actually removing the property change listener, you ended up queuing many copies of the exact same listener (basically enable() / disable() were called repeatedly based on the state of the UI).

To make a bad situation worse, have the listener make a server call. It’s not too bad when there’s only one registered, multiple that by 300 and you’ve got issues.