Raible Designs

How do you get up to speed on Rails and Grails quickly?

What's the best way to learn Rails and Grails and satisfy one of my New Year's Resolutions (read more) at the same time? Books:

• Getting Started with Grails
• Rails for Java Developers
• Practical JRuby on Rails Web 2.0 Projects: Bringing Ruby on Rails to Java
• Groovy Recipes: Greasing the Wheels of Java
• Programming Groovy: Dynamic Productivity for the Java Developer
• Groovy in Action

Thanks to connections with publishers, I was able to get PDFs of most of these for free. The only ones I paid for were the beta books (Groovy Recipes and Programming Groovy) from the Pragmatic Programmers. I doubt I'll read them all, but I've had fun so far.

I polished off Getting Started with Grails in a few hours. I expect to finish Rails for Java Developers this week. I used to hate reading PDFs, but I've enjoyed reading these books. A 30" monitor might have something to do with it.

After honing my Grails and Rails knowledge, I hope to become a GWT and Flex Ninja. For those GWT and Flex experts out there, what are the best books for those technologies? By "best", I mean the most advanced and up-to-date.

Is there room for both Rails and Grails in a company?

For the last week, I've been knee deep learning more about Rails and Grails. The reason is because I think developers (and companies) are going to have a hard time deciding which framework is best for them. The real question is: do they both do the same thing or are their different applications for each? Is "Grails vs. JRuby on Rails" a "Struts 2 vs. Spring MVC vs. Stripes" argument - where they're all so similar it probably doesn't really matter which one you choose?

Of course, the Stripes folks will object, but I really don't think it's that much better than Spring MVC 2.5 or Struts 2.1. Sorry guys.

If it is a Spring MVC vs. Struts 2 type of argument, then it seems to make sense for a company to standardize on one -- don't you agree? Does it make sense to allow both frameworks in a company if they're so similar?

Google has had much success in restricting its allowed programming languages to C++, Java, Python, and JavaScript. Shouldn't other companies do something similar? It seems like a good idea to restrict allowed web frameworks to a few as well. For companies with successful Java infrastructures, it seems logic to allow one Java-based web framework and Rails or Grails for getting things done as fast as possible.

Here's the sticking point: Ask any Rails developers and they'll say Rails wins hands down. Ask any Grails developers and they'll say Grails is the easy choice because it builds on top of Java's strong open source projects. Blah, blah, blah - where's the objective voice that's identified the "sweet spot" for each?

The Relevance guys, particularly Stuart Halloway, has a post about How to pick a platform. The logic in this post seems to imply that both frameworks do solve the same problem - just in different ways. Stu seems to recommend Rails for most applications, because Ruby is a better language. He says Grails might win if you have "an established team of Spring ninjas".

I know Stu and believe he does know his stuff (in both Java and Ruby). So is this the definitive guide on which framework to choose? If you have a staff full of Java developers, they should start learning/using Rails rather than doing the easier transition to Groovy, which they pretty much already know?

I don't know what the answer is, but that's what everyone seems to be saying. The problems is, the authorities on this matter (Rails vs. Grails) are often "head honchos" in companies that have a vested interest in seeing their respective framework/platform succeed. Since the Relevance team employs some Grails developers, it seems they're less biased. But who knows.

Is Rails really head and shoulders better than Grails? I don't think so, but I've only been programming with both for a week.

Don Brown Makes Maven 2 Not Suck

Don Brown spent some time over the weekend Making Maven 2 not suck:

While there are a few (very important, I might add) things Maven 2 gets right, there are a bunch that just suck, yet I use it at my day job (Atlassian) and in Open Source work, so in true Open Source tradition, rather than continue bitching, I'm doing something about it. I'm embarking on a quest to fix all the bits of Maven 2 that really annoy me and waste my time. I hope to get most, if not all, of the changes back into the codebase, but my personal deliverable is a build of Maven 2 that doesn't suck.

On his blog, Don lists a number of improvements he hopes to make. This weekend, he implemented the first three, which concentrates on speeding up remote repository access and downloading of artifacts.

First up, tasks #1-3. I implemented these changes in a bored Sunday afternoon and saw a example build (Struts 2 core) go from 3 minutes, 26 seconds to 2 minutes even, so a little over 40% performance improvement.

