Wednesday, June 17, 2009

Cogi Mobile, Part 2

In terms of the things that I learned from this project, I suppose there's the obvious:

The API was written in Python using the Django framework.
The Android client was written in Java using the Android API.
The Cogi Mobile website was written using AJAX, and the Google App Engine to tunnel requests.

But honestly, learning each of these languages was not a hard thing to do. Programming languages are only a means to express certain concepts, and being able to familiarize yourself with all these different languages is not in itself particularly meaningful.

It is useful, I suppose, to know how to use AJAX to create a web page that serves everything on one web page.

See: Slashdot. They have a continuous flow of information script running on their pages such that, as users near the bottom of the page, more stories are updated onto the page.

But AJAX isn't the thing to be learned here. It's the concepts. Concepts are the all important part of it all; once you grasp the concept, you can bring it anywhere.

So what did I learn in terms of through the term of this project?

Well, from the programming aspect, the concept of DRY (Don't Repeat Yourself) and refactoring code.

In Agile development, there's a big fuss about unit testing; every individual thing must be tested, rather than the whole. Granted, I'm hardly the type to do unit testing on anything; I prefer to think long and hard about something and then get it all down in one shot, rather than get bogged down with writing drivers and tests for some tiny if statement.

But there was something to be gained from the amount of unit testing that went on while I was working with Cogi. Every individual method I wrote had to be tested for correctness, but if I had about a million branch paths in my code, I'd probably have to write 2^billion tests to cover them. What happened instead was a revelation; Chris, one of the programmers at Cogi, took my code and refactored it as such to tunnel it through as minimal number of paths as possible. It was really interesting to see the number of tests required for a module go from some 50+ down to maybe 5-10 tests at possible. It's definitely something impossible to learn in a classroom environment, where the objective is simply to get a product working.

From the design aspect, this entire project was about accessibility. For a company providing telephony services, things should be made as accessible as possible. It's not enough that you can retrieve your recordings and things from only computers. Unless we live in a world where desktop computers are built into every vehicle (here's looking at you, WingMan project) and have them everywhere we go, services need to be capable of being accessed beyond just the primary means.

No comments:

Post a Comment