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!

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