My first son William arrived yesterday. Unlike our planning here at PaperCut which usually run a few weeks behind schedule, my first child has decided to buck the trend and run ahead of schedule. William weighed in at 1.795kb (just under 4 pounds) - very small but strong and healthy. Both Mother and baby are doing well and Dad is very proud.

William’s bound to be a “tech baby” and I’m sure will be writing computer code in a few years. I was meant to be presenting at the Australian Java User’s Group the night he arrived. He was obviously very keen to get out and attend (also thanks to Matt who stepped in and did the presentation for me). He’s first taste of technology was his photo being sent out to everyone a few minutes after his birth courtesy of a 3G iPhone!

I’m sure to have my hands full over the next months. Lots of time looking after baby and working on print control software between feeds!

Another update for the sites participating in the Novell OES Linux beta program. It looks like we’ll have to wait a few more weeks to get proper print quota on iPrint. The iPrint update required to run PaperCut will now not be available until next week. Novell will be undertaking the last validation tests on Friday and assuming they all pass, they’ll be looking at supplying us with the update on Monday. The build is going to be based on the iPrint Beta 4 release. I’ll keep you all posted and let you know if there are any further delays.

Last week we announced the start of the official beta testing period for PaperCut on Novell. Novell is our last remaining platform so it’s great to see this finally in beta. We already have close to 50 sites that have contacted us expressing eagerness to participate in the beta testing program. There is a lot of excitement out there and a lost of organizations are happy to finally see best of breed print auditing and print control on iPrint.

As discussed in this page, I am going to post updates, news and announcements in our developer blog. One of the immediate announcements is with respect to the availability of the new iPrint release from Novell. PaperCut targets a yet-to-be-released iPrint version. This is a new version of iPrint scheduled for official release in Novell OES Linux 2 SP1 and includes the API hooks we required to get PaperCut working and cooperating with iPrint. Dean and Devon at Novell are working through the internal procedures at the moment so all beta test sites have early access to this iPrint update. The plan was to have this available last week but it’s been delayed. Dean is aiming to have all approved and available on Thursday the 21st.

In the meantime please regularly check this Blog for any news. Also if you have any questions or what a sneak peek, please check out the announcement and/or feel free to email me at support.

As keen Java programmers we’re always on the lookout for interesting tidbits about the language, how it is being used and where it is heading. Just the other day Matt brought in a copy of Java Puzzlers to test our knowledge. So it was something of a coincidence that the guys over at Atlassian came out with their own Java puzzler.

The puzzle is a Java version of the shell game (AKA ‘thimblerig’), where the onlooker must choose which shell the ball is under (after the con artist has shuffled them around).

The puzzle and the included solutions are interesting, and well worth a read if you’re a programmer. Chris came up with the ’static block’ method almost immediately, but I must admit that my thinking was just along the lines of “err, with reflection somehow?” before we looked up the answers.

Four solutions were presented on Atlassian’s blog post, but I have a fifth: The terms of engagement were “you can only modify the class representing the ball”. But what about a solution that doesn’t involve modifying the ball either? What if you could alter the onlookers’ perception so that when the cup is raised they see a ball, despite there not being a ball at all?

Using the Force and with a wave of the hand, we get:

aspect YouWillBeEqual {
    boolean around(): call(boolean String.equals(Object)) {
        return true;
    }
}

Now there is a ball under every cup, always. At least, it appears that way. Actually, everything around here appears to have a ball under it…

Made possible with a little AOP

When we’re not working on new features, we’re often working on improving PaperCut to ensure it works well in a large variety of situations.  Sometimes customers use PaperCut in ways we never intended, or encounter scenarios which we never envisioned.  We take pride in listening to our customer experiences, and making improvements to ensure we meet their needs.  The result is a better product, and everyone benefits.

Today I’ll explain an issue raised recently by one of our largest PaperCut ChargeBack customers, and then describe how we designed and implemented the solution.

The Problem

This customer was running PaperCut in a challenging environment:

• Around 2,000 users all running the user client to charge printing to shared accounts;
• Users are located at a number of remote sites over slower network connections;
• Printing is charged to over 30,000 shared accounts;
• All users could charge printing to any of the 30,000 accounts;
• Each night an automated process added, removed or modified hundreds of accounts.

They reported the following problems:

• The user clients on remote sites were slow to popup when first printing.
• A large amount of bandwidth was used communicating with the primary PaperCut server.
• The PaperCut server was slow to respond in the mornings.

Analysis

It was clear that the cause of all these symptoms was the large amount of account data downloaded by each of the user clients.   The user client will only download the account list from the server when it detects accounts have changed.  But at this customer the account list was changed nightly.  This caused the client software to re-download the large account list when the user first printed each day.

The client software communicates with the server using XML web services.  After some analysis we found that the the XML representation of the 30,000 accounts was about 7.5 MB.  On a fast local network this size is not a problem, but with 100’s of clients running on remote sites over slower WAN connections this starts to be an issue.  It causes congestion on the network, the popup is slow to appear, and the server becomes overloaded.

After a few brainstorming sessions and consulting with the customer we approached the solution from two angles.

1. Reduce the size of the account download;
2. Allow the account data to be efficiently distributed to remote sites.

Solution Part 1: Reducing the download size

To reduce the size of the data downloaded we changed the account file format in two ways:

1. Change from verbose XML to a much more efficient binary format;
2. Compress the binary data

The net result was a reduction of approximately 25 times!   In the case of this customer the 7.5MB download was reduced to around 250KB. Quite an improvement!

This change alone dramatically reduced the popup speed, and bandwidth used over the WAN connections.  But we could do better!

Solution Part 2: Efficient distribution

We realized that it was very inefficient for multiple clients at the same remote site to download the identical account list.  What if we could only download the list once per site?

We implemented a server-side tool to save the account list to a file (in the identical format described above).  We added a new option to the client software to allow it to load the account list from a file instead of downloading from the server directly.  Then all that this customer need to do was:

1. Schedule a task to create the account file each night (after the accounts were modified), then copy the account file to a file share on each of the remote sites.
2. Configure the clients at each site to load the local account list file.

The result was that only a single 250KB transfer was required to delivery the new account list to all clients at a given remote site.

Conclusion

The result of these changes was dramatic.  Previously, on a site with 20 users the daily account download would consume around 150MB of bandwidth.  After these changes it was reduced to only 250KB.  What an improvement!

Not only was this a great result for this customer, but the product is improved for everyone.

I hope this gave you a little insight into the work we do behind the scenes.  This change wasn’t glamorous or exciting.  It will only be a single bullet point in our version 8.4 release notes.    However it’s often many of these small improvements that make the overall product great.