Raible Designs

Want a kick-ass Java/UI Engineering Job in Mountain View?

The last month working at LinkedIn has been an absolute blast. I'm new to the whole "treating developers like royalty" thing, so that's taken a while to get used to. It's definitely nice, especially when the company gives you ownership of the things you're working on. Sure, there's schedules and priorities, but it seems like each and every engineer has control of their own destiny. As a consultant, I've been very impressed with the way I've been embraced and folded into the team like a regular employee. There's lots of team lunches, a tech meetup every now and then, and I even played hoops with a bunch of guys last night. This is probably the coolest company I've ever worked for.

Wanna have fun like I am? LinkedIn is looking to hire quite aggressively over the next several months. There's new faces almost every week and hopefully I can "hook you up" to be a part of the festivities. Below is a position that we're currently hiring for in the UI Engineering team. Working remotely is not an option at this time, you need to live in (or relocate to) the Bay Area.

I don't know if JSF and Facelets experience is still a requirement (now that I'm here ), but a passion for UI frameworks and web development is. You should know at least two leading Java frameworks and have a lot of experiencing with testing web applications out-of-container. We're not looking for Java Developers turned web developers, we're more looking for Web Developers that know Java.

If this sounds interesting to you, shoot me your resume in an e-mail. Don't forget to include a link to your LinkedIn Profile.

Do we even need web frameworks?

On the Struts mailing list, Ted Husted writes:

IMHO, if we had today's JavaScript/CSS/HTML environment available to us in 1998, then JSP, ASP, JSF, PHP, and all the rest of it, would not exist. We did all these things to make up for the shortcomings of the client-side environment, and, since then, the key shortcomings have been addressed.

I believe Ted has a good point. However, today's Ajax development toolkits don't help those applications that require Section 508 compliance. Of course, if your toolkit embraces 508 compliance, I'd love to hear about it.

AppFuse vs. Grails vs. Rails

In the comments of my Choosing a JVM Web Framework, Graeme Rocher writes:

no offense Matt, but I fear you are a grossly inappropriate person to be writing such a study given your past history of claiming frameworks like Grails are competitors to AppFuse. Any such study will come laced with doubts over its honesty and I'm sure this doesn't just apply to Grails.

In the post Graeme linked to, I said:

I think Grails and AppFuse are more likely competitors rather than compatible. Grails uses Spring, Spring MVC and Hibernate under-the-covers, whereas AppFuse uses the raw frameworks. Of course, it would be cool to allow different classes w/in AppFuse to be written in Groovy or JRuby. At this point, I think it's probably better for users to choose one or the other.

Since writing that post a year ago, I've changed my opinion about AppFuse being competitors with Grails or Rails. Why? Because they're different languages. I don't think you should choose a web development stack first. I think you should choose your language first. For those that choose raw Java, I think AppFuse provides a good solution. To be more explicit, here's a private conversation that David Whitehurst (author of The AppFuse Primer) and I exchanged.

David: Have you been looking at Ruby on Rails any? And, if so, I'm sure you're as impressed by those who command the language as I am. But, I think the J2EE web application is not dead yet. Do you think any comparison of the complexity of AppFuse vs. Rails should be mentioned in the book?

Matt: I'm highly aware of Rails, have attended talks and tutorials on it, even bought books about it - but I've never written an app, done a tutorial or used it in the real-world. I'm afraid of it. I'm almost certain I'd like it, and I'd likely like Grails as well. However, the reason I stick with pure Java is because that's where my clients' demand is and hence the consulting dollars for me.

It's probably also possible to create AppFuse for both Rails and Grails. I believe Rails' Streamlined in much like AppFuse. I like to think of AppFuse as language agnostic - it's always been designed to eliminate ramp up time. While Rails and Grails simplify the programming API and make it possible to develop code with less lines of code, it'd be nice to have user management, file upload and other things like AppFuse has. When I start using these frameworks, it's likely I'll develop some sort of features like AppFuse has and use them on projects. Of course, if they already have all the features of AppFuse via plugins, I wouldn't reinvent the wheel - I'm simply use what's already there and be happy about it.

