Apr 10 2005


The Unitarian Jihad

My Unitarian Jihad Name is: Sibling Cattle Prod of Patience.

Get yours.

Thanks to Sam Ruby for pointing out Jon Carroll's fantastic column on the newest movement in America. My favorite part:

People of the United States! We are Unitarian Jihad! We can strike without warning. Pockets of reasonableness and harmony will appear as if from nowhere! Nice people will run the government again! There will be coffee and cookies in the Gandhi Room after the revolution.

Welcome to the Jihad. Seriously, welcome. Have some coffee and pie.

Apr 06 2005


A Little Note about Religion

I was at lunch today with some friends, and we were talking about the religious passions of various developer communities. My friend James (congrats on the new job, by the way) was talking about the varying degrees of religious passion amongst the different developer communities at his office. The Java crowd, he said, was much more into debating the merits of different technologies, and much more likely to be disparaging or dismissive of other technologies than the .NET crowd.

This echoes my personal experience in this area, so I offer the following analogy: The Java crowd is extremely passionate because of the level of choice in the field. Since all Java developers at some point have to make a choice (I'm a WebLogic/Jakarta/Struts guy, or I'm a JBoss/WebWork2/Fit girl, or whatever), that element of choice causes the emotional stakes to be raised. Conversely, being a .NET person is like being a citizen of a country with a state religion: if somebody attacks your beliefs, you'll push back, but you aren't out there every day trying to promote it. Why bother? Where you live, everybody is the same religion.

Apr 06 2005


The Debate Rages

It seems that I'm being propped up as some kind of poster boy for Rails hysteria. I would have everybody re-read the "Conclusions" paragraph of my original post, which states (to paraphrase myself): This Rails stuff if really nifty, surprisingly efficient, and I had a lot of fun working with it, but I'm not quitting my managed-languages day job any time soon. For those of you who wish I had said something more controversial, I apologize, but I'm not all that controversial in real life (my wife and business partner would both describe me as conflict-averse).

Secondly, I wanted to respond to Keith's comment below, but I wanted to do it up front here on the main blog, because it speaks to something important and I don't want it buried. Here's Keith's comment, in it's entirety:

My issue here is the public has no way of judging the merits of this comparison, and I highly suspect there are fundamental architectural differences between the two versions that account for at least a decent portion of the LoC differences. In other words, you're not entirely comparing language vs. language here, you're muddying it by comparing development frameworks and architecture. You're also not attempting to explain *where* the Ruby version saves and the Java version bloats, and why. I wouldn't doubt it if the Java version was overengineered to begin with. But it's all speculation at this point. What I read is hype in support of your next book. That's what the sigh is about. Promote all you want, certainly, you're doing a great job. I'd just like to see a little community contribution, too, while you're at it.

Let me make this absolutely plain so there is no confusion: I am not involved in either the Ruby on Rails project, the Ruby language, or any book about Rails. I'm not employed at 37signals or Next Angle. I've never met DHH. At most, as a reviewer Dave Thomas' forthcoming Rails book, and as Bruce Tate's co-author on "Better, Faster, Lighter Java" and "Spring: A Developer's Notebook", you might say I have a friendly interest in Rails doing well because that would mean two friends of mine were doing well. But I receive nothing from having posted this story other than the wonderful discussion it has spawned.

As for contributing to the community, I have offered, again and again, to take part in any open source version of Petstore-or-something-like-it that anyone wants to organize, but at this point, I think we've gotten off track. Here's where I was trying to go with this whole story, and where I think we've gotten lost along the way:

There are a lot of developers in the world who develop in Java or .NET or C or Perl because that's all they know. There's a lot of FUD in the world that says to stay away from X, or Y, or Z because it isn't, or, my favorite, "can't possibly be" any good. I took a gamble and tried something new, that being Ruby on Rails. I was genuinely surprised, and pleased, by the results, and so was my paying customer. That leads me to want to tell people about it, because when I have fun, I want others to have fun. It was that impulse that led me to co-author the Spring book with Bruce, because Spring is a lot of fun, and makes writing Java apps fun. (And by the way, if you don't think writing books is contributing to the community, you haven't seen many royalty statements. ;-) )

So I say to you: take a look at Rails. If you are writing web applications that babysit a database, and want to try a more expressive and less restrictive language than C#, VB.NET or Java, it just might be a good thing to do. If your application needs XA transactions or detailed security management, you might want to stick with a strongly-typed, managed environment with a lot of vendor support, because overall, that will be a more pleasurable experience than fighting against a tool that is ill-suited to your needs. As anecdotal evidence, I offer you this one pleasurable experience I had. Hopefully, I'll follow it up with others.

I suppose it is also possible that every single blog post in the development blogosphere must end with YMMV, but that just seems redundant.

