This is a reposting or an article for the Ona blog.
It's been a big year for the Ona tech team! In this post, we look at what we built in 2016.
Ona platform tech in 2016
In 2016 we added more new features to the Ona platform than in the previous two years combined. Here's a run-down of select features we added to Ona in 2016:
CSV uploads – Upload any CSV into Ona and we'll automatically build an XLSForm from the CSV's columns with data types guessed based on the data. E.g. if a column has only dates we'll assume it should be formatted as a date type, but give you option to adjust that.
Photo gallery – View only the images from your dataset in a grid-based gallery or full-screen slideshow.
Dynamic form linking – Use the data in one form to populate questions in another. For example, you could use a school registration form to collect the list of all the schools in your district, and then in a school performance form you could have a drop-down menu where users choose one of the schools from the registration form and then add additional performance data about that school.
RapidPro integration – Forward incoming data from Ona to RapidPro and trigger flows based on that data. E.g. send out a text message to a number submitted in an Ona form with a message based on that submission's data.
Google Sheets integration – Connect your dataset to Google Sheets and as you submit new data, or edit existing data, Ona will update your spreadsheet. You can use this to create lightweight dashboards with realtime data collected using Ona.
In addition to the new features above, we improved performance to handle the 4.5 million new submission we received. This was a jump from an average about 6,500 submission a day in 2015 to 12,500 per day in 2016. Next year we'll be putting even more focus on performance and fix anything that might be slowing you down.
OpenSRP tech in 2016
We've made significant improvements in the OpenSRP platform. As the technical lead on OpenSRP our biggest task this year was transitioning the server and client to use an Event/Client data model. This helped us support more efficient client-server data synchronization.
We'll continue to be busy with OpenSRP next year. We're about to roll out a number of new implementations, including a generic vaccination register. And we’re also very excited that the UNICEF Innovation Fund invested in OpenSRP as one of their inaugural five technology investments.
Free Open Source Software at Ona in 2016
We're still improving the documentation and doing clean up, but in late-2016 we published an updated version of our core data collection application, onadata (Github). This fixes some serious issues encountered when running at scale, introduces a more robust permissions model based around projects, and stores all data in PostgreSQL + PostGIS database. All new development will take place in this repository on the master branch with stable releases (Github) tagged.
We've continuously updated milia (Github), our Clojure/Script Ona Client API library. We've added libraries to interact with more API endpoints and improved overall stability. Also in the Clojure world, we've been incrementally adding functionality to our Clojure/Script utilities library chimera (Github) and our data viewer library hatti (Github).
Finally, we've released a public version of the STEPS app developed for the World Health Organization's STEPwise approach to noncommunicable disease risk factor surveillance. If you're interested check out the the code for the Android steps-app (Github).
We're excitedly looking forward to an even bigger year in 2017. Happy new year from the Ona technology team!
About 5 years ago I was a researcher at Princeton and worked with Mitchell Duneier. We used historical text analysis to evaluate his thesis, it's great to see his book in print. To do part of the analysis I used Google's text n-gram data and a mix of Python, awk, bash, and R scripts.
Map Your World empowers youth to explore issues and ideas that matter - like clean drinking water, or food justice – then write surveys, collect data, and create maps to make change in their communities.
Yesterday I spoke at PyConZA 2014 about Ona's work building the vote tallying system for the Libyan Constitutional Assembly Election last February.
The slides from my talk are below:
Here is the abstract:
Earlier this year Ona was given three weeks to write the software that will tally votes in the Libyan elections and decide who wins and who loses. This is not something we could get wrong. We combined agile development with best practices in testing and QA to build an open source tally system that was well tested, accurate, and easy to use. We will describe a success story of iterative behavior/test-driven-development under extreme conditions. Did the structure of the data change the day before the election? Yes. Did we have the tests to ensure that our implementation changes would not compromise the system's integrity? Yes, and they didn't.
This talk provides a narrative to both Software Engineers and Tech/Product Managers describing why best practices are essential for any organization and any project of any size. We will provide the audience with:
Real world examples they can implement in their own workflow and organizations,
Insight into what succeeded (quick iteration with prioritization) and what was challenging (nothing being static),
Anecdotes and coherent arguments they can take back to their organization to advocate for best practices.
At Ona we are rebuilding our data management platform. We are
starting with a light weight front-end that will serve up content pulled
from the REST API of our current application.
We are aiming to have the back-end in Clojure, the front-end
in ClojureScript, and the infrastructure
in Clojure using Pallet. We are excited to have a
single (and a great) language handle all of these responsibilities.
We are still at a very early stage but we are a distributed team and like to
have our apps on development boxes as we go. This allows us to share a common
reference point, give mini-demos, and QA each other's changes. Like Fabric for Python
and Capistrano for Ruby, Pallet let's us do quick
deploys of the latest master or branch code.
Even better, Pallet let's us write Clojure to bring up new clusters, similarly to Puppet, Chef, or Ansible – but in Clojure. We deploy
to EC2 on AWS and are glad to avoid spending time mucking around in the AWS GUI.
A succinct pallet file
specifies the instance, the web application, and the deployment. Putting the current
code online and bringing up a server (if one doesn't already exist) is a single command:
lein do uberjar, with-profile +pallet pallet up \
This tells Leiningen to first create an uberjar,
which puts all of our app's dependencies in a single jar file. It then uses
the pallet profile to install, configure, and deploy our application. This
command is idempotent, making it easy to push the latest jar up.
A nuance we did not anticipate is that you cannot output logs to stdout in a
Jetty app. This is not particularly surprising, but using stdout was a development
configuration that we had not yet bothered to abstract.
This does the normal logging if verbose? is true and otherwise does nothing.
When you run lein ring server-headless a handler is called which sets verbose?
to true. When you run the app through java -jar ..., as in our pallet configuration,
verbose? is set to false.
The ona-viewer project is a work-in-progress and we would welcome any feedback. Check it out on github.