Tag Archives: Ruby

Why people are returning to Java
7

Why people are returning to Java

| By | 7 comments

I am a huge fan of Ruby on Rails, but I was not terribly surprised to read that as Twitter’s code base has grown, they’ve found it more amenable to move to JVM-based languages for reasons having mostly to do with encapsulation. InfoQ interviews Twitter engineer Evan Weaver about how the company’s stack is evolving as they get bigger.

On one hand, they’re moving more services to the JVM for performance reasons. When they extract components from their main code base to optimize them, they generally migrate them to the JVM:

The primary driver is honestly encapsulation, so we can iterate faster as a company. Having a single, monolithic application codebase is not amenable to quick movement on a per-team basis. So when we decide to encapsulate something, then because of our performance concerns, its better to rewrite it in the JVM for most systems, than to write a new Ruby system.

They’re also finding the rigidity of the JVM useful for productivity reasons:

And the other half is that, as search has moved into a Service Oriented Architecture and exposes various APIs, static typing becomes a big convenience in enforcing coherency across all the systems. You can guarantee that your dataflow is more or less going to work, and focus on the functional aspects.

Those are the kinds of reasons why I could not imagine rewriting the main application I work on as a Ruby on Rails application. I’m surprised he doesn’t also mention the maturity and power of the tools on the Java side. Text editors like TextMate and Vim are great, but when it comes to navigating through a large, complex code base, you cannot beat the state of the art Java IDEs like Eclipse and IDEA.

Update: Edd Dumbill lists seven reasons you should use Java again.

March Madness dorkiness
0

March Madness dorkiness

| By | No comments yet

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.

John Resig on _why
0

John Resig on _why

| By | No comments yet

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.

Why do Ruby developers test?
4

Why do Ruby developers test?

| By | 4 comments

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.

Links from June 12th
0

Links from June 12th

| By | No comments yet
Links from June 8th
0

Links from June 8th

| By | No comments yet
Links from March 23rd
0

Links from March 23rd

| By | No comments yet

There are a whole ton of links in the backlog today.

The Ruby book market
1

The Ruby book market

| By | One comment

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:

  • Deployment problems. The Rails deployment picture did not improve quickly enough to enable people who were dabbling with Ruby to make the transition to deploy real applications. That could be lowering interest in Ruby. I think 2009 will be the year of Ruby deployment — Phusion Passenger changes everything.
  • Lack of new bestsellers. Speaking for myself, I bought several Ruby and Rails related books in 2007, and none in 2008. There just weren’t any titles that really caught my attention.
  • Fragmentation. It seems like 2008 was the year in which there was a lot of splintering in the Rails community, and for good or ill, Ruby and Rails are still tightly coupled. People were trying new test frameworks, alternative persistence frameworks, and alternative Web frameworks. This hurts the book business.
  • Declining interest in Ruby in general. There are any number of reasons why interest in Ruby (and more specifically, Ruby on Rails) may be declining. For one thing, no platform can be the “new hotness” forever. For another, there are plenty of things not to like about Rails, the rate of change not being least among them. My feeling is that it’s nearly impossible to keep up with what’s going on in Rails unless you make a full time job of it. Fatigue sets in.

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.