Moving On13 June 2016

June 17 will be my last day as CTO at Public Good. I am moving on after three years and joining the team at Ad Hoc.

I am proud of what I have accomplished with the team at Public Good. Over three years we have built a powerful platform that has processed more than a million and a half dollars of donations for hundreds of nonprofits in the United States. We’ve helped thousands of people find the organizations and causes that they care about. We built online fundraising software that’s faster, easier, and cheaper to use than any competitor in the market. We built an innovative tool to connect folks that read the news to the organizations and causes related to what they just read. From a pure technology standpoint, we’ve made tens of thousands code commits and nearly two thousand releases.

We have built quite a bit, all that on a team that has rarely exceeded 10 people total, and only 4 full-time engineers. Personally, I have learned a great deal about building technology and teams, and all of the ups and downs involved in the rollercoaster that is a venture-backed product-first technology startup.

I joined Public Good on September 3, 2013. Since then, the company has gone through three major product pivots: the original vision for a data integration platform as a service, inspired by the work Dan, Jason, Paul, Aaron, and I (the original PGS team) were involved with on the Obama 2012 reelection campaign; then a two-sided marketplace joining nonprofits with new donors; and now a focus on linking news readers to organizations and causes related to stories that inspire them to act.

Through each stage of product evolution, I have been challenged to learn and adapt to the needs of the people using our systems. As a result of working with our most recent partners, large media organizations, I’ve learned that I don’t have the desire or passion to build the products they want. I've also spent time reconsidering how much risk I am comfortable with, and realized that I no longer want to be part of an early-stage startup. I have decided to move on as a result.

I am excited to join Ad Hoc for two reasons. First, they employ a number of people I admire and have had the pleasure of working with before, namely Paul Smith and Daniel X. O’Neil. Paul hired me at Public Good, back in 2013, and Dan hired me for a 9 month spell at Smart Chicago where I helped him build the beginnings of the CUT Group,, and a bunch of other civic-minded projects. Second, I am impressed with Ad Hoc’s meat and potatoes approach to building software that solves problems. Reading their case studies and coverage in the press, I am struck by their simple, direct approach to solving real problems that affect real people. The size and scope of the problems they're trying to solve, like making it easier to get health care and simplifying the process for getting veterans' benefits, is impressive (and more than a little intimidating). I believe that, as part of the Ad Hoc team, I will be able to effect real change and have positive impact on peoples' lives.

I am grateful for the opportunity I had at Public Good, and sincerely believe that the team will be successful. The folks that remain are smart and more than capable of building a fantastic product. I remain a cheerleader and ardent supporter.

Talking Go at SXSW Interactive 201520 March 2015

On March 17, 2015 at 9:30am in Salon B of the JW Marriott in Austin, Texas, I delivered a talk titled "Lessons Learned Building Web Apps with Go" to a crowd. The talk covered much of what the Public Good team has learned over the past two years building

The slides are online at I look forward to refining the content of the presentation and sharing it again in near future.

2014 Music Top 1014 December 2014

Some friends compile an annual review of their favorite music and asked me to contribute. Here's what I had to say about 2014.

Top 10 albums of the year ranked in order.

  1. Aphex Twin - Syro: This the is Aphex Twin album everyone wanted. Certainly worth the wait.
  2. War on Drugs - Lost in the Dream: I don’t think I listened to any album while driving around the Midwest as much as I did this one.
  3. Tycho - Awake: At first Tycho was a Boards of Canada clone, but with this album they finally shake that off and assert themselves as the real band that they are.
  4. The Budos Band - Burnt Offering: I love listening to music that makes me feel like I’m in a late-70s police chase scene.
  5. Jungle - Jungle: These dudes came out of nowhere to remind us all that disco wasn’t terrible.
  6. The Antlers - Familiars: I listened to this a ton then deleted the Spotify playlist and forgot about it. I’m adding it mostly based on the strength of the amazing show they put on at Lincoln Hall.
  7. Clark - Clark: Pretty heavy and intimidating end-of-the-world music. I dig it.
  8. Spoon - They Want My Soul: These guys are flawless.
  9. Caribou - Our Love: A late addition to the list but incredibly catchy.
  10. Various - Hyperdub 10.4: Another late entry, but a great cross section of music from the legendary London label.

Top 10 songs of the year ranked in order.

The War on Drugs - An Ocean In Between The Waves

A Sunny Day in Glasgow - MTLOV (Minor Keys)

Jungle - Busy Earning

Aphex Twin - minipops 67 [120.2][source field mix]

The Budos Band - The Sticks

Caribou - Our Love

Tycho - See

