1
00:00:00,120 --> 00:00:05,520
Now that the user and points are sitting behind authentication we're going to turn our attention towards

2
00:00:05,520 --> 00:00:06,770
our tasks.

3
00:00:06,810 --> 00:00:12,420
We haven't worked with tasks in a while and if we're going to set up authentication there's a few important

4
00:00:12,420 --> 00:00:13,860
things we need to do.

5
00:00:13,980 --> 00:00:20,550
First up we need to figure out how to create a relationship between a user and the tasks that they've

6
00:00:20,550 --> 00:00:21,480
created.

7
00:00:21,480 --> 00:00:27,540
This is going to be important to make sure that users can only access and manage their tasks and that

8
00:00:27,540 --> 00:00:29,760
they can't mess with someone else's.

9
00:00:29,790 --> 00:00:31,800
And that's exactly where we're going to start.

10
00:00:32,280 --> 00:00:35,850
So to kick things off what we need is index data J S.

11
00:00:36,030 --> 00:00:38,880
We don't need off dot J us anymore.

12
00:00:38,880 --> 00:00:40,860
We're gonna need the User model.

13
00:00:40,860 --> 00:00:43,560
We don't need the user router anymore.

14
00:00:43,560 --> 00:00:48,460
We need the task model and last up we need the task router.

15
00:00:48,810 --> 00:00:54,300
So we're going to kick this video off by working with these four files and the first file we're going

16
00:00:54,300 --> 00:01:01,740
to touch on is a task that J S now there are two ways we could set up this relationship between a user

17
00:01:01,830 --> 00:01:03,180
and a task.

18
00:01:03,180 --> 00:01:10,650
The user could store something like the I.D. of all of the tasks they've created or the individual task

19
00:01:10,680 --> 00:01:16,680
could store the idea of the user who created it and that second approach is the one we're going to go

20
00:01:16,680 --> 00:01:16,950
with.

21
00:01:16,950 --> 00:01:18,890
It is the better approach.

22
00:01:18,900 --> 00:01:24,990
The only change we're gonna make to our data is we'll be adding a single field onto task it's going

23
00:01:24,990 --> 00:01:32,820
to store the I.D. of the user who created it and that's going to allow us to lock down the task management

24
00:01:32,970 --> 00:01:33,990
later on.

25
00:01:33,990 --> 00:01:39,300
So right here let's go ahead and set up a another field on the task model we can call this.

26
00:01:39,300 --> 00:01:45,990
Anything we like something like owner or creator or user or author would be appropriate you could use

27
00:01:46,020 --> 00:01:47,160
any of those.

28
00:01:47,250 --> 00:01:52,800
I'm going to go ahead and stick with owner for this one and we'll set it up like an object which we've

29
00:01:52,800 --> 00:01:55,950
done for all of our other model fields.

30
00:01:55,950 --> 00:02:00,590
Now from here we're going to customize the field we are going to set the type.

31
00:02:00,630 --> 00:02:06,900
So let's go ahead and start with that the type for owner is gonna be an object I.D. and to set this

32
00:02:06,900 --> 00:02:09,420
up we have to use something on Mongoose.

33
00:02:09,450 --> 00:02:20,060
So right here as the value for type it is Mongoose dot capital S schema dot capital T types then dot

34
00:02:20,060 --> 00:02:25,050
capital O object capital I d perfect.

35
00:02:25,100 --> 00:02:30,240
So this is saying that the data stored and owner is going to be an object I.D. And that's correct.

36
00:02:30,260 --> 00:02:36,860
Additionally we'll also set required equal to true for this like we've done for other fields that must

37
00:02:36,860 --> 00:02:42,800
be provided and we're going to say that if you're creating a task you have to provide an owner for that

38
00:02:42,800 --> 00:02:50,090
task no longer will it make sense to be able to anonymously create a task now that we have this in place

39
00:02:50,090 --> 00:02:51,500
and we've changed our data.

40
00:02:51,770 --> 00:02:56,540
What I want to take a quick moment to do is trash our existing database.

41
00:02:56,600 --> 00:03:02,130
We have old task data inside of there without owners and that doesn't make sense to have anymore.

42
00:03:02,270 --> 00:03:06,440
So what I'm going to do is right click the database and drop it completely.

43
00:03:06,620 --> 00:03:13,910
Once the database is dropped we can go ahead on focus on actually creating tasks that belong to a specific

