chrisk

I’m not sure if Laszlo Systems would approve of this, but I found something that improves the speed of rendering views that are changing their dimensions or positions rapidly. In our application, we need to resize and move many views all at the same time, repeatedly. During all this, we also need to adjust xoffset and yoffset since these views might be rotated. All this view morphing puts a heavy strain on the system, and performance noticeably suffers as a result. I was poking around in the OpenLaszlo source code, and discovered that when you set the xoffset or yoffset attributes using setAttribute(), setX() and setY() are invoked internally.

Our code looked something like this:

   while( aBunchOfTimes ) {
        //setX() and setY() invoked internally by LzView
        someView.setAttribute('xoffset', someView.width/2 );
        //setX() and setY() invoked internally by LzView
        someView.setAttribute('yoffset', someView.height/2 );
        someView.setX( anewx );
        someView.setY( anewy );
    }

In the above case, setX() and setY() are being invoked a total of 6 times. It turns out that setX() and setY() and costly enough operations that this is worth optimizing. How do we speed things up? I went ahead and changed the above code to look something like this:

   while( aBunchOfTimes ) {
        someView.xoffset = someView.width/2;
        someView.yoffset = someView.height/2;
        someView.setX( anewx );
        someView.setY( anewy );
    }

What’s going on here? setAttribute(’xoffset’) and setAttribute(’yoffset’) cause internal functions to be invoked which in turn invoke setX() and setY(). If you assign a value to xoffset and yoffset directly, as I’ve shown in this last example, the internal functions are not invoked. When I finally do invoke setX() and setY() on my own, the OpenLaszlo view system does whatever it needs to do with xoffset and yoffset to keep everything in order. It turns out this simple change made a very noticeable performance improvement in our application. (Clint said, “It’s smooth like butter!”)

Yay for open source!

It’s important to note that this optimization now depends on specific internal behavior of the OpenLaszlo view system. Obviously, this goes against the rules of code abstraction, and we run the risk that our application might break if the internal workings of the OpenLaszlo view system change significantly. In our first round of user testing, we found that performance was a significant factor in making happy users, so we think this risk is worth it.

Get ready folks, Rich Internet Applications (RIA’s) will soon have you doing things on the web which you thought were only possible with desktop applications. These new web based applications will soon have you collaborating in ways you never thought possible, increasing the overall efficiency of companies in many ways. Here are a few interesting reads which all point in this general direction:

• Jason Fried of 37Signals predicts that most innovative software in the next 10 years will be web based
• Robert X. Cringly suggests “After a decade of messing around, thin client computing is almost inevitable for businesses. “
• Evan Williams of Odeo posted a while back about running your company on web apps.
• Michael Sica of Ataraxis Software will be developing his Project Management software using OpenLaszlo. I think you’re on the right track Michael, and I can’t wait to see what you come up with!

What could this all mean? I have a few predictions:

• As RIA alternatives begin to arrive on the scene in the next 1-2 years, progressive folks will stop using traditional desktop applications, including ALL Microsoft Office products.
• Lighter weight RIA alternatives to traditional desktop applications will offer collaboration opportunities far beyond those which are available in their desktop counterparts.
• Microsoft knows this trend is in the works, and will be mostly helpless to stop it until Windows Vista has greater market share.
• Many of Microsoft’s big money making software titles will be threatened. Microsoft stock will take a big hit when this trend becomes clear to the masses.
• Microsoft will find a way to create problems for RIA’s. A few possible scenarios:
  • The new version of IE will break existing AJAX RIA’s in subtle ways
  • The new version of IE wont play well with Flash, causing trouble for Flash based RIA’s like OpenLaszlo and Flex applications
  • Microsoft will create and bundle it’s own Flash player, breaking Flash based RIA’s which threaten their desktop application dominance.
• SocialText and JotSpot will be leading the charge (if they don’t get acquired by Yahoo or Google first)

What do you think?

In previous start-up companies I’ve worked at, it’s been implied that the official development process was something along the lines of Extreme Programming (XP) . In the book Extreme Programming Explained by Kent Beck, it is suggested that Pair Programming is an essential element to effective development with XP. So why is it that none of my managers encouraged pair programming as a regular development practice? I think one reason is that it seems counter-intuitive that a pair of developers can produce more code with higher quality on a single computer than that same pair working on two different machines.

