Saturday, October 1, 2016

Outreachy: the end or just a new begin?

The Outreachy internship has ended up to me (cries in Spanish), but to you can be your opportunity to apply to the next round! See information about application here: (I really would like to apply again :'(, unfortunately I can't), you can also read the first blog post of this blog to see some application tips, alternatively there is also the blog post of Anjana that are also some valuable tips. And I hope it is not going to be the end to me as well, I hope to keep being a contributor to Open Source.

Because of the next round, I have been receiving some questions, and some of those doubts I had as well when I was an applicant... So I'll answer some of them here.

1) How should be the relationship with the mentors? How much I should talk to them?
I kind of had this question in my mind as well when I applied: "Am I asking too much? May s/he thinks that I am not interested enough?", but I think I have related in a good way that they didn't thought that I was a freaky, neither that I wasn't interested: I picked a bug, and started to solve it, the relationship with my mentor them was basically discuss the bug. During the internship, I could talk to him about other themes, not only work... But for a first initial contact, I would suggest to you ask basically about your work, and don't be shy: you can ask as many technical questions you want: they are hiring interns, not senior developers, so you aren't supposed to be a tech guru.

2) What if the issue I pick was too hard?
I said on my first blog post, that you should not do just a trivial collaboration (such as changing a parameter, or deleting a function), do something that you write at least a few lines of code (I think that an enhancement is better to pick than a bug, bugs often are tricky) that you can show that you have basic code skills, but you don't need to pick the issue tagged with "hard" just to impress your mentor. If the issue that you pick is too hard for you, first ask questions: ask your mentor if this contribution is really suitable to Outreachy interns and if it is the level that s/he expects from his/her interns, if so, keep calm and tell him about your difficulties: what has been hard to you? Understanding the code already there? Understanding what for is that platform? Installing the software? S/he can help you on that, your mentor was a beginner such as you one day. Alternatively, you can ask for a easier bug as a introduction to the hardest one.

3) You've traveled to Germany, England and US with Outreachy. Am I going to travel that much as well?
I don't know, each case is a case. I know that all Outreachy interns that works to Mozilla are invited to "Mozilla All Hands" ("mine" edition was in London, and for this round, it is going to be in Hawaii!!), so at least one travel you are supposed to do. But I don't know if you are going to receive invitations to extra meetings, I think it depends on your team and your work.

 if you have extra questions, mail me:

Wednesday, August 10, 2016

Pytest-HTML release 1.10.0: Dealing with CSP

The main topic of the version 1.10.0 of Pytest-HTML was dealing with Content Security Policy (CSP), since the HTML reports started to look terrible on sites (such as Jenkins) where CSP was active. Before the report was something like that:
As you may see, the table report was almost illegible.

To handle with that, I had to solve many issues. I'll tell from the start.

Handling with CSS

The first thing that was breaking the CSP was that Pytest-HTML only had inline CSS, because when the plugin was built, we thought that could be a good idea to have all in a single document, so it could be exported more easily. The problem is that CSP doesn't allow inline CSS, so we had to create a new file to CSS and export it from the plugin, but for people who desire to have all contained in a single file, there is a new option to use with pytest-html: --self-contained-html, when that is active, pytest-html doesn't create any other file other than the HTML file.

Handling with images, text and JSON

The images had a similar problem of CSS, to be in a single file, they were compressed to base64 strings. The problem with that is that a CSP page doesn't accept to render a base64 string as an image. So the solution was similar to the one applied to CSS, there is a  code which creates images on an external file, and there is an option to still creates the images alongside the HTML when it is necessary to easily share that file. There was not problems related with CSP, JSON and text, but there were an open issue suggesting that we should create then in separated files as well, so we did that.

Initial sort order of the Results

