At the finish line – final report

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.

Mid-point progress report

Outreachy internship blog – part 4

Since my original post for this topic got lost somewhere in the cyberspace after I have spend several hours writing in – here is my second attempt.

End of January marked the mid-point of my internship with Mozilla, working on the project of making columns in Network Monitor resize-able. Original timeline that my mentor and I set up for the project is here.

Time Period	Task	Details & Outcome
Week 1-3	Code base analysis	Document summarizing results
	UI/UX analysis	PRD Document with screenshots and mockups (showing existing support in other browsers)
1st checkpoint – December 20, 2018	Analysis done	Finished with Code analysis doc and UI/UX analysis – outcome can be  PRD doc or an analysis doc
Week 4 Christmas week		OFF
Week 5-6 (first two in January)	Implementing a prototype	implementing a prototype of resizable column component (that would be re-usable, shared) review the prototype/architecture and implement any suggested changes work out patch landing strategy (including breaking down changes into smaller patches) (order and logic of patches), e.g. hidden behind the pref
Week 7-9 (last three weeks in January)	implementation	implementation phase – build resizable columns feature in the Network panel (based on experience with the prototype) Save in preferences integrate into DevTools properly spliting all changes into smaller patches that are easy to review. testing and collecting feedback regarding – functionality testing influence on performance write down automated tests specification
2nd checkpoint End of January 2019	Working prototype, implementation on the way
Week 10-11 (first two in February)	Testing & Collecting Feedback	Automated test coverage – write tests for the new implemented feature Mochitests document all introduced bugs, suggested optimizations work on bug fixing, UX/UI polishing, code clean up Stretch goal? – reorder columns
Week 12-13 (last two in February)	Bug fixing
3rd checkpoint – End of February 2019	Resizable columns implementation done	Working solution
Week 14 (first week in March)	Documentation	writing of final documentation of all the code written and landed writing a Blog post on hacks.mozilla.com about the feature more polishing and code clean-up

First month:  learning by doing…

In the time prior to my internship start date I have started to work on two bugs and one of them has turned out to be a much bigger scope then just a ‘good-first-bug’. This work carried on into the internship period. I enjoyed working on it because it included changes in UI and also in the logic of Headers Detail panel of the Network Monitor.

While I worked on this issue, I got more familiar with code base and components of Network Monitor. I learned more of React JS and how Firefox uses it. In addition, my mentor explained and encouraged me to use Debugger more which was helpful. So even though it took lot of time that I could dedicate to my project, I valued the opportunity and consider it a great part of my overall learning opportunity.

By the end of December, I have managed to finish the analysis for the internship project on Network monitor columns, although I have not started any real work on it. But I was more familiar and comfortable using Mercurial source control tool, Bugzilla – bug tracking tool, I gained experience pushing patches to ‘try’ server, fixing broken tests and more.

Second month: New Year  – new beginning.

With the beginning of January, I finally started coding what was needed for making the columns of Network Monitor resize-able. I really struggled with CSS because the css file related to the headers component was quite complicated. I managed to have a first patch that allowed re-sizing and I was able to have the size of columns saved and read from the user preferences. With more and more code and structural changes in the Network Monitor, we started doing regular performance testing with every set of changes. At the same time, I continued working on the bug related to Headers detail panel mentioned earlier. I was able to submit the final patch and land that fix in January.

As the work continued on the re-sizing of columns, I have struggled with the complicated DOM structure and its corresponding CSS styling. We made a decision to implement several changes in the HTML table and its table elements. But I felt like I couldn’t be sure that we are heading the right direction because I couldn’t make things work even though it all made sense to me.

So at this point (of frustration) my mentor Honza had a splendid idea to create a simple React App where we would be able to work forward in the desired direction but in a much simpler environment. And voila, as soon as he created this ‘playground’ for me, things started to make sense and confirmed that the logic and the direction we were heading was indeed correct. I was able to move forward in my work faster and then import the implemented changes from this simple app back into DevTools. So I am really grateful to my mentor for that idea :-).

Where we are at midpoint.

As I am writing this (few weeks past the mid-point due to the lost blog post) we are further ahead and I can tell that my feeling of Netmonitor having too complicated structure was right. We are currently working on simplifying the structure and CSS styling. More on that in the follow-up blog post.

