PaperCut Blog / News

I recently helped out one of our biggest corporate customers to resolve issues with their print server. During the the last week of the financial year (when printing load is the highest) their print server became overloaded and stopped working. This sounds bad, but we quickly got things working smoothly again and learned that …

This customer had been running PaperCut for about 6 months without issue. Over this period they were gradually transitioning 100s of print queues from legacy print servers to the server hosting PaperCut. This single print server was hosting all queues for their offices country-wide. The extra load of these additional print queues combined with the end-of-year printing load pushed the server to the limit.

When analyzing the problem I noticed that this server was handling a huge print load. In the 30 day period prior the following printing occurred:

• 477,287 print jobs
• 2,021,454 pages printed
• Between 22,000 to 25,000 print jobs each week day

Wow! That’s a lot of printing!

They were also using hold/release queues and Find-Me printing (aka follow-me printing) to provide secure print release and to reduce paper wastage. The result was an average of around 500-600 print jobs waiting in the queue to be released.

The cause of the problem was under resourcing. Their setup was:

• A single server hosting the both the print queues and the PaperCut application server
• The server was a virtual machine assigned only a single processor
• Allocated 3GB of RAM
• Running on a 32-bit Windows Server operating system

My recommendation was to leave the print queues on the existing server, but move the PaperCut Application Server service to a server with 4GB of RAM, 2 or more processors, and running a 64-bit operating system with the 64-bit add-on pack. This configuration:

• Spreads the load between 2 servers
• Allows the PaperCut Application Server to take advantage of more memory (64-bit)
• More available processors allowed efficient processing of simultaneous print jobs

Since making these changes, their system has been running very smoothly. Their servers are now handling more load than ever, and without overloading the servers.

If you’re managing a large PaperCut installation, and in particular leveraging some of PaperCut’s advanced print management features such as secure print release, then there’s a few lessons to take from this:

• Don’t skimp on RAM or CPU resources
• Monitor your servers. Particularly if you’re adding print queues and increasing print load
• Consider running a 64-bit OS to allow for future expansion (e.g. more memory)
• Run PaperCut on an external database like SQL Server, Oracle, PostgreSQL or MySQL

CC image courtesy of Emilian Robert Vicol on flickr

Priyanka transitions from Java code to Java drink!

The regular readers of our blog will have noticed a few off-topic posts slipping in from time to time. The common theme is coffee and beer. As a group of passionate computer programmers and tech geeks it’s no surprise that we have developed a strong corporate coffee culture. Coffee is our secret weapon! Over the past 10 years we’ve changed programming languages, compilers, and development practices, but one factor has remained constant: Coffee. It must be the pillar for PaperCut’s success.

Coffee is very much part of our culture. The company funds a continuous flow of lattes, cappuccinos and macchiatos (Hendrik’s favorite) all arriving from the coffee shop directly opposite the office. Most of us have espresso machines at home (e.g. Rancilio Silva) and discussions on brewing techniques seem to pop up in developer meeting agendas unannounced.

Recently management decided that attending a formal coffee barista course would be a good idea. Traditional businesses would have called this a “cooperate team building exercise”, however for us it’s “core competency training” The whole Melbourne development team (minus Tom) spent a day at a coffee training academy learning the finer points of coffee production.

Lessons included:

• The art of wasting lots of milk perfecting the perfect froth.
• The amount of coffee one must waste to calibrate the ideal 25 second espresso pour.
• Latte art: The art of convincing someone that the shape on the top of their coffee was deliberate.
• How to make beverages unknown to computer programmers (chai lattes, and hot chocolates)

The day finished off with a competition. We paired up into teams and had to make 8 coffee variants in 8 minutes. Congratulations to Matt and Jason who took out the title.

To take a slight deviation, my favorite pieces of coffee trivia:

• The magic number on Java .class files is 0xCAFEBABE
• The embedded framework we target for our HP embedded MFP development is called Chai

Overall it was a very fun day. We even got to walk away with a formal certificate – we’re now qualified Baristas! If we all get sick of writing print management software we now at least have a fall back option – open a Cafe!

Thanks to Jason for the great images!

A few weeks ago we launched our new website design. Working on the website took up the majority of my time in the few weeks prior. As part of the redesign we added a number of new pages, removed some and moved others from one place to another. During this process a question was raised, “Should our URLs have trailing slashes?”. What we were talking about is this: http://example.org/page/ versus this: http://example.org/page . The former has a slash on the end, the latter doesn’t. Does it matter? Which one is better?

Does it matter?

