Support for image acquisition devices in Flex/Air

I would like to see support for image acquisition devices in Flex/Air. Currently there is no such support for image acquisition devices, like scanners that operate via the TWAIN API. However you can use sockets in combination with a Java application but this is far from an ideal scenario.

I filed an issue request which you can see at https://bugs.adobe.com/jira/browse/SDK-16239. Please vote on this issue and we may see support for image acquisition devices in the future.

Open Space sessions

Upcoming august 2008 me and a colleague organize the first internal Open Space session for our company. Although the concept is not new, Open Space sessions date back from 1985, they gained momentum at Java Polis 2007. Here, Bruce Eckel held an excellent presentation about Open Space sessions.

I think knowledge and/or experience sharing is a key point in our profession as a software developer/engineer/architect etc. We constantly seek new and effective methods to share our knowledge. The most effective method for sharing knowledge is the one with the best cost/benefit tradeoffs. Costs have the form of the amount of time invested to prepare a session and the benefit is the amount of knowledge and experience shared amongst other colleagues.

The cost/benefit ratio of a traditional session/presentation is not very high. Usually, the preparation of a session costs far more than the benefit it gets. When this session is held multiple times, the cost/benefit ratio gets better. The format of a traditional session is of a very static nature. You have one or more presenters and a whole lot of attendees. The attendees do not know if the session is of any value for them. For some this may be the case and for others this may be not. Also, the attendees usually are not in the position to determine the subjects of the session.

Open Space sessions try to address these shortcomings. In an Open Space session the subject is determined by the attendees. The attendees seek a space where they can discuss/contribute and learn about the subject. One thing to remember in an open space session is the 'Law of the two feet'. This means: if you feel you do not learn anything or cannot contribute something meaningful to the session, use your two feet and seek another session which may interest you. This way you and the other attendees get the most value from a session.

I will post our experiences and the way we organize our Open Space session in the next month. Stay tuned...

More information about Open Space sessions can be found at:

• Open Space world


• Wikipedia

JavaFX and Air: a brief comparison

Paul Bakker has wrote an excellent post of our first impressions when developing the FolderVisualizer. Check it out and also don't forget to install and try both applications!

Efficiently reclaim you disk space

We started a new project on Google code named FolderVisualizer.

The application is able to visualize the relative size of files and folders below a given directory. With this tool it is easy to see which files and folders take up the most disk space which you then can use to efficiently clean your hard drive. See Olav Maassen's post about efficiency :).

Although such tool already exists, it is fun to see how different implementations compare to each other. At the moment, the following technologies are planned:

• A Groovy implementation with a command line client


• A Java implementation with a command line client


• A JavaFX client


• An Adobe AIR client

It is nice to see that the JavaFX client can make use of the Groovy implementation of the visualizer algorithm. For the AIR implementation we have to rewrite the algorithm in Action Script.

The project can be found here.

Once again: Assumptions are the mother of all fuck ups!

Even the most obvious assumptions aren't all that obvious. Who believes that a software tester tests a new release in the production environment! This has actually happened. When a new release was installed in the acceptance environment, the acceptance tester was signalled.

When he finished testing, a whole list of issues was reported via the issues tracker. We had absolutely no idea of what was going on until we asked for the URL and user accounts with which the tester had tested. The URL that was used was actually the URL of the production environment! After that it was totally clear to us what went wrong.

Lesson learned: even if your assumption is obvious, do not assume!

Code review

During a code review I stumbled accross the following code:

SomeObject someObject; 
if(o instanceof SomeObject) {
 someObject = (SomeObject)o;
} else {
 throw new ClassCastException("Cannot cast=[" + o.getClass() + "] to expected class=["+ SomeObject.class + "]");
}

Obviously the throwing of the ClassCastException is redundant. You can replace the above code with the following statement:

SomeObject someObject = (SomeObject)o; 

This statement doas semantically the exact same thing! At runtime a ClassCastException is thrown when object o cannot be cast to SomeObject. By looking at the stacktrace you can figure out where in your code things go wrong.

Moral of this story: use code reviews to improve the quality of your code.

Using Spring elements and attributes in your custom namespace

With Spring 2 it is possible to define your own namespace and have your own custom elements which you can use in the application context. Sometimes, allthough I do not promote this, you want to use Spring elements and attributes on your custom elements. For example: suppose I have a custom element named "foo:myCustomFooElement" with one attribute named "text". By default, you can't write something like this:

< foo:mycustomfooelement text="test" abstract="true">
   < property name="property" value="value">