At this point of writing a mid-point progress report, I am glad to say that we have a working prototype of resize-able columns. I am still working on some bugs, polishing tests. We still need to improve performance and simplify CSS styling. Also, at the same time as we work on the resizing of columns, another work is being done on  simplifying the whole Netmonitor structure (hurray). We will have to rebase our work on those changes as well.

Grateful…

Looking back at half time, I am amazed at how much I’ve had the privilege to learn. I am thankful to my mentor for his patience and for explaining and teaching me lots of things. Now as we are finishing, he has scheduled our check-ins on a daily basis, giving me direction, setting tasks, going over the code, talking things through…

It wasn’t easy and still isn’t, it requires often working late or during the weekend, much more than just 40 hours a week. But I am motivated and want to finish the project as planned. And on top of it all, although I am tired, I like what I am doing. 🙂

Explaining my work on Network Monitor

Outreachy internship blog – part 3

For this internship with Mozilla I am a part of the Firefox team called DevTools (developer tools). Developer tools are different tools that help web developers in their process of building web pages and web applications. The tools are part of the browser although not visible to the regular user who is just searching the web. Developer can open the tools by right-clicking anywhere on the page and selecting Inspect Element . There are several different developer tools, like Inspector, Console, Debugger, etc. I work on the Network Monitor.

What is a Network Monitor?

The Network Monitor shows all the network requests Firefox makes (for example, when it loads a page), how long each request takes, and details of each request. Simply said, one can monitor all the internet traffic between the browser (client) and the web server. When the browser asks for some information – it is a Request. When the web server somewhere out there replies with information – it is a Response.

 

Image from here.

What is it good for?

I think web developers would give you many different answers. It can help to improve the speed (performance) of web pages, it can help to find out where the information on the webpage comes from, how much information the page receives, it can check for failures…

To keep it simple, here is one simply use case from (my) school boy. His school project was to create a video about something. He wanted to add some “machine” voice to his video so he decided to use google translate since it allows to listen to the translation text. With the help of Network Monitor, he was able to download a voice file, generated by the google translate page.

Here are the steps he took.

• Navigate to google translate and open DevTools.

• Click on Network Monitor.

• Press listen (the speaker symbol) and watch the network traffic. Then in the list of requests, select one with file type mpeg.

• Right click and select Open in New Tab

• When the new tab opens, right click and select Save Audio As

And he’s got his “machine” voice that he played in his school project. 🙂

And what is my humble task?

Many web developers would like to adjust the width of different columns that are part of the table in Network Monitor. This feature has been repeatedly asked for, so my internship project is “Implement support for resizeable columns for Network panel in Firefox Developer Tools“.

My internship work consists mostly of:

• reading a lot of code,
• writing code to implement resizing of columns in the table of requests
• testing for functionality
• testing for performance
• reading lots of documentation
• learning constantly

What am I learning?

I am constantly looking something up, refreshing some information or simply trying new things out. Here is a list of some things that I am learning:

• more of React JS and the way Firefox is built
• how to store and load different browser user preferences
• lot of CSS although I still feel like CSS hates me 🙂
• Mercurial version control system (this is a tough one)
• how to use Browser Debugger
• how to use automated tools for testing
• generating and using ssh keys for authentication
• encrypting information in email (for outreachy tax info)
• I am also learning how and when to ask for help.

So that’s it. Hope you now have a better understanding of what it is that I currently work on.

I struggle too

Outreachy internship blog – part 2

When I read this week’s blog topic (Everybody struggles) I knew that was about me. My first weeks of internship have really been kind of a struggle.

What was I struggling with?

Basically, I’ve been struggling while fixing one bug that I have started before the internship officially began. The bug’s description sounds pretty easy – Network Panel should use proper styling. It involves moving two buttons to another place in the panel, change one of the buttons into two toggle elements, change the wrapping of longer lines, etc.

It took me a while just to figure out where exactly in the code should those React changes go. That was needed even before any CSS changes. After I spent several days tweaking my React js code I made only a small progress. I was hesitant to ask for help because I thought that I was going the right direction and that only because I am not that skilled it takes me longer. I thought I simply have to press on.

I was also doing different CSS tweaks and honestly I sometimes felt like CSS hates me. 🙂

What happened when I reached out for help?

After I finally decided to consult my mentor, we scheduled a session where I asked him to explain some parts of the code in the component that I was working on. It turned out that I was actually changing one part of the code but there was a much more convenient place for my desired changes.

