We’re kicking AzuleJoe development up a gear over the summer. We’ve got a schedule to keep for the Nesta Prize we won and we also want to be able to show off cool things at ISAAC 2016.
Right now there are three major tasks to attack:
Full implementation of special commands
Currently, as you will have seen in the demo, users can write things like special::clear or special::deleteword in the link field of the PowerPoint template to give the buttons special behavior. At the moment, only those two commands are implemented, and there are many left to do – the commands to insert different text than the label, or control external functions (like TV controls and the calculator).
One of the things that is making this more urgent is that it’s needed to completely finish off (this is why the CK20 demo wasn’t released when the CK12 one was). It should actually be relatively simple to implement. The major sticking point is that I need to carefully consider exactly how I’m to handle the care where a user would like to write completely arbitrary javascript….
Export to the open board format
We are big fans of the Open Board Format around here, and it’s a bit embarrassing that we haven’t put the code in to get us there. Currently our parser takes in a PowerPoint document and produces a JSON file and some icons. It should be trivial to extend this so that it plays nicely with the other Open Board Format tools and, from a wider perspective, it’s important to get this done before ISAAC – it will be a tricky sell to talk about the importance of portability and all the advantages of open source if we haven’t got on board with the format.
Testing Code
The third, and deeply unsexy thing we need to put in place is an automated testing core. For the uninitiated: we need a script that runs AzuleJoe on a range of different inputs designed to test the limits of the code. This helps us check that a new feature hasn’t broken an old one and means that we can also start doing significant rewriting of the code to make it a little more efficient and easier to maintain.
What’s next
When I started writing this post I thought that getting the special commands working was going to be the thing to tick off (because then I could call the current state of the code a stable release) and then we’d look at everything else. However, the more I wrote, the clearer it was to me that the testing structure is going to have to happen first. I’ve been running into more and more development problems around pageset versions working one day and failing to work another and that’s causing problems.
More to the point, without a sensible test architecture, it’s very hard for other people to work on the code well. Now that we’ve got people using the code in Academia, it’s going to be hard to encourage them to merge changes back into the trunk without a proper test system.
So it looks like I’m going to have to finally work out how testing works in Python. Time to go into research mode.
Update
As of 27th May, there is now regression testing for the python parts of AzuleJoe. On it’s own that’s a big relief. I need to have a careful thing about how I want to test the javascript, but that will get me most of the way. I was going to post my contemporary notes of the implementation, but they were mostly uninteresting when I came to review them. I should be a little careful about that in future. The only really useful thing I can find from my notes is that this was about five hours work spread over three days.