Contributing to Open Source

... as a noob

One of the nicest thing about Jumpstart Lab's gSchool program has been the mentors. 

These awesome developers have volunteered to take time out of their day to work with us on our silly projects, while we are swearing and making frustrated faces. They are saints of the highest order.

So it's no surprise that, in gratitude, a lot of us want to give back to the developer community. We want to contribute to open source... badly... 

We're eager to add features to code, but it's hard to find out what features the owner(s) of a repository actually would want. And if the repo does have a wishlist, most of those things are beyond our ability to create on our own.

So how (other than hunting spelling errors) can we help? 

One way I've found to contribute is with tests.

So here's my testing journey, over christmas break

I had heard about - a site which encouraged developers to make 24 pull requests before christmas. While looking around repositories, I found a lot of pull requests and todos that I wasn't sure how to tackle, but I also found some repositories that used allows you to dig in and see where sections of the code are uncovered by any tests. 

I found a neat little rails project called MedLink.  I was able to find a model that was untested and add coverage to it.


I was now on a test fairy mission. My ego had expanded. Time to reach for larger fruits.

The second project Jekyll - they also had coveralls - but they were using Test Unit instead of RSPEC. 

The Jekyll code that I targeted was commented. Even though I didn't fully understand some parts, I was able to write test scenarios that fit the comments. I did a lot of test failing and searching the entire code base for method calls to make sure I was writing tests that wouldn't be arbitrary. 

This one took a lot longer - but I was pleased to submit the pull request - until OH THE TRAVIS CI BUILD FAILED

The shame! The terror! What had happened? I quickly closed the pull request and by pulled up the build

Turns out, even though it worked locally, the assert_includes method was not working out for Test Unit. I had to reformat the tests a bit to remove it, but once I did, I reopened the pull request and the build passed


The Jekyll code is pretty well covered, so I decided to tackle a harder piece of the code that I didn't understand one bit. The test was supposed to test out a successful process, or an error message rescue. After spending about two hours, I could test the happy path... but I COULD NOT compose a test situation that would bring up the rescue block. 

Which was a sign that I really didn't understand it well enough to test it. So I backed off. I'll be back though, when I'm older.

Third Project: I decided to try looking in the github account repos of rubyists that I admire or know.

I found Avdi Grimm's Pair Program With Me one page website. The site is pretty simple, and didn't have a testing suite but it looked like Avdi was looking to grow the site. I decided to try and implement a new testing suite and write some capybara tests. For a multitude of reasons, it seemed unlikely that Avdi would actually merge my work (maybe he's not an rspec guy, maybe I don't know how rubby is formed, you know, etc). It did seem like a decent little challenge though at least.

But guess what. There is one little button on the page, where you put in your email and it pops up the text for a mailto button link with said email. 

I fear JavaScript. It is alarming. I do not know how to test JavaScript elements in a page.

So to the google. I ended up using selenium, and during the googles, found an article actually written by Avdi about how critical it is to use Database Cleaner with Selenium. 

I got the test to work. I submitted the pull request. THE JOY