I don't know if it's relevant to mention Rails, but it probably doesn't hurt. There's no reason to ignore the competition if they're indeed competition. I don't see them as competition, and I almost don't see Grails as competition either. AppFuse (in its current state) is for developers that've chosen to use the language and frameworks that AppFuse supports. It's not trying to solve everyone's problems - it's merely trying to simplify things for those using the frameworks it supports.

There's nothing saying that AppFuse can't have a Rails or Grails version in the future. For me, it'll happen if I start developing applications using these frameworks and see the integration needs like I saw with the Java frameworks. The good news is most of these frameworks have done the integration work, so it's really just a matter of creating features or using plugins.

David: I keep getting these "dream-squasher" friends of mine showing me Rails, Grails, and how wonderful Ruby is. It's impressive, but I'm not convinced that big business is ready to adopt it any time soon.

Matt: As a Java programmer, I think you'd be a fool to ignore Rails or Grails and not at least be familiar with them. There's no reason to discount technology until you've used it on a real-world project - at least 6 months or longer - IMO.

Just because you're productive in Ruby and like it - that doesn't make you a bad Java programmer.

I hope this clears up any confusion on how I feel towards Rails or Grails. I would welcome the opportunity to use them on a project. If I was starting a products-based company, I certainly would give them a shot in the prototyping phase. However, I'm a consultant that makes money from clients hiring me to explain/do what I know best. At the current time, that happens to be open source Java frameworks.

I do plan on learning a plethora of other frameworks, in other languages, I just haven't had the time yet. When I do, I hope that I can somehow become proficient enough to help companies adopt them as well. However, to build up that experience and expertise will likely take years. I think this is how lots of companies feel. Can you blame them for not "jumping ship" on their current skills and knowledge?

Of course, then you have the Relevance guys who seem to be doing exactly what I hope to be doing in several years from now. Not only do they specialize in Java and its frameworks, but they also do consulting and training around Rails, Grails and Ajax. I can't help but admire them tremendously.

Choosing a JVM Web Framework

I plan on rewriting my "Comparing Java Web Frameworks" presentation for this year's Colorado Software Summit. Rather than "Comparing Java Web Frameworks", I'm going to make it into more of a "Choosing a JVM Web Framework" presentation. I think this opens it up to more possibilities such as Grails, JRuby on Rails, Flex and GWT.

One of the things I hope to talk about is choosing the right tool for the job. I think there's 3 types of web applications you can develop:

1. Consumer-facing, high-traffic, stateless applications
2. Internal, more desktop-like applications that are stateful
3. Media-rich applications that require a RIA framework like Flex

Once you've decided on which of these you're developing, it's much easier to narrow down the choices:

1. Struts 2, Spring MVC, Stripes
2. JSF, Tapestry, Wicket
3. GWT, Flex, OpenLaszlo

I'm not sure if GWT fits in the RIA category. I'm not sure where Rails or Grails fit either. They more closely resemble category #1 than any other, yet there's a lot of speculation about their scalability. I think if that perception can be changed, they'll fit into the first category quite well. However, I don't think they compete with component-based or RIA because they don't hold state or offer rich-media capabilities.

Sidenote: I find the scalability debate quite interesting. There's a fair amount of propaganda in Javaland that scalability can be achieved with appservers and clustering tools like Terracotta. If this is true, I've yet to read good solid proof of it. Most of the "how to scale" information out there suggests "share nothing" architectures that shard data and applications across several servers. Of course, there's scalability and then there's massive scalability. Can appservers and clustering solve massive scalability like Google and Amazon require?

The 2nd and 3rd categories have someone of a blurry line, so I'm hoping to figure out how to clarify that. There's also a lot of other factors that will go into choosing a web framework. What if you're simply trying to replace a home-grown framework with an open-source one? If you want to keep your backend and all its logic, does it make sense to use something like Seam, Grails, JRuby on Rails or even AppFuse? Probably not - all their wizbang features and CRUD generation doesn't mean much if all you're using is the web framework. Also, if your application requires support for non-JavaScript browsers (for 508 compliance), then GWT and JSF can be easily eliminated. I know that there are many claims that JSF doesn't require JavaScript, but I've yet to see a real-world application developed with JSF that expects JavaScript to be turned off. Progressive enhancement is a requirement by many of my clients these days.