44
00:03:14,060 --> 00:03:15,080
user.

45
00:03:15,080 --> 00:03:20,890
And to do that we first need a user to create the task with over in post man.

46
00:03:20,900 --> 00:03:21,950
We can get that done.

47
00:03:22,340 --> 00:03:24,000
So we just deleted the database.

48
00:03:24,020 --> 00:03:27,580
But as long as our app is running we can still add data to it.

49
00:03:27,650 --> 00:03:32,000
It will automatically get created for us right here as an example.

50
00:03:32,000 --> 00:03:35,330
We can fire off create user to create a new user.

51
00:03:35,540 --> 00:03:42,140
And this is the user that we're going to use when creating our very first tasks that have the owner

52
00:03:42,200 --> 00:03:44,300
field so to do this.

53
00:03:44,480 --> 00:03:51,240
Let's head over to the task router and make a change to the very first endpoint we have inside of here.

54
00:03:51,260 --> 00:03:56,120
This right here is the endpoint responsible for creating new tasks.

55
00:03:56,120 --> 00:04:00,710
Now this end point doesn't provide an owner and it's not behind authentication.

56
00:04:00,710 --> 00:04:02,440
We're gonna go ahead and change that.

57
00:04:02,450 --> 00:04:06,850
The first thing we need to do is load in the off middleware so we can actually use it.

58
00:04:06,860 --> 00:04:09,910
We'll start their contest off equals.

59
00:04:09,920 --> 00:04:17,390
We'll be using require to load that in dot dot to get out of the routers folder forward slash middleware

60
00:04:17,450 --> 00:04:19,240
forward slash off.

61
00:04:19,340 --> 00:04:24,290
And once we have that in place we're gonna add it as the second argument to the post method.

62
00:04:24,560 --> 00:04:31,070
So right here off moving the async callback function to the third argument position.

63
00:04:31,070 --> 00:04:37,580
Now that authentication is set up it's time to make sure that when a task is created it's associated

64
00:04:37,580 --> 00:04:39,980
with the person who is authenticated.

65
00:04:40,070 --> 00:04:43,550
That means we're gonna be altering how we provide the data.

66
00:04:43,550 --> 00:04:49,400
Right here I'm actually going to comment out this line and leave it in place so we can compare and contrast

67
00:04:49,460 --> 00:04:51,140
the two solutions.

68
00:04:51,140 --> 00:04:54,080
Now the new one is going to start off much the same way.

69
00:04:54,200 --> 00:05:01,070
We can still create a constant called task and we still use the new operator with the task constructor

70
00:05:01,070 --> 00:05:08,150
function though instead of just specifying request dot body we're going to provide our own object right

71
00:05:08,150 --> 00:05:08,900
here.

72
00:05:08,900 --> 00:05:15,070
We want all of the stuff from request dot body with the addition of an owner property.

73
00:05:15,290 --> 00:05:18,800
So to do that I'll start by using the iOS 6 spread.

74
00:05:18,800 --> 00:05:26,840
Operator with request dot body that's going to copy all of the properties from body over to this object.

75
00:05:26,840 --> 00:05:32,960
So that would copy over the description for the task as well as optionally the completed value if it's

76
00:05:33,090 --> 00:05:38,160
provided then right here we're going to hard code in the owner.

77
00:05:38,240 --> 00:05:42,680
The owner is not something that should be specified via the request.

78
00:05:42,700 --> 00:05:49,670
There is no need to pass the owner I.D. along with the data you send as part of the request body.

79
00:05:49,670 --> 00:05:58,300
It's all from the authentication token right here owner is gonna have its value fetched from request

80
00:05:58,710 --> 00:06:04,470
that user dot underscore I.D. the person that we just authenticated.

81
00:06:04,540 --> 00:06:10,660
So with this in place when new tasks get created we're not just taking in the body data and saving that

82
00:06:10,900 --> 00:06:15,400
we're adding on the owner property to actually create that association.

83
00:06:15,670 --> 00:06:22,180
Now that we have this in place we can remove the old solution we can save the task router and we can

84
00:06:22,180 --> 00:06:30,300
test things out to make sure that this endpoint is working as expected let's head over to postmen and

85
00:06:30,300 --> 00:06:31,320
get that done.

