Spaghetti Cables

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…

Ye Olde Printer Share - the LPT switch!

What I did find was plenty of audio/video switches for RCA plugs – the kind you would use under an old TV to switch between TV, VCR and DVD. This formed the basis of a crazy plan: could I use an AV switch for desktop audio? RCA has three plugs – two for audio, one for video. Surely I could just use the video plug for the microphone and I’d be set?!

I went to work finding all the parts. These arrived in bits and pieces over the next few weeks, at prices I don’t attempt to comprehend (one connector was shipped from Hong Kong in an envelope with a hand-written address, and the total price was less than a dollar!). All going to plan, this setup would allow me to:

• Listen to music/audio from my cell phone, and answer calls.
• Listen to music/audio from my computer, and answer calls (on VoIP / Skype).
• Answer calls from my desktop phone.

And if I wanted any of that on my desktop speakers, I’d just need to turn them on.

Here’s how it fit together:

I have no idea what some of these connectors are really used for

And… it worked! Kind of.

When switched to the desktop phone there was a loud static hissing. When switched to the computer, Skype wouldn’t recognize the microphone (although other applications worked fine). Perhaps both of these were due to the poor quality switch? In any case, the setup didn’t cut it.

What’s the next step? These days many modern headsets plug into computers via USB. This means they don’t use the computer’s sound card, but rather emulate their own. This allows the headset to produce/emulate surround sound, have a microphone, add mute buttons and other buttons all sharing the one USB plug. Obviously the audio switch setup above can’t be used with a USB plug, but if everything was in the computer and managed by software then the problem goes away – you could just switch between inputs and outputs in your OS’s sound properties.

This shift from hardware to software is the inevitable evolution of many technologies. This includes printing, as Peter pointed out in his post on the history of digital printing and of course demonstrated clearly by the fact that we don’t use hardware printer switches today! Putting these functions in software allows for ultimate flexibility in switching, control and automation. When someone is calling, the audio can die down and pause, and afterwards the audio resumes, just like happens on cell phones today.

All of this seems like it should be technically possible, but the devil is in the details. Does anyone have a desktop audio success story to share? How do you manage your audio devices in the office or at home?

Image “Project 365 #318: 141109 Spaghetti Junction!” by comedy_nose / CC BY

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.

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!

Software Support Specialist

• Smart customers, smart colleagues.
• International customer base – work with sysadmins from around the world.
• Influence the direction of our actively developed software.

The Company:

PaperCut Software is an Australian software development house based in Mount Waverley, Melbourne. We develop print, copier and internet control software that is used worldwide in over 60 countries and 20,000 organisations. We are a small team of IT adepts who love to talk tech. The work environment is casual and the organisational structure is flat.

Our customers include many high profile education and business organisations, such as Harvard University, the University of Cambridge and Allianz.

The Job:

Our software is installed and configured by our customers’ own system administrators, such as the IT department at a university. These sysadmins inevitably have questions about our software or how it integrates with their environment.

Your job will be to assist our customers with any questions they may have. This will require a thirst for knowledge and ability to easily learn technologies, as questions and customer environments are diverse. The majority of our support is conducted via email, but we also use phone calls / VoIP, live web chat, remote access software and on rare occasions on-site support or training.

Many customers operate multi-platform environments including combinations of Windows, Mac, Linux and Novell servers and workstations. As you might imagine these are not your typical end-users; they are some of the world’s top system administrators – less RTFM, more challenges. Topics can range from print queues, directory servers, login scripts, databases, resource management, virtual machines, clustering and of course bugs in our software to name a few.

This is not a typical support role and is certainly not a call centre. You’ll be working in a small, tight-knit team and will be responsible for converting customer ideas into implementations by working directly with the developers.

As we are a small company opportunities will arise to work in other areas that interest you, such as managing internal systems, testing our software with new operating systems and applications or working on the software itself.

Required:

• Minimum 3 years commercial experience in system administration, product/system support or a related field.
• Excellent communication skills.
• Proven aptitude for troubleshooting.

Preferable:

• Diverse system administration skills (multiple platforms a plus).
• Scripting or programming experience.
• Experience using sysadmin tools to diagnose issues, such as Sysinternals utilities.

To Apply:

Express your interest to Tom Clift by sending your CV and cover letter to jobs@papercut.com. Applications close November 6.

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!

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!

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

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!

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