You Want XUL, You Got XUL

I've written a lot of articles for IBM over the last couple of years. I've covered a lot of topics. It was interesting for me to see which articles have been viewed the most. Last year I did a tutorial on XUL for beginners. To be honest, I really thought XUL was a very niche topic. If you are going to write a Firefox extension, you have to learn XUL. There are lots of resources out there about that. I did not want to write about that kind of XUL development. So instead I wrote about creating a XUL desktop application that used a lot of web development skills. Hey if Adobe can market AIR as a way for web developers to create desktop apps, then why shouldn't Mozilla do the same thing with XUL? It was a fun article to write, but I didn't expect it to be especially popular. Boy was I wrong!

That tutorial has been one of the most popular things I have written for IBM. So it made sense to update it this year. The tutorial used Firefox 3 as a XUL runtime. When I wrote it, Firefox 3 was in alpha stage. Obviously it has been released since then and is in wide use. So the opportunity for web developers to use XUL to create desktop applications is greater than ever. This week IBM published the updated tutorial, so go check it out.

Get Lifted

Yeah, I'm a John Legend fan, but that's not the reference here. The reference is to Lift, the web application for Scala. Today IBM published an article I wrote about Lift. This was an article that I pitched to IBM and I was very excited about writing. Lift itself takes a different approach to web development than the typical MVC approaches. It is also in Scala, and takes great advantage of that languages features, especially its native support for XML.

One of the most surprising features of Lift was the ORM that it includes. Lift's creator, David Pollak, commented that he would use JPA for complex schemas and not Lift's ORM. I must admit, it was the part of Lift that took me the longest to get my head around. I consider myself quite the veteran of ORMs, but Lift's is definitely unique. I think it needs some tooling around it, as it felt like some boilerplate-ish code was present (like creating a model class and singleton factory for the model class.) However, I really liked its use of generics.

I didn't have time in the article to get into Comet with Lift and Scala's Actors. That is an awesome feature. Hmm, perhaps that should be another IBM article..

Finally, of Lift and Scala related news... check out Graceless Failure by some of the developer at Twitter. It seems to imply that Scala and maybe Lift or at least "in the mix" at Twitter. I wonder if it is replacing Ruby and/or Rails in some places. Certainly Actors would seem like an obvious way to handle new updates on Twitter.

Finally Grails

It sure took me long enough, but I finally got around to writing about Grails. This article gives some introduction to Grails, but also talks about using Grails with Geronimo. The most valuable info in there might be the Geronimo deployment plan. This shows which packages to exclude from Geronimo's classpath when deploying a Grails application. This prevents classpath implosion.

New Scala Article

IBM published my first Scala article today. It's on using Scala to work with XML. It was a lot of fun to write about Scala. I am very lucky to get to share something that I enjoy. However, it was also a little challenging. It is so easy to be so terse with Scala that it seemed to carry over into my writing. I thought it would have the opposite effect, i.e. I would feel like I would need to write a lot more to describe what was going on with Scala code than I would with Java. Instead I had to really force myself to be descriptive about things. I would look at some of the code and just think: "the reader does not need me to explain that, it is so obvious." That is a testimony to Scala. Its handling of XML takes advantage of its DSL-friendly nature. A lot of complex and powerful expressions in Scala simply do exactly what they look like they should do. Or maybe its just my mathematical mind that sees things that way, who knows. Anyways, I have another article in the works for developerWorks that will cover Lift, a web framework developed with Scala.

eBay on developerWorks

I have written a lot of articles for IBM over the last couple of years. Most recently I got a chance to write about "my day job" if you will: eBay. I wrote two articles on how we use Eclipse at eBay to tackle a lot of interesting problems. When I first came up with the idea for the two articles, it seemed really cool but I was a little worried about it being complicated. When you think of a large company (and with 15,000 employees and a $36B market cap, eBay certainly qualifies) you think of all kinds of red tape, armies of lawyers, etc. I was pleasantly surprised to have almost none of that to deal with for these two articles. The articles definitely show some of what's "under the hood" at eBay, but its just enough to explain some of eBay's unique needs and how we have used Eclipse to help with these needs.