Prior, the sort was all made by JS, so when JS was disabled (CSP disallow JS), we lost the ability of sorting the table (there is a default order that results should appear by type,  which is Error, Failed, Rerun, Skipped, Passed), this was also a very cost operation to use with JS when there was a big amount of tests, many times the browser used to stop working when this script was loaded. So the idea was to order that using the python plugin. Since ordering is a very cost operation, the better idea is doing an ordered insertion (every time a row was inserted in the table, it should be inserted on its right position), and for doing that, I created an object that represents the TestResult, and before inserting each test result on the table, I compared it to the others by its outcome. Now, even more, the plugin is object oriented, we have an object that represents the report, other one the TestResult and other one the Outcomes of the test set.

Minor issues: Rerun outcome and filter checkboxes

Since last release, we started to have two new things: support to rerun-failure plugin and the ability to filter the results by its outcome. The problem is that the rerun should not always appear, only when the rerun-failures is enabled, and the filter function is totally dependent on Java Script. Thanks to OOP, doing those changes were quick, I just had to add a condition before creating the rerun object, and change one line of code where the code of the checkboxes were being created inside the rerun  class.

Contribution of external public: collapse and show logs

One enhancement that was asked a little time ago was a button to hide logs, and another one to show those logs, so there was an external contributor named Leitzler who did that.

That is it! And see the result of the new reports of the HTML plugin right here:

Sunday, August 7, 2016

Lessons from Outreachy

It is almost unbelievable that the internship is almost finished! There is only two weeks to go! Seems that it started yesterday! Many things have happened since the beginning and on this post I'll comment my impressions about the program in general.

Now I am almost finished with my main project, which was making the reports look good even with Content Security Police on, you can read details about this project was thought on my mentor's blog. Hopefully, this week, we are going to release the version 1.10.0 of Pytest-HTML which will include my main summer project. When it is ready, I'll write a post about it. Now I am working on an issue that I suggested: creating unit tests to Java Script code, maybe I'll let this issue to our work week in Mountain View - California (yes, I am going into one more trip because of Outreachy! If you like traveling, you should definitely join Mozilla on Outreachy haha :P), and work on minor issues for this week.

During the internship I could learn many things, starting from Python: I just had one semester of Python more than one year ago, and never worked on big projects with it (just a small calculator or something like that)! I only had previous experience in Java, I learned many things, from creating constructors to classes with optional parameters to what was Flake8 (and I thank my mentor, Dave, to be so patient with some of my errors and to help me). It was so good to see that I could learn a new programing language and work on a bigger project without much effort. It was very good to be out of my comfort zone, I feel that I can face any technology change and adapt to it.

Another way to get out of my comfort zone in this project, was that it was my first time working only in English with mostly native English speakers, and when I thought about applying to this program, I was a little afraid that I would not be able to communicate well and my first thought was to apply to a project mentored by a Brazilian, but fortunately he had too much applicants and told me to find another project: talking like that, you may think this guy is rude or something like that, but he is lovely (I meet him in London), it was just because I felt good on this project, and I could assert that my English is not that bad: for sure, sometimes I misunderstand something, or I do some spell/grammar error, but I just can ask my mentor to repeat when I don't understand and write again when I do that (and not just because English is not my native language, because it happens also when I try to communicate in Portuguese). It was good to see, that yes, I can work in English.

Some things that I didn't learn and I am glad because of that were some concepts. I was glad that I already listened about all the data structures and algorithms that I faced during the project (okay, there were not so many, just simple ones like Hash, dictionaries and lists), and OOP concepts were not new at all! I am glad that I could transform the plugin on a more Object-Oriented plugin, because when I got into it, it was almost only functions, and now it has some Objects such as "Outcome" (which represents the outcome of the tests) and TestResult. I think because of that, it was easier to make some changes, such as giving support to Rerun (it was just create a new Outcome object) and just showing Rerun when actually the plugin is installed (it was just a if statement before creating this new object).

Thought, to be a better Mozilla worker, I still have to learn and adapt to many things! It was my first time working remotely with people from many different time zones! I still get confused when there is a team meeting: "Is it going to happen 9 A.M.? No! 9 A.M. California time, I think it is about 6 P.M.? No it is my mentor's time, here it is around 12 AM or PM?" :P. I still have to get more used to use IRC, for some reason, I feel totally weird when I write on one channel: I think, "am I right to post this here?", "Does anyone will be annoyed with that?". I think also, that I should have a dedicated work place and better internet connection, because I mostly work from my room, and I don't like it very much, and having to work from home I realized that my home's connection was not that good (because before I almost always stayed full time at university and used internet there).

