The Aftermath

Well, here we are again… After exactly 1 month of frantic coding, the end of Google Code-In 2016 has arrived. Personally, I feel it’s been a great experience - despite my starting late on December 16 as my school holidays only began then, over the last month I’ve worked on 11 different tasks spanning a wide variety of Sugar applications, guided by several incredibly helpful volunteer mentors.

I began the contest with high hopes, signing up on 28th November, but after actually looking at the tasks and their daunting complexity I quickly lost hope of completing any within a reasonable amount of time. Weeks passed and GCI soon became a fading memory in my mind. However, once my school holidays arrived, wanting some coding stimulation but not knowing where to look, I thought of having a go at a GCI task. Of all the organisations available to select tasks from, Sugar Labs seemed to have the most appealing ethos and also was reasonably familiar to me - furthermore they used languages familiar to me: Python and Javascript. After having a look at the sugar-labs GitHub repo and familiarising myself with their applications, I decided to dedicate a day to doing a Sugar Labs task and plunged into the task list…

During the contest, however, I was so busy writing code that I didn’t really have the time to reflect on what I was doing, how I was making a difference and how I can improve - this post is an attempt to inventorise my coding over the period and should be a chance for some much-needed self-assessment and target-setting.

Task #1: Resolve An Issue

Time taken:

16/12/16 - 17/12/16

Task length:

3 days

Mentor(s) I worked with:

Walter Bender

Description:

This was my first task. I chose to resolve an issue as I hoped that by debugging I would learn more about the application and frameworks involved, and this seemed the least ‘scary’ introduction to Sugar Labs! My chosen issue was “Coordinates of turtle changes after resizing the window” in Turtle Blocks - this was a bug in Turtle Blocks (a Scratch-like LOGO program) where when the window was resized, the coordinate grid would resize but the turtle would not move with it. Looking at the code, I found that this was due to the fact that no resize function was implemented for the turtle; to fix the bug I implemented a resize function for the turtle and, as the traces of the turtle would be too complex and time-costly to resize, cleared the screen of turtle pen marks after resize.

What Went Well:

I completed this task relatively quickly - it took just over two hours, spread over two days. I made good decisions regarding the practicality of resizing the turtle pen marks - I decided that the benefits gained by implementing this were very small (the user resizes very infrequently) and would be heavily outweighed by the time and complexity of doing so.

What Did I Learn:

I learned about submitting pull requests and working with open-source projects. It also helped me to get to grips with Turtle Blocks and how it works, in particular with easel.js. If I were to do this task again, I should take the time to leave proper comments around code I modify and provide more detail in my GitHub commit - I’m stuck in quite bad coding habits as I’m too used to coding by myself.

Time taken:

18/12/16 - 19/12/16

Task length:

3 days

Mentor(s) I worked with:

Walter Bender

Description:

Since I had been working with Turtle Blocks and felt slightly more confident with it, I decided to give this task a go. Due to good commenting and very neat coding, the Planet code was pleasantly readable and easily modifiable; to implement this I changed the images on some of the Planet thumbnail buttons and added a button to the thumbnail HTML template structure which, when clicked, would create a tooltip with a link to the project on the Planet server.

What Went Well:

I feel that in this task I integrated my code more nicely into the existing framework than in the last task - I still didn’t make many comments though. Also, I was slightly more verbose in my commits and pull requests, making it clearer what I was doing. While doing so, I found a bug which I reported in the correct manner.

What Did I Learn:

This project taught me a lot about CSS (which has always been a weak point for me) as the tooltips proved to be quite challenging to implement. Also, I learned how to use document.getElementById and how to manipulate the styles and properties of elements via JS and the DOM. I improved my knowledge of JavaScript prototypes and the use of “this”.

Time taken:

20/12/16 - 21/12/16

Task length:

3 days

Mentor(s) I worked with:

Walter Bender, Devin Ulibarri

Description:

I found this task more challenging than the previous two tasks - unlike them, this task required me to actually work out how the turtle was rendered on screen and how notes were played from the turtle, and link the two by making the turtle blink when notes were played. This task took much longer than the previous one - this was the first task to require essentially two full days. After digging through the Turtle Blocks code for a few hours, I decided that the method I would use to make the turtle ‘blink’ was to change its colour to grey then fade it back to the original. I sent this off for review with high hopes at the end of the first day… but I received my first ‘More work needed’. Some very helpful comments were made there, and, not too disheartened, I resumed coding the next day - instead of changing the turtle’s colour I enlarged it using easel.js’ tweening functions and shrunk it over a period of time determined by the length of the note. This implementation was more efficient and had less ‘stutter’ and delay; it was accepted.

