Everybody Struggles

I had to take several mental detours during my contribution period to go down the rabbit hole a few times, for example on Rails Active Query. I knew what I wanted to do but I needed to figure out how Rails handled these queries in order to get the result I needed. I also had to learn a lot about Capybara testing – and testing in general!

One area that has been full of stumbling blocks (and then growth!) is GIT. I’ve got a pretty good handle on the regular workflow, of push and pull and rebase. The problems happen when I do something wrong and I don’t know how to back out of it. Then I get to search google for possible answers and try them out. Usually it works. Sometimes I make a bigger mess and have to ask my mentors what to try next.

  • Made a commit then wish I hadn’t? I can use either git revert (will create a new commit undoing the changes) or git reset --hard <HASH> (resets back to a specific commit and throws away anything after that).
  • Committed to master instead of my branch? Ooops, I had to learn git cherry-pick.
  • Somehow added extra commits to my branch when cherry-picking? By using git rebase -i HEAD~8 I was able to go down the list and select which commits to keep and what not to.

A Jasmine Test Failure

One of the stumbling blocks I’ve encountered is when my code works properly in the app but the testing all fails. I had this happen on one of our Javascript repositories, which uses Jasmine testing (which is different from the Capybara testing that I had used prior in our Rails repo). The tests had been passing until some recent commits and a rebase conflict merge so I needed to figure out exactly what was causing the tests to fail.

First stage in error debugging: google the error! Copy and paste it, see what pops up. Once in a while you’ll get lucky and the answer will be right there on the front page, someone else already solved it for you. But my error was extremely vague, “undefined is not an object” – and the same error on every test. This wasn’t just a situation of one test failed because of a change, this was all testing is completely broken.

Considering the scale of the error I wanted to double check that testing was working on my local environment at all. However, when I switched branches it gave me some errors on the command line and wouldn’t let jasmine run at all… even though I had just run them in my feature branch. This has been happening to me with some regularity, and it’s very frustrating! Sometimes I get a “grunt not found” message, which makes me confused because I use grunt all the time in that repo so how can it just disappear? I’ve learned to run npm install just in case some dependencies were updated, that has fixed several of my issues in the past. And it did fix it this time!

First thing I tested was running grunt jasmine in the main repo. All the tests pass, so this is a good starting point! I always like to check a known-good branch just to make sure the tests are running correctly. Once I discovered that the issue was not my feature branch at all, it was something else causing all the tests to fail! Better to learn that first rather than after spending hours searching code.

I knew there were very few changes between main and feature-branch so my next step was to compare them to see if some code had been accidentally deleted or changed when I handled the merge conflict. Google brought me to this page on Stack Overflow. I can use git diff branch1..branch2 – but that outputs text and will be hard for me with a large file. That page also mentioned the tool Meld. This looks very useful on its own for comparing one file to another file, but how to use it with GIT? Their help files say that it can be done but didn’t give specific instructions. That page also had an answer for that: git config --global diff.tool meld to set Meld as the default tool for git diff, and then git diff branch1..branch2 to open it. However, one very important note here: this will open every single page in that folder, one by one. For each file there is a Y/N prompt for opening it in meld or not. I have a whole lot of files so I need a way to specify which one I want to look at! Thankfully google told me that I can easily do git diff branch1..branch2 folder/file.js to target which one I want. Excellent! I opened it up and looked through carefully only to discover… the code looks correct, only my functions were added, there’s nothing obviously wrong.

So my next stop is to identify what code is causing the failure. I added 4 functions, so first I commented them out and ran the code – it passes. I add one back in, it fails. I leave the function there but comment out all the lines inside it, it passes. This is where I get stuck for a while because at first it seems like any code inside causes it to fail, and that doesn’t make sense. I had a forced break for a while, which I didn’t want but in the end was possibly a good thing! When stuck it can be actually really helpful to walk away and put your brain on something else for a while. Sometimes you need your brain to shift gears and get out of a stuck path – if you find yourself trying or thinking the same thing repeatedly, with no progress, then you probably need a break. When I came back I looked it over again. I had recently added a different new function that worked and passed the tests. So why did that one work and the new one didn’t? I scrolled through existing functions with an eye for what is different? And I noticed that all the other functions use var. I used let. I tried var in my failing function… and it passed! Problem identified!

The final step was refactoring one of my functions because it didn’t want to run with var. It was easy enough to find a different way to compare two values, so that was a quick fix.

I still don’t understand why jasmine caused all kinds of errors by using let. I was only using temporary variables inside a function to do a simple task, there was no scope or re-declaration conflict. But the tests are now passing and my code was able to be pushed up for merging. And next time I’m writing code in this repo I’ll be very wary of how I declare variables!

