Original subtitles

1 1

Now, before we write a single line of code, 2

2

we first need to plan this project, 3

3

because this one is a little bit more complex 4

4

than the other projects that we have been building. 5

5

So until now we have always simply started to code, 6

6

but without much thought about the features, 7

7

or the architecture before writing 8

8

the implementation itself. 9

9

I mean, we actually did use a flowchart a couple of times, 10

10

but I always simply provided that flow chart, 11

11

and we never did it together. 12

12

So we never planned an application together. 13

13

So in the real world, it's very important 14

14

that you always start with a planning phase 15

15

before building any project, 16

16

because otherwise you're setting yourself up 17

17

to a lot of confusion and problems down the road. 18

18

So to avoid all that, we will now do the planning 19

19

of the Mapty project together. 20

20

And so then you will get a feeling of how it works. 21

21

Now, there are many different ways of planning a project, 22

22

but I'm gonna show you my favorite process here, 23

23

which works great for many small and medium sized projects. 24

24

So I always like to start out 25

25

with a concept called User Stories. 26

26

And many companies, and teams use this idea 27

27

of user stories. 28

28

So you will see this everywhere when you start working 29

29

on a real developer job. 30

30

So a user story is basically a description 31

31

of the application's functionality 32

32

from the user's perspective. 33

33

And then all the user stories put together 34

34

will clearly describe the functionality 35

35

of the entire application. 36

36

So user stories are basically a high level overview 37

37

of the whole application, which will allow us developers 38

38

to determine the exact features that we need to implement 39

39

in order to make the user stories actually work as intended. 40

40

Then to visualize the different actions 41

41

that a user can take, 42

42

and how the program react to these actions, 43

43

we usually put all these features into a nice flow chart. 44

44

And again, we actually already used flow charts 45

45

in some other applications that we built before, right? 46

46

Now, once we know exactly what we're gonna build, 47

47

it's time to think about how we're gonna build it. 48

48

And this brings us to the project's architecture. 49

49

And in this context, architecture simply means 50

50

how we will organize our code, and what JavaScript features 51

51

we will use. 52

52

So the project's architecture is essentially what holds 53

53

all the code together. 54

54

It gives us a structure in which we can then develop 55

55

the application's functionality. 56

56

Now, my goal here is of course not to turn you 57

57

into a software architect. 58

58

The goal of this step is simply to stop and think about 59

59

how we will implement all this functionality. 60

60

So all these features before we actually do it. 61

61

Because we could implement any project 62

62

in a 1000 different ways. 63

63

So we could have one big file with no organization at all, 64

64

or we could divide everything into functions, 65

65

or we could use classes, or use multiple files, 66

66

or a mix of everything. 67

67

The possibilities are really endless. 68

68

So we have a lot of choice and all that choice 69

69

can sometimes be a problem. 70

70

And so if we don't think about the architecture 71

71

before writing the main part of our application, 72

72

then we will probably end up with a mess 73

73

of unmanageable spaghetti code. 74

74

And so that's not what we want. 75

75

But anyway, once we thought about 76

76

the project's architecture, 77

77

we are finally done with the planning step, 78

78

and are then ready to finally move on 79

79

to the development step. 80

80

And of course, this is where we're gonna implement 81

81

the plan that we created using JavaScript code. 82

82

So let's not plan the application that we're gonna build 83

83

in this section, 84

84

and so basically go through these four steps 85

85

of the planning step. 86

86

And we start with the user stories. 87

87

And remember a user story 88

88

is essentially a description 89

89

of the application's functionality 90

90

from the user's perspective. 91

91

And all user stories put together, 92

92

provide a clear picture 93

93

of the application's whole functionality. 94

94

Now there are multiple formats 95

95

in which we can write user stories, 96

96

but the most common one is to write sentences 97

97

with this format. 98

98

So as a certain type of user, 99

99

I want to perform a certain action so that I can get 100

100

a certain benefit. 101

101

And so this format of the user story answers the question, 102

102

who, what, and why. 103

103

Great, and so now applying this to our own Mapty project, 104

104

the first user story could go something like this. 105

105

So as a user, I want to log my running workouts 106

106

with location, distance, time, pace, and steps per minute, 107

107

so that I can keep a log of all my running. 108

108

So if we analyze the sentence, 109

109

then this clearly tells us who wants to perform 110

110

which action and why. 111

111

And then based on this, we will be able to plan 112

112

the application's necessary features in a next step. 113

113

So that as user story can basically be satisfied. 114

114

Next up, we can also say that as a user, 115

115

I want to log my cycling workouts with location, distance, 116

116

time, speed, and elevation gain, 117

117

so I can keep a log of all my cycling. 118

118

So this is similar to the first one, 119

119

but this one is regarding cycling 120

120

rather than running. 121

121

