Skip Navigation Links

How we are working to improve App Builder

Posted by gregsmit on February 12th, 2009. Other posts by gregsmit

We on the sMash development team have been paying attention to the community here on projectzero.org, and what we have heard is that you want a faster, more responsive App Builder.  You want to be able to use App Builder for large, complex files and projects, and you are not quite sure that you can do that yet.

Well, we are listening, and we want you to know:  We want the same thing, and we are working on it.

In fact, we have spent the last week identifying where our problems lie, how they can be fixed, and prioritizing the order we are going to fix them.  I wanted to share with you here the way we have been going about these activities.

  • Profiling the client side javascript

Over the last week, we have been doing very heavy anaysis of where we are spending time within the browser in our client side code.  To do this, we have been using the increadibly helpful profiling tools available in Firebug.  Firebug can help you profile your code in two different ways:  It can directly give you information on how much time you are spending in given methods, and it can also allow console logging of times.  We have been using both in figuring out where we are wasting cycles.

While we have collected much profile data in Firebug directly, we have also added new instrumentation to App Builder, so we can see how long certian tasks are taking, and measure them over time.  This allows us to run tests on regular builds so that we can insure, as time progresses, that we are getting better and better performance.  To see these profile numbers, you can add “?profile” to the end of any App Builder URL, and the timing numbers will be printed to the Firebug console log, as in the following screen capture.

Here, you can see some of the timing information we are now able to collect.

Here, you can see some of the timing information we are now able to collect.

  • Analyzing App Builder network requests

Another area in which we have been looking to optimize App Builder has been in the amount of network traffic between the web client and the App Builder server process.  There is a lot of various connections going back and forth: autosave, building, validation, current application status, as well as others.  We have been doing significant cataloging of these connections, recording how often they occur, and how much data is flowing over them.  By doing this analysis, we believe we can improve the responsiveness and feel of the App Builder by eliminating unnecessary requests and reordering requests by priority.

  • New and improved UI test framework to assure App Builder quality

We have always had a large number of tests to verify quality before builds are published to projectzero.org.  But, we have never had enough client side UI tests to verify proper function with each build.  We used to use Selenium in our build environment for testing the App Builder’s UI, but we found that Selenium was just too fragile.  Tests would sometimes work, sometimes not.  And when the tests begin to fail often, with false errors because of the testing framework and not because of the quality of the code being tested, developers lose faith in them.  And when that happens, tests do not get updated often enough.

So we decided to move over to a new UI test framework based around DOH (Dojo Object Harness) and the new doh.robot.  The DOH robot allows automated tests to run in any browser with a Java Applet plugin, which will allows for easier developer setup than Selenium.  And we also found that integrating it in with our continuous integration build system was much easier.  Already, it has been more stable than our previous testing framework.  Plus, building new tests with DOH robot is more natural and much easier for our developers, so it is easier for our test coverage to increase.  We have already found a way to use DOH robot and our new profiling instrumentation in App Builder to create timings we can use with each build to mark our progress.  We are hoping to include our UI test harness built around DOH robot in next release of sMash.

We have been doing these tasks for a single purpose:  To improve App Builder and the WebSphere sMash development experience.  From the data we have collected, we already identified several areas where we are going to be concentrating over the next couple of weeks.  We are going to improve App Builder, so you can use it for any size application, any size task, any size project.

2 Responses to “How we are working to improve App Builder”

  1. Aldrin Leal Says:

    Something to think about:

    Comet anywhere?

  2. nicholsr Says:

    Thanks for this post Greg. Its important that the community are being listened to. Its really interesting to understand how you are setting about this too.

Leave a Reply