Hands up if any of this sounds familiar: You’re at your desk. Your headset is plugged into your cell phone to play music. The desktop phone rings. You take off your headset to pick up the handset. Then someone calls on Skype. You unplug the headset from the cell phone and plug in into the computer. Now the cell phone rings. You pick up the cell phone, unplugging its charger in the process. The call finishes, cell phone goes back on the table, charger and headset plugged back in…

That’s what my desktop is like here at PaperCut, and it’s a real pain in the donkey. One day after enough plugging and unplugging to wear out the connections I decided it was time to look for a better way…
(more…)

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.

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…)

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.

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!

The internet is a great place to laugh and poke fun at the grammatical abilities of its denizens. Not that I claim to be such an expert; I just enjoy the occasional entertainment at someone else’s expense. While some, like “you loose” and “your a …” are just plain annoying, there is the odd gem like cereal killer (that link is from FAIL Blog’s Burn of the Week, which has been a bit of a regular for classic grammar blunders).

Fortunately for the grammatically challenged, there are a few factors that save from too much embarrassment:

1. A spell checker
2. Anonymity
3. Obscurity (the fact that very few people are actually going to read what you wrote)

I’d like to highlight an example that failed all three, is possibly the most common misspelling of all time, yet is one I’d never seen or heard of until the other day.

I was recently working on integrating PaperCut’s Payment Gateway Module with the Barclaycard ePDQ CPI service, allowing students (or others) to transfer value from their bank or credit account into their PaperCut account, which they can then use in addition to any print quotas they receive.

One of the security features of the Barclaycard service is to only accept connections from users who have been redirected from a particular URI. This is a feature of HTTP called the referrer URI – our web browsers tell the web page we are visiting where we just came from. This information is valuable for web masters to understand where their viewers are coming from. In this case, only accepting users who have come from a particular URI prevents a malicious site trying to make use of the service.

During development, this turned out to be more of an annoyance than anything. Luckily, there is an easy way to set/fake the HTTP referrer URI in Java:
urlConn.setRequestProperty("Referrer", "http://my.allowed.url/");

Something was wrong though… the above line didn’t seem to be working, or at least Barclaycard was still refusing my connection. Perhaps I spelt it wrong? A quick search in an online dictionary confirmed I’d spelt it correctly. But wait, what was the next entry?

referer

A misspelling of “referrer” which somehow made it into the HTTP standard. A given web page’s referer (sic) is the URL of whatever web page contains the link that the user followed to the current page. Most browsers pass this information as part of a request.

(from the Free On-Line Dictionary of Computing)

Well that was a surprise. Not only did someone misspell the word when formulating the standards document and possibly fail to run a spell checker, but supposedly there was no-one amongst the committee or technical consults that successfully recommended a correction. What a colossal screw up. Even the official HTTP/1.1 specification has this to say:

The Referer[sic] request-header field allows the client to for the server’s benefit, the address (URI) of the resource which the Request-URI was obtained (the “referrer”, although header field is misspelled.)

So, given that HTTP referrer URI is used every time any person clicks a link on the internet, I’ll vote it the most common misspelling of all time.

On the flip side, as Chris pointed out, this misspelling has saved the world a whole heap of bandwidth: 1 byte for every link ever clicked!

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

If you were looking really hard while browsing our knowledge base recently, you might have noticed your Firefox search window glowing. You are using Firefox aren’t you? (get it here) Ok ok, if you’re stuck with IE7 you might have seen it as well. Anyway, the glowing search box is letting you know that there’s a new search engine available on this page to add to your browser’s drop-down list. This means you can search the PaperCut knowledge base quickly from your browser’s toolbar (without having to browse to the search page first).

It’s done using OpenSearch (WP). Basically it allows adding new engines the browser’s list in a standard way (i.e. you don’t have to write one for every browser out there).

The syntax is really quite simple, the bulk of it being contained in an XML file – an “OpenSearch description document”. You can view the OSDD (I just made that up because I didn’t want to type it again) for our knowledge base here.

Most of it is just fluff that may or may not be ever needed/used. The important bit is the <Url /> tag. You’ll notice ours is quite long – this is mainly to do with customising the search results (excluding pages that aren’t relevant to people looking for answers in the knowledge base). A much simpler form of this tag might look like so:

http://somesite.net/search?q={searchTerms}

Then the following line in the <head> section of a page will make it available for consumption:

<link rel="search" type="application/opensearchdescription+xml"
      href="/papercut.osd.xml" title="PaperCut" />

That’s it. The glowing effect in the browser and everything needed to add it to the list of engines is all done for you. Search plugins to the masses!

Hello, world! I’m Tom, the latest addition to the PaperCut development team. Over the last month or so I’ve undergone a lightning induction into the world of programming at PaperCut and the many technologies used – Java, Tapestry, Hibernate, Spring, Jetty, JasperReports, Derby, PostgreSQL, Squid and many others, not to mention developing for Linux, Mac and Windows – an exciting prospect for any graduate!

You may have already noticed some of my additions to PaperCut NG – some new reports including the ‘detailed summary’ reports that show a breakdown by page size, the ‘report based on above data’ component, regex document name filters, and some new web service and server-command calls. I hope to be adding even more features in future, as well as improving our web site. Is there something that you would like to see added or improved? Send an email to the development team and let us know!

Even with the recent first public testing release of Internet Control for PaperCut NG, the fantastic feedback we’ve been getting with the PaperCut NG for Mac testing programme, and recent improvements for running PaperCut in unauthenticated environments, we’ve still got big things on the way. Here’s a quick look at what you can expect in the coming months:

• PaperCut NG 7 – just around the corner!
• Features from PaperCut ChargeBack coming to NG.
• All those little updates that make the software that little bit easier or nicer to use.

We’ve also aggregated the developer blogs to one location, so please update your links if have been following along.

Happy to be on board with PaperCut and looking forward to hearing from you all in the future.

Cheers,

- Tom