Code for America: Philly 2012

This past weekend I attended the Code for America event held at Azavea’s offices around 12th and Callowhill. Their office was spacious and well accommodated, but the wireless was slow during the day.

I met a coworker, Hector, there and had some coffee and breakfast. We didn’t really get started until at least quarter of ten, a bit late. Organizers passed out Post-It notes for us to write down ideas. Various people involved in city government and other civic organizations took turns presenting their ideas of projects to work on. I took notes as best I could and when they were done, we discussed which seemed most interesting to work on. People were encouraged to stick the ideas written down onto a whiteboard at the front of the room. Half of the participants helped to group the ideas by topic.

Hector and I talked again about what to work on. Organizers meanwhile passed out colored dot stickers to use in voting for ideas. Once the herd thinned out, we voted as well. Once the voting was complete, 8 main topics/ideas were selected and participants self-selected into those different groups. We considered working on a project to make lobbyist information accessible, but decided to work on a project to publicize statistics about the plight of the more downtrodden areas of the city.

Originally, the concept was to take statistics about the city such as crime and poverty rates, and relate them to a person through their neighborhood. Someone would enter either their zipcode or various other statistics about themselves (perhaps highschool class size), and the site would use that information to give them a statistic like:

If you lived in Philadelphia, only 58 of the 100 students in your class would’ve graduated.

or

If you lived in Philadelphia, 3 of your 200 neighbors would’ve been the victim of violent crime.

We discussed this concept with other people, and someone suggested this type of site might make someone glad they didn’t live in Philadelphia rather than promote civic engagement. This helped to lead to the concept that we eventually ran with. We decided that we should use people’s friends to illustrate the statistics.

So, we went to work implementing Facebook authentication, querying the Graph API, designing the site views, and writing code. I mostly paired with Hector and focused with him on the Graph API. We needed to retrieve friend names and profile pictures. We worked on various other pieces such as sampling friends for the statistics, wiring up the views, and pushing to Heroku.

We had some last minute difficulties shortly before our demo, including:

  • Heroku having limited functionality for the free-app tier
  • Problems connecting the site on Heroku with the Facebook app
  • Wireless network issues
I am proud of the project we completed, especially since I think we all had fun working on it. There are some things that could be improved, but it was a great experience overall. It’s up now if you’d like to check it out at http://theotherphiladelphia.org. We wound up winning 3rd place. Here’s the repo location: https://github.com/CfABrigadePhiladelphia/the-other-philadelphia.

In case you’re wondering, the project that won first price was http://lobbying.ph/, the site that provides information about Philadelphia’s registered lobbyists. Technically Philly has a writeup about the event. You can find our presentation on Viddler.

Philly Give Camp 2010: Part 5

The Builder

To keep the teams working as separately as possible with the least interference, we decided that the PAAL Builder, the tool used to build student schedules and lessons, would be completely HTML and Javascript. That means that there would be no server-side code, no ERB or HAML template files, and no Rails special sauce. This allowed the designers to work without developer support, and allowed developers who did not know Ruby or Rails to work solely on Javascript code. The Builder would interact with the API via ajax calls with JSON responses. A simple format for the response envelope was designed:


{
version: 0.1,
error: '',

data: {
  task: {
    id: 1,
    name: 'Brush Teeth'
  }
}
}

This is an example response upon the creation of a task with the name “Brush Teeth.” On each request, the error property would be checked to make sure that it was blank. The version property would also allow changing the API in the future without breaking the application.

In the previous post I discussed the problems of having a simple API. One common scenario is to create a task and link it with a parent task. This would happen if you wanted to create a task like “Brush Teeth” and steps underneath it like “get toothpaste,” “get toothbrush”, “brush front teeth.” Here is the code necessary to do that (I am just posting the necessary jQuery calls rather than the wrapper functions I wound up writing):

// create the task via a POST
$.post(
  '/tasks',
  taskData,
  function(envelope, textStatus, request) {
    if ( envelope.error != '' ) {
      // error
    }
    else {
      // on success, tie the newly created task
      // to a parent task
      function callbackSuccess(newTask, envelope) {
        $.post(
          '/task_parents',
          {
            task_parent: {
              task_id: newTask.id,
              task_parent_id: some_parent_id
            }
          },
          function(innerEnvelope, textStatus, request) {
            if ( innerEnvelope.error != '' ) {
              // error
            }
            else {
              // success!
            }
          },
          'json'
        );
      }
      
      callbackSuccess(envelope.data.task, envelope);
      
    }
  },
  'json'
);

Wrapper functions make this simpler to understand, but the fact that it requires two posts troubled me. Still, I avoided adding a new method to the API to do this all in one step.

When we were working on the project, the designers and another developer worked mostly on basic UI. I then worked on “installing the plumbing” as I put it, making all the API calls and using the live data. A lot of this plumbing went into the product after Give Camp. One aspect of the project I found hard after Give Camp was figuring out how a feature or UI element would work. Often, I’d be hooking up the plumbing, but be unsure of whether they wanted a stand-up shower or a bathtub. Both would get the job done, but I wasn’t sure what they had in mind, and it wasn’t clear from the design.

Part of this was due to the fact that I didn’t have the most recent design. We switched versioning systems two times during the course of Give Camp, and repository locations 3-4 times. Part of this was due to lack of notes or obvious visual stimuli. In general, after Give Camp was over, it was hard to coordinate with each other.

Mediawiki-Usage/Changes Storage and Visualizations

A coworker and I have been doing some work on visualizations of wiki updates. The server-side code, written in Ruby, stores changes from a media-wiki feed.

Media-wiki Changes Feed

Media-wiki Changes Feed

I got a chance to use the Google Visualization API, which is really simple and useful for a wide variety of domains.

He also turned me on to HAML, which offers a concise, structured way of specifying HTML.

Project Page: http://github.com/hectcastro/mediawiki-usage/
Demo: http://www.angelforge.org/mediawiki-usage/

Media-wiki Changes Visualization

Media-wiki Changes Visualization