Month: October 2016

I think the biggest event that’s happened in the last two weeks is that I gave a Beginners Track talk at the Boulder Ruby Group’s Presentation Night (I don’t think I’ve typed that out until now, it’s a mouthful). I’ve been wanting to give a presentation for a while now, but didn’t think I had anything to contribute, being that I’m kind of a noob. I had recently gotten positive feedback on my standardized git commit message formatting, and it occurred to me that not only would an audience of developers appreciate it, the ‘beginners’ might like to know how to set it up.

Now, I’m not going to claim that one day the clouds parted and I had this vision of the perfect commit message, of course I had help, as is the nature of web development, and most of life. One of my now many mentors, Corey Davis, introduced me to this concept a while back when we were working on a group project. He send me a .txt file and then I dug around the interwebs to figure out how to configure it with git. At this point in my coding path I even more green than I currently am, so it took some trial and error to get the message to properly configure. As I found out again recently, testing changes to git configuration can be a beast. Unless I’m missing something obvious, the only way I’ve found is to have a burner file, make a change to it, work through the git add and commit process, and confirm that everything is how it should be. The caveat, especially when dealing with the commit message, is that if something’s not configured properly it can hang the whole process in limbo, which requires an entirely new trial and error process to figure out how to fix that. This is all that to say that I felt like it would benefit some people to give a quick tutorial on how to efficiently setup a standardized git commit message.

I’ve heard from other people how beneficial giving a presentation is for both the audience (obviously) as well as the presenter. I have to say that this couldn’t be more true. I started putting a GitHub Gist together the night before the presentation and quickly realized that although I knew the general workflow of how to create and configure the commit message file, there were a lot of little details that I didn’t know and should probably read up on before I gave the presentation. Because of this I now have a deeper understanding of git and why the .txt file that Corey sent to me was configured as it was.

Before I started the presentation I informed everyone that this was simply my workflow, not the gospel, and that I welcomed any and all feedback. I’m always trying to improve my workflow, which is another reason I wanted to present. What better opportunity to see if you’re doing something right than to show a room full of other developers? I did get some great feedback, in fact there was quite a bit of back and forth during the entire presentation, which to me makes for a better presentation than me just jabbering the entire time. One nugget I received was about another technique on how to stage files for commit.

My previous workflow, mostly because I was mainly only working on one feature or bug issue at a time, was to use git commit -a. Thiswas staging everything for commit. I’ve quickly come to learn, from both my internship and this presentation, that this is the lazy way to stage. I’ve also learned that I should be more thoughtful about what gets staged and what doesn’t. For this I’ve been staging each file manually, then performing a git diff --cached, which essentially shows you all the changes made to each staged file. Then, if there was a file staged that shouldn’t be for that particular commit I would have to go back and manually unstage it. That is, until now! During the presentation I was informed of the command git commit -p, which I’m pretty sure is the patch option. Basically, when this command is run it shows the changes of every file that has been altered since the last commit, and gives the option to stage, not stage, quite the staging process, and about 10 other commands. (here’s a stackoverflow link showing all the commands). This is now my workflow. It handles the code review and staging in one go, which is exactly what I want.

All in all the presentation went very well. I did a little live coding with VIM (with sweaty, shaky hands), had a great dialogue about how/when/why to commit certain things at certain times, and checked a few items off of my programmer-in-training to-do list. I adamantly recommend to every student I meet to attend meetups in their area, and I can now recommend from experience that everyone give a talk as soon as they feel comfortable doing so. This is the link to the Gist, if you have any interest in standardizing your own commit messages. At the bottom of the Gist are some more git references if you want to dive even deeper.

