EclipseWorld

This week I have been speaking at EclipseWorld in Reston, VA. I have been talking about Ruby on Rails mostly, and a little session on iPhone (web) development. Most of the developer here are Java developers, so they look at Rails as a way to make their jobs easier. It's a grim economy, and they are being given the classic task of doing more with less. They look at Ruby on Rails as a way to do just that. More features. Less code. Happier developers!

EclipseWorld has been a great conference to speak at. What has been very cool for me is interacting with developers outside of Silicon Valley. Now don't get me wrong, if you are a developer, especially a web developer, then Silicon Valley is the place you want to be. I would compare it to working on Wall Street if you are in finance, or working in Hollywood if you are in show business. It's not for everybody, but it presents the chance to prove that you've got what it takes, and, if you are lucky, a chance to make a lot of money.

However, in the Valley it is easy to forget that most web development is not about creating The Next Big Thing. In the Valley, @tychay will rip you up for using Rails because it fails at web scale. On the east coast, I have met a lot of developers creating internal web applications, or maybe customer service applications. These are applications that can run just fine a single multi-core box, even with the database running on the same machine. They aren't stressing out over page weight, database partitioning, or terabytes of cache. They are creating sophisticated applications, and always have way more feature requests than they have time.

These are the people who are most empowered by tools, especially Eclipse. They don't have some huge team with specialists for doing the CSS or tuning the database. They do it all themselves, and Eclipse makes that a whole lot easier. I've written a lot about things you can do with Eclipse, but this experience has really put things into better perspective.

Recent Other Writings

Last week, IBM published an article I wrote on using JRuby on Rails with Apache Derby. It concentrates on rapid prototyping/development. I didn't get too heavily into the IDE side of things, but when you add RadRails into the equation it really is nirvana-ish development. Very fun.

I've also been writing a lot on InformIT about Java Concurrency in Practice. I did some fun stuff over there too, like try to turn some Project Euler code into parallel code. I guess technically that succeeded just fine, but is a good example of when parallel code is not any faster. In this case, the algorithm was CPU bound anyways. Even having two cores didn't really help much. Oh well. I treated it like a strength exercise back when I took piano lessons.

Get Lifted

Yeah, I'm a John Legend fan, but that's not the reference here. The reference is to Lift, the web application for Scala. Today IBM published an article I wrote about Lift. This was an article that I pitched to IBM and I was very excited about writing. Lift itself takes a different approach to web development than the typical MVC approaches. It is also in Scala, and takes great advantage of that languages features, especially its native support for XML.

One of the most surprising features of Lift was the ORM that it includes. Lift's creator, David Pollak, commented that he would use JPA for complex schemas and not Lift's ORM. I must admit, it was the part of Lift that took me the longest to get my head around. I consider myself quite the veteran of ORMs, but Lift's is definitely unique. I think it needs some tooling around it, as it felt like some boilerplate-ish code was present (like creating a model class and singleton factory for the model class.) However, I really liked its use of generics.

I didn't have time in the article to get into Comet with Lift and Scala's Actors. That is an awesome feature. Hmm, perhaps that should be another IBM article..

Finally, of Lift and Scala related news... check out Graceless Failure by some of the developer at Twitter. It seems to imply that Scala and maybe Lift or at least "in the mix" at Twitter. I wonder if it is replacing Ruby and/or Rails in some places. Certainly Actors would seem like an obvious way to handle new updates on Twitter.

Armchair Architects

Funny post by @al3x about Twitter architecture. Oh wait it wasn't supposed to be funny, oops. The fact is that he should totally expect more people to diss Twitter and pretend that they could easily solve all of the problems. I am not just being cynical about people, they actually have some good reasons to do so:

• Twitter crashes a lot. If your site did not crash so much, then people would not think you are an idiot and that they could easily do a better job. The people may all be wrong, but that does not matter. Why do you think Microsoft has come to have such a bad reputation? People do not care about what MSFT did to Netscape, Sun, or Apple. They care about BSODs. People hate Vista because Microsoft did not make it as backwards compatible with 3rd party drivers that did lots of bad, hacky things. But now Vista crashes, so people complain about MSFT.
• Twitter seems simple. You put a 140 character limit on updates and what do you expect? Part of Twitter's appeal is its simplicity, but that same simplicity creates expectations and makes people think they could do it themselves better. Maintenance is expected for things that seem complex, like cars or Photoshop, but not for (seemingly) simple things like iPods or Twitter. If you think hard about it, Twitter is much more complex than it seems, but who wants to think hard?
• Ruby developers are obnoxious. Oh this is my favorite. Ruby developers are a small but very vocal group. They love rubbing it in your face that Ruby is so much more expressive or object-oriented or whatever than anything else on the planet. The Rails sub-cult is even worse about this. So when the most high-profile Rails site starts failing constantly, you must expect a lot of smug developers to wag their fingers. It is kind of a shame that Twitter is paying for DHH's bad karma ... but then again @blaine did make that infamous claim about how easy it was to scale Rails. Of course he's gone now, but there is still enough bad karma to go around. How many Ruby developers would admit how bad their software is? Think about that.

As the Bird Turns

Another week, another Twitter outage ... and a new round of technology questions and rumors. TechCrunch now thinks that Twitter is abandoning Rails. This time out, Arrington attempts to be a little more fair-and-balanced than when he wrote about Blaine leaving. He points other sites that claim to have scaled Rails. This was of particular interest to me, so let's take a look.

Scribd -- Slide 7 claims three databases! Uh oh, is DHH right and I'm going to have to eat crow? Well maybe, but not because of Scribd. They only use master-slave relationship, but cleverly offload expensive queries to the slaves. Still only one place to write data. When (if) their data gets too big for a single database, they are going to be the ones singing "bring that beat back!"

Friends for Sale -- I could write a lot just about these guys and how ... umm ... interesting their setup is. I'll just quote them: "The most important thing we learned is that your scalability problems is pretty much always, always, always the database" but "on the database side we're still with a monolithic master and we're trying to push off sharding for as long as we can." They still have no problem claiming that "The whole 'but does Rails scale?' discussion sounds like a bunch of masturbation - the point is moot." You can't make up stuff like this!

Why Johnny Can't Scale

Today TechCrunch "reported" that Blaine Cook has left Twitter. I had the pleasure of interviewing Blaine and his fellow Twitter developer Alex Payne last year. I was working on a book about Ruby on Rails, so they made the perfect people to talk to. After all, they had written a Ruby on Rails application that was being truly pushing the scalability limits of Rails. I was most interested in those limits and how they were attacking them. Let's get back to the present though.

Michael Arrington pins a lot of Twitter's notorious instability squarely on Blaine. He has a point. He points out that Blaine did a presentation at a Rails conference on how Twitter had scaled Rails. If you go out and say "here's how to scale Rails", your app is part of your proof. Facebook can go out and tout the scalability of PHP, MySQL, and memcache. You can dispute their rationale, but their results are hard to argue against. Blaine could have a great rationale behind how they scaled Rails, but the instability of Twitter discredits any argument.

Some of TechCrunch's reader object to this. They point out that Twitter only had three developers. Others say only ignorant non-programmers would blame Rails or Blaine. Maybe they are right. Here goes my explanation.

Take a look at that presentation that Blaine did. In particular, look at slide 3. I quote "180 Rails instances (Mongrel). Growing fast." That is essentially 180 web servers. That is 180 instances of the Twitter application serving requests made by Twitter users. Keep in mind that this was a year ago, so you can only imagine what the numbers are like now. Now take a look at the next line in that slide "1 Database Server". No mention of that growing. I won't claim to know the intricacies of Twitter's operations, but this is an obvious bottleneck.

Since then Blaine & co. did a lot to alleviate the pressure on their bottleneck. They created an innovative messaging system called Starling. They made heavier user of memcache. To my knowledge, they still have that 1 Database Server.

