When we began work on the new Status page of YippieMove ’09 we searched high and low for good charting software, both server based and dynamic. OFC 2 came out on top. OFC is an excellent Flash charts program written primarily by John Glazebrook. It supports several different chart types including line graphs, bar graphs and pie charts. It dynamically reads its data using JSON.

To meet WireLoad’s specific design goals for YippieMove’s status page a number of modifications were made. We needed a particular look and feel, we wanted the fastest possible load times and there were a couple of glitches when using our particular data sets that needed fixing. Since many of these changes were very specific to our use case we opted to just branch the software and not disturb the ordinary development of OFC. This branch is what we are releasing today as OFC WireLoad Edition 0.2. We hope it will benefit the OFC community and perhaps interested parties will be able to find pieces and parts they can use elsewhere.

OFC 2 Hyperion was used as the base. An overview of the changes can be found below.

Visual Changes

• Support for a gradient background.
• Chart encompassing border.
• Look of axises changed.
• Pie chart drop shadow.
• “Fuzzy” grid lines sharpened up.
• New ‘spinner’ progress indicator.

Functional Changes

• Fast loading progress indicator which starts showing before the whole flash file has downloaded and remains until the graph data has been loaded.
• New on the side legend for pie charts.
• New build script for building without the Windows specific Flash Develop.

Size Reduction

• Each chart type can be enabled or disabled at build time, which enables a site specific light-weight build. Many individual functions such as image saving can similarly be disabled.
• Embedded fonts are no longer required for 0-90 degree rotated X axis labels or rotated Y axis labels.
• Reduction of some redundant code.

The final version used on YippieMove’s status page is about 50KiB, down from 200KiB in the original.

If you want to set OFC WireLoad Edition 0.2 up for a test, be aware that when using IE7, SWFObject did not always properly detect the running Flash version in our testing. So you may see unexpected degradation to your non Flash content. Updating to the latest version of Flash seems to resolve the issue, regardless of your installed version – it’s the reinstalling itself that fixes the problem. Word on the net is that there is an installation corruption issue happening to some IE7 users.

Downloads and a complete change log can be found on WireLoad’s open source page.

1. Forwarding all emails, one by one. This is not a very appealing solution because it’s very time consuming, but also because it ruins the integrity of the emails by inserting a forwarding tag.
2. Just forget about the messages and let them be deleted when the account expires. This is obviously not a very appealing solution either.
3. Setting up the account in a desktop email client and drag and drop the messages. Not only is this very slow, but it’s also too complicated and error prone for the greater majority of the users.

If you’re really tech-savvy, you know that there are a few different tools you can use for this. However, as I recently was in this situation myself I realized that none of them worked out very well. After some research I discovered that there were only a few Open Source tools that could do the task. Out of these, Imapsync and imapcp seemed to be the most realistic tools. However after playing with these tools for a while, I realized that imapcp was to immature, and Imapsync was just too slow and too memory consuming (also, I was looking for a tool that copied the messages, hence the ‘sync’ part was just plain overkill). Because if this, we developed our own solution and turned it into a web app.

Even for tech-savvy users, YippieMove is a reasonable option, as it does what the Open Source tools mentioned above does (but without the hassle of figuring out how to use them). However, if you’re migrating hundreds or thousands of accounts, YippieMove might not be the best option….yet.

When we designed YippieMove, we tried to make it easy enough to use for even the most novice users, but at the same time provide the option that tech-savvy users are looking for. So far, judging by the feedback we’ve received, we have succeeded.

So how does YippieMove work? Well, we decided that everything more than three steps makes the service too complicated. Thus we created a simple three-step-process.

Step 1

In Step 1 we ask you for the account details for the source account. You can either choose to use one of the pre-configured settings, or ‘other,’ where you can fill in the server settings yourself.

Here’s an example of how Step 1 looks using the pre-configured settings for Santa Clara University.

Here’s an example of how Step 1 looks with the ‘Other’ option. As you can see, you can enter the host yourself as well as selecting if you want to use SSL or not. For tech-savvy users, we also allow you to specify a non-default port.

Step 2

In Step 2 we ask you to fill out the account details for the destination account. At this point we only support Gmail as the destination. However, we will be adding more types of destinations shortly. The argument for initially using Gmail as a destination was that Gmail both supports IMAP and that it has generous storage quotas. Unfortunately the IMAP setting in Gmail is disabled by default. To solve this, we provide a simple guide below the input-boxes where we explain how the user can enable IMAP.

As you can see above, this step is very straight forward.

Step 3

Here we ask you to select what folders to transfer. This is very simple for the more tech-savvy user, but might be a bit confusing for the most novice users. To cope with this problem, we’ve tried to make an educated guess of what folders the user may want to transfer. To be safe, we worked out a list of folders to exclude (ie. Junk, Spam, Trash), rather than a list of folders to include. For most users, the default selection should be sufficient.

In this screenshot you can see that we’ve selected ‘Apple Mail To Do,’ ‘Drafts’ and ‘INBOX.’ We decided to not include ‘Cabinet,’ ‘Calendar’ and ‘Checklist’ as these are Novell GroupWise specific folders.

In three easy steps, you’ve successfully managed to migrate your email. I hope we’ve shown in this article that YippieMove is designed for the entire spectrum of users, from the most novice to most tech-savvy. If you have any comments or feedback, please let us know.

PS. We’ve tried ditching sleep, but that didn’t turn out to be a great idea in the long-run DS.

1. Why Gentoo Shouldn’t be on Your Server (~40,000 views)

