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.

New developerWorks Articles: DWR and Google App Engine

This week, IBM developerWorks published two new articles that I wrote. The first article, is the third of the three part series I did on Ajax toolkits. This one is on Direct Web Remoting or DWR as it is commonly known. I had always been skeptical of DWR because of its RPC nature. However, after doing the article, I have to admit it is a pleasure to use. In the article I used the Java Persistence API (JPA) in combination with DWR. I was very pleased with being able to simply annotate some very simple, vanilla code and create an Ajax service that talked to a database. Ruby on Rails often seems magical to people in its ability to very easily work with databases and simplify Ajax development. DWR shows that you can do some pretty magical things in Java, too. DWR also makes Google Web Toolkit’s RPC code look ridiculous.

Speaking of Google (that is called a segue, if you are keeping score at home) the second article is the first of a three part series on the Google App Engine. I had mentioned some of the work on this here, and now you can read all about it on developerWorks. Of course you can also check out the application developed in the series, i.e. the aggroGator and you can get its source code here.

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.

Galpin on Rails on IBM

A couple of pieces that I wrote on Rails appeared on IBM at the end of last year. I didn't even realize it until today when somebody emailed me about one of the articles.

The first article is part one of a four part series on using Rails, XForms, and DB2's PUREXML tables together. I also wrote part two, but another writer wrote parts three and four. Only part one is up so far.

The second article is the third tutorial I wrote on using Eclipse as a web development platform. Part one was about using Eclipse for Java web development, and part two was on using it for PHP development. The last tutorial is on using Eclispe (via RadRails) for Rails development. Note, the link for part two shows the intro page to part one. If you login, it correctly gives you part two. Clearly some kind of technical glitch for IBM!

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.

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.

GWT Tutorial Part 2

The second part of the GWT tutorial I wrote for IBM is now online @developerWorks. The second part adds some more server-side logic for persisting data (in this case a stock portfolio) to a database. Of course it makes judicious use of GWT to accomplish this auto-magically.

Geronimo Plugin Tutorial

I posted yesterday that the GWT tutorial I wrote is now on the developerWorks. I didn't even realize it, but another tutorial I wrote was published last week as well. I wrote a tutorial on Geronimo plugins for IBM. It was actually a really fun tutorial to write. I think Geronimo's plugin architecture has a lot of exciting possibilities. In some ways it's a natural progression in terms of modularity. I always think of JBoss as folks who really recognized the possibilities opened up by making JBoss so modular via it's JMX based architecture. Geronimo's GBean architecture is a natural improvement, and it's what makes the plugin architecture possible. So check out the tutorial to see how easy and open the architecture is.

GWT Tutorial on IBM

Part 1 of the tutorial I wrote on GWT is now up on developerWorks.

Thoughts on GWT

I recently finished the second part of a two-part tutorial on the Google Web Toolkit. It should appear on IBM's developerWorks in the near future. I read a lot of materials on GWT during that time, including quite a few criticisms of it. So I figured I should take the time to put in my $0.02 about it.

GWT is an interesting engineering solution to a hard problem: generating standardized, cross-browser AJAX applications. What makes it unique is that it doesn't require you to understand JavaScript at all. You barely need to understand HTML even. That is really cool. But is it worthwhile?

The answer is, I don't know. It seems like a toy at times, but a really powerful toy. It's hard for me to imagine creating a real website using it, and there is really no way to even use it just for prototyping. As I understood it more though, I realized that there was a real-world workflow possible with it, and maybe that's its biggest strength.

If I were using GWT to build a real site, I would have a web designer build a complete prototype that I would check in and deploy -- as is. Ok, maybe I'd make sure that various visual components had the proper IDs or classes, since that's what GWT uses to identify and replace components. It's the replace part that is really important. The GWT runtime would replace the components created by the designer. It would replace it with JavaScript generated HTML. However, all the CSS created by the designer would be applied. So as long as the CSS was tight, then the GWT-generated component should look how the designer wanted it.

