“Six weeks? We don’t do projects in six weeks. We usually do them in six months.”
~Mr. Lee, CEO of Azeus, during his meeting with us interns. Words are not verbatim.
Aaaaaannndddd we’re on the final week. We coded last week away and I expect we’ll do the same for our final week. My fingers are now packed with awesome strength, honed from hours of coding. My body, on the other hand, is starting to display symptoms of coffee dependence, as coffee is my mental stimulant during those sleepy hours after lunch break.
Our project is nowhere near finished yet, sadly. And we already scrapped some features at that. Among the casualties in the clean-up was my statistical ranking system. I’m not really disappointed that it got scrapped as I still have two challenging features to implement. And besides, I don’t think I’ve managed to perfect that system to behave exactly as we expect it to; after realizing that Python’s randint returns a uniform distribution I stopped thinking about it but I bet I have a few test cases in which it will break.
To manage all the project’s files, we are using SVN. This is the first time I ever coded with such a large team and I admit that it can be quite overwhelming. The most number of co-developers I ever had before this was 4, making-up a team of five, including me, and we didn’t use SVN that time. The first (and, prior to my internship, only) time I ever used SVN was, ironically, in a pair-programming project.
This is also the first time I ever used a framework that’s being coded as we work, and being coded by co developers at that. The pros:
- If there is a function you need but is currently not in the framework, all you have to do is talk to the person responsible for that type of function and you’ll have it at your next SVN checkout. No more awkward workarounds or (worse) waiting for months for the release of the next version.
- If there is a bug, or something you don’t understand, do the same as above. No more waiting for forum answers that may never come at all.
- It is a learning experience. I don’t really work with frameworks a lot but for those few times I did, I always wondered how they did things* (my current fascination, by the way, is CodeIgniter’s URLs, which are actually class/function names). Since my co developers (with our mentors) made the framework, I can see the code and learn how they did it. While I don’t understand everything about the framework (the jwebsocket-based framework still stumps me), I sure have picked-up some nifty programming tricks.
And the cons:
- Since we’re running on a tight deadline, and since framework development runs parallel with project development, some parts of the framework tend to be buggy, especially those made by request (see #1 above). It changes rapidly too: the jwebsocket-based framework has been through a number of deprecations already.
- Again, maybe due to the tight deadline, the framework isn’t well-documented, if at all. Though I can ask the person responsible directly, it gets a little embarrassing after a few rounds especially when that person is also working on something for his module—something that is always the case, without fail.
So there. I hope I can finish everything under my responsibility this coming (final) week. I’ll really work hard and smart to beat that!
*Maybe, my hesitation to work with frameworks is because I don’t understand how they do what they do. They’re like magic.