The Wonders of Mozilla Proper

Last week, the team managed to finish the functionality for bi-directional syncing with MakeDrive on the browser, that being a huge milestone in the Nimble project. Helping in the design of the front UI, work on unit tests, and pair program through bugs was as rewarding and productive as it could've ideally been.

The cherry on top of the icing was being able to visit the Mozilla office downtown to present the demo on Friday. The working space in and of itself is worthy of song and film, with ping pong, a music corner, couches abound, snack and fruit bar, and an espresso machine that cannot get enough praise for its impeccable quality. More importantly, to be able to gain insight from and work with some of the most talents minds in the industry was invaluable to say the least.

With project lead David Humphrey expected to return from vacation this week, there's lots of catching up to do with Websockets authentication and changing the client codebase to function completely off of Websockets instead of server-sent events. Another daunting week ahead, with newfound energy and inspiration to tackle the tasks ahead. 

To Websockets or not to Websockets

With project lead David Humphrey currently on vacation and senior team member Ali Al Dallal called away to Vancouver with tertiary work from Mozilla, there was no shortage of work to be done or tasks to be undertaken. Kieran Sedgwick went ahead and took over Makedrive unit testing for the time being in order to try and eventually successfully solve the nightmarish bugs that blocked the tests' infrastructure from being fully implemented and able to support comprehensive codebase testing.

Concurrently, I went ahead and switched gears and focused on the two tasks of trying to research and piece together a proof-of-concept of a Websocket-core API system that handles user and session authentication before automatically upgrading the connection protocol from HTTP to WS. This is still a work in progress, but much learning is being had thus far. Some decisions might need to be made on the issue of the potential limitations of the core library not being able to handle upgrade events as comprehensively as might be necessary in order to properly and securely create this connection switch validation.

Lastly, I was helping fellow team member Gideon Thomas with the planned upcoming demo of the bi-directional syncing functionality of Makedrive, mainly with designing the front-end UI and pair programming through the client-to-server communication and invocation of our libraries. That unfortunately wasn't able to be materialized due to the discovery of a bug with the server-side diff route validation that is still being solved to this day which not only affected bi-directional syncing but the unidirectional syncing that was demoed weeks earlier as well. Slightly heartbreaking, but on we fight with the knowledge that eventual victory will taste that much sweeter.

Makedrive Unit Testing

In most projects of similar breadth, understanding the big picture is paramount in the search of perfecting the design and function of the system itself. This week was crucial in my comprehension of how all the pieces need to integrate into the final product in order to satisfy all the desired end-user applications of the APIs that we're creating.

My assigned work was primarily focused on unit testing the sync route hierarchy that takes place when the end user initiates a file save from one of his active sessions. This is the perfect task for mastering one's familiarity with a complex codebases. A firm grasp of what each variable, function, and object contains and passes is paramount to successfully and efficiently test against the environment. On top of polishing up agnostic unit testing syntax and conventions, I inevitably have to traverse through all of the code in a way that isn't necessary to accomplish most other work. This is turning out to be an extremely fascinating and challenging endeavour, since valid user credentials from the client session as well as valid session objects including file and directory data must be present and persistent in order to initiate the sync sequences and were therefore arbitrarily mocked in order to successfully go through each route. This infrastructure was developed by project lead David Humphrey due to the time constrained nature of the current sprint, but the helper functions that I wrote and am presently using ended up emulating the same behaviour in order to achieve the similar goal of having to persist valid session data throughout the test process.

Backtracking to more fundamental concepts that I must still catch up on, I've taken the weekend to fill in some knowledge gaps with object context and scope in javascript. A great article I've found on this gives insight on this from the simplest to the more realistic use cases can be found here.

With the first of the 4 routes seeming to be properly implemented, and with the help of fellow teammate Kieran Sedgwick, I intend on finishing the test foundation for all of the primary sync routes by the end of today and start integrating this logic with rsync and websocket applications for the rest of the week.

The Acclivity that Separates Programming from Development

Concluding this week was the presentation of Webmaker team's first completed two-week-long sprint which showcased the initial integration of makedrive with filer and its initial connection with client-side DOM sessions. As I alluded to in last week's post, my work on this heartbeat was primarily focused on implementing Server-Sent Events.

The design was structured as so:

(This was also seen in my original proof of concepts' front-end page). The initiating client session would "save" a file they just created, effectively sending a request to push the data into the server. Once validation and syncing would be completed, I (along with great help from Mr. Sedgwick, yet again) used a server-sent event back to all the other active client sessions (on the same user) that the sync and push has successfully completed and that it's time for them to update their version from the server. Completing the cycle and syncing all the other sessions is one of the goals of the upcoming sprint we are about to undertake.

The demo, although executed wonderfully as a concerted team effort, ended up being received with a rather tepid response. This was likely due to the majority of the mozilla developers being away at conventions, and leaving the large part of the crowd to be more community and marketing work-oriented folks.

This week I will be working on writing server-side and restful-API unit and functional tests. More to come next week, as usual.