Freemind is an opensource mindmapping tool (written in Java) that can usefully export to a variety of formats (main homepage seems to be freemind.sourceforge.net , link from wikipedia). I had an occasion to use it recently with a view to providing a mindmap on the Nominet website. A problem here though was Freemind’s required use of Java - and no real practical way to provide an accessible alternative (imagemaps anyone?) for anyone viewing the map.

A solution was to use Flash as a container (although that in itself raises accessibility questions). To create a mindmap entirely in Flash was also a possibility although that would be tricky and time consuming; so using Freemind was the only realistic alternative. Unfortunately, the latest release (0.8.0) does not support exporting to ‘.swf’. Exporting SVG (or even JPG) static maps is entirely possible, but this would not have contained any interactive links to other content, for example.

Luckily, the latest beta (0.9.0 beta .8) does indeed contain an option to export to ‘.swf’. The bad news is (as I found out) that the functionality of ‘rich text’ within nodes does not work within a Flash environment. This means that anything other than text within a node (or even styling of that node’s text, including any formatting) will not appear. Any attempt to include an image next to a node results in ‘undefined’ when displayed.

However, there is a tweaked version of the Flash browser, developed by Juan Pedro at Efectokiwano.net. This has some sketchy support for rich-text within the Flash container, which at least means images can be placed. However, there are definitely some areas that could be improved, such as:

• Complete rich text support for all image formats
• Ability to place images before or after a node’s text.
• Hyperlinks: this needs to be customisable, either by underlining the text or by linking an image, not just the tiny red arrow.
• Nodes that have children: currently shown by a small rounded circle - this needs to be far clearer.
• Icons - again should be able to be placed left or right of a node’s content.
• Local links (local to the .mm’s file location) currently do not work unless the map is on a server.

A fairly useful userguide can be found at: fb.stikipad.com.

After discussing code coverage with several colleagues recently, and the use of various tools (Clover, Jester - more test validity/mutation testing than coverage), I have since found out that my personal editor of choice, IntelliJ Idea has had some built in support for running code coverage (on a line by line basis) for unit tests using its own built in engine (based on the open source EMMA toolkit). This isn’t without its issues however.

For the uninitiated, Code coverage refers to a software engineering technique whereby you track quality and comprehensiveness of your tests by determining simple metrics like the percentage of {classes, methods, lines, etc} that got executed when the test suite ran. In general, line coverage answers the question, “Was this line of code executed during simulation?” (which is what IntelliJ attempts to show).
You can access code coverage by selecting Run | Edit Configurations (Shift + Alt + F10) through the Run/Debug Configurations dialog (where you can enable and configure).

Code coverage is automatically measured when running/debugging. Statistics on the lines covered by your unit tests are displayed in the Project View by selecting View-> Show Coverage Information or pressing Ctrl+Alt+F6 ( if your keys are set up using the default keymap - Apple key+Alt+F6 on a Mac).

Coverage is given both as a percentage against individual files listed in the Project view, and also visually alongside the code using a traffic light key (green = covered, red = not covered, yellow = partial coverage).

The integration of this feature within the IntelliJ development environment is supposed to provide two key benefits:

• low overhead - because IntelliJ knows the structure of your project, it can calculate statistics based on compiled code, allowing for low run-time overhead as compared with using an external tool.
• On the fly visual coverage info - by comparing new code against a version of the file when coverage was last run, the traffic light indicators in the editor window automatically change as you type. The project view statistics are only updated when you run coverage (run/debug).

At first glance, this looks like an excellent way of making sure you are writing sufficient tests for your code. In practice however, I found that if you selected IntelliJs “merge data with previous results” option, it cached the results after the first run, and I couldn’t get them to update subsequently. Also, if you selected a single class file to record coverage data against (as opposed to a package), you wouldn’t get coverage statistics displayed in the project view. I also found the on the fly updating of traffic light indicators to not work.
There is also an known unresolved issue which I experienced that munges the output like

EMMA: collecting runtime coverage data ...
EMMA: runtime controller started on port [47653]
raw session data merged into [/sers/lpower/ibrary/aches/ntelliJIDEA60/overage/est$FormValidatorTest.es] {in 7 ms}"

…knobbling the first letters of directories in path - this is apparently on the display of the path only.

So all in all, it seems to work, but in a limited respect.

Of course if you were doing TDD (test driven development - i.e. writing tests FIRST) then there wouldn’t be so much of a need for tools like this, but they do act as a valuable sanity check.

Commercial tools like Clover look like they cover more feature-wise and come with fully integrated plugins that hook into IntelliJ and other IDEs. If you do want reporting, you could always try EMMA on its own - its free and open source, and apparently supports several report types: (plain text, HTML, XML). All report types support drill-down, to a user-controlled detail depth. The HTML report even supports source code linking (see EMMA sample report for an example).

When one is working on a project that are a product of several developers, unit test coverage is always likely to vary based on personal development practices, so running code coverage tools looks to be a good way to see quite what is being tested and what is/isn’t partially covered.

