Dreaming of Software

Today I had the nasty little problem that one Windows-Application I was using constantly refused to rezise its window properly. It was only all or nothing, meaning the window was either maximized to the full size of the desktop or minimized to the taskbar. Somehow it was not possible to have it at a “normal” size, so that it can be moved around or being used for screenshots.

It was not too easy to google for this kind of problem, but luckily I came accross the following tool which was the solution to my problem: Auto Window Manager

Here you can choose any running application and give it a new size. And the best thing is: This size is used even after restarting the application. Really a great tool and it might be good to keep its existence in mind even if you have no such problems right away,

Selenium is a very nice and powerful tool to enable automated tests for web applications. This is especially true when using the Firefox PlugIn Selenium IDE, which allows to record testcases in Firefox and then exporting those testcases into various formats, for example Java JUnit testcases.

Today now I was working on some Selenium Tests, but I could not manage to start them. Already when launching Firefox the tests where hanging and in the end the Selenium Server was throwing exceptions:

java.lang.RuntimeException: Firefox refused shutdown while preparing a profile at org.openqa.selenium.server.browserlaunchers.FirefoxChromeLauncher.waitForFullProfileToBeCreated(FirefoxChromeLauncher.java:267)

org.openqa.selenium.server.browserlaunchers.FirefoxChromeLauncher
.waitForFullProfileToBeCreated(FirefoxChromeLauncher.java:267)

…

And in the end was complaining about parent.lock file that could not be deleted. Furthermore I noticed that there have been always some Firefox processes left in the process list, even though no Firefox application was visible any more.

It took me more or less the half day to figure out the solution for this nasty problem including the attempt to use a custom Firefox profile. In the end I found the following easy solution more or less accidently:

I had to upgrade the Selenium JAR-Files I have been using on the server- and on the client-side. So I removed all Selenium-related Firefox PlugIns. Then I downloaded the following files from the Selenium download page:

• Selenium IDE June 30, 2009 1.0.2: Can be installed directly as a PlugIn when downloaded using Firefox
• Selenium Core June 10, 2009 1.0.1: Extract the selenium server JAR (when using Java) with version “1.0.1″
• Selenium RC June 10, 2009 1.0.1: Exract the selenium client JAR (when using Java) with version “1.0.1″

Afterwards ensure to restart the server using the new server JAR and compile your client application using the new client side Selenium JAR. At least in my case afterwards all problems have been vanished and Selenium worked again like a charm :).

After a long time with no activities here I at least managed to update the design and I can refer to an - hopefully interesting - article I have been publishing today on our company blog. It is an introduction to Agile Testing and - if time allows - the beginning of a small series of blog posts on this topic over there. The plan is to have a closer look into some of the available tools around agile testing, probably FitNesse and Robot Framework. Another interesting topic will be the usage of those tools in continuous integration environments. Let’s see …

Nothing too fancy here, but I thought I write down my experiences when installing JBoss on Mac OS 10.5.7. My starting point was the following article from the Apple developer site, but I am having the feeling that those pages are not really up-to-date. Please note that those instructions should only be applied to the “non-server” versions of Mac OS as the server-version has JBoss installed already.

Before any installation the JBoss software needs to be downloaded first. I would say the best starting point for downloading JBoss is here.

I am choosing the most recent stable version, which is at the time of this blog post JBoss 5.0.1.GA. On the following download page I am selecting jboss-5.0.1.GA-jdk6.zip. As typical the file is saved to the Mac OS Download folder. While the download is running it is a good time to start a terminal window as now we get our hands dirty. (I was asking myself if I should explain how to start a terminal window on the Mac, but then I thought that people who do not know that will anyway not survive the rest of these instructions, so I skipped it ;).)

First of all we need a directory to extract the JBoss files in. Thus execute:

bash-3.2$ cd /usr/local
bash-3.2$ sudo mkdir jboss

Your prompt might look different and you need to give your superuser password when executing the mkdir-command. This password should be the one you are using when logging in to your Mac.

Once the download is finished we copy the downloaded file to the newly created directory and extract it there. Of course the path to the downloaded file will vary as you have to give your own user name there instead of mine. Afterwards we are cleaning up by removing the ZIP-file again as it was anyway only a copy from the download-folder.

bash-3.2$ cd /usr/local/jboss
bash-3.2$ sudo cp /Users/thomasjaspers/Downloads/jboss-5.0.1.GA-jdk6.zip .
bash-3.2$ sudo unzip /Users/thomasjaspers/Downloads/jboss-5.0.1.GA-jdk6.zip
bash-3.2$ sudo rm jboss-5.0.1.GA-jdk6.zip

Ok, in principle nothing should prevent us now from starting up the JBoss server right away. So let’s give it a try:

bash-3.2$ cd /usr/local/jboss/jboss-5.0.1.GA/bin
bash-3.2$ sudo ./run.sh

The following error is not really nice, but does not look too severe:

./run.sh: line 89: ulimit: open files: cannot modify limit: Invalid argument
run.sh: Could not set maximum file descriptor limit: unlimited

But the following exception does not look too promising and definitly needs some attention:

21:35:29,286 WARN [ClassLoaderManager] Unexpected error during load of:org.jboss.resource.metadata.repository.DefaultJCAMetaDataRepository
java.lang.UnsupportedClassVersionError: Bad version number in .class file
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:675)
at org.jboss.classloader.spi.base.BaseClassLoader.access$200(BaseClassLoader.java:63)
at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:546)
at org.jboss.classloader.spi.base.BaseClassLoader$2.run(BaseClassLoader.java:506)

The “jdk6″ in the name of the JBoss ZIP-file might be a good hint here already as executing “java -version” shows that I am only running Java 1.5 still:

java version “1.5.0_16″
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b06-284)
Java HotSpot(TM) Client VM (build 1.5.0_16-133, mixed mode, sharing)

It seems to be time for some update so I am downloading Java SE6 for Mac OS from the Apple Support Pages. As this is downloaded as an Mac OS DMG package the installation can be done straightforward by opening the downloaded file. Unfortunetly this does not do the complete job as afterwards still the previous Java version is set to be the default one. So we need to take a closer look into this directory: /System/Library/Frameworks/JavaVM.framework/Versions
Here we can see that the softlink for the “Current” version still points to some old Java release.

lrwxr-xr-x 1 root wheel 5 5 Okt 2008 1.3 -> 1.3.1
drwxr-xr-x 3 root wheel 102 14 Jan 2008 1.3.1
lrwxr-xr-x 1 root wheel 5 5 Okt 2008 1.4 -> 1.4.2
lrwxr-xr-x 1 root wheel 3 11 Sep 2008 1.4.1 -> 1.4
drwxr-xr-x 8 root wheel 272 21 Feb 2008 1.4.2
lrwxr-xr-x 1 root wheel 5 5 Okt 2008 1.5 -> 1.5.0
drwxr-xr-x 8 root wheel 272 21 Feb 2008 1.5.0
lrwxr-xr-x 1 root wheel 5 5 Okt 2008 1.6 -> 1.6.0
drwxr-xr-x 8 root wheel 272 11 Sep 2008 1.6.0
drwxr-xr-x 8 root wheel 272 5 Okt 2008 A
lrwxr-xr-x 1 root wheel 1 5 Okt 2008 Current -> A
lrwxr-xr-x 1 root wheel 3 5 Okt 2008 CurrentJDK -> 1.5

So let’s change this one and check again:

bash-3.2$ sudo rm Current
bash-3.2$ sudo ln -s 1.6.0 Current
bash-3.2$ java -version

And now we are getting what we want:

Java version “1.6.0_07″
Java(TM) SE Runtime Environment (build 1.6.0_07-b06-153)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_07-b06-57, mixed mode)

With this it is time to give the JBoss startup another try … and now the startup works nicely without any Java exceptions and we see the server running like a charm :):
But there is still the other problem left, as it is simply not nice that the system is complaining on every startup on this: “/run.sh: line 89: ulimit: open files: cannot modify limit: Invalid argument”. So let’s have a look at the run.sh file, for example by opening it in “vi” and enabling line numbers with the command “:set number”. When printing out the value of the variable $MAX_FD it becomes visible that it contains “unlimited”, which does simply not work. As it is late and I am a little bit lazy I am just replacing this one hardcoded with some maximum value, which I am setting to 10240. This should be more than enough for some local testing and playing around. (I will not use JBoss productive on my MacBook Pro I guess ;).) So just change line 89 as follows:

old: ulimit -n $MAX_FD
new: ulimit -n 10240

And then start the JBoss application server again. The error message should be vanished. Please note that this is not the nicest possible solution for this problem and it would be of course much better defining some environment variable and using it there, but did I mention already that I am too lazy now for this?

Of course we need some final proof that the JBoss-server is really running for you disbelievers out there. Therefore please open the following web page in your browser and enjoy: http://localhost:8080/

Next time we will integrate some local MySQL database to the server by adding the corresponding data source, but now it is time to get some sleep as there is some real work to do tomorrow :).

Give a spontaneous answer to the following question: What is better? No decision or a wrong decision? Ok, it might be hard to answer without having a more concrete context, but on this site obviously we are talking about software development :). My answer to this question is: Better a wrong decision than no decision at all.

