How to Setup Your Development Environment

Using and customizing the tools built into Rails to run your development environments is a huge benefit.

Check out how to can use some standard scripts like bin/dev and seeds.rb to prepare our system, and dev:prime to prepare the development environment specifically.

Transcript:

Having a good system in place for your Rails app to get it up and running can make it a lot easier to get going. There’s a few things that are built in and a few things that we can add to a Rails application to make onboarding new people or switching to a new computer just to be a lot easier. Looking at a project that I’ve got, a side project, this here has a few things that are kind of built in.

bin/dev

Inside of the bin directory, you’re going to be getting bin/setup as a thing that’s built in.

And this is a good place to start.

So here we’re going to make sure that we’re installing all the gems.

This is using yarn for new JavaScript dependencies.

We set the database, clear it all the files, and then reboot the server if it was already running.

So this basically gets things set up.

This is a great place to start customizing.

There’s other things that you need to connect and hook up and make sure that they’re there.

That’s a great place to put them.

seeds.rb

The next step is seeds.rb.

I’m going to uncomment this.

So with your seeds, your seed file is basically things that your system depends on.

So this is the system configuration and data that’s just kind of universally needed.

So this is stuff that you’d want to exist in production and development and in testing.

So the example we have here is we’ve got a list of countries or something that’s more appropriate.

This is the budgeting app. So it’s going to have some default categories for budgeting things.

So the thing is that you want to have this in all environments, you don’t want to put stuff in here that’s going to be, for example, development specific. So we wouldn’t want to put in a test admin user.

One of the other things to remember when we’re doing this kind of seeding type stuff, we want to make sure that we’re using find_or_create! by typically.

What this is going to do is this… Let’s see if I can say it right. I always stumble over the word. But there’s the idempotent to this, which basically means we can run the seeds again and again and again. And it’s not going to break anything.

So if we did something where we said Country.create(name: country), then we would end up having 15 Canada’s and 15 US’s after we ran it a few times.

That’s going to be a problem.

find_or_create! is going to do a find. If it finds something, it will return it. If it doesn’t find something, it will create it and then it will let us optionally run a block on it so we could throw on here a do |country| and then something.

But we don’t need to in this case. So you want to make sure you’re using find_or_create_by.

One thing to note. I initially way back in the day did first_or_create, which is a big no-no. What this is going to do is it’s actually going to ignore the where clause that you’re doing here and just grab the first record. If the first doesn’t exist, then the thing you create will have that where clause applied to it.

So that’s not what we’re typically going to be looking for.

This actually is in classes that don’t exist so we can comment that out and just move on.

So that’s looking at the db/seeds.rb file.

dev:prime

The next, and this is probably going to spend a little bit more time digging in, is the prime.rake. And this is what I typically will have set up. So this would be in your lib/tasks/prime.rake in this case. So what this is, is this is the kind of development environment seed file, basically.

So in here, for this system, we’re creating an admin user.

So we’re going to find or create by it, and we’re going to use password.

I also print that out that way.

If you run this, it’s going to say that you created it.

I also typically would have a few other normal users that way you can jump around between accounts.

With this, we have an admin organization and we create the membership for that organization.

We create two budgets and then for each of those budgets, I’m going to be setting up some test information. So they get a checking and credit card account, which is for spending, and they have savings, which is a savings account.

This system is doing envelope style budgeting. So, we create a set of default envelopes. In here, I make up a few names for payees and some dates. And I basically create a bunch of random transactions.

Now, for most of these, I’m doing find_or_create_by, as I already said, that way they’re of unique.

The transactions however are all random, so I just don’t want to keep track of them or anything. So that’s why in here, I’m just saying spit out 20 of them.

Now, I instead of doing a something like 20.times do, I’m going to create them until the count is 20. This is to avoid running 20.times if the transactions are already created.

So in here, I’m actually going to run it and I’m only going to do it if, and actually I’m noticing, I should probably be bumping this up to the top. So if it has less than 20, we’re going to loop through and do it until we have 20.

And here I’m doing everything random. I’m putting into a bucket, I’m putting on to the same membership. The payee, I’m just pulling from one of the random ones here. I’m just taking a sample and I’m doing the dates. I’m doing a sample from that as well.

A transaction can be made up of multiple splits, but in here I’m doing a spending one. So it’s going to be -$150 to -$0.

And that’s going to be going into a random one of the envelopes and a random one of the bank counts.

This lets me basically set up the entire database and get it up and running.

bin/dev0

Built into Rails is bin/dev. I typically recommend doing any preparatory stuff for running your system.

And its focus primarily is looking at your procs file.

Because of the way I have this project set up, I’m using yarn, JS bundling and CSS bundling.

So in here it’s going to run those two javascript processes. It’s going to run the web process as well. This is where we can also throw in anything else that we need to, sidekick or whatnot.

This is a good place where we can override those options.

Using the Tools

So to use these, I come into the terminal and I go rake db:drop so we completely drop the database. I can now do kind of run through the scripts.

So I can go bin/setup, rails db:seed, rails dev:prime, and bin/dev.

And if I refresh the page, I’m going to sign in.

If I do admin@example.com with password. I’m now signed in.

And if I hop over to the transactions, I can see that there’s a bunch of transactions in there that’s put into a bunch of random categories and I’ve got no groceries, which is interesting.

But anyways, you can see how that kind of looks.

And we have our whole system setup.

A Shortcut

Now, one thing that I like to do, kind of following along with this trend of the bin/setup, bin/dev, etc, is to do a bin/prime.

With that, if I drop it again, and run bin/prime, this is just going to do bin/setup, db:seed, and dev/prime, and the bin/dev.

So this basically does that whole process automatically, and we’re back to the blank system that’s up and running.

So having this, and a lot of the naming conventions on this comes from some of the articles by Thoughtbot, but this basically means that you can get people on board up and running right away.

And if there are standard issues that people run into, you can easily put in something that either checks for the condition and gives a nice good error warning message or maybe even corrects the issue automatically so they don’t have to run into it.

So using something like this helps simplify your onboarding, makes you more consistent and makes everything run a lot better. This is a good way to get your project up and running well.

Alright, take care and see you next time.