And then the pain. One of the collaborators of the repo asked two questions, one, why poltergeist over selenium (answer: I don't know how to use that one either, and google brought me selenium first) and two, why database cleaner... because the tests don't touch the database... because there really isn't any database touching.


Oops. My noob is showing.

I did try to use poltergeist instead of selenium, but still haven't been able to figure out why it doesn't activate the mailto text correctly. The pull request has not yet been accepted, and I sort of doubt it will be. 

Still - I learned how to use selenium at least. And a little humility at the end of my testing rampage.

So What Are My Next Steps?

I would definitely like to go back to Jekyll and try to add more testing. It's a neat balance to maintain adding coverage while not adding tests that are silly and therefor likely to break down the line. I'm also trying to make my pull requests small so that it's easy for a repo owner to say 'no' to any test that they consider poorly written or that doesn't actually fit with their future goals for the app. I think it's probably easy to make those mistakes as a newbie to both ruby, and the specific code base.

I had looked at contributing to GitLabHQ - and their contributing How To(manifesto) is pretty intense.

While I don't think that most repos are that selective in accepting pull requests, I would like to improve my pull requests by following their format and rules.

Personal Retrospective :: First Group Rails Project

This week, our class has been working on our first large scale group Rails project. The premise is that we create a web based ordering system for a restaurant.  

So far our group has been meeting a large number of our goals. We forced ourselves to work in small iterations. We are documenting our 'dream' fun adders in pivtotal tracker but focusing on getting the basics done and not over-reaching.  

Out wireframe layout

Out wireframe layout

The first day, Monday, our group went to the coffee shop and drew out wireframes for the layout, wrote user stories in pivotal and then designed the database. This has been hugely helpful throughout the whole process.  I wasn't sure if taking an entire 'work day' to do layout without any actual coding would be profitable, but I think it made the entire project accessible for all the team members.


On the second day, we mobbed the initial database creation and rails model and controller creation. 

Screen Shot 2013-11-08 at 10.36.57 AM.png

Wednesday we tackled the big terrors. Getting the entire database to be done with postgres and pushing to Heroku.

Thursday we worked together, all day, with two people pairing on user authentication while the third teammate worked on special projects. Rolen and George were able to set up see data and got a shopping cart to populate and display. George Rolen and I finished the users. I focused on getting a basic well formatted layout. 

Our Layout as of Friday AM

Our Layout as of Friday AM

I chose to focus on the layout. I have noticed the trend that having a very basic pretty background makes a world of difference in how a team will feel about how a project is going. I am hypothesizing that 'shitting out' something early and easy to edit will allow us to focus on fine tuning the backend without being overly worried about the front end. 


The biggest challenge for me so far in understanding rails has been transferring the database to postgres. Many, many times I've shouted 'HOW DOES COMPUTER WORK?!'


I had created rails applications before coming to the program. They were uniformly very, very fragile. I am actually very excited to return to the old projects and now, with a ruby background, understand the things that were total mysteries.  Also to mock past me.

It was also very interesting to go back to the Hartl tutorial while we were generating user authentication now that I understand testing. Hartl's focus on testing almost completely derailed my learning from his book - since it  rested on being able to install a few gems correctly. Now I have a hard time figuring out if the tutorial has been improved (I followed a rails 3 tutorial, now it's updated to rails 4) or if I am just much better at understanding. 


This has been a fun project to work on, and it's nice to feel comfortable with our progress. I'm looking forward to working on the project over the weekend, especially since we are planning to meet up at an indoor playground so our teammates daughters can play and we can at least attempt to code, or at least fellowship :) 

I feel like I've been lucky to have classmates who are positive and intelligent, so when groups are announced, I don't have to dread the announcement. So far everyone that I've worked with has a good attitude, which keeps projects from being nightmarish and allows an open exchange of learning.  

Massaging My Schema (and other words that sound medical)

So before I came to Gschool

I was cutting my teeth on creating an application that would generate paleo-friendly meals for me. But I had an ulterior motivation, which is what (instead of grit) kept pushing me forward through the hard bits: I cannot feed myself. Grocery shopping involves planning and spending money... two things that I only ever do manically.

I need this application for my very survival. 

As it turns out though, making an application is real hard. I did get it to function - but not WELL ENOUGH.

See it here: 

The biggest problem is figuring out how to correctly structure the database.

This is not something I even understood to be a possible issue until I accidentally deleted all of the recipes that I had inputted after about a month in.

While I can continue to make it more user friendly, and pretty, and more RESTFUL or whatever that means --- I can't really use the app until the schema is at least the skeleton of what I want it to be.

RIght now, for example, I need a horse skeleton of an app. And what I have is a drawing of a horse skeleton hastily taped to a cardboard box. 

Today in class my partner and I had a problem in a tutorial that I really suspected was an error outside of our control, maybe based in the gem we were working with.

I was wrong. But that's not the point.

The point is that I had to break out of my 'school' mindset that defines 'cheating'. After we had worked on the problem for a half hour, it finally occurred to me to look up what other people had done with the tutorial on github.  

We found quite a few other examples, some from our classmates.. and while it actually took yet another student to look over things with us to solve the error -- looking up the code was able confirm that we were on the right path and also afforded us the opportunity to see different ways to solve the problem. 

We got some smart mother f'rs in our class. 

So on the walk home I decided that I have spent enough hours on my own laboring over the food matrix schema -

It was time to search GitHub for similar apps and browse their schemas

So the journey towards rails and away from pawing at my neighbors windows when they cook dinner is back on track! 


Yes fellow coffee shop patrons, admire my brilliant schema....

Yes fellow coffee shop patrons, admire my brilliant schema....