First of all I would like to take a closer look at the term “wrong” in this context. Of course there are absolutely wrong decision you can take (even the term fatal is justified sometimes) in your software architecture and design. Those could be really bad and expensive in the long run. But from my experience this is happening very seldom. Far more often it might be more a question of finding the one ultimate solution or just one that works, even though it is not perfect. So the first question was a bit exaggerated, but hey, I needed your attention ;).

Porbably almost every Software Developer knows the following scenario. Some new piece of software must be developed and there are - as always in life - different possible ways to do this. Now you say: Ok, just pick one and go ahead! Yes sir, if it would be that easy. At least in bigger companies you typically have then a series of meetings about this problem. Participants in those meetings are developers and potentially the project manager. Now the fact is that there is usually no hierarchy among the developers and the project manager has technically no clue which way to go. And developers like to argue on their viewpoint, which is a very good attitude as it often helps digging into the problem, analysing it from all sides and finding a good solution. But here it should stop - at least in commercial projects - do it good instead of perfect! You can continue discussing forever should this functionality be split into two or three classes, what should be the name of a class, what is the best way of interprocess communication and so on. The following should be considered:

• The design of the software will anyway change during the implementation and due to new/changed requirements. And a lot of those “issues” can be changed later on still with some refactoring. It is simply not worth this amount of discussion probably.
• These kind of discussions might be a sign that the team (or individual developers) do not want to decide. With a decision some kind of responsibility comes along and we are back at the point that decisions can be “wrong”. But that should not be something that is bad and the project organisation must definitly support making decisions.
• But also the opposite situation happens: Two (or in seldom cases more) developers want the decision for the solution they are in favor of. It is good to fight for ones own solution, but you also must be able to step back. If you cannot proof objectively that the other solution is crap then consider going that way. For some other parts then your solution is taken. It is kind of a give and take almost comparable to being married ;).

What can help here? Agile development methods are probably helping as there is much less upfront design and thus less chances for some fundamental discussions. Furthremore in these kind of projects change and refactoring is more commonly accepted and thus it is easier to accept a solution and start implementing it. There will be also more likely early feedback from the customer. When using Scrum it might be possible that the scrum master is helping to moderate at least the discussions or some experienced developer might be able to do so as well. Anyway it should be kept in mind that those discussions do not only require technical skills, but also a lot of soft skills. Thus if these situations are happening frequently within a team some training or coaching might be very helpful as well.

Ok, I would like to come to an end with a quote from a movie I do not like too much, but I like this sentence really a lot. Maybe there is often not that much of a hierarchy in software projects, but decisions must be taken nonetheless.

In every organisation there is always one person that can decide, if you only go high enough in the hierarchy. - Very freely quoted from the movie Payback

Testing your software will make you happy, and do you know why? Because this will make your customer happy and trust me: Nothing is worse for a Software Developer than an unhappy customer as it means your boss is unhappy and then … you know the rest for sure.

But why is testing software carefully then something that is neglected by a lot of software developers? The answer is easy: Testing is not seen as the fun part. It is not seen as part of the creative side of this work in comparison to the actual software design and coding (huh, that is cool). It is typically perceived as boring. And of course as a developer you are anyway sure that everything works, I mean hey, YOU have coded it and you have taken care of everything, don’t you?! Finally testing - at least in traditional development methods like waterfall - is always happening at the very end of a project. And as the project is anyway already late some program and/or project managers will push you - the poor Software Developer - hard to get things finished. Fine for the developer, who anyway hates testing, and is just throwing it over board happily. Thus getting rid of that “stupid task”, saving time and thus bringing good news to your project manager as. A very dangerous combination that is unfortunetly seen far too often still.

Sounds familiar? No? Then you are probably a happy developer already! Yes? Let’s try to change something as the described scenario is not caved in stone.

Let us assume you are a software developer who is responsible for testing as well; what can you do? (Things will be different - not necessarily easier - in bigger companies having own test departments.)

• Accept testing as part of your job - or try to get rid of testing entirely
  You do not have to love it, but it is part of the job like software design and coding is. So you better start accepting it as such and not just as a nasty aside. Or maybe you have the opportunity to get rid of it more or less entirely. I know of one brilliant software developer who is really awful in testing - and everyone in the company knew it - so basically testing his software is most often assigned to other developers. Maybe this is a possible way to go, but open communication on this within the project is the key here.
• Learn something about Software Testing
  I am sure you have visited some trainings about oo-design or read a book. You are constantly looking for the latest design patterns in your favourite blog and of course you learn the changes in the API of every new Java Edition that is released. Ok, then why don’t you do the same thing for the testing part (uhm, I remember, I was writing it is boring)? But maybe it will no longer be that boring once you have learned more about it. It might even feel extremely cool delivering software with less bugs. And I am sure there are even ways to be very creative in testing. Test automation could be the key here. I am sure it is worth it. But keep in mind what is the sole purpose of testing and let’s not be taken away by trying out every fancy technique leaving you with - you guess it - no time for the actual testing in the end.
