Welcome to the first 2010 PaperCut Vote for a Feature!

After the fantastic success we had we our last vote for a feature we’re going for another round! Our last Vote for a Feature Survey focused on Big Ticket items. This time we’re evaluating the “smaller items” that can have a big impact – the small little things that can help make your life easier as an administrator/user. The goal of this round of voting is to determine type of small features help out the most.

You can access the latest Vote for a Feature survey via:

• Administration console -> About -> Product News.

PaperCut is considering sponsoring a public mailing list enabling all users to share ideas and innovative print management practices with each other. If you are interested in this please enter your email into the space provided in the survey.

When I first started as an intern at PaperCut in late November I didn’t now what to expect. As I first entered head office in Melbourne, I mentally prepared myself for all the usual mundane tasks that interns are inevitably assigned to (fetching coffee being at the top of the list). Now, being almost three months down the track, I can confidently say that my experience here at PaperCut couldn’t be any more personally and professionally fulfilling.

During my first two weeks at PaperCut I quickly realised that quality assurance was a BIG thing. Any new release candidate for PaperCut goes through a stringent testing process. For a period of time all development stops, and the whole team gets their hands on the newest version. We then go through a check-list of features to test, all of which must be tested on each supported operating system (Windows, Mac, Linux). Testing is no small thing here at PaperCut, it’s an intense process designed to catch as many bugs as possible in our print management software.

So, after I had settled in at PaperCut, Chris asked me to look into how we could increase the effectiveness and efficiency of our testing process. PaperCut has been using automated unit testing (testing of individual software modules) for a while, but Chris pointed me in the direction of automated functional testing. In affect, automating the manual testing described above.

Functional testing is the testing of the software as a whole. This form of testing provides benefits that are unachievable using unit testing. While unit testing is still useful for ensuring we don’t make any silly mistakes in small parts of of the product, functional testing is essentially simulating a user interacting with our software.

How is this all done? Over the past two months I’ve designed and written a framework that uses existing, mature software (including Selenium). I then used this functional testing framework to create scripts that simulate tasks that most users would do every day, syncing groups/users, editing printer properties, generating reports, performing printing.

It does this all by opening up a web browser and interacting with the user interface of PaperCut. It’s is completely automated, robust, and many times faster than any human. Below you can see a little demonstration of the testing at work, this test, which is one of dozens, is designed to generate every report and ensure that they successfully completed.  This process was previously done “by hand” and took 30 minutes or more:

The automated testing framework is designed to help us accomplish two things; firstly, we don’t want to catch ‘most’ bugs, we want to catch all bugs. By reducing the potential for human error involved in our test processes, we increase the quality of testing. Secondly the speed at which these tests can be completed not only increases the amount of the application that we can test, but it means that the development team has more time to continue improving PaperCut.

This automated testing was used side-by-side with regular user testing, and unit testing, in the latest version 10 release, and will continue to be integrated into our standard testing procedures in the future. Automated testing was never intended to replace good old-fashioned manual testing, but it is my hope that it will allow us to provide an ever-increasing quality of service.

Last week we released PaperCut 10.0 with the much requested “Printer Groups” feature. But we’re not standing still. All our developers are working hard to implement the new ideas that you’ve been asking for. As you can see from our release history the product continues to improve with each release. But we want to do more … much more … and faster!

And to do that we need another fantastic developer to join the PaperCut team at our head office in Melbourne. If you’re interested, or know any friends who might be … please read on and apply.

The full position description is included below. If you’re applying mention that you read our blog for bonus points!

(more…)

As time goes on we increase both the number of features in our software and the number of customers using it. Because the developers of PaperCut also provide customer support, there is a balance between the two that continues to tip towards support as the number of customers increases. When the team starts to feel like our rate of development is slowing it’s time to increase the size of the team (someone suggested reducing the size of our customer base but were promptly shut down).

Traditionally we’ve hired only software developers. This is good for keeping up development pace, and our customers are happy to speak directly with the developers for support. There is a gap, however: when developing PaperCut we work with programming languages, web technologies and APIs. When supporting PaperCut we deal with print queues, user directories and databases. While we know a lot about the technologies our customers use, our expertise is in developing software for our customers. It became clear that we want someone who knows all about the technologies our customers use to help our customers use our software with those technologies. It became clear that we want… one of our customers.

The full position description is included after the break. If you’re applying mention that you read our blog for bonus points!

(more…)

