Everyone knows that auto­mated tests are use­ful. When you are just start­ing a new pro­ject, it is easy to include all sorts of auto­mated test­ing dir­ectly from the start. You can take all sorts of things into account: auto­matic unit tests, auto­matic user inter­face tests, or even con­tinu­ous integ­ra­tion with auto­matic tests.

But what if you have an exist­ing code base that you wish to add auto­matic test­ing to? Chances are that you can­not just do extens­ive changes to your cur­rent code base, just to add auto­mated tests. Where to start? My advice: start small.

This art­icle will show you how to add auto­mated unit tests to your jar builds. This is fairly simple, and can be done without mov­ing your entire code base around.

Continue read­ing

JavaFX 2 is an amaz­ing new plat­form that allows you to build cli­ent applic­a­tions eas­ily. I am by no means an expert yet, but I love what I have seen so far. Here are a few char­ac­ter­ist­ics of JavaFX that I like in particular.

  • Specify your lay­out in Java-code, or in a seper­ate so called FXML–file. The sep­ar­ate file allows you to keep the actual lay­out out of your code, so you can focus on functionality.
  • Specify a con­trol­ler in the same FXML–file, keep­ing your code clean.
  • Style your lay­out using CSS, again keep­ing your code clean.
  • Easily build your own com­pon­ents, again using either Java-code or FXML.

Continue read­ing

Recently I ran into a very pecu­liar bug. The bug would only show in Chrome and Safari, and would cause all JavaScript on a page to stop work­ing. In all other browsers, everything was just fine. The only thing I had to go on, was a kind of cryptic error message:

Refused to execute a JavaScript script. Source code of script found within request.

At first, I thought that this meant that the script that the browser refused to run, could be found inside the request. A strange place to put addi­tional error inform­a­tion, I thought, but I went look­ing for the script nontheless.

Continue read­ing

When read­ing or writ­ing XML files in Java, chances are that you are using classes from the pack­age org.w3c.dom which comes bundled with the Java-interpreter. I found these classes very cum­ber­some to use for a small pro­ject. Many calls to factory-methods are needed before it is even pos­sible to start using an XML file. Debugging is even worse since all you get to see are undoc­u­mented instances of imple­ment­a­tions of the inter­faces that are in the org.w3c.dom package.

My atten­tion was recently drawn to another XML parser: NanoXML/Lite. For small applic­a­tions that do not need advanced fea­tures, like DTD val­id­a­tion, NanoXML/Lite provides suf­fi­cient func­tion­al­ity and is very easy to use. For more advanced applic­a­tions there is another parser avail­able, NanoXML/Java, which I will not dis­cuss since I have not used it.

Continue read­ing

Recently I have taken the Functional Programming Principles in Scala class on Coursera to refresh my know­ledge on func­tional pro­gram­ming and to learn a new pro­gram­ming lan­guage. Scala is an object-oriented func­tional pro­gram­ming lan­guage that com­piles into Java byte­code, which allows it to run on the JVM. Because of this, it is pos­sible to call Scala code from other lan­guages that also run on the JVM, and vice versa.

One pat­tern that kept pop­ping up dur­ing the course, was the usage of an accu­mu­lator to store inter­me­di­ate res­ults when mak­ing recurs­ive calls. This pat­tern has always felt a bit odd to me. It feels like a loop that puts some­thing on a list or updates a res­ult for every iter­a­tion, only the recurs­ive approach seems less clear. Let us take a closer look at this phenomenon.

Continue read­ing