A Little Mapping Project

Quote

knot

“Computer scientists, neuroscientists and nanoscientists concluded that it would require three petabytes of storage capacity to capture the amount of information generated by just one million neurons in a year.

There are one million gigabytes in a petabyte. The Large Hadron Collider in Geneva generates about 10 petabytes of data annually. If the brain contains between 85 and 100 billion neurons, that means that the complete brain generates about 300,000 petabytes of data each year.”

- The NY Times, Feb. 25th 2013, on Obama’s project to map the human brain.

A Ruby/Rails learning list + some extra

aboardrails

Since starting to learn how to code (about a year ago now), I’ve been meaning to put together a list of the really helpful links and resources I came across along the way. Sometimes it was a tutorial video that finally cleared up some long-standing befuddlement, or a random snippet of code that made the damn thing work after 3 hours of head-banging, or some really good explanation I wish I had read weeks earlier. Here’s a jumble of all those things. Most are Ruby and Rails related, with some JavaScript, Git, and other stuff thrown in for good measure.

••• RUBY/RAILS •••

Peepcode: Meet Rails 3 Part 1 and Part 2
Awesome introductory videos that are also very convenient – you can download them right onto your phone and watch them on the subway (if that’s your thing). Super comprehensive, might wanna watch them a couple times to get everything.

Rails Course from the University of Texas
A complete set of videos from a Rails online class from a prof at UT, a bit slower-paced and more detailed than the Peepcode lectures.

Rails Guides
Best resource for both getting an introduction to different components (like routes or active record, etc) and also something to look back on every time you forget the correct syntax.

Bastards Book of Ruby
For getting how Ruby works, from Dan Nguyen.

Ruby on Rails Tutorial
Super detailed, super comprehensive, online book that walks you through the entire process from install to deploy.

Rails Casts
Tips and tricks, how-to’s for solving specific problems, and introductory “tours” of Rails techniques.

Rails for Zombies
Actually a somewhat entertaining way to get the basics of Rails down in a real “lesson” format (complete with quizzes and exercises and many zombie-references).

Ruby Programming Language official page
Screencasts from the Rails official page
Programming Ruby: The Pragmatic Programmer’s Guide
Learn Ruby with the Neo Ruby Koans
Learn to Program (ruby)
Rails API
Ruby Tutorial
Rake
Loops
Helpers
Link_to and css classes
Case Statements in Ruby
Strftime
Indexes in Rails

••• OTHER •••

Javascript
Eloquent JavaScript: A Modern Introduction to Programming
Peepcode: Meet jQuery
Codecademy: JavaScript
JavaScript: The Good Parts

Command Line
Meet the Command Line
Zed Shaw’s The Command Line Crash Course

Sinatra
Rapid Prototyping with Sinatra

Git
Get Started with Git
Pro Git Book

CSS
Shapes of CSS
The 30 CSS Selectors you Must Memorize
CSS Curly Quotes
Pure CSS GUI Icons
CSS Nth Child Tester
Pseudo Class Selectors

Colors
Color Oracle
Color Brewer
0to255
CSS Color Gradient Tool

Regex
Ruby regular expression editor
Regular Expressions
Learn Regex The Hard Way

Sublime Text
Sublime Text Tips and Tricks

Vim
Using the Vim Editor

Markdown
Markdown Basics

Diagrams and Foreign Languages

Quote

For an image to be useful, the relevant or key results should be immediately obvious, so that the viewer need not spend a great deal of time first trying to understand what might be important. Diagrams can themselves be complex, requiring some time of study before they’re understood, but the basic idea being expressed needs to be immediately apparent. It is similar to hearing someone speak in a foreign language, where even if it’s not possible to understand the language (the specifics of the diagram) it’s generally possible to tell whether they’re angry or happy (what parts of the diagram are relevant and require further inspection).

– Ben Fry, Dissertation: Computational Information Design, 2004

Pop Experiments

I drink a lot of soda. Maybe not as much as this woman (let it be a warning!!), but still, Diet Mountain Dew is a substantial part of my daily liquid intake. So of course I was intrigued when I ran across this dataset on soda consumption since the 1950′s (it actually inclues all beverages, but one track mind here). I decided to make an interactive chart out of this very significant information. I had just learned how to use FasterCSV and a little Ruby to turn a .csv file into a bar graph, so I used the same approach. Basically I ended up creating a bunch of little divs, their heights calculated as percentages of the total height of the container div. Also learned about jQuery .prepend method, which let me attach labels – the gallons of soda per person – to each bar. Here it is! 

Hey girl, it’s data