< /foo:myCustomFooElement>

This is because the property element and abstract attribute are not defined in your xsd which describes your custom element. Following is the source of a sample application I wrote to demonstrate the use of Spring properties and attributes on custom elements. The reason I do not promote this, is because you will loose the encapsulation of implementation details which your custom element hides. So use it with care.

public class Foo {
    // This property gets injected by our custom FooParser
    private String text;

    // This property gets set by using Spring's < property> element
    private Bar bar;

    // getters and setters omitted

}

We will write a custom element for the Foo class.

public class Bar {
    private int count;

        // getter and setters omitted
}

Bar is just a regular class that gets injected in Foo. Below is the xsd I wrote to define myCustomFooElement:

< ?xml version="1.0" encoding="UTF-8"?>
< xsd:schema xmlns="http://www.mynamespace.com/foo"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"
    xmlns:beans="http://www.springframework.org/schema/beans"
    targetNamespace="http://www.mynamespace.com/foo"
    elementFormDefault="qualified" attributeFormDefault="unqualified">

    < xsd:import
        schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd"
        namespace="http://www.springframework.org/schema/beans" />

    < xsd:element name="myCustomFooElement">
        < xsd:complextype>
            < xsd:complexcontent>
                < xsd:extension base="beans:identifiedType">
                    <!-- Here we re-use Spring elements and attributes -->
                    < xsd:group ref="beans:beanElements">
                    < xsd:attributegroup ref="beans:beanAttributes">
                    < xsd:attribute name="text" type="xsd:string"
                        use="required" />
                < /xsd:extension>
            < /xsd:complexContent>
        < /xsd:complexType>
    < /xsd:element>
< /xsd:schema>

The XML file containing the bean definitions looks like this:

< beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:foo="http://www.mynamespace.com/foo"
    xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
    http://www.mynamespace.com/foo http://www.mynamespace.com/foo/foo.xsd">
   
    < foo:mycustomfooelement id="foo" text="test" init="true">
        <!-- Here we use a Spring property element inside our custom element -->
        < property name="bar">
            < bean class="nl.sample.customnamespace.Bar">
                < property name="count" value="100">
            < /bean>
        < /property>
    < /foo:myCustomFooElement>
< /beans>

To parse the myCustomFooElement we must create a namespacehandler and register a beandefinition parser like this:

public class FooNameSpaceHandler extends NamespaceHandlerSupport {
    private static final String NAME_CUSTOM_FOO_ELEMENT = "myCustomFooElement";

    public void init() {
        registerBeanDefinitionParser(NAME_CUSTOM_FOO_ELEMENT, new FooParser());
    }

    class FooParser extends AbstractBeanDefinitionParser  {
        @Override
        protected AbstractBeanDefinition parseInternal(Element element, ParserContext parserContext) {
            // Here we parse the Spring elements such as < property>
            BeanDefinitionHolder holder = parserContext.getDelegate().parseBeanDefinitionElement(element);
            BeanDefinition bd = holder.getBeanDefinition();
            bd.setBeanClassName(Foo.class.getName());
           
            // Here we parse our custom attributes
            String text = element.getAttribute("text");
            bd.getPropertyValues().addPropertyValue("text", text);
            parserContext.getRegistry().registerBeanDefinition(NAME_CUSTOM_FOO_ELEMENT, bd);
            return (AbstractBeanDefinition) bd;
        }
    }
}

Don't forget to register the namespacehandler in a file called spring.handlers in the META-INF directory. The contents of de spring.handlers file looks like this:

http\://www.mynamespace.com/foo=nl.sample.customnamespace.FooNameSpaceHandler

Also, specify in the META-INF/spring.schemas file where Spring can find the foo.xsd:

http\://www.mynamespace.com/foo/foo.xsd=nl/sample/customnamespace/foo.xsd

Write a class to verify everything works:

public class Driver {
    public static void main(String[] args) {
        ClassPathXmlApplicationContext appContext = new ClassPathXmlApplicationContext("classpath:nl/sample/customnamespace/customelements.xml");
        Foo foo = (Foo) appContext.getBean("foo");
        System.out.println("foo.text = " + foo.getText());
        System.out.println("foo.bar.count = " + foo.getBar().getCount());
    }
}

Extensive documentation about extensible XML authoring can be found in the reference manual. Eriks Wiersma has also written an excellent piece on his [URL="http://erik.jteam.nl/?p=23"]blog[/URL] about implementing custom namespaces.