A few weeks ago I competed in my first triathlon - a super sprint distance race aptly named the Rookie Tri. It’s a 300 meter swim, followed by an 11.2 mile bike ending with a 2 mile run. I’m registered to race an Olympic Distance (1500m swim, 40km bike, 10km run) at the CapTex Triathlon at the end of the month, so I figured this would be good practice. I’m so glad I did it, I had a great time and learned a ton.
I was in New Orleans, LA at the beginning of 2014. Fitting, as the Crescent City played a huge role in my life this past year. Meg and I were in town planning our wedding and decided to stay and celebrate New Years in our favourite city.
Our normal abode (and future wedding venue), the Maison de Macarty in the Bywater, was fully booked that night so we were temporarily relocated to the Hilton Riverside hotel. After a nice evening out, we decided to get a bottle of wine and go back to our hotel room before the countdown began. This turned out to be a wise move as when the clock struct midnight, we were treated to a spectacular fireworks display over the Mississippi river. It was the perfect way to ring in what would become one hell of an eventful year.
On June 7th and 8th, I’ll be joining the Ride to Conquer Cancer — a two day ride from Toronto, Ontario to Niagara Falls (that’s just over 200km). The ride raises money for the Princess Margaret Cancer Centre, one of the top 5 cancer research centres in the world. I’m doing this because the work done at centres like Princess Margaret has a direct impact on cancer patients and their loved ones. The ride funds are directed towards research initiatives that are focused on Personalized Cancer Medicine improving detection, diagnosis, targetting and support.
Building great teams is hard. We all know this. Nobody has the perfect recipe for creating a great engineering team, but I’m fairly certain that some things are obvious and should be heeded. What follows is a list of observations I’ve made throughout my career about what seems to work and what doesn’t. Perfect excuse for a good old “Do” and “Don’t” list:
All good developers run into things that piss them off from time to time. Great developers build tools that help them fix the shit that pisses them off. Give developers space and time to work on things not on the roadmap and they’ll probably end up building tools that solve unseen business problems. Intentionally under-load developers (or go one step further and do away with deadlines) and you’ll start to see deploys run more smoothly, metrics start being captured, open source libraries and tools start being published and everyone is happier for it. Allowing developers time for side projects is an intangible, but I’m convinced it’s an investment that pays for itself and then some.
I’ve always been interested in cross-language service frameworks. I believe in using the best tools for a job, instead of being limited to a specific language or framework, so being able to write components of a service in whatever langauge makes the most sense is attractive to me. In past lives, I’ve developed software that used CORBA, SOAP, COM and XPCOM and found that they all suck in different, significant ways. Because of this, I’ve been interested in the Apache Thrift project originally developed at Facebook.
I’ve had some people ask me about the through argument supported by Django’s ManyToManyField class. This option supports a very simple use case: when you want to store additional data in a join table.
Imagine, for instance, that we’re building a simple course registration tool. Let’s call the Django app courses. We’ll define the following models:
from django.db import models
class Course(models.Model):
"""A course offered at our school."""
name = models.CharField(max_length=100)
code = models.CharField(max_length=5, unique=True)
description = models.TextField()
def __unicode__(self):
return u'%s: %s' % (self.code, self.name)
class Student(models.Model):
"""A student registered with our school."""
first_name = models.CharField(max_length=50)
last_name = models.CharField(max_length=50)
number = models.CharField(max_length=10, unique=True)
courses = models.ManyToManyField(Course, null=True)
registered_on = models.DateTimeField(auto_now_add=True)
def __unicode__(self):
return u'%s -> %s, %s' % (
self.number, self.last_name, self.first_name)When we run syncdb or generate a migration for these
models, Django will automatically create the following tables:
courses_course, courses_student, and courses_student_courses. The first two should be
self-explanatory. The third table will store information about our
many-to-many relationship. Each row will associate a student id with a
course id.
I’ve been thinking about signup processes lately and what we can do with batucada (the next drumbeat.org) to make it easier, while encouraging users to use open, decentralized identity technologies like OpenID.
Whenever I come across a new service that I want to create an account on, I dread the idea of creating a new set of credentials and re-entering a bunch of information I have already entered elsewhere. OpenID solves part of this for me, and I’m always happy to see sites supporting it. The problem, however, is that OpenID only solves one piece of the puzzle (authentication) and there are usability problems abound. The latter problem is well known, and people have come up with a bunch of innovative ways of tackling it, including intelligent OpenID selectors.
This is pretty old news, but I missed the original announcement and I think it’s pretty interesting.
Google have implemented an alpha of the WebFinger protocol. If you have a Google profile, click on “Edit your profile” and add ‘webfingeralpha’ as an interest. Congrats, your gmail address is now a WebFinger identifier and will resolve to an XRD file containing information about services you use (if you’ve included that information in your Google profile).
This article will provide a brief introduction to mod_python, a tour of what you can do with it, and some pointers to further resources should you want to explore it in more depth. I will assume that the reader is comfortable programming in Python (although no specific knowledge is required) and is familiar with Apache and basic web concepts. This article is not intended to be a complete reference for mod_python. Instead it is meant to consolidate information available from other sources, to hopefully whet your appetite and encourage you to read more from the official documentation (links are in the Resources section).
You can always reach me by sending an email to my first name at the domain eval dot ca.
I have profiles on LinkedIn, Github, and some other places. Googling for my name usually brings up relevant results (there are a few other people who share my first name and surname but I don’t think any of them are in software).