Thursday, August 31, 2006

What is Enterprise Software?

What is "enterprise software"? And the follow up question what is an "enterprise software developer"?

The reason I ask is that I've been thinking about the Java vs Rails question again and the reaction I get from my fellow Java developers when I talk about Ruby and Rails. Generally, they turn their noses up. Ruby doesn't have the breadth they say, it's immature, it's slow, it doesn't scale, it's not an "enterprise" solution. So what exactly are they talking about?

"Breadth": Java has it and Ruby doesn't. There I said it. And quite frankly I agree with it. If I need some oddball service in my app, I can probably find an open source Java framework to help me out. I may not be so lucky in Ruby. But on the other hand do I care? Not really. If I'm building a web app (which describes nearly every single Java project I've worked on) then I don't really give a hoot about most of the stuff that's in Java. As a matter of fact Ruby's ability to create domain specific languages (DSLs) is the power that Rails exploits in its framework, allowing me to express the complexities of my projects very succinctly. It's not about writing gobs of code it's about efficiently expressing a maintainable solution to a problem in as few lines of code as possible. And this is where Ruby and Rails succeeds.

"Ruby/Rails is immature/slow": While it's true that Ruby's been around a long time it certainly hasn't had the commercial success that Java enjoyed and therefore it hasn't received the research dollars to improve it's language runtime. However Rails is getting a lot of attention and by extension so is Ruby. Ruby is in the early stages of running within the .NET CLR and Java Virtual Machine and by the sounds of things Ruby 2.0 has some virtual machine tricks of its own. So at that point at least the discussion of performance can be evenly leveled at all the virtual machines of the world.

Immaturity has also been expressed to me in terms of a lack of an IDE. While I lament the inability to easily refactor my Ruby code as easily as I refactor my Java code with the assistance of something like Eclipse, I console myself with the knowledge that refactoring tools in the Java world are relatively new too. It wasn't that many years ago that I was doing this the hard way in Java. Personally I think this particular complaint is pretty weak. I think developers who are clutching on to this one are doing themselves a real disservice. If nothing else they are depriving themselves of a fresh perspective to object relational mapping and web development because they don't have all the fancy tools.

"Scalability": Well that's a tough one to tackle because of the differences in strategy between Java and Rails. Java likes distributed shared caching (think EJB). Rails likes a Shared Nothing Architecture (SNA). So which is better? Well both have their successes. But to me, the SNA architecture is simpler to understand, simpler to implement and well-proven by the Googles of the world. Fewer moving parts certainly attracts me. There's less to go wrong.

"Enterprisy": Well I dunno how to address that one at all. Because first of all, I don't know what the term "Enterprise" means. I've developed a lot of applications for a lot of users who believe their apps are critical to the success of their business. So does that mean I've developed "enterprise" applications and as a result am an "enterprise developer". Maybe? So am I qualified to say whether or not Rails is ready for the enterprise? Maybe... maybe not. But in any case I can say that I think the IT shops I work for could definitely benefit from Ruby and Rails. I've seen a lot of crazy Java solutions. They tend to be overly-complicated and inconsistently designed and constructed. There is way to much configuration, way too much thinking about "what-if" and not enough thinking about keeping it DRY. Rails comes with a lot of opinions about how things ought to be done and if you can just accept them and go with the flow, you can be very productive.

But it's funny, the "enterprises" that could benefit the most from this technology are probably the people who will be the last to adopt it. Enterprises are big and difficult to steer. Once they get some momentum in one direction, it's hard to get them off that path. Take for example my latest attempt to move from Java 1.4 to Java 1.5. You wouldn't believe the number of departments and the amount of bureaucracy I have to cut through to try and get this approved. All I want to do is use the latest version of Java that was released two years ago so I can take advantage of it's language features so I can write cleaner, more maintainable code. What are the chances that this particular enterprise will ever use Rails? And they claim they're an agile development shop too. LOL.

Thursday, August 24, 2006

Watch that SQL!

Long before I used object relational mapping tools like Hibernate or Toplink in Java or ActiveRecord in Ruby on Rails I used to write a fair amount of SQL (some real nasty queries too!). And in a lot of the shops where I worked it was standard practice to create an explain plan just to make sure that the database could execute the SQL efficiently. If it couldn't, I would dutifully restructure the query, add indexes, or go ask for some DBA help.

But nowadays in this wonderful land of ORMs people just let the framework crank out the queries and never ever look at them. To me, that's just plain wrong. If you're using Hibernate turn on the logging. If you're using Rails just go take a look at the development.log file and go watch what's going on! You may be surprised.

I started a new job a few weeks ago and just wanted to see what Hibernate was doing. And lo and behold, a JSP page was causing 69 queries to run in order to generate a simple list of rows from a table. The main problem was that every lazily instantiated relationship for each object in the collection was being traversed after the initial fetch.

So what could have been done? Well in this case, Hibernate has several options:

  1. Hibernate's query language is quite expressive and something like select e from Employee e left outer join fetch e.department d would have caused both objects to be fetched in a single query.
  2. The fetch keyword I used in the first example has one limitation (for good reason too). It can only be used to fetch one collection. So take advantage of Hibernate's caching to prefetch related objects instead. Hibernate will associate any newly instantiated objects with objects that already exist in cache. Even if you're not using something like EHCache you still have some caching built into your session so don't discount this tip right away.
  3. Use a DTO-like object and go old-school and only select the fields you need with something like: select new EmployeeListDTO( e.firstName, e.lastName, d.name) from Employee e left outer join e.department d
Now if you're using ActiveRecord you don't have the double edged sword of a cache so the second option I described above isn't available, but the other two are possibilities:

  1. Employee.find :all :include => :department
  2. Employee.find_by_sql "select e.first_name, e.last_name, d.name from employees e left outer join departments d on e.department_id = d.id"
The second option shows one distinct design difference between Hibernate and ActiveRecord. Hibernate gives you a SQL-like query language but does away with having to specify join constraints because that information is in the mapping metadata. Whereas ActiveRecord says why reinvent SQL and just let's you have at it. Oddly enough I like both approaches...

Finally, be sure to use the ad-hoc query tools at your disposal to try out your queries before you embed them in your app. If you're using Hibernate 2.x then go get a copy of Hibernate Console (part of the Hibernate Tools). It can be a bit of a pain to get it setup but I really appreciate being able to work out the query before running it as part of my app. If you're using Hibernate 3.x and Eclipse then go get the Hibernate Tools plugin. If you're using Ruby on Rails then you already have all the tools you need. Simply drop to the command line, cd to your project directory and then type script/console. Open up a second shell window (if you're running unix) and type tail -f log/development.log from your project directory and you can instantly watch what SQL Rails generates when you execute those find methods.

