Raible Designs

Migrating a Rails app to Grails

There's an interesting trend I've seen happening at companies over the last year. More and more, they're experimenting with Rails and/or Grails for both prototyping and real applications. I think this is an excellent use for these frameworks as they both are very productive. The reasons for their productivity is simple: zero turnaround and less code.

For a Java-based company that's built their bread and butter applications on Java and been successful with it, both frameworks can be disruptive. Bread and butter applications tend to be large and somewhat difficult to maintain. In my experience, the biggest maintenance headache is not writing code or fixing bugs, it's the turnaround time required to make changes, run tests and build the application to test in your browser. Since Rails and Grails eliminate the turnaround, it's only natural for developers at companies with a lengthy build process to love their increased productivity.

Over the next couple weeks, I'm going to do some experimenting with porting a Rails application to Grails. Why? Because I think companies are going to have a difficult time choosing between these two frameworks for rapid prototyping and (possible) production deployments. While both frameworks are great for prototyping, the last thing most developers want to do is throw away the prototype and develop it with something else. They want to continue to enhance the prototype and eventually put it into production. With Rails and Grails (and many others), it's possible to build the real application in a matter of weeks, so why shouldn't it be put into production?

For most Java-based companies, putting a Rails application into production is unfamiliar territory. However, a Grails application is just a WAR, so they can continue to use all the Java infrastructure they know and love. So for companies with an established, tuned and successful JVM infrastructure, does it really make sense to use Rails over Grails? The only thing I can think of is language reasons - there's a lot of Ruby fanatics out there.

So again, the purpose of my experiment is simple: to see if a Grails app can do everything a Rails app can. As for language features and scalability, I'm not really concerned with that right now. I'm not looking to prove that either framework should be used for all web applications - just certain types.

Has anyone out there ported a Rails application to Grails? If so, are there any gotchas I should watch out for?

NOTE: I realize that Rails can be deployed on the JVM with JRuby. However, I think many companies have existing Java-based tools (logging, JMX, Spring backends, etc.) that more easily integrate with Grails than Rails. I could be wrong.

Bus Project Update

This afternoon, Jeremy Vreeman from Motorworks Restorations stopped by to take a look at my bus. I first e-mailed Jeremy way back in June of last year, so this meeting has been a long time coming. He took lots of pictures and we talked at length about the things I wanted as part of this restoration project. To start with, I'm going to have Motorworks do paint and body, and possibly suspension. Jeremy said they could probably take it out of my hands in March and have it back to me 2-3 months later.

I'm pretty pumped - for a number of reasons. The first is Motorworks seems to be best company on the Front Range to help me make "Daddy's Bus" into my dream car. I realize it's going to cost quite a bit of cash (a full restoration to pristine condition is 50K), but it's something I've always wanted to do. Furthermore, it's not a bad investment (most car restorations are). Jeremy told me about a deal he just saw where a guy sold his restored '59 for 70K. I'm certainly not planning on spending that kind of money this year, but with 15K already into the project, it's likely I'll spend another 30K over the next 5-10 years. The last reason I'm excited is because anything is possible with this bus at Motorworks. Jeremy was telling me about a project they have right now that closely resembles a "Pimp My Ride" episode: flat screens, A/C and even Wi-Fi (I didn't ask why an EVDO card wouldn't work).

I don't plan on selling the bus when I'm done. I hope to drive it during the summer and possibly show it. I think it'd be pretty cool for the kids and I to cruise around town in one of the coolest cars ever. It should be a great childhood memory for them. Hopefully it's not too painful when one of them totals it in high school.

A Positive Wicket Experience

Julian Sinai recently released the first version of his company's product based on Wicket. In A Year of Wicket, he describes the experience (emphasis mine).

I've been working with Wicket for almost a year. We've just released our first product that uses Wicket for the user interface, and so it seems like a good time to take stock. Unfortunately, it's not a public site, it's an installable enterprise product, so I can't show it to you. If you don't want to read further, here's the executive summary: Wicket rocks!

I was hired as the GUI Architect for this project. I came to it with many years of GUI experience, mostly using Swing, but without a lot of web development experience.

Because of my Java and Swing background, I was drawn to Wicket. It maps fairly closely to the Swing model of development. So does GWT, but when I evaluated it, it seemed so different from other J2EE frameworks that I felt it was a step too far. No HTML, and no WAR files, for example. This made my colleagues nervous, who were used to Struts and PHP. Me too, as a matter of fact.

