- Home Page
Categories
Archives
- May 2013
- April 2013
- March 2013
- January 2013
- December 2012
- November 2012
- September 2012
- August 2012
- July 2012
- June 2012
- May 2012
- March 2012
- January 2012
- December 2011
- November 2011
- October 2011
- September 2011
- August 2011
- June 2011
- May 2011
- April 2011
- February 2011
- January 2011
- December 2010
- October 2010
- September 2010
- August 2010
- July 2010
- June 2010
- May 2010
- April 2010
- March 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- June 2009
- May 2009
- April 2009
- March 2009
- February 2009
- January 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- June 2008
- May 2008
- April 2008
- March 2008
- February 2008
- December 2007
- November 2007
- October 2007
- September 2007
- August 2007
- July 2007
- June 2007
- May 2007
- April 2007
- February 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- June 2006
- May 2006
- April 2006
- February 2006
- November 2005
- October 2005
- September 2005
- June 2005
- April 2005
- March 2005
- February 2005
- January 2005
- December 2004
- November 2004
- October 2004
- September 2004
- August 2004
Monthly Archives: February 2010
If (version > 10) { doMore() }
(This is an older news post that has been migrated into the blog)
If you are a geek, you’ll find that our new 10.1 release contains what is probably the most exciting and highly anticipated feature to date: Advanced Scripting. This feature is targeted squarely at our core audience of system administrators, and is the start of a whole new level of flexibility and functionality.
What have we done? First, we added a script editor to the admin interface:
Browser based script editing
All scripts are written in JavaScript, the most common and well known scripting language. Don’t be fooled however, this kind of scripting has nothing to do with web pages.
The first use of the new advanced scripting feature is to write print scripts – scripts that run when a new print job arrives. Your script can do a whole host of things including checking details of the job and influencing what happens to it. Some examples:
- Displaying a pop-up message if a user forgets to select duplex on large jobs.
- Showing statistics on the environmental impact on large jobs via a fancy popup dialog.
- Prompting the user to confirm large jobs before printing.
- Automatically routing large jobs to more efficient high volume printers.
- … and much much more!
So what does an actual script look like? Something like this:
Example print script
The user manual contains a new Advanced Scripting chapter that will help to get you started. Happy scripting!
As usual the full list of changes can be found in the release histories for PaperCut NG and PaperCut ChargeBack.
P.S. If you have a novel script idea or just a comment or suggestion about the new feature please let us know!
Posted in Releases
Leave a comment
Customer Feedback Time!
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.
Posted in General
2 Comments
Quicker than a human… maybe even smarter than a developer!
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.
Posted in General
Leave a comment
We’re hiring again! This time for a developer
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!
Posted in General
Leave a comment