That's nice, really nice. I think having a good workflow between designers and developers is huge. Just look at what Microsoft has tried to do with Web Forms and now with XAML. Web Forms arguably inspired Java Server Faces, which is now part of the JavaEE specification. So maybe that's the real strength of GWT. Everything else is icing on the cake. That being said, here's my favorite and least favorite things about GWT.

Good Stuff

• Debugging -- Being able to debug client side code inside Eclipse (or any IDE) is really nice. I don't know how much time FireBug has saved me in debugging JavaScript. Every JS developer I know uses it. I show those guys what it's like debugging GWT code inside Eclipse and they freak out. The Visual Studio debugger is also really nice, but it's still got nothing on a Java debugger. GWT just enables a Java debugger. Of course it's only valid for hosted mode, but that's another topic.
• Unit Testing -- Ditto for writing unit tests. I know that there are initiatives for creating JavaScript unit tests, such as JsUnit. I've looked at it a little bit, and it's really clever. It still requires all your code to be deployed (of course.) Being able to run a unit test either inside your IDE or with an Ant/Maven target is really nice. Easier unit testing == more unit tests == better software.
• Nice HTML Abstractions -- Really like the FlexTable for example. It's also interesting to port layout managers to HTML. I can definitely see possible conflicts with CSS though. I'm not sure what would happen if your CSS specified a position that really conflicted with the layout algorithm. I'm sure CSS would win, I'm just not sure how bad it's going to make things look.
• RAD Tools -- Nice tools for setting up your project, etc. A lot of GWT was clearly inspired by Ruby on Rails, and this is one of the notable inspirations.
• Architecture -- Encourages UI logic being pushed to the client. Make use of the user's computer, and offload from your server.

Bad Stuff

• Cross Platform Problems -- All those RAD tools are OS dependent. In my experience they work really well on OSX, but are haphazard on Windows. I love OSX, but that's not good.
• Obfuscation -- The generated JS is dense and heavily obfuscated. Maybe that is useful for Google projects, but how is it good for the average developer? It creates a dependency. If you can't debug your client code in hosted mode, you have no chance of debugging it at all.
• No Java 5 -- It's understandable that GWT only supports a subset of Java classes when it comes time to generate JavaScript. But it's really annoying that you can't use things like the improved for loop, generics, and annotations. The annotations present a real problem if you're using Java Persistence or EJB3. An annotated entity bean cannot be passed to the UI essentially. You're forced back into a data transfer object anti-pattern.
• Lots of boilerplate code to write -- To use a remote service, you have to write a client side interface for it (not too bad), an asynchronous version of the same interface, and the actual (server side) implementation of the interface. Then you have to write some obscure looking client side code for registering the service at runtime. Doesn't this all sound familiar? Doesn't this sound like creating remote and home interfaces for an EJB and then having to use JNDI to look it up at runtime? We all know how that turned out for EJBs.
• Better build support needed -- Hosted mode is great, but it's kind of a pain going from hosted mode to a real deployment. GWT can't solve this completely obviously, but they can do more. Hosted mode lets you switch to a "live" mode where GWT creates a Tomcat directory and installs the web application to Tomcat. So clearly they understand the deployment issues, like exposing the RPC servlet endpoint in web.xml.
• RPC is bad -- Ok, I'm not quite as convinced of this as I used to be, but I think it is mostly true. RPC encourages a lot of strong coupling between server and client. However, I think the distinctions between server and client are fading anyways, so this is becoming less of an issue. You're probably going to want the services called by the client to be facades to the "real" services anyways, just because you don't want your real services to be compiled into servlets (which is what happens because you have to extend the RemoteServlet class in GWT.)
  

Ok, so maybe I named more good than bad, but that's always the case, right? The bad things always stick out more because you spend a lot of time working around them.

I'd like to see GWT leverage Java 5 a lot more. It needs to support generics. It should not only ignore most annotations, it should use them to eliminate the boilerplate code that developers have to write and the redundant interfaces that have to be declared.