Sometimes, it’s the little things that matter the most. As cool and complex as your giant application might be, small details like a toggleable button, or beautiful-formatted and styled dropdown select can have the biggest impact on the look and feel of the rest of your application.

Once you’ve built out the skeleton of your application and filled in the backend functionality, the next step is to connect the all the logic with your frontend framework. And once you’ve done that, you start to see all the gaping holes that you need to fix next. One of the applications that I have been working on recently got to that state. Once I ensured that the user-facing page corresponded to the admin panel, it was time to fix all the little things that I had been putting off until we got the application working!

One of those minute details was rendering markdown. While building out the application, we were just using Ruby string primitives in our database to render text. But no one wants to see a long five-paragraph article rendered as a single, huge block of text, right? So, we had to make our text easily editable on the admin panel and renderable — that’s word, right? — on the user-facing side. At first, I had no idea how to go about doing this. But it turns out that (no surprise here!) this problem has been solved before! All we had to do next was figure out how to implement someone else’s solution on our own application. Luckily, the answer to our prayers is as simple as rolling out the redcarpet gem.

We all know how this scene plays out: you’ve created the first iteration of your application and you’re ready to test it out in production. You can’t wait to see what it looks like live, and you want people to be able to start playing with it! Everything seems to go smoothly without any glitches while deploying until you go to your app on Heroku and see…a broken image icon. Tada!

This happened to me recently, and boy was it disheartening. I was all excited because I had used paperclip to get some pretty cool image uploading functionality on my application, but it didn’t seem like it was working. It turns out, however, that an application in development is one thing; the same app in production is another game entirely.

While developing an application, our environments are configured in a certain way. It’s easy to forget that things will change once we deploy what we’ve been working on. Being able to implement something like the paperclip gem in development doesn’t easily carry over to your production environment – unless, of course, you know what tool to use. Luckily, there’s a great gem that was created specifically to make the transition from development to production quick and easy: the aws-sdk gem, Amazon Web Services’ Software Development Kit that was created to use with Rails applications for storing your static assets in your AWS Simple Storage bucket. And once you know how to set it up with your Heroku account, you can get rid of that pesky broken image icon once and for all!

They say that a picture is worth a thousand words. How they came up with a such a nice, conveniently specific number number I’ll never know. But what I do know is that everything on the web is just data floating around in cyberspace. And when I say everything, I really do mean everything – including pictures!

I’ve worked on a few different projects that have required building out an interface to allow a user or an admin to upload images. The first time that I had to do this, I knew that there were a few different Rails gems out there to help make this magic happen. But I didn’t really understand what was going on when I implemented these gems the first time around. To be quite honest, the first time I had to implement file uploading, I just followed the setup steps rather blindly. Now that I’ve had to solve the same problem multiple times, however, I feel a bit more comfortable with the process.

There are a few different gems out there for handing file attachment in Rails, but my favorite one to use so far has been paperclip. Created by the super cool developers over at ThoughtBot, the paperclip gem is fairly simple and straightforward to use. The reason that I like this gem in particular is that it fits seamlessly into the Rails framework. Files and attachments are treated just like an attribute on an ActiveRecord object, which makes the setup process both easy and intuitive. However, that doesn’t mean that it’s not intimidating at first! Luckily, we’re going to walk through using the paperclip gem together.

Database indexing: the last frontier. Well, okay, not the last frontier perse…more like the frontier that I’ve been reading about a lot recently. While learning about writing about smart and efficient migrations, I stumbled upon a rabbit hole that I had to restrain myself from going down: the rabbit hole of database indexing. But this week, I allowed myself to explore and learn some more about how indexes work.

As the cat gif above might already suggest, an index in a database is much like an index in a book: a place where you can quickly look up the exact information that you need. We already know that indexing can be super helpful when it comes to application performance. Using indexes forces our database to use integers to look up rows – which are just representations of items or objects – in our database. The reason that they’re so efficient is because looking up something in a database is both fast and cheap if we use an integer to do it (using a string on the other hand, is much, much slower and more expensive). By implementing a simple index, we can speed up a single query by seconds!

But it turns out that even a single index can be complicated. And that’s because there are so many kinds of indexes available for us to use. In fact, there’s a whole world of different types of database indexes out there. Of course, knowing the options available to us when it comes to database indexing is just half the battle; the other half is knowing when it’s the right time to use all these different types of indexes. The best way to learn is by playing around with some indexing ourselves – so let’s dive in!

All it takes is a single feature to make you realize how well – or perhaps not so well – you’ve written your application. Depending on if you’ve done a good job of separating concerns, abstracting and encapsulating bits of functionality into cohesive code, and just generally not repeating yourself…well, you’ll probably be way more enthusiastic about adding a huge new feature to an already massive application. But if you haven’t done any of those things…well, you might find yourself doing a massive rewrite of your codebase just to implement a single feature.

Luckily, the application I started adding a feature to last week is pretty well-built, which makes it flexible enough to add new functionality relatively easily. Yet even the most well-thought-out applications need to be teased apart and glued back together during the course of their lives. Often times, a big part of building out a new feature is restructuring the architecture of your application. When you’re working with larger code bases (legacy code in particular), that can be the most daunting task. But a lot of the intimidation of that begins to dissipate once you know how to go about restructuring a schema which already exists without breaking all the the things.