86
00:06:31,350 --> 00:06:37,770
So over here we already have a user created and since we created the authentication token was automatically

87
00:06:37,800 --> 00:06:39,470
set up for us.

88
00:06:39,480 --> 00:06:43,050
We're going to move over to the create task request.

89
00:06:43,050 --> 00:06:45,470
Now there's no need to change anything here.

90
00:06:45,480 --> 00:06:51,420
We're still passing in the necessary data and the you are L is fine but now that it's using authentication

91
00:06:51,630 --> 00:06:56,250
it will be associated with a specific user the one who's authenticated.

92
00:06:56,280 --> 00:07:01,700
I'm going to go ahead and fire off the create task request exactly as it existed before.

93
00:07:01,830 --> 00:07:07,860
And down below we get a two a one we can see the stuff we had before with our task and also the new

94
00:07:07,860 --> 00:07:08,960
field owner.

95
00:07:09,030 --> 00:07:15,630
And right there we're getting the object I.D. of the user who was authenticated.

96
00:07:15,630 --> 00:07:20,560
This is going to be the piece of data that links tasks to their owner.

97
00:07:20,640 --> 00:07:26,220
And we're going to use that to make sure that someone can actually read a given task that they can update

98
00:07:26,220 --> 00:07:29,880
a given task and that they can delete a given task.

99
00:07:29,880 --> 00:07:36,120
If I'm trying to delete a task I need to be able to confirm on the server that I'm the one who created

100
00:07:36,120 --> 00:07:36,760
it.

101
00:07:36,840 --> 00:07:41,910
Now that we have the basics in place I want to mess around with some more advanced ways we can work

102
00:07:41,940 --> 00:07:43,710
with this relationship.

103
00:07:43,710 --> 00:07:50,190
So let's go ahead and do just that by heading over to index dot J S what we're gonna do is write just

104
00:07:50,190 --> 00:07:55,920
a little bit of code down below to mess around with a couple of the features that we now have access

105
00:07:55,920 --> 00:07:56,530
to.

106
00:07:56,610 --> 00:08:02,520
And once we understand how these work we can integrate them into the task router to finish off those

107
00:08:02,520 --> 00:08:03,650
other end points.

108
00:08:03,690 --> 00:08:07,780
The first thing I'm going to do is load in the task model which we will be using.

109
00:08:07,830 --> 00:08:11,500
So const task equals I will require it.

110
00:08:11,580 --> 00:08:16,430
That is dot forward slash models of forward slash task.

111
00:08:16,530 --> 00:08:22,660
And once we have that in place we'll set up a example asynchronous function for this little demonstration.

112
00:08:22,950 --> 00:08:25,490
It's not something that will live in our app long term.

113
00:08:25,590 --> 00:08:31,200
I can call it Main and we'll set it up as an async aero function just so we can take advantage of the

114
00:08:31,230 --> 00:08:37,980
async await syntax and then down below we'll go ahead and just call it inside of here what we're going

115
00:08:37,980 --> 00:08:43,110
to do is find our task by its I.D. the one that we just created.

116
00:08:43,110 --> 00:08:46,950
Now I have the idea of the task right here so let's grab that.

117
00:08:47,010 --> 00:08:54,090
Make sure you don't accidentally grab the owner I.D. We want the task I.D. not the user I.D. then from

118
00:08:54,090 --> 00:08:56,330
Maine we're gonna go ahead and find it.

119
00:08:56,340 --> 00:09:06,290
So right here const task equals I'll use a weight with methods we've used before task dot find by I.D.

120
00:09:06,600 --> 00:09:10,980
and I will provide that I.D. as the first and only argument.

121
00:09:10,980 --> 00:09:14,670
Now we should have access to the task and down below.

122
00:09:14,670 --> 00:09:22,020
We're going to go ahead and print it right here console down log dumping task to the terminal.

123
00:09:22,020 --> 00:09:26,790
Now to get this code to run all I have to do is save the file and down below what do we see.

124
00:09:26,790 --> 00:09:33,560
We see our task showing up and I'm going to go ahead and print out the owner property specifically.

125
00:09:33,570 --> 00:09:39,830
So right here that's going to be task dot owner when we do that like we saw before.

126
00:09:39,870 --> 00:09:40,560
What do we get.

127
00:09:40,590 --> 00:09:43,470
We get that object I.D. printing.

