2degrees Developers

Looking for Senior/Mid-Level Developers to Change the World!

Fri, 08 May 2015 09:00:00 +0000

2degrees, the world’s leading collaboration platform for sustainable business, are currently looking for disciplined software developers to build and maintain Python/Django applications.

We’re fundamentally looking for team players who are able to produce well-crafted software (e.g., elegant design, self-explanatory code), whether or not they have prior experience with our stack (which we’d consider a big plus).

To learn more about the software that we build, have a look at the Free Software projects that we host on our GitHub account. Recent projects include hubspot-contacts and python-recaptcha.

Telecommuting 2-3 days a week is possible, as long as the successful candidates are able to work in our Oxford office the rest of the time.

To learn more about these vacancies, head over to our careers page.

Converting our multi-page Django app to use AMD

Fri, 18 Jul 2014 00:00:00 +0000

Introduction

The application which powers 2degrees has, to date, mainly been driven by a Django-powered back-end. Django is agnostic about any front-end stack and this has certainly contributed to a fairly ad-hoc approach to javascript. With an increasing demand for a more interactive experience, we have been adding more and more javascript, experimenting with AngularJS to power our pinboard, and looking at ways to use/build frameworks to play nicely with the back-end. As a result of this work, we have found issues of manageability of the javascript code.

Manageability issues

The issues we had fell into the following categories:

Risk of missing dependencies when inheriting complex pages with lots of javascript.
Dependencies loading out-of-order in some cases.
The code becoming increasingly complex to manage (poor separation of concerns in the code, etc.)

AMD to the rescue?

We hoped that a modular approach to javascript would address all of these issues and more. After some research about various module patterns and loaders, we decided to use RequireJS. This decision was based mainly on API features and how well-maintained and well-documented the library is.

Porting the codebase to using RequireJS

After performing a spike to asses the complexity of the task, we found that we’d have to carry out the following tasks:

Upgrade 3rd party dependencies where AMD wrapped versions are available
Add an AMD wrapper to all of our open source javascript libraries
Figure out how to deal with non-AMD code (e.g. google analytics)
Pass configuration from the back-end to javascript modules in an efficient manner (e.g. URLs for the code to carry out AJAX requests)
Pass environmental data to the javascript (e.g. whether the user is authenticated)

Setting up the configuration file

After reading the docs on how to configure RequireJS we decided to alias all our third party modules which live in a lib directory in our JS folder so that they were available directly rather than as, e.g. require(['lib/jquery']). Not only did we feel this was a nice to have, but neglecting to do this means than no jQuery plugins which support AMD will work, since their AMD wrapper expects jQuery to be available as jquery.

For all the 3rd party libraries which don’t have AMD version available we declared a shim configuration as well.

We put out configuration in a separate file which we included in our base template:

var require = {
    baseUrl: '{{ JS_MEDIA_URL }}',
    paths: {
        'async': 'lib/async.min',
        'angular': 'lib/angular.min',
        'domReady': 'lib/domReady.min',
        'jquery': 'lib/jquery-1.11.1.min',
        'jquery.cookie': 'lib/jquery.cookie.min',
        'jquery.form': 'lib/jquery.form.min',
        'jquery.history': 'lib/jquery.history.min',
    },
    shim: {
        'angular': {
            deps: [],
            exports: 'angular'
        },
        'jquery.history': {
            deps: ['jquery'],
            exports: 'History'
        },
    }
};

Passing environment variables from Django

We explored several options for working out how to make some environment data available to the javascript code. We looked at the document on passing config but this can only be used on a per-module basis.

In the end, we took the approach of defining an inline module called env which we placed in our base Django template:

define('env', [], {
    IS_AUTHENTICATED: {{ request.user.is_authenticated|json }}
});

This code must come after the initial loading of the require.js file. preferably as soon as possible.

Then inside any modules we need to access the environment, we can do something like:

define(['env', '...'], function (env) {
    if (env.IS_AUTHENTICATED) {
        // Do something for authenticated users only
    }

    // more code ...
});

Passing configuration to specific modules