I spent next working hours coding the changes and before our next meeting the following morning I was able to show my mentor progress.

Consulting my mentor helped me also in another way. I was mostly logging things in the console when I was debugging my code. My mentor encouraged me to become friends with Debugger and helped me with it in a live session. So that was an improvement in my work.

Is the struggle over now?

Now I still have several CSS changes that I had to do on this bug before I can submit a patch. Sure it bothers me because it’s taking longer than expected and I am slowed down working on the internship project. I want to finish this one bug first. Then I will move on to the internship project and follow our plan.

Discouragged?

I am an optimist. Everything new is hard at first and generally speaking I like challenges. So I am prepared to invest all those extra hours now in the beginning, hoping for an improvement with the coming weeks. I look forward to what’s ahead. So even though there are struggles, I would say: “So far so good :-)”.

P.S. Only 2 days after publishing this post, my attention was caught by this excellent post that describes EXACTLY my feelings during these weeks. It is encouraging for all beginners feeling frustrated. Read on…

Ready Set Go

Outreachy internship blog – part 1

Here I am in Orlando, FL at Mozilla’s All-Hands meeting. It is my first week of Outreachy internship. I am an intern working for Mozilla and I am really excited about it.

What is Outreachy?

Outreachy is a program that organizes three-month paid internships with free and open-source software (FOSS) projects for people who are typically underrepresented in those projects.

Outreachy internship projects may include programming, user experience, documentation, illustration and graphical design, or data science. Internships are open to applicants around the world. Interns work remotely with mentors from FOSS communities.

I’m working for Mozilla on developer tools for Firefox. Specifically, I am working on implementing support for resizable columns for Network panel.

Why did I apply to Outreachy?

I first heard (read) about the program on Medium where I read an article from a previous intern. I am learning Web development and always want to learn more and move ahead. I have previously participated in Chingu cohort where I learnt React and now I wanted to extend my experience so I can eventually use it in the job market.

After reading about the program, I got really excited because it was not just for students like some other internships. I am a mommy and I stayed home to care for our kids. I was learning web development and now there was a chance for me to progress and work on real life projects. (As it turns out there are more mommies in the Outreachy program.)

How did I choose this particular project?

When the projects were announced on the Outreachy page I went over the list and selected those that had in requirements React. I like React and wanted to use it more.

Eventually I picked working on the developer tools (Network panel) because I thought I’d like to learn more about using the dev tools for my web dev future :-). (You know – learning by doing 🙂 It also seemed challenging enough and it appealed to me.

How was the application process for me?

After I chose the project I went through the process of installing and creating my own Firefox build. It wasn’t smooth. I had to deal with several problems caused by specific windows behavior. Eventually I managed to get it working and I was able to start.

Part of the application is a requirement to make at least 1 contribution to the project before submitting your final application. So I went to choose a ‘good first bug’ to work on. It turned out that wasn’t easy either. There were no more ‘free’ or ‘unassigned’ good first bugs so I had to look through bugs for devtools to try to pick something. Luckily together with my mentor we were able to find a bug that I could start working on.

And then the work began. For about a month I tried to spend every free time to work on contributions. Understand the code base (or to be humble – understand those few java-script files I was working on), make some sense of the CMS Mercurial (it is still NOT my best friend) and try to figure out what should I try to google/solve myself and what should I ask my mentor (Google IS my best friend :-).

My mentor was great at giving direction when I asked. Step by step he was giving me more and more responsibility so I was learning new things during the whole application process. At the end, I successfully managed to land 2 patches for 2 bug fixes in devtools and submit my final application. Also, I continued working on the contributions even after the application deadline.

When I found out I was selected I was really happy. The month of hard work has paid off and there are now 3 months of learning, building and coding in front of me. 🙂 Yeay!

Looking ahead

I am totally looking forward to this new experience. Learning is the primary reason why I’d encourage anyone eligible to apply for Outreachy. Working with so many smart people is invaluable. You learn software engineering skills that you’ll use in your day to day job as a developer.

Even this past week at Mozilla’s All-Hands has been quite eye opening. I see the mission of this great open source project (and of Mozilla organization) with new eyes. I am thankful that I can become a part of it while learning and building within devtools. I am thankful to my mentor for all the guidance he is providing and to other helpful people on the dev team. And finally, I am thankful to Outreachy and Mozilla for giving me this chance!