Next up as a user, I want to see all my workouts at a glance 122

122

so I can easily track my progress over time. 123

123

Then as a user, I also want to see all my workouts 124

124

on a map so I can easily check where I work out the most. 125

125

And finally, the last user story, which makes sense 126

126

for this application is that as a user, 127

127

I want to see all my workouts when I leave the app, 128

128

and come back later, 129

129

so that I can keep using the app over time. 130

130

Now, of course, we could have written these stories 131

131

in a different way, and certainly different people 132

132

will come up with different user stories 133

133

for the same application. 134

134

But what matters is that we can use user stories 135

135

to describe exactly what the application will do. 136

136

And I think that these user stories 137

137

do a pretty good job on that. 138

138

Now in this project, I actually already showed you 139

139

the working application in the last video, right? 140

140

But of course in the real world, you will be building 141

141

the application from scratch on your own. 142

142

And so therefore you will really have to think 143

143

as if you were the user and put yourself 144

144

in the user's feet so that you can come up 145

145

with these user stories, 146

146

and then build your features from there. 147

147

So let's not actually think about the features. 148

148

So here on the left side, we have a more boiled down version 149

149

of the user stories so that we can now work 150

150

on the features that the application should have, 151

151

and again, that is based on the user stories. 152

152

And based on this first user story, 153

153

we can already imagine a couple of features 154

154

that our application is gonna need. 155

155

So first we're gonna need a map where the user 156

156

can click in order to add a new workout. 157

157

That's because the user wants to log the workout 158

158

with the location. 159

159

And so therefore the best way 160

160

to get the location coordinates is gonna be 161

161

just clicking on a map. 162

162

Next, since we are working with maps, we should probably use 163

163

geolocation in order to display the map 164

164

at the current location of the user, 165

165

because this is a lot more user friendly than having 166

166

the user scroll to their current position, right? 167

167

So this is a perfect use case for geolocation, 168

168

and since all browsers on mobile and desktop 169

169

now support geolocation this will be a great addition 170

170

to our application. 171

171

Then of course, we're also gonna need a form 172

172

to input the rest of the data. 173

173

So the distance, the time, pace, and the steps per minute, 174

174

which is also called cadence. 175

175

So from the first user story alone 176

176

we could already know that we need these three features. 177

177

I mean, we don't really need them, 178

178

but they are nice to have because they allow us 179

179

to satisfy the user story. 180

180

And so let's now take a look at the second user story. 181

181

And so for this one, we're gonna need a form 182

182

that is very similar to the first one, 183

183

but this one has to ask for the elevation gain 184

184

instead of the steps per minute. 185

185

Then the user wants to see all the workouts at a glance, 186

186

and so therefore we're basically just gonna have a list 187

187

with all these workouts. 188

188

Then the user also wants to see them on a map, 189

189

and so therefore we will have a feature 190

190

basically displaying all the workouts on the map as well. 191

191

And lastly, the last user story basically says 192

192

that the workouts should of course persist over time. 193

193

And so there are multiple ways of doing that. 194

194

And so usually in a real world application, 195

195

you will have accounts where people's data then get stored. 196

196

But in this case here, since we are just building 197

197

a very simple application, all we're gonna do 198

198

is to store the workout data right in the browser. 199

199

And for that, we're gonna use a browser API 200

200

called local storage. 201

201

Then whenever the user comes back to the page, 202

202

we will read the data that was saved in a local storage, 203

203

and then display it both on the map, 204

204

and also on the list, okay? 205

205

And so these are the features 206

206

that we will have to implement, 207

207

and so let's now put them in our flow chart. 208

208

Now the flow chart should of course 209

209

contain these different features 210

210

that we're gonna implement, 211

211

but it's also gonna contain how the different parts 212

212

of the app interact with each other, 213

213

which event makes sense to implement, 214

214

and also how data flows across the application. 215

215

So let's now see the first couple of features 216

216

that we need to implement, 217

217

and that is geolocation to display the map 218

218

at the user's location, 219

219

and then to also display a map where the user can click 220

220

to add new workouts. 221

221

And this is how we could put them on the flow chart, 222

222

but let's actually think together about why 223

223

we put them like this on the flow chart. 224

224

So whenever we start to build a flow chart like this, 225

225

it's a good idea to start with events. 226

226

And so here in this case, I'm starting with the event 227

227

of the page loading, basically. 228

228

And so that's always a good event to start 229

229

the flow charts because of course that's always 230

230

the first event that basically occurs on any page. 231

231

I mean, it's not an event that we're gonna handle, 232

232

but as you know, all the code that is in the top level 233

233

will essentially be executed when the page loads. 234

234

And so we can count the page load as an event here as well. 235

235

So when the page does load, we want to start 236

236

by getting the user's location coordinates 237

237

