lesscode.org

As a side note to the last post about the Rails and J2EE article, it’s interesting that the title of that article was Ruby on Rails and J2EE: Is there room for both? when there was barely an official J2EE technology mentioned. Struts and Hibernate weren’t J2EE technologies the last time I checked - they evolved in real life hacker communities under liberal licenses, not under a vendor sanctioned expert committee. Perhaps the original comparison that used cross vendor, JCP approved specs like PO Servlets, JSP, and EJB was just too much to bare?

I’m not trying to be a troll or anything, I’m just wondering whether others find it interesting that the popular Enterprise Java technologies today aren’t part of J2EE at all.

People wonder why there’s a push for Sun to free Java, I don’t. I personally don’t give a shit what they do with it but when you see the results of one of these communities in action it’s hard to advise against it from a technical standpoint.

I have to admit that as a Python guy I sometimes have a hard time reporting on all the recent Rails press (and I’m doing something about that, I promise). But hey, those guys are kicking ass and have made huge advances in getting the rest of the industry to wake up to the benefits of not only dynamic languages but also some of the concepts and practices that are common to the wider community. The old walls are starting to come down and its in no small part to the Rails community. Big ups and all that.

I think its interesting that of all the really inventive material the Rails guys have thrown together (movies, books, and now a friggin podcast), you just can’t beat a public display of less code, such as the one you’ll find in this IBM developerWorks article published a few days ago by Aaron Rustad:

Hibernate (Java State of the Art)

<hibernate-mapping>
  <class name="models.Order" table="ORDERS"
         dynamic-update="true" dynamic-insert="false"
         discriminator-value="null">

    <id name="id" column="id" type="java.lang.Long" 
        unsaved-value="null">
        <generator class="identity"/>
    </id>

    <set name="items" lazy="false" inverse="false"
         cascade="none" sort="unsorted">
         <key column="id"/>
         <one-to-many class="models.Item"/>
    </set>

    <property name="name" type="java.lang.String"
              update="true" insert="true"
              access="property" column="name"/>
  </class>
</hibernate-mapping>

public class Order {
    private Set items;
    private String name;
    private Long id;

    public Long getId() { return id;}

    public void setId(Long id) { this.id = id;}

    public Set getItems() { return items;}

    public void setItems(Set items) { this.items = items; }

    public String getName() { return name; }

    public void setName(String name) { this.name = name; }
}

ActiveRecord (Rails)

class Order < ActiveRecord::Base
     has_many :items
end

That’s hard to ignore.

I just hope that with all the recent attention paid to the Rails community those guys keep in mind that we all stand on the shoulders of giants and that all roads eventually lead to Lisp <ducks>

This Joel on Software Thread shows that the notion that “LAMP can’t scale” is alive and, apparently, still quite popular.

The big issue I have with rails scalability is admittedly based on some prejudices I have about large scale webapps. Rails doesn’t really have a model of a stateful server, primarily because there is no threading, connection pooling, etc. You have one lighthttpd/apache/whatever thread, and it has one rails instance, which has one db connection, etc.

Oh, wait, that comment is just plain old disinformation and/or ignorance of how these systems actually work.

This comment does a far better job of representing the popular your-stuff-doesn’t-scale mindset:

scalability is an important issue when choosing a development environment. If it is not scalable, you made the wrong decision and you will be rewriting your app into something that is scalable once you start getting customers. And this is just the wrong time to have to start worrying about rewriting your app. It is always better/cheaper/faster to do it right the first time rather than plan for a rewrite in a new environment once you start getting busy.

Required until proven unnecessary in all its glory.

David has a nice rebuttal that sums up nicely the place I think many of us have reached with regards to the scaling issue: it’s a boring problem that’s been solved for years. Maybe we should tell others?

Along with the usual set of “that’s not for the enterprise” posts, there are also some insightful posts. I’d encourage you to join the discussion, especially if you have a cluestick similar to Ged Byrne’s:

I think I should start posting on all those enterprise server forums with comments like ‘I’m concerned that this won’t scale down very well. Could a team of 3 provide 24/7 support while extending functionality? We only have a couple of thousand users and at the rate the market will accept a bigger team would not be economical. The thing is, we 3 really want to do this rather than ending up as corporate drones wasting our existance in a cubicle.”

Anyway, here’s something IBM/Zend or other members of our community toating around a fair amount of spare cash and resources could do to help the poor hippies out in gaining a bit of acceptance: slay this cow once and for all, formally, by setting up an environment to simulate the kinds of “enterprise class” loads we’re seeing in even the most demanding environments. You can use David’s basic setup or perhaps this one from circa 2000. If, upon being weighed we’re found wanting, we’ll find a way to fix it like we’ve been doing forever. But we would feel more comfortable if the burden of proof was placed appropriately. Our repeated attempts to show the scaling capabilities of LAMP/friends seem destined to be repeatedly deflected by the Enterprise Class Distortion Field.