Chad Fowler did a presentation last month that I happen to be listening to at the moment. He's talking about his "evolution" from a Java developer to a Ruby developer. He talks about the various XML files you have to edit when doing J2EE, the number of lines of code that's needed to do just the simplest things in Java, etc.
What I find so surprising is that some of my recent comments seem to be echoing his statements. Unlike him however I was already on the path to trying to simplify my Java development and Rails has simply dropped in a great big exclamation point. Web application development doesn't need to be the morass we suffer through in Java. Ruby can make it fun and Rails can make it so easy to do. Geez now I'm starting to sound like an evangelist too! Oh well I use a Mac too... maybe it's in my DNA...
Monday, February 27, 2006
Sunday, February 26, 2006
Hibernate vs ActiveRecord
Over the last 2+ years I've grown quite accustomed to the facilities of Hibernate (one of the most popular Java object-relational persistence frameworks). And before that I used TopLink for a couple of years. So now when it comes to my work with Ruby on Rails I have some pretty high expectations.
The out-of-box experience with Rails' persistence framework is undoubtedly different but similar enough to Hibernate to make life fairly comfortable. But recently I started watching the SQL that gets generated from Rails and decided I'd like to optimize them a bit. But unfortunately that isn't as easy as everything else in Rails. I found this article at TheServerSide that sums things up pretty well. I think Rails comes out on the losing end. Now the question becomes, are the things you lose worth the things you gain?
The out-of-box experience with Rails' persistence framework is undoubtedly different but similar enough to Hibernate to make life fairly comfortable. But recently I started watching the SQL that gets generated from Rails and decided I'd like to optimize them a bit. But unfortunately that isn't as easy as everything else in Rails. I found this article at TheServerSide that sums things up pretty well. I think Rails comes out on the losing end. Now the question becomes, are the things you lose worth the things you gain?
Monday, February 20, 2006
What I don't have to know
I was thinking recently about how someone with no knowledge of Java or Rails web development would choose which of the two technology stacks to learn. Then I started comparing the lists of technologies on both sides.
First let's start at the View: In Rails we take standard HTML and embed Ruby to dynamically generate the content. In JSF-flavoured JSPs on the other hand we substitute HTML tags with custom JSF tags. You must also know JSF EL (Java Server Faces Expression Language) because it is used heavily in the JSF tags.
Secondly, the Controller: In Rails, controllers are written in Ruby. In JSF the controllers are thankfully written in Java but in order to make them work you have to configure the dependency injection framework with XML. Your JSF XML file must conform to a particular DTD. Now if you also believe in the value of dependency injection frameworks you may want to use Spring. Spring isn't mandatory, but it's popular enough to be part of a typical Java stack of technologies. Unfortunately it requires it's own XML DTD.
Finally let's move onto the Model: In Rails we use Ruby to define our model. The naming convention is usually sufficient to allow ActiveRecord to determine what classes map to which tables. We typically use snippets of SQL to tell ActiveRecord how to fetch data from the database. In Java, Hibernate is the common persistence framework choice. In Hibernate another XML DTD tells the framework how to map the classes to the tables. But since people grew tired of maintaining so much XML they turned to XDoclet. And since that became so popular there are now Java 5 annotations that allow you to annotate your domain model wth mapping metadata. Currently you can use any of the three choices. Hibernate also uses its own query language, HQL, to instantiate objects from the database. This query language is based on SQL and has quite a few benefits but is yet another syntactically different language to learn.
So let's add it all up. To do Rails web development you need to learn:
- For the View you have JSP (Java Server Pages) vs ERb (Embedded Ruby). (We'll assume that (X)HTML, CSS, & Javascript are a given knowledge requirement regardless of framework choice.)
- For the Controller you have JSF (Java Server Faces) vs ActionPack
- For the Model you have Hibernate vs ActiveRecord. (Since both of these technologies are Object Relational Frameworks we'll assume that relational database knowledge, including SQL is a given requirement regardless of framework.)
First let's start at the View: In Rails we take standard HTML and embed Ruby to dynamically generate the content. In JSF-flavoured JSPs on the other hand we substitute HTML tags with custom JSF tags. You must also know JSF EL (Java Server Faces Expression Language) because it is used heavily in the JSF tags.
Secondly, the Controller: In Rails, controllers are written in Ruby. In JSF the controllers are thankfully written in Java but in order to make them work you have to configure the dependency injection framework with XML. Your JSF XML file must conform to a particular DTD. Now if you also believe in the value of dependency injection frameworks you may want to use Spring. Spring isn't mandatory, but it's popular enough to be part of a typical Java stack of technologies. Unfortunately it requires it's own XML DTD.
Finally let's move onto the Model: In Rails we use Ruby to define our model. The naming convention is usually sufficient to allow ActiveRecord to determine what classes map to which tables. We typically use snippets of SQL to tell ActiveRecord how to fetch data from the database. In Java, Hibernate is the common persistence framework choice. In Hibernate another XML DTD tells the framework how to map the classes to the tables. But since people grew tired of maintaining so much XML they turned to XDoclet. And since that became so popular there are now Java 5 annotations that allow you to annotate your domain model wth mapping metadata. Currently you can use any of the three choices. Hibernate also uses its own query language, HQL, to instantiate objects from the database. This query language is based on SQL and has quite a few benefits but is yet another syntactically different language to learn.
So let's add it all up. To do Rails web development you need to learn:
- Ruby
- the various Rails APIs (e.g., ActiveRecord & ActionPack).
- Java
- JSF tag libraries
- JSF EL
- JSF's XML DTD
- Spring's XML DTD
- Hibernate's HQL
- Hibernate's mapping DTD or XDoclet or Hibernate Java 5 annotations (and the DTD for configuring the framework)
- The DTD for web.xml.
- The APIs for Spring and Hibernate and JSF
- (And I didn't even mention EJBs)
Thursday, February 16, 2006
Manifesto
Everyone has a manifesto nowadays. I just read an interesting entry at the "Creating Passionate Users" blog that pointed to the the 37signals manifesto. Both recommended reading.
Sunday, February 05, 2006
Patterns
Christopher Alexander says:
Example 1. The Data Access Object was originally created to hide various data access APIs (LDAP, RDBMS, ODBMS, XML, EJB, etc.) behind an interface. But in reality most applications use a single data access API, and it's usually a relational database. So if you already use something like Hibernate as your data access framework, is it really necessary to wrap the data access in yet another class? Hibernate already abstracts you from the specifics of the target database (e.g., SQL Server, Oracle, PostgreSQL, etc.) Your queries are usually created in HQL and are written in the terms of your object model not the data model, so why add another layer that just delegates to Hibernate? Think about it, how many of your DAO methods look like "return session.getNamedQuery("someName").list();".
Example 2. The Data Transfer Object was originally conceived when Entity EJBs were in vogue. Because you wanted to use course grained data access and eliminate network traffic you'd package up your data and pass it over the wire in a DTO. But in a world where you're using something like Hibernate in the same VM why incur the overhead of DTOs and the marshalling they require. Hibernate can give you a domain object that you can disconnect from the Hibernate session and work with independently. Secondly DTOs are horribly brittle. If you change a domain object chances are pretty good you'll have to change a DTO.
I'm not saying the two patterns I used above are necessarily bad, it's just that they don't need to be used in every single case. People should look to patterns when they discover a problem with the way things are being coded. Remember the old agile mantra "Do the simplest thing that could possibly work". Don't try to build the most complex solution with every conceivable pattern. Instead think of building the simplest most elegant solution with the fewest lines of code. The people who have to maintain your code will thank you. Well okay, they might not thank you, but maybe they won't be cursing you every hour either ;-)
Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution ...So why is it so commonplace to use patterns where a problem doesn't exist?
Example 1. The Data Access Object was originally created to hide various data access APIs (LDAP, RDBMS, ODBMS, XML, EJB, etc.) behind an interface. But in reality most applications use a single data access API, and it's usually a relational database. So if you already use something like Hibernate as your data access framework, is it really necessary to wrap the data access in yet another class? Hibernate already abstracts you from the specifics of the target database (e.g., SQL Server, Oracle, PostgreSQL, etc.) Your queries are usually created in HQL and are written in the terms of your object model not the data model, so why add another layer that just delegates to Hibernate? Think about it, how many of your DAO methods look like "return session.getNamedQuery("someName").list();".
Example 2. The Data Transfer Object was originally conceived when Entity EJBs were in vogue. Because you wanted to use course grained data access and eliminate network traffic you'd package up your data and pass it over the wire in a DTO. But in a world where you're using something like Hibernate in the same VM why incur the overhead of DTOs and the marshalling they require. Hibernate can give you a domain object that you can disconnect from the Hibernate session and work with independently. Secondly DTOs are horribly brittle. If you change a domain object chances are pretty good you'll have to change a DTO.
I'm not saying the two patterns I used above are necessarily bad, it's just that they don't need to be used in every single case. People should look to patterns when they discover a problem with the way things are being coded. Remember the old agile mantra "Do the simplest thing that could possibly work". Don't try to build the most complex solution with every conceivable pattern. Instead think of building the simplest most elegant solution with the fewest lines of code. The people who have to maintain your code will thank you. Well okay, they might not thank you, but maybe they won't be cursing you every hour either ;-)
Subscribe to:
Posts (Atom)