Apr 05 2005


Rails: What would it take?

The response to my earlier post about my experience with a (admittedly, small) Java to Rails port has got me thinking. There's a lot of folks, here, on /., and elsewhere, who dismiss Rails out of hand as not being "Enterprise Ready". And, as much as I want to argue with them, I kind of have to agree. Even though I can't really define "Enterprise Ready", or what "Enterprise Software" is, I can say that there are classes of web-enabled applications that you simply can't solve with Rails right now.

Which begs the question: enough FUD, what is it really missing? I've heard that internationalization is a big one for lack of Unicode support, though that argument doesn't really hold water anymore with Ruby's support for Unicode and the new article on using GetText for translation. And I know the "its interpreted, not compiled or managed" argument, which has merit and for which there is no current answer. But I'm interested in features: what is Rails really missing that would allow it to grow into the next tier of application development?

The things that come to mind are:

  • Distributed Transaction support: as much as this is the bane of our existence, it is absolutely necessary in some environments to support distributed transactions. The how to on using multiple databases doesn't even address this as an issue; it is primarily concerned with db routing and failover support as opposed to multi-db transactions.
  • A Security Manager: something akin to the Java Security Manager and
  • A second-level cache: something to provide an alternative to all-lazy-all-the-time loading.

What else? Other ideas?

Apr 04 2005


Some New Comparisons Coming

Two new comparisons coming up over the weekend. One, serving the site using Resin instead of Tomcat. Two, running the whole suite on my Windows box instead of my Mac. I'll let you all know what the results look like. Thanks Mark and Anoop for the suggestions.

Apr 04 2005


Some Numbers at Last

So, a few weeks ago I made an offhanded post here about my new-found love for Rails. I'd been skipping off the surface of Ruby for a while, trying to decide if it, or Python, or Groovy, or something else, ought to fill out the empty slot in my tool belt. (I'll save the "why LISP isn't on this list" post for another time.) Rails seemed like an excellent way to put Ruby through a workout, and I had the right sized project to try it out with.

The project itself is not open-source; the client is now and shall remain anonymous. But they are paying me my going rate to do this work, which makes it a commercial Rails project, and it will in the future be installed into some rather large organizations. I can't really say much about what the application's domain is, but I can lay out the general principles of the app.

The application must support multiple users, in the order of 10-100 concurrently. The load isn't particularly high, but the application will be treated like a desktop app (more specifically, a spreadsheet replacement) so it has to be responsive. The application is for managing pieces of a large machine process. There are lots of types of components to be managed, and the relationships between them can be quite complicated. There are no one-to-one relationships in the model, but plenty of one-to-many and many-to-many. In addition to managing the components, the application has to allow for the addition of entirely new categories of components as well as a variety of customizable fields. Finally, the authorization rules call for a breadth of user roles with a complex mapping of permissions to those roles.

I've finally gotten around to running the profiling numbers and doing some comparison between the two systems. I won't spoil the suspense by listing my conclusions up front -- you'll have to scroll through the rest of the post to see them. But, first, let me set the stage: the original application is based on the Java/JSTL/Spring/Hibernate/MySQL stack. I used ACEGI for the security, SpringMVC for the web controller, and was using Hibernate 2.x for the O/RM. To increase performance, I was using the default output caching from SpringMVC and data caching in Hibernate. The re-implementation is in Rails on top of MySQL. The authorization is done through a custom observer and a custom authorization class, which uses a declarative rules file for permission mapping. For performance, I'm using a combination of page caching, action caching, and cache sweepers (observers whose job it is to expire cached pages).

Now, for the comparisons:

Time to Implement I made a comment about this in the previous posts on the topic, and that comment has been quoted widely out in the wide blogosphere as a classic example of Rails hype. So, let me make it plain: any time you re-write an application, it will go almost infinitely faster because you already have a firm grasp on the problem domain. Such was the case for me in my re-write; we'd spent so much time on the domain model and the database schema that the second time through the application, everything already made perfect sense to me. Any comparison of how long it took to implement one or the other is bogus, since the only fair comparison would be to implement two roughly functionally equivalent projects in the two different stacks and measure the competitive results. Since I have not done that, making statements about how it only took 5 days to re-implement the site are almost meaningless. What I can say is that I had more fun implementing it the second time, but that's just personal preference.

Lines of Code This one is a lot more interesting. Folks will tell you all the time that there is a running debate about the meaningfulness of LOC comparisons. They're right; there is a running debate. I just think it's moot. For my money, the fewer lines of code I have to write to get a piece of functionality, *as long as those lines are clear in meaning*, the better off I am. Obfuscated Perl programs don't make the grade; I can write some really concise Perl code and not have any idea, three months later, what the heck I was doing. But if the code is legible, its intent obvious, then more concise is better, pure and simple.