As mentioned previously, RequireJS provides an excellent feature to configure modules. We took extensive advantage of this to set-up URLs and data from the back-end on a per-module basis, e.g.

requirejs.config({
    config: {
        'foo/formset': {
            max_item_count: {{ MAX_FOO_COUNT }}
        }
    }
});
require(['foo/formset']);

And in foo/formset.js:

define(['module', '...'], function (module, ...) {
    var max_item_count = module.config().max_item_count;
    // rest of the module
});

Dealing with non-AMD code

There were a couple of examples of 3rd party code which didn’t have AMD support, and it is essentially standalone to support our application. Analytics code is one such example. In this case, we simply used a normal script tag as recommended by the analytics providers.

One case we came across which didn’t work well with this approach was google maps. After some reading around the best approach we found was to use the async plugin for RequireJS:

require(['async!//maps.google.com/maps/api/js?sensor=false&key={{ GOOGLE_MAPS_API_KEY }}'], function () {
    'use strict';
    var map_marker_icon = '{{ STATIC_IMAGES_URL }}/internal/map_marker.png';
    var map_shadow_icon = '{{ STATIC_IMAGES_URL }}/internal/map_marker_shadow.png';
    var uk_latlng = new google.maps.LatLng(51.776596,-1.264314);
    // more code ...
});

Conclusion

The switch to AMD was nowhere near as painful as we thought it might have been and the results are already paying dividends in terms of quickly we can develop our javascript code.

The future

We’d love to use the optimizer but the thought of coupling integrating node.js into our build system for the initial release was unpalatable! We also considered using bower to pull in our 3rd party dependencies, but again time didn’t allow for us to explore this fully.

Announcing django-pastedeploy-settings: A Maintainable Way to Define Django Settings

Wed, 19 Jun 2013 13:33:00 +0000

We’re happy to announce the first beta release of django-pastedeploy-settings, a more maintainable way to define and override Django settings. Its features include:

Simple, Python-free configuration files. The format used is INI because configuration files should be declarative, not scripts.
Settings can be inherited. For example, you can define your base settings in your project’s repository, while overriding some from a separate file outside your repository.
Setting values are defined with JSON.
Variable substitution, allowing you to define a value once and reuse it in different settings.
Integration with Buildout, so that you can expose your Django settings to Buildout parts.
Integration with Nose, so that you can easily set the settings to be used by your test suites.Under the hood, this library uses Paste Deployment, a widely-used system which has the sole purpose of enabling developers and sysadmins to configure WSGI applications (like Django) and WSGI servers.

In spite of this being the first public release of this library, its code is based on twod.wsgi v1, a library which we’ve been maintaining and using in production for over 3 years.

Example

You can keep the following file in your project’s repository:

# base.ini

[DEFAULT]
django_settings_module = your_django_project.settings

[app:main]
use = egg:django-pastedeploy-settings
DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.sqlite3",
        "NAME": "%(sqlite_db_path)s",
        }
    }

And then have two separate files, one for development and the other for production, both of which will extend base.ini:

# development.ini

[DEFAULT]
debug = true
sqlite_db_path = /dev/your-project.db

[app:main]
use = /your-project-repository/base.ini
SECRET_KEY = "weak key"
DEBUG_PROPAGATE_EXCEPTIONS = true

# production.ini

[DEFAULT]
debug = false
sqlite_db_path = /production/your-project.db

[app:main]
use = /your-project-repository/base.ini
SECRET_KEY = "str0ng k3y"

Alternatively, you can keep it all in one file:

# settings.ini

[DEFAULT]
django_settings_module = your_django_project.settings

[app:base]
use = egg:django-pastedeploy-settings
DATABASES = {
    "default": {
        "ENGINE": "django.db.backends.sqlite3",
        "NAME": "%(sqlite_db_path)s",
        }
    }

[app:development]
use = base
set debug = true
set sqlite_db_path = /dev/your-project.db

SECRET_KEY = "weak key"
DEBUG_PROPAGATE_EXCEPTIONS = true

