... 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 http://24pullrequests.com/ - 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 Coveralls.io
Coveralls.io 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.
AND THE TESTS WERE ACCEPTED - Great success.
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
AND THE TESTS WERE MERGED - I EVEN GOT HEART EMOJIS - THE JOY
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.
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.
What did you learn through Dinner Dash? Do you have any interesting areas of focus as you go into your next project?
The most interesting thing that I got to work on for the Dinner Dash project was the merit badge system. One thing that I've learned from the last few projects has been that adding something unusual or 'shiney' to your app adds way more value than it often, code-wise, deserves.
On the next round, once I know and have faith that the app meets the minimum requirements and that the team is happy, I will definitely either branch off myself or encourage another teammate to branch off into a pet project.
The most important thing with adding the badges to Dinner Dash was pre-research. I sat down, looked at 3 different badge system repositories, watched a rails cast and dug into the code. Once I was confident that I could get the system to work, I split off onto my own branch - wrote tests - made a few badge images and got the 'minimum viable product' to work.
What did you think about the code retreat? How did it feel to work on a problem which, given your time constraint, was unsolvable? What lessons/ideas did you take away?
I really enjoyed the code retreat - even though I was fighting a pretty intense headache caused by intense water displacement the night before (hangover... I had a gnarly hangover)
I don't mind working on unsolvable problems - I actually found the Battleship game to be a pretty good base framework for experimenting with code. The next day I sat down and tried to recreate crunching out the game. I'm also reading the POODR book, and the game has been a great playground for testing out the concepts:
Additionally, I have a pie in the sky dream of using the ruby code to arduino-up an LED game board for battleship.
I've had a really hard time focusing this week, actually. On Sunday night, I not only caught a little stomach ichyness, but also had both my iphone cable and computer charger get destroyed. This is something that the survivalist in me does not like to admit, but if my iphone, ipad and computer are all powerless, I literally have no method by which to set an alarm. I guess if the zombies riding a tornado full of nuclear rockets apocalypse actually does come then it probably won't matter if I wake up at 7:30am of 11, but on Monday, it did result in my missing class.
Also - having been a little under the weather, I took a 'med vacation'.
I try to speak openly about having Attention Deficit Disorder, if nothing else so that it might get the gears running for other people who have undiagnosed ADD. Had I known that ADD was a thing you could have while still being able to sit still when I was younger it would have saved me a whole host of other mental pains. Not being able to trust yourself to accomplish basic tasks leads to a surprising number of strange mental reactions.
Periodically I'll take 'med breaks' to kind of reset my brain and to sort of surface and take stock of things. Usually I take at least one weekend day off, if not both. Now that I'm in gSchool, these vacations happen way less often. I'm working all the time.
Although this week has been a little less productive for me, I'm excited to keep learning.
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.
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.
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.
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.
This week started with getting a surprise project: Clone Wars on Monday afternoon with the requirement to have it finished by Thursday morning and presentable by Thursday afternoon.
The project was working with a team of two other students to take a local business's website, pull out the contents with Nokogiri and Mechanize and then recreate it with Sinatra and a SQLite3 database.
Our group had a few constraints - the largest of which was time. Since we didn't know about the project before Monday, many of us had scheduled other appointments (doctor, mentor, etc) and I, personally, had my mother flying in to Denver. So we really only had two days to complete the project and couldn't work as a group after 5:30.
What I Learned:
Sinatra: I feel like my focus with the project didn't extend to learning much about Sinatra that I didn't already know.
SQL: I learned a lot about translating between SQLite3 and PostGreSQL as a function of pushing our project to Heroku. I worked with one of our teachers, Jorge (https://twitter.com/novohispano) to get the project Heroku ready. We did a LOT of fail, read the logs, google-fu, minor change and then check. A lot of issues came from SQLite3 commands not translating into something that PostGreSQL could use. One critically cool thing we did was creating a rake task for the migration of the information into the database.
HTML/CSS: I learned a LOT about inspecting elements and formatting from this project. We pulled straight html from the website - which was in XHTML… so a lot of what we had to do was clean up the formatting. I also learned to pull color hex codes from Gimp.
What Was the Most Confusing Part that We Hacked Together?:
Am I allowed to say 'All of It'?
How are you Feeling about Writing/Using Feature or Acceptance tests?
Well. At one point I wrote some great tests. But then, with the time constraint of having something that wasn't completely embarrassing deliverable by Thursday, I started rushing ahead without tests.
Boo this developer.
I really enjoyed a presentation by another group of students explaining how they created acceptance tests first thing to make it clear what they wanted to accomplish at the end. I very, very much want to do acceptance testing first on my next project.
If you had another week for Clone Wars, what would you build?
I don't even know if I would build so much as clean up. I like what we created, which was a scraper that could recreate a website - but every part of it needed more love and attention. I would have wanted to clean up with the scraper so that it could be used without a lot of human correction. I would want to add validations and protections on to information going into the database. I would want to build up the testing suit so that it could help in pulling other websites… I would want to delete outdated code that we left in the project… etc etc etc
What was different about working in a three-person group?
This actually wasn't the first project that I worked in a group of three for… but it was the first project without clear step by step directions. Defining objectives as a groups is hard. When I work on my own, or with other people, it's easy to correct errors in judgement. But with three people, it's hard to recognize when you've gone down the wrong path and then correct it.
With a larger group, taking the time to write acceptance tests might really help at the beginning of the project. I'd also like to look into using pivotal tracker or creating github issues to define reasonable expectations… but an acceptance test is a little bit more grounded. In writing the code to create the test, you get an idea of how large your expectations are.
That said, I was super impressed by my group. We kept our spirits up really high and it ended up being very fun to work with my teammates :)