Manel Rhaiem: CD Outreach Intern

The Project Haiku and CD Metrics Team would like to thank Manel Rhaeim for her contributions over the past summer.

Manel Rhaiem was an Outreachy intern in Summer 2016 who worked on Connected Devices. During Manel’s internship, she made contributions to both the Project Haiku team and the CD Metrics team. In Project Haiku, she worked on doing data analysis for our second user research experiment. She also made contributions to a web-based prototype for the ongoing user testing and experiments.


Manel worked with a variety of technologies in Project Haiku, including SQL,Google BigQuery, Periscope/Re:Dash, HTML/CSS/JavaScript, and programming libraries for devices such as the Particle.  Manel was also an active and engaged member of Project Haiku, always ready to participate in brainstorming discussions and prototyping exercises. On the CD Metrics team, Manel worked to implement the floating-point code for the existing metrics library. She then helped several teams including Project Magnet and Project Vaani implement the metrics library as well as help them out with some data analysis.

Manel Rhaiem has been involved with the Mozilla project since 2012. She is a member of the Mozilla Tunisian community. Manel has participated in every single Mozilla Work Week since Portland. She has contributed to a variety of areas including QA and l10n, and has lent her expertise to various projects which have included Firefox OS and l10n. At the 2014 Mozilla Festival, Manel helped flash some of the thousands of Firefox OS phones that were distributed at that event. At the Mozilla Work Week in 2014,  she participated in the right-to-left (RTL) language pattern decision-making meetings and was also instrumental in testing RTL localization on Firefox OS. She was a dedicated Firefox OS tester and never hesitated when asked to help with testing. She also worked alongside the Firefox OS team and learned how to write Firefox OS automation.



Manel is a Mozilla Rep and also part of WoMoz.


Thank you, Manel!

Russ Nicoletti, CD Metrics Team

Manel contributed to both the visualization and the coding of the CD Metrics project. She used her expertise in both Re:dash and Periscope to provide data visualization to the Haiku and Magnet projects. She also added floating point support to the CD Metrics library, which involved updating software in javascript, Rust, java, and C. Manel was a pleasure to work with; always enthusiastic and willing to take on any challenge.


Kate Glazko, Outreachy Co-Mentor

Manel has been a community member of Mozilla for a while, but this summer as an Outreachy intern, she jumped in and made a big impact on the projects she was working on during the wild ride that is the prototyping/experimentation process of Connected Devices. Manel did a great job staying positive and optimistic in the face of uncertainty and the unknown, and was not one to back down from a challenge. She would go out of her way to attend and participate in meetings with her teammates in a timezone different from hers and showed consistent passion for the projects and people she worked with. Thank you for being a great intern and Mozillian, Manel!


Mozilla Outreachy Mentorship

Hi all! So, this is a post regarding my work as a mentor for the Outreachy Program. Mozilla participates in this program to help foster diversity in technology. The intern I am mentoring, Manel, is a talented techie and student from Tunisia. She has been working with on Connected Devices initiatives including working through data analysis for Project Haiku’s User Research Test #2, contributing to the CD Metrics Controller Library, and actively engaging in prototyping/ideation efforts from our teams that are a trademark of CD work.

It recently became the midpoint of her internship with Mozilla, and I would like to write about how having an intern during lean-style work and change as a constant is actually possible and can be enjoyable. In CD, lots of things are changing as we quickly iterate through new ideas, test them, and move on. The standard internship, where one is given one specific project to complete in X amount of weeks can’t fit into this mold. Instead, you need to be a little bit more creative to make the internship a great experience for both intern and team.

  1. Foster communication and encourage regular meeting attendance. When working in remote teams, as we do at Mozilla, and everything is changing- it can be very difficult to understand what is going on. Make sure that intern/team communication is happening daily and that the intern feels comfortable interacting with a variety of team members so they are not waiting on a single person bottleneck.
  2. Stress the idea that change, rapidness, and chaos is not to be feared. In the typical internship, things are very structured. An intern on a prototyping team that is constantly iterating needs to understand that intern projects will resemble full-timer work on these kinds of teams: the projects will likely be small, performed quickly, and not as polished as they may be used to.
  3. Disappointment is ok! On iterating and prototyping teams, many ideas and approaches emerge. An intern, like any full-timer, may find themselves getting attached to ideas and work. As a mentor, you will need to make sure that you communicate that part of working on this kind of team means that sometimes ideas and even work can get left behind- and that is a natural part of the process.
  4. Involve the intern in brainstorming sessions and other important team meetings. Part of the reward of having an intern involved is getting a fresh perspective and fresh ideas- and that is really valuable! Leverage it by never leaving them out of the process and siloed to only “intern tasks”.
  5. Being on an innovative, iterative team will teach the intern many lessons by giving them the opportunity to be hands-on in a way that typically only employees at start-ups or innovation labs get to be. They will leave with the technical and mental skills of getting things to work quickly, creative/design thinking and ideation, prototype mentality, cross-functional cooperation, client/user awareness, and much more- and hopefully a newfound passion for making new ideas a reality.

