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.