Month: November 2014

I’m doing a little cleaning in the icanhaz code repository.  One of the things I’m throwing out is the code to connect different machines to the Skype API (below):

import os
import Skype4Py
if os.name == "nt":
    print("Windows")
    #32 bit and 64 bit windows behave differently with Skype
    if 'PROGRAMFILES(X85)' in os.environ:
        sconn = Skype4Py.Skype() #64-bit
    else:
        sconn = Skype4Py.Skype() #32-bit
elif os.name == "os2":
    print("Mac")
    sconn = Skype4Py.Skype()
else:
    print("Linux machine or similar")
    sconn = Skype4Py.Skype(Transport='x11')
#Now go do the usual Skype API things.

I’m leaving the code here because

1. I sometimes need to write code that works differently on different machine types (here’s a more detailed discussion about that), and
2. One day Skype might recant their somewhat strange decision to shut down their API to more than a handful of developers.

What Skype’s API decision means in practice is that anyone wanting to search a Skypechat for an interesting set of words, or scrape urls out of it, or even know who made which comments when, has to now do that with cut-and-paste and hoping that people don’t change their nicknames halfway through a chat, instead of automating those processes.  Which when you’re halfway through a sudden onset disaster can be a bit of a pain.

If you want to know about a physical environment, use sensors.  Take pictures, take air quality readings, take water quality readings, detect radiation levels, use strain gauges,  listen to and analyse noise and the signals in it.  Smell, measure, touch (If it’s not dangerous to do so) what’s around you.  Find people who can teach you how to analyse what you see: imagery interpreters, naturalists and earth scientists for those pictures, acoustics experts, ornithologists and whale experts (as appropriate) for the noises.  You’ll learn a lot, and maybe question a lot too, like why some places have higher radiation readings than others, but at some point you’ll realize that the data you have available is limited by the number of sensors you can use or place by yourself.

Which is where crowds come in.  If you want to understand how the environment changes over time, or how the environment differs over a wide area, you’ll either have to dedicate a lot of time to placing sensors, or work out how to involve other people and organisations in your data gathering.

Journalists are used to crowdsourcing now.   In truth, they’ve been used to it for perhaps longer than even they know: my investigations into the roots of sensor journalism found Francis Galton crowdsourcing weather observations in 1870, and earlier than that, groups of amateurs collecting readings for the Central England Temperature series from 1659 to the present day.  Skip forward hundreds of years, and it’s not unusual for a data journalist to crowdsourced open data, or the Mechanical Turk crowdsourcing site to sift through documents and data.

But how do we ask a crowd of people to place sensors for us? How do we find them?  How do we equip and train them? What are our legal responsibilities when we’re asking them to do physical tasks in the outside environment?  How do we guarantee that the data we get back will be good – or at least, of a known and consistent quality? 

Oh grief, I’ve had posts stuck in my blogs list for a year now, but here’s one that I wrote last year, as part of a campaign to get more non-academics to speak at crisismapping conferences.

An ignite talk is 5 minutes’ talk with 20 slides that change automatically every 15 seconds.  Giving ignite talks is a skill, and one that can be learnt.  With the ICCM ignite deadline coming up soon, OpenCrisis thought that a) an ICCMxVirtual event for people who can’t travel to Nairobi would be good, and b) non-academic mappers could do with some help creating ignite talks. We’re talking about training sessions, but in the meantime, here’s what works for me.

• Start with a story. Mappers have great stories, but they’re often too modest (“who, me?”) or too scared of presenting to tell them.  Here are some stories that could be told from a mapper’s perspective, to help other groups understand us: a deployment you enjoyed, and why; a technology you’d really like built (and why), good…
• Sketch out the story. I do this literally, with a piece of paper and pen, or with a set of slide headings.
• Start finding and making images that relate to the story.  Use a screen-grabber. Look at your maps, your data, your messages, your links, your notes (being careful not to disclose any sensitive data, of course).
• Start writing paragraphs to match the images.  Some images will take more than 15 seconds – that’s okay, because you can either repeat the image, zoom into the relevant part of it, or …
• At this point, you’ll realize that things need to be tweaked.  That’s okay. That’s supposed to happen.  If you try to write something perfect first time, you’ll fail (NB I edited this blogpost several times).  But if you get the basic framework together and start getting materials, your story will start to emerge. Encourage it!
• Start talking… read your paragraphs out aloud… make a recording of it (you can do this from powerpoint, which can also advance your slides for you!), and listen to yourself speak (if you’re shy, video is a no-no: it’s terrible watching yourself, but not so bad to listen).  Edit again.
• Keep talking… find someone to practice on, who’ll make notes as you talk.  Ask them what the 3 biggest messages they got from your talk were.  Ask them what the 3 biggest messages should have been.  Rewrite your paragraphs to emphasis these; it’s okay to use silence in an ignite talk, and using it around a big message can be a very powerful thing to do.
• Now you have a talk.  Practice it… and as you practice, start highlighting the key points in your text (I use bold font for this).  If you’re nervous like me, having those key points in a paper in your hand can make all the difference between freezing up completely, and having a way to restart your talk so nobody notices.
• Finally… the talk.  Get out there, tell that story, and most of all remember that this isn’t a judgement of your message or your style – it’s a conversation between you and the audience that you get 5 uninterrupted minutes to start.  Then take a deep breath and go continue that conversation – in person, online, wherever your audience takes you.

I was watching aerial practice recently – it’s something I’ve always wanted to try, but… I’m clumsy, I’m scared of heights, I’m… but so are some of the beginners there too.  Clumsy isn’t the point, nor is getting your legs in the right place first time.  What counts here is that you keep trying, and if you need to, you make it a little easier until you get it (e.g. using a trapeze rather than the silks until the legs go the right way).

This doesn’t just apply to circuses. Some of the best volunteers, deployments and systems that I know started out awkward and clumsy, but kept trying, adapted to where their skills were, and kept trying ‘til they got good.  The circus school has incredible teachers who know when to ask for more, and when to walk over to the trapeze. We have great teachers in the crisis data space too – now we need to distil their knowledge, to best get skills and lessons to all the individuals, deployments and systems that we’re fostering.  That’s why we created OpenCrisis, and why it continues to support other efforts to teach.

I’m heartened that at ICCM 2014, some of our shyest but most knowledgable mappers stood up and talked about what they know, what they’re passionate about – people like Leesa who knows more about virtual PTSD than anyone else I know, and Hilary talking about how to manage gender issues in map creation. But more of you have amazing experience and know so much… please, please, get out there and teach others about it, give them the chance to learn from you too.

I’m teaching a coding course this autumn, and looking for materials to help explain to non-coders that whilst programming can be magical, it really isn’t magic.

I’ve chosen Ruby on Rails for the course because I want people to win at getting something working and fast.   One of the great resources I’ve found is “the Bastards Book of Ruby” http://ruby.bastardsbook.com/about/, whose “about” section I’d encourage every aspiring non-programmer to read.  Especially this quote: “if you had spent that hour just copying-and-pasting, dragging, clicking, redoing the times that you didn’t properly drag-and-click, you’ve only gotten better at…just copying-and-pasting.”

Coding isn’t magic. Most of data science isn’t magic. But they do both need practice and determination to become natural to you.  Not everyone needs their code or science to be magical; if you don’t, then an hour or a day’s training will set you on your way. But if you do, put in the time and do as much practice as you can: it’s worth it.