Tipa.li – a Tool for Easily Finding Polio Vaccination Clinics

No one is sure what caused the Polio virus, eradicated from Israel since the1990s, to reappear. The virus was detected in sewage samples in the south of the country in early summer and began spreading northwards, prompting Ministry of Health to start a massive vaccination drive.

Parents of children under the age of 9 were asked to bring them to the nearest Tipat Halav clinic for vaccination. Country-run Tipat Halav (in Hebrew, “drop of milk”) childcare clinics are a household name in Israel. Spread throughout the country, they helped it reach some of the world’s lowest infant mortality rates.

The Ministry of Health decided to create a mobile application to help parents find the nearest clinic. It commissioned one of the country’s largest development shops to create it. They decided to create a native app. This is the Android version:

It’s in Hebrew, but you get the idea

I assume the iOS version is still undergoing the App Store approval process.

We discussed the app during lunch at Gizra. We’re no doctors, but we thought we could do something about the software. Going with a native app didn’t seem ideal for a single-use application which needs to be deployed on as many platforms ASAP. As for the UI, I’ll leave the image above as an exercise to the reader.

Lunch concluded with a particularly good Malabi. It’s one of the few deserts I ever bother with, so I’m pretty sure the extra sugar is the reason I shot off a message to the Public Knowledge Workshop mailing list as I got back to my laptop, asking who’s with me – help me scrape the clinic data and I’ll take care of the front end.

Malabi, by naamanus. Best desert ever.

Malabi, by naamanus. This is good.

Within a few hours, a person I’ve never met sent me a link to a JSON file with all the clinics. I still have no idea who this is and how s/he had this file. I geo-encoded a few, put the data on map using GitHub’s geoJSON support, and sent a link back to the mailing list. At 1am that night, Alon Nisser (whom I’ve also never met before) sent some patches that fixed the major missing parts in my code.

By morning we had a working prototype. Meanwhile, Udi Oron and Erez Segall – yet another two people I’ve never met – announced they were working on a more robust scraping code to get all the data from the MoH’s website and encode it reliably.

With the data in Alon, Udi and Erez’s capable hands, I focused on the front end with the goal of keeping it server-free – only HTML/JS code – thus allowing us to develop a quick, simple solution that’s easy to deploy and scale.

The final app is extremely simple. When opening tipa.li (Hebrew wordplay meaning “My drop” or “Tiny drop”) the user is presented with a map, zoomed to the city level and centered on her current location, showing nearby stations. Touching a marker (design donated by Ilan Dray, who I’ve also yet to meet) reveals its street address, opening hours and a phone number.

Tipa.li UI. This is all of it.

Tipa.li UI. This is all of it.

That’s all. No search or distance filtering features to clutter the UI. The user knows better – a more distant station might have better parking, for example. All the stations in the country are the one geoJSON file, so users can find clinics in other locations by just zooming and panning around.

The code is as simple as the UI. The app is one geoJSON file rendered on a MapBox map with the excellent Leaflet.js API. No searching, no AJAX calls to a backend server. Everything is client-side, served from the ultra scalable (and only occasionally down) GitHub Pages.

I’m pretty happy with tipa.li. It’s one of these rare cases where things just work right, from the start – the code, the UI, the development process. The media in Israel liked it too, giving it some nice coverage on Haaretz, Calcalist and some national radio/TV shows, helping us further the cause of opening government data. As for users – within 12 hours of posting the site on Facebook, we’ve passed MapBox’s free quota of 3000 requests. It was a good week.

Around Here, the New GeoCities

I know I’m not the only one who needs a map in Jerusalem:

Old City Map

Problem is, a simple map is not enough here. Some places just really accentuate a dimension. Australia taught us to respect distance, driving our camper all day to cover a mere wrinkle on the map. Manhattan forces you to acknowledge it is 3 dimensional. Jerusalem is impossible to understand if you ignore the dimension of time.

So I made a little app I call “Around Here” which shows wiki articles around my current location:


It’s not a lot of code, but actually pretty useful. I mostly use it on my phone, but it works on laptop, tablet and would work right here too if WordPress would allow embedding JS.

Building it made me think of how much the web has changed in the last couple of years. Have you noticed how much you can do with JavaScript now? All the awesome libraries coming out? Not even node.js, just old fashioned client-side JS.

Programming languages are like musical genres. New ones are created, existing ones change and move in and out of fashion, but every once in a while a specific genre will experiences a sudden explosion of creativity. If JavaScript is Punk rock I guess this is the mid-1970s now.


HTML5 and modern browsers’ capabilities are a major factor, but also some slower moving, deep server side changes:

  1. Continued APIzation of everything  allowed me to write the app using the WikiLocation API instead of my own DB backend. An embeddable service like Disqus enables pure HTML Jekyll blogs to have active comments. If your data is not sensitive you could even use a Google Spreadsheet as your DB.
  2. Decreasing costs of serving HTML/JS/CSS only pages now allow GitHub to let you serve your pages for free, with no restriction on content and almost no scaling limit. Basically you could do that in 1995 with GeoCities – look how much more you can do with just the above client side technologies now.

So, what we used to call “static pages” are now becoming increasingly powerful, and free. There’s an odd back to basics feel as we’re crossing a gap between very low cost to zero cost for serving a useful, highly scalable app. It might turn out a big deal. More importantly, coding is fun again.

KalSMS Growing

It’s been a good first year for KalSMS, which I’m particularly happy about since I didn’t really have much time to work on it myself (nor, evidently, on this blog). It truly took on a life of its own.

In India, Sheldon D’Souza was using it to power a food ordering startup and contributed some polling code to the codebase (it’s still in a separate branch, I really didn’t have much time for non-work stuff).

In Liberia, local activists were using John Etherton’s Ushahidi KalSMS plugin to track conflict indicators and humanitarian needs.

I had the opportunity to give a talk on KalSMS at the inaugural Dar es Salaam GTUG meeting. Allen Machary, one of the engineers I met in Tanzania (an impressively sharp and passionate group, btw), later joined Bienmoyo and ended up using KalSMS for part of a mobile pregnancy care program he was working on. Here’s a photo I got from Lushen Wu, Allen’s colleague, of a training session in Tanzania.

KalSMS is not pictured, but is somewhere around here

I’ve been hearing from people interested in putting it to various other uses: cross-network SMS service in Poland, salsa club promotion in LA, activists communications in Northern Africa, marketing for a fashion boutique in Finland and so on. Who knows how many of these got built, and how many others I never heard of.

All that has been a pleasant surprise, since about a month after I released KalSMS Ushahidi project launched SMSsync, which has similar goals and obviously much more resources behind it. With my rapidly shrinking spare time and negligible Java skills, I assumed KalSMS was done for. But people still seemed to find a use for it, and improve it.

I was particularly happy to get an email recently from Jesse Young of Envaya, who have taken the codebase and added a LOT of functionality. Envaya’s version is now out as EnvayaSMS, the history page lists the major features they added.

If you’re looking for new features, EnvayaSMS is your best bet. I’m still going to keep KalSMS up, with minimal maintenance, in the same place, and it’s also out on the Amazon Appstore now for easier download. There may be a place for having a minimal feature and the super-simple UI it enables.

When I get some free time, I might integrate some of EnvayaSMS new features down to KalSMS, keeping the UI minimal. If Python/Ruby/etc on Android ever become viable I’d be happy to rewrite the whole thing in a language that doesn’t feel like it was designed by a committee of lawyers.

It’s been a fun ride so far. It’s a great feeling to see my code gets picked up and used all around the world, and have much better programmers than myself take it places I never thought it’ll get. Thanks everyone. Keep KalSMSing.


KalSMS is a small Android based SMS gateway I’ve released as open source. “Kal” is a Hebrew word meaning “lightweight” and “easy”, so it fits KalSMS’ primary goal of being very easy to install, maintain and work with.

