Shawna C. Scott

Learning to hack, one day at a time

Archives (page 2 of 4)

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. Erin Call 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 Erin 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.

Community is Everything

This past week has been a whirlwind. I’ve had tons of demands on my time from my personal life, on top of watching the firestorm that has been the Ruby community on Twitter these past few weeks*, and trying to learn ALL THE RUBY for Portland Code School.

I have to say, in a week where community has not been safe for many people*, I have never felt more supported. The men and women who are part of my network of friends who are also in tech have gone above and beyond to help me learn and grow in the ways that I need to succeed.

This week, I struggled mightily in understanding the chain of events in Ruby. Classes and methods and instance variables had me all tied up in knots, and I was stuck. A friend directed me to the online overview of Chris Pine’s Learn to Program, and I finally started to trace the threads. I’ve now received the updated, paperback version (as well as Eloquent Ruby!) as a birthday present, and I can’t wait to dive in! The next day, another friend lent me her copy of the PickAxe book by Dave Thomas.

Later, while trying to work through the Code Challenge this week from Portland Code School, I got myself all twisted in knots again thinking I needed to use regular expressions. Turns out I didn’t, but as a result of mentioning I had had trouble finding good resources for beginning to use them, three different members of the community started writing blog posts to fill that need. So far, Erin Call, and Cory Kolbeck have both written up some awesome stuff about them, which I still need to carefully read and review!

Then this past weekend, I hacked on stuff with other awesome people for seven hours in various parts of town. To be able to have so much knowledge and such generous giving of time and expertise so readily available is a gift I will never be able to repay.

So thank you.

Thank you to Christie, who founded Women Who Hack, the first technical event I ever attended. Thank you to all the amazing women I met there. Thank you to Melissa and Ian who donated to my fundraiser so I could even go to Code School. Thank you to Liene for studying Python with me and sending me well-timed resources. Thank you to Rachel for her unending kindness and consideration matched with extreme insight. Thank you to Kronda for her WordPress wizardry and generally amazing sense of humor. Thank you to Michelle, the founder of Code Scouts for helping me meet even more amazing people. Thank you to Ashe and Julie and Shanley for doing the blisteringly hard work of carrying us all forward. Thank you to Chuck and Erica for creating Portland Codes School and for helping me find a direction. Thank you to Sam, for inviting me into his home to help me learn. Thank you to Cris for giving me the benefit of the doubt. Thank you to Al for always working to be accountable and give us the best possible class. Thank you to Erin for being the most generous and understanding technical lead, mentor, and friend. And thank you to Emily, who pestered me into attending that first Women Who Hack meeting, and has been there to cheer me on every step of the way, and to walk me through the scary parts.



*I will not be discussing the details of that here. Please go google around if you want to know and don’t already, but be forewarned, massive trigger warning for everything bad you could say to and about sexual assault

First Week at Portland Code School!

This week has been quite the whirlwind!

Monday was my first class with Portland Code School for their Ruby on Rails class. We spent a lot of time getting to know each other, since the plan is to spend the next three months eating, sleeping, and coding together. We talked about the tech experience (or lack thereof) we each have, and discussed the structure of the class to follow. As I feared, I’m the only woman in the class, and possibly the only queer person (though that’s much harder to determine). Overall, our class of seven is somewhat more diverse and somewhat less privileged than I expected, so I actually think it won’t be a barrier.

Tuesday we were asked to attend the Portland Ruby Brigade meeting, which was not my first time to their events, but was my first time attending one of the sessions featuring speakers. Overall, I liked the first speaker, Markus, the best. It’s hard to even describe the topic of his talk, since he seems to integrate his thoughts across multiple topics quite deeply. Overall, he was discussing this forum post. Definitely worth a read.

The second talk was honestly quite over my head, and I didn’t really have a framework yet for relating to it. Talking with others afterward, though, I discovered I definitely wasn’t the only one who felt a bit lost. Not to say the speakers weren’t engaging or funny or smart. They just had a target audience that didn’t happen to include me.

The last speaker was talking about different models of inheritance, and it was actually quite interesting. I’ll have to do some research at some point.

Wednesday was class number two, and we covered web applications, how the web works, the model view controller structure, and a bit of standards based development.

