Slightly amusing

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: The unity of action : a play should have one main action that it follows, with no or few subplots. 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. 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. :)

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...

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...

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 ...

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 invol...

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.