Active record and those darn caps

Due to my recent illness I've had a lot of time to myself in doors. So I've been looking a lot of technologies that have been on my watch list. When looking at ruby's active record I can't help but like and hate it at the same time.

One thing Ruby-lovers pride themselves on is "do as little as possible an get as much for free as possible." Take the following active record example:

class Person < ActiveRecord::Base 
  belongs_to :company 
end

class Company < ActiveRecord::Base 
  has_many :people 
end

Gavin King, the creator of Hibernate ORM has an interesting comment about this :

At this point, most developers are thinking um, ok, so how the hell am I supposed to know what attributes a Company has by looking at my code? And how can my IDE auto-complete them? Of course, the Rails folks have a quick answer to this question Oh, just fire up your database client and look in the database!. Then, assuming that you know ActiveRecord's automagic capitalization and pluralization rules perfectly, you will be able to guess the names of the attributes of your own Company class, and type them in manually.

Somehow, excitement about the Ruby language has warped their perceptions to such an extent that these people actually believe that this is a good thing!

I completely agree. Ruby plays some magic and when a record is pulled from the database ruby inspects it and adds the needed fields to these "active record" ruby classes. While this is neat and keeps developers from having to plan out their ORM entities I can't help but see the possible problems with doing this on a very complex schema AND entity model.

crap in the fan

Obie Fernandez, a Ruby evangelists, created a post saying why java is inferior to anything ruby and ruby on rails. Of course being me I can't pass this up.


http://www.jroller.com/obie/entry/top_10_reasons_why_java

Obviously even a ruby fan can read this and see that Obie really wanted to do little more than spread FUD and get his panties in a bunch (and I do say panties because anyone who wines like that must be wearing pink-lacy panties over his squirrel-sized package).

However, his morning-after post showed that he does have some reasoning within him:

http://www.jroller.com/obie/entry/what_subtelty_and_suck_ass


I've been doing a lot of "battling" lately with ruby evangelists about why I still do a lot of my deployments in JEE. I think he has a good quote here:

"Like Gavin pointed out, you can't do an app with thousands of model classes in Rails. Okay, but I'm really not trying to say that you should try. Right now, I personally have no interest in working on those kinds of monstrosities, but to each his own. "


I completely agree with this. Ruby on Rails is great for small, database driven apps that have the functionality of CRUD. Go beyond that and its simply too much heavy lifting and you need to look into something more heavy-weight, like JEE. Most ruby developers I talk to don't really want to tackle the large enterprise projects, they want to do what Rails was meant to do, small database driven websites.

What this is really about is choosing the best tool for the job. Some projects I would love to do in something like rails. Other projects I think I would spend more time trying to get around rails to solve the problems and I need a framework that can handle those requirements.


Of course after the above post the java community fired back. While I'm obviously biased I sort of feel like this one was much more intelligent.

http://www.javalobby.org/java/forums/t101687.html

JMS.. the fruit rollup of non-transactional resources

Everyone knows I love JMS. Almost all of my deployments take advantage of it and rightly so. Who couldn't love transactional, durable, scalable asynchronous processing.

One thing JMS is great for is wrapping resources that aren't JTA so they can "participate" in global transactions. Notice the quotes because the correct way of doing this would be to write your own JCA connector, but sometimes we don't have 3 months to read the spec.

A good example is if we want to save some stuff to a database and them write a file. If we were to do the following sudo-code, assume this is in a stateless session bean:



@TransactionalAttribute(REQUIRES_NEW)
public void doSomething()
{
Person p = new Person();
p.setName("Joshua");
entityManager.persist(p);

File f = new File("myStuff");
// write stuff to the file.
}



We actually don't know if our transaction succeeded until after this function has been executed. But wait... we have already written a file... Oops!

Enter JMS. Put this file-write code in a message-driven bean and have the above method pump a message to its destination and the message won't get sent unless the transaction completes.

Now there is one last thing to think about... what if the file write fails. Well, you have 2 options.

1) make sure the mdb rolls-back its transaction so the message will flow into a dlq and do your own compensation.
2) just set the destination to not use a dlq. This means if the message will keep being delivered until it can write a file. Not really ACID compliant but you won't loose any files.

scripting here I come

So I'm ashamed. I've been putting off learning a new scripting language for way too long. Commence beating me with a rubber duck now.

So why do I even need to learn something like this? I consider myself a pretty good C++ and Java programmer. On top of that I feel like I can fully embellish the heavy-lifting fruits of JEE when it comes to building robust servers. And unlike others in the development world I'm just not turned on by syntactical candy like "no accessor methods required."

The main reason is I do think dynamic scripting languages have a place in my deployments and I like some of the things they are doing in the web-tier world. While the interface-driven language characteristics makes Java a powerful player in the services/backend world it can sometimes be a bit tedious when pumping out web flows. So for the time being my services-tier will always be the heavy-weight JEE server. But I need to learn something smooth to fit on the front.

So what are my options? Well the talk on the town is Ruby. I wrangled with this in my previous posts and I'm simply not a fan. Lets forget for a second that its so slow it makes Java in the early 90's look good. My issue is its almost diabetic on syntactical candy. Who cares if you can do 50 things with 3 command words, I still can't understand it! And the parenthesis rule drives me crazy. Either make the developer use them or don't. Because of this I feel like the Ruby community is full of language evangelists who's only defense of Ruby is
"but its so agile". Remember, a scripting language is suppose to be easier to read/understand than embedded C. And personally I think the Rails framework has some serious functional issues.

Groovy is a Ruby-like language that gets compiled to the JVM. I like it because they took the best of java and ruby and blended them together. I'll keep this in my bag of tricks but I'm not sure this is the complete answer. And lets face it, I can't spend my life in a VM.

Python is a little different for me. My co-worker is a big python guy and I've been listening to what he has had to say. I'm a picture-drawing sudo-code-thinking abstract engineer. If we have a design session and you start throwing byte orders out at me I'll get lost until a dry erase board is brought in. Python seems to really target people like me with their sudo-syntax approach. Plus I like some of the more java-like features they have annotations. Also, compared to Ruby their plugin bank seems to be much more full. And most of all when I ask python people why they like it they can actually tell me things about the language they like.

So Python it is! My next few posts will be how a Java and JEE lover tames the rabid python.


[UPDATE] First note about python.. the main website is python.org, not python.com. Lets hope that doesn't show up in the web logs at work.