Thursday I went to the Green Mercury hack night, and proceeded to spend most of my time there fixing things I had broken on my own system. I was trying to customize my bash prompt in iTerm, and I managed to overwrite the contents of the file (which I was using as a source) with the contents of my .bash_profile. Which resulted in an infinite loop, locking me completely out of bash. Which, by the way, makes it somewhat difficult to access your hidden files. Eventually, with massive amounts of help from Erin, we were able to use zsh to get into the files and change them in order to break the loop.

After that, I discovered that the link between my local Green Mercury repo and my remote was somehow severed, and had to spend a bit troubleshooting that. Then I made the brilliant move of deleting a file both through Github’s web interface, and also on my local branch and had to once again ask Erin to rescue me. Ultimately, I learned about git reset, my reflog, cherry picking, and how exactly git structures and conceptualizes branches, so ultimately it wasn’t so bad.

Between working and code related activities, I was outside my house at least fifteen hours each day this week, and I was glad we didn’t have anything planned for Friday! This weekend, I’ll spend a lot of time working on getting up to speed on all my homework, and hopefully getting a workspace set up for myself at home. This coding/learning while in bed thing doesn’t work for me. All in all, though, I can’t wait until class on Monday!

Adding Color Schemes to iTerm

This may seem ridiculous, but I had a lot of trouble trying to figure out how to add the zenburn color scheme to my terminal program, iTerm. Since I had trouble doing it, and it turned out to be way easier than any of my internet searching suggested, I figured I’d chronicle it here. Hopefully it’ll save someone else some time.

Searching for how to add zenburn produced a whole lot of results telling me to add one script or another to one of the various dot files for bash. I agonized over how to add it correctly, and when I did, why it didn’t actually affect anything. Then, I asked a friend. Turns out, the answer is this:

  1. Go to the iTerm 2 Color Scheme repo on Github
  2. Click, “Clone in Desktop” and save the file somewhere
  3. Open iTerm’s preferences, and choose the “Colors” tab
  4. Choose “Import…” from the drop down at the bottom that says “Load Presets”
  5. Choose the file from wherever you saved it
  6. Enjoy your new color scheme

Hope I saved you some time!

Streamlining My System, Part 2

My Ruby on Rails class through Portland Code School starts tonight, and I can’t wait! In preparation, I’ve been working on getting all those fiddly annoying things about my (I feel weird calling it this, but…) environment set up in a way that makes sense. I outlined some of my goals in an earlier post, so I wanted to revisit it to see how I did!

I did end up getting “subl” set up, which I’ve already started using pretty regularly, and its great. Vim is cool and all (no, that’s a lie), and I’m glad I can navigate my way around it if I have to, but modern text editors exist for a reason. I am happy to help myself out with tools anytime I can.

I ended up abandoning Colloquy, and went ahead and actually paid money for Textual. To anyone who knows me personally, I’m sure this is shocking. I never use paid software. Like, not ever. And yet, I paid a whole $5 for Textual, and it was totally worth it. It’s so much sleeker and more intuitive than Colloquy, the documentation doesn’t suck, and I can easily customize which (if any) noises I want it to make. I can’t tell you how many people I scared to pieces with Colloquy notifications.

Relatedly, I have progressed in my quest to have an IRC bouncer set up. I now have ZNC installed and configured (sort of) on my server, and now I just have to actually figure out how to add channels to it. Installing was a challenge, since nginx is apparently designed to be the least beginner-friendly and intuitive server on the planet, as is my AWS instance. I ended up having to create a swapfile in order to install all the things I needed, since apparently I was maxing out the capacity of my instance.  I may also have made a mistake in configuring ZNC, since I appear to have somehow disabled SSL (although I swear I followed ZNC’s instructions on enabling it exactly, so WTH). So, not a total success quite yet, but definitely significant progress made.

I did manage to add the zenburn color scheme to iTerm, which turns out to be ridiculously easy, and I am irritated that apparently no one on the internet knows that it’s easy. Or else, they just don’t bother to explain it because it’s so easy. Look for a post on that soon, since I can explain it easily and hopefully save someone else hours of time sorting through dot files to no purpose.

As you can probably tell, I didn’t make any progress on making this blog look less atrocious. I also didn’t have any luck figuring out how to edit a WordPress blog locally that is not run off of some sort of Apache server. I’m doing some more research on Vagrant after reading a bit about it and how it works with nginx, but have nothing to show so far.

Overall, I’m pretty happy with my progress. All the essential things are finished, and the rest is really just gravy. I’m sure I’ll eventually get around to it. Onward to code school!