RSS Feed

Organizing a Successful Open Source Sprint: a tale of Django, cupcakes and ReSt


Documentation is usually written by people who are subject matter experts, people who have lost the beginner lens.  For beginners, this is a tough situation. When one first enters the fray of, say, an MVC framework, there’s a lot of big picture concepts that need to be covered before getting into the granular details. I had decided, at some point, to build a Django app for my Burning Man camp, and spent a good two months wading through tutorials and official documentation before deciding that it was time to stop swearing at home by myself and throw a nerd party sprint.

I wanted to create a space where people would not only learn Django, but also make their first contribution to an open source project.  Did you know that women make up only 3% of contributors? And that the mean number of open source contributors is one?  This was an opportunity to be constructive, and create a welcoming space for new engineers who would hopefully be inspired to contribute to open source frameworks.  Hackbright offered to host, and I connected with Angie, their Director of Growth, Nick, instructor at large.  We recruited a couple of other people we knew had both technical knowledge and an interest in community building – Jeremy Dunck is a Django expert and a mentor to many coders, and Asheesh Laroia, who runs OpenHatch.  In what was ultimately a successful event, we had a structured system that works, and can serve as a template for similar sprints.

We did a fair amount of prep work, including going through the tutorial, looking for potential trouble where beginners might become confused.  Additionally, we created a system for tracking suggestions to fixing the documentation.  But, most importantly, we set up clear goals to help us, the organizers, stay on track:

1 Create a welcoming space for people to follow the Django tutorial, and help them successfully go through the Django tutorial (with the remark that the ability to follow an online tutorial is in fact a skill of its own, worth practicing)

2.  To motivate people to make contributions to an open source project by setting them up to succeed initially.

3. Create a collection of first-hand experiences with the Django tutorial, usable as raw data for someone else to improve the Django tutorial

What made this work, ultimately, was were several factors:

0. We had clear systems in place for tracking questions and answers.

In order to support the goal of improving the Django docs based on user experiences, we needed to make sure people were tracking their questions and answers.  We did this in two ways:

  • We had bright red sticky notes available.  When someone hit a snag as they were going through the tutorial, they would put one on their workspace as a way to signal to a mentor that they needed help.
  • After their questions were answered, the hacker would make a note of the answer, and then write it up in the shared cheat sheet.

1. Brief, topical presentations that supported the goals.

We kept these limited to what was essential, and spread them out so information was given as it was needed, and there wasn’t a lot of interruption to peoples’ workflow. Here’s what we had:

  1. A mentor gave a fifteen minute presentation on an broad overview of Django at the beginning of the sprint.
  2. Right after lunch we had a group check in to field questions, and I gave a presentation on an diagram of how the Django engine works to those who wanted additional information.
  3. On Sunday afternoon, I presented on ReST and Sphinx, which are the fundamental tools for document editing in open source. Here I am with the balloonicorn:



2. Sufficient support

We had a 5:1 ratio of hackers to mentors, so  everyone could get immediate help when the were hung up, and hackers pair programmed so they could talk their way together through the problems.

3. Funny hats for mentors


Mandatory. Else, how would people find us?

4. Shared resources


Our Django cheat sheet was a Google doc where participants shared new insight gained from mentors, suggestions for changing the docs, and additional resources for learning about Django.

5. Cupcakes:

Also mandatory.  Can’t think without cupcakes.



6. Providing access to the right tools

Contributing to documentation requires a whole separate skill set that we didn’t have time to get into.  Rather than delving into a tutorial on contribution tools, we set up a copy of Sphinx on my Github and asked participants to spend a half an hour writing up suggestions and making pull requests.

All of the hackers completed the tutorial and came away with new skills, everyone got fed, and the feedback on the event was overwhelmingly positive. We’re hoping to host these a few times a year to make Django more accessible to beginners.

To follow up, we still have to submit the proposed changes as tickets to the Django organization.  Everyone had a great time, and the energy was hugely positive, and we managed to accomplish every goal! It took a lot of planning, but the amazing team made it possible.  I believe it is not possible to make something incredible without a community, and this event was the result of a lot of a team effort.  Many thanks to Angie of Hackbright Academy, who provided so much organizational support, to Amazon Web Services, who provided the food, Asheesh Laroia of OpenHatch, who knew how to make this open-source event a success, Jeremy Dunck, who represented the Django Organization, and all of the mentors who showed up.


All photos by Angie Chang.


Mapping data: step one in creating an interactive, animated map

Back at Hackbright, I knew data visualization was what I wanted to do, but getting to where I knew how to use the tools took a couple of additional months.  See, there’s a steep learning curve with data viz, and unlike Python and Javascript, D3 and mapping doesn’t have a local active community where you can easily find support as a beginner.

