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.

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

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.

(more…)

There are also plenty of other examples at the big end of town. Today I received an email from PepsiCo and HP outlining their use of PaperCut Print Logger. It’s great to see that this little free program has uses ranging from small homes to the largest corporates.

For us, PaperCut Print Logger serves two purposes:

1) It’s a great test bed for our printer page analysis technology. With hundreds of thousands of users, we quickly get reports about incompatibility with new drivers. The program actively encourages users to report incompatibilities and in turn this ensures that all our applications offer the widest range of support.

2) It’s also a fantastic way to get a “taste” of our applications. Many schools for example will install PaperCut Print Logger to get a quick view of what’s going on on their networks. It’s then only a small jump to move to PaperCut to implement print control, quotas, reporting, and of course monitor the environmental impact of printing.

If you’re running print logger, please take a few moments to send us an email and share your stories.

Our use of Jetty is quite a bit different to most. Instead of treating Jetty like Apache or a stand-alone server, we’re using Jetty as an embedded component. It’s deployed with our print accounting application, PaperCut (tour here for those interested). As a result, Jetty is running on tens-of-thousands of servers in over 60 countries and the vast majority of users are completely unaware that it’s there. The measure of a good embeddable component is not who’s using it, but who’s not aware that they’re using it! Jetty is fantastic in this regard - zero config and zero maintenance, working away flawlessly for years on end.

Jetty is hosting PaperCut’s web application interface. This is a web application based on Tapestry, Spring, Hibernate and Apache Derby. Jetty’s embeddability has allowed us to deploy this stack in a standard setup.exe type installer targeting all major platforms (Windows, Linux and Mac). Our users don’t need to know anything about web servers or their setup and configuration. All they need to do is run the installer! Jetty’s scalability has also been an advantage. In some cases PaperCut is installed on a small business server supporting 5 workstations, while on other sites it’s running in University environments on clustered servers supporting 100,000+ users. Jetty has prove equally adaptable at both ends of the scalability spectrum.

Choosing components for a project is always difficult - often too much choice! Obviously Jetty has been a great choice but was one we carefully considered back in 2005. Technical functionality was one criteria, but another important consideration was the strength of the team behind the project. We’ve seen too many Open Source projects start out with enthusiasm only to run out of puff and “age” early. What grabbed us about Jetty was the future looking team. In 2005 AJAX was very new and there was big questions about how to handle server-push events in a scalable fashion. We had an immediate need for this, not with AJAX, but with our web services API (client software receiving web-services push events from the server). The Jetty development team members such as Greg Wilkins, were openly discussing “long polling” and the issues around this. Jetty was one of the first servers to present working and more importantly “workable” solutions to the scalability problems.

We can’t recommend Jetty more highly. It’s a great web server, a great component, and is backed by a switched-on forward looking and innovative team - make sure you check out the open source Jetty and the team!

The offending card censored to protect the innocent!

The situation reminded me of the Infinite monkey theorem. We calculated that the probability of this, or any other four letter work appearing in any one card, is approximately 1 in 800,000. That’s very low, but given a large enough number of administrators generating a large enough number of cards, it was bound to happen some day.

We considered a number of solutions including Black Listing words. The only problem with this approach was that it’s hard to know what constitutes a “bad” word in all the 9 languages we support. Also, maybe some legit words may be inappropriate in some cases. Our final solution was to simply drop vowels which in turn prevents word formation - a simple but elegant solution. Anyone know any bad four letter words without vowels?!

We have a rapidly growing KB and we hope this will help PaperCut users find answers they’re after. Please give it a test run and let us know if you have any comments/suggestions.

The website also has an interesting survey (XLS file). Almost 40% of respondents didn’t use double-sided duplex printing because it was “too awkward”. Another good reason to deploy PaperCut – so you can enforce duplex on all printers that support it!