128
00:09:43,470 --> 00:09:46,760
Now what if we wanted more than just the idea of the user.

129
00:09:46,770 --> 00:09:51,000
What if I wanted the name of the user who created it to do that.

130
00:09:51,000 --> 00:09:57,430
I would have to grab task dot owner and fire off another query down below to try to fetch that user.

131
00:09:57,540 --> 00:10:03,770
And it would be a manual process where I search for a user by their I.D. and the value I use to search

132
00:10:03,780 --> 00:10:07,030
is this one right here with mongoose.

133
00:10:07,050 --> 00:10:11,820
There's a way to actually set up the relationship between our two bottles and it's gonna provide us

134
00:10:11,850 --> 00:10:18,060
with some helper functions that will make this possible with very minimal code so to explore this what

135
00:10:18,060 --> 00:10:24,960
we're going to do is continue to build off of the owner field over on the task model.

136
00:10:24,960 --> 00:10:27,780
We're going to set up one additional property.

137
00:10:27,780 --> 00:10:30,900
This right here is known as Wrath.

138
00:10:30,990 --> 00:10:37,800
It allows us to create a ref which is short for reference from this field to another model.

139
00:10:37,950 --> 00:10:42,390
And in that case it would be a reference to the following a user.

140
00:10:42,390 --> 00:10:49,020
So right here inside of quotes I've typed out the model name exactly as we had typed it out in the file

141
00:10:49,050 --> 00:10:49,830
below.

142
00:10:49,830 --> 00:10:57,190
Over in the user model down near the bottom right here we typed capital you user as the model name.

143
00:10:57,300 --> 00:11:03,860
That is the exact same one I'm using over inside of the tasks model to create that relationship.

144
00:11:04,110 --> 00:11:10,770
Now that we have this in place we can easily fetch the entire user profile whenever we have access to

145
00:11:10,770 --> 00:11:12,550
an individual task.

146
00:11:12,650 --> 00:11:19,530
So over going to do is add a single line of code right here in between our two existing statements.

147
00:11:19,530 --> 00:11:26,520
This one is going to take owner and convert it from being the idea of the owner to being the entire

148
00:11:26,580 --> 00:11:28,680
profile of that owner.

149
00:11:28,680 --> 00:11:30,450
Now we do that with the following.

150
00:11:30,450 --> 00:11:31,350
It's asynchronous.

151
00:11:31,350 --> 00:11:34,790
So we'll use a wait and it's available on task.

152
00:11:35,250 --> 00:11:37,560
It's called populate populate.

153
00:11:37,590 --> 00:11:44,400
Allows us to populate data from a relationship such as the data we have right here for owner we pass

154
00:11:44,430 --> 00:11:47,250
to populate the thing we're trying to populate.

155
00:11:47,340 --> 00:11:49,700
In this case we want to populate the owner.

156
00:11:49,830 --> 00:11:55,230
We want to bring it from being just an I.D. to being the entire profile.

157
00:11:55,290 --> 00:11:57,620
Next up to actually fire this off.

158
00:11:57,620 --> 00:12:01,770
We use the following e x E C populate.

159
00:12:01,800 --> 00:12:04,580
So what exactly is this line going to do.

160
00:12:04,590 --> 00:12:11,130
It's going to go off and it's going to find the user who's associated with this task and task that owner

161
00:12:11,310 --> 00:12:17,070
will now be their profile the entire document as opposed to just being the I.D..

162
00:12:17,160 --> 00:12:23,610
So since the last time we ran the program we added two lines we added this line right here in the task

163
00:12:23,610 --> 00:12:26,880
model and we added this line right here.

164
00:12:26,880 --> 00:12:30,870
Let's go ahead and save the program and see what we get down below.

165
00:12:30,870 --> 00:12:35,840
Instead of getting what we had before the I.D. I'm now getting an object.

166
00:12:35,850 --> 00:12:38,210
This is the user document.

167
00:12:38,280 --> 00:12:42,030
This is the user that created that task.

168
00:12:42,030 --> 00:12:49,020
So now we have a relationship between tasks and users and we can actually use populate to figure out

169
00:12:49,200 --> 00:12:54,690
which user created which task or which tasks a user owns.

170
00:12:54,720 --> 00:12:57,120
So let's go ahead and reverse this direction.

171
00:12:57,120 --> 00:13:00,060
We've taken a task and we found the user.

