Does gun ownership (A) increase violence or (B) deter violence? C: none of the above.

In the wake of a terrible tragedy, talks about gun control are at the forefront of today's political stage. Of course, both advocates and opponents of gun control point to the Connecticut shooting as a validation of their own viewpoint. It's unfortunate that occurrences like this only seem to polarize us further. We can't rely on anecdotes or emotion to solve this problem. So, what does the data say?

Using data from the Guardian on gun ownership by country, I evaluated the hypothesis that higher rates of gun ownership either (A) lead to increased gun violence (as believed by the left) or (B) actually work to deter gun violence (as believed by the right.) Note that without an experimental manipulation (which is difficult to do due to the many factors that would need to be controlled for, not to mention very questionable ethics), we can identify correlations but it's difficult to really say anything about causation.

First, I compared the total number of civilian-owned guns in each country to the total number of gun-related homicides. The results, unsurprisingly, show a strong positive correlation, most of which can be explained by population: more populous nations will tend to have more homicides and more guns. (In these figures, the size of each data point indicates population.)

To control for population, I compared the rate of gun ownership (per 100 people) to the rate of gun-related homicides (per 100,000 people) and the results were surprising. There's a weak positive relationship between the rate of firearm ownership and the rate of firearm-related homicide (p=0.25), which doesn't strongly support either side's claims:

I suspect that there are other cultural, political, and socioeconomic factors that far outweigh gun ownership as predictors of gun violence, and that both sides in this debate potentially have valid points. In some situations, the presence of guns may deter violent crime. In others, it may enable violent crime.

We can all agree on one thing: we want there to be less mass shootings in America. When considering what policy changes will move us toward that goal, it is absolutely essential that we rely on evidence instead of either emotions or anecdotes.

Additionally, since "guns don't kill people (people with guns kill people)", maybe gun control is less important to curing the modern epidemic of mass-shootings than improving access to and understanding of mental healthcare.


The data and code I used to produce these figures is available on GitHub, and you're free to use them however you like. Feedback is welcome.

Edit: Someone did some additional analysis, uncovering a couple interesting correlates of overall homicide rates (including those unrelated to guns): GDP and income inequality. See it on Reddit.

Hour challenge 12/7: zot, a command-line Zotero client

The last hour challenge was fun, but it was also a dismal failure - honestly, I had been envisioning nanote for a long time prior to developing it, and an hour was just not enough time to build in all the functionality I wanted. I've started using nanote in place of nano and have continued to build in additional functionality, and will probably continue to do so for a while. End result: I now understand how to write a program with the curses library, and my notes are much more organized than they were a week ago.

I use Zotero all the time to manage papers and books. Today I'll be developing a command line interface to Zotero. (There's not already one of these? Really?)