If you are familiar with Rails, then you know that this is a flaw in Rails (a flaw in ActiveRecor to be more precise.) RoR associates a class to a database connection. You can write code that alters this behavior, but it is very hard to do this efficiently. Now let's be fair. This is true of a lot of frameworks, maybe all of them. Java practitioners like me know that our favorite technology with similar functionality, Hibernate, has the same flaw. Google has kindly produced an extension, Shards, to address this. Certainly the general JavaEE specification does not address this.

So it's not just a Rails problem, and we shouldn't blame Rails, right? Not so fast. Rails is the poster child for rapid, high productivity development frameworks. Remember how TC readers pointed out that Twitter only had three develoeprs? Rails is a big part of that story. In general, Rails is one of many technologies that seek to simplify web development as much as possible. This allows three developers to build such a popular site, but that's also the problem.

It's easier than ever to build a website. Social media makes it easier than ever to gain eyeballs. But it is just as hard to scale your site to handle massive traffic. Actually, maybe it is harder. When you rely heavily on frameworks and out-of-the-box goodness, it is that much harder to rip it out or reject it when you outgrow it. Rails magnifies this problem, because it is not just a technology, it is a philosophy. Rails developers pride themselves on the elegance and terseness of their code. If you are already writing ugly code, it's a lot easier to throw it away and write code that is an order of magnitude uglier but solves your scale problems. When you write beautiful code and don't know of a beautiful way to solve your scale problem, what do you do?

Finally, it is easy to trivialize Twitter's problems. "Oh they just need to use PHP" or whatever. Think about their application a little more before you say that. Let's think about a really naive approach to their application. You have a User who creates Updates. One User has many Updates. For example, I am a Twitter User and today I have made three Updates. I follow 65 other Users. The naive approach (also the one a DBA would tell you to use) is to have a join table to associate who you follow. So what has to happen when I load my home page? First, we need to figure out the 65 people I follow. Next we need to get their Updates. How many of their Updates? Well there are 20 Updates shown, but they are the 20 newest across all of my 65 friends. So do you grab all of the updates from all of my friends and then sort it? That is certainly the most naive approach. In that naive approach, we need one query to get my friends and then N queries to get all of their updates. We can put a sort on those N queries and then do a merge sort, quitting once we get the first 20 potentially. Still each of those N queries could be returning a lot of data. We all follow @Scobleizer, right?

So even if we only needed "1 Database Server", things are non-trivial. What about splitting your database? Obviously you want to split the Updates table. Let's think about your home page. Ideally all of the Updates on that page would be in the same database, so all of your friends need to be the same database server. But what about the other people following your friends? You see where this is going. The Kevin Bacon six degrees of separation problem is going to kick your ass.

The point is that even though Twitter might seem simple to the outsider, it is not. It is complex. Even if they didn't use Rails, it is non-trivial. Rails definitely does not help, at least in some regards, and that's the real story. It may be easier than ever to build something and, perhaps because of social networking, easier to get an audience. But all of the syntactic sugar in the world doesn't make it any easier to scale an application.

Metaprogramming in Grails

Groovy is a swing-and-a-miss. It will go down like OS/2 did. People will say "man that Groovy language was so good, I don't know why it didn't catch on." Here's an example of why it is a fail.

I was reading this article on developerWorks about GORM, the OR framework in Grails. Like everything else in Grails, it is "inspired" by Ruby on Rails. In this case GORM was inspired by ActiveRecord. In GORM here is an association:

class Airline {
 static hasMany = [trip:Trip]

 String name
 String url
 String frequentFlyer
 String notes
}

Compare this to the same thing in Rails

class Airline < ActiveRecord::Base
 has_many :trips
end

Forget the explicit listing of fields for a minute, concentrate on the has-many notation used by both frameworks. In Grails, you have a static field that has a special name. In ActiveRecord you use a meta-API or macro (or whatever you want to call it) to dynamically add methods to each instance of Airline. Grails accomplishes the same thing, but it is much more of a hack. You just happen to have a static field that has a special name.

