Packaging and Testing my XML-RPC WebService Project
I have written previously on a project I was undertaking using a C# client calling a PHP-based XML-RPC webservice. Well, the project is near to completion. It should have been finished, but there were several delays from the client’s side - most notable of which was, they refused to even take a look at the software until it was 100% bug-free: they wouldn’t even test it! What a lot of people don’t realize is that the client plays a huge part in the design process. Simply saying, “go and design a Car rental management Software for me” without taking a look back, and then asking “why is it not ready yet?” without even looking at the software in development is a serious morale killer.
I finally got the IT Manager convinced to run the tests, and I send daily updates to her - which has proved to be an enriching experience. We agreed that I would send weekly updates to her by mail and she would send back bug reports and new feature requests. It was awkward at first, because you have the initial difficulty of communication between a core techie and a business manager.
First, we had a problem of packaging - the application was made up of a client developed in C#/.NET, with CrystalReports and the XML-RPC.NET component from CookComputing. On the server side, there were several related php scripts making up the webservice, and of course the ubiquitous MySQL database. I have to send a windows executable installer, a tarball of php scripts, and a database schema every week. You might say, “why not just send her a patch?” but you have to bear in mind she is an end-user and will balk at the slightest sign of installation difficulties. I live miles away from the client and cannot afford to show up every time an update/patch is required.
I created a self-extracting Bash script (the server runs on Linux) to pack and automatically update the server components, and update the MySQL database at the same time. Despite step-by-step instructions, the IT manager could not run the script. Oh, yeah, I forgot to add that I found she had been trying it from her windows laptop. I separated the files and had to give instructions on how to replace the old components with new ones, via instant messaging (Yahoo has helped a lot of businesses to grow…) Another issue was the windows executable - rejected by GMail (even when zipped and tarred!), dropped by Microsoft Outlook, ignored by Yahoo - there was no way she would receive it by mail. I have to upload it to my site and send her a link each week.
Having solved that problem, I now became deluged with several feature requests and bug reports per day. Context menus, coloring, company logos and images, dimensions changes, etc. Things that IMHO should have been specified in the design stage. Oh well, I cant complain right now - because I’m enjoying it. A lot of funny bugs showed up, adding weight to my argument that a programmer should not be solely relied on to test the software he is developing. This is because he might not even see some quirks as worth worrying about. For instance, if a control throws an exception because its datasource is null, all you have to do is make sure the datasource never gets empty, right ? Wrong.
End-users have proved time and time again that if it can go wrong, it will. Imagine a user trying to delete records upon which other records depend? I didn’t think of that happening - which illustrates what I’m talking about. I also had to deal with the odd exceptions thrown when users attempt to sign in with unusual usernames, multiple logins from different machines, creating a search that produced zero results and then attempting to print the empty dataGrid, using the control buttons instead of the provied “Close” buttons, resizing to ridiculous dimensions, and so on. Well, I’ve learned a lot - which can be summarized as “Prevent instead of Scolding”. Rather than give an error message about invalid input, simply make it impossible for the user to enter invalid data.
The software is still being tested, but it has a load of nifty features now. Maybe I may get to post more screenshots soon. And I will write about how i discovered the joys of HTTP GZip compression with XML-RPC webservices.
Post a comment