[UPDATE] This position is now filled.

We recently noticed that many of the users of Project Dirigible weren’t actually using it as a spreadsheet: instead, they were essentially using it as an online Python development environment. This sounded like a great idea, so we’ve started a new project: PythonAnywhere. It’s starting as a Python console in the browser, but we’re adding new features daily, and the plan is to gradually turn it into a fully-featured online Python IDE and cloud deployment platform.

If you’re interested, sign up for the beta waiting list today!

If you’d like to try it out, you can sign up for the beta program on the Dirigible web site; numbers are currently limited while we make sure it’s secure and stable, but we’re bringing more people on board daily.

If you’d like to know a bit more about Dirigible, and particularly how it fits in with Resolver One, read on!

Let’s take a look at Resolver One first. It’s a super-programmable desktop spreadsheet, targeted at developers and technically-savvy spreadsheet users. It works well with your existing Windows desktop applications, connecting seamlessly to .NET components, importing your documents from Microsoft Excel, and making it easy to script with IronPython. If you want it to talk to your Bloomberg console, there’s a plugin for that — and if you want to share your .NET environment over the network, there’s the Resolver One Web server.

By comparison, Dirigible was designed from the ground up for the more technical user, and plays to the strengths of utility computing. We took the things from Resolver One that made software developers say “wow” — like Python-based formulae, objects in the grid, and the ability to treat a spreadsheet as a function and call it from another sheet. Then we worked out what we could make better by coding just those things as a web application backed by traditional Python — not IronPython — on a grid of Linux servers. You can access your spreadsheets from JavaScript on your own web pages — building simple web apps using a spreadsheet. It runs your spreadsheets on a grid of servers (hosted by Amazon EC2) and makes it easy to build calculations that scale across that grid. (Imagine writing a spreadsheet to work out the price of a financial instrument, and then using 100 computers for a few seconds to price up a portfolio of a hundred of them.)

Of course, we couldn’t stop there — new ideas kept popping up. Why not make user code control how the spreadsheet is recalculated — perhaps you want to run the formulae multiple times within one recalculation to do goal-seeking? And surely we should make it easy for people to change formulae from any user code, not just button handlers? The great thing about improvements like this is that we can see how people like them in Dirigible, and bring them back into Resolver One if they work out well.

We’re proud of what we’ve created so far with Dirigible, but we know that early feedback is essential. So while it’s only a few months old, it’s already in beta — if you’d like to give it a go, you can sign up on the Dirigible site and we’ll let you know as soon as we can.

We also have a developers’ blog, where we’re posting details about some of the technical choices and challenges we’re encountering as we develop the software — and, of course, there’s a Dirigible Twitter account that you can follow too.

We think Dirigible is a great addition to the Resolver Systems product line, and we hope you will too.

We released Resolver One 1.9 to get some useful new features out to everyone while we worked on our new grid component. It was originally going to be called 1.8.5, but there were enough new features that we decided it deserved a full point release number:

• Intelligent patch-up functions — when you enter a formula, instead of waiting until it’s been evaluated before returning control to you, however long that might take, we wait for a maximum of a few seconds and then move the calculation over to a background thread. This makes things much more responsive when you’re working with complex spreadsheets, and is just one of many improvements we’ve made to Resolver One’s responsiveness.
• Improved performance when importing files from Microsoft Excel.
• A much-requested feature: moving around the grid using Control and cursor keys.

If you want more details, here is a full list of every change in this release.

Don’t forget, we have forums to discuss and ask questions about Resolver One, and there is detailed documentation too.

There’s an excellent Python library called the Natural Language Toolkit, which includes a function for generating text based on word-frequency analysis, so we decided to see what would happen if we hooked it up to code that reads the UK’s newspapers. We discovered we’d created a monster!

We’ve named it REABot, for the Resolver Electoral Analysis Robot, and you can read its political musings here. So far, it’s treated us to an overview of the electoral campaign so far, and profiles of the leaders of the three main political parties: Gordon Brown, David Cameron, and Nick Clegg. It also makes occasional appearances on Twitter.

