There aren’t too many things that bring me down when I’m deep into programming. But there’s always one thing that’ll stop me dead in my tracks: a code smell. In the context of programming, a code smell is something that tells you that your code is…well, a bit off.

Whether you’ve been programming for months or for decades, you’ll run into “code that smells” again and again. Except the better that you get, you’ll anticipate your code smelling, or before you even write it, you’ll know that it’s going to stink. For me, a lot of my code that tends to smell are sections where I’ve duplicated what I’ve written, which is to say that I’ve written something that’s identical or at least very, very similar to another piece of code in my application. I’ve noticed that I’ve started catching myself as I write duplicated code, which is a sign that I’m getting better as a developer – hooray!

But, there are a lot of common code smells, and I definitely still can’t catch all of them in my own code. Generally, if any part of your program has a common code smell, it’s a sign that you need to rethink how your system is structured on a deeper level, and that it’s probably time to start refactoring.

Recently, I’ve noticed that I’ve been sniffing out the same issue in my code: long methods. So I did a bit of investigating and found that there are some cool ways to shorten up your longer methods. Thanks to Ruby magic, we have easy access to methods like to_proc in the form of “ampersand and object”, or the &: syntax. If you have no clue what those are, don’t worry. I didn’t either! Until I wrote this post, obvs.

This blog post is part of a series on databases. Read Part 1 here.

When it comes to databases, there are generally two schools of thought. There are those people who love them, and there are those people who just hate them. While I wholeheartedly admit that I belong to the former camp of believers, I can understand why someone would subscribe to the latter group. Databases are hard! They’re beautiful and super fun once you understand how to manipulate them, but until you get to that point, they’re pretty much just hard.

I think that a large part of what makes databases hard to understand is the sheer amount of things you can do with the data it contains. Between database migrations, which we unpacked last week, and writing SQL queries that actually do what you want them to do, it’s really easy to just throw your hands up in the air and give up completely. But, you shouldn’t! And I hope that, after reading this post, you won’t! Because databases are beautiful (that should be on a t-shirt somewhere), and you just have to get to know them a little bit.

So, what should we get to know about them? Well, the scariest part, of course: join tables. Join tables are used to combine two sets of data from two different tables. Depending on what you query the database for, different values can be returned. No matter the size of your application, you’re probably going to have at least a few tables, and usually many more. Most of the time, the data in a single table by itself isn’t super useful; when it’s combined with another database’s information, however, then things really get cooking. Join tables are how we get specific information from two different datasets (or two different database tables). There are seven different types of join tables, but there are three in particular that I’ve encountered time and again. Let’s explore the differences between inner joins, left outer joins, and right outer joins.

As young developers, we often get caught up in what we don’t know. One of the first and hardest lessons to learn when you’re starting out as a programmer is the sheer volume of things that you don’t know. You have to get comfortable not knowing them, and you have to work towards learning as much about them as you can.

However, sometimes we focus so much on learning new things, that we forget to come back to what we already know – or at least, what we think we already know. In fact, this is exactly what I’ve been guilty of for the past few weeks. I’ve been focusing so much on learning new frameworks and getting comfortable with other languages, that I forgot to question my knowledge of Rails. Since it was a known domain and language, I assumed that I didn’t need to revisit it that often.

But boy, was I wrong. Just because you’re familiar with something doesn’t mean that you understand it completely. The trick to dealing with this is to make yourself feel uncomfortable in your otherwise familiar language. And that’s exactly what happened to me. Last week, while writing some lines of SQL (yes, really), I ran across a database migration that used an up and a down method. I saw those lines of code and realized something: I had no idea how my database really works. In fact, I’ve written so many migrations in so many Rails applications that, at some point, I’ve stopped thinking about what was actually going on under the hood. So, I set out to make myself uncomfortable and uncover the secret life of my database.

When you’re a relatively new developer, it’s easy to get caught up in all of the things that you don’t know. And boy is that a long, long list of things. But there’s also another list that we should probably consider and revisit from time to time: the list of all the things we thought we knew, but didn’t really understand when we learned them.

Last week, while developing some curriculum for an Intro to Programming course, my co-teacher and I had one of those moments. We were trying to draw a diagram to explain the concept of an object “receiving” a method. As I looked back through our code snippets, I noticed that we were using very basic methods like puts and gets quite often, as most Ruby tutorials usually do. And then I realized something: I had no clue what the receiver of the puts method was.

We both just sat there, partly perplexed and partly dumbfounded. How could we not know how puts and gets really worked? We used them all the time when we were learning to code, so perhaps we didn’t really think past the flexibility of these methods. But now that we are both more seasoned programmers, it seemed strange that we had never really thought about this before.

So, I did exactly what any good developer would do: I asked Twitter. Well, okay, I asked Twitter…and then I put on my detective hat and did some investigating of my own.

A really amazing thing happened to me last week: I wrote some code that I was actually proud of! I was trying to solve an interesting problem for an application I started building at work recently, and I implemented the first solution that came into my mind. And after I took a step back from my text editor and actually looked at what I had written, I realized something. My code was actually good.