Bear in mind that this comparison is somewhat unfair. The Rails version of the app has been in development for an extra month (meaning a month's worth of new features added) while the Java version has been stagnant since the switch. Since the Rails version started out as an experiment, I don't have a clear history of the codebase to be able to produce a version that is identical in features to the Java version. Therefore, I've made the comparison based on the current state of the app vs. the abandoned Java version.

The LOC counts used here do not include comments or unit tests, nor do they include simple punctuation lines (lines with just a "}" or "end").

Without further ado:

  • Lines of Code
  • Rails: 1164
  • Java: 3293

Number of Classes:

  • Rails: 55
  • Java: 62

  • Number of Methods:
  • Rails: 126
  • Java: 549

  • Configuration Lines
  • Rails: 113
  • Java: 1161

Those numbers are beyond striking. The configuration count alone is enough to make me think long and hard about what I've been doing lately. Let me forestall any criticism about my "agenda", by the way. Somebody recently said that I must have an "anti-Java" or an "anti-Spring" agenda. That is far from the truth, since my Spring: A Developer's Notebook hits shelves any day now. I don't want people to stop using Spring, or Java. In fact, I want lots and lots of Java developers to use Spring and lots and lots of non-Java developers to start using Java so they can start using Spring. But one of the things I like most about Spring (its concise configuration) is still, well, huge, compared to the same app in Rails.

Performance This is where everybody really wants to see the numbers. So, for the sake of total specificity, the following numbers were generated on a 1.5GhZ Mac OSX (10.3.7) PowerBook with a 4200rpm hard drive and 1GB of RAM. The Java app is running on Jakarta Tomcat v 5.0.28, while the Rails app is running in Lighttp with FastCGI. The setups are standard for each application stack.

Since both stacks have different caching mechanisms, with different degrees of difficulty to manage them, I'll start the performance comparison with a walk through the application without using the caching systems. To generate the first number, I walked through every screen in the application (using the screens available in the Java version to form a subset of the screens available in the newer Rails version) hitting pages that have not been cached yet. This starts from logging in, then hitting every available piece of functionality once. These numbers do not include the time it took me (the user) to navigate to the next request, only the time to process the requests. Both applications had roughly equivalent logging turned on (obviously, it can't be exact, but without the logging, I couldn't provide measurements). Here's what I found out.

To walk the entire application feature set, once, in Rails, without caching, took 41.801s. To walk the exact same feature set in the Java app took 58.369s. These numbers are averages over five attempts with each app, with full restart between to give the cleanest runs possible. Those summary numbers are deceiving, though. What I found was that, the less complex the feature, the faster the Java app served it relative to the Rails app. The more complex the feature, the slower the Java app served it relative to the Rails app. Some of that difference might be changes to the model during the re-implementation based on a better understanding of the domain. Regardless, that difference comes out to show the Rails app at ~30% faster than the Java version when caching isn't taken into account. If I am generous and say that half of the difference is due to optimizations in the model, that still leaves us a 15% better performance in Rails.

The caching story is interesting. The default caching mechanism for Rails is either page caching (caching the output of the rendering to a physical html file and letting the server serve it directly instead of invoking Rails the next time it is requested) or action caching (similar, except the output is cached in memory or another kind of store and Rails is invoked to process the request). On the Java side, there is JSP pre-compilation, Spring output caching and of course Hibernate data caching. I used a simple load tester to test a couple of pieces of functionality in the application. For each URL, I ran the test without a pre-existing cache of the response, then again with it, 100 times each, and then determined the number of requests per second.

Functionality 1: Rails, 100 runs, no pre-existing cache: 75.59 request/second. Rails, 100 runs, pre-existing cache: 1754.39 requests/second. Java, 100 runs, no pre-existing cache: 71.89 requests/second. Java, 100 runs, pre-existing cache: 80.06 requests/second.

Functionality 2: Rails, 100 runs, no pre-existing cache: 62.50 r/s. Rails, 100 runs, pre-existing cache: 1785.15 r/s. Java, 100 runs, no pre-existing cache: 80.06 r/s. Java, 100 runs, pre-existing cache: 88.97 r/s.

These numbers are not a great comparison, because there is tons more I can do to increase the cache performance of the Java application. No doubt whatsoever (I just hadn't gotten around to it by the time I abandoned it). What *is* interesting, though, is that the Rails page caching maxes out . The server can't serve the pages any faster than that. And with the Rails cache_sweeper observer pattern, it is dead-simple to use this hyper-fast caching whenever possible (obviously, highly dynamic pages can't be cached, but that's the case with that kind of page in any application stack). If you switch to the action caching (which allows all the filters to be executed) the Rails app still ends up in the 800-1000 requests/second range.

Conclusions So what do I think? I think that the application I'm working on is perfectly suited for Rails and Rails is perfectly suited for it. I think that I have had more fun working on the Rails app than the Java version. However, I think that the Java version is just as capable, and could be just as performant, as the Rails app. To me, the eye-opening revelation isn't "Rails is faster than Java/Spring/Hibernate". It's "Rails can be very fast". I think that there is a lot to be said for Rails, and it deserves much of the press it is getting. However, I don't think its a Java-killer. I think there are plenty of applications, and development teams, that are better suited to Java and its immense universe of available support libraries. I certainly am not going to stop developing in and learning about Java just because I've discovered Rails. On the other hand, I am going to spend more of my time trying to find projects that I can use Rails on.

I'm extremely interested in how these numbers strike folks, and whether there are other comparisons that you would find useful. So interested, in fact, that I'm risking blog-spamming by turning comments back on. So, if you have some other comparisons you would find useful, or some insight onto these numbers, or even some things you think I ought to try to make the comparisons better, let me know. I can't promise I'll tackle them all, but I think it will be interesting.

Apr 04 2005


Secret Service and Personalized Cracking

The Secret Service is into the decryption game (article) and its this kind of thing that makes me love computer security. Long story short, the SS has developed an app which scours the non-encrypted parts of a target's hard drive and creates a dictionary of terms from it that can be used to brute-force any encrypted portions. Even better, the software uses your browser bookmarks, follows them to their target sites, and uses those sites to expand the dictionary of terms. This gives them a focused corpus of words to attempt first, under the assumption that none of us is any good at picking or remembering passwords and we all use familiar material to help us.

I wonder if criminals use

Apr 04 2005


More on Rails and Java

Mike Spille made a comment on Dion's blog stating, essentially, that 3K LOC is meaningless and trivial and not worth getting excited over. Perhaps he is right, but on the other hand, it raises an interesting question: how would the size of the Java app be affected if written as, say, an EJB app? Did the choice of Spring and Hibernate reduce the amount of code in any noticeable way? I can't answer the question, because I'm not about to go rewrite the app yet again, but it is an interesting question.

Perhaps Dion is right about a Petstore, but the whole idea makes me shudder.

Apr 04 2005



Welcome, all you /.ers! Thanks for coming over. I'd like to say a big thanks to the crack team at TextDrive for getting us back up and running and not just booting us off the servers. The fix? They switched us from Apache to Lighttpd. Go fig.

Anyways, welcome aboard.

Mar 10 2005


More on Rails

Lesson 1: Never post about a hot topic in haste.
Lesson 2: Never assume nobody reads this stuff.
Lesson 3: Never make passing statements about personal experience unless you have hard scientific, statistically significant chartsand graphs with circles and arrows on the back to prove it.
Lesson 4: I actually like that people read my post and were turned off; it was too "hype-y".

I posted a brief note earlier about my experience with Rails, and got several interesting responses.

Mike Spille, in a comment on Dion's blog, says:

Hey Dion, I have a bridge to sell ya :-) You gotta start reading with a more critical eye, man. He spent 5 months writing an app and then re-wrote 80% of it in a new language in 4 nights? That alone should get your radar jangling. Then he says it's fast, sometimes even faster than the old stuff - but he won't know for sure until he measures it. Huh? He hasn't done measurements but he can say one or the other is faster? Sorry Dion but the whole blog entry you're referring smells from one end to the other.

For Mike's benefit, you are right, my post was not rigorous enough in its numbers or definitions. So, here's a quick recount: I've been working part-time on an application for ~5 months, with a domain model that has been through three *major* revisions. So the total amount of time I spent writing code on the project was somewhat less than 5 months of full time work.

Regardless, being able to recreate 80% of it in 4 nights of work was thoroughly rewarding, but not particularly shocking given the readily understood 80/20 rule of software development. The first 80% is ALWAYS the easiest. Its the last 20% that kills, and it took longer to get that in.

As for whether or not I can say one is faster than the other without measurements, well, I'll be doing some benchmarks over the weekend, but c'mon, Mike, I have eyes and an internal clock that's *reasonably* accurate, and can tell the difference between a call that takes 1.5 seconds and one that takes .5. :)

Comments over at David's blog weren't quite as specific, but were also looking for numbers. Check back on Sunday, and I'll let you know. But for those who want something to chew on:

Original app:

  • MySQL
  • Java 1.4.2_05
  • Tomcat 5.0
  • Hibernate 2.1.2 (with extensive optimizations)
  • Spring 1.1
  • JSTL

New version:

  • MySQL
  • Rails 0.10.0
  • Ruby 1.8
  • Lighttpd w/ FastCGI

I'll let you know what the numbers look like after my weekend of air travel.

Popular Tags