Kundi Bora: Personal Analytics

Where Does the Time Go?

With the end of March approaching, many of us are looking forward to spring but I’m going to take a look back at the work done to get this point. Working on our plugin for Ushahidi has differed from other software projects substantially. Starting out, our group spent time familiarizing ourselves with the Ushahidi project. Unlike other university projects though, started with the code and the documentation rather than just the documentation. This code was the code we’d have to work with and eventually edit for our own means which has made a very novel experience for me. Reading of other’s code has been a core element of the development of our plugin as working in a group means having to understand and using the code that others in the group have written.

Git it Together

One challenge our group has faced is working with the same code. Each of us has our own copy of the plugin forked to our personal public repos on github but, as of this writing, the code on the our private group github repo is not the current code. The problem has not been infrequent commits but rather no pushing those commits to the github group repo. this has led to a few challenges in trying to make progress.

One issue has been knowing what needs to be done. I have found it hard to know what to work on with out having the most current version of the code as I do not want to duplicate work others have already done or work on the same features as others. Working on the same features without knowing the specifics of what others are working on can lead to some pretty ugly merge issues and also wasted time.

My own workflow includes the following git branches in my repo:

  1. develop: the working directory for our group’s repo on github. Has the current code found on github.
  2. master: the master directory linked to the master on our group’s github.
  3. myDevelop: the working directory for my forked version of our group’s repo on github. Holds all my changes that I have not merged into the group’s github repo. I’ve pushed these changes to my github account.

From the pair programming I’ve done, I fear that merging the groups code together at this point will be no small task.

A New Way of Developing Code

A lot of the work I’ve done has been working with the code that a team member has written. He flew out of the gate and wrote much of the code that did the job of integrating the flot.js charts into a plugin for Ushahidi. This has led to me using this code to add more charts and streamline the process of adding charts. Much of the initial code has been replaced either partially or completely. It wasn’t technically wrong but it wasn’t flexible. Adding a new chart involved a lot of duplicate code if that chart type was already being used. SQL queries also had to be hand crafted for each new chart which ate up a lot of my time as I have never dealt with mySQL before this project.  The solution to code redundancy is straight forward and function were created to handle multiples of the same chart type. Streamlining the SQL queries that are required to build the JSON objects needed by the charts has been less so. One member has been working on using switch-case statements to allow queries to be built using a string rather than having to handcraft the query for every chart. MySQL has been not taken kindly this attempt as syntax errors are a common obstacle.

While working with a large code base such as Ushahidi can be daunting, there are advantages. I find it can take me a while to get into developing a new program, especially as they get increasingly complex, as the starting point is not always clear. Or the starting point may be clear but the specification may be open ended causing a abrupt halt once the trivial components have all been fleshed out. This halt is partly due to the difficulty in visualizing code. An established code base can be very helpful in this instance as it may be ripe with code similar to what you need to implement the feature you after. This was the case with our plugin as the Kohana php framework underlying Ushahidi is fundamentally modular. Ushahidi is a collection of modules, some of which are not optional. To build our plugin, we simply mimicked how the other modules of Ushahidi were implemented.

Dear Diary

During the last month, I kept track of our group meetings and pair programming in the following file: 

-group meeting from 1330 to 1530
-trio programming from 1400 to 1500
-Spent about 2.5 hours on the following:
  -> create view for a new chart
   ---add the required HTML
   ---add required javascript hide and show the chart as well as plot it
  -> add controller code that retrieves the JSON for the new chart
  -> add the model function that queries the database
   ---query does not properly formatted at this point
-spent ~2 hours:
  -> working in analytics/model/analytics.php to build a new SQL query for
  a new pie chart that will display the number of incidents per country.
  -> starting to streamline javascript in controller 
-group meeting from 12:30-14:30
-prep for presentation
-discussion about d3
-Julian and charlie worked on integrating d3
-Julian and I worked on building SQL queries
-I worked on reducing redundant code in /analytics/controllers/analytics_json.php
  -> added arguments to functions to allow functions to be passed as
  parameters rather than copying the function code for every chart we want to
-Spent about 2 hours preparing for the part B presentation. This involved taking 
screenshots of code changes and writing relevant descriptions as well as writing 
slides that describe issues we had encountered as well as our goals moving forward
-pair programming with Julian from 11:30-13:30
-looked at what files need to be modified to add filters
-looked at how to grab categories for filters
  -> grabbing from database
  -> inspected the filtering in the reports tab
  -> discussed what we want to allow users to be able to filter
  -> discussed how we would deal with charts that require specific x and y 

While this may be a crude way to do it, I found it fairly effective though there have been a few shorter (~30 mins.) sessions that occur after class between group members that haven;t made it in here. These sessions were only tangentially related to developing the plugin as they focused around using git and issues we were having with file permissions.

Looking Ahead

At this we point, we can see the finish line but that doesn’t mean there isn’t a significant chunk of work left. We would like to have filtering working within the next week so that users can choose what that charts display. Adding a few more charts and chart types would also show potential of analytics within a data driven project like Ushahidi. A less sexy item on our to do list is making sure the code adheres to the Ushahidi projects coding standards as we’ve neglected this aspect of contributing to a software project. Finally, we would like to streamline the code as much as possible which involves mainly adding flexibility through functions instead of hard-coded javascript for each chart.

Introducing Kundi Bora: Analytics for Ushahidi


I am taking a class in University that has us contributing to a Free Open Source Software (FOSS) project as a means to learn about real world project development. FOSS is a great way to cut your teeth as a software developer because these projects rely on contributions from anyone with the skill and time to do so. Contributing to a FOSS project allows a developer, especially one just starting out, to build their portfolio outside of school and on top of whatever employment they may or may not have as a developer. Large FOSS projects, Firefox for example, are usually managed professionally by a dedicated team and so contributing to them builds experience working within a development team and environment where there are coding standards to follow and team members who you work with and who scrutinize your work.


Ushahidi is a FOSS project developed to take in and represent data geographically. It was initially developed in response to the unrest following the 2008 kenyan elections. Ushsahidi was used to take in reports of unrest and represented them on a google map of Kenya. Since then, Ushahidi has been deployed for tracking disasters to pot holes via user submitted reports and boasts 3000+ deployments.


Ushahidi 2.7.2 uses the Kohana php framework. This framework uses a modular cascading file system. Ushahidi is modular in its very nature, with the default directories present in a basic Ushahidi install being essentially hard coded modules. We added to this by adding out plugin to the plugins folder.

The arrows and their direction represent decreasing precedence.