Interested, I decided to try Don's improvements on AppFuse. Since it fetches seemingly hundreds of artifacts from Maven's central repository, it seemed like a good testing ground. With a clean repository (rm -r ~/.m2/repository), a 8 MB/sec internet connection and "mvn -Dmaven.test.skip", I achieved the following results with the stock version of Maven 2.0.8:

[INFO] Total time: 7 minutes 40 seconds
[INFO] Finished at: Mon Jan 28 09:02:11 MST 2008
[INFO] Final Memory: 55M/508M

With Don's improved uber-jar, I received the following results:

[INFO] Total time: 5 minutes 17 seconds
[INFO] Finished at: Mon Jan 28 09:10:56 MST 2008
[INFO] Final Memory: 56M/508M

460 vs. 317 seconds = a 31.1% improvement -- Nice work Don!

When he implements #4 (Should support artifacts checked into the SCM in the lib/ directory so no external repository needed), I'll be a much happier Maven consumer. I've always wanted the ability to bundle all of AppFuse's dependencies for offline use like we did in 1.9.x.

Don - I'll buy you numerous beverages in Vegas if you add the ability to run a Maven command to put all a project's dependencies in its lib directory too.

The future is now -- Java development in 2008

In The future is now -- Java development in 2008, Andy Glover writes:

The year 2007 was full of exciting plot twists, punctuated by growing excitement about dynamic languages, the open source evolution of the JVM, and the rise of Google as a strategic contributor to the Java community. The question is, what does all that tell us about the year ahead?
...
And so, despite some rumors to the contrary, I would argue that Java isn't going anywhere but up in 2008. Rather than peer into a crystal ball and try to divine the future, let's reflect on the major events and trends of the past year. Taken together, they reveal all we need to know about what's ahead in 2008.

He concludes the article with:

An African proverb states that Tomorrow belongs to the people who prepare for it today. Thus, the future of Java (at least for the next year) has already been brewing for some time. The events of 2008 will largely be shaped by the JVM itself, as languages like JRuby and Groovy grow in popularity and eventually gain enterprise-wide adoption. The promise of using Java to develop consumer mobile applications also seems more accessible than it has for some time, given Google's foray with Android and Sun's with JavaFX Mobile. Most of us will also be concerned with leveraging the emerging multicore systems and looking to Java 7's java.util.concurrent packages for answers. Lastly, open source Java and the business model surrounding it will continue to grow.

I agree that learning about JRuby and Groovy is a good way to be prepared for the future. Reading Ola Bini's Practical JRuby on Rails Web 2.0 Projects and/or Stuart Halloway and Justin Gehtland's Rails for Java Developers seem like good ways to get started with JRuby. With Groovy, Groovy in Action has received a lot of good reviews. For Grails, it's a bit more difficult as it's evolved so quickly w/o any updated books. I like the look of Scott Davis's Groovy Recipes, but that won't be released until March.

One thing to note: just because you learn these languages and frameworks doesn't necessarily mean you'll find a new job doing them. In my experience, there's still way more Java jobs than there is Rails or Grails jobs. I sat on a Consulting Panel last night at Denver's Ruby on Rails user group (DeRailed) and this was confirmed (at least for Ruby) by the recruiters on the panel. There were three recruiters and combined they've only seen 2 Rails positions in the last 6 months.

So if you're looking for a new job, I doubt you're going to find one that allows you to leverage your new-found JRuby/Groovy skills out of the gate. However, I do believe you can leverage these tools in your existing jobs and hopefully make your development life more efficient.

How long does it take to build a modern web framework?

Dear Java Web Framework Authors,

I hope you're doing well and continue to enjoy working on the web framework you created years ago. I'm curious to know something:

    How long would it take you to build your web framework from scratch?

If all the code from your framework magically disappeared tomorrow and you had to write it from the ground up - how long would it take? What if you had a group of 3-5 developers (of your choosing) to help you do it?

Furthermore, would you write the whole thing line-by-line, or could you borrow code from other open source projects to streamline the process?

Thanks in advance for your response,

Matt

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.

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.

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?