It just feels like "wow that feature is cool, we can't do it the same way ... but we can hack something together that is pretty close!" Just seems like Groovy comes up short.

Galpin on Rails on IBM

A couple of pieces that I wrote on Rails appeared on IBM at the end of last year. I didn't even realize it until today when somebody emailed me about one of the articles.

The first article is part one of a four part series on using Rails, XForms, and DB2's PUREXML tables together. I also wrote part two, but another writer wrote parts three and four. Only part one is up so far.

The second article is the third tutorial I wrote on using Eclipse as a web development platform. Part one was about using Eclipse for Java web development, and part two was on using it for PHP development. The last tutorial is on using Eclispe (via RadRails) for Rails development. Note, the link for part two shows the intro page to part one. If you login, it correctly gives you part two. Clearly some kind of technical glitch for IBM!

Language Wars 2008

Two interesting blogs inspired this post. First, there is the amazing analysis of the great Neal Gafter. And then there is the insightful rant of Rick Hightower.

I have to admit that I am getting on the Scala bandwagon. Here is why I think Scala is important. Note, most of this is just me ripping off Neal Gafter :-)

There is great potential in languages with control abstraction. Scala is just such a language. It is possible to implement the actor model, a shared nothing, message based design for parallel computing, in Scala. This is not possible in Java. You can do it in Groovy, sort of, but it can be awkward. The reason for this is simple. If you have a object call method call closure (for example) the closure can return control back to the object in Scala, but only to the method in Groovy. The extra control structure coupling in Groovy makes some aspects of control abstraction awkward at best.

And then there are pattern matching (no not regexp) and case classes... The point is that there are syntactical advantages in Scala that make it possible to handle concurrent programming in a completely different, more scalable way. So it is not just about lines of code and what not, it is about being to do practical things in a better way.

Now Rick's main point in his rant, is why invest in JRuby and Scala when there is Groovy. Hopefully I've given at least one reason why Scala has potential that Groovy does not. When it comes to Ruby, the answer is less technical and more social.

On the technical side, it is very conceivable that by the end of the 2008, the absolute best way to deploy a Rails application will be to use JRuby. That is partially because of the current state of native Ruby interpreters, but also just because of how powerful the JVM has become. Sun really wants this to be the case, and here is why.

Sun knows what it takes to introduce a new language and platform and make it the de facto standard in the industry. It is very hard and expensive. They have done it once, and it cost them dearly. Java cannot stay at the top forever. They do not want to fight this battle again. However, if they can get the Rails on JRuby scenario described above to exist, then they could "stay on top" without having the fight all of the battles this time. They let the Rails community do it for them. They let guys like DHH and Martin Fowler win over the hearts and minds, while they simply concentrate on making JRuby run screaming fast.

But wait, there's more. Sun really wanted NetBeans to be the premiere Java development platform, but IBM beat them with Eclipse. They get a second chance if Ruby becomes the new de facto standard, and this time they have a head start on IBM. Sun is imagining a future where there are armies of IT developers writing Rails apps using NetBeans and deploying them to Glassfish.

Now all of the above may be possible, maybe even easier, with Groovy. But then they have to fight the language wars all by themselves. They have to win over the hearts and minds of developers to get them to use Groovy instead of C# or PHP.

That is why it makes more sense for Sun to back JRuby than to back Groovy.

That is also why you should not expect Sun to get behind Scala until they have no choice.

Rails 2.0 Released

