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

You’re installing GeoDjango and you meet this error “django.core.exceptions.ImproperlyConfigured: Could not import user-defined GEOMETRY_BACKEND “geos” while trying to runserver (or any other command) in your project. Check the following in order of severity:

Have you included this in your .bash_profile (or equivalent)

export DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib:/opt/local/lib/postgresql91

Where 91 is the version of postgres you’re using.

If that doesn’t work, I would try reinstalling all the packages listed here: https://docs.djangoproject.com/en/dev/ref/contrib/gis/install/#macports

Make sure you’re getting the right versions for each package and that postgis is installing to the right postgres!

Installing Django PostGIS Postgres on OS X: Version Hell

Ran into a day and half’s worth of trouble while trying to install postgis and I still haven’t resolved it yet. Some things to note so far:

  1. If you install postgis via brew, `brew install postgis`, it will also automagically install postgresql9.2.1 for you. So if you have a previous version of postgresql installed, you will now have 2!
  2. Django1.4 doesn’t play will with postgis2.0 for now. So, you have to install postgis1.5 (https://code.djangoproject.com/ticket/16455)
  3. postgis1.5 doesn’t play well with postgresql9.2.1, so you to install postgresql9.1.x (http://trac.osgeo.org/postgis/wiki/UsersWikiPostgreSQLPostGIS)
  4. So, the working versions to use together would be Django1.4.x with postgis1.5 and postgres9.1.x
  5. To NOT get the latests version of postgres from brew, follow this gist (https://gist.github.com/3188632) to install postgres9 which will link you to postgres9.08
  6. The crazy thing is trying to `brew install postgis15` gives me the following error [1]
  7. Client version of psql is different from the server version of postgres. If you run psql in terminal and you see something like `psql (9.2.1)`, it means the client and server versions are the same. If you see something like `psql (Client (9.2.1) Server (9.1.2))` (can’t remember the exact phrasing but the first number would be the client, the second number would be the server itself), it means the client and server versions are different.
  8. If you have a previous version of postgres, you would have had to run `initdb /usr/local/var/postgres`. You gotta move/delete this guy if you’re installing a new version of postgres and rerun the initidb command!
  9. `brew doctor` is your friend

[1]

Error in Question:

nai@nyc ~ $ brew install postgis15
==> Downloading http://postgis.refractions.net/download/postgis-1.5.3.tar.gz
Already downloaded: /Users/nai/Library/Caches/Homebrew/postgis15-1.5.3.tar.gz
==> ./configure –with-projdir=/usr/local –with-pgconfig=/usr/local/Cellar/postgresql/9.2.1/bin/pg_config
==> make
num2_tuples = reltup->reltuples;
^
4 errors generated.
make[1]: *** [lwgeom_estimate.o] Error 1
make: *** [postgis] Error 2

Other Useful Links

http://blog.dyve.net/upgrade-your-mac-to-postgres-9-using-homebrew

http://stackoverflow.com/questions/12547872/trouble-installing-postgis-postgresqldjangomac-os-x-10-7

http://gibuloto.com/blog/install-postgresql-in-mac-osx-lion/

https://gist.github.com/3188632

http://stackoverflow.com/questions/3987683/homebrew-install-specific-version-of-formula

Apple and Patents

The internet has been abuzz on Apple’s recent patent war. My stance on this has always been that as a public listed company, Apple owes a fiduciary duty to maximise returns to its stakeholder and wielding the patent sword is just one of the many tools powerful companies have at their employ. Don’t blame the player, blame the (broken) game.

We can debate the merits and flaws of the existing patent system but that’s well covered. Perhaps, a more interesting question to ask is why has Apple taken such an provocative stance when it could have chosen to adopt a defensive posture instead?

When you have a company that’s built around a product visionary, and when many people are dependent on this person, the stakes are incredibly high. I imagine, as part of a ‘risk reduction strategy’, that the C-Suite executives have been planning for a scenario where Steve Jobs might no longer be with the company, be it for natural causes or not. Deepening the moats through patent protection is a good method to stall while they scramble to find the next Steve Jobs. Paul Graham said that he spoke to someone ‘high level’ at Apple and asked if there’s any more ground breaking products in the pipeline — the answer was: noI suspect that a side result of this is that Apple will start using it’s massive cash reserve and go on an acquisition spree to try and find the next product visionary.

Faced with such a predicament, the most rationale decision management can make is to protect the company’s interests at all cost and milk the cow for all it’s worth while they can. Apple has at most 2 -3 cycles of products ahead of them that have been in planning for many years now. After which I imagine, they are going to plateau and their growth numbers are going to decline. They are going to be cruising at a steady state, reaping the harvest sown by Steve Jobs. So bring on the patent wars, Apple has a fort to defend.

A Naive Code Counter for your Django Project

On a whim, I wrote a short management command that counted the lines of code in only the ‘core’ files in my django project and also code count for my unit test which are mostly written to test these ‘core’ files. This excludes html, css and javascript.

from django.core.management.base import BaseCommand
from django.conf import settings

import os

class Command(BaseCommand):
    """
    This counts the code for each app in the project and displays the 
    lines of code of unit test written.
    """
    help = 'Display Project Code Count and Unit Test Code count'

    def handle(self, *args, **options):
        file_types = ['views.py', 'forms.py', 'models.py', 'utils.py', 'tests.py']
        counter = 0
        unit_test_counter = 0
        for app in settings.APPS:
            for file_type in file_types:
                file_name = app + '/' + file_type
                if os.path.exists(file_name):
                    with open(file_name) as f:
                        for row in f:
                            counter += 1
                            if file_type == 'tests.py':
                                unit_test_counter += 1
        print 'Total lines of code in bbox only apps: %s' % counter
        print 'Total lines of code in bbox excluding tests: %s' % (counter - unit_test_counter)
        print 'Total lines of code in bbox tests: %s' % unit_test_counter
        print 'For every 1 line of code written, %s lines of test code is written' \
                % (float(counter-unit_test_counter) / float(unit_test_counter))

Total lines of code in project specific apps: 20172
Total lines of code in excluding tests: 13145
Total lines of code in tests: 7027
For every 1 line of code written, 1.87064181016 lines of test code is written

Source: https://gist.github.com/3566434