What Went Well:

I took on board feedback given by mentors and applied it appropriately (handling failure gracefully). I used documentation and Stack Overflow correctly, mostly avoiding the temptation to simply copy snippets.

What Did I Learn:

I found out much more about easel.js, especially about how the stage updates and about tweening. I discovered and joined the Sugar IRC channel during this task - I learned that the Sugar community can provide help and support and that communication is crucial for success.

Task #4: Create a Synonym-Antonym activity (Web version)

Time Taken:

21/12/16 - 24/12/16

Task Length:

4 days

Mentor(s) I worked with:

Walter Bender

Description:

This Herculean task was a huge step up from the previous three. After I selected it, I almost immediately regretted my decision, but decided to struggle on with it and see how it turned out. I decided to use the easel.js framework for the activity as I had learned about it during the previous few tasks. After drafting a plan for it on paper, I slowly began to code it, one step at a time - I first implemented the boxes to drop words into, then the words themselves, then the function whereby the words dropped from the screen, quite quickly (in a day). However, I soon learned the truth of the maxim attributed to Tom Cargill from Bell Labs, “The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.” - the small parts of projects take much more time than expected. Hence, due to many bugs in the code and unfamiliarity with JS in general, the scoring, lives and level system alongside the creation of the synonym-antonym corpus took the remaining two days to implement.

What Went Well:

I didn’t give up during the task but instead struggled through issues and bugs innumerable, finally finishing it with a day to spare. I was reasonably independent and tried not to plague the poor Sugar mentors with questions… I followed the Sugar constructivist ethos of ‘learning through doing’ - allowing myself to make mistakes but trying to learn productively from them, and to not consider myself at fault when I do so.

What Did I Learn:

Many things… :) In particular: How to set up a Sugar Web Activity, how to use require.js, how to setup and use easel.js, how mouse events work in easel.js, how graphics work in general in easel.js, how to manage time and timeouts in JS, XML processing and manipulation in Python (to create the corpus), how to use, import and process JSON, how to manage a large project spanning many files, how to debug effectively with the Chrome developer tools console, how to create Sugar-friendly icons, how to publish Sugar activities on ASLO.

Task #5: Introduce Yourself

Time Taken:

25/12/16 - 26/12/16

Task Length:

3 days

Mentor(s) I worked with:

Walter Bender

Description:

I chose this task partly to learn more about Sugar and its values, and partly as a short break from coding. Walter Bender very kindly shared with me two chapters of his book on OLPC/Sugar: “Learning to Change the World”, which shed some light on Sugar’s history and how Sugar became a separate entity from OLPC, along with giving much information about why Sugar does what it does. I wrote a ‘potted history’ of Sugar along with some information on why I decided to try GCI, and published it on this blog.

What Went Well:

I wrote a thorough and informative history of Sugar quite efficiently.

What Did I Learn:

I learned about the history and ethos of Sugar, and about how to effectively use Markdown to format a document. I also realised the benefits of trying to be more concise in my writing…

Task #6: Install the Sugar development environment (Beginner Task)

Time Taken:

27/12/16 - 27/12/16

Task Length:

3 days

Mentor(s) I worked with:

Ezequiel Pereira

Description:

I completed this task simply because I needed to set up the development environment for the next task I wanted to do.

What Went Well:

I completed the task successfully.

What Did I Learn:

I learned about VirtualBox and how to use Fedora Linux.

Task #7: Port xoEditor activity to Sugarizer

Time Taken:

27/12/16 - 30/12/16

Task Length:

3 days

Mentor(s) I worked with:

Lionel Laské

Description:

Since I had successfully made a web activity in task #4, I decided to try this task as it was of a similar nature (develop a web activity). As before, I used easel.js to code this activity. This activity allowed the user to change the colour of their XO buddy icon in Sugar - it consisted of many different multicoloured circles in a spiral which, when clicked on, changed the colour of the buddy icon. This was rather straightforward to code, as I could directly port the code for producing the coordinates to put the circles in a spiral into JS, and I could use a very similar method to that used in task #4 to create the draggable circles. However, for this activity I had to implement a save/restore feature; this involved using many Sugarizer-specific functions and provided quite a challenge in terms of debugging.

What Went Well:

I created a neatly coded, commented activity that replicated exactly the feature of the original. I appropriately reused code I used in task #4 and modified it to perform a similar task.

What Did I Learn:

I learned about many Sugarizer-specific save and restore functions, in particular about the activity-specific datastore, and I also improved my knowledge of callback functions and ‘computational thinking’ in that respect.

Time Taken:

31/12/16 - 1/1/2017

Task Length:

3 days