Those are the lessons that I learned from Outreachy until now, I hope you liked my report.

Monday, July 18, 2016

Suport to rerun failures and release 1.9.0

Before traveling to London, I started to work on giving support to Rerun failures to Pytest-HTML. I didn't had time to finish before the Sprint in Freiburg. In this post, I'll explain what is that about.

Pytest-rerun-failures is a plugin to rerun every result of a test that fails, and you can decide how many times it is rerun. This is used to see if a test is failed in a consistent way. Before this enhancement, when Pytest-html was used together with rerun failures, it didn't show anything.

This issue was solved on adding a new outcome to the Outcome list, a little of refactoring was also done,n appending the rows. If you want to see all the changes, you may visit the pull request page.

After that, the version 1.9.0 of pytest-html was released. =) 

Thursday, July 14, 2016

Pytest Sprint

The fourth week of my internship was in a lovely German city named "Freiburg", I was there to take part of an event named "Pytest Sprint", and it was the first time that I went to an event of this kind!

Before going to a Sprint I didn't know what a sprint was... So if you are wondering what is that, I can explain to you: open source projects has many developers involved from all over the world, and there is no way to put together everyone other than a sprint, so a sprint in open source context is an event where the developers of a project get together.
Group photo
Participants of Pytest Sprint, people from al over the world: From Brazil and US, to China and Australia. Most of the participants were from Europe, though.

 In a sprint, the developers generally work in pairs (they are there to collaborate =P) on many different topics: from documentation to bugs solving. The sprints can be "individual events" (like, just a sprint) or a part of a bigger event (like, a pytest sprint part of a Python event). Also, during the Sprints, there are also talks with the new features of the project. I gave a small talk about Pytest-HTML.

During the pytest sprint many things happened: I did a little of everything, I helped to solve bugs, I helped a little the documentation, I did a little of my Mozilla project (Pytest-HTML) and started to think about creating a new plugin to Pytest (Pytest-Env). If you want to know details about what happened technically in the sprint, you should visit the Pytest blog.

By the way, the most amazing thing of the sprint, was the people that I meet: we had so much fun going together to Biergarten (best thing of Germany in my opinion :P), parks and so on. It was good not just to work but to create a sense of community. The Pytest Sprint week was not the most productive of my life, but it was a good week to keep motivated to keeping contributing to Pytest, and maybe get involved in other open source projects.
Amusing moments at Biergarten

Friday, June 24, 2016

Third week: London!

My third week of internship was a pretty special one: I went to London to the Mozilla meeting named "All Hands". This meeting happens twice a year (one in the summer and other one in the winter) and puts together all the Mozillians, from the CEO to the interns and some top contributors (volunteers to Mozilla Open Source projects), everyone (even the invited contributors) has no cost to go to this meeting, they pay everything: from the food to the visa (if needed), including flights, hotel, etc.

Me in the Police Box, in Mozilla All Hands. In the opening session of All Hands, the speakers got out of Tardis

The meeting was huge, there was more than 1,300 Mozillians and so many sessions, lectures, meetings, Hackathons, etc in two hotels in the center of London: Mozilla All Hands is definitely overwhelming for a first time attendee: there is so much to see in so little time. Even more if it happens in a city like London! You can imagine how much a new comer as me, in a such city that I have never have been before, felt!

The event was amazing, but the city even more: I could go to three nice points of the city: The Parliament, The Tower Bridge and The British Museum, it was amazing.

Me and a friend in Parliament.

Me in British Museum.

I saw many good things about London: it was very clean, it has a very good public transport system, it seems to be very safe, I haven't saw many house less people etc. But other things were quite weird to me, such as: I could barely listen to English in London, people on the streets were talking in Portuguese, Italian, Hungarian, German, etc. but so few talking in English! I could understand why the European immigration is such an issue to English people: I could not feel anything Britain in London, because there were so many foreigners there, it is like there is not a culture from London: just a crazy mix of cultures.

