2013 is going to be a big year for us in terms of WebVTT Development. In the last year we have accomplished a lot and it is looking like this year will be focused on taking what we have done and building further on top. At the end of 2012 we have managed to code an entire WebVTT Parser which was implemented in the C programming language. Further, we have written some tests for the parser using Google’s GTest Unit Testing Framework.
Given the previous accomplishments they come at some cost to us. The code is riddled with errors and poor developmental style. The tests are well written, but the vast majority of them do not pass and the code is very hard to read and understand.
Although I wanted to contribute significantly to the code base this year, I do not think it will happen unless the following is completed to a reasonable degree. The answer to the problems seems very obvious to me: to fix the code and to ensure all of the current tests are passing. This however is going to be a difficult and tedious task because most of the code for parser is not written by me and it will require a great deal of collaboration in order to truly address these issues. For my part, I have been analyzing the code and building some hypothesis on why errors are being thrown in our code base independently.
Luckily, I took a free online debugging course during the break which taught and reaffirmed some of the knowledge it takes to efficiently and intuitively debug code.
Here’s a link to a Free Software Debugging course:
Here’s a link to a Free Software Testing course:
Once I am finished with debugging the code. I will focus on ensuring the webvtt spec is fully developed. I will also make a contribution to the WebVTT C parser while debugging and this may involve programming better algorithms and styling to ensure the code performs well and looks like code that is maintained by a Professional Software Development Team.
My Agenda is written with the focus of ensuring the parser is robust and has the required integrity needed to be integrated to the mozilla firefox browser. Most of this testing will involve some programming to fix or re-code parts of the code base. The focus will be to solve the main objectives of the problem areas and to ensure they are coded in the simplest and most efficient manner. Styling will also need to be improved.
Jan 14 –> Build Hypothesis on the problem areas in the code base
Jan 28 –> Refine Hypothesis by testing the code base
Feb 11 –> get all of my Unit Tests to Pass the parser
Mar 04 –> get some more unit tests to pass the parser (10-20 or more)
Mar 18 –> get more tests to pass (10-20 or more)
April 1 –> Hopefully finish testing everything or continue testing
April 15 –> Finish and polish everything up or work on coding and integrating the parser with mozilla.
This agenda is subject to change but it outlines what I hope to accomplish by these dates. I hopefully want to finish everything as early as possible so I can add more work for myself in terms of actual programming and development.