As many of you know, we xAPI interns have been hard at work since we arrived in May. A couple of weeks ago, we released our first contribution, TinCanPython. It should look very familiar to anyone who has experience with the existing xAPI libraries (TinCanPHP, Java, JS, .NET).
What’s it all about?
One month ago, the only thing that I knew about the Experience API was that it did something in e-learning with statements and stuff. It was new, anticipated, and out of my understanding. One month ago, I had never worked in Python. I had never used GitHub. Never worked as a part of a real development team. I hadn’t done a lot of things needed to make our first big project, TinCanPython, happen.
It took a lot of effort from us and a good deal of patience from Brian Miller (who got a lot of practice explaining things), but we built it—TinCanPython. Along the way, I learned so much:
- Python: the language, the style, the patterns, the neat tricks – all of it
- xAPI: Now I know what statements and stuff are! And can, you know, write a spec compliant library.
- Work on a team: We delegated work, made design decisions, helped each other, bumped heads, and, in the end, got it done.
Was it useful?
I learned more during this project than I did in my classes at school so far. No seriously, I feel like I’ve learned more about software (both the technical and business sides) in the last month than I have during this past year of classes. I picked up a few things about xAPI from working on TinCanJS, but that was just a small piece. For this project we built a whole library, so I learned quite a bit more about all aspects of the spec.
Working in a team of talented devs is good and fun, but it can also get pretty complicated and confusing sometimes. Especially when the code one person is working on is keeping you from finishing yours. So sometimes you get slowed down, and sometimes you’re the one slowing people down, but it all works out in the end.
What was challenging?
Working with the team has been a roller coaster, but probably like a kiddie roller coaster where nothing gets too dramatic. The only thing that is similar about anyone in this room is that we are all detail-obsessive micromanagers. Oh, hour long disagreement about a single word choice in documentation strings? Sign us up. Whitespace conflict? Drop everything you’re doing, this is more important.
Ultimately, though, if that is what was required for us to produce something of acceptable quality while remaining within our deadline, then who am I to complain? As one of the two interns with a full CS core in the books, the gem of working on xAPI Python has indubitably been seeing the interactions and processes necessary to release a non-trivial piece of software collaboratively and effectively.
Are we xAPI geniuses now?
Yes and no. xAPI has many layers, and I think we can call ourselves experts in the client libraries. But in setting up the LRS server itself, and figuring out what to build on top of the client libraries, I think we still have more to learn.
I am proud that we got a working product that passed our tests at the end. We even uncovered and submitted a bug in the LRS during our testing of the Python library!
I wish that the documentation was even more complete than it is now. Although it goes beyond what was previously available, it is still not quite complete. I am still working on that whenever I need a break from my other projects.
Bottom line: the details.
Even having Brian Miller’s past works to jump off from, building a strong, clean, and spec-conformant Python library was definitely a challenging and rewarding opportunity for all of us. We designed TinCanPython not only to follow Pythonic style and practices, but also to balance Pythonic freedoms with safety nets and code clarity to ease developer headaches. It fails fast and has a lot of guards against big pitfalls. We used practices like typed lists, coercive setters, and thorough documentation to help anyone working with TinCanPython stay on the right path.
We really think that TinCanPython’s accessibility will be its biggest contribution to the community. Python is one of the most common languages for novice programmers as well as an extremely popular language for rapid production in the professional world. A lot of people know Python and like it. Now, with our well-documented and clear library, these people will be able to approach and use the Experience API.
Features:
- Supports Experience API versions 1.0.0 and 1.0.1
- Documentation on every object
- Designed to fail fast – typed lists, coercive setters, fixed properties
- Uses native Python types like datetime, timedelta, and uuid
As with other xAPI libraries, TinCanPython is open source and available on GitHub. TinCanPython is registered/uploaded on PyPI and is one line installable using pip or easy_install. If you have any questions about TinCanPython or anything xAPI, you can get in touch with us at here.
