Following a post by Aleks Jakulin, I found a great site that presents an interactive Ruby prompt married to an extremely user-friendly tutorial: Try Ruby.
I don’t know Ruby at all, but I followed the tutorial for a bit and quickly felt comfortable with the basic syntax. I’m not a perfect candidate to judge this for a novice because I’m proficient in a number of other languages, but this is the best tutorial I’ve ever seen for any language, period. It makes me cringe when I think of days spent with a fat book propped open, trying to understand some obscure nuance of a language’s syntax that, somehow, was obvious to everyone except me.
So, if you’re looking to learn Ruby specifically or just want a better understanding of what it means to program, look no further than this easy 15 minute tutorial. The colorful page and everyday language make the process much less intimidating than, say, Try Python.
This morning, I was excited to see two of my interests collide as Nathan from FlowingData posted a tutorial for creating a choropleth: a map that uses color to convey values (I didn’t know that’s what they’re called either). He used county-level unemployment statistics to generate the following image:
However, the process appears quite intense, involving some python scripts and mucking around inside an SVG file. I half-heartedly wondered if there wasn’t a simpler way to create the image. And just then, along came David from Revolutions to throw down the gauntlet: could anyone come up with a way to replicate Nathan’s map in R?
David’s post pointed me toward R’s maps package, and off I went to start downloading the tools…
It took some time to coerce the BLS data into a compatible form; R don’t understand the FIPS county identifiers, so I had to jump through some hoops to get the strings to match (BLS uses state abbreviations; R wants full names. BLS puts in the words “county”, “parish” or “borough”, R doesn’t expect those to be passed. The BLS has a “Miami-Dade” county in Florida; R recognizes only “Dade”. Etc.) Ultimately, I used the following code to format the strings:
With the data in the correct format, I aligned a color vector with R’s list of counties and plotted the result:
It came out like this:
Not too bad, I think. It’s a little rough around the edges and a couple of counties are missing – I assume they are the ones with odd naming conventions (you’ll notice I manually adjusted Miami-Dade in my code). Also, I’m not sure how to bring Hawaii and Alaska into the picture. Moreover, the image doesn’t look too good in R itself. For example, I had given up on getting the county borders to show up as faint lines (I could only get them to be completely opaque) – imagine my surprise when I exported the chart and could see the borders just fine!
In any case, I wasn’t satisfied with this result. I’ve been experimenting with ggplot2 and remembered it had some mapping functions, so off I went to recreate the image with yet another library. Ggplot2 is an excellent general-purpose graphics library; the maps package feels positively last-gen after playing with ggplot2. It’s much more extensible and has many more parameters to experiment with – hard to believe it’s not the standard graphics package that ships with R (which itself is another last-gen experience).
Anyway, I kept the data formatted as above – which may have added an extra line or two to the ggplot2 code, but makes it simpler to jump back and forth – and used the following script to draw a new version of the map:
And the resulting image:
Again, a couple drawbacks: Alaska and Hawaii are nowhere to be seen and the borders are slightly aliased. The aliasing does make a difference, especially when compared to the maps output, but the ease with which I put together the latter graph and the frustration I experienced with the maps package, in my mind, more than erase that perceived shortcoming.
On the whole, I’d still take Nathan’s map over these as a finished product. However, I don’t think R can be beat for ease of use and all-in-one packageability – if I wanted, I could run regressions on the data, overlay my chart with more colors or new metrics, explode out certain counties or states… the possibilities are endless. With just a couple lines of code, I could overlay states the voted for Obama in blue, or highlight counties starting with the letter “C”. The static SVG method doesn’t allow any of that flexibility. Also, I’m completely confident that if I had any experience with these mapping packages – rather than using them for the first time tonight – I could mimic Nathan’s image perfectly.
The ggplot2 package, in particular, is fantastically powerful. I really wish I had discovered it sooner. As a matter of fact, Josh Reich runs a monthly R meetup for R users in the New York area and the next topic happens to be ggplot2 – it’ll be my first time attending, so I can’t really say what to expect, but I’m definitely looking forward to it.
Google has posted a style guide for R which is being used throughout the organization. It’s mostly in line with what I learned once upon a time, but it’s nice to see such an authoritative body coming out with a set of standards. Universal coding benefits everyone, and R is growing so rapidly that some form of standardization is becoming necessary.
A couple bullets:
- File names: end in
.R
- Identifiers:
variable.name, FunctionName, kConstantName
- Indentation: two spaces, no tabs
- Curly Braces: first on same line, last on own line
- Assignment: use
<-, not =
- Semicolons: don’t use them
The full guide is available here.
(via Revolutions)
Update 6/8/09: The release version of Safari 4 went with none of these.
One of my favorite Safari features is that the address bar doubles as a progress bar, whereas most browsers place a progress bar at the bottom of the screen, taking up real estate. This is how mobile Safari works on the iPhone and it is how the current release version of Safari 3 works.
The Safari 4 beta, however, gets rid of this behavior in favor of a little “spinning wheel” that tells you that a page is loading but gives no indication of how much has been loaded. It sits at the far right of the address bar:
It turns out that there are actually three different progress indicators available in the Safari 4 beta. The first is the default choice of the spinning wheel. The second is the old Safari 3 progress bar, which looks like this:
To enable this throwback indicator, load up Terminal and execute these two commands (while these two lines of code are harmless on their own, use caution while messing around in Terminal — you can easily damage your computer from the command line). To restore the original settings, just replace NO with YES.
defaults write com.apple.Safari DebugSafari4LoadProgressStyle -boolean NO
defaults write com.apple.Safari DebugSafari4IncludeToolbarRedesign -boolean NO
As you might expect, the first line turns the new Safari 4 progress indicator off. The second line restores the entire address bar to its Safari 3 look – meaning the new bookmark button and other embedded controls disappear. You need to revert both parameters to get the old progress bar back.
What happens if you only turn off one setting? That depends on which one you choose. If you disable the LoadProgressStyle parameter but leave IncludeToolbarRedesign on, nothing happens as far as I can tell and the default Safari 4 behavior persists. If you leave LoadProgresStyle on and turn IncludeToolbarRedesign off, however, you get a third, hidden progress indicator:
This little “progress icon” is my personal favorite – it gives complete information with minimal real estate use and distraction. Unfortunately, I like the new address bar in Safari 4 more than I miss a useful progress indicator, so I’m leaving the default settings turned on. Which do you prefer?
p.s. This will not affect your bookmarklets.
Update 6/8/09: This still happens in the release version of Safari 4.
Update 6/13/09: More details available at Sakuzaku.
I have been unable to verify if this is a widespread problem or just my luck, but my Java bookmarklets are no longer working in the Safari 4 beta. Bookmarklets are mini-applications that can be run by a web browser.
Specifically, I use two bookmarklets to quickly resize my browser window in an attempt to solve my frustration with Mac OS X not having a proper “maximize” button. One bookmarklet makes the window take up the whole screen, the other makes the window smaller and recenters it. They sit in my bookmarks bar, and so resizing/recentering is just a click away (or, a command-1 or command-2 away — the only time I’ve ever appreciated that Safari chooses bookmarks, not tabs, in that manner). But suddenly in Safari 4, neither is working!
The maximize bookmarklet is:
javascript:self.moveTo(0, 0); self.resizeTo(screen.availWidth, screen.availHeight);
The small window bookmarklet is:
javascript:self.resizeTo(1024, screen.availHeight * .9);self.moveTo((screen.availWidth - 1024) / 2, screen.availHeight - screen.availHeight * .95);
Is anyone else having problems executing this code?
Edit (5 minutes later): And now it’s working again! Never mind! Maybe it was related to some hacking I was doing in Safari’s developer settings… more on that later if it turns out interesting.
Edit (10 pm): The problem is related to multiple tabs being open. Bookmarklets work fine with just one tab.