Djangosites Open Sourced

Back in 2008 I started as a listing of websites powered by Django. Prior to that, we relied on a wiki page to see who was using Django, so an image-based website felt like a big improvement.

Since day one I've promised to release the source code that I use for the site. It's relatively simple, so I never stressed much about making it a high priority - but I continue to be asked and politely berated for not getting it published.

Today that's changed. I think it's too late for me to say I've come good on my promise, but the Djangosites source code is now available on GitHub.

The README has more details, but in short this is a dump of the code currently running the site. I'll continue to use this repository as changes are made to the live site, however I'm not actively working on djangosites at this point in time (other than reviewing & approving submissions)

There's a few pieces of this that might be useful for people new to Django, but otherwise this is really a collection of generic views. The useful bits might be:

Suggestions and pull requests are welcome, but I'm not actively soliciting changes. I should probably clean things up a bit given that this codebase hasn't changed materially since Django 0.96, other than slight refactors to allow upgrades to work - so I'm certainly not yet taking advantage of new functionality that's been made available in recent Django versions. Perhaps now you can see how bad the code is, I'll have more of an incentive to fix it :)

The source code is available right now from GitHub under a mixed licence: the Python code is MIT-licenced, and the rest (HTML etc) is not open source but included in the repository for completeness and as an example.

Payment processing options for Australian startups - 2013 Edition

Not that long ago, startups and hobby businesses had very few options for accepting online payments here in Australia. We could sign up with a merchant facility with a bank (with minimum fees over $100/month) and then pay to use eWay or similar gateways (again, for a few hundred bucks a year), or we could use PayPal.

As services such as Stripe launched in the US, us Aussies felt a bit left out. Our tightly regulated banking industry didn't seem welcoming to new players, or so it seemed.

Throughout 2013, a number of new players have become available in Australia.

Since launching WhisperGifts we've begrudgingly accepted PayPal payments. Although PayPal is pretty ubiquitous, the user experience leaves a lot to be desired - sending your ready-to-buy customers to an external website for payment looks amateurish, regardless of how much custom design that external party lets you do.

The three key players as of today are Braintree, Pin Payments, and Stripe. Having tried each of them for WhisperGifts, I'm ready to write up my thoughts and recommendations.

Common Features

As far as I'm concerned, all three services cost pretty much the same. All have no monthly fee, a 30c per transaction base fee, and a small percentage per transaction (ranging from 2.4% for Braintree to 3% for Pin). I do pretty low transaction turnover, so at this stage I'd rather pay a slightly higher per-transaction fee than a monthly fee.

All provide Javascript-based payment processing libraries, allowing you to put a form on your own website that POSTs encrypted credit card details to your server for processing. None of them require a customer redirect for payment.

Lastly, all three have similar functions for storing credit cards for future or recurring use. Braintree and Stripe have explicit recurring billing functionality built in (ie they handle the recurring billing themselves), and Pin Payments has a relationship with Spreedly to manage this, albeit at extra cost. If you do your recurring billing yourself against a pre-saved customer token, all three are sufficient.


Braintree Payments are an American company, who launched in Australia in late 2012. The service is solid, having had a few years to mature in the US market, although their initial Australian offering had a minimum monthly fee of $50. These days, there's no monthly fees.

Their web console is also quite useful, although after getting started with them I had a major gripe: The underlying banking relationships are just too messy. It sometimes feels like Braintree are an old-style bells-and-whistles gateway, who have cut fees to appeal to startups and small businesses.

When you sign up for Braintree in Australia, you're actually opening a merchant facility with the National Australia Bank. This isn't made clear during the initial process, however it's abundantly obvious when you come across any issues: My first settlement from Braintree took over a month to arrive, due to the NAB refusing to pay proceeds to my personal bank account (I run as a sole trader; my legal entity name doesn't match my trading name. This is normal.)

This led to a long process of opening a new business bank account in my trading name, simply to get paid by Braintree. But it wasn't pretty - after I started interacting directly with the NAB, I began to be charged all sorts of fees that Braintree must normally abstract / negotiate away. Every interaction with the NAB seemed to cause a regression, and the NAB business bankers really don't understand the relationship with Braintree.

Not all of this is directly Braintree's fault, of course - but it still soured my experience. Regardless, this banking relationship has it's benefits: Braintree do settlements within a couple of days.

Braintree is now owned by PayPal, however the public messaging is that they'll remain as-is for now. Support times were somewhat slow, as it appeared to be done out of the United States (despite an Australian office). This meant multi-day to-and-fro email conversations to get issues resolved.

Pin Payments

The first Australian payment provider (that I know of!) to launch was Pin Payments, who hit the scene with a public beta in early 2013. I joined up pretty quickly, as their beta participants received a no-monthly-fee account. After their public launch, the fee jumped to $30 however there is again, as of October 2013, no monthly fee.

Transaction fees are pretty normal, at $0.30 + 3%. Some foreign payments attract conversion fees, which you should be aware of.