It certainly matters if you are allowing both URLs to access the same content. Google’s SEO Starter Guide says

“Provide one version of a URL to reach a document”

or risk splitting the reputation of the page between all the URLs used to access it. This means that at best it won’t matter for you. At worst you’ll have your page’s reputation diminished, and you might also be penalised for duplicate content.

The best option is to pick one scheme, use that scheme in all your links, and redirect users who access your pages using the other scheme.

So it probably matters. Now do we slash or not?

I lean heavily towards slashless URLs, but at first I couldn’t put a finger on why. “They just look right”. So I thought about it for a while, made a list of the factors I could think of, and wrote it up as a blog post.

Semantics

What does it mean for a URL to contain a trailing slash? For me, it traditionally means “this is a directory listing”. When performing a request on a URL that maps to an actual directory in the file system in absence of an index document most web servers serve up a listing of the files in that directory. This is similar to doing an ls or dir from a terminal. Does the same apply when accessing http://www.papercut.com/blog/? That page is serving up the X most recent blog posts, and the view might depend on whether or not you’re logged in. In my opinion it is not a canonical list of sub-items items being served up, so the directory analogy doesn’t fully hold.

The more interesting part of how slashes affect semantics is the format of the response. What’s actually happening when a web browser requests /blog is the web server recognising that no specific format was requested in the URL (i.e. there was no .html extension), but because it’s a web browser making the request it makes an assumption that it wants the response in HTML. On the modern web that’s no longer a given. We have .json, .atom, .rss, .xml and others. If a browser wants a view of something in a format other than HTML, it makes sense to allow that simply by adding the requested extension. E.g. http://example.org/blog.atom . If the URL had a trailing slash that would become http://example.org/blog/.atom, which looks horrible.

Reddit provides at least one example of where both a trailing slash and format extension are used together!

Role Models

What are the big boys doing? Google sometimes add slashes and sometimes don’t, but they pick one and use redirects to enforce it. Stack Overflow allows both (!), but their own links omit them. Wikipedia omits slashes and doesn’t know what you mean if you add one.

Ruby on Rails put a lot of thought into their URL routing functionality. The result is, in my opinion, the most intuitive and complete definition for URL schemes anywhere. It should serve as a model to other frameworks and to those creating URL schemes by hand. Oh, and trailing slashes aren’t used (unless you go through some extra work to add them back in).

Legacy

For us the main factor was legacy. Most of our website URLs would remain the same (we were just introducing some new ones), and they already had trailing slashes. Would it hurt to redirect all the slashful URLs across to slashless ones? The best we could come up with is “maybe”, but that was enough to can the idea. Redirecting one URL to another via a 301 redirect (“moved permanently”) is rumoured to result in the page’s reputation flowing to the new URL. In practise, and confirmed at least once by Google, some of that reputation will be lost.

We’ve done a similar thing once in the past when we switched our main domain from papercut.biz to papercut.com. We used 301 redirects for all our URLs but several pages lost some reputation (e.g. from PageRank 6 to 5). Any pages that lost reputation gained it back after a month or two, however.

Implementation

Ask four web devs how to implement pretty URLs or remove/add your slashes and you’ll get seventeen answers. We use Apache with PHP, and implement the redirection in our root .htaccess file via Apache’s mod_rewrite.

Firstly we provide access to .php pages using “directory naming”:

RewriteCond %{PATH_INFO} ^/$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule . %{REQUEST_FILENAME}.php [L]

(the above reads “if the requested filename doesn’t exist as a real file or directory, but adding .php on the end results in a real file, serve up that .php file (but don’t change the URL”).

Then we add a trailing slash if none was present in the request:

RewriteCond %{PATH_INFO} ^/?$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME}.html -f [OR]
RewriteCond %{REQUEST_FILENAME}.php -f
RewriteRule (.*[^\/])$ $1/ [R=301,NS]

(the above reads “if the requested filename doesn’t exist as a real file or directory, but adding .php or .html on the end results in a real file, if they didn’t add a trailing slash then send the browser a permanent redirect to add the slash”).

Search on this topic and you’ll find hundreds of ways to do similar things, many of which have subtle problems in certain situations. Ours probably isn’t perfect, but it’s been working for us so far.

Summary

• Picking slashful versus slashless URLs probably matters. Pick one or the other, don’t allow both to return the same content.
• Accessing a URL with a slash on the end is not fully analogous with performing a directory listing.
• Slashless URLs look much better when you want to support multiple formats (/page.json not /page/.json).
• In the wild, people do it both ways.
• Ruby on Rails has a very nice and complete system for dealing with URLs, and they don’t use trailing slashes.
• If you already do it one one, your pages will probably lose some reputation if you redirect them to the other way.
• Implementation is a black art. Allow yourself time to understand the details.

