Shawna C. Scott

Learning to hack, one day at a time

Menu Close

Tab Completion for Git

My new workflow includes creating a branch with git for every new feature, and adding the Pivotal story ID to the branch name. This gives me branch names that end up looking like this:


I don’t know about you, but it only took manually typing out 79045950 once before I started looking for a better way. Luckily, git has auto completion capabilities!


If you use the Bash shell, Git comes with a nice auto-completion script you can enable. Download it directly from the Git source code at . Copy this file to your home directory, and add this to your .bashrc file:

source ~/git-completion.bash

If you want to set up Git to automatically have Bash shell completion for all users, copy this script to the /opt/local/etc/bash_completion.d directory on Mac systems or to the /etc/bash_completion.d/ directory on Linux systems. This is a directory of scripts that Bash will automatically load to provide shell completions.

Check out Git Basics Tips and Tricks for the full instructions, and make your life easier.


On Tumblr:

Fixed Height Sticky Footer CSS, via CSS Tricks

I don’t know about you, but I absolutely hate footers that float in the middle of the page if the page has very little content. Like this:

Look at all that whitespace. Ick. I suspect I’m not alone in this, since I rarely see footers that don’t stick to the bottom of the window and then expand to accommodate more content. And yet, it’s not very straightforward how to make that happen. Even good ol’ Bootstrap doesn’t have a class for it.

Twice now, I’ve had to spend more time than I would like using the junior dev answer machines to figure it out.

So, now recorded for posterity:*

Sticky Footer by Chris Coyier @chriscoyier on CodePen

One caveat: This technique only works for fixed-height footers

Properly Factored MVC in Rails Applications

EDIT: After feedback from Katrina Owen Herself, I wanted to include the “much improved” version of the tutorial, as well as Katrina’s amazing five-part series on Golden Master testing


Recently, I wanted to learn more about refactoring, and about general best practices for structuring Rails code. Generally, when I’m working on a feature, I don’t spend the majority of my time figuring out how to make something work. I spend most of my time trying to find the best way to make it work.

As a new programmer, though, I have to rely on external resources, since I don’t yet have that internal lexicon of good and bad design patterns to point me in the right direction. So, this past weekend, I decided that I wanted to learn more about Rails best practices, and about refactoring. Imagine my delight when I found this great workshop and accompanying tutorial, “Properly Factored MVC”  [tutorial] (see edit) from RailsConf 2013, presented by Katrina Owen and Jeff Casimir.

I finished the video, although I haven’t worked all the way through all the tutorial iterations yet, and I’ve already learned a lot about the theory of refactoring, and how to insure your refactoring doesn’t cause regressions.

If the 1:43 runtime of the video is daunting, you can just work through things from the tutorial alone. Personally, though, I found the video helpful, since Katrina Owens is talking through her thought process as she goes in more detail.

Hope you find this resource helpful!

PS: If you feel inspired to help refactor some Real Live Code ™ after this, feel free to hop on over to the very beginner-friendly open source project, Calagator. I’m a contributor there, and there’s plenty of places to test and expand your skills!

On Tumblr:

Make your commits better with interactive rebase and -p


Yesterday, I finished up the initial code for my third feature at work (Yes, I can still count them on one hand). It came time to submit my code for review, and I realized I had done this to myself:

[Image description: A screenshot of the shell output of running the command ‘git status.’ It shows dark pink text on a black background, showing 38 modified, deleted, or new uncommitted files.]

This is why you commit early and often, folks. So it’s not 4:30 on a Friday afternoon, you’re the last one in the office, and you’re late picking up your wife because you’ve been trying to make Perfect Commits (TM), which means you didn’t commit anything at all for days at a time until it was done. Hypothetically. Not that that happened.

What I should have done is commit things along the way in logical chunks. But sometimes, when you’re a noob and you’re not entirely sure where you’re going until you get there, it’s hard to know what a ‘logical’ chunk looks like.

If you also want to commit more often, but not have messy, half-done features committed over and over, there are two git tools that can make your life easier.

Strategy 1: Commit broken things however much you want. Use git rebase --interactive to rewrite your history once the path is a little more clear.

Caveat: You should only use this strategy when your code is isolated while you’re working on it, i.e., you’re the only one working on your topic branch. Otherwise, when you rewrite history, you risk completely borking other people’s histories if they’re based on the one you just rewrote out from under them.