Pin's API is fantastic, as is their web console. I released an open-source Pin Payments library for Django which is easy to use.

The relationships with banks are abstracted away to become almost invisible, however the signup process asks questions typical of a merchant facility. This suggests to me that they're doing a lot of work under the covers to hide that bank relationship, which is fine by me.

There's two things, however, that I don't like about Pin at the moment.

Firstly, your payment form must collect the full address of your customers, rather than just their credit card details. As I'm selling an online service, I don't need these details for any other purpose and would rather not collect them. I can appreciate the fraud management use of this data, however if I can get away with keeping it off my signup form then I'd prefer to do so.

The second irritation is that Pin will email your customer a payment receipt. This means that you must share your customer contact details with Pin, and the customer begins to see the plumbing of your payment system as the Pin email includes their logo and contact details. When I contacted Pin about this, they mentioned that there might be an option to disable it in the future if you agree to email a receipt yourself - although this is still in the pipeline.

Settlements take seven days, which might be an issue if you rely on the cashflow - however they don't hold any balance other than this. Support was fantastic, with quick responses. This is the joy of having a vendor in your own timezone!

Update January 2014: Chris from Pin Payments was nice enough to reach out to me after this blog post to address my points above. With his permission, here's the meaty bit of of his email:

Pin Payments are able to switch off the e-mail receipt sent to customers, and set the billing address fields to be optional. At the moment you just need to e-mail the team at

Something else that's worth noting when comparing is the multi-currency support we provide. Currently you can bill in 6 currencies. This is seriously powerful for Australian companies looking to go global, or even being able to tap adjacent markets like NZ.

Changing the e-mail receipt and billing address were a big deal for me, so I'm likely to switch back to this Australian-based provider. Now, back to the original post! End update


Stripe were the first company since PayPal that I remember seeing turn the payments industry upside down. For a long time, foreigners looked at websites using Stripe with awe, thinking "If only we could do that!".

In August 2013, Stripe launched in Australia. They're still in Beta, but it's easy to apply.

In my opinion, Stripe is the benchmark in simple payment processing and it's clear that Pin have somewhat modelled themselves on Stripe. I can't blame them.

The signup process is incredibly simple, and there's no multi-day account setup or validation (you do, however, have to provide copies of your drivers licence or passport to meet Australian banking laws). There are many, many third party libraries for Stripe - they are very well supported. The only fields you are required to have on your site are the credit card number, expiry, and verification code - no address or e-mail address.

Like Pin, payments are settled after 7 days.

I haven't yet needed to contact Stripe support, however I wouldn't be surprised if I saw similar wait times to Braintree.

Final Thoughts and Recommendations

Since none of these services have signup or monthly fees, I'd highly suggest signing up for yourself to try them out. The barrier to integration is pretty low (especially compared to PayPal) and all have mature APIs and third party libraries.

For my use, I'm currently sticking with Stripe. It ticks all the boxes for me, is easy to use, and doesn't have any quirks that impact me. If Pin end up simplifying requirements for payment forms to only collect payment card info, and stop sending my customers an email, I'd prefer to use them due to their being Australian owned and operated - something I have major respect for.

The online payments industry in Australia is currently undergoing quite a bit of a transition. In less than a year we've seen two major foreign players launch locally, and have seen a home-grown company get off the ground with quite a bit of success. The next year or two are going to be really exciting, as it finally seems that we can launch a small startup in Australia without the long and expensive process of applying to accept credit cards. I'll drink to that.

Eulogy for my father

Three weeks ago, on September 4th, my father Phillip Harry Poulton passed away at age 58 after a brief battle with cancer of the gall bladder. The toughest thing I've ever done was read part of his eulogy along with my siblings, mum, and Dad's friends.

I'm very proud of my Dad, and I'm happy with the stories about my time with him that I was able to squeeze into the few short minutes that I spoke.

Below is one of my earlier drafts, which has more detail than what I read at his funeral on September 11th 2013. At the bottom is a video that was recorded - I've included this for friends and family who weren't able to make the service - I assume it isn't fascinating viewing for anybody else.

A number of newspaper notices were placed for my Dad, from friends, family, and his colleagues. You can read tributes to Phil Poulton on the Herald Sun website.

Like most people, I learned a heck of a lot from my Dad. Chatting to my siblings it was clear that we all saw Dad in much the same way - he was genuine to everybody he met, and didn't filter his personality to suit the audience.

Dad married my mother, his first wife, and they renovated their home together in Ringwood. I was their eldest child, but not their first pregnancy - Dad helped mum through a miscarriage in an earlier pregnancy, setting the scene for the strong role he'd play for the rest of his family life. The fernery in their Ringwood home was expanded as a small memorial for their unborn baby.

We moved to Mitcham before I started school, into a house that was continually being worked on.

Before Benn started school, Mum and Dad showed us the world. We moved temporarily to the UK for a working holiday, to a small town outside Cambridge called Royston. My memories are foggy but fond, and seemed to involve more time driving our little Ford hatchback around Europe than we did at school or work.

