Last week was my first week of working from home, which meant two things: spending a lot of time with my computer and limited time with other human beings and, more importantly, debugging things on my own without having anyone nearby to ask for help. The latter of the two actually ended up reaffirming the fact that I actually can debug a decent amount of things on my own if I just power through and am stubborn enough to not give up.

I also learned something interesting about the debugging process: while we’re learning, we often solve the same problem again and again. At least, this was the case for one of the features I was working on which involved using an object’s slug to generate a url. As I started thinking through how to approach solving this, I immediately had the feeling that I had done something similar in another project. Digging through another repository’s source code confirmed my suspicions, and I rediscovered the stringex gem and its multiple libraries, including acts_as_url!

All of this begs the question: why didn’t I remember that this gem existed — or that I had already used it? My guess is that it’s because I neither wrote about it nor understood how it worked until a few days ago. This week, it’s time to rectify that situation and dive into the acts_as_url library and find a solution for all slug problems, once and for all!

A few weeks ago, while learning everything I never knew about user authorization, I also stumbled upon a cool refactoring pattern that I didn’t even know existed. This pattern is based on the simple idea of Ruby modules and mixins, but is particularly handy when it comes to dealing with class methods and callbacks.

ActiveSupport is a pretty massive component within Rails, and it’s responsible for a ton of different functionality, including language extensions and utilities. I last wrote about ActiveSupport back when we were exploring the Rails inflector and the libraries it provides for handling the pluralization of different strings. This was way back in September, and at the time, my understanding of ActiveSupport was pretty limited. It turns out that yes, ActiveSupport does provide a bunch of different patterns to transform simple Ruby strings…but it also has a lot more going on inside of it. For example, the ActiveSupport Concern module, which only recently made its debut in Rails 4.

The ActiveSupport::Concern wrapper is an interesting way of encapsulating…well, certain functionality that you might be concerned with. These concerns take advantage of two directories that are automatically part of the load path within a Rails application: app/models/concerns and app/controllers/concerns. So, how do you write a concern, and what should go inside of it? Don’t worry, that’s exactly what we’ll concern ourselves with next.

There are times in a Ruby program or Rails application that one comes to a single realization: Oh no, I need to deal with an external file! For larger applications, this might manifest as a request to your Amazon S3 bucket for a file, which you then need to modify in some way, or perhaps just simply read and have access to. But sometimes, even a simple Ruby script or plain old Ruby class may need to read or write to an external file.

I honestly didn’t know a lot about Ruby’s File class (wait, Ruby has a file class?! Yes, yes it does.) until recently, when I had to handle a situation that would allow me to download files from a file storage service (such as S3), and then process the file locally on my machine. The process was a bit complicated, and I still think that I have more to learn about how it actually works. But, one thing that I did actually start to wrap my head around is Ruby Tempfiles. Yup, that’s right: not only does Ruby have a File class — it also has a Tempfile class.

It turns out that these two classes intersect quite a bit, and it can be a little confusing to know how they differ. The only way to really understand Ruby’s Tempfile class is to play around with it and create some tempfiles. So let’s get filin’!

Ah, authorization – or as I like to call it, authentication’s cooler, slightly less complicated twin. It’s easy to confuse the two, but there’s a fundamental difference between them. I recently learned that while setting up an authorization system for an application that’s nearing the end of development. Authentication focuses on who you are as a user — an admin, guest, or user with an account, for example — while authorization is about what actions you can take. Authorization centers around what you are actually able to do within the context of your role.

It often makes sense to leave authorization as one of the later (and sometimes, last) step of development, purely because it means that you don’t need to worry about making sure that you are authenticated in your development environment while you are still building out your application. But eventually, somewhere between development and deployment, you’ll have to think about the abilities of your users — or, what they can and can’t do.

There are a few different ways to go about creating an authorization system, one of the most popular being can_can, a gem that has been around in the Rails community since 2010, as well as a newer gem called rolify. But the one that I’ve found really easy and fun to work with is pundit, an authorization system crafted by eLabs, and interestingly enough, based off of the logic and thought behind the CanCan’s approach. The developers at eLabs actually started off using the CanCan library in their own applications, but quickly realized that it could become very complicated, very quickly. So, they built the simpler authorization system of pundit, which is exactly what we’ll play around with today!

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

With the advent of Rails 4.2, one thing is definitely for sure: there is now one background job to rule them all: Active Job. Last week, I learned about Active Job’s easy integration with ActionMailer. But, as nice as it is to have those simple deliver_now and deliver_later methods, there will inevitably be a time that we want to do something more — something that requires writing our own custom job.

Active Job is, thankfully, very good at letting us do this. Since my ActionMailer post last week, I’ve written a few jobs using Active Job’s framework. And each time that I’ve done it, it’s gotten easier and easier. Of course, not all of my jobs have been super complex, but once I understood the basics, I could look at other people’s code and understand how it was structure and what exactly was going on.