I had done some pretty serious prototyping for another project with Tapestry, and there were certain things I liked, like runtime bytecode generation. But the learning curve was pretty steep. At one point I needed to create a custom component, and to do so I needed to learn about engine services and other arcane things that I felt made the process too hard. By contrast, custom components are Wicket's bread and butter, and they are very easy to build.

I also took a close look at JSF. It seemed overly complex to me, and not much of a departure from the Struts era. It came across as a technology designed by committee, with the combination of several complementary libraries required to get the job done, and there are still too many configuration files.

So we decided to use Wicket.

...

One of Wicket's advantages is the strict separation of design from behavior, that is, HTML from code. While we did not have a web designer on the team who built the HTML (the developers did this), and therefore didn't get any mileage from the separation in that sense, we definitely gained from having all the behavior in Java code, because it gave us all the power of refactoring, compile-time error checking, and maximum reusability. [Read More]

I really like how Julian talks about reasons they didn't choose other frameworks. Beyond that, I think it's important to note that Wicket was a perfect fit for someone with heavy Java and Swing experience. I still think Wicket is a little verbose for Web developers that program in Java (me), but it's unlikely there's very many of those. Building a form in Java seems so much more cumbersome than building it with HTML - but that's probably just me.

FreeMarker vs. JSP 2

I've been doing quite a bit of prototyping with Spring MVC and Struts 2 with both JSP and FreeMarker in the last few months. I'm trying to migrate a proprietary servlet-based framework with a proprietary JSP compiler to something that's open source. There's a couple of important features that the proprietary view framework has:

1. It's expression language allows methods to be called with arguments.
2. Templates can be loaded from a JAR on a remote server.
3. XML in variables is escaped by default.

For #1, I've found this to be impossible with JSP EL or JSTL. I've created JSP functions that allow argument passing, but they don't allow overloading of functions. FreeMarker solves #1.

For #2, JSPs again fail because the templates have to be on the file system or in a WAR. FreeMarker solves this problem as well.

For #3, neither JSP or FreeMarker solve this problem. I realize it can be fixed in FreeMarker by hacking the code - I've done the same with Tomcat and solved it for JSP as well.

So based on the requirements in this project, FreeMarker is the clear winner. Here's some problems that I see with using it:

• No XML escaping of expressions by default
• No compile-time checking of expressions
• IDE support is limited to Eclipse (meaning very little in the way of code-completion)

FreeMarker users - are there other problems you've experienced when using FreeMarker in your applications?

RE: Why Grails doesn't use Maven

Graeme Rocher's in Why Grails doesn't use Maven:

In his post entitled "Grails - The Good, The Bad and the Ugly", Jonas has some nice praise for Grails, his main beef is that it is not built on Maven.

So I wanted to clarify why exactly we chose not use Maven (by default) and the explanation is there for all to see in Jonas' first example of creating a Grails application vs creating a Maven project:

Instead of

grails create-app name

could be just

mvn archetype:create -U\
-DarchetypeGroupId=net.liftweb\
-DarchetypeArtifactId=lift-archetype-blank\
-DarchetypeVersion=0.4\
-DremoteRepositories=http://scala-tools.org/repo-releases\
-DgroupId=your.proj.gid -DartifactId=your-proj-id

My goodness, what a mouthful the Maven example is. There is a common acronym in the open source world called RTFM (read the *ing manual), when a user asks a question on a mailing list and the "experts" respond by pointing them to the place in the manual.

I think Maven's biggest problems are 1) poor metadata in the central repository and 2) the source of metadata in projects (pom.xml).

I believe #1 can be fixed if the Maven guys allow dependencies to be fixed based on user feedback. It's also gotten a lot better in recent years. In reality, maintaining transitive dependencies is hard and I believe Maven has done a good job. In reality, they're the only ones that slurp up transitive dependencies, so the only other option is to maintain the dependencies yourself.

To fix #2, I think the problem is mainly XML and the verboseness of the elements-only pom.xml that Maven requires. Most of the contents of a pom.xml are either dependencies, plugins or exclusions/variances of Maven's conventions. What if Maven's metadata was pluggable? What if XML was only one option? What if you could write a pom.groovy and describe your entire build process in 5 lines instead of 500? That would be very cool.