Whilst in Royston, Mum discovered a lump - she was diagnosed with breast cancer. The UK jaunt was cut short, and we returned home for treatment.

In 1992, Mum passed away. Benn was 6, and I was 9.

When I look back on my hero father, it's from this point forward that he really deserved that badge. He was a widowed father of two young boys, working full time, running regularly, but he couldn't cook to save himself. For a short while, Benn and my diet consisted of sausages in bread and "fruit cake" - but I use both words loosely. Sue recently reminded me of the recipe, which was a grand total of 5 ingredients: flour, bran, milk, dried fruit, and sugar. You'll notice a distinct lack of eggs.

Apparently such a loaf is fantastic for endurance runners, but Benn was lucky enough to get one for his birthday one year. It seems to be one of the few things for which he hasn't forgiven Dad.

Even through this grief, the accountant in Dad kicked in. Although he was working hard at Heritage Seeds, and trying to keep up with Benn and I, Dad made sure mum's teachers superannuation was shared between Benn and I - a forethought that gave both of us a huge help to buy our first homes.

Alice and Bill, my maternal grandparents, were and still are a huge part of our lives. They often lived with us, and us with them. Dad still called grandpa "Dad", even though there they were inlaws.

A while after Mum died, new neighbours moved in, so Dad went over to introduce himself to the lovely blonde who had started making a new home with her two kids.

My memory is hazy, but I'm told that it was Ben and Benn who became great friends and knocked a hole in the fence. Something tells me that's only part of the story, since I doubt Dad would have let a primary school kid loose on his fence with a powersaw - but soon after, we were a regular fixture for dinner at Lesley's house.

I'm sure Dad would have hosted Lesley, Ben, and Tash for dinner, but he was trying to make an impression - and sausages and cake wasn't going to help his cause.

Soon after, we found ourselves living together as one family here in Eltham. Dad always seemed to have a love for Eltham, especially for places such as Montsalvat where we are today - lots of trees, lots of timber, and other eclectic building materials. Many of you will know of our first house in Eltham, a timber and mud brick house that was always being extended upon. This theme of always improving was one of the biggest that rubbed off on me, as evidenced by the number of half-finished jobs around home.

My time in Eltham was my true formative years: I started high school, made lifelong friends, and really got to know Dad's own lifelong friends. As time went on, I learned more and more about the world, much of it from Dad's viewpoint. I was learning from Dad until the day he passed away.

Dad got me my first job, doing work experience with the company who looked after the computers at Heritage Seeds. As a result, through a series of buyouts and cross-training, I've never had to interview for a new job - yet I've ended up working somewhere I love with a fantastic group of people.

We often spoke politics at the dinner table, although we rarely saw eye to eye. The weekly dinner table was where we bought our own growing families, to talk with and learn from Pa. It was also the scene for the infamous "Sonos Battles".

Us four kids had always considered Dad a bit of a ... let's just say he was an Accountant. Fads, trends, and new stuff wasn't his cup of tea, and as he held the cash we weren't likely to be sporting new video games or the latest Nikes.

When he moved to the new house at Wombat Drive, something seemed to change. Maybe it was because we weren't in his back pocket all the time, but suddenly there was a huge TV. Then two more, just in case.

The old record player was put on the nature strip, and a top of the range surround sound system found it's way into the living room, along with a remote-controlled music system.

It became a bit of a game at Sunday dinner to see who could choose a song that would actually get played through to the end. One of us kids would chose something contemporary, and we'd all happily hear the first half of the song. Dad would then decide that he'd like to hear Aretha Franklin, so he would pull out his phone and queue up an Aretha Franklin song. Well, he tried to - but every time, without fail, we ended up with the entire Aretha Franklin back catalogue, including live versions, cover songs, and interviews. And he didn't just queue them up to play after our one song - he stopped the song hard halfway through, and we'd hear the opening bars of "R.E.S.P.E.C.T", followed by her rendition, as lovely as it was, of "Bridge over Troubled Water".

Dad was a pretty non-technical person, who still did his banking with bits of paper. To watch a new guest arrive for the first time was amusing, as they tried to deal with Dad's excited demonstrations of wireless music selection. Who would have thought that after a life of collecting 8-tracks and then records, that he'd be most enthusiastic about music over the internet.

Watching him in the last few years I learned a few other useful lessons. It turns out, that a caravan cannot be too large. It also cannot have too many gadgets. Once the gadget-laden caravan arrives, there's no reason not to go out and buy more gadgets to go in it.

It turns out it's also OK to wear shorts. Dad was particularly rapt one night after going shopping on his way to running, having had a stranger at the supermarket yell out "Nice legs!".

Even when we landed in Nepal, our Sherpa guide, Lhakpa, asked with a concerned face, "Mr Phil, do you know you are in Lukla?". Dad was doing us proud, surrounded by the permanently ice-capped Himalayas - wearing his shorts.