using the geolocation API. 238

238

So just like we decided on in the last slide, right? 239

239

Then after that data arrives, 240

240

we want to then render the map basically centered 241

241

on the current location of the user. 242

242

Then we also already saw in the last slide that we need 243

243

a form to input the data for cycling and for running. 244

244

So we're gonna need to display a form, 245

245

and basically we will display that form, 246

246

or render that form whenever the user clicks 247

247

on a certain position on a map. 248

248

So here in this flow chart, as you see the yellow parts 249

249

are the actions, and the green parts is basically 250

250

when we render something on the user interface, 251

251

and in red I have marked operations 252

252

that happen asynchronously. 253

253

And what that means we will see in the next video. 254

254

Now, if the way that I'm building this flow chart here 255

255

is still confusing to you, then don't worry. 256

256

So in the future with more and more practice, 257

257

you will, of course be able to come up 258

258

with a flow chart like this on your own. 259

259

So just like everything in coding and programming, 260

260

this really is a matter of practice. 261

261

Now, just know that in the real world, 262

262

we usually don't always come up with all the steps 263

263

in the flow chart right in the planning phase. 264

264

So it's perfectly okay to just create a rough sketch 265

265

in the beginning here and then come up 266

266

with the exact detail during the implementation. 267

267

So definitely don't get hang up on building 268

268

the perfect flow chart, all right? 269

269

That's just not really necessary 270

270

in the beginning, 271

271

and so you should not waste too much time on this. 272

272

As you become better with practice, this will become easier, 273

273

and then you might be able to add more and more details 274

274

to your flow charts, right at the beginning. 275

275

But when you're just starting out and working 276

276

on your first applications, then don't stress 277

277

too much on this. 278

278

All right, but anyway, let's continue 279

279

with our features here. 280

280

So next up we want to display workouts in a list 281

281

and on the map. 282

282

And so therefore this is what our flow chart 283

283

is gonna look like. 284

284

So basically we rendered the form in step three and four, 285

285

and then we're going to have an event listener 286

286

on that form. 287

287

And so then whenever the user submits in your workout, 288

288

it is gonna be rendered on the map and on the list, 289

289

in steps five and six. 290

290

Then remember we want to store this workout data 291

291

in the browser and then read that data 292

292

whenever the page reloads. 293

293

And so what's gonna happen here 294

294

is that also whenever a user creates a new workout, 295

295

it will store all the workouts in local storage. 296

296

So we're using that local storage API in the browser 297

297

that I just mentioned in the last slide. 298

298

Then whenever the page loads, 299

299

as we see here on the left side of the flow chart, 300

300

then we get all of the workouts from local storage, 301

301

and render them on the map and on the list. 302

302

And of course that can only happen 303

303

after the current location has been fetched, 304

304

and a map has been displayed. 305

305

And so that's essentially what async means. 306

306

So that red box up there means that it is an operation 307

307

that takes some time, and only after it's completed, 308

308

then the rest of the operations that depend on it 309

309

can be executed. 310

310

And finally, there is another feature 311

311

that I didn't mention in the last slide, 312

312

but with just a nice addition 313

313

to the way the application works. 314

314

And so that is to simply move the map 315

315

to the workout location, 316

316

whenever we click on one on the workouts in the list. 317

317

And so here in the flowchart, 318

318

that is also pretty easy to represent. 319

319

And so basically all we need is an event handler 320

320

on the list. 321

321

And then whenever the user clicks on a workout in the list, 322

322

it will move to that workout's location, all right? 323

323

And so this is essentially how our application 324

324

is gonna work. 325

325

And so the features that we need to implement 326

326

using this flow and this sequence basically. 327

327

Now keep in mind that this flow chart itself 328

328

actually has nothing to do yet, 329

329

with the implementation itself. 330

330

So this is just how the program is gonna work. 331

331

And we might very well implemented in some other language, 332

332

so it wouldn't even have to be JavaScript. 333

333

So essentially this is only what our program should do, 334

334

but not how it does it. 335

335

So that's more specific and that's actually 336

336

for the architecture. 337

337

And so that brings us to the last part 338

338

of this planning step, which is, in fact, architecture. 339

339

Now just like the flow chart, we don't always need to have 340

340

the perfect final architecture 341

341

figured out before implementation. 342

342

So we can first do some experiments, 343

343

play around with the code, and only then, 344

344

think about the architecture for the final project in case. 345

345

Of course we can do it right in the beginning, 346

346

but it's not always necessary. 347

347

And so to start this project, 348

348

we will actually simply start coding, 349

349

and starting to implement the features 350

350

according to the flow chart that we just developed. 351

351

Then as we start to need more organization, 352

352

and ways to manage our data, 353

353

we will come back to thinking about the architecture. 354

354

Now, right, and so actually let's now go do that.