KalSMS is a very thin layer between SMS to HTTP and back to SMS. For example, a simple SMS weather service works like this:

  1. A user sends an SMS “weather 10026” to a phone running KalSMS
  2. KalSMS intercepts the SMS message, and sends it to pre defined URL. In this case http://qkhack.appspot.com/weather?msg=weather+10026
  3. In this URL, a script uses Yahoo!Weather API to get the weather forecast for zip code 10025, and formats an XML response like:
        Fair 37F today, Mostly Clear 34F tomorrow, Partly Cloudy 37F Friday
  4. KalSMS parses the response, and sends an SMS back to the user with the weather forecast.

In effect the phone running KalSMS has now become an SMS server, running a weather application.

I’ve been working recently on applications that are meant to be used in places like India and Africa. This taught me that (a) SMS is accessible by a LOT more people worldwide than the web, and (b) it is MUCH harder to build an SMS app than a web app.

KalSMS tries to help this by leaving the heavy lifting to a web app, and just providing a simple, as thin as possible layer between SMS to the Web and back again. This means developers can work with the tools they already know, use state of art technologies like Heroku or App Engine that make launching a web app extremely simple and cheap, and just use an Android phone to enable the SMS part.

Current solutions require either collaboration from a local cellular provider, often a challenge for low budget projects, or setting up your own server – that is, an actual computer running the SMS gateway software connected to a cellular modem. This is non-trivial to install and maintain, and since the solutions out there are tightly coupled you have to write your actual application in a specific language or framework dictated by the SMS solution.

By being Android-based, KalSMS installation is a matter of scanning a barcode, maintenance means keeping the phone working – something almost all people in the world now know how to do. Basically an Android phone with KalSMS replaces a computer, network connection, cell modem, a UPS system and whole bunch of software.

I’ve got plenty of opinions on aid efforts and their effects over the years, but in keeping with the unwritten “produce or shut up” motto of this blog I’ll just say I think things will start to improve when more people pay attention to Bill Easterly than Bono. In my corner, I hope hackers will use KalSMS for various projects simply for its simplicity and reliability – and perhaps in time will seep into the developing world projects I had in mind when building it.

MacBook Time Lapse in Make Magazine

I had the the idea to use iSight for time lapse photography during a record setting blizzard in February, now we’ve just been through perhaps the hottest July on NYC’s records and the new volume of Make Magazine carries the print article. Make is one of my favorite publications, which makes me particularly stoked about the whole thing.

Randi & Patrick, thanks for your photos! Unfortunately Make had to pick just one (it’s only a two page piece..) I really appreciate both your help!

TheRealURL Chrome Extension

Lately I’ve been using Chrome quite a bit, and liking it a lot, which is why I was particularly excited to get a note from Don Magee at Tactical Coder saying he’s now using TheRealURL to power his Chrome URL Expander extension.

Don has some kind words for TheRealURL, too:

This is done by using the API found at: http://therealurl.appspot.com/. I know this is the second time I have switched backends. This new backend is even faster and supports every single url shortening service I have tried.

Thanks :)

I installed it on my Chrome and it works great. Note that the UI is a bit different from the Firefox extension – rather than displaying the long URL in the status bar, it inserts it in the HTML instead of the short one. So now we got Firefox, Thunderbird and Chrome covered (all, by the way, thanks to the kindness of developers I’ve never met, volunteering their code). If someone wants to do an IE/Safari/Opera extensions, let me know – I’d be happy to help any way I can.

Open Sourcing Crowds Machine

I’ve been way too busy recently to give Crowds Machine much attention, and since it’s such a resource hog I’m frankly not that motivated to improve it – better performance will just mean more users which will lead to higher hosting costs.

So I figure the best thing to do is open source the code, so that people would be able to install their own instance (and hopefully give it some much needed TLC): http://github.com/niryariv/crowds

The code is layers upon layers of Rails, much of it written when Rails (and myself) were young & naive. I updated it from time to time, but it’s not my submission to Beautiful Code. Licensed under Creative Commons Attribution-Share Alike 3.0 Unported – if that’s a problem, let me know and I’ll see what I can do.