Call for Action

I've worked on a few open source projects and I have nothing bad to say about any of them. If there is one shortfall in the open source world its that everyone wants to be the hero. Everyone wants to "start" an open source project. But far less people are willing to join existing projects and take them those last tedious few steps necessary to truly make them useful. These steps usually include bug fixing and documentation. This is why sourceforge has hundreds of thousands of projects that will never be used.

At RubyConf Charles Nutter issued a "Call for Action" asking people to help take things those last steps, both on documentation of the new Ruby runtime AND bug fixing for JRuby. So if you are interesting in doing something new, try and help him out. Its the little things that makes most open source projects great.

Charles Nutter's Call to Action Post

JRuby and Seam

After spending a month or so playing with Ruby and Rails I'm really not happy with Rails.  I build systems that have to scale and Rails has some serious issues when it comes to that.  Its great for simple CRUD apps, but if you need to move outside of that or need to scale its got issues.

I do, however, like JRuby.  I'm also a big fan of jBoss Seam.  It just makes sense to me, use the scalability of EJB3 with state management in web apps.  In JBoss Seam 2.0 you can write your Seam components not only as EJB3, but also in Groovy.  I love EJB3 so that would be my first choice.  But I work with people who really want to use Ruby.  To meet in the middle I've been playing around with integrating JRuby into Seam.  Luckly, Seam is designed well to allow this with some learning curve.  

I'll post more later, but I've got a proof of concept where I can write my view in JSF, and a Seam-managed component in JRuby, which then uses JPA for persistence. 

Dreams of Fuel Cells

I live about an hour from the auto-motive capital of the U.S. (well, the former one at least). The big 3 and the UAW are pretty much house-hold names in Michigan. Most people who know me would testify that I'm not a fan of the U.S. auto industry. From union squabbling to companies who produce non-creative, sub quality products and insist that the reason you should buy them is not because they are better, but because its your patriotic duty.

Even though I rarely achieve this, I always strive to be a creative, forward thinking engineer. I believe that sometimes its not always enough to just solve a problem, but solve it in a fantastic way that yourself and others can learn from. I simply don't see this a lot from the big 3, which is why I drive a Honda.

Tonight I saw a commercial for the new Honda hydrogen fuel-cell car, and I was captured. I felt like I was looking at the iPhone of cars. A company whose industry is as old as some governments refuses to subside into the monotonous productions of U.S. big business and big labor competitors.

I need to do more reading to fully understand what this car is, but it looks like it will hit the road in the summer of 2008. While other companies are just trying to stay a float and squabbling about overtime pay for employee uniform changes, Honda is making history.

http://www.honda.com/fuel-cell/

well-defined api

So from being a java/c++ developer for years I've been taught the importance of exposing well-defined save apis. You expose parts of your api that you think is safe for black-box users to incorporate and abstract/protect the rest. This is usually done by the visibility, security, and overriding features of the language.

For instance, if I have a method that I think its unsafe for any class, including sub-classes to call, I'll define it as private.


Ruby seems to think this isn't important. I can do this:

class Base
def aMethod
puts "A private method";
end
private :aMethod
end

class Derived
public :aMethod
end

In one line the sub class "Derived" was able to change the visibility of the method "aMethod". A little scary when trying to define things like data structure libraries and application frameworks that depend on the validity of certain methods.

Ruby on.... jetty?

So I'm playing around with JRuby, and I think its really cool. The java community has really come a long way and created some great tools for doing enterprise deployments, why should the ruby community spend time backtracking and re-inventing the wheel? The JVM has become a proven execution environment and with an open byte-code standard its trivial to compile to it (well not trivial, but do0-able).

So with JRuby you can get the syntactial sugar of ruby with the heavy lifting of such java services and JMS, hibernate, and even servlet containers. Currently Ruby on Rails uses either WeBrick or Mongrel as their web server. Both are written in ruby and, well, slow. If there is one thing the java community has done a good job of the past few years its build fast and reliable servlet containers (just look at tomcat and jetty).

What I'm wondering is how hard would it be to replace mongrel/WeBrick with jetty in a JRuby on Rails app? Just think of the performance gain with Jetty's NIO engine?

sequel to the rescue

No sooner than I pushed the "post" button on my last post did I find sequel. Its a light-weight ORM in Ruby that looks promising. Does all the association fetching and even has 2nd-level cache support.


http://code.google.com/p/ruby-sequel/

Active Record, the sludge in Ruby

So I've been learning Ruby lately, and being a bug ORM guy I decided to checkout the source for active record and see how it works. There are some very serious issues here. Active record uses the dynamic mixin ability of Ruby to do its work, but that same logic kills itself in performance. To explain myself further I we should compare the active record model with JPA.

JPA
Java persistence architecture delegates all ORM work to the persistence manager, an external library that manages db entities. If I want an entity I ask the persistence manager for it, if I want to save, I do it through the persistence manager. When my app starts up the persistence manager looks at all my entities and my schema and creates the necessary object structure to do its ORM magic. The mapping/querying logic is done once and used by everyone.

ActiveRecord
Active record delegates all ORM work to the entity itself. Entities must know how to query/save themselves and if they are transient or persistent. They do this by mixing in methods to to the ruby-defined entities at runtime and then, when an instance of an entity is instantiated, created the necessary links to do its ORM stuff.

The disadvantage of active record is the function of ORM processes is spread throughout however many entities you have. It becomes hard to do things like locking, transactional caching and even transactional enlistment. If I have a 100 entities, each entity has to be concerned with cache invalidation and managing their relationships.


Until the ruby community either fixes this in active record, or comes out with a JPA/Hibernate -like ORM they will never be in the spotlight. If you talk to any ruby-evangelist they always bring up that Twitter uses RoR. And that is true, but if you read any of their posts to scale Twitter had to remove ActiveRecord from their deployment because it was just too slow.

So I think Ruby is cool but I really don't like active record. Anyone interested in porting hibernate to Ruby???