Tips and Tricks: Adding the Ruby Faker Gem to your Project

I recently built my first complete full-stack application (so exciting!) and learned how to incorporate the Ruby Faker Gem into the Ruby backend of my project. It was incredibly handy and saved me a bunch of time I would’ve otherwise spent manually putting placeholder data into my seeds.rb file. Now I want to share this new knowledge with you all!

I’ll walk you through how to get the Faker gem all set up, then I’ll share the tips and tricks I learned while working with this gem in my own project. Read on to learn how to implement it yourself! And let me know in the comments if this was helpful or if you have any other similar gems you love and recommend.

A gif that says “How to use the Ruby Faker Gem (+ tips and tricks!)”

How-to:

Here’s the link to the Ruby Faker Gem in Github: https://github.com/faker-ruby/faker

1. Add the gem to your project — you can do this two ways. You can either run “gem install faker” in your project terminal, or you can add “gem ‘faker’” to your Gemfile with the rest of your gems, like this:

I like to leave myself comments about this kind of thing, like the one above on line 37.

2. Add “require ‘faker’” to the top of your seeds.rb file, like this:

I like to leave myself a little terminal message, too, which you see on line 3 above.

That’s technically all that’s required! Now, instead of manually filling placeholder properties into your seeds.rb file, you can use the handy-dandy Faker gem instead!

The documentation that’s included in the Github link above is great for getting started, but I came up with some extra tips and tricks while working with the Faker gem in my own project. Read on for the brief rundown, and to learn from my experiences!

Pro-tips:

Consider the relationships within your data before seeding

For this project, my colleagues and I built a marketplace app, much like Craigslist or Facebook Marketplace. In this case, there were three models and their corresponding tables — items, users, and reviews. As you can imagine, we wanted our app to function similarly to our reference apps, so we decided that: our items should be able to have many reviews, our users should be able to sell many items, and each review should belong to one item (to which it’s applied) and one user (who posted the review). In order to make sure that the tables were all working together properly, it was important to take these relationships into account before seeding!

We could’ve just seeded a handful of items, a handful of users, and a handful of reviews, separately. Like this:

As long as we made sure that the ID number parameters in lines 19, 33, and 34 matched up with the numberer of rows in each table and the ID numbers in each table, this would’ve worked okay. But we were proud to come up with a more sophisticated solution!

Since any one user could own many different items, and any one item could have many reviews, we landed on the following seeding structure after much trial and error:

This time, you can see that the seeding is nested so that we create users, and then we create items for each user, and finally we create reviews for each item. Since we’re creating each of these interrelated records using looping, we no longer need to randomly assign our foreign keys. Instead, we’ve given each new instance a variable name on lines 15, 22, and 32, and then we can use those variables names on lines 27, 35, and 36 to encode the ownership between the users, items, and reviews!

If you want multiple random images at a time, try interpolating .rand()

You may have noticed that line 26 above didn’t look quite like the other lines that used Faker data to populate the record seeds. After a lot of trial and error with the Faker gem’s random image generator (LoremFlickr), we came to the conclusion that the gem would really only give back one image per use. In our case, we wanted a different random image for each item on our marketplace (because you wouldn’t see each item on Craigslist posted with the same product photo, right?) but the LoremFlickr Faker generated just one image and applied it to each item.

Although there are many creative ways to work around this issue, we ended up adding some extra randomization. This way, using .rand() to interpolate in random photo size parameters forces LoremFlickr to actually return a new random image each time we loop through the item creation code. You can see it again below on line 26:

Note that the Lorem.sentences Faker will wrap everything in array brackets. Consider using Lorem.paragraphs instead

For this project, we wanted to to randomly generate a placeholder description that was a few sentences long for each item. Originally, we tried using the Lorem.sentences Faker, but we realized that it wrapped each individual sentence in straight brackets, like we see used to hold arrays.

Although it would’ve been totally fine to work with those brackets and simply iterate through each sentence to remove them, we found that the existing Lorem.paragraphs Faker was a better choice. It offered us a simpler solution right off the bat, since it didn’t give us brackets around each sentence.

Use Class.destroy_all and rake db:reset (for specific circumstances)

** Note: please use these last tips with caution! These two are really handy if you’re working on your own project where you’re the only person using the database, but I would not recommend using these otherwise! If you apply these to a larger project where the database might be larger or more important, you could accidentally destroy those records with this code. **

If you haven’t tried using these two pieces of code in your own projects, this is your sign! They make things much simpler and smoother in many cases.

First, I like adding “Class.destroy_all” to the top of my seeds.rb file for each of my classes, like this:

That way, if I have to run my seed file multiple times (which is almost guaranteed), it’ll destroy all the user, item, and review records from those three tables before executing the rest of the seeds.rb code that will add new data to those tables. This is handy so that you don’t end up with massive tables while you’re just tinkering on a personal project.

It’s great that using .destroy_all destroys the records, but what about the ID numbers from all those records? Since we know that ID numbers aren’t normally overwritten, it can be really easy to end up with huge ID numbers if you’re re-running a seed file that creates a lot of records. If ID numbers matter for your program, try using the command “rake db:reset”.

You can use this command in the place of running “rake db:migration” and “rake db:seed”. Essentially, “rake db:reset” will drop your database, run your migration files, and then run your seed file. Again, use this one with major caution, but when applied to the right program it can keep your database nice and manageable.

I hope you found these tips and tricks helpful! Feel free to leave feedback in the comments, and happy coding!