I'll be using the pygnotero library to interface with Zotero. To avoid the GPL, I'm not going to use pygnotero - instead, I'll just interface directly with Zotero's sqlite database. And, for fun, I'll use SQLAlchemy, which I've never used and should really learn more about. I want my client to be able to search (by author, title, citation, tags, etc.), add notes to papers, and output bibliographies (and potentially the text from PDF articles using pdfminer? I'm going to keep thinking about this.) It'll be called zot - short, memorable names for command line tools are always a good thing. I'm going to design it to pipe output to itself, i.e. "zot search ecoinformatics | zot bibliography" to generate a bibliography for all articles on ecoinformatics.

I'll begin sketching out planned functionality while I eat lunch at 12:00 (eastern time), start coding at 1:00 and hope to be finished no later than 2:00. Code will be available at https://github.com/hourchallenge/zot. The final result will be available on the Python Package Index as soon as it's relatively functional.

Update (2:00): my command line client can currently search for articles by title, author, or publication. I'm going to go for another hour to see if I can finish up.

Update (3:00): after two hours, I'm calling this finished. To try it out:

    pip install zot
    zot path /path/to/your/Zotero/directory/
    zot search --author Brown | zot bib

Hour challenge 11/30: nanote, a terminal note-taking app

I'm fairly stone age when it comes to productivity software - I keep track of notes, my calendar, etc. in plain text files on Dropbox and edit them with nano (yes, I use nano and sometimes gedit.) I've decided there's no excuse for this anymore, so I'm going to spend some time developing (open source) productivity tools that I can use from the terminal that are a bit more sophisticated.

Of course, I want to get something out of this, and I don't want to sink a lot of time into development. So, I'm starting a weekly "hour challenge." Every Friday afternoon, I'll be setting aside an hour to develop a specific terminal-based productivity app, and releasing the source on Github. I'll report on my progress here.

I was originally going to develop a terminal interface to Google calendar today, but I discovered gcalcli which fits my needs perfectly and there's no need to reinvent that wheel. So, this afternoon, I'll be developing a terminal-based note-taking system similar to Tomboy notes. I used to use Tomboy, but it frequently caused problems syncing with Dropbox and I constantly lost work, and it uses XML which makes trying to restore after conflicts prohibitive. My notes will use a simple markdown-based text format and allow easy linking to other notes and hierarchical note organization using directories. I'm going to borrow functionality from Nano and call my app "nanote." I'll be learning how to interact with the ncurses library in Python.

The rules: I'm allowed to look into what libraries to use, plan, etc. for one hour prior to starting to code. I won't actually start coding until exactly 1:00 PM, and at 2:00 it's pencils up. Obviously, I'll probably keep coding for a little bit after the fact, but at the end of the hour I want to have a bare bones, functional tool.

I've created an hourchallenge Github organization for storing these projects, so drop me a line if you want to participate! Suggestions for future tools are also welcome.

Shortly after 2:00, I'll update this post with the results and a link to the repository.

Update (2:00): I didn't make it, partially due to not enough planning/familiarity with ncurses and partially due to suddenly being offered free pizza. I'm giving myself another hour! I can definitely finish this off by 3:00.

The code so far is live at https://github.com/hourchallenge/nanote

Update (3:00): I got close! It's more or less functional: you can edit text, save, and link to other notes. I'll probably end up spending another couple hours filling out the missing functionality. Hey, I think this is pretty good for a two hour development sprint.

Update (12/1): after 24 hours, it does just about everything I wanted it to, and supports Markdown formatting. Mission accomplished!

So, in summary, I utterly failed to develop something in an hour (and maybe this project was too ambitious for an hour coding sprint) but I'm still pleased with what I was able to do. Tune in next week when I take another crack at it.

If you have an idea for a tool that you'd like to see developed, or want to develop a tool in an hour yourself, let me know!

nanote is now available on the Python Package Index, so "pip install nanote && nanote" should get it running.

Gordon Research Conference: Metabolic Basis of Ecology, 2012

Just finishing up a great week long conference in Biddeford, ME. Here's the poster I presented (full-size image here):

Our school, and Utah in general, were very well represented, with three students, a postdoc and two faculty members attending from our lab. Here's Dan McGlinn (postdoc)'s poster on testing MaxEnt spatial patterns (PDF), and here's Ethan's talk on testing other aspects of MaxEnt.

The GRC was excellent, and while we're not allowed to talk about specific talks due to Gordon's "off-the-record" policy (which we all waived for our own work), I highly encourage anyone interested in metabolism to attend. Talks varied from exploring mechanisms to large-scale patterns. It's really not just for ecologists. There's content that would appeal to evolutionary biologists, physiologists, environmental scientists, and even anthropologists or biomedical researchers.

Thanks to Ethan and Morgan for the advice and funding that enabled me to make it out here. I learned a lot, met some cool people, and got some great ideas to apply to my own research.

New Scientific Programming Blog

This is my personal blog where I post on a wide range of topics. I've decided to make a second blog devoted specifically to the concept of scientific programming. You can find it at http://www.sciprogblog.com. I'll be posting various tips and tricks for scientists and other professionals who haven't been formally trained as programmers but find themselves programming out of necessity and want to learn more.

Open data needs to be accessible

I'm trying to acquire two very different datasets in completely different fields right now: infectious disease incidence data from the CDC Morbidity and Mortality World Report, and CMIP5 global climate models. They both illustrate a simple truth: making data public is just the first step. If no one can access it in a reasonable way, it's essentially just as closed as if you were to not provide any kind of access.

The Morbidity and Mortality World Report (MMWR) is available from the CDC's website via a web interface: choose a year (1996-2011) and week number (1-53) from lists, press submit, choose a table number (there are 10-12 tables per week per year), press submit, and you're presented with an HTML table containing data for a subset of the notifiable diseases. Okay, CDC, now suppose I'm interested in large scale patterns: I want to download data for all diseases for a five year period. This is going to involve hitting "submit" 6,360 times (5 * 53 * 12 * 2). Sure, I could write a script to do it automatically, but the output is a bunch of HTML tables, each of which has a slightly different format making it difficult to "scrape" out the data.

(After toying with the idea of trying to build a scraper, I made contact with the CDC back in June to try to acquire the raw data behind the online tables. I thought this would be faster. I was mistaken. I've had a few responses, but I'm still waiting for the actual data.)

But, believe it or not, the CMIP5 data is far worse. CMIP5 stands for Coupled Model Intercomparison Project - intercomparison! To me, the word "intercomparison" suggests that data for multiple models should be easy to download simultaneously. Not so. Again, a web interface stands in your way, only this time it uses asynchronous JavaScript to build each page so you can't just go to a specific URL to get your data. You have to narrow things down by clicking on a Model, then an Experiment, then a Frequency (monthly, yearly, etc.), then a Realm (land, atmosphere, ocean), and finally a variable. At this point a list of models will be provided, with only ten results per page. You have to check a box for each dataset you want (at this point I typically want all of them), press "download all," download the WGET script they provide (seriously?) and run it.

I've started writing an automated tool to do this for me using spynner, an automatic browsing module for Python that understands JavaScript. The tools is about 500 lines of code so far and climbing. The process is like this: log in to the website, click on a model, wait ~10 seconds for the JavaScript to run, check which experiments are available on the page, open a new copy of the browser window (so I don't have to retrace my steps after each download), click the first experiment, wait 10 seconds... To give you an idea of how obnoxious this is, for their research, the Utah Climate Center wants data from: 18 models, 54 experiments, 6 frequencies, 4 realms, and 31 variables. This amounts to many terabytes of actual data, and many, many iterations of "click a link and wait ~10 seconds." Once this tool is finished, it will need to run on a server for hours, probably days, to download everything.