The only way to get comfortable writing my own custom jobs was by – wait for it – actually writing one! So that’s exactly what we’ll do together. Let’s turn our ActionMailer method from last week into its own job that will be able to run asychronously. Hold on to your hats, because we’re about to leave the shire.

Last week, I sent a lot of emails — after all, I was working on creating my very first mailer. But in the process, I also realized something else: waiting for an email to send is not fun. Especially if you can’t do anything else while you’re waiting.

This problem pretty much encapsculates the reason for the existence and invention of background jobs. I’ve actually been playing around with creating and running jobs in different applications for the past few months now, yet I never really felt comfortable with them. I knew that having jobs run certain processes was clearly very important since they kept popping up all over the place. However, I was having trouble wrapping my head around what exactly a background job was, and when and why I would ever need to use one.

Working with ActionMailer turned out to be the perfect stepping-stone to Active Job, which helped me to better understand inline processes, asychronous requests, and how all of these things fit into running a job. Since we already know how to create mailers, that will be the perfect introduction to running our very first job! Integrating ActionMailer and Active Job is a piece of cake, so we’ll start with that first. Baby steps, my friends!

There’s one thing that everyone loves: getting mail! But there’s one thing that all developers would rather avoid: sending mail. Unfortunately, this paradox perfectly describes the joys and horrors of getting your application to send a single email.

I recently worked on building out a password reset feature for one of our applications. In order for this feature to work, I had to figure out how to get my Rails application to send an email to our user with a password reset token in case they had forgotten their password. I thought that handling the authentication and token aspect of this would be complicated, but it turned out that learning about mailers was the more fun part. I had never actually worked with Rails mailers before, and honestly, I thought that I was in over my head (this also might be partly attributed to the fact that I had just come back from a two-week vacation and felt like I had completely forgotten how to code).

So, I did what any developer would do: I cried and went home. Okay, okay, I’m just kidding! What I actually did was read through the documentation, play around with my application and, in the process, taught myself how to use Rails Action Mailer. I never thought that I’d say this but, getting that feature to work and seeing that email pop up was incredibly exciting. In fact, I don’t think I’ve ever been more excited about sending and receiving an email. But don’t let me tell you how thrilling it was — let’s create our own mailer and experience it together!

Words are pretty important. But do you know what’s more important than words? Grammar. (Can you tell that I was an English major?) Despite how big of a book nerd I am, there’s acually a crucial reason as to why we should keep things like grammar in consideration: convention.

At it’s very core — pun totally intended — the Rails framework is based in conventions. We rely on the framework to create our models, controllers, and views in a specific file structure, and for them to be named in a certain way. But what we often forget is that we also rely on Rails to be smart enough to handle strange edge cases, like knowing that a mice table should store the Mouse model objects, and that the MiceController should be responsible for passing those objects back and forth!

It all seems pretty automagical. But we have to keep in mind that it was the Rails core team that created and established these conventions, which means that they’re not magic — they’re just code! And as much as we can rely on preexisting Rails conventions, there might be times that we need to tweak our code to abide by those conventions. And because computers are not people (and because English is a crazy language with so many strange exceptions), we’re probably going to run into a roadblock when dealing with grammar naming conventions. Thankfully, there’s a great tool to help with this problem: the Rails Inflector, also known as every grammar nerd’s dream.

I recently went down a little bit of rabbit hole in order to do some digging on database transactions. And when I say “a little bit”, I mostly mean “a lot bit”. I opened up the Rails source code for ActiveRecord::Transactions, and I saw some interesting terms I hadn’t seen in awhile.

Back when I was first learning Ruby a year ago, I remember reading about keywords. At the time, the only thing that really set them apart for me was the fact that they had special syntax highlighting in my text editor! (Yes, really.) But when I saw them again in the Rails source code, I thought it would be time to get a quick refresher on a few keywords that I saw again and again.

But first: what are keywords, exactly? Well, they’re definitely not objects, but instead are reserved words, which are actually defined in the Ruby parser. In fact, there’s a whole slew of keywords in Ruby, but the ones that I’m the most interested in sharing with you are begin, end, ensure, and rescue. So let’s start unlock the door to Ruby with these keywords!

Is there anything more satisfying than writing concise, perfect line of SQL and then watching it query your database exactly as you expected? Probably not. Writing — and subsequently watching! — an efficient database query is one of my favorite parts of building an application.

But if there’s one thing about software development that I’ve learned over the past few months, it’s this: projects can get out of control, rather quickly. You start off with your basic models, but then as you add one feature after another, things can start to get out of hand. At that point, your focus as a developer shifts and spreads out to various things. You can’t just care about how readable your code is; you also have to consider how efficient it is, and how different units of your application might be breaking other parts (hopefully not unbeknownst to you!). In other words, you have to consider how defensive and safe your code actually is.

Recently, while writing some background jobs and creating some service objects for a new feature, I realized the importance of executing and enforcing safe code. The good news is that there’s a really helpful, life-saving ActiveRecord transaction method that allows you to do exactly this. And the really great news? You get to watch your SQL queries execute safely as a result!