So, no matter what kind of team you have, an intern can always be an awesome part of it!

Non-Technical Things I Learned from Google IO 2016

Innovators come in many varieties

One thing that struck me about Google I/O was the variety of innovators and change-makers taking the stage. Some of these individuals were my age, in their early twenties, and some were much older, and many were in-between. People of various races were represented. Both males and females lead dynamic talks and presentations.

As an aspiring innovator myself, it was beyond motivating to see people like me teaching others about emerging technologies, social trends, accessibility, and more. As a new software engineer in the industry, it is all too easy to feel like your only role is to produce bug-free code. However, the people my age on the Google IO stage showed me otherwise; that it is in fact possible to go beyond the technical and to connect with people, explore the impacts of their technical work on society, and step up as teachers and mentors for others regardless of experience or age.

It was thrilling to see an older Google employee state during his presentation that it had been his dream for thirty years to present on the Shoreline Amphitheater stage, and to never give up. I sure know I won’t!

tl;dr Allow people from all walks of life to be innovators and influencers, and the result will be a greater sense of inclusion and representation.

VR Finally Won Me Over

It is true- I have been a semi-VR skeptic for quite some time. I was convinced that VR is an anti-social experience, and can lead to people shunning the real world. After seeing the Google Expeditions presentation, I am glad to say that I am wrong.

I learned about the possibility for VR to change education- by allowing students to explore places that they wouldn’t otherwise be able to explore, like the site of the Chernobyl incident or inside the human human body on a cellular level. VR can also allow the students to relive historical moments and gain a visual context they otherwise wouldn’t be able to.

I learned that if done right, VR can be a social experience. Apparently, people once feared the movie as well because they feared it would be an anti-social experience that an individual would watch alone- and look at us today, with movie theaters and group Netflix binges! If the hardware experience and software experience are done right, VR can in fact be social. ( On a side note, this has become a new interest of mine- social VR- and I will be investigating it in weeks to come).

Also, VR can be used to supplement real life field trips by adding information panels and visual overlays. I’m wondering if that would be considered more of AR? VR or AR, consider me fascinated!

tl;dr Keep an open mind and learn more about technologies you are skeptical about

Users are easily frustrated

  • User engagement decreases when scrolling performance decreases.
  • 40% of people abandon a website if it takes more than 3 seconds to load.
  • 92% of people give up if they’re not able to sign into a website right away.

tl;dr Add some extra effort to improving your user experience

Being in the open is better

With many sessions being streamed, Google I/O was able to increase participation from around the world. This also served to benefit many attendees who were unable to make it into the many limited-capacity sessions. It is also an inclusive strategy- with tickets running a high price of $900.00, Google made sure that price was not a barrier to allowing as many people as possible to gain knowledge about their emerging products and new approaches to doing things.

tl;dr Less people miss out and more people learn when you leverage existing technologies to be inclusive

That’s just some of the things I learned! How about you? What did you like about IO16? Sound off below!


What I Do

Sometimes people ask me what I do at work. The answer is, I code on and play with new technology and cameo as a hand model.


Yeah, I think that just about covers it. (In this particular example, these are Internet Buttons that can send messages to each other through wifi- and can even be on different wifi networks).

Particle Internet Button and Webhooks to Google Spreadsheets via Zapier