[app:production]
use = base
set debug = false
set sqlite_db_path = /production/your-project.db

SECRET_KEY = "str0ng k3y"

Get it while it’s hot!

Making Django play nicely with AngularJS

Thu, 09 May 2013 13:42:00 +0000

Introduction

During the development of a new feature to allow users to “pin” content to read at a later date, we came up against the age-old problem in our application - how to write javascript without a whole heap of boilerplate. We’ve tried various approaches in the past, e.g. using Handlebars to template data received from the server, and wrapping up some repeated operations in some hand-rolled “libraries”. We’d chosen not to use a javascript framework previously since jQuery is a pretty powerful tool which could be used to meet most of our needs since our application consists of many pages which require a small degree of progressive enhancement and not a full-blown client-side application.

This pinning challenge was a bit different from problems we’d come across before since there would be a pins widget on almost every page in the site and any page that contained our editorial or user-contributed content would be eligible for a pinning control, so we decided that it was the right time to choose a framework, even if it were one with a fairly minimal feature-set for wrapping some low-level operations.

Why AngularJS?

We identified several things which cause us irritation and slow us down when developing javascript and used these as a guide for which library or framework we would use:

A sensible degree of separation of concerns (i.e. model, view, controller type split)
Two-way data binding (we were fed up or writing loads of event handlers and updating the DOM all the time when the state changed).
Communicating with the server easily.
A pure javascript library (we know how to write javascript - we didn’t want to learn another language!)

Separation of concerns

Taking a look at TodoMVC, there were plenty of candidates which satisfied this requirement (after all that’s what TodoMVC is all about!). To be honest, most of these libraries met this requirement fully and the only aspects which swayed us were:

Amount of documentation
Size of community (both in terms of development and users)
Ease of use of syntax

Two-way data binding

Of the libraries surveyed, this feature is available in ones which tend towards the fully-featured framework end of the spectrum, e.g. ember.js, knockout.js, meteor.js and angular.js, or those which simply encapsulate this feature, e.g. rivets.js.

Server communication

Here, there was two camps: those which deal with the communication themselves and those which require the use of, e.g. jQuery. Since this was really only syntactical sugar and we already use jQuery, this feature wasn’t used as a tie-breaker for us.

The only library that was ruled out here was meteor.js since it relies on a node.js backend and we are constrained by having a Django app powering the backend.

Language of library

Nearly all the candidates use javascript to work with them with the exception of batman.js (coffeescript) and the Dart example (which isn’t strictly a library).

The verdict

With all of these things in mind we came to the conclusion that we would either have to put a whole load of libraries together or pick one of the fully-featured frameworks. We opted for the latter option on the basis that we’d only have one set of documentation to read and we could guarantee that everything would play nicely together. This got us down to:

There was very little to choose between these in terms of their documentation and syntax and their communities and in the end the decision came down to the fact a couple of us had used angular.js for hobby projects.

So was angular.js the right choice?

In terms of implementation we found angular.js to be an excellent choice in terms of its capabilities. We had some fun with scopes, but learned a great deal. If I had to criticize anything about angular.js, it would be that the documentation is quite variable in quality. Some of it is truly outstanding in terms of worked examples, whereas other parts are very sparse and are written as if the reader is already an expert. That said, there were no points where we thought that we’d made the wrong choice.

In the end our application came to a couple of hundred lines of javascript and we felt that using a centralized service to co-ordinate the pinning across various widgets led to a good level of abstraction and some easy-to-follow code. We didn’t have to work around anything in angular.js and didn’t need to rely on any third party software to augment the core codebase.

Was angular.js the right choice to play nicely with Django?

This post isn’t just about the virtues of angular.js, but more about how we found it when coming together with our Django application. By choosing an application framework in javascript to sit on top of an application framework in python led us to feel somewhat nervous. Both Django and angular.js attempt to address many similar aspects of web applications, but their differing domains of operation (server- and client-side respectively) clearly set them apart and we had to be careful to avoid some issues to do with code duplication, etc.

Routes vs. urlpatterns