One great thing about starting your own company is that you have more flexibility to experiment, so Clint and I have taken the opportunity to try some pair programming. Our most recent adventure into pair programming was an effort to build a new feature into our top secret project which would enhance usability greatly. The feature (which I’ll likely discuss in a future post) is really hard to implement…. so much so that of our three main competitors, all of whom who have had commercial products for over 5 years, only one of them supports this feature fully. Through careful collaboration in the design process, and then pair programing to turn our design into reality, we were able to get this feature working fairly well in a matter of several days. When I tried to build this feature out on my own previously, I probably spent 5-6 days implementing it and debugging it, with an unacceptable result.

Why is pair programming better?

• Problem solving - When working on hard problems, two brains are better than one. Often when I would be stuck on a difficult conceptual problem, Clint would have a solution that I hadn’t though of. This kept our momentum going, and allowed us to make rapid progress.
• Faster Development - When I was at the keyboard, Clint often spotted stupid mistakes I’d made (or visa versa). This allowed us to correct the mistakes before we compiled and tested the code, drastically reducing debugging time.
• Quality - Having the input of two people during the design process has a tremendously positive impact on your design. Having two eyeballs on the design will help reduce the risk of introducing mistakes, and help increase your chances that you’ll get the best design in place early on.
• Focus - I literally think the internet is giving me ADD. When pair programming, you are squarely focused on the task at hand. Distractions such as IM or email are less likely since that would be rude to the person you are working with. This intense focus makes a huge positive difference with anything you work on.

I’m sure pair programming isn’t for everyone, but I think we’ve been able to solve hard problems that we wouldn’t have been able to otherwise. While we haven’t decided to make pair programming something we do 100% of the time, I think that whenever we face a difficult problem in the future, pair programming will be the natural choice.

Even as a former employee of Laszlo Systems, deciding which Rich Internet Application framework to use for the new venture was harder than I thought it would be. Clint and I really wanted to use OpenLaszlo, but AJAX was making headlines. Furthermore, AJAX/DHTML applications were being successfully deployed all over the place. Even though it’s challenging to question using a technology that you’ve invested 2 years of your career on, when starting a new company, you better do it or risk paying for that decision later.

Some pros of OpenLaszlo include:

• Clint and I know LZX, Laszlo’s markup language, really well (Clint was the lead developer on the ColorSmart Application for Behr Paints).
• Since Macromedia tightly controls the Flash web browser, you can be sure that 99% of what you write will run in any browser that has flash 6 or higher installed. (At the time of this writing, Macromedia claims that flash 6 or higher is running in over 96% of web browsers out there)
• At the moment, LZX is a lot more elegant, and fun to write when compared to AJAX. (though, there are several frameworks out there that are trying to change this)
• LZX gives you constraints, delegates, animation, data binding/replication out of the box for free
• No need to cobble together scraps of code from all over the place to build a framework…. it’s all there for you in one nice place
• OpenLaszlo is open source, making deployment costs much lower. We thought we had enough experience with Laszlo that we could get by for a while without paying for support.

Some pros of AJAX include:

• There are many examples of deployed AJAX applications out there. The developer community around DHTML/AJAX/whatever has been around a LONG time.
• It’s not flash. Be it justified or not, developers are always wary of flash. I think this has something to do with the gratuitous flash animations that you occasionally see misplaced on corporate web sites. For our purposes, if we ever expected to sell our application, developers have to see this as something they could work with.
• Javascript in the web browser is WAY faster than it is in flash. While this isn’t too much of an issue in Laszlo apps on fast hardware, slower hardware can have some issues in certain situations

(If you think I’m missing something critical in these lists, feel free to let me know and I’ll update it)

So what did we decide? We eventually concluded that utilizing our Laszlo skills would give us a competitive advantage, and decided that whatever project we choose to chase down (there were many) should be something that Laszlo is perfectly suited for, and would either be impossible or really hard to do in DHTML. We are really excited about the project we’ve started working on, and can’t wait to show it off soon!

Need help deciding if OpenLaszlo is right for your project? For a limited time, I’m available for one day consulting gigs. Email me at:

In May of 2005 Clint and Lyla quit their jobs to start Silver Tie Software. with me. Dana followed suit shortly thereafter. The focus of this blog will primarily deal with our business, but will likely also contain entertaining bits of fun I discover along the way.