Outreachy internship blog – part 5
Photo by Steven Lelham on Unsplash
Mid March marked the end of my internship with Mozilla. I was part of the DevTools team working on Network Monitor which is part of the developer tools in Firefox. My job was to implement support for resize-able columns in Network monitor.
I’d like to look back at my journey – first from the professional point of view and second from the personal point of view.
Professional point of view
Although the internship period was little over 3,5 months, my work on Firefox browser began few months earlier. When I have learned about the Outreachy program and found out that I was eligible to apply, I signed up for the newsletter and waited for the sign-up period to open. Then I chose 2 projects that looked interesting to me and started preparing my development environment. My suggestion for a future Outreachy applicant would be – get set up before the application period and start getting familiar with the code base and the structure and all the tools. In my case I had to do it all within the application period which lasts about 2 months.
The beginning…
Now I’ll jump to the point of officially starting my internship. In the beginning I was given the opportunity to participate in the All-hands meeting which takes place twice a year and is a face-to-face gathering and co-working opportunity for all Mozillians. There I got to meet my mentor Honza Odvarko and some other DevTools team members. We had time to go over the internship timeline and project objectives. We have looked at some components that we may use and decided to use component Draggable which was used in the SplitterBox component and had already some logic regarding the mouse movement and events. We also looked at which components would be modified and at the (rather complicated) structure of Network monitor requests table.
Next task was to analyze the behavior of Google Chrome Network Monitor which already offers this resize-able feature. We obviously wanted to implement something very similar to Chrome as the web developers should experience similar behavior across different browser when it comes to developer tools.
One of the requirements was to store the user preferences (the user defined width of each column) for the Network Monitor. We have decided to store the preferences in percentage (with 2 decimal places) although the actual column widths are calculated first in pixels.
Getting the hands dirty 🙂
Although the first month of my internship I have mostly worked on some other bugs related to Network monitor and not on the resize-able feature which was my internship projects, I was still working full time on the Netmonitor code base, reading and fixing the code on different Netmonitor components. I have learned that often a change in the DOM structure breaks a test (or a few) that needs to be fixed. I have learned how to generate and submit a patch for review, how to run a set of tests. I was getting more and more familiar with Mercurial – version control tool and with Bugzilla – the bug tracking tool.
At the same time our video meetings with Honza, my mentor, were often short lessons on some React JS subject or some ES6 feature that I wasn’t quite familiar with. He encouraged me to use debugger more (while I was mostly debugging through console.logs). I was definitely making progress and learning a bunch. The biggest struggle I had during that time was CSS and some features that seemed easy to implement but due to the complicated structures I had a hard time implementing.
Prototyping
Next step was to start prototyping the column re-sizing feature.
- We had to correctly implement the mouse events in the Draggable component – onStartMove, onMove and onStopMove.
- All of the column widths had to be loaded and later on stored in user preferences. We ended up using Redux store for column widths.
- It was necessary to handle correctly the cursor (mouse pointer) style while dragging – even when dragging outside the Netmonitor area.
- We needed to implement a function that would automatically adjust the widths of the columns when hiding/showing a column in the table.
- The logic for resizing the waterfall column was different then for all other columns. So it turned out we needed a function that adjusted (decreased/increased) the widths of all columns when increasing/decreasing the waterfall column.
- We had to clean-up the CSS file and try to keep the performance of the Network monitor unchanged (or improved).
During this second phase I have realized that my work is hindered by the complicated table structure that included several wrappers and <div>s that were used for styling but didn’t give much sense from the logical point of view. In fact, some table elements seemed illogical or were nested inside other table elements unnecessarily. At this time I have mentioned to my mentor that this is really hindering since I think I am going in the right direction but I am constantly “fighting” this complicated table structure. Honza (my mentor) suggested that we can create a “sandbox” – simple React app where I could test all my thoughts and code and styling. This app would be simplified version of requests table and there I could freely change/re-order the different table elements and structure in the way that made sense to me.
This was huge! I thanked Honza for that great idea. After having the simple React app as a “sandbox” we were able to prove the correct approach and make progress much faster. After that I was able to change the table structure in the Network monitor and bring in the features from the simple React app to the Netmonitor code base.
Performance issues
During this period, we have started doing some performance testing. This was again a great learning opportunity since I haven’t dealt with performance testing before. My mentor made me an instructions guide to run tests on Talos and compare them against base revision. It turned out that some of the Netmonitor tests were showing regression. This allowed me to learn more about HTML tables and the ways to improve their performance. Through some reading on Stack Overflow I also learned about CSS rules that influence performance.
Another team member Alex started looking into the performance issues and filed another bug where he discussed possible structure/ CSS changes in the Network Monitor that could influence the performance for better. I have shared some of the structural table changes that I have already done. Alex ended up landing two patches that reorganized the request table of the Network monitor. Although at first I was afraid that his changes are going to break my working prototype, it turned out that those changes were just confirming what I was thinking from the beginning. Now the structure of the table was much more logical and more simplified. At the end I was thankful for it and gladly re-based my work on top of the newest table structure.
Testing, testing, bug fixing
As I mentioned before – changes in the DOM structure caused several tests to fail. Those tests had to be fixed. At the same time we were doing a lot of testing and review and discovered different bugs that the new feature still had. So there was still more work to do.
I was also asked to write a brand new test to cover different testing scenarios for column re-sizing functionality. So I had to learn about simulating the mouse behavior in the automated tests. I have also learned how to go about debugging intermittent test failures. Again, another great learning opportunity.
Getting ready to land the new feature
When the time came that all the tests were passing and we were not aware of more bugs, we have started talking about the landing strategy.
Since we decided that the feature would benefit from more user testing, it was decided that the entire feature should land in Firefox release 68.
However, we have landed the feature patch in the previous release 67 but implemented a preference to hide the feature from users. The feature is enabled by default in Firefox 68.
What then…
When the patch landed it was time for some bug triage. I went over the list of Network Monitor bugs in Bugzilla (the issue tracker tool) and updated/closed some bugs that were related or fixed or no more relevant considering the new functionality that we just added – the support for resize-able columns.
Since I have learned so much during my internship I wrote 2 documents – 1 for myself (sort of my engineering notes or cheat-sheet 🙂 and one doc with suggested changes to the documentation for Firefox Developer Tools based on my own experience and on my own notes that I made being an intern with Mozilla.
What’s next
I am no more an intern with Mozilla but I want to continue as a contributor. I currently look at some other Network Monitor related bugs that I intend to work at.
Also, in connection with my intern work, I would like to analyze what it would take to share resizing & sorting in tables across developer tools. To separate the code from Netmonitor directory into shared directory. I loved the work and was really driven and want to come back to it as the time allows.
Personal point of view
The internship at Mozilla was quite an intensive time for me. Very soon after I started the internship I realized that I had put almost everything else on the side. I spent way over 40 hours a week working, learning, reading, testing, thinking code… I was tired but at the same time, I really really liked what I was doing and couldn’t wait to sit again at my computer. I was excited and then again I fought the imposter syndrome.
I stopped jogging in the morning (I was too tired after working late). I (almost) stopped cooking for my family. 🙂 I still had to take time in the afternoon to pick up kids from kinder-garden, school and different after school activities. Sometimes I had my youngest one at home all day when she was sick and I felt bad that she was mostly watching films or making crafts by herself. I tried my best to be there for my husband who (during that time) lost his dad.
But I have gained so much. Without a real job-interview I had my first real web-developer job. A great reference for the future. I was working with React JS a technology which I wanted to learn more of, I was part of a remote developer team. I felt like I was making so much progress. I gained confidence and experience. I can now start looking for a web development job. I am again experiencing the satisfaction that I discovered back in high-school. The reward of your code doing what you want it to. 🙂
Lastly, I want to thank my family for being so patient and so encouraging. You are great!
I also want to thank to Outreachy organization for providing such a wonderful learning opportunity. I want to thank Mozilla and all the great people – Mozillians for the welcoming, open and helping attitude. And lastly, I really want to thank my mentor Honza Odvarko from DevTools team of Firefox. He is a great mentor, teacher, leader. Enjoyed it all.