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.

Sometimes technology isn't enough

I'm an enterprise java developer.  I love writing scalable servers in JEE land, which usually involve a database back-end.  The current server that I'm architecting has been using the Mysql 5.0 database and we have been amazed with the performance.  Database purists have been bugging me to switch to Postgres because of its rich feature set.  I haven't messed with Postgres since college but I have over 8 years experience with MySQL.  Still, I evaluated Postgres and found it to be a very nice database.  

So if Postgres is a more mature database with a richer feature set why do so many people still use MySQL?  Easy... community and marketing!  While at Borders book store I found 2 full shelves on MySQL, and only ONE book on Postgres.  If you have the money you can get on the phone to MySQL AS support or even have them come out to your business to train/troubleshoot.  I love open source software and both databases can be considered that, but MySQL has done a very good job at creating a service-oriented company behind their offering while Postgres has tried to stay with the purists. 

So my final decision was to stay with MySQL, not because it was the better database, but because if something went wrong I'd have more options on how to get things solved. 

I love EJB3!!!!

So for the last 4 years or so a lot of the development I've done has revolved around J2EE. This means using things like EJB, JMS, MBeans, and usually other goodies offered buy JBoss. I've always liked EJBs, especially the way they remove concerns from the developer like threading, locking, synchronization and clustering. However, I have never liked how hard they are to develop and deploy. Things are so much easier in EJB3. Here is a comparison.

In EJB2.X

To deploy a stateless EJB in 2.1 you need to write the bean and make sure you extend SessionBean. Then implement a home, make sure you write the correct method! The create your local and remove interfaces and place the correct methods you want to expose in both EXACTLY as they are in the bean definition. Then you need to write 2 very complex xml documents telling the application server how to deploy and manage your bean. Then package it up into a jar, place it in an ear and deploy.

Now to access the bean you need to create a InitialContext. Then do a lookup on the bean and get the home method. Now use the home method to create an instance of the been itself. Now you can use it.

In EJB3

Write a pojo bean with the business methods you want. Have it extend a local interface and have it override methods in that.

Place the @Stateless annotation on your bean telling the app server this is a stateless bean.
Package it up in an ear and deploy.

To access a bean, if you are in another ejb3 just annotate the member variable with:

@EJB
MySessionBean bean;

And when that bean is created it will also create an instance of your bean and inject it!

Now you get the power of EJB with the simplicity of writing plain old java! I love it! For more information you can go to JBoss or get this really great book.


Happy Coding!

ACM World Programming Competition

The 2007 ACM World programming competition just wrapped up and they have released the problem set (solve it if you can). This holds a special place in my heart because at Baylor I worked for Dr. Poucher, who is the chair of the ACM contest. While most of the competitors at this level are light years ahead of me, its always fun to look around and see what they solved and how they did it. Enjoy.