Wednesday, October 06, 2010

Aristotelian unities for drama unit testing

I was discussing today a recent SE-Radio episode on "The History of JUnit and the Future of Testing with Kent Beck". In this podcast he (among other stuff) mentioned something to the effect that each test case (unit test) should tell a story complete with all the parts of a good story: intro, plot and finale.

My friend could not resist and soon provided me with a following excerpt from the definition of three classical unities of drama:
Aristotelian unities or three unities are rules for drama:
  1. The unity of action: a play should have one main action that it follows, with no or few subplots.
  2. The unity of place: a play should cover a single physical space and should not attempt to compress geography, nor should the stage represent more than one place.
  3. The unity of time: the action in a play should take place over no more than 24 hours.

So, there it is. Your guidelines for writing good unit tests. :)

Monday, September 27, 2010

Developers are also users

As a software developer I care deeply about usability. And in my book, the term "usability" is more than just shiny new widgets on a shiny new website.

To me, the usability is just as much about finding the appropriate api abstractions to program against as it is about delivering the best and shiniest UI to our customers.

It is all about user experience. If you're a user of an api, the experience of using this api should be just as smooth and effortless as using the best designed desktop or web application...

Friday, June 04, 2010

Delicious wraps

Ever needed to perform some computation in another thread, and the return the result. Typically what you do is you create a Runnable, where you perform this computation, run it in the separate thread, wait for it to complete and then somehow get the value out of that runnable and return it to the caller.

In SWT, this type of pattern is quite common when you need access to some widget values from outside of Display thread:


Nothing really revolutionary in this piece of code — Since the only safe way to ask text of the widget is to ask it from the display thread, I am invoking syncExec on the text widget's display.

To access the text field itself from the anonymous runnable, I have to declare it final. Also, to be able to return the value I need to write it to a local variable retValue, which needs to be declared final as well so that I could reference it from the inner anonymous class run method body.

In order to be able to write to the retVal, I also need to declare this final variable to be an array with length 1 and use first element of the array to hold the value.

This is a bit cumbersome but quite common pattern in Java brought on by a combination of weird scoping access rules and lack of true closures in the language.

In itself, it is not all to difficult to master, but to me it has always felt somehow ... hackish and unclean. It is not an array that I want in retValue, it is the value itself. Not to mention that if I need the computation to return an array of items, I always seem to forget how exactly should I initialize the 2 dimensional array...

Enter the Wrap — a delicios form of fast food, that when prepared with fresh vegetables and just the right amount of white and well seasoned meat, will quickly sate my hunger and still make feel better about myself than when I have a burger instead...



Just take a look at this extremely simple and almost naive piece of code. It does not do almost anything except allow access to a internally stored variable. It is just a light wrapping around a tasty filling that can make your life just so much easier.

Just consider the following snippet:


This feels just so much cleaner now than hacking around with arrays that I already feel much better just by looking at it :)

Wednesday, May 12, 2010

My first deep dive into e4 application model

After some time of observing he progress of e4 application framework development and reading some fine high level documentation and fidgeting with some of its samples and creating few toy projects, I decided to dive in at the deep end so to speak and try it out with somewhat more serious and concrete project.

I am trying to implement a proof-of concept of an application that among other things needs at startup dynamically create a set of windows (one per each monitor) and go full screen with all of them.

Reading the implementation of  E4Application (I must admit it is quite an interesting and educational excercise in itself) I found that I need to define a "Lifecycle handler" and intercept "processAdditions" lifecycle event to dynamically create new windows after the model has been loaded.

At first I was struck by an apparent problem where I needed an access to a Display instance. At first I simply tried and to add it as an argument to my processAdditions method but it produced quite an ugly exception as the IEclipseContext did not hold a reference to the current/context display (the exception message could probably use a bit more intelligence when pointing at the most likely cause of the issue).

I worked around it by intercepting "postContextCreate" lifecycle event and injecting a context function that returns current thread's display if it exists (by calling Display.getCurrent()).

I could safely do that because I had the internal knowledge that the life cycle events are intercepted on the same thread as the display creation and that the display is created right at the beginning of the E4Application.start() method.