In the world of software systems, blind faith is often consider the province of the naïve and inexperienced. The high potential for surprises in software deployments has given rise to the following axiom.

If you use a piece of hardware long enough, eventually it will break. If you use a piece of software long enough, eventually it will work.

This somewhat dark reputation of software has grown over decades of implementation horror stories that have a much longer lifespan than the multitude of boring stories of successful deployments. When things go bad with a software implementation the damages are often characterized as a waste of time, money and productivity; the very areas that the software was supposed to improve! This painful irony is enough to give most system administrators a measure of respect for the bleeding edge of software.

When it comes to adopting new technology healthy skepticism is a good thing, but if overdone it can block the path of innovation and the payoff valuable technology. This is because in spite of the afore mentioned axiom, when it comes to reputable software ‘fresh is best’. If this were not true software versions would be valued for their age, like fine wine. Instead, for most commercial software, six months without an update is usually considered the early warning signs of a dying product.

The fear of early adoption is not limited to the implementation of entire systems, it also extends to installing new versions and using new features of existing systems. The gravity of ‘not broken / don’t fix it’ in a production environment sometimes results in shops running software that is several revisions behind and often out of production.

So how do you decide where to place yourself on the luddite / suicide scale of software deployment? The decision is different for each implementation, but we have some tools that can help you make your mind up. First, read the PaperCut Release History to find out about changes that have been made since the version that you are currently running. The list of new features, fixes and improvements are updated with each minor release. Second, when you find a feature that looks interesting (for example, maybe you like the idea of improving your printer utilization using some of the example recipes in PaperCut’s new advanced scripting), use the search tool on our website to search all of our documentation. You will find links to the Tour, Knowledge Base, and User Guide sections that were updated when the newly added features were introduced. Third, try it. The license allows you to install a copy of PaperCut on a test server (even a desktop system will do) so you can test features before introducing them into your production environment.

One last thing. If you are running an older version of PaperCut, please remember to check that your license will work with the new version. From the Admin Console open the About tab. You will find the Licensed Version, and if you purchased Upgrade Assurance a ‘Software updates available until‘ date. If not, upgrade costs are modest and listed here. You will also find a link to check for and order updates as well as a link to email technical support in case you have any questions about the update.

CC image courtesy of cogdogblog on flickr

Hello, my name is Jason and I’m the new member of the PaperCut team. In my previous position I was a Systems Administrator (SysAdmin) at a leading high school. It though I’d share my story about PaperCut from my last role.

Part of any SysAdmin job is finding technology that fits a business need and in more recent times, a budget! Far gone are the days of unlimited budgets and unaccountability. There is now pressure on SysAdmins to quantify how a new piece of technology is going improve the bottom line.

One of perhaps the most costly areas of a SysAdmins responsibility is printing: hardware, consumables and time! The impact on a organization when a printer breaks down can often be heard office wide! “WHY is this printer out of paper AGAIN?”

Maybe this printer is being utilised by a department that should have their own printer, or maybe we need an extra couple of paper bins so that it only needs to be refilled in the morning, or perhaps someone is even doing printing outside of business hours. We often just don’t know.

Having been both a SysAdmin and as an Employee, I understand the frustration on both sides. In my past position I decided to investigate some print management software and see what kind of results I could achieve. So off to Google I went and after a bit of research PaperCut NG was the top candidate. I downloaded the trial and installed it to my test environment. It worked. I threw print jobs at it, I threw weird configurations at it. It just worked and I wanted it installed as soon as possible. I could see the immediate benefit.

I spoke to my manager, praising the features of the software and expecting an easy path to purchase. Unfortunately the budget was tight and it would need to be considered and justified. At this point I realized that the information I had did not quantify how this software would improve our bottom line. I needed to present my case to the budget holders!

I went back to PaperCut and discovered the ROI Calculator (Return on Investment). I started putting in some figures: 2,000 students, 250 staff, $0.05 a mono page, $0.20 per color page, checked with Accounts Department again to see how much paper we were using (about 8 reams a day, 4,000 pages). With all of these figures in, the numbers that came back were staggering. What was even more of a stand out was the time it would take for the purchase of the PaperCut software to pay for it self. It was possible that inside of 3 months we would be ahead.