Strategy 2: Commit often, but use the --patch or -p flag to interactively choose chunks of code (rather than full files) to add, stash, or checkout. This strategy is great, especially when you can’t rewrite history.

on tumblr:

New Job, and Junior Dev Lessons

I haven’t announced it here until now, but recently I was hired at a startup called:



We make a data logger that connects to our cloud aggregation service. We’re doing everything from making custom boards to embedded programming to data cleaning, all with a web-based Rails GUI on top. I’m three weeks in, and absolutely loving both the work and my coworkers!

Currently, I’m working on the Rails app, so I’m using Ruby daily, which is awesome. And because our software team is small and the app is young, I’m living the dream of helping to establish code conventions and working mostly on greenfield problems. And when I’m not feeling like working on Rails for a bit, there’s plenty of room for me to learn more anything about embedded programming and hardware.

Here’s where I work:

Why yes, that is an arctic exploration pod. Why do you ask?

I’ve blogged about code here before, and will continue to on occasion, but I often put off blogging because I feel like I don’t have something ‘big enough’ to say. Simultaneously, I’ve been feeling the need to catalog some of the things I’ve learned, and some of the silly things I’ve done, in the hopes that my pain can help someone else avoid headaches in the future.

So, I’ve decided to launch a Tumblr specifically for small snippets and quick tips that junior devs may find helpful. Tumblr just feels like a more natural place for something intended to be short form. Junior Dev Lessons posts will crosspost here, on their own page. If you want to follow those tips on Tumblr, you can go to

If you want to share junior dev lessons you’ve learned the hard way, contact me and I’ll post them, too! Maybe we’ll save some other junior devs some headaches along the way.

Preparation for “The Case for Junior Developers”

On Thursday, June 26th I’ll be giving my second-ever conference talk at Open Source Bridge! The talk is called “The Case for Junior Developers,” and is meant to explore when and where it makes business sense to hire junior developers, some strategies for overcoming common obstacles to hiring juniors, and how to support juniors in a sustainable way for both them and your business.

Here’s where I need your help! I need to hear from you how companies engage (or don’t) with junior developers, and why. Please take a few minutes and let me know by filling out the form below. Thanks!

Regular Expressions

When I was first learning about what regular expressions are and how to use them, I was having a harder than average time finding good resources to explain the basics. Luckily for me, I have an amazing community that came to my aid. Andrew Lorente wrote this awesome post, and Cory Kolbeck wrote this one explaining the bones of using regexes.

I wanted to write about regexes, but the write ups from Andrew and Cory are far and away better than any intro I could write. So, I wondered for a while what I could contribute to the discussion. Then a friend who just graduated from Epicodus mentioned that she understood how to construct regexes (use Rubular!), but not really how they would integrate with an actual program. And I have done that! So, here is a description of how my pair partner and I used regexes as an integral part of solving PCS’s code challenge 4.

For our code challenge, we had to parse and clean a text file of data in this format:

[prefix] [first_name] [middle_name | middle_initial] last_name [suffix] phone_number phone_extension

where anything in square brackets is optional, and then appropriately assign the parts that are present to the correct column in a CSV. We used OptionParser to create our own flags to run a command line script that would do all this.

The way my pair partner and I ended up solving this problem was by creating two scripts. The first script read in the raw data, stripped off the first word in every line of that data and created a reverse sorted histogram*, and then wrote that histogram data to a CSV. We then examined the output and determined which of the words were legitimately prefixes. This is the script we used:

histogram =
while line = gets
  prefix = (/^S*/).match(line)
  prefix = prefix.to_s
  histogram[prefix.to_sym] += 1
histogram = Hash[histogram.sort_by { |prefix, count| count }.reverse]
histogram.each { |prefix, count| puts "#{prefix} #{count}" }

We needed to do the same for the suffixes, so we had to split the raw data into the name portion and phone number portion in order to expose the last word of the name section. At this point, we used a regex to match the tab whitespace separating those two parts of the data, saved the first part to a variable, then ran it through a similar script to create a histogram for the suffixes.

Once we’d done that, we set up OptionParser to take the prefixes and suffixes files as input, used those lists to break up the name parts of the data, then used digit matching regexes to both match the existing phone information and reformat it in a consistent way. You can see the source code for the cleaning script. Please forgive our horribly verbose code. Hopefully I’ll get around to refactoring it soon, but for now, done is better than perfect.