Now go out there and watch what you're doing for database access! Don't let all that ORM goodness make you lazy.

Tuesday, August 15, 2006

Should Rails come with a Warning Sticker?

I've been a Java Developer for about 9 years, and maybe my interest is finally waning or maybe the lack of productivity is starting to get to me but maybe, just maybe, something else is has come along that has shown me a better way... I suspect that something is Ruby on Rails.

Now I'm not saying Rails is perfect or that Rails is an appropriate solution for every problem but as I said to someone else last week, it amazes me how many of the things that I've written these past 9 years would be appropriate for Rails.

One of the things that tends to annoy me is that every Java development shop is maddeningly different. They all have a different combination of open source and commercial frameworks. I've dealt with Struts, Hibernate, Spring, JSF, Tomcat, OC4J, Spring, JBoss, Weblogic, TopLink, EJB, JSP, JSTL, DOM4J, JAXB, Swing, Tiles, Facelets, etc, etc. Now while some will say (and yes I'm sure I've used this argument in the past) that the Java community is vibrant and constantly pushing the state of the art, sometimes I wish there wasn't so much choice. Some consistency would be quite nice.

Secondly, why does each shop have to have its own collection of "clever" Java developers who feel they need to endow the poor developers that follow them with some fascinatingly weird framework of their own? Why can't these guys just build a straightforward solution with the frameworks they've chosen? They all seem to feel this overwhelming urge to hide what they're doing behind layers and layers of abstraction, abstraction that usually involves one implementation. For crying out loud if you're going to abstract away Hibernate's API behind your own, you better have a darn good reason and it better not be "just in case".

Rails is a breath of fresh air. David Heinemeir Hannson has said he's very "opinionated" and that may tend to put some people off, but the strength of his character has allowed a single vision to shine through. Rails isn't littered with a pile of abstraction because it's not needed. It's simple, it's straightforward and it's productive. As a Java developer someone should have told me that Rails was so revolutionary. Now when I write Java web applications I'm constantly thinking about how much better it could be with Rails. Is the grass just greener on the other side? Maybe, but either way Rails should have come with a warning sticker. It's addictive.

Tuesday, August 08, 2006

Rails and Apple together in Leopard

David Heinemeier Hannson notes in his blog that Ruby on Rails will ship with the next major release of the Mac OS, Leopard (a.k.a., Mac OS 10.5). As a Mac user and Rails admirer I have to say that these two seem to go so well together... Not sure how to explain that... It's just that they both have a great aesthetic, and are two of the most elegant software products I've used in years.