In my opinion, the use of metrics should be seen as a useful tool and pointer to guide improving tests for developers, rather than the be-all-and-end-all of test reporting used by non-technical management. It would be easy for someone not familiar with using such a tool to assume that 100% coverage is the ideal, when in fact it is the opposite - you get a lot less quality improvement for the cost of time spent to achieve such “perfection”, and relying only on such data could lead one astray.

The metric isn’t that important - an experienced developer will look at the generated coverage statistics for pointers, drill down a bit into their code, look at the “red” areas, and figure out which, if any, areas of the product were left somewhat under-tested.

Front end developers using anything in addition to Java, such as a framework (which may have functionality coded in its own idioms), must also make sure testing takes into account this additional functionality, which would not be reported by code coverage tools.

For further information on IntelliJ buit-in code coverage and some nice screenshots see IntelliJ’s blog and EMMA on Sourceforge.

This is a basic explanation on how to set up VoIP at home because there are a number of different configurations possible using a variety of kit. First, I need to explain some terminology:

• PSTN - Public Switched Telephone System. This is the ordinary public telephone system.
• DECT. This is the technology behind the wireless telephones that are in common use within homes. It consists of a base station that connects to the PSTN and one or more DECT phones that are registered with that base station.
• FXS. This is the name for the telephone socket on a piece of kit into which you plug a handset, a DECT base station, a fax machine and so on.
• FXO. This is the name for the telephone socket on a piece of kit that connects to the telephone provider’s socket. In other words, if you want some kit to connect to an existing PSTN line then you need one of these in it.

VoIP provider

There are two things you need to make this work:

As well as an ADSL (broadband) or cable Internet connection, you also need a VoIP provider in order to make this work. That is a company who will route your VoIP calls for you and provide interconnection to the PSTN for both incoming and outgoing calls.

VoIP providers come in three flavours:

1. Closed network using proprietary technology. Such as Skype. You can connect to the PSTN through them but not directly to other VoIP providers.
2. Closed network using open standards. Such as Vonage. They use industry standard technology like SIP so you can use different software and hardware to connect to them. But again you can connect to the PSTN through them but not directly to other VoIP providers.
3. Open(ish) network using open standards. Such as Sipgate or Gradwell. Through them you can also call subscribers to other VoIP networks and the calls are free of charge.

Option 1 - Existing phone with only a VoIP provider

This is the configuration that many manufacturers assume we want to use, though I doubt that many of us actually do. It works by adding a VoIP adapter in between your existing PSTN phone and your broadband modem. All calls then go out to your VoIP provider over your broadband connection. If you want access to the PSTN (incoming or outgoing) then your VoIP provider does that.

However you normally cannot do 999 calls or can you reach premium rate services. There are also limitations on whether or not you can move your existing telephone to a VoIP provider.
The setup looks like this:

Option 2 - Existing phone with VoIP adapter and retaining PSTN line

It is perfectly possible to retain your existing PSTN line and use just one phone to access both lines, you just need a VoIP adapter that also has an FXO port to plug into the PSTN socket. This gives you the best of both worlds.

The only real problem with this setup is choosing what calls go down what line. Some of the adapters are very basic in the functionality they provide. Another tip is to make sure any VoIP adapter you buy has a PSTN failsafe or similar. This ensures that you can get to the PSTN through the adapter even if the power to it fails.

This setup looks like this:

If you have a DECT phone then the setup will look much the same:

Of course you may be unlucky enough to have your PSTN socket and your ADSL modem in different rooms, in which case some VoIP adapters can use a WiFi dongle to access the ADSL modem. I only know of one, which is the Linksys WPB54G. This setup looks like this:

Option 3 - New hybrid DECT phone retaining existing PSTN line

You may wish to throw caution to the wind and buy a completely new phone system that does both PSTN and VoIP. One such example is the Siemens Gigaset C460IP (called the C450IP on Siemens website, C460IP is the UK-specific model) which is also a DECT phone.

This setup does not require and adapter since the DECT base station has that functionality built-in. It looks like this:

Option 4 - New WiFi phone with only a VoIP provider

Finally we come full circle to the most Internet way of doing things that uses the least amount of kit. This is using a WiFi telephone that connects directly with your WiFi ADSL modem and on to your VoIP provider. As mentioned above, there are potentially some issues with relying solely on a VoIP provider.

This setup looks like this:

That’s all for this post but we hope to have some future posts that review VoIP adapters and a few Hybrid or WiFi phones.

I recently moved some test code written in PL/SQL from one database (Solaris, Oracle 10.1, US7ASCII) to another (Linux, Oracle 10.2, UTF8). This revealed a SQL trick that doesn’t work quite as expected on the new platform, almost certainly due to the change in Oracle version. The code in question is:

SELECT 1
FROM DUAL
CONNECT BY ROWNUM <= 7

This returns 8 rows on the first database and 7 on the second. I suspect that this is due to a change in the point that ROWNUM is incremented in the processing of the query. As I said, this was only in test code, but I guess that the lesson here is that if you rely on unsupported SQL tricks then don’t be surprised if their behaviour changes.