Build Geos and Collectstatic

was originally using these buildpacks:

got this error when i pushed: Collectstatic configuration error. To debug, run …..

when i ran: heroku run …. collectstatic everything was fine!!!

so i had to patch the python buildpack:

then i got when i pushed:

—–> Preparing static assets Traceback (most recent call last):


django.core.exceptions.ImproperlyConfigured: Could not import user-defined GEOMETRY_BACKEND “geos”.

so i found a newer fork of heroku-geo-buildpack which had two newer commit to fix everything:


To this stack overflow post Heroku/Django: Could not import user-defined GEOMETRY_BACKEND “geos”

Backups are as easy as 1-2-3

I like Leo Laporte‘s idea of 1-2-3 backup solutions.

  1. Local Copy – I keep anything local that i need to access quickly. every time i format the hard drive or buy a new computer, i only copy across the bare essentials. everything else, i grab from the external drive when needed.
  2. Cloud Copy – I use Backblaze for unlimited backup including external drives!
  3. Different Hard Drive – I use a simple rsync script, triggered nightly by a cron job, to backup to my external hard drive (which I plug in every night). The rcync script goes something like this:
rsync --progress --recursive -a --exclude="*.Trash*" --exclude="Downloads/*" /Users/matt/ "/Volumes/laptop-2tb/matt-2013/"

Pretty simple hey?

Using Google Maps API

I’ve just started playing with the Google Maps Javascript API for a web version of Hpflsk. So far so good, but there are a few little quirks that have left me a bit baffled. I’ve also thrown in some examples that fit our use case.

 Include the Libraries You Need

Firstly, if you jump directly into the API Reference, wherever you see the word library after the heading in the table of contents, e.g. Places Library, you need to make sure you load that library when you load the API.

I spend way too long in the javascript console writing… and hitting the tab key and couldn’t work out why places was missing!

Geocoding versus Places Search

Geocoding is the process of turning an address – e.g. 123 Fake Street – into a geographic point (latitude/longitude). If you want to search for a location by name – e.g. Lucky Donut Shop – similar to what you can do in the search box on Google Maps, you need to use TextSearchRequest in the Places Library. Here’s how I implemented a text search for places near the user’s current location:

<div id="map-modal-inner"></div>
<script type="text/javascript" src=""></script>

// JS
// Find the venue location by searching on the venue name
// Get client's location using HTML5 navigator.geolocation
var venueLocation;
navigator.geolocation.getCurrentPosition(function(position) {
  var latitude = position.coords.latitude;
  var longitude = position.coords.longitude;
  var myLocation = new google.maps.LatLng(latitude, longitude);
  // Search for places nearby and take the first result
  // First make a temporary map object
  var mapOptions = {
    center: myLocation,
    zoom: 16,
    mapTypeId: google.maps.MapTypeId.ROADMAP
  var map = new google.maps.Map(document.getElementById("map-modal-inner"), mapOptions);
  // Then search for places matching the venue name
  var places = new google.maps.places.PlacesService(map);
  var placesRequest = {
    query: "Lucky Donut Shop",
    location: myLocation,
    // favour results within 50km of currrent location
    radius: '50000'
  places.textSearch(placesRequest, function(results, status) {
    if (status == google.maps.places.PlacesServiceStatus.OK) {
      // for some reason jb = latitude, kb = longitude
      var loc = results[0].geometry.location;
      venueLocation = new google.maps.LatLng(

Django + Elastic Beanstalk

Hpflsk has been playing around with Django and AWS Elastic Beanstalk. We’ve hit a few roadblocks along the way, but so far we’re up and running and everything seems to be fine.

Just to summarise our current situation:

  • We have 1 Android and 3 iOs developers working hard on version 2 of the app
  • These guys and me (sometimes) are the only people hitting the new API
  • The new version of the app will be hitting the new AWS Elastic Beanstalk setup

Here are a few roadblocks  and successes we hit along the way:

  • Setup using this excellent guide from Grigory Kruglov but each of the .config files, change commands: from commands: to container_commands:. This cost be a few frustrating and headbangingly awful days
  • The official docs get you started with a simple example, but in my opinion are really lacking
  • The whole config system is wack. The options are spread across two seperate files and one of them seems to update from AWS at random times. Uhh, it sucks and leads to so many headaches.

One thing I wanted to talk about was cost. There’s a guide that is on the Amazon site which estimates costs at something ridiculous – in the $1000s of dollars – and way outside the range of a lean startup. You definitely want to monitor your expenses using a Cloudwatch alarm.

So far, Hpflsk has been charged around $50 AUD a month with only a grand total of 5 people hitting the API regularly. This includes the free tier. This may seem like not that much, but it definitely discourages developers from creating a bunch of apps and seeing what sticks – which seems to be the lean startup model. So if you want to keep everything super lean and mean, you’re better off with a VPS (~$100 AUD per year). It’s that not much of a pain in the ass to setup – took me around a day – and can be used to host multiple projects.