JavaFX for GNU/Linux has arrived

Finally, the time has come: JavaFX is now supported on both GNU/Linux and Solaris.

It’s not really advertised, though, so h Here’s how to get it:

• Go to the JavaFX website.
• Click the Download now button. Yes, the one that reads JavaFX 1.1 SDK.
• Click the JavaFX 1.1.1 1.2 SDK option, and click Download.
• You’ll be prompted to download javafx_sdk-1_2-linux-i586.sh. Save it somewhere convenient.
• Make the downloaded file executable with chmod + x
• Run the shell script with ./javafx_sdk-1_2-linux-i586.sh
• Page through the annoying legal stuff by pressing Space repeatedly. At the end, type yes.
• You now have a javafx-sdk1.2 directory that you can play with.

Enjoy!

Oh, and in case you have some JavaFX code from pre-1.2 versions, here’s how to migrate it.

Update: There is also a new Eclipse plugin. Binaries only, the source will have to wait until it gets transferred to eclipse.org.

Supporting multiple versions of a data model

As an application evolves, its data model often does too. If you control both, this usually isn’t a problem. However, sometimes your power to change the data model is restricted. This happens, for instance, when the data model is published, and others may depend on it. An extreme case of this is when the data model is defined by another organization as, for example, with S1000D.

Having no absolute control over the data model isn’t much of a problem if you can leave one version behind completely, and move on to the next. But often you won’t be so lucky. I know I’m not: we need to support both S1000D 3.0 and 4.0.

There’s different ways in which you can support multiple data model versions. The one I’m concerned with here, is when your application needs to support multiple data models at the same time with the same code. That leaves out alternatives like having multiple branches of your code for the different data model versions.

One trick that can come to the rescue here is the Once And Only Once rule (also called the DRY principle). When applied to creating instances, this leads to the Factory pattern. If you have all your instances created by a factory, then there’s only one place where you need to decide which class (e.g. the 3.0 or 4.0 version) to instantiate. If those decisions are similar for all the classes in your model, then you could even extract them into a common base class for your factories.

Most of the time, the different versions of the data model will share a lot of similarities. It is tempting to extract those into a common base class. For example, in S1000D there is a type called descriptive data module, and you could derive DescriptiveDataModule30 and DescriptiveDataModule40 from DecriptiveDataModule.

But when the objects in your data model have inheritance relationships themselves, that can get ugly very fast. For instance, a descriptive data module is one of many kinds of data modules, and these data modules share a lot of characteristics. So in code, DescriptiveDataModule would descend from DataModule, and both would have aspects that differ in the 3.0 and 4.0 versions. This spells trouble.

Therefore, it is usually better to use composition instead. So DataModule would have a reference to a DataModuleIssue (where “issue” is used in the sense of the various issues of the S1000D specification, i.e. what I’ve been calling “versions” so far), which the DescriptiveDataModule would inherit. The factory would inject either a DescriptiveDataModuleIssue30 or a DescriptiveDataModuleIssue40 into the DescriptiveDataModule, where DescriptiveDataModuleIssue30 would descend from DataModuleIssue30, and DescriptiveDataModuleIssue40 from DataModuleIssue40.

The idea is to make the Issue classes very bare, dealing only with the stuff that differs between issues, so there is no need for a common base class (although both do implement the same interface). The things that are the same in all issues, go into the core model objects (DescriptiveDataModule and DataModule in our example).

Kanban

Lately, I’ve seen a lot of discussions on Kanban. For those of you who, like me, want to know what all that fuss is about, I collected a couple of links that I will try to merge into a coherent whole below.

So what exactly is Kanban? Literally, it means “visual card”, but that’s not very helpful. This introduction explains that Kanban revolves around a board that visualizes the software development flow.

In fact, flow is a very important concept here. Kanban is a pull system, in which Minimal Marketable Features (MMFs) flow through the development stages when there is capacity available. This contrasts with most Agile methods that push work items into iterations. Also, note that for most Agile methods, those work items (e.g. User Stories) would be smaller than MMFs.

The other big point is that Kanban limits Work In Progress (i.e. the number of MMFs per development stage). This naturally exposes the bottleneck(s) in the flow.

This leads us nicely to the main reason to use Kanban: to improve your software development process. Other Agile methods deal with process improvement as well, but Kanban is different from e.g. Scrum.

So, if all this sounds cool and you want to give Kanban a shot, then apparently this is how you should get started. If you do, then you may see these effects. Also, make sure to get into a Kanban state of mind.

Update: here is a great compilation of Kanban resources.

Replacing the word “test”

Elisabeth Hendrickson wants to get rid of the word “test”, as it can mean two different things, which she labels “Check” and “Explore”.

I very much agree with the fact that there are two entirely different aspects to testing. “Checking” is when you get a warm fuzzy feeling when the bar gets green. You perform an experiment and if you get a positive result then you know that all is well.

“Exploring” is different in that you don’t get a warm fuzzy feeling on “green”. In other words, if the experiment produces a positive result, you’re not done yet. You need to look further, until you find a negative result. Only then will you have learned something. And if you spend some time exploring, and find no problems, then there’s always that nagging feeling: is there really nothing to find, or did I just not look hard enough?

So it seems I agree with Elisabeth. Then why this blog post?

Like Elisabeth, I think that words matter. She’s right to want to replace the word “test”. I just disagree with the replacements. “Check” has way too many meanings, and the definitions of “explore” don’t seem to catch what is meant well enough for my taste.

So I’d like to propose an alternative from the world of science: “verify” and “falsify”. Automated tests verify that the software behaves as expected, while exploratory testing falsifies both the expectations and the completeness of the test suite.

What do you think?