[MUSIC]

>> In this lecture, we will discuss building a rakefile,

defining a rakefile task, and populating a database with sample data.

We're going to be staying with the UI topic, but

we need to take a slight detour in order to be able to create some test data

that we can use while we're interactively developing our web application.

So to do so, I'm going to implement a customary file that

will be responsible for purging all the current data in our selected database and

populating them with users and subjects, like images and things and links.

To get started with that customary file, I can use the task generator.

And my break file is going to be called ptourist, or

the namespace of my task is going to be ptourist.

It's going to have one primary method that we'll use quite often which is reset_all.

Drop what you have and rebuild and get us back to the starting point.

And then it will have a couple of supporting methods like delete_all

the business data without deleting the users, delete everything

including the users, delete everything and put back only the users, and

delete the business data and just put back the business data.

Okay, let's just get started with what we have.

So that creates a raketask in lib tasks.

And you notice when we go into the rakefile that we have the shell of

each task.

And with that shell gives us the ability to get a minor amount of help.

We can register some words to say when they ask for a -T option.

And you'll notice that all the tasks either hierarchically, or

through inheritance, depend on :environment.

Using that approach allows us to assign the particular database and

run our raketask against a custom target.

By default, it's going to run against the development database.

Okay, let's just go through some of the overall structure of the rakefile.

For the subjects,

what we're going to do is depend on the user's task which is the task above it.

And then what we'll be doing inside of here are creating new things,

images and links.

For users, what we'll be doing is depending on the delete_all task,

which is just above it, and once that's complete, we'll be creating new users.

And we'll be populating it from a list of members, and

let's make about nine members.

Let's go ahead and bring in the Brady Bunch in order to run our organizations.

And then for delete_all,

it's going to depend on delete subjects which is the task above it.

And then it's going to worry about removing users.

And then delete_subjects to be responsible for removing all things,

ThingImages, and images, and anything else related to the business data.

The reset all really doesn't have a lot to do,

except depend on the other tasks and supply a short help message.

So if I go ahead and just run,

you'll see that we're printing out how many things we've removed.

We're printing out how many things we're going to create, haven't created them yet.

And just a couple of DEVO.

All right, so rakefile tasks are kind of nice.

They're a step above CRB in that you have the ability to define

finer grain methods to interact with your application.

And with CRB there's really only one.

So I kind of think of the CRB as your poor man's rakefile.

It's not all that poor, but there's only one and

there's no straightforward way to define any kind of methods into it.

So if you think you're going to have more data population scripts or

you want to actually have some fine grain methods into this, like for

example, the default implementation that I'm going to put into users and

subjects will create a specific set of data that's repeatable.

If you want something that allows it to generate, go into a for loop, and

churn out fake data, that's another task you could put into here.

So to fill out my initial rakefile, we want to start with some helper methods,

give it a first name, and knowing who our members are,

what will be their full name that'll be associated with the account.

What's going to be their email address associated with their account?

And some ability to find them based upon first name,

knowing that everyone in the family has a unique first name.

It's pretty simple now because our images just have metadata.

And this method is probably just recreating what

the factory was going to do.

But anyway, I have a helper method that if you know who's going to create the image,

and the metadata for the image we'll get that in place.

And then the next method,

don't sweat the details, just realize that there's a helper method going on here.

If you pass the properties for a thing, a hash, that thing will be created.

If you pass the organizer for

the thing, the actual database object that gets returned by this user method,

it will be assigned to be that organizer for that thing.

And then when accompanied by a list of images, that thing will have images.

So essentially after the thing is created, we'll go through a loop

creating each of the images in the collection and assign it to the thing.

So when it comes time to deleting subjects,

I could use thing delete_all, image_delete all.

But I can also bring in database cleaner and say I would like everything out of

the database except for things in the users table.

But I also want everything from mongo gone as well.

And then when it's time to remove users, I'll use database cleaner as well

except the only thing I want it to remove are the users.

And then when we go to create users, we're just doing a loop over each of the members

and building a definition of their name, their email address and password.

And the password is going to be a one up number.

So that we're sure that we're not reusing passwords across,

that we actually have unique data.

So Mike will be password 0.

Alice will be password 2.

Cindy will be password 8, if I've got my math right, at 0 relative.

Okay, when it comes time to creating subjects,

there's going to be many things in here.

And I'm just going to show you one of them, the simplest one that I could find.

I'm just going to create a set of records, that's what is the thing.

Well, thing has a name, a description.

And it's going to have some notes.

The name and description are public information, and

the notes is private information for the members and the organizer.

It's going to have an organizer.

In this case it's going to be Alice.

And it's going to have a set of images.

In this case, it only has one image.

And there should only be one priority zero.

But the application will work with multiple.

But what we mean by priority zero is if we look for

it, this is the image that should be shown whenever we're referring to that location.

Now we're not worrying about it yet and we're not doing anything with it yet, but

each of these images are going to have a geolocation.

And that's going to be very important in about two modules or so,

to where we know where is this image, so we can associate it with the thing and

begin to map it and know how far it is from another location.

Since we know it now and sooner or later it needs to get into this file,

I went ahead and left it in as I pulled in the data.

I'm also leaving in the reference to the image.

We'll get into images in the next module.

But for right now, again, it's only metadata.

We're only worrying about captions, for the most part, captions and priorities.

Okay, so actually if I stopped here, with just that implementation, and

ran it against my test database, Now we get

the fact that nothing was removed but that I did create about nine users.

I built an image for the Holiday Inn in Timonium, that's like North Baltimore, and

it's of the front entrance.

And if I were to run it again, that one hotel would be removed,

its one image would be removed and all nine users would be removed.

And the nine users would come back, the hotel would come back again.

So you don't have to be afraid of modifying data.

You can get it back quite easily.

Now with my rig file more filled out with my initial set of data,

which is probably going to change, you'll see that the same users are being created.

And that we have many more things, organizations,

would be a railroad museum, the water taxi, rent-a-tour, the national aquarium,

things like that and different images that are going to be associated with it.

The images are coming. That'll be in the next module.

Right now, we'll just worry about the metadata which currently just consists of

caption and the organizer, so who supplied this image, okay?

And realize, this may not have been my first pass at creating this data, but

it likely won't be my last either.

So don't be surprised that these numbers change.

For example, I'm noticing right now I don't have orphan things,

things that don't have images.

So expect the contents of this file to be adjusted over time.

In summary, we built a way to reset our database back to a known starting point

with useful data.

We could have used a seeds.rb file, and used rake db:seed.

However, there's really only one seeds.rb file supported with that technique,

and it's very coarse-grain.

With a rakefile, we can define as many custom rakefiles as we need, and

we can make the tasks within a rakefile as fine-grain or coarse-grain as we need.

Much more flexible.

And we use the power of a custom rakefile in order to populate our

Photo Tourist development database with image metadata, some Things and

then links between those two known as ThingImages.

So that our UI during development has some information that can be displayed

that we can interact with.

What's next?

Authenticated image management.

Let's build some crud management in the UI that performs authenticated interaction

with the server to manage the images we just finished putting into the database.

DB: Populating Sample Data with Rakefile

Capstone: Photo Tourist Web Application

Meet the Instructors