How to Prep for a Rails Internship
Andy Andrea, Former Former Viget
When I first found out that I managed to land a Rails internship at Viget, I was incredibly excited: not only was I getting to intern at a great company, I’d even get the chance to learn all I could ever need to know about Ruby on Rails in the gap between my exams and the internship. By the time that June 9 came around, I felt like I had a pretty solid foundation; by June 10, I wasn’t so sure. I wasn’t truly struggling, but I didn’t really feel like I was able to do any of my assignments better than I would have a month prior.
For the first several weeks, I wondered how I could have better prepared. At first, I thought that it was simply a matter of time—had I dedicated more hours per day, I surely would have been better off, right? Now that I’ve had more time to learn and reflect, however, I’ve realized that the issue was less about the quantity of time I spent but rather the quality of that time. Since I was completely new to Ruby, I just didn’t know what to prioritize.
Now that I have a little experience under my belt, I have a much better grasp on what my prep work should have entailed. To help any future interns here at Viget—or anyone else who wants to start working with Rails—avoid using their time poorly, I’ve created a small guide to help other Ruby newbies gain the knowledge and experience they’ll need to be ready for an entry-level position in Rails.
Obligatory disclaimer: since learning anything as significant as Rails is a non-trivial undertaking, you might not end up liking the resources that I’ve outlined in this post. However, I do think that the technologies that I’ll cover are pretty important. As a result, I’ve compiled a list of resources for all of the different technologies that I’ve needed to know in order to effectively use Rails this summer to supplement this blog post. If you’re not a fan of the individual resources that I cover here, feel free to substitute others, either from the Gist or from your own findings. With that said, let’s get started.
Surprise, surprise: in order to develop with Rails, you’ll need to know how to code. In particular, you’ll need to know how to use Ruby and have some experience in object-oriented programming (OOP).
If you’re completely new to programming, you’re definitely going to want to start with the basics. While I was lucky enough to take a course introducing me to OOP—which, for me, was the best option—I really like this interactive Ruby course from Codecademy. It starts off very simply, but it advances in complexity as the lessons go on. From here, you’ll probably want to do a few more tutorials to make sure that you get as much practice in as possible.
For those who already have programming experience prior to learning Ruby, RubyMonk is the way to go. The beginning lessons are a little less basic than most other interactive courses, and each book is organized well enough to allow you to skip between different topics very easily. This means you don’t have to trudge through programming basics to get to what you need. In addition, there are also several books for non-beginners, which allows you to touch on some more advanced topics if you have the time and inclination.
Finally, if you’re the type of person that prefers books over tutorials, then check out Mr. Neighborly’s Humble Little Ruby Book or Why’s Poignant Guide to Ruby. Each talks about Ruby as a programming language in addition to teaching you how to use it; personally, I think that’s incredibly useful (and interesting!) knowledge that can help you to write better code. Plus, since neither is interactive, you can download them to a reader or tablet and won’t have to worry about being tied to a Wifi connection.
Local Environment Setup
Since most of your Ruby work up to this point has likely been via web interfaces, it’s a great time to set up your very own, personalized development environment. For most people, this will mean installing Ruby to a machine of your choosing and figuring out how you’re going to want to write and run your code.
My personal preference is to do everything on my computer’s command line: I can easily access Vim for code writing, set up a server to check out my work in-browser or run my test suite (more on tests later). Plus, since navigating more than ten lines of code with nothing but arrow keys would have driven me crazy, this approach forced me to learn some of the more advanced features of my text editor. If you decide to use Vim, make sure to check out and install some of its Ruby plugins to make your development that much more fluid and personalized.
If Vim doesn’t suit your fancy, other solid text editors include Emacs, Sublime and Atom. Aptana, an integrated development environment (IDE), is also an option and might be the best bet for anyone that’s a fan of Eclipse. Regardless of how you decide to run and execute your code, I’d strongly recommend learning the basics of utilizing the command line quickly—it ends up being both very simple and very valuable.
Now that you’ve got a snazzy, new development environment set up, you can use it to write some basic Ruby programs to hone your skills. For ideas, check out CodeEval: it has a lot of different challenges of varying difficulties. It even includes some common interview questions, like FizzBuzz. For additional practice, you can also try out CodeWars.
Front End Technologies
If you’re going to work with persistent data—hint: you will—you’re going to need a basic understanding of relational databases. Luckily, a relational database is exactly as it sounds: a database that can store relations. For example, the clone of Hacker News that I created for my internship has the notion of both a
User and an
Article. To keep track of who posted what, my app is implemented such that a
Articles; in other words, there’s a relationship between
Articles. Pretty basic, right? As with most any important technology, there’s more to it than that, so it’s worth checking out the Resources Gist or doing some Googling to learn more.
In addition to the notion of designing a relational database, there’s also the concern of being able to get data out of said database. Traditionally, a developer would write a query to the database in SQL to access data; luckily for us, Rails can handle a lot of the querying you’ll need by itself. That said, you may very well run into a situation where using Rails’ built-in queries won’t make the most sense. In those cases, a basic understanding of SQL is incredibly useful. Even if you happen to be lucky enough to avoid needing to write your own SQL queries like me—but unlike Nathanael—understanding how to use SQL will make your more complicated Rails queries much easier, which is due to the fact that Rails and SQL share many of the verbs used for querying, such as
merge. As far as learning SQL goes, I’m a big fan of Learn SQL the Hard Way—just don’t be intimidated by the name.
You’re now just one step away from getting to Rails itself: learning how to use version control. While there are a few different options available, Git is easily the most popular. As with Ruby, you’ll want to install Git to your preferred machine. You can then run through Git Immersion to familiarize yourself with running Git via the command line.
Next, you’ll probably want to learn how to use Github, which offers you the ability to store all of your Git repositories online and even view and participate in open source projects. In addition, it’s a great way to show off your code to potential employers. You can also throw single file programs, like CodeEval solutions you’ve written, up in Gists.
Rails (and Testing!)
Now that you’re a bonafide pro with most of its companion technologies, it’s time to dive into Rails in earnest. The most commonly recommended Rails tutorial—aptly named the Ruby on Rails Tutorial by Michael Hartl—also happens to be, in my opinion, the best. While it’s not perfect, it does a great job of teaching Rails while touching on Git, Heroku and testing. I’d highly recommend doing the additional problems that Hartl leaves at the end of each chapter: they’re not terribly complicated, but they do ensure that you’re developing in Rails yourself rather than just following what the book lays out for you.
While it is covered in the Rails Tutorial, I feel like I really need to stress the importance of learning how to test your code properly. As part of my internship, I primarily used Rspec, Capybara and FactoryGirl for testing, though several other options do exist.
Generally, I’d write a test for any features of my applications—like being able to post an article on my Hacker News clone or submit a pick on Winsome. For these feature tests, I’d do my best to ensure that my tests were emulating a user’s experience as closely as possible: rather than ensuring that an article was added to the database, for example, I’d check to make sure it showed up on the home page. The second form of test I’d usually write would be a model test. These would just check that each of my objects—rather than my features—were performing as expected. For example, I wrote a test for my Hacker News clone to ensure that you couldn’t create a new
User with the email address of an existing
User. To be safe, I’d also write tests for any significant amount of code that wasn’t covered in one of the previous two cases.
I also encourage anyone that’s trying to learn Rails to keep track of what did and didn’t work for you. Feel free to fork the Resources Gist I mentioned earlier and create your own version that you can share with other aspiring Rails devs in the future. Last, but certainly not least: good luck!