Dad also taught us that coffee is a great way to catch up with friends and family. Meeting for Saturday coffee was as important as Sunday dinner, as Ollie sat on Pa's lap to eat his muffin while we slowly started our weekends. More recently, we'd started bumping into each other at the coffee shop before work. It was a nice coincidence that we started going out of our way to foster a few days a week, even if it was only a 2 minute chat while getting a take away coffee.

But above all, Dad was all about family and friends, tied together by music - and he used it to make us laugh at the saddest of times.

Last Wednesday afternoon, with friends and family sitting in the sun at home, we put on a playlist Dad had built called "Phil's Favourites". Of course the first 5 hours was everything the Rolling Stones have ever had a part in, but the music kept going, and going, and going. I guess that's the advantage to adding entire discographies to your playlist.

As the evening wore on, we knew what the outcome would be. With twenty of us surrounding Dad's bed in tears, we kept talking to him and listening to the music he queued up.

Then, some of the worst music interviewing I've heard came onto the stereo and filled the room. I have no idea who it was, or why an interview was even on Spotify, but his living room was filled with noise we didn't want to listen to. We reached for Dad's iPad, to try to get back to the music - but it refused to work for us. His horrid music management made us all laugh, both with him and at him, at a time when we should have been in tears.

Luckily we fixed the music, and soon after Elton John's "Candle in the Wind" came on. It was quite possibly the last music he ever heard.

The messages and support I've received from everybody around me has been simply amazing, for which I'm eternally grateful. Good friendships make tough times that little bit easier.

Dad's gall bladder cancer was rare and aggressive. In his memory, we've been raising some funds for the Forgotten Cancers Project at the Cancer Council of Victoria. More research into this cancer might help extend the lives of future patients, so that they may spend more time with their families than the three months we got with my dad.

Tracking CPC Results in Django

Like many startups, I use CPC ads to attract attention to WhisperGifts. I bid a set fee per click for particular search words on Google, and for ads shown to my target demographic on Facebook. I wanted to track an individual signup to their source CPC campaign, so put together a really quick bit of Django middleware to help me out.

All I do is stash the value of utm_campaign (set by Google or Facebook) into a cookie called wgcookie.

class CampaignMiddleware(object):
    def process_response(self, request, response):
        from registry.models import Campaign
        if 'utm_campaign' in request.GET.keys():
            if 'wgcampaign' not in request.COOKIES.keys():
                # add campaign cookie
                c = request.GET.get('utm_campaign', None)
                response.set_signed_cookie('wgcampaign', c, max_age=31536000, httponly=True)
        return response

At signup time, I read out the cookie into the users table:

    campaign_code = request.get_signed_cookie('wgcampaign', None)
    campaign_code = None

user.campaign_code = campaign_code

Simple! I've now got the capability to track actual revenue by campaign source - a very handy tool to identify which campaigns might warrant higher or lower spending.

I'm aware this isn't rocket science, but I figured it's worthwhile sharing - it makes more sense to me to track these things directly in my own database, than to try and match data from the AdWords panel with various analytics services.

Happy CPC bidding!

Moving to FastMail

I've been a long-time FastMail user, and they make me happy. For various reasons I never liked using Gmail, although I never tried Google Apps for Domains. Max Masnick recently wrote a post on his move from Gmail to FastMail and experience is close to mine - and his migration tips are useful for all, not just Gmail users.

If you're looking for a fast, sturdy, secure, easy-to-use third party mail service for yourself, your family, or your business, I can highly recommend FastMail.

New Podcast: Django Roundup

Lincoln Loop are one of the earlier Django-based development shops, and their various employees contribute in many ways to the open-source community. One new addition they've just made is the launch of Django Round-Up, a podcast covering the news in the Django community.

This is a podcast hosted by @kennethlove and @bkonkle from @lincolnloop that highlights recent articles and projects in the Django community. We love talking about web development, so our podcast focuses on casual conversations as we cover the latest blog posts and project releases.

I was surprised to hear my name coming through my headphones, only a minute into their first episode - with a quick review of my recently-published django-readonly-site package.

As a result of their comments I've made some minor updates to address questions and suggestions from the podcast team.

I want to publicly thank them for including my item in their inaugural episode, and suggest that anybody in the Django community goes out and checks out this valuable new resource!

Day & Night Phones (Or: Why I Carry Two Mobile Phones)

I carry two mobile phones, for most of the week. I have a personal phone which I use to call friends and family, to read my personal e-mail, access social media, and play games. My personal phone is almost always in my pocket, unless I'm in a work meeting or giving a presentation.

I also have a work phone. It is only used by clients or co-workers to call me about work-related matters, to access my work e-mail, and access our internal CRM systems. The nature of my job means that nobody typically calls me outside of working hours - so my work phone is in my pocket during the day, but very rarely at night.

Often, somebody will see two phones on my desk and ask the obvious question: "isn't one enough?" The recent talk about Silicon Valley executives carrying two phones got me thinking about this a little more.