Our by far most popular article during the course of the year was an article called “Why Gentoo Shouldn’t be on Your Server.” Not only did this article catch a great deal of attention on blogs and forums around the world, but it even made it to Slashdot. The reason why this article became so widely read was because it discussed something that apparently is a very sacred Open Source-topic: Gentoo Linux. This Linux-distribution is considered by many as the most elite and advanced distribution because of its endless abilities to customize for you own needs. Our article took a look at how that kind of flexibility fares in the server world, and how it worked out for us after a year of use. We wrote that while we liked the distribution, it didn’t seem like the best idea to run it on a production server. Gentoo could be a great distribution for the lab-machine where you would want to stay updated with the most recent versions of everything, but for our production servers we would rather have something more stable that requires less frequent updates (only security updates), such as FreeBSD or Ubuntu (LTS).

2. Building a modern IT infrastructure for a small company (10 clients) with a sub-$3,000 budget (~18,000 views)

Interestingly enough, this article made it to the top without being mentioned on any of the big blogs: instead the majority of our visitors found the article through Stumbleupon. The article is the first in a series of two articles about how to create a modern IT infrastructure from scratch with an extremely small budget. To achieve this, we heavily rely on Open Source software for all parts of the organization. Without going into details, we utilize a software suit called LTSP to turn a set of cheap old computers into modern thin clients.

In the first article, we talk about the entire concept of using LTSP and how everything fits together. In the second article (Deploying the sub-$3,000 IT-infrastructure), we actually deploy this concept in a real company. Not only do we discuss how we ended up setting everything up, but we also provide detailed information on the exact hardware used, how it was configured, and what the actual cost was.

3. Bye Bye Binders, I Won’t Miss You at All (~10,000 views)

This article was a bit different from the articles we usually write, but it turned out to draw quite a lot of attention and it made it all the way to Lifehacker. In this article we wrote about how your could turn those ugly binders in your bookshelf into something more useful and pretty — a set of PDF-files. If you do have a scanner with Automatic Document Feeder (ADF), this guide helps you organize all of those documents into conveniently accessible PDF-files.

So what did we learn over this past year?

• Digg is overrated. If none of the few power-diggers ‘diggs’ your post, you probably won’t receive any noticeable traffic.
• Stumbleupon is very sporadic and unpredictable. Even though no major blog wrote about our LTSP article, it’s still the second most visited article on our blog.
• Blogging takes time. Although we really enjoy writing most of the articles here, it does take a whole lot of time.
• You need quite a bit of traffic to make any money of a blog. Even though we’ve had over 100,000 visits this past year, the revenue we’ve made in advertisement doesn’t even cover our hosting costs.
• It takes time to establish a user-base. Nowadays we receive more traffic in a couple of days than we did in a month in the beginning.

We hope that you’ve enjoyed the first year of Playing With Wire, and that you will enjoy another year with our technology, internet and startup articles.

The migration itself went smooth without any downtime for PWW. If you discover something that appears to be missing or malfunctioning, please notify us at admin@wireload.net.

As I wrote in my release post about SwtCallback, SwtCallback is a java library for SWT applications which adds an alternative way to handle events: callbacks. Instead of clunky listener interfaces or messy anonymous classes, SwtCallback enables one line solutions that make it easy to keep your event handling code in a single flat class – this while still being more readable and (surprisingly) improving encapsulation in some cases.

This latest release extends this functionality from just listeners to anything that takes a runnable. Prime examples in SWT are display.syncExec(), display.asyncExec() and timers.

For example, maybe you wish to refresh some UI components to reflect a change in data. But you’re not on the SWT thread so you have to use syncExec. Normally, you’d do something like,

display.syncExec(new Runnable() {
  public void run() {
    doUpdateSwtLabels();
  }
});

With a Callback you can turn this into one highly readable line:

display.syncExec(new Callback(this, "doUpdateSwtLabels"));

The most useful application may be for timers. In SWT, a timer needs to be reestablished at the end of timer execution if you wish it to recur. You may end up with unwieldy code such as,

void initWidgets() {
  /* ... */

  // Prime the timer.
  display.timerExec(INITIAL_DELAY, new Runnable() {
    public void run() {
      refresh();
    }
  }); 
}

void refresh() {
  /* ... update stuff ... */
  
  // Set the timer again.
  display.timerExec(TIMER_DELAY, new Runnable() {
    public void run() {
      refresh();
    }
  }); 
}

With a Callback you can now do this:

void initWidgets() {
  /* ... */

  // Prime the timer.
  display.timerExec(INITIAL_DELAY, 
    new Callback(this, "refresh")); 
}

void refresh() {
  /* ... update stuff ... */
  
  // Set the timer again.
  display.timerExec(TIMER_DELAY, 
    new Callback(this, "refresh")); 
}

This is much easier to read and follow, at least in my personal opinion. If you agree, go ahead and grab the download below – SwtCallback is released under the BSD license so you should be able to integrate it with whatever you’re working on.

Download the source and binary here:

Download SwtCallBack. More information is available here.

There’s some extra javadoc in this release to make it easier to get started. Still, there isn’t much in the way of documentation – we’ll go back and write some if there’s demand for it.

           

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"); 
      myButton.addSelectionListener(this);
   }
...

   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, 
      "myButtonSelected");
}

/**
 * Called when myButton is selected.
 */
@SuppressWarnings("unused")
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.

           

We also have a couple of cool Web 2.0-pages we want to share with you as well.

We promise we’ll take the time to publish a cool article within the next few days.

WireLoad, LLC
Re: PlayingWithWire
PO Box 390026
Mountain View,
CA 94039-0026

Now, don’t send too many gifts to us, because we have limited space in our post box.