If you are upgrading, I recommend upgrading Gems first (gem upgrade -system) and then using it to upgrade Rails (gem install rails --server http://gems.rubyonrails.org). There are some nice features. I especially like some of the Ajax security and JavaScript aggregating. The (expanded) JSON and XML support in ActiveRecord is also nice. 

TextMate and the Weak Dollar

I started using TextMate as it is very popular with the Ruby on Rails crowd and I am writing a book on Rails. It is a great product, and I like using for all kinds of things now. So once my 30-day trial expired, I decided to purchase it. They use PayPal for processing payments, and they charge you in Euros. Luckily, PayPal easily handles the conversion for us Yankees. This brought a brutal reminder of just how weak the US Dollar is now:




1 U.S. Dollar = 0.68 Euros ... Ouch! Suddenly TextMate seemed like a pretty expensive text editor. I still bought it, but it really made me second-guess the most recent Federal Reserve rate cuts. That gives me one more reason to vote for Ron Paul!

LINQ

I'm attending an MSDN talk today on several subjects. The one I came for is Silverlight. The first session of the day was on LINQ. It was pretty interesting.

LINQ is a real weird bundle of syntax that is being added to C#. The speaker, Anand Iyer, mentioned that it will be implemented in Mono. First it adds a SQL syntax for slicing in memory data. The classic example is around doing sub-selection and ordering of a List. This is nice, but looks funny. Reminds me of Oracle's attempt to get people to write SQL in the middle of JSP pages.

The second part of LINQ is as an ORM for databases and XML. This winds up looking like a bizarre mix of EJB3 and ActiveRecord. Annotations are used to embed mapping (table to class, property to column, etc.) Or you can use "implied" bindings (convention over configuration-ish.) Obviously the latter gives you a lot less code to write. I think you can also use a mix of these things.

It's funny to watch a language evolve. C# started off copying Java, but improving on it. Like Java, it has started to envy some aspects of dynamic languages. Microsoft has been able to move much faster with C# than Sun has with Java. Of course a big part of that is that it's a younger, much less widely used language. The stuff in LINQ really allows for syntax that looks eerily like Ruby or Python with constructs like someObj.find(name=>"Bob") At the same time, you get to keep a lot IntelliSense, which is huge for developer productivity.

If you've ever wondered what Java would look like if you could mix-in Groovy, then take a look at LINQ. It's a mess. It really looks crazy. It even made the speaker crazy. He kept trying to correct indentation and spacing to make it look legible. I guess that's what we all have to look forward to in Java. It also makes me appreciate ActionScript. It's come from the other direction, starting out completely dynamic and becoming strongly typed (which bought them a 10x+ performance boost.) Look at a complex ActionScript 3.0 class and a C# class that uses LINQ. From a pure "grammarian" perspective, you will really appreciate AS3.

It's That Time Again

Time for Terry to fan the flames and listen to the ROR... In truth Terry is an avid Rails freelancer. He charges even less than what "average" PHP programmers charge for their hackin', just because he enjoys The Rails Way so much. When he says he is "sick" or "drunk", he's actually busy creating another blog site with Rails (he's up to twenty-four now, and is yet to write a single line of configuration.)

Mmm Frameworks...

Java guys love frameworks. Instead of solving problems, we'd much rather build things to help others solve problems. We feel like we've accomplished so much more that way. There are a number of different, but equally interesting motivations for frameworks.

• Make things easier ... This is the one we're all the biggest fans of. Ain't it great when a framework turns hundreds of lines of code into a dozen? That's why Rails is so popular. There is tremendous tangible evidence of what the framework is doing for.
• Incremental improvement ... We've all got our favorite frameworks, and we always wind up finding the warts in them. You inevitably find yourself saying "the guys who wrote this framework should've just done X, Y, and Z. Then it would be perfect." This leads to somebody doing X,Y, and Z. You could probably fork, but it's so much more glamorous to claim your own territory. All the Struts clones like Spring MVC and Stripes are great examples.
• Port ... A lot of frameworks are just ports of other frameworks from other languages: NHibernate, Grails, even Cake for that matter. Sometimes it's somebody's way to prove that thier language is still better than that other language, or maybe they've just been forced to write in some other language and miss their favorite framework.
• Solving hard problems ... These are the least glamorous kind of frameworks. They take on really hard problems and try to solve them, or at least make some progress. There's no Hello World fluff in these frameworks. They may not be easy to use, heck they might be really hard to use. Google Web Toolkit is a pretty good example of this kind of framework, though it also seeks to make some things easier (a la #1.)

What do you look for in a framework?

Powerset on Rails

Like a lot of folks, I've been curious about Powerset, the company promising to revolutionize search via natural language queries. I got an interesting email from them today. Here's an excerpt. All emphasis (bolds and italics) is from the original email:

I'm happy to announce that we are, in fact, launching our front-end on Ruby.

Cool, huh? For everyone's sanity (and in avoidance of some of the flame wars to ensue), do note that we are going to be using Ruby (the language) but not necessarily Ruby on Rails (the web framework).

Why Ruby?

1. We've already got the brains

2. Ruby is already being used throughout the company

3. We're not worried about scaling

This is obviously an unusual broadcast. Do most potential users of Powerset care what programming language its front-end is written in? So why send out this email. It all comes down to reason #3. We're not worried about scaling. Heh heh.

Why all the fuss? Rails can scale, right? The email goes on to outline how they've talked to the Twitter guys who told them not to worry about the problems they had and go for Ruby. They also explain how their system is simpler and they won't have the same problems that Twitter had.

This is just too funny. Basically they have a bunch of Ruby developers (see reasons #1 and #2) who want to do the front-end in Ruby. I'll go as far as to guess they really want to do it using Rails, but they haven't been able to win that argument yet (hence the disclaimer about it.) Yet, their management is so uncomfortable with this that they had to go and do a broadcast email apologizing-- err I mean explaining why it's ok for them to use Ruby.

I can't imagine a worse endorsement about a language than this! Seriously, if they had decided to write their front end in Java, PHP, C#, Perl, Python, etc. would they have felt the need to publicly defend their decision? Are they going to send out emails about their choices of databases, operating systems, web servers, etc.? I think not.

It's a sad day for Powerset, but an even sadder day for Ruby and Rails.

Twitter Slowness Explained

Now I know why Twitter is so slow. It was built using Ruby on Rails. That explains so much.

GWT, Eclipse, and JUnit -- Rants

I love the ideas behind the GWT command line tools. They remind me a lot of Ruby on Rails. They seem to have some surprising shortcomings though. The projectCreator works pretty good for creating an Eclipse project. However, it doesn't include the gwt-dev-.jar (for example gwt-dev-windows.jar) in the classpath of the project. So you can't launch in Hosted Mode because the executable class is in that jar. Thus you can't use the Eclipse debugger either. If you add the jar to your project classpath, it seems a little better. You still need to configure the run profile, similar to how the -shell script does. Seems like these are obvious things that the projectCreator could do.

The junitCreator seems even worse. It needs a GWT module name, but none of the artifacts created by the applicationCreator or projectCreator contain this. The .gwt.xml file has the module of course, but not it's name. It took me some trial and error to get this right. Even when I did, I could only launch my unit tests using the generated command line tools. I could launch these files directly from Eclipse, but I couldn't launch the unit tests using Eclipse. Thus I could not attach Eclipse's debugger.

I'm sure there's a way to do this. I'm sure that either I 1.)didn't use the right junitCreator command option, 2.) need to configure my project differently, or 3.) need to configure my run/debug profiles differently. Whatever this case, this is all very un-Ruby on Rails like.

Oh, one last complaint. The projectCreator has an option for generating an Ant file. That is borderline useless. The build file only builds a JAR and does not include the gwt compiler as part of the build. Guess what, if you're using gwt, you're building web applications. You don't need a JAR you need a WAR, and you need it to include all the web files, i.e. all that gwt-generated JavaScript. You need a web.xml file, which gwt knows how to generate (it creates one when you launch web mode.) WAR files have a very standardized structure, so this should not be very hard. Just package up what gets deployed to the bundled Tomcat in web mode.

Update: Strangely I don't have a lot of these same problems when I run everything on a Mac. No idea why, since even though the command line tools are platform specific and some of the runtime is platform specific, one would think that the underlying Java code that creates the projects, artifacts, etc. is pretty much the same.