What's your opinion? How can we make it easier for developers and companies to choose a web framework? Is categorizing application types a good technique?

Integrating Struts 2 + JSF + Facelets

What if you didn't have to choose between a request-based framework and a component-based framework? What if you could use them together and use request-based for some pages and component-based for others? This is the functionality that the Struts 2 JSF Plugin provides.

To be fair, the JSF-Spring project says it does the same thing for Spring MVC + JSF, but there doesn't appear to be any documentation.

I did some prototyping of Struts 2 + JSF and discovered that it does indeed work. I also discovered that there's no documentation on integrating it with Facelets. Luckily, it's pretty easy to do - hence my reason for writing this entry. You might ask why I want to use Facelets when JSF 1.2 supports JSP fairly well? My reason is because JSP 2.1 hijacks #{}, which Struts 2's OGNL uses for some expressions. Because of this, I want to be able to run on a JSP 2.0 container until a workaround comes along. Sun's JSF 1.2 RI can run on a JSP 2.0 container, while MyFaces 2.1 cannot (at least in my experience).

There's two ways to get Struts 2 + JSF + Facelets working:

• Create a WEB-INF/faces-config.xml file and override the default view-handler:

  <?xml version="1.0" encoding="UTF-8"?>
  <faces-config xmlns="http://java.sun.com/xml/ns/javaee"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
          http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd"
      version="1.2">
  
      <application>
          <view-handler>com.sun.facelets.FaceletViewHandler</view-handler>
      </application>
  </faces-config> 
  

• The 2nd way is to use Ajax4JSF and declare the view-handler in your web.xml (allowing you to get rid of faces-config.xml):

  <context-param>
      <param-name>org.ajax4jsf.VIEW_HANDLERS</param-name>
      <param-value>com.sun.facelets.FaceletViewHandler</param-value>
  </context-param>
  

NOTE: You have to use 2nd method if you want to use Ajax4JSF. It won't read the view-handler from faces-config.xml.

If you're using SiteMesh, you may have to add another <parser> element to your sitemesh.xml to get Facelets pages decorated:

<parser content-type="application/xhtml+xml"
    class="com.opensymphony.module.sitemesh.parser.HTMLPageParser"/> 

Thanks to Laurie Harper for his assistance figuring this stuff out.

Now you might ask - why would you want to do this? For one, Struts 2 has a better navigation model (IMO) than JSF. Also, if developers want to use JSF and think it's a better way for a certain module - let them go to it!

OSCON 2007: Comparing Java Web Frameworks

This afternoon I delivered my Comparing Java Web Frameworks talk at OSCON in Portland. I told attendees I'd post it here afterwards, so here it is:Download Comparing Java Web Frameworks Presentation (5.1 MB)

For comments on this presentation from earlier this year, see related postings from ApacheCon EU and JA-SIG. This presentation is pretty much the same as the one from ApacheCon and JA-SIG, except it has a different theme and I chopped out the Sweetspots section (due to time constraints).

Portland is great this time of year, but unfortunately I won't be sticking around. I'm heading down to Salem to work remotely for a couple of days, returning for the Oregon Brewers Festival on Friday and heading back to Denver on Saturday. I'll be glad when July is over - I've traveled to a new state every week.

Java Web Frameworks and XSS

In preparation for my talk at OSCON next week, I've been doing some research on cross-site scripting and how good Java web frameworks handle it. I'm disappointed to report that the handling of XSS in Java web frameworks is abysmal. First of all, the JSP EL doesn't bother to handle XSS:

With JSP 2.0 you can use the following to emit the description of a "todo" item:
${todo.description}
That's pretty nice. What happens when someone has entered a description like this?
<script type="text/javascript">alert('F#$@ you!');</script>
Well, it executes the JavaScript and pops up a nice little message to you.
...
My question is this: Why in the world did the expert group on the JSP 2.0 JSR decide to make not escaping XML content the default for EL expressions, when they made the opposite decision for c:out?

(Emphasis mine) If a company/developer wants to make sure their JSP-based code is not susceptible to XSS, they have two choices (as I see it):

• Do lots of code review to make sure <c:out> is used instead of ${}.
• Hack the jsp-compiler/el-engine to escape XML by default.

The good news is #2 doesn't seem to be that hard. I pulled down commons-el yesterday, added a hack to escape XML, re-jarred and put it in Tomcat 5.0.25's classpath. This actually worked and I was impressed it was so easy. However, when I looked at Tomcat 6, commons-el is no longer used and now there's a "jasper-el.jar" in the lib directory. I don't mind modifying another library, but what's the difference between jasper-el and commons-el?

Of course, the whole problem with JSP EL could be solved if Tomcat (and other containers) would allow a flag to turn on XML escaping by default. IMO, it's badly needed to make JSP-based webapps safe from XSS.

On a related note, there's a couple of web frameworks that I've found to be susceptible to XSS: namely Spring MVC and Struts 2. For Spring MVC, its <form:input> and <form:errors> tags are vulnerable. For Struts 2, OGNL expressions are evaluated, which is way worse than XSS and actually allows you to shutdown the JVM by putting %{@java.lang.System@exit(0)}" in a text field.

Even though it was surprising for me to see the issues with Struts 2 and Spring MVC, I'm somewhat glad they exist. If I hadn't discovered them, I might blissfully think that Java web frameworks aren't susceptible to XSS. However, it appears they're not only susceptible, but no one is really thinking about XSS when developing these framework. To further prove that theory, the Spring MVC and Struts 2 teams are aware of these issues, have been for quite some time - yet they've done nothing in the form of releasing upgrades or patches.

Seems kinda strange doesn't it?

JA-SIG Keynote: Comparing Java Web Frameworks

This morning I did my first keynote at the JA-SIG Summer Conference in Denver. My talk was on Comparing Java Web Frameworks. I told attendees I'd post it here afterwards, so here it is:Download Comparing Java Web Frameworks Presentation (1.1 MB)

In addition, I mentioned my Java Web Frameworks Sweetspots Whitepaper.

Will I be comparing web frameworks at conferences for the rest of my life? Possibly. I've been submitting 2-3 proposals to conferences and it's the only one that keeps getting selected. I'll be delivering it at OSCON, JavaZone, Colorado Software Summit and ApacheCon US.

The Colorado Software Summit wants to have an original presentation - so I may need to drop a framework or two and add in Seam, Grails and GWT. If you are planning on attending one of these talks, which frameworks would you like to see compared?

Related: Comments after I delivered this presentation at ApacheCon EU.

Canoo WebTest vs. Selenium

From a message I sent earlier to the AppFuse user mailing list:

After getting Dojo's DropdownDatePicker working with both Struts and Spring MVC, I've run into a snag:

You can no longer use Canoo WebTest to enter dates in a form.

It doesn't find the form element because HtmlUnit (the underlying browser implementation for Canoo) doesn't understand/render Dojo's components.

For users, workarounds include:

1. Don't write tests for entering data on forms that have required dates.
2. Don't make dates required.

Either way, it seems logical to move to Selenium for UI testing.

What do you think? Are Dojo-based components the future of Ajax support in Java web frameworks? If so, I wish Dojo allowed more "progressive enhancement" features instead of the invalid HTML feature it seems to rely on now. I'm more than willing to support Dojo if that's what AppFuse users want. However, in my experience with Struts 2's datetimepicker, it seems pretty slow. Of course, if I could render my own input element and then add a datepicker next to it, I'd be much happier. AFAICT, the Struts' datetimepicker doesn't allow you to do this, but I could be wrong.

Of course, if Dojo 0.9 lives up to the hype and is much faster - maybe I should quit caring about Hijax and just start writing those Selenium tests?