So, hopefully this will be helpful to someone looking for some way to actually use regexes in their code! If you feel like playing around with the scripts we wrote, the regexes therein, and OptionParser, you can clone the project and run it in your command line. In your terminal, follow these steps:

shawnacscott in ~/Code on master #%
+ git clone
Cloning into 'pcs_code_challenge_04'...
remote: Counting objects: 128, done.
remote: Compressing objects: 100% (86/86), done.
remote: Total 128 (delta 54), reused 103 (delta 32)
Receiving objects: 100% (128/128), 382.55 KiB | 541.00 KiB/s, done.
Resolving deltas: 100% (54/54), done.
Checking connectivity... done
shawnacscott in ~/Code on master #%
+ cd pcs_code_challenge_04
shawnacscott in ~/Code/pcs_code_challenge_04 on master<>
+ ruby clean.rb --prefixes prefix_words.txt --suffixes suffix_words.txt --input raw_customers.txt --output customers.csv

*a hash where the first word is the key, and the value is the count of how many times that word is present.

Why You’ll Never See Comments Here

While I could spend a lot of time and energy spelling out the reasons not to read comments, many others have taken the time to do a very thorough job, so I will refer you to several very thoughtful people. First up, a post entitled, “Never Read the Comments,” by my friend Emily, who says in part:

I can count the times on one hand that I’ve come away from a comment thread more edified than I entered it. On the other hand, I’ve personally had comment threads vampirically drain away a bit of my soul and leave only regret in its place. Why would I do that to you guys?

The bottom line is that I want readers to come here and have some assurance about what they’re going to see, without having to worry about seeing oppressive language, hate speech, abrupt discussion of trauma without warning, or anything of the like.

There is a wonderful Twitter account that acts as a reminder for those like me who occasionally think the comments might provide some additional of value to that article I just read:

And then there is the straight-forward clarity of Julie Pagano, a prominent social justice activist working to expand diversity in tech, who has declared that “The Comments Are Dead“:

The few sites I frequent with quality comments have dedicated moderators who spend a great deal of time and energy maintaining a positive space. For some of them, it’s pretty much a full-time job. I do not have the time, energy, or willingness to put that kind of work into my site. Sorry, commenters, I have a day job.

These anecdotes are all well and good, but for those who discount personal narratives in favor of science, I have one more link, just for you. Popular Science recently turned off their comments, too, based on a new study. In this study, participants read an article on nanotechnology, followed by either civil or uncivil comments. The study authors described their results as follows:

Uncivil comments not only polarized readers, but they often changed a participant’s interpretation of the news story itself.
In the civil group, those who initially did or did not support the technology — whom we identified with preliminary survey questions — continued to feel the same way after reading the comments. Those exposed to rude comments, however, ended up with a much more polarized understanding of the risks connected with the technology.
Simply including an ad hominem attack in a reader comment was enough to make study participants think the downside of the reported technology was greater than they’d previously thought.

There you have it, folks. If you would like to engage with me or my content, I encourage you to do so! I would love to hear from you, and you’re most likely to get in touch with me quickly through Twitter or email. Thanks for reading!

Portland Code School, Month 2

The confluence of my horrible default theme, needing to troubleshoot upgrading/downloading anything WordPress related, as well as, you know, all the classwork I’ve had conspired to make it easy not to keep up here. I’m sorry for that! Luckily, thanks to a friend at Hacker School, I got the poke I needed to get back over here:

You may have noticed that my theme is not horrible anymore, that my links are prettified, and that I’ve disabled all comments, in addition to actually writing. If I keep going at this rate, I’ll be blogging from my homemade space station in no time! In all seriousness, though, what I hope to do now is write something every day. What I will probably achieve is something every week, but I’m shooting for every day. As you can see from above, poking at me will get me to do things, so feel free!

Last time, I gave you a quick and dirty rundown of where we were in the Portland Code School: Ruby on Rails class, so let’s keep a good thing going. In week five we finished up our Sinatra app and our intro to routes. We also cleaned up some of our last vanilla Ruby learning tools, finishing up the Codecademy Ruby track, the Treehouse Ruby deep dive, and Ruby Koans.

