While developing OpenSocial applications can be a bit tricky, getting set up to develop can be a real pain in the neck. For this installment of OpenSocial and GWT, I'm going to go through the basics of setting up a simple Hello World gadget with iGoogle. We'll get into the details of signing up for other OpenSocial containers, testing, and so on, later. Right now we're just going to do the basics.

So, what do you need to build a Google Gadget with GWT for iGoogle? You need the following:

1. The Google Web Toolkit
2. The GWT Google Gadget API
3. An account on iGoogle
4. Access to the iGoogle sandbox
5. Some public server space so you can serve up your gadget to iGoogle

Pretty much everything else is self explanatory, but the sandbox can be a little bit confusing. Let's talk a little bit about the iGoogle sandbox. It's an experimental space where you can test things out without polluting your regular iGoogle account. Eventually you'll want several accounts in order to test. But every journey starts with a single step.

First, you need to sign up for iGoogle. I'll assume this isn't your first rodeo and you've done this before. Once you've got your iGoogle access, you'll want to go over to this page to sign up for the developer sandbox and add the developer tools to your space.

When developing, make sure that there's a message towards the top left of the page that says "Welcome to the iGoogle Developer sandbox." If you don't see that message, you're not in the sandbox. If you have to, navigate to http://www.google.com/ig/sandbox. You may have to "sign up" again to drop into the sandbox.

Once there, you can add those developer tools. Just clicking this link will get you started.

The developer widgets are:

• My Gadgets: let's you set inlining and caching on the Gadgets on your page from a handy interface
• Sandbox Profile Editor: let's you modify your profile in the sandbox so you can test a few things out.
• Sadbox Friends: lets you view and edit who your friends are. Important for OpenSocial applications.
• Updates:shows activities posted to your friends while interacting with the gadget.

The Hello World Gadget

In this part we're not doing anything OpenSocial related. We're just setting up a Google Gadget. That's a necessary first step for the OpenSocial stuff.

Let's get started. In my example I'll be working in ~/src/HelloGadget. Create a lib directory and put the gwt-gadgets.jar library file from the GWT Gadgets API project in it. Next, we run the GWT projectCreator to create our ant and Eclipse files:

./projectCreator -ant HelloGadget -eclipse HelloGadget -out ~/src/HelloGadget/ -addToClassPath ~/src/HelloGadget/lib/gwt-gadgets.jar
Created directory /Users/dkappe/src/HelloGadget/src
Created directory /Users/dkappe/src/HelloGadget/test
Created file /Users/dkappe/src/HelloGadget/HelloGadget.ant.xml
Created file /Users/dkappe/src/HelloGadget/.project
Created file /Users/dkappe/src/HelloGadget/.classpath

Now we create a simple sample application using the applicationCreator tool:

./applicationCreator -eclipse HelloGadget -out ~/src/HelloGadget/ -addToClassPath ~/src/HelloGadget/lib/gwt-gadgets.jar com.pathf.demo.app.gwt.client.HelloGadget
Created directory /Users/dkappe/src/HelloGadget/src/com/pathf/demo/app/gwt
Created directory /Users/dkappe/src/HelloGadget/src/com/pathf/demo/app/gwt/client
Created directory /Users/dkappe/src/HelloGadget/src/com/pathf/demo/app/gwt/public
Created file /Users/dkappe/src/HelloGadget/src/com/pathf/demo/app/gwt/HelloGadget.gwt.xml
Created file /Users/dkappe/src/HelloGadget/src/com/pathf/demo/app/gwt/public/HelloGadget.html
Created file /Users/dkappe/src/HelloGadget/src/com/pathf/demo/app/gwt/public/HelloGadget.css
Created file /Users/dkappe/src/HelloGadget/src/com/pathf/demo/app/gwt/client/HelloGadget.java
Created file /Users/dkappe/src/HelloGadget/HelloGadget.launch
Created file /Users/dkappe/src/HelloGadget/HelloGadget-shell
Created file /Users/dkappe/src/HelloGadget/HelloGadget-compile