For users of those "next-gen" Java frameworks (like Seam, Grails and Wicket), what do you use for UI testing? Does Canoo WebTest work for you when you have a lot of Ajax functionality? If not, do you use Selenium or leave UI testing up to the QA folks?

Update: I ended up using jscalendar for both Spring MVC and Struts 2's datepickers. It's simply the best tool for the job. Dojo is too bloated IMO (240K for a datepicker!) for such a small feature. This allows us to worry about getting AppFuse 2.0 out the door without migrating to Selenium first. We will eventually migrate to Selenium (it's a better tool for the job IMO), but probably not until 2.1. The only question is what's the best way to distribute Selenium tests?

Live Coding for 4 Days Straight

Last week I had an interesting 4-day consulting gig for a client in Boulder. I was supposed to fly out to Connecticut to deliver a training course, but it got rescheduled due to the 45-day Vendor Approval Process I need to go through. The client in Boulder wanted me to come out and do an architectural assessment and provide recommendations. Topics they were interested in: web tier (specifically Spring MVC), Security, Ajax integration, build process, web services and localization. I've done this kind of before with Virtuas, but this time was different. With Virtuas, I'd do 5-days worth of presentations on just about anything the customer wanted. For example, checkout this agenda for a client in NY last year.

With the company in Boulder, I delivered zero presentations. Instead, everything we talked about and coded was hands-on. On Tuesday, we started out by discussing their application and some issues they were having. They'd done a lot of customization to Spring MVC and had managed to eliminate all the XML needed when adding new controllers and views. I spent 3-4 hours that day with 2 of their engineers finalizing and implementing their convention-over-configuration rules. On Wednesday, I helped them implement Acegi Security into their application. This was interesting because they didn't have any security mechanism and we had to implement Acegi from scratch and then tie it into their backend (using a custom AuthenticationProvider). We also integrated i18n so all messages were retrieved from their database.

On Thursday, we configured Ant to run their tests and wrote some tests for their controllers. As part of this process, I showed them how to use jMock and EasyMock and tried to explain the benefits of using Spring IoC (which they still aren't sold on). On Friday, we integrated Selenium into their build process and wrote a few tests using Selenium's Java support. In the afternoon, I showed them how they might use Scriptaculous and Prototype to Ajax-enable some features in their application.

Doing all the "live coding" on someone else's machine (with 5 developer's watching) was a bit nerve wracking. However, thanks to Cenqua's FishEye tool, I was able to search AppFuse and AppFuse Light's SVN repositories for code snippets and examples. While I knew how to do much of the stuff we covered, FishEye and Google bailed me out when I didn't. About halfway through, I realized that I don't keep a lot of my knowledge in my head. Instead, it's on this blog, or spread out on the web. I don't remember URLs anymore, all I remember are keywords. If I've read a blog post or article on the web, chances are I can find it again pretty easily with Google. Even though I store a lot of bookmarks in del.icio.us, I didn't use it all week. Remembering keywords is the new bookmark for me.

The whole week was an interesting exercise in "live coding." The whole team (6 or so) sat in a conference room all week and VNC'ed into the architect's box to do the work. We worked in Eclipse and used WTP to deploy/test things on Tomcat. The keyboard was passed around between developers at random and everyone got a chance to implement new features. I think the reason that everything worked so well was because the team was full of Senior Java Developers. Everyone learned from each other as they saw new shortcuts, keystrokes and ways or writing code. I don't know if this kind of thing will work in all development teams, but I'd encourage you to try it. It's a great way to share knowledge and educate the entire team on how a new module works.

Over the weekend, I received the following e-mail from one of the developers on the team:

Very nice to meet you this past week and get a chance to see firsthand the breadth and depth of your experience in web app frameworks and such. I believe due to your visit, we will be cranking happily along here very shortly. Everyone was quite happy with the results at the end of the day yesterday.

On a related note, if you're looking to hire an enthusiastic Web + Java Developer, please take a look at my resume or send me an e-mail. My current contract ends this month and I'm hoping to find something new to get me through the summer.