The Anatomy of an Iguana App

Translator on Demand

When we did the first cut of the regression testing application, it crashed and burned.

We started with a decent enough idea. The application used the channel API to suck the source code from a separate translator instance, and it would then override some key functions so we could run that code in a sandbox. We put in some APIs into the functions that take vmd files to take them in using memory.

Trouble was, the sandbox was the same Lua instance we were running Iguana in. Ka-boom! It was quite easy to crash Iguana with it since the imported Lua code could create a recursive loop.

So we went back to the drawing board and tried out a fresh idea. The result was the spinner library.

It’s a pretty cool design.  This is how it works:

  1. We use the channel API to create a new From HTTPS channel – this can be done on a local or remote instance of Iguana.
  2. We prime that channel with some basic code, to make it ready to “catch” a translator instance.
  3. We send the new channel a full translator (a set of Lua scripts, vmds, etc.) all wrapped up in a JSON tree.
  4. The bootstrap code is able to take that Lua code wrapped up in that JSON object and compile it on the fly.
  5. And then we can call that Lua instance with data and have it do work.
  6. When we’re done we can stop the “spun-up” channel (using an API of course) and remove it.

Yeah – it’s insane isn’t it! The funniest thing is that it works well! And it really really useful.

Last week our QA engineer Wade announced he’d run out of work to do for our Iguana 5.6.6 release so I got him to hack together a completely different type of regression testing app. It took him a day.  This one has a completely different focus.  You can read all about it!  It’s moving along.

Leave A Comment?

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.