Applying for Outreachy

I already wrote about my experience setting up a dual-boot system while I started the application process. I had a very busy month while I worked on contributions and submitted my final proposal. Last Tuesday I got the email that I have been selected as an Intern on the Public Lab project! I should probably make a post about how the rest of the application process went.

My first word of advice is to choose your top project candidates from the list of options ahead of time, then try to get the repositories installed and running on your system. Having to dual-boot my system on the day I wanted to start contributions was stressful! I also recommend really looking at the code base and trying to get familiar with it, it can take some time to understand what’s going on in a large project.

Once the repository was working I started looking for a small contribution to make. Make sure you read any instructions the organization has; Public Lab wants everyone to make a small, very easy first-timers-only issue as an introduction. Unfortunately there are going to be a lot of other people also looking for a beginners issue, so be patient and polite.

I made my first few small pull requests and felt pretty good about it. I’ve officially contributed to open source, hurrah! I wanted to show the mentors of the project that I am capable and skilled at code, friendly and helpful with others, and willing to listen to help and suggestions that they give. Public Lab really values cooperation and working as a team, it’s more than just submitting a contribution and being done. Then look around and decide what larger contributions you could make, both as a learning experience and also to show what you are capable of. I looked for something that was a challenge and a little intimidating, but not so complicated I would be completely stuck. I aimed to complete different types of issues: I had some in Rails, some CSS, and some Javascript. This not only was good to show my abilities, but also to remind myself that I am capable of taking on different challenges and succeeding!

I had prior experience using GIT for my own project, but I had never contributed to open source before. Public Lab has instructions and a posted Git Workflow; I don’t know if all open source projects have that available, but it sure is helpful! I also watched some videos on GIT (there are tons available on YouTube, I’m sure most are good). One that stood out was Advanced Git Tutorial. It really broke it down into the pieces I needed to understand (mostly) what was happening. Our workflow involves Rebase and I think it would be easy to just follow the instructions without understanding what it is really doing – and I don’t like not understanding the big picture. A big part of this internship process is challenging yourself to try new things and build new skills. Take the time to dig into subjects, figure out what’s going on.

Once I got some pull requests in I felt good about my chances but also very nervous about who else was applying. I stayed active all month, spending my time as if I was an intern and I was working on projects. I also spent a lot of time building my proposal, which required me to look at the work they wanted done and then break it down and organize it. I was unsure how that would translate in the real internship since Public Lab is using two interns to work on a group project, but I based my proposal on what I would do if I were working by myself.

The final application was due on Nov 4. It was a relief to be done with the proposal and have it out of my hands, but it was also a tough wait, not knowing if I was going to be working in December or not. On November 26 the emails were sent out and I learned that I had been selected for an internship spot! I began working on December 2; the project ends on March 3. I am working on integrating geolocation and mapping features on PublicLab.org! I am so excited to have this opportunity!

Tools I Am Using

I am using Notion to create a wiki page of notes and links to the project’s workflow, testing documentation, style guide, and planning posts. Initially I set up a To-Do template for listing the issues/pull requests I’m working on, but once we started the Outreachy project I used the Roadmap template. I love that it has space for notes on each issue, and I can add and remove properties to make it what I need. Plus I added my colleague intern so we can work on the project together and stay informed of each others progress.

One of the other tools I am using daily is the FireShot Chrome Extension screenshot tool. It gives you the option of saving an image of just the visible portion of the webpage, saving the entire webpage from top to bottom, or a selection chosen with the mouse. I am really happy with the free version. I know there are a lot of different screenshot tools out there, just find one that works for you because you will need it frequently when working in open source. Public Lab prefers to have a screenshot of any UI changes before merging anything, and of course it’s a very good idea to post a screenshot when you have discovered a bug, or when something you tried is having odd results. It is so much easier for someone to help you when they can see what is happening!

I have used Photoshop many times in the past for design and photography editing, so I figured I was all set. While creating my proposal I did use it for a few graphics, but most of the mockups and graphics I did in Adobe XD, which I am complete new to. I have to rave about it, it makes life so much easier! It automatically snaps to lining elements up and matching margins. It’s so quick to add text and rounded borders, to do all the things that we do for websites. You can do it in Photoshop, but it’s persnickety. The only downside to both apps is that I have to boot into Windows to use them – and my Windows installation is very sluggish at the moment, I think it needs a fresh install. But after my last experience with installing an OS I’m not feeling very eager!