You now have a nice little application that you can run using the hosted mode script HelloGadget-shell in the src/HelloGadget directory. Congratulations, you have a sample GWT application.

But we want a Google Gadget. In order to make it a gadget, we have to change the code a bit. First, import the project into Eclipse. Then open the HelloGadget.gwt.xml and add the following inherit statement.

<!-- Other module inherits                                      -->
	  <!-- Inherit Google Gadgets API -->
	  <inherits name="com.google.gwt.gadgets.Gadgets" />

Now let's open up the HelloGadget.java file. We're going to change it around a bit so it can be a gadget. The critical part of the original looks like this.

public class HelloGadget implements EntryPoint {
 
  /**
   * This is the entry point method.
   */
  public void onModuleLoad() {

We change our class to extend Gadget and change the onModuleLoad method to init.

@ModulePrefs(title = "HelloGadget", author = "Dietrich Kappe", author_email = "dkappe@gmail.com", height = 300, description = "A simple gadget.")
public class HelloGadget extends Gadget<UserPreferences> {
 
	/**
	 * This is the entry point method.
	 */
	@Override
	protected void init(UserPreferences preferences) {

You have to also import the following three classes:

import com.google.gwt.gadgets.client.Gadget;
import com.google.gwt.gadgets.client.UserPreferences;
import com.google.gwt.gadgets.client.Gadget.ModulePrefs;

Running the Darned Thing

Done! Well, not quite. While changing the EntryPoint to a Gadget was pretty straightforward, we now need a container to run the thing. Mind you, it will still run in it's current form in hosted mode, but all of those things it's expecting from iGoogle are not going to happen. So it's time to inject it into iGoogle.

Go ahead and compile the code using the shell command HelloGadget-compile. The resulting compiled JavaScript and sundries is under the www directory in your projects home. If you take a look, you'll see a new file that you likely haven't seen before, namely com.pathf.demo.app.gwt.client.HelloGadget.gadget.xml. This is the gadget manifest. Essentially, this is what your gadget container needs to load to display the app. Many of the parameters are set by the parameters to the @ModulePrefs annotation.

Bundle this app up and upload it to your publicly available server. In my case, I've uploaded the app here. This is the link to the XML file. You can now go to the sandbox and, using the My Gadgets gadget, add it to your sandbox.

You can tweak some of the settings having to do with caching of he Gadget resources with the MyGadgets gadgets, but more on that later. Next time we'll set up our simple Gadget in various other containers and perform something a little bit more useful with it (but only a little).

As always, comments and questions are welcome.

At times that can seem like a cop out, an admission of defeat in the face of the Flash arsenal of graphic effects. Somtimes, like today, it seems more like a visionary declaration of the power of Canvas. Check out Steven Wittens' use of Canvas for projective texturing. Maybe there is a little bit more coolness left in these Ajax bones.

As I blogged a few weeks ago, I ported the Java chess library ChessPresso into GWT, which was a blast and an example of how you can leverage existing Java libraries to write browser-based apps.

In the example, I've pulled the eleven games of the recently completed world championship between Anand and Kramnik in a single page. The GWT app identifies all of the relevant tags, reads the PGN (Portable Game Notation) in those tags, then inserts a game viewer widget into the page.

What isn't working yet:

• Doesn't look so good in IE (a little CSS work)
• The notation pane isn't hooked in so you can click on a move and jump to the position

Anyhow, have a look and let me know what you think.

Update: OK, the notation panel is hooked up to allow clicking on moves to navigate aroung the game. Still looks like crap in IE, though.

Update: for those interested in some of my very few games that make me look good, see here.

Update: Another set of tweaks to display a collection of games, one 41 games PGN chunk and a 250 or so chunk. See here.

• Amazon EC2 is offering Windows on EC2, with the pricing at $0.125 per hour for a small instance running Windows Server (as compared to $0.10 for a Linux instance). You can run SQL Server Express at no extra charge. The SQL Server Standard smallest instance (Stadard Large) rings in at $1.10 per hour, however, which ain't such a good deal.
• Microsoft's Azure Services Platform. It's still in community evaluation mode, but there is one thing that is already clear about it: it's as confusing as all git out. One of the advantages of Amazon's services like S3 and EC2 is that they are simple and can form the building blocks for other applications and services.

If I'm provisioning a web application, I'm pretty comfortable thinking in terms of virtual servers or instances. Not sure how to think about scaling and cost with Azure. I think MS would have done better to start out with a KISS approach to drive adoption. Time will tell if their "it can cure cancer" approach will work out.

This is a bit different from Didier's gOpenSocial library, which was an early success at building OpenSocial gadgets with GWT. But the google gadget library isn't really quite ready for OpenSocial. I've skinned my knee here and there, so I thought I'd give others the benefit of my experience.

So, first thing, how the heck do I get GWT to generate the

 
<Require feature="opensocial-0.7" />
 

line into my manifest?

Is it a parameter to the @ModulePrefs annotation? No. It's not. The way the GWT gadgets API deals with required features is by defining an interface that the Gadget class then implements.

 
package com.pathf.gwt.simplegadget.client.api;
 
import com.google.gwt.gadgets.client.GadgetFeature.FeatureName;
 
@FeatureName("opensocial-0.7")
public interface OpenSocial {
	void initializeFeature(OpenSocialFeature feature);
}
 

The feature itself extends com.google.gwt.gadgets.client.GadgetFeature and looks like this.

 
package com.pathf.gwt.simplegadget.client.api;
 
import com.google.gwt.gadgets.client.GadgetFeature;
 
public class OpenSocialFeature implements GadgetFeature {
	private OpenSocialFeature() {
	}
}
 

The class declaration for my simple gadget then looks something like this:

 
@ModulePrefs(title = "SimpleGadget", author = "Me", author_email = "me@gmail.com", height = 300, description = "A simple gadget.")
public class SimpleGadget extends Gadget<UserPreferences> implements OpenSocial {
 

There are some drawbacks to this particular approach, specifically that the version of OpenSocial is hardcoded into the interface. Future versions of the GWT gadgets API should probably approach this in a different way.

Anyhow, I hope I've saved some folks the trouble of figuring out how to write the OpenSocial requires into the manifest. I'll show how to overcome a few of the other stumbling blocks on the way to building a full featured OpenSocial gadget.

To recap, the idea is that you can write code like this

 
JSONValue root = JSONParser.parse(json);
JSONWrapper obj = new JSONWrapper(root);
String result = obj.get("map").get(1).stringValue();
 

when dealing with JSONValue objects.

As it's only one class, you could just include it in your source tree as code instead of using the jar.

JSONValue root = JSONParser.parse(json);
JSONObject obj = root.isObject();
if (obj != null) {
    JSONValue map = obj.get("map");
    if (map != null) {
        JSONArray arr = map.isArray();
        if (arr != null) {
            if (arr.size() > 1) {
                JSONValue strval = arr.get(1);
                if (strval != null) {
                    JSONString str = strval.isString();
                    if (str != null) {
                        String s = str.stringValue();
                        // do something with the string
                    }
                }
            }
        }
    }
}

Yikes! Just to get the string in the second array item in the "map" key of the top level object. Truth is, most of the JSON I'm getting back is fairly predictable. And if it's not in that predictable form, it's an error that the client code can't recover from. I'd like to be able to write something like String result = obj.get("map").get(1).stringValue() without having to worry about NullPointerException's cropping up all over the place.

One option is to do what other developers have done, which is to use JNSI to roll out own JSON handling code. But that defeats the purpose of a framework like GWT. I'd rather leverage what's already there than come up with my own code which I'll then have to support.

So I've written up a little helper class called JSONWrapper that lets you do the above style code. It's pretty simple. As it's name suggests, it wraps a JSONValue object and lets you perform selections on it that return other JSONWrapper objects. Thus you can string together the method calls with method chaining (ala JQuery).

public class JSONWrapper {
    private JSONValue value;
 
    public JSONWrapper(JSONValue value) {
        this.value = value;
    }
 
    public JSONValue getValue() {
        return value;
    }
 
    public final static JSONWrapper NULL = new JSONWrapper(null);
 
    public boolean isValid() {
        return (value != null);
    }
    [...]
}

If at any point a request results in an invalid value, such as requesting an array index from a non-array, we return a JSONWrapper with null as its value. We reuse the NULL constant to save on some memory.

    public JSONWrapper get(int index) {
        if (index < 0) {
            return NULL;
        }
        if (value == null) {
            return NULL;
        }
 
        JSONArray arr = value.isArray();
        if (arr == null) {
            return NULL;
        }
        if (index >= arr.size()) {
            return NULL;
        }
        JSONValue retval = arr.get(index);
        if (retval == null) {
            return NULL;
        }
 
        return new JSONWrapper(retval);
    }

We want to distinguish between JSONNull and our null values, since sometimes the backend will really want to pass a JSON null.

I'll put this up on google code in a day or two. It's just one class (though one I find really useful). Perhaps this shouldn't be a module but rather find a home in another library.

Some other things I've been working on: StringReader for GWT and a simple model Observer/Observable library.

Update: The lib is now available on Google Code.

Server-on-demand providers like Amazon's EC2, Joyent,
and others have reduced the capital necessary to launch scalable,
server intensive businesses. Google has just launched a similar
on-demand service, and companies like RightScale and CohesiveFT are building mature businesses around managing EC2 configurations.

...

Facebook applications are just the most extreme example of business initiatives that can be scaled on demand from $70/month on one EC2 server to $10,000/month on many dozens of servers running web, application and database server clusters and farms. Compare that with the old school of investing in a large data center with a significant fraction of the hardware and bandwidth that you might need if your business is a success. What used to cost $100k in capital can now be done with just a few hundreds of dollars.

...

And it's all possible as long as you are using a unix variant - Linux for the most part - to power your apps. So there is a whole class of companies out there using Linux that can out compete their Windows-using rivals - again, the capital they need to launch is much smaller because of cloud computing. That means Linux will win among the class of young entrepreneurial businesses that are so vital to the US economy.

It seems that Microsoft has spotted this gaping vulnerability and is seeking to close it. From the Amazon announcement on support for Windows on EC2:

Starting later this Fall, Amazon Elastic Compute Cloud (Amazon EC2) will offer you the ability to run Microsoft Windows Server or Microsoft SQL Server.

...

Customers will only pay for as much or little as they actually use; of course the actual price will be higher than Linux-based instances, due to the cost of Windows licenses. We’ll announce specific pricing when we make the service broadly available later this Fall.

Combine this with the announcement earlier this month that you could officially run Oracle on EC2 (though you still have to license it rather than pay as you go), and it's clear that commercial software vendors are feeling the preasure of SaaCS (Software as a Commodity Service).

Some of the highlights from Ted's talk:

• If you like CruiseControl, but it's too fiddly for you, you'll love Hudson, a much more user friendly continuous integration engine.
• The Selenium IDE is great for getting started or smoke testing, but use the API's (in Java, C#, Ruby, etc.) to get real, supportable unit tests done.
• YUI Test is intrusive, but it overcomes some of the shortcomings for testing asynchronous events that are present in JsUnit and Selenium. See Ted's post on YUI Test.

OK, not sexy, but if you want to develop quality software, you have to keep an eye on the non-sexy bits.

Monopsony - the market condition that exists when there is only one buyer.

We all have heard the term "monopoly" and even know a little bit of what it means - a market where there is only one seller. But the related term "monopsony," a market where there is only one buyer, is not as well known and it's dangers not as well understood.

Certainly both monopolies and monopsonies will reduce competition, innovation and consumer choice, but they further constitute a big risk for the sellers. For businesses on the seller side a monopsony can be the kiss of death. Just ask Walmart's suppliers how good it's been for them.

Not all monopsonies are as obvious or as overtly damaging to suppliers as that of Walmart, but Apple's iPhone and iTunes appstore looks like a benign monopsony. A monopsony in that although the iphone consumer is the ultimate buyer, Apple determines what is permitted in it's appstore, and benign in the fact that Apple hasn't flexed that restrictive muscle more than a few times.

But for the business launching an iPhone app this monopsony - benign or not - presents a real concern, a real business risk. What happens if Apple decides to compete in your space? The evidence on what happens right now is not encouraging. Take the recent example of the podcasting application that was excluded from the AppStore. The reason for it's exclusion?

Since Podcaster assists in the distribution of podcasts, it duplicates the functionality of the Podcast section of iTunes.

That's the desktop version of iTunes versus an application on the iPhone that you can use without a PC or Mac. Presumably, if people don't have to use iTunes to get their podcasts, then there's less reason to use iTunes and consequently less chance that they'll actually spend money with Apple.

Since you only find out whether your application will be approved in the last step, i.e. after all of the hard development work has been done, that's a lot of risk to take. How to minimize it? One approach to minimizing risk might go as follows:

• Distribute an application with an initial pretty minimal set of functionality. Quick to produce and get the yes/no appstore answer.
• Design your application so that it supports and embedded language runtime, such as Ruby or JavaScript, and a capability to push additional modules of functionality to the application independent of the appstore.
• Extend your application using the above distribution mechanism. The only time you'll have to push a new version of the app is when the underlying iPhone platform changes and you'd like your embedded layer to take advantage of new features.

Of course Apple is known to have a "kill switch" to turn off apps that have already been downloaded to a phone, so even the above approach may not insulate you from risk. So, if you are developing for the iPhone, have a care on whether your application will run into competition from Apple. You may find your application unceremoniously rejected or killed.

Update: Looks like Apple has  banned another application, MailWrangler, that competes with it's own email application.

The basic idea here is that while the browser is the View and the server side is the Model and Controller in MVC, you really should structure your browser side code as an MVC itself where only the Model interacts with the server.

Well worth a read.

• Comet server push
• Customization of look and feel
• Performance monitoring

Server push via polling has been available in ZK for a while, and Comet in the ZK "Enterprise Edition," but now it is available to everyone. And it is pretty easy to use: "The implementation of server push is transparent to developers. ZK chooses which implementation to use according to the edition of ZK automatically, but it is configurable."

Customization of look and feel has gotten much easier. ZK has followed the example of a number of other frameworks in styling its widgets with predictably named CSS styles. Changing the look and feel of an application is now as easy as changing the ZK widget style sheet. Styles can further be overridden on a widget instance-by-instance basis.

Performance monitoring is perhaps the most exciting new feature. Client-side tools such as YSlow can guide optimization efforts and give you point in time performance snapshots. But critical applications need to be monitored and tracked end to end over their lifespan. With ZK 3.5, you now have the plumbing to instrument your application to capture five data points for each request:

• T1, the time browser sends a request to server
• T2, the time server receives a request
• T3, the time server sends a request to browser
• T4, the time browser receives a request from server
• T5, the time the browser finishes processing a request

ZKStudio 0.8.2

There's also a new version of ZKStudio for Eclipse out. The major change is that it now supports auto update via http://studioupdate.zkoss.org/studio/update

Throughout it all, I've been trying to obey my own principle of avoiding leaky business logic and sensitive data. That means that most of the heavy lifting, business logic wise, happens on the server side.

This past weekend, however, I got a rare chance to do some programming for myself. One of my hobbies is chess, and I've written a few programs over the years to help me study and analyze the game. Right now I'm putting the plumbing together for a web/iphone application site. I've got all the stuff that handles FEN, move generation, PGN and UCI (interfacing to chess engines) on the server side, and the application side is mostly concerned with board displays.

It seemed kind of inefficient to make a round trip for every FEN or move generation operation, so I thought I'd write a simple bit of chess code in Java and compile it as a library using GWT. After all, this isn't proprietary or high security business logic that can't sit in the browser. Before I did that, though, I took another look at my favorite chess library, Chesspresso. It's a sort of swiss army knife chess utility library that was originally developed for a chess database application. Big, sophisticated, nice.

An hour later after stripping out all of the java.io.* specific code, I had a nice GWT library that did FEN, move generation and position state for me, all in a pretty svelt 50k of JavaScript code. I had an "aha" moment very similar to the one I had on seeing "write once, run anywhere" actually work with Java on Windows and Solaris back in 1998. Here I could port this non-trivial Java library to run in the browser in literaly a matter of minutes. I was jazzed about GWT all over again.

The idea isn't to write a high performance chess playing program. Even with all of the performance improvements in TraceMonkey, you're not going to be able to get that kind of speed out of current JavaScript engines. But to avoid having to make a round trip for every chess specific bit of logic, this is certainly a good way to go.

I'll have an iPhone version of my analysis app up by the end of October, depending on how many free weekends I get.

If you can dream it, you can do it.

-- Walt Disney

You have a great idea, an idea that is going to transform an industry. You've turned a venture capitalist's head with your presentation and now you just need a software development firm to translate your vision into reality. This is where the trouble starts.

If you move in startup VC circles, you see enough of these deals go sideways or never get off the dime. Investors see hundreds of thousands or millions of dollars plowed into software development without a usable product or service coming to light. Fingers are pointed; tears are shed. For every success there are a half dozen failures. Why is that?

In my experience it all comes back to that word, "vision" as in "translate your vision into reality." What the heck is vision? If you've ever cracked a book on software project management (or just general project management), there's usually a section about having a project charter and a vision statement. As a young developer I would wince and turn to the next chapter. After all, I thought, isn't vision the same thing as what you're going to build? Isn't scope or, more basically, a list of things your are going to build, the same thing as "vision?" Why blather on in consultant speak about vision statements when a more concrete and practical project description could be had?

And this is where the trouble starts. If you don't have a clear idea of what you are building but have a bright and effective development team, you may still come up with a plausible list of things to build. You'll crank along, iteration after iteration, turning out software -- that is, after all, what a good development team does -- but you are likely not developing the right software.

Poor Vision: Are We Building a Spreadsheet or a Word Processor?

Poor vision is not the same thing as bad vision. You may have a very clear idea of what you want to build but it may suck, like the company that wanted to build a laptop software management suite based on cc:Mail in the face of the burgeoning web. No, poor vision means that you have a poor or incorrect notion of what you want to build.

Hopefully most of these ambiguities have  been cleared up by the heartless venture capitalists, but just in case, let's do an exercise. Answer the following questions about your proposed software:

• Do you know who your customers are? Not just traders, but day traders above a certain trading volume in options and futures.
• What is your value proposition? Why would someone actually use your software? Don't use "wonderful" or "joy" in your description.
• What specifically will your users be doing with your application? Don't use abstract verbs like "collaborate" to describe their actions.

If you can't put together a one or two paragraph description of your software that answers these questions, you just have a cool idea, not a vision. As a friend of mine likes to say, "that's crap...it's not something you can develop software from."

At this point you may be scratching your head and wondering what kind of idiot would launch into development without a good vision. It seems so obvious. The truth is that coming up with game changing business ideas is hard work, and in conceptualizing the business opportunity, you may fail to articulate a precise vision. Whatever the reason, software project launching with poor vision is all too common.

Poor Vision: The Version 2 Problem

There are other types of vision problems beyond a lack of clarity and focus. One common case is the "version 2 problem." This is where the stakeholder just focuses on the "new" things that are to be present in version 2 and ignores all the hard work that has to be recapitulated just to get them to where version 1 was. Asking the question "what are we building?" should lead you to realize that what the stakeholder is expecting is enhancements to version 1, not a complete rewrite or redesign. The why are they talking about a "version 2?" Ideally this should lead to a discussion that clarifies vision and expectations.

Poor Vision: Integrating the Wrong Systems

Poor vision isn't just limited to custom software development. Sometime the job calls for customization or integration of existing software packages. The vision problem here is that sometimes stakeholders will look at the feature list of an application and the fact that it has an API and conclude that tweaking the beast into your ideal solution is a piece of cake.

Here the solution is simple: make the stakeholders get their hands dirty. Force them to use the system in question -- no, vendor demos are not enough -- to accomplish some non-trivial tasks. This exercise, combined with an analysis of the power and expressiveness of the API, should resolve any vision dissonance.

The Perils of Agile Development

Poor vision is a problem that can strike any project and any method ("methodology" is the study of methods, right?). Agile development, however, is especially susceptible to it's chaotic effects. Why is that? The great strength of Agile development is that teams start developing and delivering software right away so that the client-developer feedback loop can operate early and often. If that feedback is useless -- as it is when you have poor vision -- the Agile development process can turn into a meandering mess, with features being scrapped, redeveloped and re-redeveloped.

How do you avoid this trouble? Simple: if your vision is poor, don't develop software.

Software development is a surprisingly expensive way to do product definition.

Waterfall, by comparison, is marginally better in this regard (but worse in most others), since the right thing to do in the face of poor vision is to not develop software until that vision has been clarified, and waterfall is excellent at not developing software until pretty late in the project.

That's not to say that you can't get stung by poor vision in waterfall projects (and stung by a number of waterfall's other shortcomings), but you've got more of a chance to catch the problem before expensive developer teams are deployed.

Fixing Poor Vision: Product Definition

The best way we've found of fixing poor vision is by going through a product definition phase. It can still be iterative and agile, so don't worry that you're slipping into a waterfall requirements phase. Just do some of the user research and product conceptualization up front. Use wire-frames and the like rather than code to spitball ideas and narrow in on a definitive product concept.

I'll have more to say on product definition in subsequent posts. For now, I hope I've convinced you of the importance of having a clear vision if you expect to succeed with software product development.

First you have to find the appropriate page among the 300 or so flogging IE8 Beta 2 in the MS redundaverse. Drilling down into performance, you find the terse:

...the script engine in Internet Explorer 8 is significantly faster than in previous versions, minimizing the load time for webpages based on JavaScript or Asynchronous JavaScript and XML (AJAX).

OK. Faster. Faster how? How much faster?

It used to be that JavaScript engines were so slow that benchmarks served mostly to show that they weren't suitable for anything serious (slow and slower). It's time for some head-to-head benchmarks. Stay tuned.

Now surprise, surprise -- SpiderMonkey can do JIT as well, as Brendan Eich, Mozilla's CTO describes in his blog. The technique used in both Tamarin and SpiderMonkey is called tracing, where during code execution, each hotspot (code that is executed a whole lot) is traced and compiled, so the next time it is executed, the compiled version is used. The beasty is called TraceMonkey and boasts several orders of magnitude improvements over the old SpiderMonkey.

Since this JIT involved actual compilation, you have to look at which architectures TraceMonkey supports. Again from Brendan's blog:

We have, right now, x86, x86-64, and ARM support in TraceMonkey. This means we are ready for mobile and desktop target platforms out of the box.

Sweet. I guess that means the Intel Macs are supported.

There are still some bugs, of course, but this is great news for sophisticated Ajax apps on Firefox. Will Microsoft respond? Is a JavaScript JIT upgrade in the works for IE? This is an arms race I can get excited about.

Update: John Resig of JQuery has some more details and demos about TraceMonkey.

1. 37Signals - yes, the company where it all started is headquartered in Chicago. They're out of the professional services business and selling software built in RoR, but we used to see them as a competitor and have tried to emulate some of their business plans.
2. Pathfinder Development - yes, the small but growing RoR powerhouse is also headquartered in downtown Chicago. They combine Agile development, User Experience Design (UXD) and RoR to develop "extraordinary applications," as it says in the tag line to the right. Watch for our Rails-based competitor to Mingle, Tasker, in the next few months. Of course we also have Noel Rappin, author of Professional Ruby on Rails.
3. ThoughtWorks - global IT consultancy, but an OO and Agile Rails development shop at heart. Their Agile project management product, Mingle, is implemented in Rails.
4. Centro - they're all Rails, all the time. Their core business is "providing the most comprehensive platform and services to help agencies easily and effectively buy local online media," but they have an impressive team of Rails developers powering their development. Heck, they're just a handful of blocks from us. We may have more Rails developers per square mile than any other neighborhood in America!
5. WindyCityRails - our own local Rails conference (yes, we sponsor it).
6. Two, count'em, two active Ruby groups, ChicagoRuby.org and the Chicago Area Ruby Group.
7. Obtiva - another Agile and Rails shop, this one in the suburbs.

Think your town deserves the title of Rails-town USA? Bring it on!

Now the folks at the Restlet project have ported the Restlet API to GWT.

Thanks to the support for generics in GWT 1.5 RC1, we were able to achieve this port with reduced efforts and limited troubles. We had to get rid of the server-side features that don’t make sense in a browser, and of the APIs like NIO and logging that aren’t emulated by GWT. The major impact was the adaptation of the API to the asynchronous communication imposed by AJAX and GWT.

So now you can make much easier use of RESTful back ends. If you've been working with Rails or Grails, you won't have to ask why RESTful backends are good. If you want a quick intro to Restlets, see this quickstart.

Metawidget takes your domain objects and automatically creates User Interface widgets for them, saving you handcoding your UIs and leaving you to concentrate on stitching together your application.

Think of a configurable form widget driven off of your beans through runtime inspection of properties, getters and setters, annotations, etc.

But wait, there's more. It automatically detects your backend at runtime and makes friends with Hibernate, Spring, Seam, Groovy, etc.

But that's not all you get. MetaWidget will work with JSF, Swing, GWT, Android, Struts, and on and on. I'm just scratching the surface here, including how it will work with IDE GUI Builders and such.

Definitely check out the MetaWidget tutorial.

Just a little taste of MetaWidget code from the tutorial:

 
public class Person {
	public String name;
	public int age;
	public boolean retired;
}
 
import javax.swing.*;
import org.metawidget.inspector.propertytype.*;
import org.metawidget.swing.*;
 
public class Main {
	public static void main( String[] args ) {
		Person person = new Person();
 
		SwingMetawidget metawidget = new SwingMetawidget();
		metawidget.setInspector( new PropertyTypeInspector());
		metawidget.setToInspect( person );
 
		JFrame frame = new JFrame("Metawidget Tutorial");
		frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
		frame.getContentPane().add(metawidget);
		frame.setSize(400, 220);
		frame.setVisible(true);
	}
}
 

I have a couple of tedious GWT/Swing apps with lots of forms that are going to see and application of MetaWidget.

in Technical Blogs

The self licking ice cream cone that is blog awards has dripped on Agile Ajax. We've gotten a nod from Computer Weekly for the IT Blog Awards 08 as one of the best programming and development blogs. Funny thing, it's a list for the UK, and we've got offices in Chicago and New York.

To curry favor with the voters, we'll start blogging about tyre's and setting colour in CSS. What is it they say? Two peoples divided by a common language?

Anyhow, the self licking ice cream cone part. Go and vote for your favorite. Unfortunately, since we didn't make the short list, you can't stuff the ballot box for us.