C3DL Test Automation

My main assignment for this summer will be to add features to and improve the performance of C3DL. I believe that improving performance is impossible without an automatic and consistent way to gather evidence about what the performance actually is. It's also necessary to test that the engine is still rendering images correctly, so that we know immediately if something breaks.

In order to do both of these goals my first objective is to establish an automated testing suite. Because CDOT has given me a machine with a public facing IP address I can set up some sort of WIMP stack on it that can receive test results and store them in a database. Then I can set up some javascript test scripts that will run tests and deliver results to that stack.

The image rendering tests will be rendering a static image, and can be used in something like testswarm as a result. This will allow us to ensure cross-browser and operating system compatibility.

The performance tests will need to be run on machines that are guaranteed to be not doing anything else when they are run, but they don't need to be run on nearly as many machines or operating systems as the image tests because increases in the performance of our engine should be seen across all platforms when we make those increases. Eventually we may get into the area of coding specific enhancements for platform/browser/graphics cards, and I very much don't want to be working on this project if that happens, so I don't need to worry about that right now.

I'll be making a battery of tests that check very specific features and are designed for a machine to test them, unlike the human-oriented tests that we currently have. These tests will need to be designed in a way that allows some javascript code to automatically redirect between them once they have finished and the results have been delivered.

By storing the results of all the tests in a database we'll be able to make a timeline of rendering/performance increases across the lifespan of the project, showing quantitatively how much work we've been doing on it.

We can also show the results of our tests to the browser developers if they reveal bugs in the browsers.

Should be an exciting process! Although enabling the actual wimp stack itself is really boring right now.

JQuery, JSONP, and fun

I just created the first release version my twitter widget! It was not an easy process as I haven't ever really debugged anything in javascript before.
Many of my issues were due to this line:

$.getJSON(jsonurl+"&callback=?",{},function(json){ 
a whole bunch of code follows

While making that line and encountering numerous errors I discovered the following facts:

JSON is not the same as JSONP, and due to extremely valid browser security restrictions you can't access JSON files from outside your domain- JSONP, on the other hand, is fine because your browser interprets it as a script.

Twitter needs a callback=? parameter passed in order for it to give you JSONP instead of JSON.

Javascript will automatically place the function {} in place of that ?
Giving the function(json){a whole bunch of code follows} in place of that {} causes it to not work in some circumstances.

Now that those issues have been resolved the twitter widget works properly. It can either display tweets by searching for them or by showing all the ones from a given user.

You can check it out at http://pastebin.com/DUnqw0n6 . Please save it into a file named twitterWidget.js
An HTML file that will test it can be found at http://pastebin.com/GbnGQvB9 . It needs to be placed in the same directory as twitterWidget.js
You also need dashBoard.js, which needs to be placed one directory up from the other two files and can be found at http://pastebin.com/0i7kLEsa

First week at CDOT

This is my first week here at Seneca's Center for Development of Open Technologies (CDOT).
So far it compares very favourably with other environments where I have done software development- the other developers and managers care about the things on lists like this one.
There is a genuine and concerted effort to make sure that developers here have the tools and environment they need to make good code.

I'm also proud to work here because of the altruistic goals of CDOT- to create technologies that everyone can benefit from. I've been a fan of open source software for years, beginning sometime in 2002; since then I've been to see Richard Stallman give talks twice and have switched to using almost entirely free and open source software in my day to day life.

So far most of my time has been spent updating myself on what javascript has been up to since the last time we seriously talked in 2006, which is a lot of things! It's like an actual real language now. Which I will be using to enhance C3DL and make it faster and better than ever before.
I'm also working on this dashboard project that Dave Humphry is having us do. The end goal is to have something that will let people see, at a glance, statistics/advertisements about CDOT's projects. Or anything else that people want to code javascript widgets for.

*fakeinformation*
The end end goal is, of course, to provide the actual dashboard for the free software powered car that CDOT is building. They plan to use that funny mannequin-looking guy by the windows to provide power for it. He's actually a real person! Just very lazy.
It's step 12 on their 42 step world domination plan.
Shhh. Don't tell anyone.
*/fakeinformation*

The first widget I'm working on is a twitter feed. Learning to do this has taught me many things about JSON (it's very easy to do; you just need to press x) and jQuery and javascript itself.

You can see the first version of the code for it here

That's all I can think to write on for the moment. Time to learn me some git.

First post

This is a sample post