172
00:13:00,150 --> 00:13:04,350
Let's go ahead and start with a user and find their tasks.

173
00:13:04,350 --> 00:13:09,840
Now to do this I'm going to start by commenting out these three lines I'll leave them in place as a

174
00:13:09,840 --> 00:13:15,180
reference but we're going to work on this second little project and we'll start by trying to find a

175
00:13:15,180 --> 00:13:16,790
user by their I.D..

176
00:13:17,430 --> 00:13:21,450
Now over inside of postman four that create task request.

177
00:13:21,480 --> 00:13:23,530
We had the idea of the owner.

178
00:13:23,610 --> 00:13:28,030
I'm going to grab that I.D. and bring that over to visual studio code.

179
00:13:28,170 --> 00:13:30,450
And that's what I'll use to start with.

180
00:13:30,450 --> 00:13:32,870
Now we will need access to the user model.

181
00:13:32,880 --> 00:13:39,720
So right here I'll load that in concert capital you user and we'll use require it to load it in dot

182
00:13:39,720 --> 00:13:49,390
forward slash models forward slash user next up down below we'll use find my I.D. with the user so const

183
00:13:49,450 --> 00:13:59,310
user equals right here we're going to use a wait with user dot find by I.D. which we've used before.

184
00:13:59,320 --> 00:14:07,690
We'll provide our I.D. and then we'll go ahead and print out the tasks property on user right here that's

185
00:14:07,690 --> 00:14:12,480
gonna be console dot log user dot tasks.

186
00:14:12,520 --> 00:14:14,610
Now this does not exist.

187
00:14:14,620 --> 00:14:22,870
Users do not have tasks on that document and down below we see that is true because we're getting undefined

188
00:14:23,020 --> 00:14:24,040
printing.

189
00:14:24,040 --> 00:14:31,120
Just like we fixed that for tasks we're gonna go ahead and adjust that in the other direction for users.

190
00:14:31,120 --> 00:14:32,860
Now what's this going to look like.

191
00:14:32,860 --> 00:14:39,730
Well what we're not going to do is actually create a tasks array on the User model so up above for example

192
00:14:39,910 --> 00:14:43,540
we do create a tokens array to store those tokens.

193
00:14:43,540 --> 00:14:48,540
We're not going to do the same thing for tasks the tasks live in a separate collection.

194
00:14:48,610 --> 00:14:55,720
Instead what we're going to do is set up what's known as a virtual property a virtual property is not

195
00:14:55,750 --> 00:14:58,470
actual data stored in the database.

196
00:14:58,540 --> 00:15:01,300
It's a relationship between two entities.

197
00:15:01,300 --> 00:15:07,760
In this case between our user and our task to start off we'll be using something on user schema.

198
00:15:07,810 --> 00:15:12,800
It is called the virtual and it allows us to set up one of these virtual actual Buttes.

199
00:15:12,820 --> 00:15:18,730
Now it's virtual because we're not actually changing what we store for the user document it is just

200
00:15:18,730 --> 00:15:23,320
a way for a mongoose to figure out how these two things are related.

201
00:15:23,320 --> 00:15:25,810
Right here we pass to it two arguments.

202
00:15:25,810 --> 00:15:31,870
The first is the name for our virtual field we could pick anything we wanted but something like tasks

203
00:15:31,930 --> 00:15:33,130
seems appropriate.

204
00:15:33,130 --> 00:15:39,040
You could use my tasks or users tasks and then we're going to set up an object.

205
00:15:39,070 --> 00:15:45,340
And in here we're going to configure the individual field we're going to start by setting up ref like

206
00:15:45,340 --> 00:15:50,860
we did for the task model and we're going to set this one equal to task.

207
00:15:51,100 --> 00:15:57,740
So over inside of the task model we have a reference to the user on owner owner is a real field.

208
00:15:57,760 --> 00:15:59,870
It is stored in the database.

209
00:15:59,950 --> 00:16:04,780
Over here we have a reference between the user and the task on a virtual.

210
00:16:04,780 --> 00:16:06,690
This is not stored in the database.

211
00:16:06,700 --> 00:16:12,520
It is just for Mongoose to be able to figure out who owns what and how they're related.

212
00:16:12,520 --> 00:16:17,500
Now we're going to set up two other fields on this virtual to get things to work correctly.