Well done to Dennis and his team from Latvia. PaperCut is now available in the Russian language. This brings PaperCut now to 20 languages with a few more on the way. This was our first language using the Cyrillic alphabet. We had to overcome a few issues with the PDF reports, however the process generally went very smoothly. Most of the bugs with dealing with non-latin character sets came out when we did the Chinese translations a few years back.

Welcome to all the new users in Russia, CIS & Baltic States.

Click for larger view

Back in 2001 we received an order from Mercy Ships. After an online search into “Mercy Ships” it was decided it would be a nice gesture to give them PaperCut as a donation.

How thrilled we were at PaperCut to receive a letter this week by regular post.

The letter, from Mercy Ships, was a thank you for our continuing support, providing them with PaperCut and free upgrades and support over the years.

There was an outline of the work that Mercy Ships program.

Mercy Ships have a mission to the world’s impoverished people.

Several Mercy Ships programs address the various needs in many surgical areas, community development and also in the training of nationals. One area that has been especially helpful is the Hospitality Centre Eye Clinic in Benin, Africa.

One month after having cataracts removed, eye patients return to the Hospitality Centre Eye Clinic for additional procedure to prevent a film-like layer developing over the lens and impeding vision ……. many patients who have been blind for years by cataracts can now see.

This news, shared with all our staff, gave us all a great feeling and we are happy to be a part of helping Mercy Ships with their work.  Check out the video here to find out more about what Mercy Ships do.

All the best Mercy Ships, PaperCut is glad to be a small part of your journey.

We were amazed a few weeks ago when a customer from Germany emailed to inquire about an upgrade from version 1.0. Wow! We emailed back asking them to confirm. “Are you sure you’re running version 1? That’s almost 10 years old!” Sure enough the customer was correct. They were customer number 47 and purchased and installed PaperCut almost 10 years ago. It’s been running perfect ever since but they needed to re-install and had lost the key. I thought some of our other users may be interested to know more about this story so I emailed Marco and asked him if he’d answer a few questions for our blog. Not only did he oblige, but the team at Landkreis Calw have written us a poem!

This is a good story but also a catch-22 for us! In some ways it’s a testament to the longevity of our programming, but on the other hand, we’d love to see sites upgrade more often

We have a very international customer base covering over 60 countries. It’s always nice to hear stories like this. If you’d like to share your story please email us at support.

Here at PaperCut we develop software that’s used in every region of the world. Most of our customers are in USA, Canada, UK, Australia, Brazil and China. However there are thousands of customers in more exotic locations. We have customers located throughout the depths of Africa, the middle east, the channel islands, and even a small tropical island.

Developing software for the world represents unique challenges. The most obvious challenge is ensuring that every facet of the application is translatable. PaperCut is already translated into over 15 languages which shows that we’ve done this bit right. You also need to make sure that you are 100% Unicode aware so that you can handle all characters, like Chinese, Japanese, Korean, Russian, etc. Again, PaperCut handles all this with ease.

But occasionally we encounter a problem or unexpected behaviour that only affects users in a particular region in the world. A few weeks ago we had one of these problems. In this case the user was reporting a problem where they were unable to run any PaperCut reports. We obtained debug logs that showed the error details, but even with this information we could not explain the problem. In the end it was the customer that helped find the problem. They reported that if they changed their “language” to “English” the reports worked, and if they changed the locale to “Turkish” the reports failed. Aha!! With that information we reproduced the problem.

I won’t go into all the gory technical details, but it turns out that the problem was that in Turkish the letter “i” when converted to uppercase becomes “İ” (unicode character 0×0130) which is an “I” with a dot above it. Some of our code has assumed that if you uppercased “i” it would become “I”, and when this didn’t occur the report failed to run.

As they say, you learn something every day. And we did! We learned that when dealing with text in different locales around the world … assume nothing.

We’ve now fixed this problem and this fix is now available in our 9.3 release. And with this release PaperCut is available to another large group of users. Prior to this Turkish users needed to run PaperCut under an English/US locale.

Now all we need is a Turkish translation. If you’d like to help translate PaperCut into Turkish (or any other language!!!) then let us know. We’d really appreciate your help.

editor’s note: The development team has given Tom 10/10 for his beer and has asked him to bring some more in for us all to enjoy!

The programmers here at PaperCut all write print management software for a day job, but have varied and often somewhat eccentric hobbies out of hours. I’d like to share with you one of my recent discoveries: all-grain brewing. I’d hazard a guess that home brewers are disproportionately represented amongst all you techies and readers of this blog, so hopefully you’ll find this interesting.