There's no doubt that I'd prefer to only have one phone, however it isn't that big a deal. My work and personal lives rarely overlap, so I don't miss calls. Most of my work involves sitting at a desk with my phones on the desk, so I don't constantly have pockets full of mobile phones.

So why do I do it?

I want two phone numbers for the same reason I have two e-mail accounts - one for play, one for work.

My father has recently left his job. He's been there for over 20 years, so his work e-mail address was his first e-mail address, and his work-provided mobile phone was his first portable phone. Whenever somebody asked for his phone number or e-mail address, he gave out his work details.

Now, as he moves into retirement, he's left with the burden of updating his e-mail address with every person and organisation he wants to keep an online relationship with - from Facebook to overseas friends to his newspaper subscription. He's lucky that he's able to keep his phone number, so that's one less thing to change.

I won't be so lucky. When I move jobs, I'll most likely stay in an industry close to what I currently do - so my employer is not likely to let me keep access to my e-mail account or to let me take my phone number, along with all of the contacts and business benefits it brings.

As part of the generation who got mobile phones and e-mail addresses before getting a job, I didn't want to go through that hassle when I move on from my current job. Now, watching my dad go through the process as he wraps up his career, I'm glad I made that choice.

And, if I can let you in on a secret: Sometimes I carry three phones, so I can test stuff out for work. I'm the sole user of no less than five 3G/4G devices. Connectivity is actually rather useful.

Tools I Can't Live Without (2013 Edition)

I'm not one to jump from productivity tool to tool to try and become 5% better. In fact I use very few such tools, preferring to keep things simple instead. However over the past few years I've collected a short list of extremely valuable tools that I think it's safe to say I cannot comfortably work without. I often recommend one or more of these to friends and colleagues, so I figured I'd write up the list here for future use.

My day job and my hobbies are very different, however I use most of these tools for both. My hardware consists of a Windows 7 laptop for work, a Windows 7 desktop for home (hobbies, games, and other non-work stuff), and an iPad & iPhone (used for work & play). I also carry a Windows Phone 7.5 for work use.

Some context: I spend my day customising Microsoft Dynamics CRM for clients, which requires very little code cutting. When it does, it is usually plain JavaScript. I also write significant volumes of documentation, in MS Word. Say what you like about Word, but it's synchronisation and multi-user editing with SharePoint is fantastic. I also blog, both at work and at home. I take lots of photos, mostly of my kid, and don't share most of them online.

I've used every one of these for at least a year, in most cases many years. Where possible I pay for services so they don't disappear on me.


I distrust Google with my e-mail for various reasons, and I really dislike seeing ads next to my e-mail. FastMail (now owned by Opera) is my go-to for e-mail services. They give me multiple domain names with multiple aliases, a shared address book with my wife, and great IMAP support over any port I like (great for networks that specifically filter IMAP/SMTP). There's also alternate logins and two-factor authentication.

I am more than happy to pay the few bucks a month this costs me for what really is a premium e-mail service.

Tip: With a Family or Business account, you can share address books and files between users.


Evernote Screenshot

Evernote sucks as a text editor, but it's a great way to store snippets of text across multiple systems. I use it for note-taking in meetings, and I use it to write most of my blog posts (so that I can add to & edit on my iPad or work laptop).

The tagging & classification is really useful - I often find myself using Evernote to refer back to previous notes to make sure I haven't missed anything. My notes are kept in-sync between laptop, desktop, and iPad.

Tip: Create bullet lists but insert Checkboxes on each line instead. Your notes then instantly become a todo list that you can mark off. Evernote can also capture Win+S and save screenshots to a new Evernote note, or to your clipboard.

Sublime Text