Sunday, June 12, 2016

First two weeks: Filter tests by outcome

On my first two weeks as an Outreachy intern, I worked on the issue 38 of Pytest-HTML. That issue is to allow users filter tests results by its outcome. My strategy to do that is putting check-boxes on each outcome, so when the checkbox is checked, we can see the result of that outcome, but when it is unchecked, we can't see that.
Now is how it looks

A few changes has been made on Pytest-HTML code to do that. Maybe the biggest one is that before, the log row and the result row were totally separated rows, so we had to do the checking twice to hide the result and the log row. So now, both rows, are under a element, and like that, we can associate the result and its log.

On the plugin structure, a few changes were made, now there is a class named "Outcome" in the main plugin, so now the summary can be created in a much more elegant way. Maybe it can be created classes to build the table also (And it may helps on the next issue that I will work on).

Also, a few enhancements to the testing methods were created, now the assert summary (now named "assert results") is asserting more things than before, and in a more elegant and legible way.

Today I am going to travel to London, to meet my mentor and other Outreachy people! But I already started to take a look on my next issue: support to another Pytest plugin, the Automatic reruns.

Thursday, May 26, 2016

A little more about Pytest-HTML

As I said before, my project for this summer is about creating enhancements to a plugin named Pytest-HTML, but I didn't say here what is that, in this post, I'll explain a bit.

If you don't know even what is Pytest, I'll try to explain in a few words (if you know, you may skip the following two paragraphs): Pytest is a tool to guarantee that the code you have done in Python is doing what it is supposed to do. Just giving a very simple example, if you have a function named "sum(x1, x2)", what would expect that this function does? Most probably, sum x1 and x2, right? Imagine the situation where x1 and x2 are 2, your expectation is that the function returns 4 to you, right? If it returns any other value (e.g, 9, 8, 2) most probably your function is not doing what it is supposed to do. So to code what I just mentioned above, you would do something like:

 def sum(x1, x2):  
   return x1 + x2 
 def test_sum():  
   assert sum(2, 2) == 4  

So, the function sum is returning x1 + x2, and the test_sum() is asserting that its return is 4. If you copy and paste this code into a file named "" and after installing python and pytest (To install it, run "sudo apt-get install python", and "sudo pip install pytest", in Linux and Mac), you can run on your terminal something like "py.test", it will return the name of your file followed by a single dot indicating that your test has passed, something like " ." . So, it is a very, very quick introduction to Pytest, there is much more you may read about in Python and Pytest websites linked above.

Okay, now you already know what is Pytest, but what is Pytest-HTML? As I said, to indicate that a tests has passed or not, Pytest returns to you a single spot on your terminal. But what if you want the results of your test on a browser? Well, that is what this plugin of Python does: it creates a HTML page (HTML is the language that your browser understands), so instead of seeing just a dot, you see something like the image bellow:

To have your tests in a HTML page like the one above, first you must install (after having python and pytest installed) pytest-html by typing on your terminal "sudo  pip install pytest-html" and after that, run "py.test --html=name_of_html_file.html", and then open the file generated on your browser (by default, the file is generated on the same directory of your test).

If you want to contribute with the development of python, pytest or pytest HTML, you may visit the following gitHub repositories:

Sunday, May 22, 2016

Fun starts tomorrow!

So, it has been a few weeks since I got the big news that I was selected to Outreachy, and tomorrow my internship is finally going to start.

Since my selection,  I started to feel a bit overwhelmed (not in a bad way, actually in a great way), many things happening. First there was all the happiness of being selected to such a nice program. After that, there was an invitation of Mozilla to go to London to participate in All Hands meeting, and then a suggestion of my mentor to go to Freiburg (Germany) to take part in Pytest Sprint. So I started to plan my travel, book tickets, fill forms, etc. Now I got the news that I am going to receive a MacBook offered by Mozilla too (it all - travel to Europe, meeting so many new amazing people, 5.5 K, MacBook, etc. - still seems too good to be true).  Combined with that, there are the last weeks of my semester at school, so many school assignments as well. So, wow, many things happening.