As an engineer and lover of beer it was inevitable that one day I would pose myself the question, “how does this beer stuff work and how can I make it?”. I’d been put off for many years because the only home-brew I’d heard about was to brew from extract. In summary, extract brewing means:

• Buy a kit from the supermarket. A kit usually has malt extract, hops and dry yeast.
• Boil the malt extract with water and the hops.
• Put the result into a fermentor with the yeast.
• Put the result into bottles with some sugar.

Well that’s easy enough, but it’s not exactly an art form. How can you change the flavour of the beer? By choosing a different kit, and maybe by varying the boil or amount of hops used. That’s why extract brewing was completely disinteresting to me. The value proposition seems to be that you can make beer cheaper than you can buy it, which is really only because you don’t have to pay alcohol tax to drink your own home-brew. To me it was like trying to be a handyman by building Ikea flatpacks.

Then I discovered all-grain brewing. Not only is all-grain brewing possible to do at home, it’s actually quite easy and doesn’t require much additional equipment. Rather than using malt extract all-grain brewing involves starting with malted grains (a sack of grain, available at brew shops) and extracting the sugars yourself. This is “real brewing”, and allows you to take on any style of beer you can think of by varying the malts, water, hops, yeast, sugars and other additions.

One site that was a fantastic guide for me while learning about brewing was the aptly named howtobrew.com. This covers a lot of the theory behind brewing, as well as guides for building some of the specialised equipment.

from howtobrew.com’s instructions for building a piece of brewing equipment: a mash/lauter tun and manifold

For the first batch my brewing partner and I decided to start with a beer that would require as little “modification” as possible. When extracting sugars from malt the water quality is a big factor. Basically: the harder the water, the darker the beer. This is why Dublin, with its very hard water, is known for its dark stouts, and Pilsen, with its very pure/soft water, is known for light coloured beers (and the Pilsner style). Melbourne’s water is about as pure as it is in Pilsen, so we settled on a Pilsner.

The one thing we didn’t count on was fermentation temperature. A Pilsner beer calls for a lager yeast, which ferments best at around 9°C (48°F). This might not be a problem in Pilsen, but in Melbourne that’s almost impossible without refrigeration (unless you want to leave it outside in the winter, in which case you’d risk freezing it). Ale yeasts on the other hand call for a temperature of around 20°C (68°F), which is much more achievable. So the result was a “Pilsner ale”. Not exactly a recognised style, but that’s part of the fun.

We couldn’t have been happier with our first all-grain batch. It’s encouraged us to learn more about the details (and there is a lot to learn) and to try other styles of beer. Fermenting now: a strong Scottish ale.

If you’ve got some brewing experiences to share I’d love to hear about them in the comments!

This blog post continues to focus on our support quality and builds on the graphs and analysis from my post two weeks ago. This time however, the graphs are not static but updates in real-time! Read on for the exciting details.

Offering good support is a balancing act – a compromise. How much developer time should we allocate to support? Being software developers (a.k.a. Tech Geeks), we’ve always wondered how we can measure this balance. I then had an idea… In the last “Vote for a Feature” survey I decided to add the following question:

PaperCut’s support is done direct by the development team. Should the developers allocate more time to supporting customers, more time to development, or do we have the mix about right?

[a range to select]

It’s a bit of a loaded question and hence the results needs to be taken with a grain of salt, but still is sure to give us some level quantitative feedback (and the sample size is now large enough to pass a significance test, just to bring back bad memories for those of us that did Stats101 .

With over 20,000 organizations running PaperCut, our surveys collects a lot of data. I started crunching the figures so I could email the results around to our development team, but half way through I had an idea. I could do one better. How about a real-time graph for the world to view! Anyway, after a late night playing around with some Google Docs APIs I’ve come up with a solution.

The gauge below represents the current real-time results of the survey data:

• If the gauge is at the top in the green range, we have the mix right.
• If it leans to the right (positive), our users are suggesting that we should spend more effort on new development and a little less on support.
• If it leans to the left (negative), we should spend more effort on support and and a little less on new development.

You’ll need a modern SVG enabled browser (e.g. Firefox) to view.

The gauge above is live. As of 27th of March, it’s at 4.76% suggesting we have the mix right. If you think the gauge should be leaning one way or the other, make sure you log in and express your vote! Anyway, too much time playing… back to adding new features to our print management software as the gauge currently suggests!