Week six had us diving into Michael Hartl’s Ruby on Rails tutorial, and getting a brief overview of database structures and design. We’re on track to finish up Hartl by next Monday, and I have to say, thank goodness. Personally, I haven’t liked it overly much. It’s a great bird’s-eye view of a lot of different built-in Rails functions, but because it tries to really hit everything, it lacks a certain depth, in my opinion. It’s been a slog for me. Once I finish, I’ll write up a more in-depth overview of my thoughts on it.

In our seventh week we kept working through Hartl and started our fourth code challenge, learning more about scripts, regular expressions, and Ruby’s OptionParser class. That continued through week eight. A lot of us PCS students were a bit confused, I think, about where we were heading with this one, but once we got into the groove of it, I think we learned a lot. I love that we now have an understanding of regular expressions (which are awesome, and totally not scary!), a taste of what’s necessary to clean and parse incoming data, and a framework for writing scripts to automate processes.

As an aside, the OptionParser class has some terrifically bad documentation, but it’s worth it to slog through. It’s quite a powerful and easy to use (once you eventually figure out how) little tool. It allows you to create your own command line flags and do all sorts of fun manipulations of files quickly.

Week nine is where we are now, and this week was all about getting us ready for our capstone projects! Can’t lie, I am excited for this. We actually pitched our project ideas last week, but this week we wrote our briefs, user stories, wireframes, and page flows. The tl;dr is that I’m making an ally email moderation app. It will allow people who receive a lot of hate mail to filter out harassing messages and let their trusted allies catalog them. The allies can then immediately alert the intended recipient if there are any actionable threats in a message, and log all the rest.

I’m a little nervous, since I’ll be writing this app on my own, and it will require a lot of different and somewhat complex Rails functionality. I’ll need to be able to use encryption, authorization, authentication, and any and all general security chops I can muster to make this a thing that could be used some day. I’m confident, though, that I will learn a huge amount of practical Ruby on Rails knowledge by implementing all of these things, though, and that is really thrilling!

What I’ve Learned So Far

The days (and hours, and weeks!) are flying by now that I’m able to make learning and coding a priority. I can’t believe my time at Portland Code School is one-third over!

I haven’t been as diligent as I would like to be about blogging here, so I wanted to skim the surface, and make sure I’m keeping some perspective on how much I’ve learned and how far I still have to go. So, here’s the run down:

We started out with the basics in week one. Getting our environment fine-tuned, installing things, learning about version control, and getting hooked in to the Portland developer community by leveraging social media and local user groups. I had already gotten a lot of those things done in the weeks leading up to school, which gave me time to focus on Treehouse and Ruby basics.

In the next week, we got our first code challenge, and I had a lot of fun finally getting in the mud with some actual Ruby. Well, actually, I had a lot of hair-pulling and late nights reading and watching screencasts to force the basics of methods and classes in my brain. But fun too! We learned to create classes and methods and started working with simple internal data structures like arrays and hashes. We built our knowledge base on other basic programming constructs like loops, iterators, and branching, as well as working on our git workflow to learn more about pair programming and working with remotes. We started getting our feet wet with the concepts of debugging and test driven development, too!

Our second code challenge (and third week) introduced us to modules and extending the Kernel, and worked to mentally reinforce the amount of room and flexibility that Ruby has. Everything really IS an object! Unit testing became an integral part of writing our code. We continued the basic introduction to Ruby concepts we’d been working through.

Currently, we’re on code challenge number three, and about to head into our fifth week. We jumped headlong from the end of our Ruby concepts (procs, blocks, lambdas, libraries, and core!) to building a basic Sinatra app and manipulating HTTP requests. We’ve gone from taking stairs two at a time to four at a time, and I can only imagine we’ll be leaping whole flights by next month!

Looking back, I’m so excited to see all the things I’ve been able to encounter, struggle with, and then finally understand. It has given me a lot more confidence in my ability to learn. Now when I encounter something complicated and foreign, I feel more often like the reason I don’t instantly understand is that I need to read and ask more questions, rather than thinking that I must just be inherently flawed and unable to comprehend.

I don’t have any illusions that I will come out of this program with the ability to write brilliant code as an island. But I am confident that I will come out of it with well-developed tools to write what I can, collaborate well, and keep learning voraciously. It seems to me, those might be the best tools I could have.