CP3108B Independent Project

Progress Report
TEAMMATES

CP3108B is a module offered to a Computing Student every semester as an independent project which allows the student to choose a particular topic he/she interested in, and submit work regularly to advisor. At the end of each semester, this student is required to submit a progress report, which is this document. This report is written chronologically from week 1 to week 12, and each week will have detailed progress, ranged from Issues, Problems, Comments from Advisors, and Tools Used. For this Individual Project, I have chosen TEAMMATES, local NUS project started by Professor Damith C. Rajapakse, which is a project evaluation tool aim to serve various local schools.

Reasons for Picking This Project

Out of all the open source projects being offered in this module, I have chosen TEAMMATES due to these few following reasons: 1. First time working with open source project a. I have no experience nor background in an open source project before, and attempting a straight open source project might be a huge barrier to leap across for me b. I see this as a stepping stone/middle ground between a University school project, and an actual open-source project, due to the different nature/culture/workflow involved in both type of projects. 2. The local time zone a. Other open source projects including Mozilla require the student to communicate with professional developers from across the globe, and therefore the time zone becomes an integral part of communication. As a first starter, I do not wish to add another complexity such as time zone to my first independent project.

b. Clarifying things and issues with local students/professors are also easy as we understand mostly the working culture here, after spending few years in the university. 3. An opportunity to improve my resume a. This is one of the selfish reasons I believed I should not disclose, but involving myself in this project will open up more opportunities for me, for it be enterprise jobs or open source jobs.

Week 1
Introduction In the starting week, we are introduced to this module. Prof Damith and a couple of previous seniors shared their experience with previous open source project they have done and everyone is to decide which project they wish to involve in. A couple of projects were shared, and also the possible wonderful contributions we could potentially be a part of. Each project uses different tools and language which includes Python and C#/C, both I have less experience with. At the end of Introduction, each student were required to decide a project and I made up my mind to choose TEAMMATES after weighing the pros and cons of each project.

Week 2
TEAMMATES Setting Up This week mark the start of the project. One of the seniors, James, taught me on how to do the set up and how TEAMMATES work. First I clone the source code from the TEAMMATES online repository, and then make changes as specified by the development manual. I ran the code, and it works fine. I try to add in extra elements but it turns out, I would need to address exactly the issues found in the system, and not suggests a new issue. At this point of time, there wasnt any new issues which I could work on easily. Also, since Mercurial is used for versioning, a simple HG(Mercurial) tutorials was shown as well on this week. However there was some permit issue regarding my student pass, I had to skip classes for about 3 weeks before I continue on this project again. Before I leave, I asked James on what to do, and James gave me my first thing to handle with during my absence, which is Issue 340, converting system specification document to spec.html.