• Consider testing when asked for effort estimations
  Sounds trivial? Yes it is and it is nevertheless not considered far too often. The project manager is asking you for some effort estimate and the thinking goes like “yeah, small code change here, some XML changes there, nothing really impressive, let’s say 5 hours”. The project manager answers: Great, this is really urgent, do it right away, we will deliver tomorrow afternoon! Well, noone was saying it must be delivered, I mean, this is changing quite some part of the entire logic and … well, bad luck, too late. When we have productive software then changing parts of it in 99% of the time means it must be productive software still afterwards. And that means it must be tested and even if the change in the code takes only 5 hours it might be very well the case that re-testing these changes takes several days. Period. (Of course this does not mean that there is not some project manager promising things earlier nevertheless, but that seems to be somehow unavoidable.) Thus always include testing in your estimates unless you explicitly state it is not included.

Of course there is a hell of a lot more to say on this topic, but I want to come to an end for now. There will be more posts on this topic here for sure. For example testing in an agile project setup has quite some other/additional challenges, but this does not mean you can do less testing. The opposite is true as you are delivering more often. I already touched the aspect of test automation which is the key here for sure.

I was also mentioning working with a test team earlier in this post and want to say at least a few words on this still. Of course this changes everything as typically software developers are then no longer responsible for the actual testing (I am not talking about module/JUnit testing here of course). But typically this requires then some close co-operation and thus we are back in the testing business somehow. This setup indeed has its own pitfalls and I think it is worth a blog post of its own as well at some later time. But just in case you have not yet heard of it the IBM Black Team might give you some inspiration what good testing is about and that it indeed can be very satisfying.

Now, IBM in the 60s was not exactly known fostering creativity in the workplace. Corporate identity was bound up in dark-blue suits and starched white shirts. Management, however, not only tolerated what was happening, but loved it. Perhaps they felt some admiration for a group so passionate and dedicated, but the bottom line was that software quality was improving at a rapid rate.

Personally I have no real preference for doing the test job as then I would be a software tester and not a developer. But from experience I have simply realized the importance of doing a good job in testing … and coming back to the beginning: It gives me some peace of mind as I know who is in trouble in the end if things are not working as desired.

Somehow I feel that I have doomed myself with this blog post as I am quite sure my boss and collegues will dig this out the next time I mess things up … I better do a really good job in testing ;-).

Jurgen Appelo has written a very comprehensive and - in my opinion very good - presentation on the scrum topic: The Zen of Scrum … and it is a really cool title as well.

Alan Skorkin has taken a closer - and subjective - look at the current state of the agile nation … and beyond.

I liked the following sentence (ok, it is only fragment of a setence) especially:

agile doesn’t kill agile, people kill agile

One definite possibility to kill agile is to use it as an excuse for chaos and aimlessness saying “We are agile” all the time. Hopefully soon I will have the opportunity to use agile again more in praxis and share more of my own experience here :).

It was a long way since the first screenshot I have posted on 25th of December 2008 until today. But now it is done and the first version of iPlode is available for download. I think everyone doing some programming beside the job knows that it could be quite hard, no matter how much fun it is … and the final touch is always the hardest one ;).

Therefore I enjoy this moment really a lot, especially as iPlode is available for all major platforms (Mac OS, Windows and Linux) right from the beginning including some user documentation. Of course I have no idea if really a lot of people will like the game, but for me it is enough if there is only one … and I am sure there will be one :).

The nice thing of having a first version available is that now I can start making improvements, maybe I get some feedback and of course fixing potential bugs … and I can ensure that my head is full of ideas for features and improvements.

So I hope you will enjoy it and I will drink a beer now :). Cheers!!

Yepp, yes, I know! I should bring a first final version of this thing out before porting it to any (exotic *hide_and_run*) OS. But I was just sitting a bit brain-dead in front of my Mac and was thinking that I could install Ubuntu to my VMWare Fusion. So I did!

Well, Eclipse was installed quickly and what should I say: iPlode was running out-of-the-box after adjusting which SWT-Libraries to be used. Which brings me back to my headline: Java is really great!

So the plan is still valid to release a first version on the weekend ready for download. Of course everyone developing software knows this problem with plans, but currently mine is still valid :-).

I am almost there :). With the New Game Dialogue I have finished the final part of the game basically. Now I need to do some updates on the documentation and think of the proper packaging and then the baby can go out. I even implemented a very basic “Update Check” by now, so I am well prepared for future releases.

Optimistic as I am I think I will go online with iPlode on the forthcoming weekend with version 1.0 … hoping that my server is not collapsing due to the huge load I am expecting :-).