Sublime Text is my go-to text editor in Windows. I use it for building HTML, writing JavaScript, and even editing long blocks of text. For a long time I used Vim32 on Windows, but it just doesn't seem right to me. It doesn't seem to work as fluidly as on a Linux machine, probably because of the lack of useful command line. (Yeah, yeah, PowerShell and Cygwin and such. Doesn't do it for me, sorry).

Tip: When you close ST, even with unsaved documents, your exact location is saved. When you reopen it, the unsaved buffers are shown. This means you can constantly have a scratchfile open that doesn't have to be saved, that maintains state through reboots. However, this also means that you close down ST sometimes without saving changes to disk, so the files you e-mail/upload aren't complete.


When I'm coding for fun, it's usually using Django on a Linux server. To edit this code I use Vim because it's what I know best. I have never been a huge fan of it on Windows, however, which is why I still use Sublime Text there.

Multiple buffers, good command-line support, syntax highlighting, and (for me) absurdly quick keyboard controls make this ugly duckling incredibly powerful and fast.


My BackBlaze Stats

I've had a computer stolen before, and it isn't nice. If you don't have sufficient backups, then all of your documents, photos, and more are gone. Just like that. A fire is possibly worse, as it wipes out your CD-Rs and USB hard-drives that you "safely" stored in the wardrobe.

I pay BackBlaze fifty bucks a year to store all of my junk on their servers in the United States. Photos, documents, prior years tax receipts, and more. Whenever I add new photos to my PC from my DSLR, they're automatically backed up.

Tip: Make sure your photo folder(s) are included in the backup, as well as any external hard drives you use. Test the backup by downloading a significant chunk of it, so you understand the restore process before you need it.

Royal TS

Royal TS with Multiple open connections

Royal TS is a great remote desktop tool that lets you save and connect to multiple RDP sessions at once within a single window. It's cheap. Apparently it's now available for OS X and iOS, however I only use it on Windows.

Tip: Group servers into Folders, and save login credentials (at least just Domain & Username) against the Folder. You then avoid storing login details against each server, making changes even quicker & easier.


The defacto SSH client on Windows - Using PuTTY with Pageant makes accessing Linux shells from Windows a piece of cake. It's also great for building secure tunnels through my home network when I'm on the road.

Tip: Put PuTTY in your $PATH and save your session details (eg which key to use, hostname, and window configuration). You can then run putty -load dev to login to your dev machine with pre-saved configuration.


It seems pretty common to use Dropbox for backups, however I don't use it for that - it's just a stupidly simple way for me to move files from one machine to another, or share online. Most commonly it'll be to move files between my work & home PCs; less regularly to move documents onto my iPad without using iTunes.

I only use a few hundred MB of storage so it's completely free. If you want to kick more storage space my way, you can use my Dropbox referral link (I get 250mb of storage if you signup this way, and it won't cost you any extra.)


1Password for Windows