It seems to me, it would probably be better, if the display is injected into the context as part of the context creation by the E4Application instead.

The actual process of adding new MWindow instances to the model using standard EMF model factory class was quite easy from this point and I could almost fully control every aspect of all the windows. I say almost, because one attribute that was out of my reach at this point was the fullScreen toggle.

All in all, I am fairly pleased with the relative ease and flexibility, e4 provides to me. The variety of ways I can intercept the start-up sequence and initialization of my application is amazing.

At first I was kind of hesitant that I would have to use someone else's implementation of IApplication. It seemed somewhat restrictive, but after looking at the internals of an E4Application I found that I had all the necessary hooks available to me and there was hardly any reason to write my own.

Wednesday, March 24, 2010

Musings about build systems

I was just hacking the other day our somewhat horrible hairball of an ant build to try to mold it to my understanding of how a build should work when I had a sort of an epiphany about why on earth I dislike Ant so much.

Apart from the syntax (and I think it is universally agreed by now, that XML is a horrible, horrible language for scripting like tasks), what hit me is that while ant is okay for simple one-shot single project builds, it really falls on it's knees as soon as you start building complex modularized systems where you need some sort of dependency management.

Now, before I go on, I must mention that I have heard of alternatives like make, Maven, Buckminster, b3 and the ilk, but I really don't know much about any of those (well, by the time I started to write this piece, I had taken a peek at Buckminster). I am not really what you would call a "build person" - I'm using Ant, because it's what comes with most of the projects I've been involved in...

For simple and mostly declarative stuff, Ant is great. It's easy as long as you don't have to do any of the "smart" stuff and even with some of the smart stuff, it works fine.

Where I run into the wall is where one build file goes out and mucks around with something from another build. Like for example taking a jar out of another build and putting it on a classpath or offering it up for some deployment operation for copying. The way you do this today with ant, is you call a target from another build (and, my god, is the syntax cumbersome there if all you want is to call a specific target in a specific ant file) and after that task finishes point a property at the location of a resource that task was supposed to produce. And cross your fingers, that you've got it all right and the other ant file has not been changed to put that resource actually in some other place or saved with another (arguably better) name.

It all kind of messy and yucky and brittle in so many ways, that I just shudder every time I have to think about diving into one of those ant build files...

So I was hacking away at yet another ant build involving many dependencies as I suddenly realized, that what I was actually looking for was a sort of interaction that I've come to expect from a programming language.

The thing I needed, was a build scripting model where each build script is an equivalent of an object in a programming language, it's properties are ... well, properties of the build script object and targets are methods on that object that always return some sort of resource set structure.

In this fantasy build language of mine, a build target could call to other build targets and get a set of resources they've produced as a return value to be used as it pleases. These calls could be chained together, optionally applying various filters to the the resultsets of one build step before passing them to the next.

The syntax of the build script would have to be lightweight (no XML here), easy to follow, clean and mostly declarative with a touch of functional features for performing some of the advanced operations.

So far, the closest thing I have seen to match my imaginary build scripting language is b3, but that one is not quite ready yet. In some ways Buckminster's model also matches what I had in mind, but that is negated by the fact that it uses XML as an underlying language for describing the components, queries and it feels a bit cumbersome with all those separate types of artifacts thrown around...

Wednesday, February 17, 2010

Optional iterators right now...

Monads in terms of Java has been the topic that has caught my attention of late and while some of the articles out there have almost managed to penetrate my rather thick skull — I can almost see the potential benefits I can reap in terms of being able to design clean and easy to use apis — I still feel I am missing some crucial piece of information before the whole puzzle starts to make sense...

Oh well — maybe it's best to simply let it settle and let these ideas mature a little in my head (I am sometimes slow, like this).

Meanwhile I am getting kind of tired of all the boilerplate I have to write to get around potential NPE traps with this new and shiny for iteration syntax introduced in Java 5. Not that there is a lot to write, but it is kind of tedious and introduces something, that even has a nice buzzing name for it — "accidental complexity" into otherwise quite straightforward application logic.