Angular.js has a routeProvider service which allows the client to take care of the URL structure and even has an HTML5 mode which would have been appealing to us since we already have our routes defined in the Django application in the form of urlpatterns in Django’s urls.py system. We initially considered trying to mimic these, but we couldn’t see an easy way to convey the relevant configuration of our app into the client, and we didn’t have much of a need to do so, we didn’t use angular’s routeProvider.

For those whom the routeProvider would be more relevant, you’re going to need some way of defining URLs in a single place and getting the client and server apps to recognise them!

Templating

The syntax of angular.js templates bears a fair amount of similarity to Django’s in the use of the {{ var }} syntax and we found that we couldn’t mix the two. We could have served the angular templates up as static HTML files via Nginx, but some of the templates needed server-side logic which would have meant duplicating some large parts of logic in the client to avoid this.

In the end we opted for using the {% verbatim %} tag in Django to stop it parsing the angular template or by using ng-bind if we could get away with it. This solution is quite sub-optimal as it means one has to be very careful when considering the boundary of which templating system the file belongs to, but we really needed to use the backend templating system for outputting data (see below).

NB these issues are not inherent to angular’s templating syntax. We have the same problem with Handlebars templates.

Data

For a lot of the work we needed to do we were integrating the pinning system in our main content streams and we didn’t have time to re-write everything to use angular as the renderer so we had to mix up blocks of angular template code with that of Django’s (see above). For each piece of content we had a controller instance we needed to know something about the piece of content so that server communications could take place. We ended up injecting variables into data attributes before we began the angular template and then used jQuery to read the data out of the relevant DOM elements. This was pretty unsatisfactory as we had hoped to not have to rely directly on jQuery itself and it seems like a bit of workaround to say the least. However, short of creating a framework to communicate variables between the client and the server (which has a whole load of security considerations) we felt it was the most expedient route to solve the problem.

XHR

By default, angular serializes any POST data as JSON into the body of the request rather than using URL-encoding. This has large advantages when sending complex data-structures as URL-encoding doesn’t really support this without a great deal of effort. However, Django automatically decodes URL-encoded data from the POST to give the view access to key-value pairs of POST variables.

It is possible to force angular to use URL-encoding but only by encoding the data yourself and passing it to the $http service as a string. This isn’t a short-coming of either framework, but rather something to watch out for at the interface of the two.

CSRF

For methods other than GET, we use Django’s CSRF protection middleware. Django sets a token in a cookie in the client which needs to be passed back to the server in an HTTP header. We had already altered jQuery’s XHR defaults to include this cookie value as an HTTP header for AJAX requests and we had to duplicate this for angular, but again this is not a failing of the framework, just something to watch for.

Angular ships with a cookie handling component but this isn’t build into the angular core by default. We already load jquery.cookie so used this rather than angular’s version.

So was it right then?

Bearing in mind the above points, I would have to say yes. I can’t imagine any other framework would have been without issue and we certainly didn’t find anything that was a show-stopper or what we created to be inefficient or a mess.

Conclusion

Angular.js is a great piece of software, but is likely to be one among many other equally good contenders. The framework met all of our needs and was straight-forward to integrate with Django. That said, we didn’t leverage many of the features of Django (our backend code was only a few hundred lines) and it will be interesting to see what happens in the future. It would be great to have a RESTful API (using something like django-rest-framework or similar) and really see what angular.js can do with it’s resourceProvider service.

Announcing WSGI X-Sendfile: High-Performance File Transfer for Python/WSGI Applications

Thu, 11 Apr 2013 12:50:00 +0000

I’m pleased to announce the first public release of WSGI X-Sendfile, a library that lets your Python/WSGI application serve static files via your Web server.

Modern Web servers like Nginx are generally able to serve files faster, more efficiently and more reliably than any Web application they host. These servers are also able to send to the client a file on disk as specified by the Web applications they host. This feature is commonly known as X-Sendfile.

This simple library makes it easy for any WSGI application to use X-Sendfile, so that they can control whether a file can be served or what else to do when a file is served, without writing server-specific extensions. Use cases include:

