Like most developers, I was approached by my management to “Make Something Work” without having any prior experience. The job was to connect our Plone/Zope content management system to Kaltura, so web content editors could seamlessly upload and edit video content and metadata that is managed by the KMC. It wasn’t hard to find the Kaltura Python API Client Library, but once you have the Client Library, you have to learn how to use it – and at the same time, learn the features that the KMC provides (see:
Kaltura Management Console Training Track).
I can read through the many docs from cover to cover (I usually don’t) and still have the uncomfortable, lost feeling of having no clue what’s going on. And then there’s always the pressure of overcoming the learning curve in a reasonable amount of time.
So I begin by writing “Playground Code”. A directory that will be filled with useless, proof-of-concept code that helps me get the hang of a language, an API, or a new concept. This code will never be used in production, which gives me the permission to write really bad code while I climb up the learning curve.
Being able to become unattached to code, throw it all away and start over, was an important step for me. You learn the ‘right way’ to do things by doing them the ‘wrong way’ first. It also helped me figure out where exactly I should be reading in the docs to get done what needs to be done.
In the past few years, I’ve been working a lot with the concept of Test-Driven-Development. In TDD you write very small, encapsulated tests before you actually code the functionality or patch you are implementing. You are, in fact, intentionally writing failing test cases. I found this method very useful for isolating and fixing bugs, but not so much for new large projects or new enhancement development. The requirement that the tests should be atomic and very specific does not lend itself to complicated projects with many moving parts. Until now.
When I found myself having to learn the Kaltura Python Client Library – having no prior experience, I found the concept of “Playground Code” and Test Driven Development coming together. I simply took my proof of concept, put together some code and threw an assert() statement at the end, and viola – it’s now a test case!
“How do I connect to a Kaltura Server with the Python API”
The answer was “testConnect()” – that was easily incorporated into a test suite using python’s excellent testing framework ‘unittest‘ (Then, assert that something like client.media.list() returns something that looks like a response. Or, at the very least, not an exception).
I developed the trivial, but important test case at the same time I learned how to connect to the Kaltura server! My code doesn’t have to be thrown away, nor does it have to be perfect. However, it can now serve the purpose of being a proof of concept, a unittest, and a code example for the next developer all at the same time.
When I got confused with something, I could easily take my entire test case, which was an atomic, very specific exercise/problem, and post it to the forums as is – and quickly get a direct answer on what was confusing me – instead of submitting a link to my entire application with the “xxxx not working” title, which would have made it harder for others to review and help.
And then it got even better. The proof of concept code grew as I learned more about the API. A large tests module started forming. I started coming finding small bugs in the Kaltura Python Client Library, nothing critical, but important to my application – And I was able to patch, test and contribute my code upstream to the Kaltura project.
Through my humble experience (from complete newbie state) with Kaltura’s API and Python Client Library, I was able to submit and contribute a more polished and complete Python Test suite for the Kaltura API Client Library!
Want to join the Kaltura project and become an active contributor? Start Here.