Introducing YippieMove '09. Easy email transfers. Now open for all destinations.

Today WireLoad is releasing SwtCallback, a Java library for SWT that enables callbacks for event handling. SwtCallback is inspired by the Swing enhancer Buoy by Peter Eastman.

If you know you want this, just skip to the bottom of this post for the download link. Otherwise, read on and I’ll explain the reason we wrote this library.

I’m a big fan of readable and concise code. Another thing I’m a big fan of is user interfaces that look and feel like what users expect. Given this, I’ve always had an aversion to UI programming in Java. Because I think it’s very telling, I’ll let this flash video illustrate: totally gridbag. Bottom line is that in Java, user interfaces look weird and often attempts to alleviate this weirdness result in enormous amounts of hard to read code.

One solution is to use the Standard Widget Toolkit (SWT) instead. SWT enables easier UI building with resulting UIs that are both faster and look and feel better for the end user. What’s more, the code is more concise thanks to FormLayouts, sane widget sizing and the availability of standard functionality.

There’s one thing I think can be improved on though: readability. SWT code has a tendency to, like Swing, become littered with hundreds of listener classes, or worse, faceless listener implementations. For example, your code may look like this:

public class Demo implements SelectionListener {

   void initialize() { 
      Button myButton = new Button(shell, SWT.NONE);
      myButton.setText("Click Me"); 

   public void widgetDefaultSelected(SelectionEvent e) {
      // I don't care about this event but I have to 
      // have a handler to satisfy the interface.

   public void widgetSelected(SelectionEvent e) {
      // Do something

Notice how the method named ‘widgetSelected’ has a very generic name: it has to since that’s the name it was given in the SelectionListener interface. Also, if there are many widgets that listen for selection events, then this single method has to handle all of them with a big if statement or some such. Not very readable. We also had to thumb on conciseness by adding one method which we didn’t even want: widgetDefaultSelected.

A better method is to associate the handler with only a single widget by using an inner class, and to use an adapter to avoid having to add a dummy method. This would typically look like this:

Button myButton = new Button(shell, SWT.NONE);
myButton.setText("Click Me"); 
myButton.addSelectionListener(new SelectionAdapter() {
   public void widgetSelected(SelectionEvent e) {
      // Do something

Much better. Less code, easier to read and it’s clear what ‘do something’ is associated with. But now we end up with a bunch of anonymous classes and deeply nested code. It’s still not perfect.

Enter SwtCallback. With SwtCallback, our final version of the program may look like so:

void initialize() { 
   Button myButton = new Button(shell, SWT.NONE);
   myButton.setText("Click Me"); 
   Callback.add(myButton, SWT.Selection, this, 

 * Called when myButton is selected.
private void myButtonSelected() {
   // Do something

This has everything we wanted: it’s clear what the ‘myButtonSelected’ method does because it’s well named. There are no listeners to implement and no inner class bloat. The definition of myButton is short without being complicated or hard to understand. As an added bonus SwtCallback allowed us to make the event handler method private – this makes sense since the method is only relevant for the corresponding UI class.

UI programmers with experience outside of Swing will hopefully immediately recognize and appreciate the idea of callbacks. If you still need more reasons though, I’ll suggest a couple:

  • Less code means fewer bugs and easier maintenance. Callbacks allow you to handle events without lots of extra classes or big if-else statements.
  • You can link many events to the same handler. For example, maybe you have a ‘Quit’ button in a window. This button can have the same handler as the standard close event for the window.
  • No need for dummy methods. Since you’re not implementing listener interfaces you don’t have to implement handlers for events you don’t care about.
  • Natural names for methods. You’re not constrained to some standard name for an event handler. You can name your method ‘handlePasswordFieldGainedFocus’ if you want to.
  • Private or protected event handlers. With interfaces your event handling methods have to be public. Most of the time they’re very specific to some UI classes. It doesn’t make sense for other unrelated classes to call your handlePasswordFieldGainedFocus() method.

If you still need more, Peter Eastman, the author of Buoy, expresses the rationale for callbacks much better than I ever could here.

SwtCallback is released under the BSD license. Download the source and binary here:

Download SwtCallBack. More information is available here.

Patches and comments are welcome. Apologies for the lack of documentation – if there’s interest in this library we’ll revisit it. For now, if you find it useful, great!

Update 1: SwtCallback 0.2 has been released.

Author: Tags: , ,
Introducing YippieMove '09. Easy email transfers. Now open for all destinations.

How many times have you made a change to a server to only a couple of days or weeks later discover the change you did broke something? It happened to me a bunch of times. Sure, call me irresponsible, but sometimes I’m in a rush and don’t have time to document the change and write nice comments about it. I try to do so, but sometimes I forget.

For quite some time I’ve thought about a simple way to track the changes to my servers, but without coming up with any perfect solution. My ideas have included everything from wikis to blog-style logging to Tripwire. Sure, a change-blog would work, but it would take quite some extra time to write the entry.

One day when I was working with our development tracker a quite brilliant solution stroke me: why not use CVS/SVN on /etc? It sounds like overkill, but it would do the trick. By using this you would be able to:

* Display when the changes were made
* See what change was made
* Revert to a previous version

There are two different ways to go along using a repository for /etc. One way is to create a CVS/SVN tree on a different server and sync the entire /etc directory to that repository. The benefit with this is that you could have the repository on a different server and be to collect all your servers /etc on the same repository. By combining this with a web-interface, one would be able to easily compare and contrast the configurations of the different servers. Moreover, the change logs would be kept in the repository, and not on the individual servers, creating a cleaner file-structure. Another benefit would be that you could easily sync the /etc filesystem with your local workstation and modify/create your config-files there. The drawback with this solution is that you need to make your local changes first, and then upload the files to the repository. Once you’ve uploaded the files from your local workstation you can go ahead and sync the actual server with the repository to commit the changes.

Another solution would be to use a custom file-system. There are two different filesystem that supports version-tracking: CVSFS and Wayback. Between these two alternatives, Wayback appears to be the most developed alternative. Worth noting though is that both these alternatives only targets the Linux-platform.

The benefit for using such approach is that you don’t need to set up a separate repository to keep the files in, as well as that it enables you to make changes in a traditional way on the server. The drawback is that neither of these two filesystems are very well maintained. It appears that both these programs were last updated back in 2004, rendering them both quite obsolete. The question is if you really want to put the faith of your /etc-folder in a program that no one longer maintain.

Regardless of which one of these two alternatives you find most appealing, the concept is very interesting. I have still not tried to use this myself, but I would certainly argue that having a /etc-folder that allows you to keep track of changes is far superior to the traditional way of keeping /etc.

Edit 1: Since the article was published, I’ve found two more file-systems worth mentioning: CopyFS and ext3cow. Both these filesystems appears to be useful for /etc usage. Out of these two alternatives, ext3cow appears to be more sophisticated. However, CopyFS appears to be easier to set up.

Author: Tags: ,
Introducing YippieMove '09. Easy email transfers. Now open for all destinations.

If you’ve followed us for a while, you might remember our article ‘Selecting an Accounting System’. Not too many things have changed since then. The developers over at Quickbooks are still not competent enough to write an OS independent web-app, and no other major events have occurred. The most interesting thing that have happened since we wrote the article was that SQL-Ledger silently changed license from GPLv2 to SQL-Ledger Open Source License. Although we would rather have seen SQL-Ledger staying GPLv2, we don’t really blame them. The company needs to make some money in order to survive. So, despite the change of license, we still decided to use SQL-Ledger as our accounting system. At least for now.

Enough about that, let’s get started. First time I installed SQL-Ledger I ran into a couple of problems. Even though I spent a fair amount of time doing research on how to set everything up, I still hit a couple of speed bumps. Since I’m quite new to PostgreSQL, some of my problems were related to this. Some other problems were related to the fact that the manuals did not really match what I saw on the screen.

Now, let’s get started. First we start with updating the ports to make sure we’re getting the latest version.

# portsnap fetch; portsnap update

After updating our ports-tree, we need to install PostgrsSQL. When writing this post, the 8.2-series is the latest stable series.

# cd /usr/ports/database/postgres82-server/
# make config

Select the flags you prefer. The only flag I changed from the default was the optimization flag. Not that I know if it makes much of a different, but if you’re compiling it you might as well try to build more optimized binaries.

# make install

Now Postgres is installed. However, in the normal FreeBSDish manner, we need to enable it in rc.conf before we can fire it up.
Edit /etc/rc.conf and add postgresql_enable=”YES”

When you’ve activated Postgres, we first need to initiate the database, and then start the service.

# /usr/local/etc/rc.d/ initdb
# /usr/local/etc/rc.d/ start

Voila, now we have Postgres initiated and up running.

Let’s take a look at the package we’re actually interested in installing: SQL-Ledger.

We’re just going to use a simple ports-installation of SQL-Ledger.

# cd /usr/ports/finance/sql-ledger
# make install

After installing the package, we need to make changes to Apache in order to enable SQL-Ledger. Simply add the following line at the appropriate location in your httpd.conf or ssl.conf:

Include /usr/local/etc/sql-ledger-httpd.conf

To make sure our Apache-file is intact, we run:

# apachectl -t

And if that went well, we run:

# apachectl restart

The only step remaining now is some database-related stuff.
Since I’m not an expert at Postgres, I might not be explaining this in the best way. Anyways, I’m just trying to share my experience, since this was the step where I ran into some speed bumps when first setting up SQL-Ledger. The problems I was facing was that the prompts I received differed quite a bit from the ones found in the various manuals I read before installing.

First, log into the Postgres user

# su - pgsql

When you’re logged in, we need to create a user for SQL-Ledger:

# createuser -d -P sql-ledger
Enter password for new role:
Enter it again:
Shall the new role be a superuser? (y/n) n
Shall the new role be allowed to create more new roles? (y/n) y

Note that if you remove the -P, you won’t be prompted for password. However, I personally prefer setting a password here.

Lastly, we need to copy the template.

#createlang plpgsql template1

Hopefully that went without any problems. Now it’s time to surf into SQL-Ledger to make the final configurations. Open your browser and surf into http:///sql-ledger/ Log in without any password.

SQL-Ledger Login

Note that I’ve already set up a password when taking this screenshot.

SQL-Ledger - PG database
Select the “Database Administration” link.

Use the user ‘sql-ledger’ and the password you assigned when creating it. For ‘connect to,’ use ‘template1.’ When you’re done filling that out, hit ‘create dataset.’

SQL-Ledger - DB admin

The next screen that will pop up is the Create Dataset-screen. Here you need to set the name of your dataset. Use only lower-case letters. I’d suggest the name ‘sql-ledger’ to keep things from being complicated later on. For ‘encoding,’ select UTF8. As for the ‘chart of accounts,’ it really depends on what business you’re setting up SQL-Ledger for.

SQL-Ledger - Create Dataset

You’re done! All you need to do now is to set up the users. Since this is quite straight forward, I’m not going to cover that.

For more information, please visit You might also want to take a look at this ‘unofficial’ manual (the official one costs $190).

Edit 1: Dieter Simader, the founder of SQL-Ledger, e-mailed me to point out that the only non-GPL’d version of SQL-Ledger is the 2.8-series. The 2.6-series used by FreeBSD ports is still under GPL.

Author: Tags: , ,

© 2006-2009 WireLoad, LLC.
Logo photo by William Picard. Theme based on BlueMod © 2005 - 2009, based on blueblog_DE by Oliver Wunder.