Ephox

To Jonathan Schwartz,

The Ephox engineering team saw the really cool work you’ve done on project blackbox and we’ve come up with a marketing idea that would help you show just how portable blackboxes really are.

In essence, the idea is to take a blackbox on a travelling road show around to Sun’s potential clients to show off what it’s capable of. The trouble is, there’s no point in just dumping a container outside their door and saying “cool, huh?” – it’s got to actually do something cool when you put it there. That’s where we come in.

After much hard work and gnashing of teeth, the beta of our next major release is finally out, including the new productivity pack and track changes. The internet Gods tried to stop us by cutting off our oxygen, er internet supply but the files finally made it across the pacific to our main servers. You can check it all out in the productivity pack section of Ephox.com. It’s a real beta in that we haven’t done any real testing on it and so it’s likely to have stability problems that we’ll iron out before the final release. We’re very keen to get feedback on the release, both in terms of any bugs you find and in terms of how to improve the UI, extra APIs to add for integrating it into backend systems etc.

We’re looking to move most of our servers into VMWare so that we can easily back up the entire system and restore it in case of hardware failure. We’ve moved our Jabber server and now buzilla into VMWare and the next most likely candidate is our Subversion server. I’m wondering if it makes sense to store large amounts of data in the VM directly or if we should look at putting the actual data store on the host machine, but all the configuration stuff in the VM.

In a comment on Software Teams Must Gel, James C. McPherson asks:

Given your brief description of the Ephox interview process, it would appear that you’re not in favour of people who work from home or are even more remote from your office. I’ve spent a long time working with remote management and geographically distributed teams.

There is, of course, no solitary correct solution, attitude or approach to building and gelling a successful software engineering or development team. I would be interested to find out what the Ephox perspective in on remoteness.

I find it somewhat amusing that Scoble is discovering the enterprise market at the SAP conference. One quote in particular stuck out for me:

SAP is no Web 2.0 business. The cool kids like Mike Arrington don’t follow its every move like, say, the way we follow Google or Microsoft. On the other hand, name the business and it probably runs on SAP.

Once you have an automated build, the next step is to automate deployment1. A lot of people take this to mean that you should be able to check out the code, compile it and deploy it all from your local work station. I think this is largely a really bad idea.

Firstly, if you have deployment system that needs to vary, or might in the future need to vary, based on the version of the product, then your deployment scripts have to be in source control with the product and be branched and versioned just like the actual source code. If your product just spits out a zip file that is uploaded to a web server for clients to download, you my want to separate the deployment of that zip file from the code base since it will change based on changes to the web server, not changes to the code. You should however still be able to build the zip file from scripts that are versioned with your source code.

Every fortnight or so the Ephox engineering team lets off steam by taking a couple of hours on a Friday afternoon to do cool stuff with our products using just the publically available APIs. Theres been some cool prototypes come out of it that may be turned into features later on but mostly it allows us to get a sense of what our customers go through when they try to extend or customize our products. You should see a number of improvements to our API appearing in future versions because of this experience1.

We took a little time this morning to set up Jabber notifications of build failures since we now have a dedicated pairing machine with no email account (plus the sooner you find out about a failed build the better really).

It’s all pretty straight forward to set up, the latest CruiseControl includes a jabber publisher so you just put the details in an it all happens. I’d suggest you put it inside an onfailure element to avoid getting a message every time a build occurs (and if you’re checking in regularly that will be often).

Since its inception, our IWWCM integration has been a bit of a pain to install – the instructions differed based on which version of IWWCM you where running and which version of WebSphere or Workplace you used and you had to move and edit files in various locations. Nothing difficult but it was just too easy to forget a step and have things go wrong.

Ephox current has two job openings available – a technical role in our Brisbane (Australia) office and an administrative type role in our San Mateo (US) office.

Application Support Analyst (Brisbane Office)

• Combine your software engineering skills with extensive client contact
• Work with a dynamic, innovative team doing eXtreme Programming
• Particpate in developing the Client Services team for a growing international business

Overview

We are looking for an Application Support Engineer with excellent communication and problem solving skills to join our technical team. With a focus on client service, your role will be varied and challenging and will include analysis of client’s integrations of EditLive!, provide advanced technical support, liaising with Sales, and provide professional services directly to customers or partners, mainly remotely. Some limited amount of travel may be required.

I got some nice feedback over night on an old post about WYSIWYG editors:

# Pedja Says:
June 6th, 2006 at 11:49 pm

You are the greatest.

You are the only web rich text control where I can simply paste image from clipboard.

Congratulations!

I had forgotten about that feature – it has often been one of my favorites, particularly when I want to include screen shots in technical documentation I’m writing.

Ah the synergies, Sam Ruby talk about getting MathML supported in planet, and the Ephox weblog talks about getting EditLive! for Java to automatically upload image versions of MathML equations so they render in any browser. The nice thing about this function of EditLive! is that you can still just double click the equation image to edit it again – the MathML is stored as an encoded attribute so that information isn’t lost.