As you may or may not know, the NCAA Tournament starts this weekend, and people around you are probably doing their best to predict the winners of all of the games in the tournament. Most years I join one (or more) pools, but I don’t watch enough college basketball to make educated guesses about who will win each game. This year, I wrote a program to do it for me.
I started with Ken Pomeroy’s team ratings. Here’s his explanation for how the system works:
My ratings produce a number that actually means something–it’s the chance of beating an average D-I team on a neutral floor. For instance, Michigan’s current rating of .8006 means that the Wolverines would win 8 out of 10 games against the average D-I team. Every March, I borrow Bill James’ log5 formula to take these ratings and compute probabilities for each team to win its conference tournament.
I’m not sure how the log5 formula got its name, but it’s fairly intuitive. Think of a coin with one side labeled “win” and the other side labeled “loss.” The chance of the coin landing on “win” is the team’s rating. Log5 is derived from the probability that a team’s coin will land on win and its opponent’s coin will land on loss. (If they land on the same side, you re-flip.)
My script takes the source from Pomeroy’s ratings page and reads in all of the teams and their ratings, and then picks a random winner for each game based on the log5 comparison of Pomeroy’s ratings. Here’s the output for a hypothetical Final Four the script generated:
FINAL FOUR
Maryland has a 45% chance of beating Syracuse
Winner: Syracuse
Kentucky has a 56% chance of beating Baylor
Winner: Kentucky
NATIONAL CHAMPION
Syracuse has a 51% chance of beating Kentucky
Winner: Kentucky
The script has no way of knowing which teams will upset higher seeded opponents, other than by giving teams that Pomeroy’s system likes a better chance of winning, but it should pick roughly the right number of upsets based on the odds.
I’ve uploaded the script to a repository named bracketologist on GitHub if you want to play with it. It’s written in Ruby.
Everybody’s linking to Ryan Tomayko’s post, I like Unicorn because it’s Unix, but I’m not going to let it keep me from linking to it as well. It’s a paean to the Unix design philosophy, and really illustrates how few applications these days are built on that philosophy. Go read it. It’s good.
jQuery author John Resig has written a great remembrance of a truly interesting individual. Nobody seems to know what is up with the person who played _why the Lucky Stiff on the Web, but _why appears to be gone, perhaps for good. As for _why himself, he appears to be one of the few people who gets to read their own obituary. His work has been much appreciated.
Giant Robots asks the question, Why Do Rubyists Test So Completely? It’s a good question. Developers on other platforms would benefit greatly from the culture of testing that has been established among Rubyists (and especially Rails developers). They have their own list, and I agree with all of the items on it. I have one reason that I’m surprised they didn’t list.
Rails makes it really easy to start testing. When you generate a new Rails application, it gives you a place to put your tests. When you generate controllers and models, it creates skeletal tests for them. Nobody has to sit and wonder, “What should I be testing.” The framework tells you. So the next step is just to fill in the blanks. Then when you want to run your tests, you just type “rake” in your application directory.
Java has JUnit and all of the IDEs have test runners, but beyond that, you’re on your own. What do you test? How do you organize your tests into suites? How do you run the suites? These are all questions you have to answer before you build a testing regime. Individual unit tests are easy to write, but getting it together to really make a habit of testing is a lot more work than it is with Rails.
And in the PHP world, things are even worse. I have never seen a PHP application with a robust unit test suite, although I’m sure they exist.
The Rails approach makes the biggest difference with people who aren’t already committed to unit testing. If you know the value of testing, you’ll jump through the hoops to set up tests, even if it’s a pain. If you’re not yet convinced, then the extra work required to set up unit testing with other platforms prevents people from getting started. It’s very much the deliberate choices the creators of Rails made to encourage and facilitate testing that explain in large part why testing is such a part of the culture.
The Rudimentary Art of Programming & Development, a programming blog, has done a detailed comparison of Ruby and Python and declared them interchangeable. In my far less systematic comparison, that’s how it has seemed to me as well. Glad that’s settled.
There are a whole ton of links in the backlog today.
Joe Gregorio prompted me to take a second look at O’Reilly’s “state of the market” report for books on programming languages. Of particular interest to me is what they report on Ruby:
We reported last year that Ruby had grown nicely, had passed Perl and Python, and was knocking on the door for Visual Basic’s spot. However, Ruby had the largest decrease in unit sales in 2008.
Let’s go to the numbers, 95,731 Ruby books were sold in 2007, and 61,171 Ruby books were sold in 2008. That’s a big drop. In terms of absolute size, in 2007, the Ruby book market was about 40% of the size of the Java and C# markets. In 2008, Ruby’s market was about 28% of the size of the Java market, and 22% of the size of the C# market. (Python has almost caught up with Ruby.)
Some thoughts on possible reasons why Ruby fell off so sharply:
There may be other reasons as well. I would also caution people a bit against assuming too tight a correlation between book sales and the overall health of a programming language. It’s a piece of the picture but not the whole picture.
The other thing I take away from this is that it’s hard to see beyond your cocoon. From where I sit, the large growth in C# book sales is surprising. I don’t really know anybody who uses it. I’m not surprised by the Python growth, and I am shocked by the decline in the market for JavaScript books. This is one of the reasons why I’m looking to expand the portfolio of software development blogs and news sources I’m following.
So the big news on Twitter among Ruby programmers is that the “hashrocket” operator has been deprecated. For those of you who aren’t Ruby programmers, here’s what that means. If you want to declare a hash literal in Ruby, right now you can do it like this:
my_hash = { :foo => "1", :bar => "2" }
Also, many methods accept hash literals as an argument, so you can do things like this:
url_for :controller => 'posts', :action => 'index'
At some point, that notation will be unsupported, and hash literals will have to declared in a different way.
When the version of Ruby is released that doesn’t support this notation, it will be incompatible with a massive amount of Ruby code. My advice to the Ruby developers would be not to do it. I don’t know what the rationale is for removing it, but the result is going to be lots and lots of servers that are simply never upgraded to that version of Ruby.
They should take a lesson from the PHP people. The migration from PHP 4 to PHP 5 has taken forever as a result of much smaller incompatibilities than this one.
Economics tells us that we have to be careful about the incentives that result from our actions. Removing the hashrocket operator creates a strong incentive to leave the Ruby upgrade path.
Update: Sometimes rumors on Twitter are just rumors on Twitter. I don’t see any mention of deprecating the => operator in the Ruby Subversion repository.
© rc3.org. Powered by WordPress using the DePo Skinny Theme.