It's great that we've seen such an explosion of publicly available data, but one of the key words there is available. For some very important datasets, in terms of availability, we still have a long way to go.

Developing Android apps: it's really not so bad!

There's been some talk recently about how Android development can be difficult for newcomers to jump into (for one, this rant on Hacker News, claiming that you'll need "months researching Android design patterns"; the top rated response is mine.) I thought I'd elaborate and show my roughly two week journey from deciding "hey, I'd like to try building an app some time" to releasing a full blown (albeit somewhat simple) Android app to the market. I plan on following up with more stats in a week's time to show how I'm doing with revenues, downloads, etc.

Background

I'm no stranger to programming. I taught myself how to program in QBasic in 1995 (when I was 7) on a little computer running Windows 3.1 (although I worked solely from DOS.) I made dozens of little QBasic games. Had I been born 10-15 years earlier I could've had a great career making crappy looking, low-res games.

One game that I started and never finished back in the QBasic days was my version of Archon II: Adept. Disclaimer: I never actually played Archon II, I just saw it in an old magazine once and thought the idea of summoning creatures onto a chess-like board and having them duke it out seemed pretty cool. I'm not sure if that's really what Archon II is like, but I had no money and an active imagination.

I got my first Android device, an enTourage Pocket eDGe, on July 7th, exactly 1 month ago. (I can't recommend the device enough, but unfortunately enTourage has gone out of business.) After a few weeks, I decided to try my hand at developing my own Android app. For my first Android project, I thought it would be fun to take another shot at finishing the "Archon II" concept so I could play it on my Edge.

I'd never programmed in Java before, although I have some experience with C# so the syntax isn't completely foreign.

Something that I really believe helped me get started smoothly was, frankly, my attitude. I don't waste time hating on Java, even though it's the cool thing to do. Java is what it is, it's very much ubiquitous right now, and it's just not productive to complain about it. Every language has shortcomings; Java is the standard language for Android development, so it's what I used. Also, when I first got started I hadn't yet read the plethora of blog posts about how terrible Android development is and how little money its developers make. I enjoyed the development process and, while it remains to be seen how my app will perform, I'm optimistic.

Getting Started

A simple Google search yielded some great tutorials that showed me how to get started with the Android SDK on Ubuntu. The whole process, downloading the SDK and Eclipse plugin and getting everything set up, took roughly 10 minutes, after which I grabbed a Hello World tutorial and was beyond excited when I got a custom text message to appear on my eDGe. It had begun.

I quickly became familiar with the Android development ecosystem: drawables, XML layouts, etc. I loved the fact that I drop an image into my drawable folder and refer to it by name or store it as an integer field in a class; with an XML drawable I could specify which image to use for a button by default and which to use when it was pressed. XML layouts were also a great alternative to programmatic layouts. Settings could easily be stored in preference files and retrieved by name, eliminating the need to create my own settings file read/write system. (At this point I really can't give enough props to Reddit user Lorc for his extremely high quality set of game images that have been made freely available. With a little coloring they look magnificent on a mobile device.)

Another great thing about Android development: for just about anything you might need to do (everything I needed to do, anyway), there's a helpful tutorial by someone who's done it before, and it's only a quick Google search away.

One hurdle I ran into: testing my app on the Android emulator. While convenient to test different display sizes, the emulator is painfully slow and took upwards of 10 minutes to boot up the first time. Not helping was the fact that I do most of my development on a netbook that's not especially powerful. I got around this problem by using my actual device for testing, using USB debugging mode when necessary. Problem solved.

Polish

I was busy full time during the day, but working only nights I was able to put together a working, playable prototype of my game within 4 evenings. (Confession: I stayed up pretty late some of those nights.) That was the easy part - I spent about a week and a half making various improvements and preparing for release.

The main difficulty at this point was the fact that I'd developed solely with the eDGe in mind, and there is a huge array of potential Android devices, each with their own resolution and capabilities. I came up with several ways to address this problem: using different layouts for different size devices, programmatically shrinking/expanding the size of the board and side bars, and including different sized boards for screens with different aspect ratios in the Settings menu.

I had some family members test the game and made some improvements based on feedback I got and new ideas I had. I made the UI more responsive by making the board extend SurfaceView instead of View, resulting in smoother animations. I simplified the controls, added trophies, and implemented a simple tutorial system that would give helpful messages the first time the user did certain things. I tried to keep things simple and intuitive to appeal to mainstream Android users.

I implemented an enemy AI that's pretty basic but still manages to beat me regularly. It looks at its potential moves, evaluates the condition of the board after making each move, and decides which is best based on things like proximity to allies/enemies and relative strengths and weaknesses.

Marketing and Release

A few days ago I committed on a Sunday evening release date, as I could keep polishing the app for years without releasing if I didn't make a firm decision. I reasoned that weekend evenings would probably see lots of users checking the market. I decided to release under the pseudonym "MonsterFace Games." "Monster face" refers to the face our cat makes when she's scolded, a kind of half-scowl that just barely shows teeth.

On Friday I started letting friends know that it was coming, posting to Facebook and Twitter. Saturday I learned how to integrate Google Analytics and AdMob into the game to serve ads on the free version and track statistics like what creatures and elements were most popular, what trophies were earned, and how often players won or lost.

One more unexpected speed bump - my release was about 3 hours later than I had hoped because I ran into problems putting up a free and paid version of the same app on the Android market - something that could've been a little more clear. But it's official, two weeks from concept to release of a full Android game with minimal dififculties. Stay tuned for updates on how Summoner performs during its first week.

Links

Summoner Lite - web, mobile

Summoner - web, mobile

Follow MonsterFace Games on Twitter: @monsterfacegame