213
00:16:17,530 --> 00:16:22,370
We have to specify the local field which will be a string.

214
00:16:22,590 --> 00:16:30,790
And we also have to specify the foreign field the foreign field is also going to be a string so the

215
00:16:30,790 --> 00:16:33,390
foreign field is the name of the field.

216
00:16:33,400 --> 00:16:39,520
On the other thing in this case on the task that's going to create this relationship and we set that

217
00:16:39,520 --> 00:16:44,780
up to be the owner of the local field is that is where that local data is stored.

218
00:16:44,800 --> 00:16:51,670
So we have the owner object I.D. on the task and that is associated with the I.D. of the user here.

219
00:16:51,730 --> 00:16:59,740
So the local field the users I.D. is a relationship between that and the task owner field which is also

220
00:16:59,890 --> 00:17:01,420
a user I.D..

221
00:17:01,600 --> 00:17:08,020
So now that we have this in place we can actually take that same code we had before use populate once

222
00:17:08,020 --> 00:17:11,710
again and get all tasks that a user created.

223
00:17:11,710 --> 00:17:16,710
So right here I'm going to save user dot and J asked the model file.

224
00:17:16,780 --> 00:17:23,140
I'm gonna head over to index dot J S and we can see that right away we're already getting a slight change.

225
00:17:23,140 --> 00:17:27,250
We went from undefined to no to actually get our real data.

226
00:17:27,250 --> 00:17:28,690
We use populate.

227
00:17:28,690 --> 00:17:33,290
So here I'm gonna use a wait I will be using populate on it.

228
00:17:33,300 --> 00:17:39,460
User and I'm going to populate the tasks that virtual field.

229
00:17:39,490 --> 00:17:44,340
Next up we're gonna go ahead and execute it by using E X E C populate.

230
00:17:44,440 --> 00:17:47,770
Exactly like we did before to make sure things run.

231
00:17:47,860 --> 00:17:54,620
And with this in place it's actually going to go off find all tasks created specifically by this user.

232
00:17:54,700 --> 00:18:01,230
And it will store them in a real array on the user dot tasks property which means we'll get it printed.

233
00:18:01,270 --> 00:18:04,800
Now once again nothing's getting changed about the user document.

234
00:18:04,810 --> 00:18:07,360
It's not actually stored in the database.

235
00:18:07,360 --> 00:18:09,910
It's a virtual right here.

236
00:18:09,930 --> 00:18:11,950
I've run the program down below.

237
00:18:11,950 --> 00:18:16,270
I get the one task that I find which is fantastic.

238
00:18:16,270 --> 00:18:22,360
Now over inside of postmen we could create an additional task so up above I'll change the description

239
00:18:22,360 --> 00:18:23,910
to something else.

240
00:18:24,100 --> 00:18:30,160
Go to office something I'll be doing really shortly here after I'm done filming this video.

241
00:18:30,250 --> 00:18:34,960
I'll go ahead and send that off and down below I can see it was created.

242
00:18:35,080 --> 00:18:41,650
I can go ahead and rerun the script by just saving index dot J S and down below I can now see that two

243
00:18:41,650 --> 00:18:45,640
tasks are showing up when I print that tasks array.

244
00:18:45,640 --> 00:18:46,530
So there we go.

245
00:18:46,540 --> 00:18:50,090
We now have a relationship between tasks and users.

246
00:18:50,200 --> 00:18:51,760
And that's gonna be really important.

247
00:18:51,760 --> 00:18:56,050
We're working with task data as we complete the rest of those end points.

248
00:18:56,050 --> 00:19:02,140
Now the topic of virtual walls and populate is one of the more confusing Mongoose topics I don't expect

249
00:19:02,140 --> 00:19:04,290
this to all be clear just yet.

250
00:19:04,300 --> 00:19:10,450
That's why I wanted to do things in a little playground area before actually using them inside of the

251
00:19:10,450 --> 00:19:11,780
task routes.

252
00:19:11,800 --> 00:19:16,720
We'll get more experience with them soon and there'll also be challenges where you'll have to use this

253
00:19:16,720 --> 00:19:18,100
stuff on your own.

254
00:19:18,100 --> 00:19:19,850
I'm really excited to get to that.

255
00:19:19,870 --> 00:19:22,150
So let's go ahead and jump in to the next one.