Yes, that’s a lot of fancy words for one blog post. But, suppose you have a Particle Button and you want it to POST its data to a Google Spreadsheet every time a published event happened? This method is an easy way of accomplishing this.


  • Make sure you have your Particle Internet Button fully set up, connected, and ready to go
  • Find a script or code that you want to run. In this case, I am running my code through their online builder at
  • Add some event publishing to your script. For examples on how to do this, see this link on publishing. This is an example line of code that I was working with:
  • Particle.publish(“LED_ON”,”on”,16777215,PUBLIC);

  • Go to your Particle dashboard and verify that you can see your events being published in the log. Verify that you can see the integrations tab. You will need this later.
  • Sign up for a Zapier account.
  • Have a Google account ready to use.
  • Make sure you have a Google Spreadsheet created with the following items in the top row:
  • Device Id, Event Name, Data, Timestamp

Step 1: Get Your Zap Prepared

  • Go to Zapier and choose to create a Webhooks-to-Google Sheets zap
  • Copy and paste the custom webhooks URL generated by Zapier. You will need this later. Click ‘ok and continue’.
  • Skip the section about the Child Key, we won’t be needing it for this tutorial. Save, and choose the Google Account.
  • Now you will arrive to a bug in Zapier. It will tell you to ‘Try Turning the Zap On’, and will fail.
  • Click Cancel. Now you should see the page with your non-activated Zap. Click on it.
  • Now you will see two steps: Catch Hook, and Create Spreadsheet Row. Click on Create Spreadsheet Row.
  • Go through the steps until it is time to choose a spreadsheet- choose the spreadsheet that you created earlier with the prefilled first row. Select Sheet1 or whatever worksheet page your rows are on.
  • You will come back to this, make sure everything is saved.

Step 2: Integrate your Webhook

  • Remember the URL you got earlier? Go back to your Particle dashboard and click on integration and add a new integration. Select the Webhooks option.
  • You will now see the menu where you will need to fill in your event name (case matters, make sure it is the exact same name that is in your code), the URL (paste in the webhooks URL you got from Zapier earlier), leave the request type as the default POST, and select your device under the device option (or if you have multiple buttons registered that will be running the code, leave as any).
  • Create the Webhook.
  • Make sure that your code is running on the Particle and that events are being published on the Dashboard. This is important.

Step 3: Get Your Zap On!

  • Back to Zapier, click on your hook and go back to Step 1 (Catch Hook)
  • Go to the item called Catch Hook and continue through the instructions.
  • In the last instruction, called Test This Step, if you have done everything correctly your hook will be caught successfully.
  • Now, go back to Step 2, Create a Spreadsheet Row. Click on the Edit Template step.
  • Now you will be able to click on the ‘lines with a plus sign’ icon to the right of your row names (such as Device ID), and select the correct input (coreid) that is being passed from the webhook.
  • Once you have done this for all of the row names in your Spreadsheet, turn your ‘Zap’ on using the toggle.
  • Check your Google Docs spreadsheet. If everything has been done correctly, you will see your spreadsheet being filled up with data from the Particle Dashboard.

Note: You will need to create a new Webhook integration, but not a new Zap, for each event you have. Aka if you have an event called LED_ON and LED_OFF, you will need two Webhooks integration through the Particle dashboard- but they can use the same Zap url.

Bugzilla API: Beginner’s Tips and Recommendations

If you’re new to development with the Bugzilla API, this is the post for you! I will be sharing some pointers and tips to getting started with the Bugzilla API in your code.

For reference, the official Bugzilla REST API is here.

  1. Make sure you have requests set up in your preferred environment. In my case, that meant importing Python requests.
  2. If you are doing queries that involve logging in, remember to create a mock Bugzilla account. If you plan to be hosting your code on Github on a public repo, your credentials will be exposed to the public. Creating an account that you don’t mind people seeing (and potentially using).
  3. For combining multiple queries, it may be more complicated. Go to the Bugzilla website and perform your desired search. Then, click on the REST API button at the bottom of the page. It will provide you with a URL that you can ‘Get’.

For example, I was looking for bugs in Firefox that are Tracking 39+ and have a crash signature, and I wanted the JSON that gets returned to contain the ID and crash signatures of the bug.,cf_crash_signature,status&f1=cf_tracking_firefox39&f2=cf_crash_signature&o1=equals&o2=isnotempty&resolution=—&v1=%2B’

That is how you would go about it! Once you do this frequently, it will be easier to piece queries together but for now the REST API button is your friend when piecing them together.

That’s all for now, let me know if you have any other questions. And happy coding!