I'm still a Maven fan, mostly because it's greatly simplified the maintenance of and releasing of AppFuse. When I do GWT, Seam or Grails development in the future, you can be sure I'll try to use Maven to do the development. Why? Because I've learned how to use it and I don't feel the pain that so many others talk about. I also think it really shines on really large projects (builds that produce 30+ WARs for example). An Ant-based system on really large projects can become quite burdensome and difficult to maintain. Not only that, but it's very difficult to maintain a modular build system (where you can build/test/deploy a single WAR) with Ant. In my experience, really large Ant-based systems take forever to process that everything is up-to-date whereas Maven systems depend on each other and require you to keep them up to date. Sure it requires you to be smarter and run "mvn install" on your subprojects, but I'd rather do that than wait 5 minutes for Ant to process everything just to run a test.

You might remember that the main reason I used to prefer Ant over Maven was speed. That was in Maven 1 days. With Maven 2, speed is no longer a problem and I've found it much easier to run "mvn jetty:run" than "ant deploy" and wait for Tomcat to restart. IMO, the perfect development environment is one were you can run a command-line command (or use your IDE to start the server) and code away without worrying about restarts. Seam and Grails offer this environment, but it's unlikely your entire organization is going to use standardize on those frameworks and not have anything else. I think Maven and the Maven Jetty Plugin offer a nice alternative for the rest of those applications.

GWT Presentation with Bob Vawter

Tonight I'm in Mountain View attending the inaugural meeting for the new Silicon Valley Google Technology User Group (SV-GTUG). The good news about this meeting is Bob plans to discuss some of the new features in the GWT 1.5 release. Although it is not available yet, it sounds like they are putting the finishing touches on the 1.5 release and that it will be available soon.

The first ting I've learned is that GWT is actually pronounced "gwit". Bob is a member of the GWT team and he's the only one that's not based out of Atlanta. GWT has a very Swing-like programming model. It has widgets, panels and windows and operates very much like a traditional UI programming API. To create an application, you create a class that implements EntryPoint. Below is an example Hello World application.

One of the really nice things about GWT is that you can easily debug your application in your favorite Java IDE. GWT doesn't prevent you from writing JavaScript - you can insert native JavaScript into your code using a special /*-{ script here }-*/.

When you compile a GWT application, you get a whole bunch of stuff. When trying to develop cross-browser JavaScript code, you often end up with "if soup" to handle the different browsers. GWT does the same thing, but it creates different versions of the application for the different browsers. The naming of these files is an MD5 hash that's bootstrapped by a simple JS file. GWT files are all static and the file sizes are ~40KB/each for the Hello World application.

If you have to write fewer than 100 lines of code, it's likely that GWT will be overkill - you can do it with JavaScript easier. Once you get more lines of code and larger teams, Java's tools do all the heavy lifting. Yes, you can create large applications with large teams with scripting languages, but Java is the clear winner when you have large teams of developers working on projects.

GWT provides a RemoteService for client code and a RemoteServiceServlet for server-side code that you can use to implement RPC calls. For more information, see the Remote Procedure Calls documentation.

At this point, we're 45 minutes into the presentation and it's pretty disappointing. This is likely because there's no presentation and Bob doesn't seem to have any sort of agenda. I think this type of presentation would work well if folks had experience with GWT and were asking lots of questions. However, it seems that most folks haven't used GWT - so the questions (and his resulting answers) aren't very meaty.

One attendee asked about making GWT applications SEO-able. Bob's suggested solution is to continue to use Servlet or JSPs to render the page, but then use GWT to for the user interaction that needs to happen within the page. The RootPanel class has a get(String id) method that can be used to put the GWT application into a particular div or other placeholder.

Google Base and Google Checkout are currently using GWT. There's also a lot of Google internal development that uses GWT. Apparently, there's quite a few applications built with GWT that haven't launched yet.

Has anyone used the Maven Gwt Plugin? It sounds like it might be pretty nice as it contains the GWT compiler with no OS-dependent Google tooling.

The main new feature in GWT 1.5 is Java 5 support. There's also a GWT Incubator that's used to host GWT features that may go into GWT's core. You can view the demos online.

GWT's mission statement:

GWT's mission is to radically improve the web experience for users by enabling developers to use existing Java tools to build no-compromise AJAX for any modern browser.