(this video is bonkers, you should watch it)

The Antlers - Hotel

The War on Drugs - Red Eyes

Spoon - Do You

The Beyoncé Award for the 2013 album you wish you would have included on last year's list.

nothing comes to mind

Your favorite album you discovered in 2014 that did not come out in 2014.

Disc Two of Derek and the Dominos “The Layla Sessions: 20th Anniversary Edition”. It’s all the session players (including Duane and Gregg Allman, Dickey Betts, and Eric Clapton) jamming for an hour straight. I love it.

Best concert you attended this year.  

Slowdive at Pitchfork this past July. Specifically, this:

Honorable mentions: TWEEDY (thanks for taking me on a date, Brian!), and Tycho at Concord (another date night with BB!).

No honorable mentions.  

Honorable mentions: Run The Jewels 2, Yo La Tengo - Extra Painful, She & Him - Classics, Arca - Xen, A Sunny Day in Glasgow - Sea When Absent, Sun Kil Moon - Benji, Future Islands.

HealthNear.Me23 March 2014

In November 2013 Melissa and I built HealthNear.Me, a web and phone-based application to help people find public health resources near them in Chicago.

HealthNear.Me Screenshot

After we surveyed the current tools people have to use to find a free clinic or a place to find free condoms near them, we knew we could build something better. We also built it because we wanted to enter the Making Public Health Data Work Challenge. We won the first place prize in the competition and we're excited to share a bit more about what HealthNear.Me is, how it works, and how we can improve it.

Search results page of HealthNear.Me


Melissa and I attended the Illinois Public Health Datapalooza to learn more about what was happening at the intersection of the public health and technology fields. Melissa is finishing her Masters degree in Public Health, and I am a software developer, so this was a rare intersection of our professional interests. We sat in on a few interesting talks at the event and decided to build something for the app contest. Our first idea involved an app for folks with asthma to record air quality and get alerts for when they might have bad days. A few minutes of Googling showed us that the market was already pretty saturated with apps that did just that.

Looking for a new angle, Melissa started to survey the available health-related datasets on the City of Chicago and State of Illinois data portals and found many lists of service providers; at the same time I reviewed the City of Chicago and State of Illinois web sites to see how the general public could locate service providers near them. What I found was a fragmented, hard to parse set of pages. Results were broken up by type, search by address wasn't available, and the sites didn't work very well on smart phones.

"Find a Clinic" on the Chicago Department of Public Health Site

It was obvious that the experience for finding public health providers was suboptimal, and we could use the raw data published by Chicago Department of Public Health (CDPH) and Illinois Department of Public Health (IDPH) to build our own search tool. I am a big proponent of Tim O'Reilly's argument for government as a platform. Paraphrasing quite a bit, he argues that governments are very good at providing raw data, but not very good at building consumer applications. By focusing on their strengths – collecting, managing, and publishing data about their services – governments can leverage developer communities or hire professional developers to build consumer-facing applications. In this case, the CDPH and IDPH provided immense value by providing relevant, consistent, machine-readable lists of service providers. If they did not publish this raw data in a sane format, we would have never been able to build HealthNear.Me. In the course of a few evenings of coding, I had all of their provider data aggregated, indexed, and available for public searching.

Melissa and I talked about how we thought people might want to look for health resources near them, and what features would be the most useful for them. We didn't spend too much time on design research doing things like interviews or developing personas. Instead, we tried to guess a few common uses cases and build features to support them. For example: "I am a social worker and want to find clinics near where one of my clients goes to school" or "I need to find a place to go warm up" or even "What is the nearest hospital?". One feature that we prioritized was making the application work via SMS. I was inspired by the rich SMS search features available in the Chicago Early Learning site. The City of Chicago has a basic SMS service – CHITEXT – but it doesn't support searching for health providers.


I wrote the backend search index and API in Go. The health provider data lives in an ElasticSearch index. The public-facing application is HTML and AngularJS. Go makes writing APIs very simple. It's fast, handles JSON well, and integrates well with the ElasticSearch. ElasticSearch is fast and does geospatial searches with ease. AngularJS is great at gluing together front end applications and JSON APIs. This technology stack is also what I use for my day job, so I was already very comfortable working with it. The application is running on an EC2 instance provided through Smart Chicago's hosted web space. I signed up for a cheap Twilio plan to handle the SMS integration. Twilio makes it super simple to read and write SMS messages from inside computer programs.

Screenshot of SMS interaction with HealthNear.Me