I can't put a price on 1Password. Here's how it works: When you sign up for some new website, 1Password generates a password for you. It'll be something like 1yf~f6dUBmw[rY. It then saves your passwords for you, so you don't need to remember 1yf~f6dUBmw[rY. When you then visit that website again, just press Ctrl-\ in your web browser and 1Password logs in for you with the right password! The whole password list is secured by a single strong password; you type that password each web browsing session (eg type it once the first time you press Ctrl-\, it remembers it for the next half-hour or so).

Since using it, a number of high profile sites I use have had security breaches but I've never been overly concerned as I know that my passwords are never re-used anywhere. I don't know what most of my passwords are, and I'm happy with that.

1Password for iOS

Tip: Sync across devices using Dropbox. Ensure you've got your Dropbox and primary e-mail passwords stored elsewhere, in case you find yourself with no access to 1Password or Dropbox. Use 1Password on iOS to copy passwords to your clipboard, to then paste into Safari or other iOS apps - retyping those long random passwords is a shit task, especially on a touch-screen.

Pocket Casts

Pocket Casts - My preferred iOS podcast client

Pocket Casts is the only iOS Podcast client that I've found with push notifications. When new episodes come out, they pop up on my screen without me manually opening the app & refreshing the feeds.

I do wish that it had slightly better handling of 'show notes', but otherwise it's a great replacement for the buggy and incomplete Apple Podcasts app.


Spotify Playlists

I use Spotify on my iPhone and iPad, almost always streamed over AirPlay to my Apple TV. For now I've given up on buying MP3s, and listen to random playlists when I want background music.

There's something fantastic about sitting on my back verandah, listening to any songs I could ever want to listen to (OK, except for The Beatles and AC/DC), without any cables or physical media.


Instapaper Menu

Instapaper has a simple premise: When you find something you want to read later, you click 'Read Later' in your browser. Then, when you've got time to read, you open the Instapaper app, where the article is formatted in a reader-friendly fashion. It even works off-line.

Instapaper Article View

Instapaper is incredibly simple, and it works well. The basic service is free, and the iPad/iPhone apps cost a few bucks. It's initially hard to believe something so simple isn't free, but then you realise how useful it really is for those of us who like to consume long-form articles in our own time.

Tip: Don't forget to open Instapaper & sync it before getting on a plane. You've then got access to your reading backlog at 30,000 feet - images and all.

What else?

There are plenty of apps I use daily, but they're probably common enough to not need explanation. A few things you'll see me using if you watch long enough:

  • Outlook - paired with Exchange, it's the killer corporate e-mail & calendar system.
  • Google Chrome
  • Adobe Lightroom
  • Paint.NET
  • WinSCP


Occasionally I need to take WhisperGifts offline, but still show some parts of the site to users. This has included some system changes that require the site to be non-functional for a little while (such as doing a deployment with a bunch of backwards-incompatible changes, or large database migrations) and for server moves, whilst waiting for DNS changes to propogate.

To do this, I wrote a little library that I could toggle within my Django settings. I've just pulled it out of the WhisperGifts codebase, and django-readonly-site is now available on GitHub. I think it's pretty simple to use.

Install it with pip install django-readonly-site, add readonly to your Django projects' settings.INSTALLED_APPS, and set settings.SITE_READ_ONLY = True. More options are available to keep parts of your site online, see the README for more details.

By keeping parts of your site online (such as the homepage, about us page, and in my case a customers' registry listing) you can provide a transitional experience to users, while the database-intensive and high-integrity parts of the site (such as signup, account management, and checkout) are taken offline with a polite "Sorry, we're temporarily unavailable" message.

Just after I had to quickly move to Rackspace after an outage with my previous web host, Rackspace announced that they now had a public cloud offering in Australia. For performance reasons, I'll be moving from DFW to SYD soon - and I will use django-readonly-site to try and minimise the perceived downtime for my users.

Your thoughts, suggestions, and pull requests are welcome on the GitHub Project Page.

Pure CSS Image Accordian

A little while ago I rebuilt my homepage. The homepage became an 'About Me' page; more of a landing page than a blog archive. The blog URLs haven't changed, and it's still there - however the move to a landing page is an acknowledgement that I just don't write blog posts as frequently as I used to.

One of the fun things that I added at the top of my landing page is a series of eight images that show who I am and what I enjoy doing. They're all from my own photo collection, and although they're hardly perfect photos they do capture the essence of the past few years of my life.

The images are shown in a simple accordion - only the middle vertical 30% of an image is shown, then when you mouseover an image slice the other images are compressed to show the hovered image in it's entirety.

The images are all 400x400 pixel squares; they're floated left by -150px (with overflow: hidden) to show the 8 even slices. On hover, all of the slices are resized to 20%, except the image the mouse is over: That is changed to 100%.

To make it a little prettier, I use -webkit-transition (CSS3-only), however it isn't as smooth as I'd like.

I've tested in most modern browsers, but as my site isn't high-traffic I haven't tested every possible combination. YMMV.


<div id='hero'>
    <span><img src='/media/heroimages/hero1.jpg' title='Image Caption'></span>
    <span><img src='/media/heroimages/hero2.jpg' title='Image Caption'></span>
    <span><img src='/media/heroimages/hero3.jpg' title='Image Caption'></span>
    <span><img src='/media/heroimages/hero4.jpg' title='Image Caption'></span>
    <span><img src='/media/heroimages/hero5.jpg' title='Image Caption'></span>
    <span><img src='/media/heroimages/hero6.jpg' title='Image Caption'></span>
    <span><img src='/media/heroimages/hero7.jpg' title='Image Caption'></span>
    <span><img src='/media/heroimages/hero8.jpg' title='Image Caption'></span>


#hero span {
    /* Show each image as a 120x400 sliver. */
    width: 120px;
    height: 400px;
    float: left;
    overflow: hidden;

#hero span, #hero span img {
    /* Animate the image width changes. Not perfect, but good enough. */
    -webkit-transition: all .5s;
    -moz-transition: all .5s;
    -o-transition: all .5s;
    -ms-transition: all .5s;
    -webkit-transition-delay: .1s;
    -moz-transition-delay: .1s;
    -o-transition-delay: .1s;
    -ms-transition-delay: .1s;

#hero span img {
    /* Ensure the vertical slivers show the centre 30% of the image */
    text-align: center;
    position: relative;
    left: -150px;

#hero:hover span {
    /* When we hover over the #hero block, change all images to 80px (20%)... */
    width: 80px;

#hero span:hover {
    /* ... except for the actual image being hovered, which now becomes 400px (100%) */
    width: 400px;

#hero span:hover img {
    /* Reset the 'left', as it was previous 150px, on hover. */
    left: 0;

This code is hereby in the public domain; no warranties or support are provided. Good luck.

Getting Paid in Django with Pin Payments

Payments in Australia are controlled by the so-called "big four" banks, and it's been difficult for a long time for startups to get merchant facilities to process credit cards online. Accounts cost hundreds of dollars per month, with high transaction costs and minimum transaction volumes thrown in.

We watched with teary eyes as companies such as Stripe launched and made it easy for developers to process credit cards, and kept struggling with the PayPal "API" with hope that one day we'd see Stripe in Australia.

I was excited, then, to see that Pin Payments have just publicly launched in Australia. They're currently offering a $9/month account fee, which isn't free but it's certainly ideal for small companies. After June 2013 this will jump to $50/month, so it seems to make sense to sign up now if you've got any medium-term plans.

Like Stripe, Pin offer a JavaScript Library for processing payments on your page without ever handling credit card details. This makes it much quicker and easier to implement.

Because I process payments in multiple places on WhisperGifts, I needed a reusable way to render the payment form and process the payment in a worker queue. The resulting code has been packaged up as django-pinpayments, which is still simple and in an Alpha state but it's a great starting point.

The code is released under the BSD licence, and I'd love to get your suggestions, comments, and GitHub Pull Requests.

A few things on the to-do list include providing Celery tasks out of the box, and providing tests & documentation. If you can help with any of these I'd be very happy :)

In the meantime, I'm about to go live with credit cards on WhisperGifts for the first time. I'll keep PayPal around as an alternative, but if demand is low I won't hesitate to turn it off. I can't wait.

I've Screwed My Kid's Identity

Last month, this website passed it's ten-year anniversary. It's a quiet milestone, but it's humbling to know that my website has been online for more than half of the age of the "Commercial Internet" 1. I was online for a long time before 2002, but always in a less organised fashion than you see here.

Since I was an adolescent, I have been online. I was part of the first generation of teenagers to start getting themselves into trouble on the Internet by over-sharing personal details (This was never a problem for me, but I'm not sure why teenage-me shied away from being TOO personal.)

I try not to be too scared by stories carried by "news" and current affairs programs on TV where untold numbers of naive young Internet users share information, as in many cases it appears to be hyper-inflated news stories on top of parents looking for "justice" for their children, who most certainly understood what they were doing in the first place.

However I'm very cognisant of the fact that I'm putting much of my son's private information online. He'll be part of the first generation of internet users not only to not know of a pre-internet society, but whose history has already been shared without their knowledge.

Without his knowledge (and certainly without his permission), his mother, uncles, aunts, and I regularly and voluntarily publish information about his life in public arenas: Facebook, Twitter, Flickr, and even this blog contain voluminous details of my son's life from the moment he was born through to today. While most children & teenagers online are (hopefully) wise enough not to tell everybody their exact date of birth and their parents maiden names, we've already done that for our kids.

Based on the way Internet trust works today, in 2013, this information is benign to us but dangerous to our children. When my son signs up for his Facebook or Gmail account2 he's going to be asked for his mothers maiden name, his date of birth, and his first dogs' name to use as future proof of account ownership.

The problem is clearer now - my son's online accounts will not be safe because of the actions of his family decades in advance.

So what are we going to do about it? In reality it's too late; we cannot take back what we've already published about our kids. We also can't expect parents to stop bragging about their kids and posting photos - it's probably also not possible to expect parents to even understand the gravity of their oversharing because it isn't oversharing as far as they're concerned.

As an example, I have no qualms telling you that my dog is named Abby; this information is useless to you from a security viewpoint though as that's not my first dog's name. For my son, obviously, the timing is different to the tune of 27 years, so now you know the answer to that security question for him.

As new generations come online, it's time for the web to stop relying on static semi-personal information for identity. In 2013, it is no longer acceptable to rely on "security questions" to prove identity. The answer for lost online identities must be two factor.

Usefully enough, two factor authentication is already the industry-standard way to deal with high-security logins. Using hardware tokens, our mobile phones, or even old-fashioned e-mail and SMS to prove ownership of an account is the only way netizens can be safe for generations to come.

So my plea to websites on behalf of my kids is this: Stop using security questions.

  • Reset lost passwords using e-mail resets or SMS messages, not with security questions.
  • High-security accounts, such as bank accounts or e-mail accounts3, should use two-factor authentication by default
  • Security questions should die a quick and sudden death. The internet already has second generation users.

1. At least in the eyes of the general public, the Internet didn't really exist in Australia until at least the mid-nineties.

2. Or whatever takes their place in a decade from now - isn't that an exciting thought?

3. E-Mail is high-security because it is the single reset point for a persons entire online identity. It's no longer "just a Hotmail account".

The Definitive Answer, Explained

Yesterday I posted that Django was almost certainly suitable to use for your project. I've had some minor push-back, so I thought I'd explain a little.

When beginning a project, many businesses appear to spend an inordinate amount of time making technical decisions that are often outside their area of expertise. One such decision might be from a small business owner wanting to decide whether to build their shopping cart with Django, Rails, or PHP.

The hard truth is that for the most part, this decision doesn't matter. All three of the above can be used to successfully build exactly the sort of shopping cart that you want, no matter how bespoke.

An article I came across this week talked about the same theme but in a different context. It's by Forbes' Gene Marks, and is titled What Won't Tell You. The message here is that no matter what CRM solution you implement, you'll get results if you implement it well - and that means getting the right people to build/design it, getting your staff on board, and making sure somebody owns the system.

This applies to your website project, too.

  1. Ensure somebody at your company owns the website and makes decisions based on outcomes rather than technology
  2. Ensure you're working with somebody competent to build your website. Don't fuss over whether they use PHP, Django, Rails, or otherwise: defer to their experience (it's what you're paying for, after all)
  3. Embrace what you build.

My feeling is that when you're building something bespoke, #2 is the most important: make sure you work with somebody you trust. If you aren't able to let go of some control and let them make technical decisions for you, then your project is already doomed.

Of course there are exceptions here. If you're a Rails developer, just build with Rails (unless you want to try Django). If you know for a fact that a particular technology can't work for you, then don't use it. But if you aren't at all technical, then don't try to make technical decisions that impact your business: please find somebody who can make that decision for you.

After all, you wouldn't expect a web developer to tell you how to layout your retail store, would you?

The Definitive Answer To "Can I Use Django For This Project?"

Short: Yes.

Longer: Almost certainly. If you don't know any technical reason why Django isn't a good fit, then Django is probably a good fit.


Want to see more? Check out the yearly archives below.