Mercurial One of the setting-ups includes using a mercurial versioning tool. Its preferred over Git as Eclipse provides a native support for mercurial.( http://mercurial.selenic.com/) Following Development Manual, I took a few steps to use Mercurial to participate in

my first ever open source project.

1. Open up a command prompt window, and type hg clone repo 2. When files is fully transfer from the repo site, I modify the settings, added a few .xml files for my local deployment. 3. In Eclipse, I also add in a couple of extensions which include the Google App Engine, the core of my local deployment server. Problems As required, I ran the JUnit test to make sure every current test passes. However, theres a small problem since my Google App Engine extension is 1.7.1, while the one this project uses is 1.7.0. This produces unexpected results in the tests, even when the deployment was successful and the website was running just fine. Solutions My first approach is to create a new project using 1.7.1 version of GAE, and replaced all generated config files to 1.7.0, hoping that it will update my current project to automatically recognize 1.7.1. However, this did not work because the new project I created only have the default config files, which are not enough. I then consulted my advisor regarding this, and he advised me to look for a 1.7.0 version from Google in the archived section. (its no longer available at the site suggested by the Development Manual) After that, the project works fine and all tests passed without errors.

Week 3,4 ,5
Absence during school In these 3 weeks, I have not been working on this independent project, and I have let my advisors know about this. I had pledged to them that I would increase my workload performance in the later stages of this semester and they accepted it.

Week 6
Issue 340 Starting of Issue 340 : Converting system specifications to spec.html. In this week, I started working on my first Issue. I was notified by both advisor and tutor on my slow work progress and was required to make up the progress as soon as possible. The best tool to do this kind of conversion is of course the Adobe Dreamweaver, as it has a lot of the short-hand keys which allows fast HTML document to be created. One of them includes the <ul> block and <li> items to be generated quickly and accurately. Converting the 20-page document to HTML isnt hard, probably took me around 4 hours worth of work. The CSS styling takes about 30 mins, as HTML document was well-formed and well generated by Dreamweaver itself, not to mention it also comes with the auto-CSSstyle insertor, which is very useful in converting document to HTML. Then it comes to the part which has some sort of learning curve for me, which is following the work flow(from creating a new branch in mercurial to committing a new change) The whole process is well documented in the development manual, however I decided to take a short cut to use the web interface provided in the Google Code. This, of course, did not end well, as I ended up committing to the wrong branch, which I did not know, until the review started in week 7.

Week 7
Update of Issue 340 Issue 340 : Converting system specifications to spec.html. As I mention in Week 6, I did not follow the workflow procedure properly, and end up committing to the wrong branch of my own local hg. Since commitment is final, the advisor told me to re-clone everything from the online repo, and even taught me a few tricks to commit properly from the command prompt. 1. The use of hg revert hg revert is used to revert all changes that was being made 2. hg st hg st is to check any changes to the folders after a commit. This is useful before to check for any about-to-committing changes.

3. It turns out the first 2 command were taught in the first weeks, which some of it I did not attend. However, there was one trick about the using short cut and inserting the right user profile by editing hgrc file under .hg folder. Everything seems obvious at this place. I re-cloned my stuff from the repo, put my edited spec.html into the right branch, and commit directly from there via command prompt. However, I missed out something important which I will talk about more at the review of this issue again at Week 8. Issue 319 Start of Issue 319: modify devman.html to follow html style guideline Despite the problems of Issue340, I took 2 more issues during the same week. In this issue, Im supposed to modify one of the html files to follow a new html style guideline newly created during my absence between week 3 and week 5. The html style guideline is to specify how the html structure has to be in all the .html files. Its a standard for coding HTML files, and at the same time preparing for the future when HTML5 becomes the standard. The modifying itself wasnt hard, probably worth about 30 mins of work, but at this stage, I was using an older version of the files(cloned from week 1, instead of the new clone this week), and this proves to be a disaster back-and-forth-checking for this issue, which I will be explaining in later weeks. Issue 339 Start of Issue 339: modify about.html to add new links. This issue is about adding new links to a current old file, about.html. Until now, all the issue I chose seems to be a bit easy as I want to focus my work more on getting the workflow procedure right before attempting a more complex problem. Again this issue wasnt hard at all as it seems, as I was supposed to add two <li> items to about.html files. The subsequent reviews about this issue is a sign of lack of communication of my part, for not understanding exactly what was needed, and I shall be explaining them in more details in later weeks. Tools used Until now, I have been using Dreamweaver and Eclipse for the above issues.

Week 8
Issue 316 Start of Issue 316: Implementing JavaScript Warning Page As I getting used to the whole workflow progress, I have taken another issue, as I knew I needed to bring up my progress since I missed out a lot between weeks 3-5. In this issue, Im supposed to implement a JavaScript Warning Page which a warning is given to the user, if JavaScript wasnt enabled. I have previously dealt with this before in my previous school projects, and the solution is to use <noscript> tags, to wrap around any elements that will be displayed when JavaScript is not enabled. Again, like any html structure, <noscript> has to follow html style guide. The content itself has included a few instructions on how to enable the JavaScript in various browsers. The content itself wasnt difficult and now my 2nd task on the line is to incorporate this new section of codes into all the files which have JavaScript. My solution for this is of course an insert method readily provided by JSP, which is just below: jsp:include() My first thought is to use jsp:include() in the footer.jsp, having previously bad experience to put it in the header section. Apparently the web crawler of some web search engine will disregard <noscript> tag and therefore not render it properly in some browser. I also was required to alter some of the test pages of which correspond to the jsp scripts, as the test pages will be compared with the generated jsp pages and made sure they are identical. This was easy but unfortunately, due to a lack of communication from my side, it has some unwanted consequences from my side. I shall explain this in details in the future updates. Previous Issues Update of Issue 340,319,339: Revert changes which are added directly to default branch + proper formatting. At this stage, the previous issues were reviewed to have some problems regarding branching and formatting. After some consultation from tutors and advisors, I fixed the branching problem and formatting issues.

In Issue 319, one major problem I came across is that although I fixed the branching and formatting problem, I have neglected the fact that I have used an old version of the file.(from repo cloned during week 1). This means I forgot an important step in using HG/Mercurial properly. Im supposed to use hg update repo before starting my work to make sure they are not outdated before I actually edited them. This causes a major confusion on why my work is always has missing lines and elements, which are added between weeks 3-5, while I was away. So I may have known the problem, but the fixing of this wasnt as obvious as I thought. To avoid redoing all my previous work, I used external software ExamDiff to find each difference which are needed, and edit according to it. For some reason, even Google Code has a side-by-side comparison between the latest code and submitted codes; I could not use the feature. After some consultation with my tutors, he told me that I need to use hg revert if my previously committed version is wrong, to make sure the Google Code always compare against the newly committed version with the repo ones, and not the wrong version which I submitted before the newly committed version. Knowing this essential idea of using hg, I started re-working other issues to make sure its properly followed the workflow procedure as well. For Issues340& 339, the fixing for this week is mostly on formatting and undoing some of the extra changes, which are required but may not exactly follow the html style guide. These task were not difficult, and both takes me about 20 minutes to finish.

Week 9
Previous Issues This week is mostly the mid-term examination week for most of us, and the reviewcoding progress has somehow slowed down, compared to previous 2 weeks. I myself have tried my best to fix all the problems from all the issues and make them as error-free as possible, to pass my first ever review. It seems that after 2 weeks of back-and-forth reviewing, the fact that my work is not yet passed have me felt quite a bit frustrated as the work itself wasnt time-consuming and difficult, but the workflow procedure is. In this week, I will briefly summarize everything I did.

For Issues 319, by using the ExamDiff, I have tried my very best to restore any lost changes due to the old version I used. For Issues 340, the file was basically ok but the name, as I have used systemspec.html instead of spec.html. I could not rename the file using mercurial so what I did was remove the old file and add in a new one. For Issues 339, Im supposed to edit according to requirements, which is arranged <li> items alphabetically, which I thought meant using <ul type=a> </ul> to wrap around the <li> items, but the truth is I was just required to look the actual names of <li> items and arrange them. This lack of communication from my part really makes things slower than it was supposed to be.

Week 10
Closing of Issue 340: Closing of Issue 339: Update of Issue 319: Adding lost parts

Issue 316 Update of Issue 316: Formatting codes, including in footer.jsp, and also<noscript> code. In this week, I continue my work for Issue 316, and conclude everything in terms whats needed for the JavaScript warning page to be displayed. However, I have mistaken the requirement yet again, as what was needed is to display only the JavaScript warning page, while I had believed the JavaScript warning page was to be displayed together with the webpage itself. My root of thought was, if only JavaScript warning page was the only thing being displayed, why not make it by default that all pages will render it first, and then when JavaScript is enabled, only then we use JavaScript to redirect the user to the page they want. I believe theres a term for this way of thinking though, either graceful degradation or progressive enhancement, not sure which one already. Of course, I do not know this until next week, and next week I will talk about how to I come about solving this and also one of the important lessons I learnt in this course. Previous Issues I was happy this week mostly because 2 issues are finally done, passed, and committed to the repo. They were issue 339 and issue 340, the document conversion

to HTML and adding links to HTML. In Hindsight, I wish this would have happened faster but nevertheless, once the issue is declared closed, I was relief and started to grasp the whole workflow progress, which really has troubled me and my approach of solving a problem, and do not add value to the solution itself. (of course it helps the overall collaboration) For Issue 319, there were still pieces and parcels of the codes which I did not restore properly after this week review. I was slightly frustrated because this should have been an easy issue, based on the time I actually spend solving it, it should have been passed by last week. Nevertheless, I submitted my final version of it using ExamDiff and have triple-check to make sure nothing will goes wrong in the next review.

Week 11
Issue 316 In this week, I have already receive multiple negative reviews on my codes last week, which say the codes did not work, and it failed a lot of the tests from test pages. I was surprised at first, but further probing of the questions from tutors and advisors makes things a lot clearer. It turns out I have not met the expectation, even though the codes was working from my point of view. Here I learnt an important lesson when working in collaboration of people. Always meet expectation, not the workload itself. For review code did not work, Im supposed to only display the JavaScript warning page, and not everything else. Also, the footer.jsp has a CSS fixed position which disabled the display of anything but the footer. I have made sure the codes works fine, but I forgot to review other section of the codes which might affect my own codes. Nonetheless, I have solved this problem by using display:none property in the <noscript> CSS, so when <noscript> is display, it will use my own CSS instead of following the current CSS. And just like that, code works again. Another problem has to do with test pages. Somehow it compares wrongly when it comes to the elements residing within <noscript> tag. Now I understand why even tech companies like Google has a one line <noscript> html because of the nature of <noscript>.(my <noscript> has more than 50 lines). For this problem, I have no solution of my own, and have to consult with tutor and advisor for it.

Previous Issue Closing of Issue 319: styling devman.html to follow html style guide This week marks the end of Issue 319, a simple issue but yet haunted me for the past few weeks with back-and-forth reviews. I finally submitted the wanted version and everyone is satisfied and passed it. I wasnt really happy that it took too long to close, but nonetheless was relief about it. Issue324. Starting and Closing of Issue 324: adding links to web compilation page. While waiting for Issue 316 to be reviewed until next week, I took another issue 324 and work at it. This issues is only about adding anchor tags <a> for easier browsing purpose. At this stage of time, I have understood both mercurial and the workflow progress and the links itself took me about 20 minutes to finish. I added a few touch of CSS of my own to make the links look better with minimal codes, and the whole process took about 45 minutes. I then committed the file and wait for review. The reviewer was satisfied and immediately passed it! And the whole duration took between me finishing the issue and passed: about 2 hours. I was overjoyed since none of the previous issues were that approved that fast but at the same time I also felt pretty bad about myself as things should have been this smooth for the previous issues and I would have been able to try at least 5 more issues in this semester, or more complex issues.

Week 12/13
Issue 316 Closing of Issue 316: implementing a JavaScript warning page. In this issue, the tests always have some problems to it. I personally could not fix it and have asked tutor for help. He spotted configuration problems in my eclipse and said that its happen to another guy working on the same project before, and its stemmed from the fact that the different version of GAE. He copy pasted the required files, and then everything works fine again and test-error free.