The very fact that I was so surprised and thrilled at the prospect of writing good code speaks volumes to the nature of programming. Most of the time I abhor the methods I write because I know they could be written better, but I don’t have the syntactical flow (yet!) to write them well. So last week’s incident of “code pride”, however fleeting, was rather noteworthy.

I looked back on my code over the weekend and thought about what made it seem so beautiful to me. What did I do differently that made me beam with pride knowing that I had been the one to write that particular method? The short answer to that question is: metaprogramming. Metaprogramming is nothing more than abstraction of code, which often means that your code will write more code for you! Of course, there are a lot of different techniques and approaches to this, and I’m certainly no expert. But I did learn a little something about a meta method called public_send, and I’ll show you just how I used it!

This blog post is part of a series on testing. Read Part 2 here.

If there’s anything that I’ve learned about testing while writing this three-part blog post series, it’s this: testing is freaking hard! It’s tough to figure out the correct syntax and conventions, particularly when you’re just starting out. Figuring out when to write a test is also a tricky business. And then sitting down to actually write the test is pretty difficult, too.

But there are ways to make it easier on yourself. And I should know, because I tried to write my tests the hard way, and I definitely do not recommend it. Here’s what I do recommend: GEMS! And lots of ‘em. There are a lot of Ruby gems out there, specifically designed to make your testing life easier.

So, to close off this epic series on testing in Rails, I’m going to share my two favorite testing gems: shoulda-matchers and database_cleaner. Once you know how to implement them, your testing life will forever be easier. Because, let’s be real – isn’t that the way testing should be?

This blog post is part of a series on testing. Read Part 1 here.

Good things always come in pairs, and that couldn’t be more true when it comes to testing. Like milk and cookies or peanut butter and jelly, test suites and test data are at their best when they’re put together. As we discovered last week, a thoughtful test suite is important when it comes to checking our assumptions. But even the most comprehensive test suite is nothing without the appropriate amount – and type – of test data to support it.

Every Rails application comes with a production, development, and test environment, and good test data is an indication of a well-constructed testing environment. But not all data is created equally. To take a cue from George Orwell, we could go so far as to claim that some forms of test data are more equal than others.

Enter FactoryGirl, a gem that I’ve recently discovered to be the most efficient way and painless way of creating test data within a Rails application. Generating test data is often the culprit for not only a great deal of pain and sufferring, but also some annoying bugs that are hard to catch. In fact, one of the most excruciating bugs I’ve ever dealt with came from a single line of code, meant to create some test data. So it seems fitting that this week we tackle the most dangerous (yet thrilling!) part of testing: generating test data.

Up until two weeks ago, I had one great fear: testing. And, to be clear, when I say “fear”, what I actually mean is sheer terror.

My test-writing anxiety stems from the fact that I’ve never really had to do it before. I mean, I’ve had to make tons of tests pass, which means that I read other people’s tests all the time. Yet I’ve somehow made it thus far in my coding career without ever having to write relatively complex tests of my own. But that all changed a few weeks ago, when I was forced to finally confront my fear of testing.

The thing about conquering fears, however, is that usually involves doing the very thing that you’re afraid of. So, I spent the better portion of a week learning how and when to write tests, all while encountering a couple painful bugs along the way. It was not a fun week, but the good news is that I can write a fully-functioning test suite now! And now that I know more about testing, I actually find it kind of fun – so fun, in fact, that I’m going to share it with you!

There comes a time in the life of every developer when you stop thinking about whether your code works. Instead, you concern yourself with something else entirely: how efficiently your code works.

In fact, you can trace this back to Kent Beck’s philosophy of “Make it work, make it right, make it fast.” Once you’ve got your code doing what you want it to do, you need to make it better. But what do you do with your improved code once you’ve set it right? Make sure that it’s working as fast as it possibly can, of course!

Code efficiency is a bit of an advanced topic, and I’m definitely no expert in it. But I recently learned a pretty awesome querying method that’s neither difficult to understand nor too complex to implement. In fact, this method has always been right under your nose, hidden inside of the magic that is ActiveRecord. So what is this magical method, exactly? Well, it’s called includes, and once you start using it, you’ll never make database queries the same way again.

It was the best of times. It was the worst of times. It was…refactoring time! Well it was for me yesterday, at least.

Refactoring your own code has a great payoff at the end, but boy, does it take some work to get there. Something I’ve noticed about my own code recently is that I’m now able to know that something needs to be refactored pretty easily. I’ve been having a lot of gut feelings about parts of my code that just feel wrong, inefficient, and repetitive. The problem is, even though I know where my code is weak, I don’t usually know how to go about making my code better.

And this is where making effective use of resources (read: The Art Of Effective Googling) comes quite in handy. Yesterday, however, I used even better resource – a more experienced developer! We took a look at my code and came up with some ways I could refactor it. I learned about a pretty interesting module that could save me lines of code and keep my application DRY. And now I get to share it with you! This module is called Forwardable, and trust me when I say that it’s going to make you want to delegate all the things.