Thursday, February 23, 2017

The biggest dev mistake: don't use your creativity

Outreachy program to me is more than over (actually now the applications are open to the next round after mine), but I decided to keep this blog as my dev blog. So today I figured out the worst thing you can do as a dev: don't use your creativity! That's a horrible mistake.

It happens when you just copy and paste code from internet without even realizing what the code is doing instead of just understanding the code to know how it would fit better to your code.

So I had to do a Spring Boot application for a Uni class, and I was only looking for on internet "How to do a PDF file with Spring Boot" because that was what I need to do, but there aren't many tutorials on that (like, how many would be to find . Ok, there aren't many, but I found a few: one that I find to be pretty good was that one. I blinded followed the tutorial, copying and pasting the code to my application, without only changing the name of the class (e.g. "Book" on the tutorial to "Tarefa" on my code). But the code didn't make sense on my application's contest, and I was breaking on some configurations file. Instead of trying to understand what was going on and trying to fix it, I tried to find a new tutorial that would match exactly with my problem just changing the name of the classes.

The thing is that in our dev's life, we'll never find something that matches exactly: and you will lost a lot of time trying to do so! The right way to use web tutorials are to figure out what they say and then think about your problem: it is not just copy and paste code changing class's names. When I gave up of looking for a sea of tutorials, and gave a think about it, i found a easy solution that was there right under my nose!

So this one was my today's lesson! I hope those thoughts can help any of you. 

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.