Restrict document downloads to authenticated users.
Log who’s downloaded a file.
Force a file to be downloaded instead of rendered by the browser, or serve it with a name different from the one on disk, by setting the Content-Disposition header.This code has been used in production for three years in our Django application, but is now being released as beta in case there are bugs that haven’t become evident in our systems.

Get it while it’s hot!

Integrating reCAPTCHA

Thu, 30 Aug 2012 12:54:00 +0000

Recently we’ve been looking into using reCAPTCHA for a form on the 2degrees site. We took a look at the python libraries out there and found that they either didn’t meet our requirements or weren’t sufficiently documented to allow a quick integration with our software.

So, we’ve developed a couple of open-source libraries to allow easy communication with the reCAPTCHA service:

python-recaptcha is an alternative to the client that google suggest. We’ve created a fully-tested and well-documented alternative which allows access to the whole API. The main advantage here, is the ability to access the different themes on offer.
django-recaptcha-field is a small library which contains a factory for generating a Django form with a reCAPTCHA field in. All the other libraries we found worked around passing the client IP address to the reCAPTCHA service. Given that the API documentation states that this is a mandatory field, we’ve ensured that this is sent.

If you have any suggestions for future improvement in these libraries, we’d love to hear from you. Of course, if you’d like to make the changes yourself you can always fork the libraries on github!

Agile team seeks talented Software Developer

Wed, 17 Aug 2011 15:06:00 +0000

Are you a recent Software Engineering graduate looking to join an Agile team? Or do you have 3 years industry experience and a passion for learning?

We’re a fast-paced, well-funded Web 2.0 business looking for a pro-active software developer to join our talented, self-organizing software development team.

About you

You are hungry to learn: You actively seek change — always looking for opportunities to improve professionally, and to help your team develop. You read software-related publications, welcome criticism of your work and offer your colleagues honest feedback.
You’re willing to try new things: Want to try your hand at requirements gathering or UI design? If the idea of becoming a Generalizing Specialist appeals, this could be the right job for you.
You have excellent communication skills: You’re comfortable communicating verbally, graphically or in written text, and you’re happy explaining technical concepts to non-technical people.
You’re qualified and/or experienced: You have a Software Engineering degree, an equivalent certificate from a leading organization (e.g.: IEEE-CS, BCS) or have at least 3 years experience.
You appreciate a sociable, friendly and supportive working environment: We value technical expertise and encourage developers to exercise their initiative and engage with the business as a whole.This is primarily a Web Development role. Experience or knowledge of Python, Django, GNU/Linux, Git, jQuery, Solr, Postgres and Agile development methodologies</b> is a big plus, but is not required. We simply want someone with the right attitude and we’ll help you get up to speed with anything you’re not familiar with!

About 2degrees

2degrees is the world leading online community for sustainability professionals. We aim to help businesses accelerate their implementation of sustainability and carbon reduction strategies on a global scale.

With offices in Oxford, UK and New York City, we work with leading companies including HSBC, Coca-Cola, BASF, Sony, Marks & Spencer, BP, Shell, Eurostar, Sainsbury’s, Hewlett Packard and Royal Mail.

Working for 2degrees, you’ll enjoy:

A nice office in a great location in Oxford, full of people who are free to be themselves.
Managers and business people who appreciate technical staff.
Support in your continuing professional development.
A competitive salary (dependent upon experience).

About the Software Development Team

We’re in the process of adopting Scrum and have successfully embedded Agile techniques such as Pair Programming, Test-Driven Development and daily stand up meetings.
We contribute to the Free Software we use and publish our own on GitHub.
Our recent and current projects include surfacing popular content, simplification of our sign-up process, generation of business reports on site usage, and a major rework of content access permissions which allows us to expose valuable content to non-authenticated users.
Future projects include a content recommendation system, integration with the Campaign Monitor mailing service, a re-work of our subscription model, user tracking and metrics, and major design and UX improvements across the whole site.

How to apply

To apply for this role, please send us your CV and tell us why you think you’re the right person for this job (don’t forget to mention any Free Software contributions you’ve made).