The first step in this process is writing migrations to change how the objects in your application and database relate to one another. Of course, knowing how to write the proper migration to suit your needs is just half the battle; the other half is writing a migration that makes object lookup in your database efficient and super fast. Even though I’ve written about migrations before, I’m learning that there’s always so much more to know. So, let’s get learning!

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

Everything seems to perform a service these days. We’ve got infrastructure as a service, platforms as a service, and even software as a service. But the servicing doesn’t end there: even our software applications often need specific services provided to them. But how, exactly?

Well, if you’ve ever opened up a Rails application and peeked inside of the main directories, you can get a good understanding of what exactly the application is doing. Pry into the models directory, and you’ll see the kinds of objects the app transforms and manipulates. Open the controllers directory, and you’ll see the different CRUD (create, read, update, delete) operations that are permitted by the application, and the various ways of handling requests and responses by the server.

Seems pretty straightforward, right? Except until your application starts to swell in size, and then you’re packing a ton of functionality into these two directories. We at least try and keep our models fat, and our controllers skinny. It would be great if just our trying to do that was successful all the time. Yet that’s not usually what happens. Instead, things start to get messy, code starts to leak out all over the place, and we all just want to give up and go home. But we don’t have to give up just yet! There’s one trick that we haven’t tried yet, and it’s guaranteed to make our lives easier: utilizing service objects. Or, in other words, servicing parts of our application and separating our code out into more appropriate places.

Rake tasks: we’ve all used ‘em. From migrating our database to seeding it, we run commands using rake all of the time! But what actually happens when you run a rake task? And where is all this stuff defined, exactly? And how do you write a customized rake task of your very own?

These were the questions I was asking myself last week, when I had to write a rake task to stage some data for an application I was working on. I knew exactly what my rake task was supposed to accomplish, and I had a general idea of the code that had to live inside of it. I didn’t quite know how to write my rake task, however. And I definitely didn’t know what was going on inside of the Ruby interpreter when it would read my yet-to-exist task.

So, I set out to answer some of those questions, and learned a bit about how rake works in the process. It was an interesting rabbit hole to dive down, particularly since I had never before questioned what was happening when I ran a rake command in my command line. When you’re first starting out with code, it’s okay to accept some of the obfuscation that is inherently a part of the abstraction of larger applications. But you should never go too long without questioning why and how a certain thing works the way that it does. And that’s exactly what we’ll do with our beloved rake commands.

Lesson number one when it comes to developing for the web: everything is just data. When you send something to the server in a request, or when you get something back from the server as a response, all you’re really dealing with is data. Simple enough to remember, right? Wrong. Because data can be complicated. Especially when you consider the fact that it has to be passed back and forth in very specific ways. And if you don’t format your data correctly, your computer is going to be very, very mad at you (or probably just throw a really unhelpful error message).

I encountered the complications of data formatting the hard way, while trying to pass data between two parts of my application. I wanted to send some data to update a Ruby object in my Postgres database on the server-side, and then I wanted the Rails side to send back an updated response. As if that wasn’t enough, I then needed the Ember front end to grab the updated data and immediately render it to the user on the client-side. Data formatting can already be complex when you have only one framework or language; throw in another framework and language, and, well…you might feel like you’re having a little bit of a meltdown.

But fear not! Because here’s one awesome thing about data: once you understand the way that it’s structured, it’s pretty simple to use. And when it comes to working on a more intricate Rails + JavaScript application (like the one I was building recently), there’s one kind of data manipulation you’re probably going to have to do at some point or another: data serialization. When working with a JavaScript front end, you’ll probably have to serialize your data into a JSON format, which is short for JavaScript Object Notation. Thankfully, there’s a handy gem that makes this so easy that you’ll never again question whether or not to serialize your data.

A week ago, I was on a code overload in Singapore. What was I doing on the other side of the world? Why, giving (and attending!) my very first talk at a Ruby conference, of course!

I was lucky enough to join some serious Ruby powerhouses at the Red Dot Ruby Conference earlier this month. And it was such a cool first conference experience. But, because I had to give a talk, I was pretty preoccupied with writing my speech and creating some fun slides to accompany it. What I forgot in the process was that I would be an audience member at the conference, too! (Pretty silly, I know).

My lightning talk was just a few minutes, which meant that for the majority of the two-day conference, I had the unique opportunity to listen to some really fantastic talks. And I learned so much. I also got to meet some interesting, talented, and creative people who have made some very significant and core contributions to the Ruby and Rails communities and codebases. Summing up everything that happened in those two days is a bit difficult since every talk was informative in many ways. But I’ll recap at least some of the dopest things I learned about while I was there. But if you want the full effect, you should probably eat a durian while reading this post – just sayin’.

There are a lot of opportunities in programming to feel pretty silly about yourself. I’m sure that the more coding experience you have, the less often these moments actually occur. But early on in your career, they seem to happen quite often – or they do to me, at least.

I had one of those moments a couple weeks ago, when I wrote a super long method and then asked a senior developer to take a look at it. While I was writing it, something seemed inherently wrong. I was sure there was a better way to do it, but I guess my Googling skills aren’t quite superb yet, because I couldn’t find quite the right answer anywhere. It was then that I decided to ask someone who would know exactly which tool to reach for.

What happened next was pretty awesome, albeit slightly depressing. I watched my code be refactored from ten lines down to a single line. It blew my mind – and not just because I didn’t know that this method even existed, but because I wanted to know how it worked! So, I did some digging and learned a bit about the method that I wrote which, as it turns out, already existed: the Rails group_by method on Enumerables.