My final project at Hackbright involved sorting data from Twitter and mapping it to try to draw conclusions about neighborhoods.  I used  the Google Map api, and hand drew bounding boxes to create the polygons, and, I have to confess, a fairly ugly map.  Then, I used Google Charts to generate a series of visualizations, with a basic Bootstrap layout to display them.  For a first project, it wasn’t bad, but now that I’ve got some experience in data viz, I’m looking back at each of the elements, realizing that now I have the skills to make my project in a way that’s easier, prettier, and far more sophisticated, in less time.  It’s pretty amazing to see that growth.

The first mistake I made at Hackbright was the map. I hand coded bounding boxes using the Google Map api, painstakingly defining by hand the rough bounding points of the neighborhoods, then importing to display a fairly standard looking (yawn) map, the kind that (snore) you might use to look at freeway directions.  As someone with a tremendous panache addiction, this was pretty depressing.  I’ve learned a lot since then, and the steps for making a basic map are outlined below.

THIS.  THIS IS SO MUCH BETTER.  I’ve outlined the steps below


Being a wiser engineer now, here’s what I did:

1. San Francisco does a great job online at organizing public data for downloading, including neighborhood shapefiles.  This one here defines the neighborhood shapes in the city much more accurately than my ugly little bounding boxes.  Shapefiles are nasty looking, and while it’s possible to work directly with them, they’re not particularly friendly on their own.  GDAL and OGRE are very difficult to use as tranformation tools, and why bother? All the random characters are just representing vector data, which we can easily convert into a much friendlier geojson using online tools like this one.   Now we have a friendly little json file.

2.  Given this happy little friendly json file, now we just need a mapping platform and a tile generator.  I like Leaflet and Cloudmade (both free for personal use), but there are plenty of others out there to play with.  Cloudmade requires you to generate a personal access key.  With both of these, creating the initial map is super simple and looks *amazing.*   Setting up Leaflet is pretty simple; like D3 or other libraries, you can either download it or link directly, so in this case, the basic heading looks like this:

<div id=”map” style=”width: 800px; height:800 px”></div>

<script src=””></script&gt;

<script src =”sfneighborhoods.json”></script>

Cloudmade, by the way, is a tileprovider.  The tile layer of the map is the part you can see – literally, each map, at each zoom level, is made up of squares that get sewn together at rendering.  In the basic leaflet tutorial, you’ll see this chunk of code that’s used to add your tiles to the map:

var tileLayer = L.tileLayer(‘http://{s}* your* api * key */1960/256/{z}/{x}/{y}.png’, {
maxZoom: 18,
attribution: ‘Map data &copy; <a href=””>OpenStreetMap</a&gt; contributors, <a href=””>CC-BY-SA</a&gt;, Imagery © <a href=””>CloudMade</a>&#8217;

What’s not obvious here: each design in cloudmade is given a number, and you can replace 256 with any one of them to change your map’s appearance.  I wish that had been more obvious when I was starting out on this kind of project.

So now, dear reader, you no longer have to suffer through hand coding.  Next, we’ll make it interactive, and show ALL THE DATA.  It’ll be fun.

transposing dictionaries inside a two dimensional list

As usual, the code is written in burgundy. 

I had to ask for clarification a few times during the interview process, because it’s so difficult to explain this in plain language without giving a hint of the answer.  We’re starting with a list of lists of dictionaries:

[{‘a’:’b’}, {‘c’:’d’}, {‘e’:’f’}],
[{‘g’:’h’}, {‘i’:’j’}, {‘k’:’l’}],
[{‘m’:’n’}, {‘o’:’p’}, {‘q’:’r’}]

And we want to transpose the dictionaries so our output, like so, ends up like this:

new_lst = [
[{a:b}, {g:h}, {m:n}],
[{c:d}, {i:j},{o:p},]

For each index of lst[i][j], where i is the row number, and j is the column number, we want to replace lst[i][j] with new_lst [j][i]. 

I admit this took me a while, and it comes down to identifying the variables and how they’re changing. Just like when you rotate a matrix, as I did in a previous post, you isolate the variables, and find their patterns of change by looking at as many examples as you can.  I’m going to skip through some of this logic, since I’m still crazy jet lagged and it’s about 4 am according to my body’s clock, and cut to the chase here:

Let’s break it down into pseudocode:

1. Create a new two dimensional list with the same structure. 

2. Iterate through identifying each list in the main list as i.

3. Iterate through inner lists as j.

4. Append to the new list, switching indexes i and j. 

# Create the new list, filling in values as None, which is particularly useful if we have a jagged 2-d list.  A list comprehension in this case is actually useful here – usually they’re decorative little parlor tricks:

lst_new = [[None for x in range(len(lst))] for y in range(len(lst))]

#now we just iterate:

for i in range(len(lst)):

    for j in range(len(lst)):

        lst_new[i][j] = lst[j][i]



Pattern matching: starts with, ends with

Regexes are daunting, but, before you can get to the deliciousness that is natural language processing you need to be able to process your text.  My current project has to do with attempts at simile interpretation, so as a first pass, I’m trying to find strings within my corpus that start with “like” and end in a period, and this is a perfect regex exercise.

The first thing to know is that re.match and aren’t the same beast at all, and choosing the wrong one will break everything.  In a nutshell, will search the entire string, whereas re.match will only search the beginning or match the whole string.

Let’s start with a string by Cormac McCarthy:

s = “ “Jimmy Smith was moving through the room like an enormous trained mole collecting the empty cans.”

We can start by matching “like” with the following search:

match =‘like’, s)

To peer inside the object, we just use

OK. Pretty easy so far, but we want to return the rest of the sentence, up to and including the period.  This gets trickier, but it’s not bad – it’s just a question of mechanically plugging in the right variables.   The relevant regex chars are these:

  • (like) will search for the words in the parenthesis grouped together
  • . is a wildcard and represents any character at all.  We’ll use this.
  • * allows for any number of repetitions of a character.
  • \ is an escape key so we can use the . to look for punctuation
  • ^ and $ represent the start and end of a search string, so we start with ^ (like) and end with \.

Aaaannd … putting it all together, here’s our magical search string so far:

match ='(like)(.*)\.$’,s)  will return “like an enormous trained mole collecting the empty cans.”

Truly less terrible than you expected, isn’t it?

Linked List in Python

There’s a lot of discussion online about linked lists, and most of it seems to agree with the idea that it’s important to know how to use them, and that you never actually do even though they’re technically faster from a memory standpoint.  There are lots of examples out there online; this just happens to be mine. 

A linked list is comprised of nodes.  A node has two parts: cargo (the data, which can be anything, really, from an integer to a bundle of software, to inventories of jars of glitter) and a pointer, which, well, points to the next node.   So we create our node object and give it necessary attributes, and a repr function to translate the object to a string. So far, pretty fundamental:

class Node():
    def __init__(self,data): = data = None
    def __repr__(self):
        return “Node(%r, %r)” %(,

A linked list is just a bunch of nodes strung together, starting with the first node, which is called the head. Let’s initialize an empty list, and give it a couple of functions – one to add nodes (either a head or a normal node), and one to print the list:

class LinkedList():
    def __init__(self):
       self.head = None

   def __repr__(self):
       return “List(%r)”%(self.head)

    def AddNodes(self, new_node):
         if self.head == None:
             self.head = new_node
        elif is None:
    = new_node
              node = self.head


              if not
                    print “adding new_node %d” %
           = new_node
                   node =

And this to print the list:

     def printall(self):
            print “this is head %r” %(self.head)
            node = self.head
                print “this is node %r” %(node)
                node =

Transforming a dictionary

This is one of the algorithms I was given at an interview this week. 

Starting with a dictionary of names and ages like so:

d = {“Sam”: 27, “Sara”:22, “Andrew”:41, “James”:22, “Rose”:27}

Transform the dictionary in such a way that the ages are the key, and as values, you have all the people with that age.  Basically, this algorithm tests your ability to manipulate of one of the most fundamental data structures in programming. 

Steps are fairly simple if you know basic dictionary syntax, but in the interview I was flustered, and used .get() unnecessarily. 

1. Create a new dictionary, and define its keys as the values of d, and for its values, give it an empty list.

2. Go through the first dictionary and add the key to the list in the correct value.  

def transform(d):
    new_d ={}
    for k in d:
        new_d[d[k]] =[]
    for k in d:
    return new_d



Rotating a matrix in Python

Interviewing preparation, as any coder will tell you, involves practicing the process of programming an algorithm on a whiteboard. This seemingly dadaist exercise of writing lines of code with dry erase markers while being evaluated for your problem solving abilities in order to predict how well you can sling bytes of code at real world problems is actually a huge determinant in career success.  I didn’t design the system, so here we are.

This algorithm would have been much easier to do using the numpy library, but that defeats the purpose and takes away the fun.

Given an two-dimensional matrix, rotate it 90 degrees clockwise. Let’s start with a simple 3 x 3.



m =[
[0, 1, 2],
[3, 4, 5],

[6, 7, 8]


[6, 3, 0],

[7, 4, 1],

[8, 5, 2],


So if we think of this as having column (horizontal) indexes 0-2, and vertical indexes 0-2, we can start sussing out patterns. Breaking this down by indexes, we can figure out a few rules:

  • m[0][0] –> m[0][2]
  • m[0][1] –> m[1][2]
  • m[0][2] –> m[2][2]
  • m[1][0] –> m[0][1]
  • m[1][1] –>m[1][1]
  • m[1][2] –>m[2][1]
  • m[2][0]–>m[0][0]
  • m[2][1]–>,m[1][0]
  • m[2][2]–>m[2][0]

Let’s label each of the four indexes:

m[a][b] –> m[c][d]

Now we can set up some rules:

1. m[b] = m[c]

2. m[d] = len(m)-1-a

To code this:

1 Initialize your new matrix

2. Iterate through the lists, and then items in lists in m

3. Define d

4. Add items to your new list as defined above.

def rotate_matrix(m):
    new_m = [[0 for i in range(len(m))]for j in range(len(m))]
    for a in range(len(m)):
        for b in range(len(m)):
            d = len(m)-1-a
    return new_m