Jake@Nitobi

Safari 3 has a Javascript interface to the browser’s XSLT processor. Adobe AIR, like Safari, is built on the WebKit engine. Unlike Safari, there is no scripting interface to XSLTProcessor - scratch that, there is no XSLT processor period. That means that any standards-loving developers out there who code their pages in XML with embedded stylesheets (using <?xml-stylesheet type="text/xsl"?> processing directives) are hosed. It also means that RIA developers can’t make use of a wicked fast template processor in our apps.

To paraphrase a great man: that’s the power AIR developers don’t have. It’s power web developers have, which means it’s power AIR’s direct competitors Google Gears and Dojo Offline provide, but if you’re developing on AIR, you’re giving up that option. AIR has some unbelievable features. I want to drag and drop files from my desktop to my web app. I want to run my web app chromeless, and seamlessly within the host OS. But I need XSLT support or it’s going to be half-baked.

The only way AIR will get traction is by delivering more than the browsers. As it stands I’m looking at the only current-version browser renderer not to support XSLT. The XSLTProcessor code from WebKit is sitting in the AIR perforce repo, so there is some chance that 1.0 will ship with a working XSLT implementation. Adobe, consider this one vote in favour.

I just committed the following source in the Nitobi Grid code base.

this.element.scrollTop=st;
// This looks stupid but it is necessary to rejig 
// the scroll position. (IE Only) (Of course)
this.element.scrollTop = this.element.scrollTop;

Dying a little inside.

We’ve been looking at ways to get one of our Rails apps, RobotReplay, a web ‘cinelytics’ package to scale out as we add users. EC2 is an interesting possibility. There are a few issues with deploying that we need to deal with. I’ll detail them in this post and update it as we start making headway.

What’s my IP?

The central problem for deploying RobotReplay as a multi-server application on EC2 was the number of locations we need the other servers’ IP addresses. On an EC2 instance you can get your global IP by calling an EC2 web service:

curl http://169.254.169.254/latest/meta-data/public-ipv4

You can get the local IP address for inter-EC2 instance communication by calling another service:

curl http://169.254.169.254/latest/meta-data/local-ipv4

(You can also use ifconfig if that’s better for you).

Server Replication

Each new DB node needs to insert itself in a Multi-Master ring of MySQL databases. What that means is that we need to keep track of the IPs in the ring, and modify both the new instance, and it’s two new neighbors. We use memcached to cache in-progress recording sessions, so we also need to modify every server’s environment.rb’s to add the new memcached server. Another choice is to ignore that multi-server aspect of memcached and make sure that a session is always routed to the same appserver by our load balancer. Using HAProxy, the load balancer needs to be updated with information about the new server. That’s why we’d love to move to Swiftiply, a proxy that lets backend processes announce their availability.

Persistence

There’s nothing up there that’s too daunting, really nothing out of the ordinary for any multi-server app. But on top we add the impermanence of EC2 instances. If one goes down our data won’t suffer because we’re replicating it, but the Master-Master replication loop is broken. The hassle is that bringing up another instance won’t bring it up with the same old IP, so all your settings need to be updated: for memcached, for your load balancer, and for your database ring. Don’t forget actually deploying changes to your app. Capistrano is great, awesome, wicked, but needing to rewrite your deploy.rb as you add and remove servers on EC2 is teh sux.

Spoiled?

I’m spoiled by getting to work in Ruby all day - doing the heavy lifting of actually RUNNING a web app is considerably less fun. The tools for Rails and EC2 are happening, but it seems like that’s just the tip of the iceberg.

I’m at RailsConf07 in Portland until Monday. If anyone wants to chat about RobotReplay, or Nitobi Complete UI email me: jake.devine@nitobi.com

For our new project RobotReplay we’ve been looking into displaying data as overlays on images of websites. There is a quick and simple ActiveX component that we could use if we were still on Windows… but we’ve moved on to greener pastures and had to find a new way.

khtml2png gave us exactly what we were looking for. The only issue then was running it headless. After wrestling with Xvfb for a while with no success we tried with a vncserver and it worked just fine.

vncserver :1 -geometry 1024x768 -depth 24
export DISPLAY=:1
khtml2png2 --width 1024 --height 768 http://www.nitobi.com nitobi_image.png

khtml2png got us most of the way, but we still needed to reduce the images from 1024×768 to a more thumbnailish size (the width and height command line options specify the size of the browser window). We wanted to avoid a post-processing step like using imagemagick.

Adding your own scaling is as easy as changing a single line in the khtml2png.cpp file.

328

return pix->convertToImage().save(file, format);

becomes

328

return pix->convertToImage().smoothScale(scaledWidth, scaledHeight, QImage::ScaleMin).save(file, format);

Where scaledWidth and scaledHeight are values you want to scale to. Using QImage::ScaleMin as the third argument means that the image will scale to take up at most the area described by a rectangle with width = scaledWidth and height = scaledHeight. You can substitute QImage::ScaleMax to scale the screenshot to make it as large as it can be with either the width respecting scaledWidth or the height respecting scaledHeight.

I added command line switches for scaled-width and scaled-height to our copy of khtml2png. Download the khtml2png-nitobi patch here and patch against khtml2png-2.6.0.

wget http://blogs.nitobi.com/jake/files/khtml2png-nitobi.patch.zip
gunzip khtml2png-nitobi.patch.zip
cd khtml2png-2.6.0
patch < ../khtml2png-nitobi.patch

You’ll then need to build khtml2png from the patched source. Afterwards you can call khtml2png like so:

khtml2png2 --height 1024 --width 768 \
           --scaled-width 120 --scaled-height 90

The public beta of our component suite is now available. The included components are:

• Callout
• Combo Box
• Fisheye Menu
• Grid
• Tab
• Tree

Last, but not least,

• Nitobi Ajax Toolkit.

This includes the building blocks for all our components and should help developing your own solutions with Javascript and XML. In the next week on this blog I’ll be going over a component that I built with the Toolkit. Download the beta here and check out some samples of the new components right here.

Joel and I have been working on setting up a framework for cutting down on the development time for these components by sharing as much of the work as possible. He has a nice post up now about the early stages of nitobi.Tab, and how the XML serialization and deserialization will be working.

I’ll be developing a tree component using this framework. Our main goals for these products was to make them as lightweight as possible while maintaining the utmost flexibility for the developer. To that end, nitobi.Tree will be as configurable as we can make it, without sacrificing the simplicity at the heart of component-based development.

Features:

• Fully template driven, using HTML or even XSL.
• On-demand Ajax loading of large datasets.
• International character support.
• Simple CSS stylesheet themes.
• Configurable and extensible animated transitions for opening or closing nodes.
• Keyboard support.
• A rich event model.

I hope that gives you a good overview of what we’ll be shooting for with this product. I will highlight some of these features in upcoming installments of my development log, and give you the nitty gritty about any hurdles I hit. If you have any questions or suggestions, then leave a comment.