The occasional speaker

The JavaOne has ended and it was both under- and overwhelming. But on a more personal note I was not satisfied with how my talk went. Being an occasional speaker, I naturally am a bit nervous at the beginning, but somewhere along the line that usually goes away. This means I get into ‘the zone’, and feel inspired by the subject I am talking about.

However, this was not the case during my talk at the JavaOne; it kept dragging a bit, never gaining the momentum I’m used to. And I have been wondering about the reason; I’ve done the talk more often, so it is not that I don’t know what to tell on a given slide. It just didn’t… Take off.

So different from yesterday, when I was in Utrecht, giving a talk about automated testing. The setting there was… Cozy. Informal. I wasn’t even really nervous at the beginning, even though it was the first time I did the lecture, and I wasn’t sure if I had enough slides, or too many. Certainly the deck was way less pruned and polished than the JavaOne’s, but it took mere seconds to get into the groove.

Keylane

So apparently I’m more sensitive to the setting than thought I was. The JavaOne conference rooms were not inspiring (read the previous post), and the speaker had to stand on a small stage, behind a small desk, above the people in the room. Totally disconnected. And people were constantly on their phones (no blame, I did it as well as an attendee).

JavaOne

I’m not comfortable up there. Put me in a room with inconvenient pillars and brightly colored chairs, and off I go. Exactly the reason why I chose the Edwardian Hotel in San Fransisco, instead of one of the larger downtown ones.

Advertisements

To comment or not, that is the question

Recently I worked my way through the “Effective Unit Testing” book. A nice read, nothing too complex or difficult, but it is always good to read the opinions of someone who really put some effort into a certain topic. One point was the question if code should contain comments or not, mainly because comments can have a negative impact because they can be incorrect and misleading. So the proposed solution was to write code that does not require comments at all; write “self documenting code”.

In my current project I run into similar situations on a daily basis; my idea on how code should look differs from the most of the other developers. I see people writing tons of code without a single comment in them and declare them “self documenting”. The problem is that for some reason I do not seem to be able to get comfortable with that code, and I’m really starting to wonder if I’m getting old, and am missing out on the “new and improved way” of doing things. But I’m not one to accept that without an effort, so I gave it a shot.

Below is an example of a simple unit test. Please do not spent too much time on this, because it is the “before” example. But the test is ok, there is nothing technically wrong with it, it just can be written better.

    public void testVerifyGroupThenAddClient() throws ValidateException {
        // group starts off not verified
        GroupCare assertGroupCare = groupCareManager.findByObjectId(groupCare.getObjectId());
        assertNull(assertGroupCare.getVerifiedAt());

        // add client
        groupCareManager.addClient(groupCare, client.getData(), groupActivity.getData(), user);

        // group is not yet verified
        assertGroupCare = groupCareManager.findByObjectId(groupCare.getObjectId());
        assertNull(assertGroupCare.getVerifiedAt());

        // verify the group
        groupCareManager.verifyGroupCare(user, groupCare);

        // assert that the group is verified
        assertGroupCare = groupCareManager.findByObjectId(groupCare.getObjectId());
        assertNotNull(assertGroupCare.getVerifiedAt());

        // add new client
        groupCareManager.addClient(groupCare, client2.getData(), groupActivity.getData(), user);

        // group is no longer verified
        assertGroupCare = groupCareManager.findByObjectId(groupCare.getObjectId());
        assertNull(assertGroupCare.getVerifiedAt());
    }

Continue reading “To comment or not, that is the question”

Stand alone business model with Activiti, Eclipselink and unit tests on PostgreSQL

Somewhere around 2007 – 2008 I was setting up a new project which had a business model (BM) as the central component. The business model I envisioned had a three layered structure: an AbstractBean handling all the Java bean plumbing, a from-the-database-reverse-engineered class with the properties (setters and getters), and finally a class containing the custom code on top. I wanted to settle on a standard (JPA) and tried using Hibernate at first, but it could not support this layered structure back then, so I ended up using Eclipselink (and with great satisfaction ever since, I must add).

I also have never been a fan of pure application servers (EJBs), so this BM is compiled into a single jar (already postprocessed by Eclipselink), and simply included in all kinds of applications; a client-server Swing application, a REST interface to support an Android app, several im- and exporters for EDIFACT, emails, XML, and of course a nice in-house webapp. Not having an additional single point of failure (besides the database) is very pleasing and keeps the overall architecture much more simple. Continue reading “Stand alone business model with Activiti, Eclipselink and unit tests on PostgreSQL”