That is how Outreachy made me feel those initial days

Well, since my application, I unfortunately didn't have much time to work on my project. The last patch I submitted was the one I used on my application. But tomorrow, the fun is supposed to begin (if I don't have 3 tests this week), I already have my first task that I agreed with my mentor: this one. This first week, I'll try to create a design to be implemented the next week.

My project for this summer is about creating enhancements to a HTML plugin to PyTest (this plugin shows tests results in a HTML page), the first enhancement that I linked above is about allowing an user to filter the results of the tests by its outcome. So I expect in two weeks come back here talking a little about the design and the implementation for this issue.

Monday, May 2, 2016

What is Outreachy and how to apply for it

Outreachy is an internship program for underrepresented people in Free and Open Source Software (FOSS) community, if you have ever heard about Google Summer of Code (GSoC), Outreachy is much like this program. If you have never heard about GSoC neither Outreachy, I'll explain what is that about in a few words: the accepted students get paid (USD 5500) for contributing to a FOSS project for 3 months. The program runs twice a year, from May to August and from December to March. To apply to Outreachy, you have to write a patch to a participating FOSS organization and after that fill the application form.

So I am one of the students accepted for the round of May to August, and I'll write here some application tips based on my personal experience to future applicants (just saying, it is my own experience, not an official guide or something, maybe your experience will be different from mine).
  1. Don't feel afraid if you have heard about the program close to the deadline and don't have much experience: When I heard about the program (by a blog post while surfing the web, maybe as you now), there was less than two weeks to go before the deadline, and the applications were running for almost a month when I knew about it. I thought that it would be impossible for me (at least this time), I didn't have any previous contact with those organizations, I thought that only two weeks wouldn't be enough to get to know them and write an application... But I tried, and it worked :) So first of all, is: don't let the challenge of contributing to a FOSS organization that you don't know in a short period of time limit you!  :)
  2. Explore the projects a little, but focus on one: When I decided that I would apply to Outreachy, I started to explore the participant organizations. At some point, I decided that I would apply to Mozilla, but inside Mozilla, there were a lot of different projects that I could apply, and I felt a little lost. But I did a short list with three projects that I was most interested in and contacted the mentors of those projects to know how I could contribute with them (to participate in Outreachy, you have to submit a small patch). The mentors were very receptive and they send some patches that I could work on, but when I was studying about the projects and the issues, one project was the most interesting for me: one related to Pytest and HTML. So I actually started to write my contribution. Maybe if you have more than two weeks to write your application, you can write two applications, but in my case I only had time for one.
  3. Do a good contribution: While I was applying, I was also encouraging some friends to apply as well, I was talking to a friend about the needed patch and she said: "I'll solve the easiest issue there" (she didn't get selected :P). I didn't solve the easiest issue there, but the one that seemed to be more interesting to me. And because it was not that easy to solve (I had to write some lines of code) I got many corrections from my mentor and I think we started to have some kind of closer relation (like, I had to talk to him almost everyday this week to get some help with the issue). Because I am a very anxious person, I've taken a look on the contributions of the other applicants to the project I was applying, and I saw that nobody has done a contribution that they actually had to write some code, it was basically change some parameters or delete some lines of code (And I got selected, they no).
  4. Write a good application and communicate:  In the application form there are some questions about our backgrounds, I was not very sure if writing a good application would help me a lot (because I thought that the background + the patch would be more important) but after hearing from my mentor I think it was as important as the patch and the background; in an email after the selection he said "[...] and I particularly liked seeing your enthusiasm and how well you've communicated throughout your application.". So my fourth tip to get selected to Outreachy is communicate well why you are so excited to be part of this program (I was very excited to be part of it, and now I am very excited to the internship start, and I could communicate that on my application).
That is all! Good Luck with Outreachy! :D