Armed with more information I arranged another meeting. Using the bar graph, dollar values, and environmental impact, I put forward my more polished case. Everyone was sitting there asking “Do we really use this much paper? Do we really spend this much?”. The questions now weren’t about how much it was going to cost. Instead it had created a catalyst whereby the questions were about “Where else can we streamline ? What other software should we be looking at? Are there other faculties that can benefit?”. PaperCut was was now over the line, it was a now a no-brainer for everyone. The only downside is there was now an expectation that I go repeat the savings in other areas!

I’m now proud to be part of the PaperCut team working with a bit of software that I know from first hand experience has a real positive impact.

For the past month Tom and I have been quietly working away on our new website. It was satisfying to push it live today (Sunday night US time). The new site is quite a change for us. It’s the first time we’ve used an external designer. Here are a few screen-shots showing how our site has evolved over the last ten years:

PaperCut Circa 2000

PaperCut Circa 2004

PaperCut Circa 2009

PaperCut Circa 2010 (Today)

Historically all our web design has been done in-house. As a bunch of computer programmers we are very proficient in HTML, CSS, and JavaScript, however when it comes to artistic flair we finally conceded that we were hitting our limits. It was time for some outside help! After some searching we found a web designer (Pollenizer) we felt was able extend our own culture and style rather than impose their own.

I see that the Internet has two quite different styles:

1. The “Corporate Look” – conservative sites painted with fancy stock images (often from istockphoto.com). If we were to adopt this style I suppose we’d have some attractively dressed person standing smiling next to a printer )

2. The “Web 2.0 Look” - punchy colors, wide open spaces, and a focus on content / message rather than visual gloss – like YouTube, Twitter, and Facebook.

As PaperCut has grown over the years, we’ve expanded from being a solution exclusively for education to one focused on all areas from schools, to SME, to large business. Increasingly PaperCut is presented at management-level in corporate organizations. Despite this “enterprise shift”, we still felt that the Web 2.0 look better fitted with our technical-focused culture. We felt it was important to have a website that reflects who we are and the way we work. We’re quite proud that we’re an engineering driven organization run by young developers and want to make this clear through our website.

The visual design of the new website was done by one of the lead web designers behind Kazaa – in its day one of the Internet’s most popular sites (and one that will undoubtedly also go down in history for notorious reasons!). He’s done lots of work with leading Web 2.0 companies and I think has done a great job for us. We hope you like the new design. We’ve kept with our green theme (in both color and environmental impact aspect), and also put more focus on our name rather than our starting-to-look-dated XP style icon.

At a technical level the site is also a departure from the norm. We’ve decided to cast away the shackles of IE6 (darn Microsoft!) and now target the last web technologies (It still “works” in IE6 but is not visually ideal). We’ve also making extensive use of CSS and JQuery. One of the design goals was to have the home page load as fast as our older site. We’ve come close to this with the help of a few tricks. For example you’ll notice the progressive image loading on the home page – the content renders really quickly, while the glowing tree loads in later in the background (this tree constitutes about half of the page download and is done last and faded in with a JQuery effect). Some other technical highlights include:

• Designed for larger screens (not many system administrators are running 1024 monitors on their desktop these days!)
• Leverages CSS font kerning and shadow
• Enabled GZip server-side compression on selected resources. e.g. compress our CSS and Javascript files. (If this works well we’ll consider enabling on other resource types.)
• We’ve used cutting-edge CSS styling attributes available in Firefox and Webkit based browsers such as rounded corners on DIV elements (emulated in IE using curvycorners.js)
• JQuery is downloaded off GoogleAPI’s CDN. Many sites are now using this so these resources are already in people’s local cache.
• Some Apache .htaccess tweaks to more effectively leverage local browser caching.
• Renders on the iPad and iPhone!

Hope you all enjoy the behind the scenes story and welcome the new look! I should also mention that the blog/news section which you are reading now is not yet skinned in the new style!

We’re working on a new website design and the moment and I’ve been crafting some new content for the home page. We’ve always proclaimed that PaperCut is in use in over 60 countries, but this was based on figures back in 2006. I was wondering if we’d add any more to the list over the years. So during a cup of coffee today I jumped into the license system and with a bit of UNIX command-line magic and came up with the new list. We’ve now cracked 100! As a computer programmer, it’s great to know that your software is helping save paper in so many countries.

I was pretty good at Geography in high school but one name on the list stumped me. Where is Benin? Well, now I know! Thanks to Africa Rice in Benin for helping us add one more to the list.

Many of these countries are supported under our Developing World program. If you’re an education organization in the developing world, please contact us to discuss options.