GWT's competition according to Bob - Visual Studio.

Action Packed Week in California

Morning light on the Golden Gate Bridge
Originally uploaded by TravelnFotog

This week is shaping up to be quite the action-packed week in California. First of all, the MacWorld 2008 Keynote is happening today. This is the event where new Apple products are announced and everyone yawns. I hope they announce some interesting stuff, but I'm not getting my hopes up. The only thing I'd likely buy is a screaming laptop with 8 GB of RAM.

Tonight, there's a presentation on GWT at Google. Since this is only a few blocks from LinkedIn, I'm going to try to make the meeting and checkout the "Googleplex" for the first time.

Finally, tomorrow night a bunch of us are getting together for a Silicon Valley Tech Meetup at The Old Pro in Palo Alto. Start time is 6:30.

Snow White gets Molested

I walked out to Snow White on Tuesday morning to discovered she'd been molested by a thief. In other words, my stereo got stolen on Monday night. It was a fancy one too - navigation system, DVD player, XM Radio and many other bells and whistles. I filed a police report and reported it to my insurance, so hopefully I'll be able to replace it in the near future. For some reason, the perpetrator decided not to take the DVD player that powers the TVs in the backs of the front seats.

While the sounds system is busted, I was pleased to discover this evening that the DVD still powers the TVs and the kids' wireless headphones still work. This should make for a much easier ski trip tomorrow. With ski traffic on I-70, I've spent a lot of time traveling to and from the slopes on the weekends. We hope to miss the morning traffic by leaving early (6:30). However, they don't get out of ski school until 3:00, so we might be smack dab in the middle of the afternoon jam.

With fresh powder in the forecast, I think it'll be worth it. I just hope my knee holds up. I promise I'll go to the doctor in a couple weeks - after a few more powder days.

Denver Tech Meetup: January 24th at 6:30

From the RedMonk Social Planner:

Why our holiday decorations are still up, I couldn’t tell you, but I do have the answer you’re all looking for: the date of the next Denver Tech Meetup. You remember, the Denver Tech Meetup? The User Group without the User Group? But with beers? Denver’s least ambitious monthly(ish) (ha!) gathering of technology workers?

Yes, I’ve failed spectacularly in my ambition to hold these things every other month, as was the expectation back in 2005, but I’ve been a little busy. And as I’m fond of telling our clients, a percentage of something is better than an entirety of nothing, right?

So ignore the inset picture - I posted it merely for nostalgic reasons; two Thursdays from today we’ll convene at our probationary new venue (my bartending friend is now way uptown) and frequent Jabber hangout, the Celtic. 18th and Blake, for the Denver folks in the audience. Still very easy walking distance for yours truly, not to worry.

Let’s you and me cram as many Tech Meetups in as we can before I flee back east before the hell that is the Denver summer. If things break as I hope they will next week and the week after, it’s possible that I’ll have my own not-so-captive audience to drag along.

See you at the Celtic. No Smithwick’s, sadly, but there is Murphy’s.

It's shaping up to be a good month for meetups: Silicon Valley next week, Denver the following. I'm participating in a Consulting Panel at the local Ruby on Rails user group that same night. Hopefully they won't mind if I have a couple cold ones beforehand.

Java Web Framework Smackdown at TSSJS in Vegas

This year's TSSJS is starting to look like an excellent conference. I'm particularly excited to be moderating the following Expert Panel.

Java Web Framework Smackdown: Struts 2, Spring MVC, Grails, Seam/JSF and Wicket
The leading advocates of today's popular Web frameworks will duel under the Vegas Lights. Come and learn when to use your favorite framework and to see if it can live up to its hype.

We're talking about productivity, scalability and maintainability of Java-based Web applications. The emerging trend is that simplicity is better and productivity matters. Furthermore, if maintainability is the most costly part of any application -- how do these frameworks perform?

Attend if you're a Java Web developer, or if you simply like good entertainment. A working knowledge of the popular Java Web framework options will make this session more fun. If you haven't worked with any framework, come and learn who has the best spokesman.

I plan on bringing the boxing bell from OSCON 2005 to make this session one of the best in the show. I'll be coming up with a list of questions for these experts in the next couple of months. In the meantime, if you have any suggestions, please let me know.

With a venue like The Venetian, why wouldn't you go?