Mentor(s) I worked with:

Walter Bender

Description:

In effect, this was a continuation of task #2 - I had to add the Share Link” function to published projects in Planet. However, this was not as easy as simply using the same code used for the Share Link function for the local storage projects - one of the side effects of an inefficient implementation of thumbnail rendering was that any tooltip, when opened, would close immediately unless all thumbnails were rendered. So to complete this task, not only did I implement the tooltips for the published thumbnails but I also improved the thumbnail rendering implementation.

What Went Well:

I managed to diagnose the root condition of a bug and fix it, allowing me to fix the bug. I wrote a very thorough PR explaining the changes I had made.

What Did I Learn:

I learned about how JavaScript handles programmatic changes to the DOM / HTML (and so why calls to appendChild are more efficient than rewriting innerHTML).

Task #9: Port Reflection activity to Sugarizer

Time Taken:

2/1/2017 - 5/1/2017

Task Length:

5 days

Mentor(s) I worked with:

Lionel Laské

Description:

This was another porting task. In general, I find these tasks challenging but enjoyable - they challenge me to implement many different features of an application robustly. This activity allowed the user to practise reflectional symmetry by clicking a grid of dots to make them change colour until they had a certain type of reflectional symmetry. While this project did not teach me many new skills, it definitely helped reinforce things that I have learned over the past two JS activities I have coded, like easel.js functions, save and restore Sugarizer features and responsive design.

What Went Well:

Again, I managed to create an activity that worked well in Sugarizer with identical features to the Python version. The code is neat and it is reasonably extensible - new types of symmetry can be (reasonably) easily added.

What Did I Learn:

I learned how to implement responsive design in easel.js - in particular handling screen resizes. I also became more confident implementing large projects with a deadline, and maintaining good communication as regards bugs and feature requests.

Task #10: Turtle write directly to the canvas instead of using Easel

Time Taken:

6/1/2017 - 6/1/2017 (I worked on this task alongside task #9, but never claimed it until I had implemented a solution as I didn’t know if there was a solution.)

Task Length:

4 days

Mentor(s) I worked with:

Walter Bender

Description:

This task asked the developer to fix an issue in Turtle Blocks whereby “running a complex graphic slows to a snail’s pace over time” by changing the method of storing the turtle path from storing each individual segment as a CreateJS shape to drawing the path on a canvas. Initially, I had my doubts as to whether this would work, as easel.js uses the canvas and wipes it every time it updates an element (e.g. when the turtle moves). However, I found a way to counteract this problem: I changed the turtle path so that it drew the path on a hidden canvas behind the main canvas, and that, every stroke, a CreateJS bitmap was updated with the latest contents of the hidden canvas.

What Went Well:

I displayed initiative by finding an alternative solution when the proposed solution would not work; I also understood the turtle.js code thoroughly enough to effectively reimplement it.

What Did I Learn:

I learned about the way that easel.js handles the canvas and drawing, and about visibility in HTML.

Task #11: Port Abacus activity to Sugarizer

Time Taken:

7/1/2017 - 16/1/2017 (it didn’t help that school started on 9/1/2017…)

Task Length:

5 days

Mentor(s) I worked with:

Lionel Laské

Description:

This final task was the most challenging of all the tasks I tackled, and personally I found it a culmination of everything I had done so far - from making a Sugarizer activity to use of easel.js to responsive design to save-and-restore to quality assurance and debugging, it was all there and all had to be tackled. This task required me to implement a variety of different abaci along with features such as highlighting of recently used beads; at many times I had serious doubts that I wouldn’t be able to fix this bug, say, or implement this next feature in the endless TODO list, but I kept going and eventually I implemented everything. This project also taught me many useful skills - for example, I had to decide on a data structure for the abacus beads and I had to make heavy use of array splicing for bead shunting on the abacus.

What Went Well:

I had enough determination to finish the task, even when the going became tough. I maintained good communication with my mentor and listened carefully to and took good heed of the advice he provided. I tried to keep my code maintainable even when it began to grow, and I ensured that I stuck to deadlines I set myself, giving notice as soon as possible to my mentor when I was unable to achieve them (for example, when I had a fever from 14-16 Jan).

What Did I Learn:

In terms of new features, I learned about the Sugarizer palette to group similar icons together. However, I learned many other far more universal skills as well - managing a large project, good coding style and self-confidence.

Final Remarks

Overall, I feel GCI has taught me numerous skills, both psychological and technological, and my coding has improved in leaps and bounds. Thanks to all the mentors who have helped me along this journey, in particular Walter Bender and Lionel Laské, and I hope to volunteer again with Sugar Labs both in GCI in the coming years and in the future.