So last week at Science Online 2012, the amazing Ruth Spencer and I rambled a bit about data journalism. The main product – still evolving – is this tumblr blog, which is our attempt to gather our thoughts and lots of resources for people interested in getting started in collecting, interrogating and visualizing data. It could have been called “Everything I know about data journalism I learned from ProPublica and the NY Times.” But we decided to call it Speed Data-ing. Yes, it took us many iterations to come up with that one.

This was one alternate title:

But this was the REAL winner, which came to us via science writer extraordinaire Ed Yong a little too late to use it this year. We are assured that’s it’s gonna be an option for #scio13.

Experiments with Google Fusion Tables

To prep for our talk on data journalism at the Science Online conference coming up next week (!!), I figured it’d be good to actually review mapping some data with Google Fusion Tables. I chose a dataset released this October from the CDC on suicide from 2008-2009. Morbid, I know, but it’s is the first time this specific state-level data has been reported, and I wanted to actually visualize the differences between states rather than stare at numbers in a table.

The numbers originally came in a PDF that looked like this:

After thinking for a little while that I’d have to do something ninja-like to get them out of the PDF, I just selected all the numbers in the “Attempts” % column, and pasted them into a Google Spreadsheet. Not bad.

Then I switched over to Google Fusion Tables, and created a new table by importing that very simple Google Spreadsheet. Merging that with the pubic KML file for US states gave me this:

Next was going to Visualize > Map, fiddling around with Configure Styles and adjusting the HTML in the Configure info window to show just the state name and percentage.

Hardly beautiful (and I gotta work out much more coherent step-by-step instructions) but here it is:

Suicide Attempts by State (in % of population)

Now the REAL story here, which the map indicates but does not explain, is why Rhode Island in particular has such a high percentage of suicide attempts. The CDC report offers some speculation, but no definitive answers:

Several theories have been advanced that attempt to explain these regional differences. These theories attribute the differences to selective migration (i.e., populations with risk factors for suicidal behavior might migrate to the same geographic areas), to the sociodemographic composition of the population (i.e., certain regions have a greater percentage of persons who are members of sociodemographic groups that are at greater risk for suicidal behavior), or to the local social environment (e.g., unemployment levels, divorce rates, social support, or environmental factors such as increased access to lethal means). Such variations might point to areas of emphasis for planning and evaluation of prevention activities.

 

To be continued, then.

Which half? (on the importance of controls)

Quote

One day when I was a junior medical student, a very important Boston surgeon visited the school and delivered a great treatise on a large number of patients who had undergone successful operations for vascular reconstruction. At the end of the lecture, a young student at the back of the room timidly asked, “Do you have any controls?” Well, the great surgeon drew himself up to his full height, hit the desk, and said, “Do you mean did I not operate on half the patients?” The hall grew very quiet then. The voice at the back of the room very hesitantly replied, “Yes, that’s what I had in mind.” Then the visitor’s fist really came down as he thundered, “Of course not. That would have doomed half of them to their death.” God, it was quiet then, and one could scarcely hear the small voice ask, “Which half?”

—Dr. E. E. Peacock, Jr., University of Arizona College of Medicine; Medical World News (September 1, 1972), p. 45, as quoted in Tufte’s Data Analysis for Politics and Policy

Should I get a bone scan? The flow chart

I don’t love flowcharts. Most of the ones I’ve seen are totally useless or just silly. But I think the simple form of a flowchart can actually be pretty useful for explaining a complicated subject (that is, when that subject isn’t beyond all hope). This one on campaign finance, for example, is easy to follow and packs in a decent amount of info into a relatively small space.

Here’s one I did for a health reporting class on bone scans (and whether or not you need one). The current recommendations are tucked away in obscure reports, and according to the doctors I talked to, many people who should be getting bone scans aren’t. The chart’s not great, but it’s one attempt to lay out the information. Just for fun, I made it in the style of a typical Wired flowchart.

Here’s the bigger version.

 

When design goes bad

A long time ago I read a book that changed how I looked at, well, basically everything. That book was The Design of Everyday Things by Donald Norman. It’s packed with examples of bad (and some good) design – everything from objects to software to architecture. The basic idea is that the user has different interests than the designer, and when they come into conflict, you end up with unusable products and lots of errors.

Take the door. Seems simple enough. But how many times have you pushed a door when you needed to pull it open, tried to turn a door knob when you needed to slide it, or just plain walked into a glass door you didn’t see (ok, fine, that was me).  I’ll always remember one line from the book, which went something like: “When something as simple as a door has to come with an instruction manual – even a one-word manual – then it has failed.”

Along those lines, my latest rant about poor product design is over at Scientific American. This time, it’s about the hazards of the instant soup cup. The soup cup might not be quite as bad as the Coffeepot for Masochists on the cover of Norman’s book, but it certainly comes close.

IMAGE CREDIT