More JRuby Performance

In the aftermath of my post on JRuby's performance, I exchanged some info with Mr. JRuby himself, Charles Nutter. Per his request, I opened a bug on the matter. It looks like it is a JVM issue, i.e. JRuby ran slowly on IBM's J9 JVM. I did some micro-benching on Ruby vs. JRuby on a variety of platforms and JVMs. It was only on the J9/2.3 (IBM's JDK 5.0 JVM) that JRuby was was slower than the latest "native" Ruby implementation on that platform. Everybody loves charts, so here are some fun ones.


This was on my MacBook, with both the standard HotSpot Java 5.0 and Java 6.0 preview versions. I also compared using the -J-server (just becomes -server for the JVM) option, since HotSpot on the Mac runs in client mode by default. Thus the -server made a big difference.

This was on my home desktop system, a 32-bit Windows Vista system. I only did native Ruby vs. JRuby with and without the -server option. Again JRuby with the -server option crushed native Ruby.

Finally the environment that caused all the problems, my workstation. As you can see, it did quite poor compared to native Ruby. However, JRuby with either the 5.0 or 6.0 HotSpot JVM was much faster. I was actually hoping to see a better performance advantage on the 6.0 VM vs. the 5.0 one... I don't have IBM's 6.0 VM, so I could not include it. The HotSpot VMs were both 64-bit, whereas the IBM J9 on was a 32-bit VM.

GWT and XForms Series, Parts 3 and 4

The last two parts of the GWT and XForms series I wrote for IBM are up now: Part 3 and Part 4. Part 4 is fun since it is more "icing on the cake" kind of stuff as opposed to the core integration of the two technologies. I really wanted to work in some info GWT's ImageBundles. It's a slick implementation of the CSS sprite pattern.

Continuing down that tangent... I'd like to see an ActionScript implementation of that pattern. It would be cool to take a dozen images in Flex Builder, have it create a composite, and then use that for any references to those images in your Flex application. Of course maybe it's not needed. If you knew you needed those dozen images for your app, you could just embed them all in your SWF. That's going to be even more efficient since you won't have to make the HTTP request for the composite image. Obviously there are advantages to externalizing, since you could change the composite image without recompiling your SWF and without having to worry about referencing a new version of your SWF that's not being cached by users. It also allows for localization of the images. Enough rambling on that topic for now.

New GWT + XForms Series

I wrote a four-part series for IBM on using Google Web Toolkit and XForms together. Somehow IBM snuck part 1 and part 2 by me on their site. The tutorial uses JSNI a lot and touches on some of the latest features in GWT.

GWT 1.4

I recently finished writing a series of four articles for IBM on GWT. You might recall that earlier this year I wrote a two-part tutorial on GWT. The new articles for IBM aren't as introductory, though they don't require a lot of prior GWT knowledge. They're definitely more advanced though. I wrote the articles using the 1.4 release candidates, and then last week 1.4 went final. So I figured it was time to look at how GWT has progressed since the last time I wrote about it.

• Cross Platform Problems -- Hard for me to say how much things progressed. I did almost everything on my MacBook, and things had always worked well on OSX. I did do a little on Windows. I had to do a little more configuration to get it to correctly run in hosted mode than I did on OSX.
• Obfuscation -- Still a problem. Of course you can turn it off, which is good. Still, I pity the fool trying to debug GWT JS in Firebug.
• No Java 5 -- Still a problem. GWT will choke on a List, but String[] is ok. Also, any annotations will choke it as well. So no returning @Entity classes from your RPC services.
• Lots of boilerplate code to write -- Still a problem. You still have to write two interfaces and one class to create an RPC service. Inserting GWT into an existing page is easier, with just a single JS file to include.
• Better build support needed -- This has a improved a little. The ant script that is generated is slightly more useful than the previous version. Still frustrating that there's no build script generated for creating a WAR file. You don't have to use GWT with a Java application server, but obviously a lot of people are. The RPC services require it as well.
• RPC is bad -- Of course that can't change! RPC is still bad. I like how in the documentation, the GWT team mentions two different design philosophies for RPC services. One is to create RPC's specifically for the web application. The other is to have general purpose ones that can be re-used by many clients. Good luck on that last one. That would mean your general purpose services can only accept and return classes from the subset of Java 1.4 that GWT supports.

So that addresses my old pain points. Not much progress has been made. There are some new good points.

• Performance improvements -- Ok, they've really done a good job here. Things are snappy even on a page where you use lots of generated JS to create your UI.
• More Widgets -- Steady progress has been made here. You can get pretty far just using their widgets. I haven't tried out any of the commercial WYSIWYGs built for GWT, but these seem more viable and useful with more widgets. Of course, their widgets are very limited. They definitely aren't components. Compare a GWT widget to a Flex component, for example, and it's not even funny. GWT's widgets are pretty lightweight, but are low in functionality compared to similar abstractions found in similar frameworks.
• Image Bundles -- Very cool new feature. I like how they use CSS to get nice layout of the images from the bundle. It seems like a great way to optimize the static assets in your app. Seems like it might play tricks with a user who wants to right-click on one of your images and do save-as, but oh well.
• Localization -- This has always been there, but it seems better documented and exposed now. Plus there is a command line tool for it. It's pretty nice, though I question the logic behind doing your localization in code that is going to be converted to JavaScript and executed on the client.
  

So all in all, GWT has made some nice improvements and added some new features. They have not addressed the things that are their most blaring weaknesses (IMO), but then again those are probably the hardest things to address. I was surprised though. From my last big write up, I got a lot of feedback from people talking about how these exact issues were being addressed, i.e. that the work was already in progress. Was that really the case?

New Articles on IBM

There's a couple of new articles that I wrote that are now available on IBM developerWorks:

The Geronimo renegade: Using integrated packages: Codehaus' Woodstox: This is an article all about Geronimo's StAX implementation, Woodstox. If you're an old veteran of XML parsing like I am, you have to love StAX. Woodstox is not only an excellent StAX implementation, it is a killer piece of software. We use it in a lot of places at eBay because it is so fast.

Use JavaScript to make your XForms more robust: This is a very cool article about mixing JavaScript and XForms together. XForms has become kind of a forgotten technology, which is a real shame. It has so much to offer. I think part of the reason it is forgotten is because people don't realize that it is standardized and integrated with other technologies. It plays nice. It's not some one-off technology that lets you do some cute things in a sandbox. This article shows how everything in the XForms world is accessible through JavaScript. It's not a read-only kind of access either. You can modify models and forms, etc. I'm planning on writing some more on XForms and how it integrates with a certain well known AJAX framework that is usually referred to as a three letter acronym...

XForms Article on IBM developerWorks

IBM recently published an article I wrote on XForms. There have been so many times in the last five years that I've looked at XForms on behalf of whoever I was working for. It was always such a promising technology. It just needs browser support. It's funny that Mozilla has a great plugin that they don't include by default. Of course it's really just a matter of Microsoft. If IE included XForms support, it would get rolled into Firefox the next day. But of course they don't do this and instead re-invent the wheel...

Non-Java Article on IBM

I have a new article up on developerWorks: Developing applications using the Eclipse C/C++ Development Toolkit. This is one does not use Java, as should be obvious from the name, though it does use Eclipse. For some reason IBM listed my very old "About the author" info from the first article I wrote for them 1.5 years ago. So it says I work for Vitria still, instead of eBay.

It was a fun article, though I must provide a word of warning on it. CDT relies on g++/make/gdb being "properly" installed on your system. This can be a real pain on Windows, though it is status quo on any kind of Linux or on OSX. From the screenshots, it is obvious I wrote the article on a Mac, and part of why I did that was so that I did not have to deal with make/cygwin configuration on Windows. So before trying CDT out, make sure you have its prereqs working, i.e. at least use make to build something with at least two source files, via the command line. Otherwise you might think there's a problem with CDT, when actually the problem is with make or cygwin.