The application is broken down into two main components: a bulk data loader and a HTTP API. The loader app reads the JSON exports of the CDPH and IDPH data and inserts it into the ElasticSearch index. The API app handles requests from Twilio and the AngularJS application, searches the index, and returns data as a blob of JSON. I'm grateful to a a number of open source libraries that made development much faster, especially the Elastigo and go-geo projects. The entire application source code is available at the health-near-me Github project page. It's licensed under the MIT license, meaning anyone can take the code, make improvements, and run their own local instances of the application.


Melissa and I are excited to continue to develop and refine HealthNear.Me. We've had productive conversations with CDPH about how we can work together to make the application available to the community and how we can increase the quantity and quality of the data in our search index. We would like to explore translation and localization to make it easier for users who do not speak or read English to search for providers near them. The user interface is rough around the edges, owing to a short development cycle and a lack of graphic design skills. We would like to improve the look and feel, and make the search results on the web application more actionable, including showing results on a map and seeing what providers in an area provide multiple services.

We're exceptionally grateful and honored to win the first place prize. We hope that HealthNear.Me continues to grow and becomes a useful tool for people in Chicago and beyond to find public health providers in their communities.

Building Chicago Works For You29 September 2013

Note: this essay was originally posted at the Smart Chicago Collaborative blog as part of my work as Civic Innovation Program Manager.

Chicago Works For You (CWFY) is comprised of three components: a AngularJS/Jekyll frontend, a custom Go API and worker layer, and a PostgreSQL/PostGIS database. This post will dive into the mechanics of the system and explain why it works the way it does.

CWFY started with only a handful of requirements. It had to pull service requests from Chicago's Open311 API, save them to a database, do some math, and expose the results to a pretty user interface.

The first sketch of the system was pretty rudimentary, but it matches very closely the end result. We implemented the worker and API in Go, a powerful and fun language that is well-suited for this type of work. We are hosting the Go applications and database on a m1.medium EC2 instance on the Smart Chicago Apps infrastructure.

The worker application finds the timestamp of the most recently updated service request in the CWFY database and asks the Open311 API endpoint for all service requests created or updated since that point. This repeats every thirty seconds. That interval is short enough that we're not clobbering the Open311 API, the number of requests in the response is small (usually less than a dozen), and we still have near-real-time data on our site. We've found that the Open311 API is very reliable — and fast — and can stand sustained load, as it did when we backfilled our database.

The database schema is very simple. There is a single service_requests table with more than three million rows. That's all service data stretching back to January 2008. This table is very similar to the service_requests schema used by Code for America's application. In fact, we used that schema to bootstrap this application.

There are two tables of ward boundary data, one for the current ward boundaries, and one for the new ward boundaries, to be instated in 2015. But the city's service request records only include the ward the request is currently in. Using the popular PostGIS PostgreSQL extension, we're able to use the latitude and longitude associated with each service request to geo-locate it within its 2015 ward-to-be and determine if it's in one the 233 areas of the city that are changing from one ward to another. These calculations allow CWFY to compute service delivery information for current and future wards, as well as individual transition areas.

Finally, there's a daily_counts table, populated with counts of service requests opened for each day, ward, and service type combination. This table is populated automatically by a Postgres trigger, and allows CWFY to perform quick aggregate calculations.

The API layer is a collection of HTTP endpoints that generate JSON. Instead of building an API and then building a client, we built the API to explicitly support the needs of the user interface. We would sketch out ideas for how we'd like to present the data, then work backwards from that to determine what endpoints were needed, what data they must expose, and how to format that data. Each endpoint allows for JSONP output, making use by JavaScript applications very simple. The API sits behind a Varnish cache server, significantly reducing the load on the database during periods of high traffic.

The user-facing application is powered by HTML and AngularJS. We use the Jekyll static site tool to automatically generate pages for each ward and service type, and to manage packaging the SCSS and Javascript assets. AngularJS is a powerful framework for building API-backed JavaScript applications. Angular manages all of the communication between the front-end and the API.

The site is hosted in a Amazon Web Service S3 bucket, making it very inexpensive to host, highly available, and simple to update.

We relied heavily on third-party libraries to speed our development. We acknowledge the following and offer our thanks:

  • Leaflet, Cloudmade, and OpenStreetMap: powering our beautiful maps
  • Gorilla: Golang tools
  • SCSS: the only way to write CSS
  • PostgreSQL and PostGIS: simple data munging
  • lib/pq: Golang + PostgreSQL
  • CapistranoRb: simple deployments
  • Jekyll: smart static-site creation
  • Jim Pravetz: Jekyll page generator
  • AngularJS: easy dynamic webapps
  • Bootstrap: simple grid framework
  • Highcharts: beautiful charts and graphs
  • Underscore: better Javascript
Next →