I love Noah Veltman’s visualization of the changing height and weight distribution of professional football players. It uses animation to convey the incredible increase in size of the typical football player, and it does so with a minimal amount of chart junk. Let’s look at two aspects that make this effective.
It uses the appropriate visualization
There are 4 variables plotted on the graph – height, weight, density, and time. Two of the variables are encoded in the axes of the chart. The time dimension is controlled by the slider (or by hitting the play button). The density is represented by the color on the chart.
You could present this data as a table of data but it would be much harder to understand the pattern that the animation conveys in a very simple manner – not only are players getting bigger in both terms of height and weight, but the variance is increasing as well.
It makes good use of color
It uses color appropriately, by varying the saturation rather than the hue. I’ve blogged about this topic before when discussing the Wind Map. To repeat my favorite quote about this, Stephen Few states in his PDF “Practical Rules for Using Color in Charts”:
When using color to encode a sequential range of quantitative values, stick with a single hue (or a small set of closely related hues) and vary intensity from pale colors for low values to increasingly darker and brighter colors for high values
I could imagine extending this visualization in a few ways:
- Allow users to view the players that match a given height/weight combination (who exactly are the outliers?)
- Allow restricting the data to a given position (see how quarterbacks’ height/weight are distributed vs those of the offensive line)
- Compare against some other normalized metrics, such as rate of injury. Is there a correlation?
This is a great data visualization because it tells a story and it spurs the imagination towards additional areas of analysis and research.
Martin Chikilian from Toptal rounds up some common mistakes that Python programmers make.
I have made mistake #1 on multiple occasions:
Common Mistake #1: Misusing expressions as defaults for function arguments
Python allows you to specify that a function argument is optional by providing a default value for it. While this is a great feature of the language, it can lead to some confusion when the default value is mutable. For example, consider this Python function definition:
>>> def foo(bar=): # bar is optional and defaults to  if not specified ... bar.append("baz") # but this line could be problematic, as we'll see... ... return bar
A common mistake is to think that the optional argument will be set to the specified default expression each time the function is called without supplying a value for the optional argument. In the above code, for example, one might expect that calling foo() repeatedly (i.e., without specifying a bar argument) would always return ‘baz’, since the assumption would be that each time foo() is called (without a bar argument specified) bar is set to  (i.e., a new empty list).
I don’t remember for sure, but I’ve probably done something like #5, modifying a list while iterating through it.
If you write Python code, the rest of the article is worth a read
Disclaimer – I work for Google but have nothing to do with the self-driving car team. The views expressed here are my own and do not necessarily represent that of my employer.
I found Eric Jaffe’s article on Google’s self-driving car and its handling of city streets immensely fascinating. He describes being a passenger in the self-driving car as it drives around Mountain View, CA (where I’m currently living) with minimal intervention from the Google engineer sitting in the driver’s seat.
It details some of the history of the self-driving car project, from its roots in DARPA’s Grand Challenge, a race through the desert with autonomous vehicles, through driving on the highway, to the vastly more complicated challenge of driving in an urban environment.
The article points out that Mountain View isn’t as crowded or chaotic as a city like New York or San Francisco, but it still has many interesting technological and algorithmic challenges, such as trying to intuit whether people at a crosswalk are really going to cross, or whether a bicyclist is going to get into the lane in front of the car.
I recommend reading the article to see how autonomous vehicles combine software engineering, robotics, machine learning, and computer vision in one sophisticated package.
This is hilarious (if you’re a programmer). Some folks trained a Markov chain on the class names in Spring and then made a game out of it – three Java class names are presented, only one is real. I didn’t do so hot – 4/11.