I was searching for topics to blog about and realized that I could get a lot of material out of the projects I have been working on since leaving the Iron Yard, and might even provide some insights for prospective readers, so here goes.
I am juggling a lot of different projects, including trying to learn Node.js and basic Python, as well as trying to improve my fundamental coding through exercises. I have some internal debates about whether I should be doing this or focusing exclusively on improving my Ruby and my Rails. The question is one of breadth vs. depth: are you more valuable as a programmer if you know how to do a bunch of things sort of well or if you know how to do one or two things really well? I’m trying to hit a compromise.
The crux of that compromise is that I am working on that other stuff at least a bit every day, but focusing on adding features and tooling to my Demo Day app, Cream of the Crop. This is a calculated choice as well. Shouldn’t I focus on building new and different apps instead of simply adding features to my old app? For one thing, I feel like I have enough experience creating new basic apps for the nonce. It’s true that making different kinds of apps provides you with experience with different code, but I feel like adding more complicated features to Cream of the Crop accomplishes more or less the same thing.
That said I finished my first major addition to the app today (converting many of my views to Ruby-Slim, on which more later) so I am an a perfect place to talk about the stuff I learned working on it.
While it isn’t Rails specific, the first thing I learned working on this project was advanced Git, specifically branching. I remember working on group projects at The Iron Yard and simply pushing to Master and hoping that nobody would generate a serious merge conflict. And obviously you can get away with it, because we did. That said I can see where that would be a major problem in a situation with multiple people all making commits. Where it became an actual problem for me was when I tried to convert to Slim the week of Demo Day and needed to make a change to my webpage to test something before I was done. Ultimately I git checkout’d and lost a lot of work. Hence when I went back to the Slim problem after Demo Day the first thing I wanted to do was learn branching.
A resource that I found very helpful was this page. The crux of it is this:
git checkout -b branchname
creates a new branch and switches to it
git checkout branchname
switches back and forth between branches, with their own commit systems
git checkout master
git merge branchname
git commit -m “message”
when you are done with your branch and want merge it into master (you might have to deal with merge conflicts).
Finally, when you are done with the branch entirely
git branch -d branchname
will delete the branch.
All of this works fine as is in your local git setup. When you start pushing to Github though, there are a couple of wrinkles. Your Github repo is set up to only acknowledge your Master branch. You can commit as normal, but to actually put stuff up on Github you have to
git push origin branchname
and you have to do it every time you want your branch commits to show up on Github. I found this page helpful in explaining how that works.
One final wrinkle is that none of those commits to a branch show up on your official commit stats on Github until you merge back into Master. So, for example, this afternoon when I merged my Slim branch, which had 17 commits, it jumped my total commits on the app from 88 to 105, retroactively inserting them into the proper timeslots. Weird, but not really a problem unless you are obsessed with maintaining Github streaks (which I totally am).
Oh and one final thing. I haven’t figured out how to delete the Github branch from the command line. Obviously you can’t git push origin branchname from a branch that you’ve already deleted locally (wait, can you? will have to try that next time), so you have to go in and delete it through Github’s website.