Well, apparently Im doing something right, because I’m currently two weeks into an internship! It’s with an independent contractor, working on two client-side Rails apps. I’m working with him 4-5 hours a week, so it’s not too taxing on the already tight school/work/life schedule. It’s a completely different beast to work with an existing code base, especially when the other person built it, and knows it forwards and back. As I’m sure is common with a good portion of web development jobs, a lot of what I’m doing is dependent on my abilities to even find the necessary file that needs to be refactored. I think its actually a legitimate ‘test’ for someone in my position, something that evaluates my problem solving skills right out of the gate. When looking at a locally-run web app, how can I identify the problem and find the necessary file in a codebase with 1000+ files. Oh, and did I mention that the entire app itself is being refactored, admittedly by mentor in a very ad-hoc way, so one quarter of the existing files are non-functioning. Im getting skilled at mining for files.

Once I’ve actually found the file, with him literally over my shoulder, knowing exactly where it is in the first place, now I have to identify the code to be refactored. This has two factors that make it interesting, the first is that I have no idea how this file was written. It. Is. Full. Of. Partials. As it should be, I suppose. The idea of DRY programming is that if theres a way to not repeat yourself you utilize it. Digging into a file and its partials just ‘spices up’ the whole process on my end, which, ultimately, I appreciate. The second factor is that the entire app has been refactored from .erb to .haml. Ultimately, it’s not that much different, it’s doing essentially the same thing, but its just something that I’ve never worked with before now, and it’s a bit daunting to take it all in, especially with the other elements that are being introduced to my workflow.

AND! Those new elements are vim and tmux! I’ve known of vim for a while, but the idea of moving that direction was a bit spooky to me. Then, in the course of one week, I was told by two different people that I should give vim a try. I started digging into it and quickly found that vim has a built in tutorial (next time you’re in the terminal type ‘vimtutor’), so thats pretty awesome. The tutorial took me about 45 minutes to work through, and once I was finished I was pretty confident that I could start editing files with vim without causing too much damage. It’s still not part of my everyday workflow, I’m just quicker with a text editor, like Atom. What I did was set vim as my default editor for my commit messages and terminal aliases. This way I have to use it a little bit every day (I’ve been making a lot of terminal aliases lately) and after a while I’m sure I’ll start using it on everyday file editing.

Tmux is also a super handy tool that seems to be widely used. In a nutshell, tmux subdivides your one terminal window into as many different independent terminal windows as you need. Before tmux I was doing a similar thing, only with tabs. I had my first tab as the standard terminal (file navigation, git commands, etc), the second as the server, and the third as the console. The same setup on every project. Now I can have all that in one window. My workflow was pretty good before the introduction of vim and tmux, but now its getting even better (faster). What I’m learning is that its all about your fingers never leaving the keyboard, and when you get really serious about it, your fingers never leaving the home row of keys.

All of this and I haven’t even touched on school yet. School is school, only now its frontend instead of backend. The first round of HTML/CSS curriculum went super smoothly, and now I’m working through Javascript. It seems to be coming to me pretty ‘easily’. I’m sure that I will get tripped up by something, but I feel like having spent so much time troubleshooting languages and frameworks as complex as Ruby and then Rails, the concepts of Javascript aren’t all that much different. And I’ve become pretty good at searching the interwebs for answers to questions. I’ve probably been spending more time on the internship and networking than I have on school. But I’m ahead of the school’s pace at the moment, so I’m more than ok with my current time distribution.

Speaking of networking, I attended Rocky Mountain Ruby last week and it was a pretty great experience. That was definitely the first time I was in a room with so many other Rubyists ( I think thats a term…). I’m also pretty certain that I was one of probably less than a dozen non-working professionals in attendance. I’m sometimes surprised at how few students I come across at events like that, or even meetups. This industry seems to be all about the people you know, and theres no better way to meet people than to go to events where everyone has something like web development in common. Almost my entire web dev network has come from events and meetups, and I’m talking to those people about one thing or another almost daily. I’m sure this is something that is obtained with less effort when attending a brick and mortar code school, but when attending an online program like Bloc I have to go above and beyond to make it happen.

I feel like I’m on a good trajectory with everything so far. Finished the first half of school with time to spare, landed a solid internship, have an ever-growing network of fellow developers, and starting the second half of school with a bang. I’m looking forward to the next few months.