Our first thought was that it was a simple anti-alias issue and that we could fix it that way. The following screenshots show the dilemma we were faced with: The two settings (ClearType and AntiAliasGridFit) that made one of the fonts acceptable, made the other one ugly.

Resolver One with GDI+ and AntiAliasGridFit

Resolver One with GDI+ and ClearType

The second version is what you would see in the current version of Resolver One, and was also what you would have seen with the new grid if we’d not heard about this problem.

After some swearing and googling, Giles discovered this post that led us to the solution. We switched from using the DrawString method of System.Drawing.Graphics (which uses GDI+ to do the drawing) to DrawText on the System.Drawing.TextRenderer (which uses GDI to do the drawing). The result is that the two fonts look great:

Resolver One with GDI DrawText

An unexpected benefit is that another issue that we were worried about has also been solved: When switching to and from edit mode in a cell, the font appearance changed. This was a result of the switch from GDI rendering in the TextBox to the GDI+ rendering in the grid.

There are two lessons here:

• Harsh critics are your best friends when you’re writing software. Their criticisms improve your product. Listen to them.
• If you’re ever drawing stuff in .NET and it looks terrible, make sure you’re using the nasty old GDI API to do your drawing instead on the shiny, new GDI+ API.

Built by Resolver Systems director Robert Smithson, the son of political betting expert Mike Smithson, the model uses the new more-detailed data available in recent polls to predict who will win. Robert explains: “Existing election forecasts in the UK often use techniques based on a Uniform National Swing that was developed in the 1950s, when Labour and the Conservatives took 95% of the vote. Yet these do not take in account the rise of effective third parties in different parts of the country. The VIPA model is designed to accurately model voters ’switching’ from one party to another, providing a much more accurate forecast for modern elections.”

You can read more about VIPA on our Election 2010 page.

For example, let’s say that you have a column full of distances in meters, but want to show them in miles. You can set a formatter like this:

def MetersAsMiles(distance, defaultFormatter):
    try:
        return "%s miles" % defaultFormatter(distance / 1609.344)
    except:
        return defaultFormatter(distance)
workbook["Sheet1"].Cols["Distance"].Formatter = MetersAsMiles

The first parameter to the formatter is the value to format, and the second is a reference to the function that Resolver One would normally use to format the value. Using that default formatter not only makes it easy to handle cases where your own code isn’t relevant (for example, when formatting non-numerical values in your “distance” column like the column header) — it also lets you take advantage of Resolver One’s normal formatting behaviour, for example by taking account of the number of decimal places specified in the “Format Number” dialog.

The formatter only affects the way the contents of a cell are displayed. For example, if a cell contained 18294, it might be formatted to and displayed as “11.37 miles”, but when referenced from another cell, the value would still be 18294.

One of the things we’re always working hard to do is to make Resolver One snappier and more responsive. And one of our most frequently-requested enhancements is to produce versions for Apple and Linux computers. These goals are actually closely related; both depend very much on the grid component we use.

Right now, the raw grid display and editing portions of Resolver One use a third party grid component. It’s a great tool, and we would recommend it highly. However, its general-purpose nature means that it can never be as snappy for us as something we have written ourselves. And, perhaps more importantly, it is very much a Windows grid component, not a .NET one — so without replacing it, we can never run on other operating systems.

So we’re writing our own replacement grid. This will make Resolver One 1.10 much faster and more usable. It will not make it cross-platform straight away — we have a few other Windows dependencies that we need to sort out for that — but it’s the first, and we think largest, step in that direction.

Naturally, there’s a lot to be done to get everything moved over, and we don’t expect to be able to release a beta until at least early May, but if you’re interested in beta-testing Resolver One 1.10 when it’s ready, and seeing how the new grid makes it a better spreadsheet, drop us a line at beta@resolversystems.com.