Shawna C. Scott

Learning to hack, one day at a time

Menu Close

`link_to` as a block with HTML options

Have you ever wanted to add an icon of some sort to a link, but couldn’t figure out how to add that <span><i class='glyphicon glyphicon-star'></i></span> in there?

The solution is to use the link_to helper as a block!

The formal syntax, as seen in the link_to documentation, is:

link_to(options = {}, html_options = {}) do
  # name

And translated into a more concrete example in an ERB template, it looks like:

<%= link_to your_path, class: 'your-class' do %>
  <span><i class='glyphicon glyphicon-star'></i></span>
<% end %>

Thanks to this Stack Overflow answer for inspiring this post!

On Tumblr

Save yourself pain; make strong params yell at you

I’d like to tell you a (cheesy, overly dramatic) story:

One dark and stormy night, you’re given a ticket that requires you to rename some data columns and rearrange a few form inputs. In your arrogance, you confidently determine this will take you no time at all. Thunder flashes. This is totally not foreshadowing.

You successfully migrate the database. You successfully rearrange the form inputs. All your tests pass. You are feeling pretty self sufficient, like a god/dess among junior developers. You decide, since you are a conscientious team member, to manually fill in the form and watch the magic happen.

Only nothing happens. The form cheerfully proclaims it’s success, but your data has clearly not been saved. You vainly try to find the problem for an hour, but eventually, BAMFness severely deflated, have to ask for help. This is when your boss/mentor discovers within minutes that you’ve forgotten to update the permitted parameters in your controller.

As you may have guessed, it’s my own hubris I’m describing here. But! I have learned something that can help you avoid this terrible tale of woe.

Add this line to your config/environments/test.rb and config/environments/development.rb:

# Raise an error when sending unpermitted parameters
config.action_controller.action_on_unpermitted_parameters = :raise

This lovely little incantation (which you can read more about on the strong parameters repo) will throw an exception when you send unpermitted keys, rather than silently swallowing them. So, instead of this:

You’ll get this:

Never thought you’d be happy to see that page, huh?

Best of luck, and always check your hubris, lest it bring you to ruin. ;D

On Tumblr

Git: Fix that last commit

Ever have that “D’oh!” moment, realizing just after you’ve committed some new change that it needs just one more little tweak? (For instance, leaving in some debugging code. Not that I’ve ever done this.)

Luckily, git’s --amend flag is here for you!

Here’s a post that walks you through using it, and the git documentation on undoing things if you want a more in-depth discussion.

On Tumblr

Testing best practices

One of the things I struggle with the most is not how to implement functionality, but instead how to create functionality that will conform to best practices. By the nature of being new, that spidey-sense isn’t yet completely developed, so I’m always excited to find new tools to help train that part of my brain.

Today, I found Better Specs, an Rspec best practices guide, and you can bet I will have it close at hand for quite a while!

On Tumblr

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 &trade; 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!