Transcript
Use with ChatGPT / Claude Auto-scroll A
Recaps last lecture’s code coverage and exception handling, then revisits why requirement engineering matters. It introduces functional versus non-functional requirements with simple examples before transitioning into authentication.
Speaker A
It.
Sa.
We're gonna cover maybe few topics.So I hope that one hour would be enough for me.Well, it's gonna be one hour ish, then a break.Then as I said, one of the admin team will talk about the second iteration.And part of the second iteration is you need to do some requirement analysis.So I'm going to talk a little bit about that.But before that I'm going to do as usual, quickly talk about what we saw in the last lecture.Then I'll jump into authentication.So as I mentioned last time, so we need to talk about the.One of the basic security aspects in software engineering, which is authentication and authorization.
Then we do some requirement analysis, like requirement and design.
Yeah.So let's start quickly.What we saw last week is last lecture, I should say code coverage.We already saw that, but we saw it in a different setup, which is the client, the HTTP protocol, which is the client server architecture.Right.
Then we said that if we use C8, what's going to happen is it's going to cover what lines of code on the server side.Right.
So that's what we said.So it's like exactly the same thing as what we saw in code coverage, but we added this C8 mini engine, if I can say that, to just check the runtime of the lines of code from the server side, not from the client side.You invoke from the client side, but the coverage is from the server side when the code on the server side is running.So it shows you the coverage from that side.What else in exceptions we talked a little bit about what like we have.
Usually we have.How can I put it like in a very short statement.So in exceptions we have usually encoding.We have two parts.One part is.
I just use plain English term.Mainstream.Mainstream.And sometimes we have exceptions.Unexpected cases, expected cases are the mainstream.Unexpected cases are the exceptions.Example of that is we use the grades example.So we have from 0 to 100.Any value less than 0 or more than 100 is an exception.Because.
Because it's not part of the grades that we.That you usually get.Right.Then how to handle that?So we saw that it has to be.
What do you say?
I forgot the abbreviation.Better.Better.Sorry, can you remind me of the abbreviations?
Ask permission better.
Anyways, can you check the slides and remind me asking for forgiveness is better than permission.So that's the one.And the other one is check before you leap.So these are the two principles.So the first one is not smooth, it's just like it exits and Keeps you safe.And it asks that.Like the code asks for forgiveness, the second one.So for the sake of this mind map in here, so I'm going to just write forgiveness, asking for forgiveness.
And the other one is check before you leap.Okay?Which means check before you leap, meaning try.The system tolerates that they keep giving input until they give the right one.However, this does not work in all cases.
Example of that is what we're going to see today in authentication and authorization.So you cannot allow someone like for cybersecurity measures, you cannot allow someone to give multiple login attempts.Right?So this is handling exception, but it's not.You cannot handle it 100% in a smooth way.You have to consider other measures.
Then we talked about requirement engineering.So for requirement engineering, what did we say?So what did we say?Can you remind me of briefly what we talked about?We talked about two things, actually.
Introduction or definition.Why do we need the.Why?Why do we need requirement engineering?
And then we talked about FR and fr.Okay, so we're going to unfold this.So why do we need requirement engineering?Briefly, one or two statements to answer this question.Just quick recap of what we saw last time.
Why do we need it?Sorry, Complete coverage of what.
Part of it is.Yeah, part of it is to have a good result of your testing.So I'm going to reverse engineer your answer.So you cannot do testing without knowing what you were looking for.And you were trying to develop something to fulfill what you were looking for, right?
Yeah.So you figure out the problem, you solve it, then you test it.So that's the reverse engineering of what you were saying.Right.So you figure out the problem as a software engineering team from stakeholders, users.
Then you solve it, you develop your software, then you test it.Right.So in requirement engineering, what we do, usually we look at figuring out the problem and how to test the solution.
I need your attention here.So you figure out the problem, you solve it, you test it.So in requirement engineering, you like, first thing, figure out the problem, then try to come up with some rules or measures to test it later after developing the solution.Okay, so it's two parts.First part is here, defining the problem.And second part, you do it during the requirement analysis when.And you will be actually, yeah, you.You do it, you define the rules, then you use them in the testing phase.I think that's full reverse engineering of your answer.Unfolding all what we need.
So that's why we need requirement engineering.So defining the problem so we can solve it and test it.Then what's digging deeper now in defining the problem?In defining the problem.Usually we have two major parts.So the first part is the functional requirements and the second part is the non functional requirement.I gave an example, I'm not sure if it makes sense to all of you or some of you which is the doctor example.So I need to go to a doctor.So that's a functional requirement.Then the non functional requirement is I choose like I have, well I have maybe headache or flu or something.I need to see a doctor.So my requirement is I need to see a doctor.Then I have like in say Kensington here four or five doctors.So I need to choose among them.The non functional requirement is maybe I need to do it fast because I need to prepare for exams.
So I have to see them and do something about my flu.So that's like fast.The appointment is available the same day.So that's a non functional requirement that this doctor fulfills for me.But the doctor fulfills the function requirement seeing them.
But the non functional requirement is same day available, same day cheaper.Maybe I'm student, I don't have insurance, something like that.So you define these non functional requirements.It allows you to choose among these doctors.
Then I think the last slide where we stopped at is the non function requirements.We have three major types.Can you remind me of them?
Link to the product and link to organizations and external extension Example is manufacturing cars, self driving cars.There's a software part in manufacturing cars, right?So the product non function requirements for the product.I need a car, so that's function requirement.Let's just keep it this vague way.
Non function requirement is this car should be comfy, comfortable, fast, something like that.Maybe in terms of fuel.So it should be efficient in terms of fuel.So these are non functional requirements related to the product.Another non functional requirements related to the organization say that you have your own SME small business and you have a fleet of your cars and in your organization you are required to fulfill some environmental regulations.
So you need to get cars like that are maybe electric or something like environment friendly that's imposed by your organization.Another non function requirement is the external line like manufacturing cars.So goes to the manufacturer and manufacturer vendor.Then you get it like buyer.
So you have your requirements that are imposed from a third party, external party which is maybe you are in Australia.So the government of Australia or the government of NSW they have, they impose some regulations regarding environment.Again so these are non functional requirements that you need to fulfill as a manufacturer or vendors selling your cars.To this state or to this country.So this is an example, like intuitive, straightforward example about FR and nfr, like function requirements and non function requirements.
Explains authentication and authorization, then walks through registration and login workflows. The speaker covers password hashing, salts and peppers, and the need for HTTPS to protect credentials in transit.
Speaker A
So what I'm going to do now, so done with this briefing, I will go to auth.Let's talk about.
Auth.So that's what we're going to see now for the sake of time, I will just explain the concept.Like it's a bit of.It's a mini cybersec lecture today.So I'm going to just talk about this Authentication and authorization.
That's our outline.What's authentication?How to store credentials.Then of course we are all familiar with the workflow register login.Then how to handle passwords in your software, how to secure.
Yeah, so I have a few questions here, so maybe we'll have some.
I have some questions for you.So I'll see how you think about the cybersecurity, despite the fact that it's not cyberseclass.Now, first thing, so what's authentication?What's authorization?
Reading these definitions here, Authentication is.I'm not asking questions because just I'm trying to like move forward.Authentication here is who is allowed to use, slash, access the system Authorization.Once you are allowed to access or use the system, what are the permissions or the functionalities that you are allowed to perform in that system?Authorization is who is allowed.
Sorry, authentication is who is allowed.Authorization is what are the operations or functionalities that you are allowed to perform once you are in.Okay, authentication then authorization.
Okay, so you are all familiar with that concept now.Registration workflow and login workflow.So in order to register, what you should do, you don't have an account, you create an account.You don't have an account, you create an account, then you log in.We all know that.
Now as a software developer, you need to prepare this workflow in your software so people can register and log in.They provide you with their email, like their credentials, their email and password.So what you do in the registration workflow, you check whether they are already there or not.If they are already there, so they cannot register, they just log in, they are not.So you create an account for them and you store their credentials.
That's the naive way to do it, right?That's registration login is easier than that.So they just provide you with their credentials and you check whether they are stored in your database or not.Easy, right?So you compare, you fetch them, you find them so they are allowed to enter.
Okay, so this is a code I provided you with.The code actually you can Access that and GitLab, I think 7.3 or 7.4 auth.Now this workflow that I just talked about, this is a simplified implementation of it.What's wrong with it?
Speaker B
There's already the credentials and data object.
So that's just on a system.
Speaker A
Yeah.So in this simplified example here, it's local.Yeah, it's just local.And in reality it has to be on a server.On a distant server.Right.So saying that, like you just said that, what's wrong with this code given that it's an implementation on a distance server.
Sorry.
So the, so the security issue, even if it's just locally, it's easier, it's easier for attackers to find the emails and passwords once they have access to your data.Right.Data object, as you just said.And this risk increases if it's in a distant server and it's plain text, as you said.So what should we do now?
How should we hash it?
So we need to hide the password and you just like said the answer.It's hash it.So what do you mean by hashing Here, thanks to math and we got this concept of hashing,
Speaker B
we use popular hash functions like SHA256 or 512 and what it does is it takes a spring password and it takes each character of it and converts it into using its mathematical function to a series of characters that correspond to every single character.
Speaker A
So you take that, that's a password.
And this hash in as you just said, SHA function, it gives you a series of unreadable characters.Right.That's good.That's 70, 75% of the answer.So what's special about hashing?
It's a one way function.Yeah, one way function.So why did you choose this concept of or principle of one way function?In hashing
Speaker B
you have an encryption key so they can be encrypted back to.
Speaker A
Yeah.So for the encryption.So we're going to see that later, it's two way street.So you can encrypt and decrypt.We will see where to use that.
But for hashing it's just one way function.So what to do is you hash that password and this is this slide and what we are talking about is an answer for question is what's the best way to secure passwords?
We can brainstorm, we can spend five minutes, I don't have this lecture today.But the answer, the best answer is not to store it.As simple as that, not to have passwords in your database or in your software.Now how to do that.How to implement this answer?
Not to store passwords.Thanks to mathematicians, we got this hashing principle.We take the password, we hash it and we store the hashing.So what happens?We are not storing the password, we are storing the hashed password.
Now how can we verify that when you give me your credentials that your password is correct or not.
Sorry.
As long as they are encrypted in the same encryption method.Encrypted or hashed?Hashed.So you take the password that I just give.Sorry.So this is explained in hashing.So we might get back to that.Now is this your answer?
That's what you were saying.So what's happening here in the registration workflow?So we.Well, we don't need the registration workflow.We just talked about it.So we don't store the password.The principle is not to store it.Store just its hash.So in the login, how can we verify.That's the new.
The new problem that we got.So what we do is once you just from the front end, you give your password, we retrieve your hash.So we get the hash and compare it with the database, like the back end.So we get from the front end your password, not your password, the hash of your password and compare it with the stored hash in the backend in our database.Stored, stored hash of your password that we got during the registration.
Here.This is safer, Much, much safer.But is it enough?
Is it enough?
Sorry,
Speaker B
does it say that we're storing the hash as well?
Speaker A
Which one?
Speaker B
Slide that said.What do we do?
Speaker A
This one?
Speaker B
Yeah,
Speaker A
Yeah.Here, Store number four.Like in the registration, store the email and the hash of the password.So that's in the registration.Once you provide your password, I hash it and I just store the hash then in.
Yeah.No password.Right.So it's some magic.It works.It's much, much, much safer than the plain text.But does it have flaws here?Can you think that it has any attacks that we can.You can brute force it.Right.
So what you can do is you can generate multiple hashes and brute force them.So what should we do?Well, this is not a cybersecurity class, but just.I'm going to give you some hints.Sorry, sorry.
Can you come.Two factor authentication.Yeah.So that complicates things.That's true, actually.That's the ultimate, best solution for now, but in a cybersec class.Not in this class, but a simple solution.You just like said salt.Right.So we can add the hash itself.
So what we need to do is just keep playing with math principles.So we can add salt and pepper.Okay, so salt is what you do.I think you are not required to learn about them, just I'm going to talk about them.
Speaker B
Additional random string that you
Speaker A
have.So yeah, additional, you missed one word.Additional random unique string that you add to the password, then you hash.So that's salt, pepper is after.So you add the salt, you hash.Then pepper is, I think you add, you get some public pepper for all the passwords, I think public string, random string, you add it to your salted and hashed password.So you add it afterwards.So you add the salt, you hash, then you add the pepper.So this is more secure.But still the brute force attacks might work if they get some insights like social engineering.
So they try to generate hashes, they figure out some information about the pepper, some information about the salt, and they can figure it out.So what should we do?Especially if you have a distant server and you are storing there.So I just hinted you that you have a distant server.When you store here, let's say create an Instagram account, you create your account, all of your information goes to that distance server, right?So there is a transmission here.So in the transmission there is a risk of attacks.Right?So what should we do?
Yeah, yeah, I just like jumped like, my bad.So HTTPs is secure HTTP.And what do we mean by secure HTTP?Adding an encryption layer to like in simple English words, adding an encryption layer to the HTTP communication.So what's encryption?Now you already said that it's two way street, right?So you can encrypt and decrypt.So how to use it in this context here?So you have the plain text, you add a key to it, you encrypt, you get a ciphertext.The advantage of that is when you, you know the man in the middle attack, have you heard of that?
So during the transmission, if someone gets the information while it's being transmitted, they cannot, it's unreadable, they cannot read it.So it's another layer of security.Your password is still safer once it's encrypted.But the problem is on the receiving end there, when it reaches to the server, what we should do is decrypt, right?So it reaches to the server encrypted.
So we need to decrypt it.So to get to the original information that you are looking for.And this by the way, encryption does not apply only to auth all the information that we transmit, encryption applies to that.Okay.And more particularly, and one of the important aspects is the authentication.So we need to protect the credentials of users.
And this is the answer that like you said, HTTPs.Yeah.So it's a layer of encryption on top of the.Yeah.So these slides of the code, we already provided you with that so you can find it on GitLab.
But I'd just like to show you the functions of encryption here.You create a cipher, then how to decipher it.So all of these functionalities are there if you import the crypto.Okay.
That's the summary.Encryption can be reversed.Hashes cannot.
Anything.Yeah.So here it's just hash plus salt plus pepper and another layer of security.See, we are adding layers like stacking layers on top of each other to guarantee the security and still always get new attacks.Right.
Most of the time they just revert back to trying to get the password directly.
So.Ok, I think I'm going to just say before that one thing here.It's not related to this course, but you need to be aware of it.All of what we are doing in hashing and encryption is tightly linked to the presumption that when you encrypt or you hash, it's impossible to have to decipher or go back from the hash to the original password in your lifetime.If I can say that using the machines that principles that we got for the laptops and all of the principles of computing that we know so far.
However, since I don't know, maybe 2020, I would say from 2010 onwards, what happened?Some quantum computing methods could crack all of these principles that we got.So now we are in a new era where we have to come up with new ways of hashing and encrypting and securing and it has to be quantum computing safe or proof.Okay, so this is an area, maybe you can look into that and work on it still.You can get jobs if you do that.
So it's very challenging still.It's still challenging actually.Yeah.
Introduces tokens as a way to stay logged in across requests, including expiry and refresh behavior. It also explains how tokens are transmitted in HTTP headers and how they are protected with encoding and signing.
Speaker A
Back to the course.Now we need to talk about tokens.
So tokens in the context of cybersecurity, actually not the context of LLMs and AI.Because it has a different meaning now.Well, it has different meaning that got evolved as well.But in cybersecurity the token is as simple as the following scenario.So imagine that you are going to an event, so they check your credentials, you are there, you can get in, Right.
But if you leave and come back, if you leave and come back.So it's awkward, right?Maybe they are busy with the new attendees and you cannot go back, they have to verify you again and you have to rejoin the queue.Does not make sense.So what did event planners do to solve that?
One of the obvious solutions is they give you a band wrist.They give you a band wrist that you are already logged in, if I can say that.And this band wrist has kind of barcode or something.So what happens those who are logging in or registering, like in analogy to what we are doing here and those who leave and come back so they can just scan that barcode in their band wrist and come go inside.So this principle, we have the same thing in the AUTH principles in software engineering and cybersecurity.
So once you register, you open your account and you are working, you might need to open different pages on a web, different pages on a web app or different screens on mobile app.So what is it that guarantees that you are logged in and you can go from one screen to another?That's one.And if you stop working, you leave, then you come back and you are not required to re log in.So what is it?The thing that guarantees that is that boundaries to barcode, right?That principle.So we can implement that here.And it's called tokens.So we generate tokens.
Once you log in, a token is generated for you and it has an expiry date.Say sorry about that.
An expiry date, meaning that.And this expiry date is a security measure as well.Because if I allow give you a token that never expires, so you can access that maybe somebody else will be using your phone and they can access your account.So this token expires and we have some measures.I think they are called authentication.
Aal I forgot like authentication a level.I forgot about that.So we have three levels.One of them is it's okay, since you are working just on your own thing, email, we can allow you up to 12 hours, up to 30 days, some cases.And if it's critical, it's just 30 minutes.
But it's not one token, it's token that gets automatically refreshed.Okay, now what information that we need in a token?Once you log in or register, you will have a user id.Then your role here that defines what operations that you are authorized, like role and permissions, they are linked to each other.Operations that you are authorized to do here.
Then as I was talking about just the expiry timestamp and how it does it gets refreshed.Now.
This the question here.So the tokens, they need to be communicated between the client and the server and we are not communicating them through the URL.Of course, that's obvious.It's not safe.
How should we communicate them?We cannot communicate them through the body.Why is that?I think the answer here is it's not as obvious as not communicating them through the URL.The URL is not safe, it's exposed.
But not the body.Because all of the operations that we got.What are the operations?Remind me.Get, put, the CRUD operations.
Get put, post and delete.Right?So not all of them, they use the body in the communication.Some of them they don't use the body.And still you need to have a token.
So communicating the token goes through headers, HTTP headers, these headers.So this is the HTTP protocol.So we have the URL and the body.So we talked about that, the URL body and the method, you're already familiar with that we added here headers, okay?For the body, for the whole actually request we have header and that's the content of the header here.
So we have the host, the authorization bearer, which is like that.You are logged in.These are your credentials then.So this is in the request, right?From the request side, from the response side.So we have whether, like the status code, whether the operation was successful or not, the data that you are communicating, or if there are, there is no data, this body is just empty then headers, or there's no body actually.And the header here has these information.Now look at this, the last one here.Store this session cookie and send it back with future requests.What does this mean?
So this is the.So I'm going to talk about the principle here, since it's not a cybersecurity class.But like the principle here is we have a trade off between usability and security.So we need to keep you as a software user, conveniently using the software at the same time secure, like in a secure way.So this cookie allows that you can.
The cookie goes, not the cookie, the token goes back and forth between the client and the server and.And it gets refreshed in automatic way.Okay, that's what tokens are for.
Now, another security layer.So tokens themselves, they should be secured.So how can we secure the tokens themselves?
And that took me longer than what I expected anyways, how can we secure the tokens?So security tokens, plain English here, obfuscating.So you try to obfuscate them by encoding them not in an unreadable way, using encryption, or just in a hard to read way.We can use this base 64, so it encodes them in a different format.So instead of ABC123.You cannot read it.It's encoded in a scrambled way, so you cannot read that.Then you add another layer which is signing.So signing usually is what you do.You have the payload which is the token itself, like all of the token.
Then you sign it.Sign it.Meaning what?Can you tell me anyone has cybersecurity?Basic concepts.
Signature.So what's a signature?If we simplify it.Hmac.So Hmac, if you try just like Ask ChatGPT or Google Hmac, what does it tell you?What's the first two, three words you get?Hmac.
So actually I shouldn't ask you to Google it or just like from the hash, the H letter.It's a hint.So in order to sign, you hash and encrypt.Actually you hash and encrypt using usually asymmetric encryption.So it's a bit advanced.But let's keep it simple here.So you take the payload, you encode it, like you try to scramble it using like base 64 encoding method here.Then you sign it.Sign it, meaning that you hash and encrypt.Okay.
Then if you want more details, you can take cybersecurity clashes.Now I think done with the layers of authentication.No authorization simply, I think we have just one slide for it.As I said, since it's not cyberseclass, authorization is what you are authorized to do once you are authenticated.Okay, can you give me an example of once you are authenticated, what is it that you are authorized to do?
Maybe thinking stretching what you have been working on on iteration one.Because you'll be doing iteration two anyway.Like some auth.
Speaker B
Yeah, for example.Yeah.
I mean we're authenticated as users of that project backend, but we're not authorized to make changes.
Speaker A
Yeah, all the operations that the admin can do, you are not authorized to do it.That's it.Yeah, you are authenticated, but you are not authorized because these authorizations are given to admin roles.Yeah, that's good.That's a good example.Good and intuitive example.
Returns to requirement engineering and breaks down the pipeline from raw requirements to analysis, specification, and validation. It also discusses gathering requirements through interviews and surveys, and how AI makes clear specifications more important.
Speaker A
Yeah.So pretty much that's it.That's what we got from.
For the AUTH part.Any questions?For deeper coverage, UNSW offer additional cybersecurity courses.That's a good ad for unsw.Any questions?
Let's take this off table and talk about that later.So it's not like software eng.Fundamentals question.It's a good question.We can talk about that later.Yeah, yeah.
Any questions?I think this is your answer, Sachin, this one.
No questions.So let's go back to requirement engineering.So for requirement engineering what did we say?We just was talking about it here.Yeah, function requirement and non function requirements.
Right.Like we stopped there.
We stopped at this slide actually specifically.So this is a breakdown of the NFR product requirements, organizational, external.So if you look at the product requirement so it could be efficiency, dependability, security like the security requirements.I want my software to be secure.So so this is linked to the product.
Okay, organizational here.Organizational it goes here.As I was telling you about the car manufacturing environmental like here for development requirements example that you are working in an organization and they have set of rules and policies while they are like a software engineering company or something while they are developing software.So they have a set of policies what to use and what not to use.We are allowed to use Microsoft technologies for example we are not allowed to use Microsoft technologies.So this is a requirement from your organization.I can develop the software but I'm not allowed to use Microsoft technologies.So this could be another external requirements.I was like for example ethical like this is what's happening with AI service now Claude, ChatGPT, all of I know that some universities are not allowing all of the AI tools.I remember like in one university like Deep SEQ was banned like from I think the first week it got released right away.
So this is external.This is an external requirement.The government asked organizations not to use that.See that?So this is a non functional requirement but you can use it to develop your software.
Generate like Claude and Chadoo are using AI to write code but are not allowed to use some AI services.And this comes from external like government or.I don't know it's ridiculous to talk about that but it's a discussion that you need to have at some point as students and as graduates as well.Now we got like some nice quizzes here in these slides.Quickly let's.
Yeah, so let's answer this one.
Which one of these is a functional requirement?
That's correct.So what was the indicator that let you.It's B.
Speaker C
That's an actual feature that needs to be implemented.Rest all rest of them are kind of parameters that you have to fulfill.
Speaker A
So it's a major or a main feature that you need to implement and A, C, D are some criteria that you need to.Do you agree guys?Any one of the other three is confusing.
No, they are all.
Speaker D
Good things but they're not A solid like
Speaker A
except B.Right.
Speaker D
The only other thing you can really measure well is the 10,000 concurrent users.
Speaker A
So not on
Speaker D
99.9% of the time it's like that's subjective.
Speaker A
So you're saying no confusion, it's confusing or no confusion, which one is confusing?You like maybe it's fr.Maybe it's nfr.
For me B is straightforward because it's something that you need.It's like the doctor example.I'm using an online banking system to do this functionality, right.So I can transfer money.Then I have the other three.
But which one is a bit confusing?How about D?What do you think of D shall support 10,000 concurrent users.
So it's not a feature that I need to implement.So I can implement it for one user, right.Or ten users.Hundred users.But it comes to me like for a scalability feature.So the scalability feature it should work for.Not scalability, not feature scalability feature scalability criteria.So I need to fulfill now non functional requirements like the other way around.Which one of them is an nfr?
Sorry?
Speaker C
C.
Speaker A
C the system should be accessible to visually impaired users.Yeah.So what made you think of that?So what's the indicator?
Speaker C
The rest of them are core functions.
Speaker A
Yeah, core functions or core features that I need.Right.Anyone confusing.
Speaker C
Without those the app wouldn't work.
Speaker A
Yeah,
Speaker B
sorry.A and C. So I would say that C is more important than a rise because the website should be accessible to users, period is the main thing now users have visually impaired and non visually impaired.So I would say that C still ranks above as more importance than sending a confirmation email after each purchase which is not really required because you already get a notification for example, if you complete a purchase or even if you don't, you know that you've completed it.I would still rank C above a force something.
Speaker A
You rank C as NFR or fr.
Speaker B
Yeah, I would say that the answer should be A instead of C because I. I would say that.
Speaker A
Oh, so you got confused in the A part.Right?Like the.
Can anyone lift the confusion
Speaker E
for
Speaker A
Sachin?Sorry,
Speaker E
how do you prove and support you made the purchase?
Speaker A
Yeah, like this is one case like you need that notification.
Speaker C
Also the number of people that rely on the received is more than the number of people who are visually impaired.
Speaker D
Well not even that.It's very.That's
Speaker A
a good view of it.Yeah.Sorry
Speaker D
subjective.Whereas the other ones you can measure, they're very outlined.
They will.Which
Speaker A
one is subjective?
Speaker D
C like it's.It can be a very broad.
Shall be accessible to visually impaired users that can do anything from having text to speech all throughout to just having different fun.Like it could be a huge Range of things that is very, very hard to measure.
Speaker A
Yeah.So I think we are all, we all agree that C is an nfr.But A, we want to say that A is not is a function requirement or no add in A to C.
Speaker B
Right.So what I initially thought was that C should be more of an FR Inst.Because the website being accessible to users around the world is a primary function of any website.Among those users does
Speaker A
no.I think the way it's being treated here it's like the non functional requirement or the criterion that we need to fulfill is say accessibility or inclusion.So we can define that.So what happens like most of the majority or all the users maybe it's pretty much safe to say that 90 or 80% of the users are like they need this confirmation notification of confirmation to purchase.Right.That's the A.
But C is I want to include the visually impaired and accommodate with them for special way to notify them or something like that.So that's how I should look at it.It's like a criterion that we need to fulfill.I like the way when you said it's not features the first question, not this question.So it's not a feature, it's criterion that you need to fulfill the same thing.Maybe if you use this logic it's going to help you to delineate between FR and nfr.
Speaker C
If it's like adding audio cues for visually impaired users then maybe you could disclose that that's a feature that you have.
Good,
Speaker A
good.Very good, Very good.I think that's what you missed, Sachin.If it was reported like the way Rehan.Right.The way Rehan said it, I think it's.It would be an fr, not an nfr.Okay, Solve this issue.Okay.Now for the sake of time.So we need maybe to spend five to seven minutes on this then because we're going to revisit that in the conceptual modeling anyway.So for the requirement engineering we gather the requirements.Then we need to do some engineering.That's why we call it requirement engineering.
Okay.So in the requirement engineering we have this very famous pipeline.We get the requirements in as I told you last time, in a raw format.So if you look at the.Maybe later Amber will explain.There is an interview between me and Ronnie, one of the admin team members and it was raw.So just.I was just talking, explaining what I want to see in iteration two work.Then what you need to do, you take that row format, analyze it, then define and formalize the specs, then define how to validate them.Later.That's what I was talking about earlier.Define how to validate later when you come up with a solution and you develop it.So just quickly I'm going to go through that.So how can you gather the requirements?So these are some methods to gather the requirements.Market research, interview with stakeholders, which is the one that you have in your, in your iteration too.
So there is an interview with the lecturer and you need to gather some requirements from there.Focus groups, asking questions.Asking questions.
Do they have surveys?Amba surveys?Yeah, yeah.So you have a survey, Some questions, yeah.So you have an interview and surveys.
This is requirement gathering.Then you need to do the analysis.You might get it in a row format.You need to do the analysis.So how to do the analysis?
Usually it goes like that.So you identify all the dependencies, conflicts, risks, and we do it through user stories, use cases, then conceptual modeling.So I'm going to do, I think for the sake of time, just finish this pipeline.Then in the conceptual modeling.I will talk about this part.
Now.Specification.Once I analyzed, identified all dependencies, conflicts and established my priorities in how to develop.So I should specify it, write it in a formal slash, semi formal way.And that's actually, that's what's going to be important these days because you are allowed to use AI or not going, you can delegate the development or the implementation part in the SDLC to AI.
So before that, the entry point is given your requirements in the most correct way, if I can say that for the lack of better words.So how can you provide that to AI is through the specification.So you get it in a row format.You get it in a row format, then you analyze it, then you try to give the specifications, the specs and what's happening like these days, like maybe you heard of this skills md.So you prepare skills.
It's becoming like a common term now in software engineering.So how can you provide your specs to an agent that will do the whole implementation part for you?
Swagger is like a low level still.It can be
Speaker D
a similar thing where it's.
Speaker A
Yeah, yeah, yeah.In plain English though.Yes, in plain English.In high level.In plain English.And that's like not that much different of before AI software.Like engineering.Software engineering, before AI.But it's just getting more important now.
Sorry.
Speaker D
A programmer can kind of process it themselves and see the vision, whereas an AI doesn't really have
Speaker A
a software developer.You mean
Speaker D
a software developer.Sorry.Yeah, yeah,
Speaker A
yeah.You envision it and you write it in the right way to get to that Envisioned picture and AI will do it for you.Right.So that's why just here, this step three we're going to talk about in the conceptual modeling later.But just here, be careful.There is a difference between the specification in requirement engineering and conceptual modeling.Conceptual modeling we go more towards more formal.But for specification.That's why I said formal, semiformal.Okay.Because you can use plain English nowadays and feed it to AI.Right.And this, the last step is validation.Validation is you prepare.
I think this is.Yeah, you prepare as I told you.Prepare your metrics, your measures when you finish require like gathering requirements, analyzing them, specifications.Then your measures, your metrics that you will use after you finish the software to test against those requirements that you defined earlier or those specs that you defined earlier.Okay, I think that's the end of it here.
Closes the first lecture segment with a brief summary and mentions upcoming conceptual modeling. The speaker then sends students off for a short break.
Speaker A
Just a list of some challenges.Actually I would love to have a interactive five minutes about that.But for the sake or for the lack of of time, we cannot do that.Maybe next week before starting the conceptual modeling, we're going to talk a little bit about that.You got some nice quizzes here that some of them are a bit confusing, which is good.
So it's going to challenge you to understand even better.And yeah, so that's the end of it.Please give a feedback.We'll take a breather now.
Maybe seven, eight, eight minutes.Then we go to iteration two.So what happened now?The conceptual modeling will start it next week.I'm not sure if I can have time later by the end of the lecture, but maybe let's leave it to next week.Okay.Now maybe you can take this break.You are free like to stay or leave for this break.But just if you have questions, go through the the SPECs of iteration two so you can understand better the breathing of iteration two.
Introduces iteration two and explains the overall story: integrating the existing project into a class management system. It outlines the shift from in-memory testing to HTTP-based server testing and the need to work with unfamiliar code.
Speaker A
Thank you.
Sam.
Sa.
Sa.
Speaker F
Sa.
How was iteration one?Have we all wrapped up iteration one?How do we feel about it?
Speaker D
Confusing.Confusing.
Speaker F
Yeah.
Speaker D
Said to be open ended.
Speaker F
It's open.Well, you kind of have to support all the functionality.You have to be able to support the functionality of the iteration one functions.Right?You can't just like open ended data store.Let me just have an object, empty object, put anything in here.By the way, this works for everything.
Speaker D
More direction would have been nice.
Speaker F
Right?That's fair.Well, I guess you've had a bit of taste into like the world of software engineering, right?So I guess when you're working in industry it's very rare that everything will be just be given to you straight.Right?
So this is just a bit of a taster.We've given you some requirements of the functions and then some of it is kind of up to you to design.Like how do you design this data source?How do you lay out your files?So that's all something that you have to get used to, especially when designing software.
And it's good taste because iteration two, you might not like to hear this, but we are adding some more open ended features as like a challenge.Right.But you know, it's kind of interesting.So let's.Let's get into it.
So I did prepare slides last night and then I got kind of tired.So we're just gonna.We're just gonna go through maybe the first five slides that look acceptable and then we'll kind of ignore the rest.I'll talk about them, but that's okay.So welcome to iteration two.So iteration two was released technically in week six, Monday.How many of you read that announcement and read through the speaker spec?Oh great.Okay, cool.Of course the people that come to lectures read the spec.That's perfect.So in case you missed, iteration two is out.It was released on the week six of Monday and updates have kind of been made over week six and then officially kind of the official release with all the starter code came out on 12am probably like Tuesday sometime early like in the morning.So all of you guys should have had had a merge request with the starter code pushed out.
It will look like that.
If you have not merged this in, please merge it in.There may be merge conflicts.Resolve them before merging in.How many of you guys have seen this merge request and have merged this code in?Great.
Speaker D
It was a little bit wrong.It didn't have NPM run.
Speaker F
Didn't have NPM run.
What?
Speaker D
Oh no.That might have been us.
Speaker F
Okay.Okay.Phew.Phew.Okay.Yeah.Guys, if there are any issues, please do not hesitate to put it on the forums or like email the court scout.
It's nice to know of issues.I'm early, so that's all good.You can see the starter code for this is quite bare and you may be wondering why.So for iteration two, the spec can be found where the spec can always be found from iteration one.Just click onto the course website here and you can find iteration two on the sidebar.
So let's.This is just gonna be like a breakdown of what happens from iteration one to two.So.Oh wait, we missed the theme.So the TLDR or The theme of Iteration 2 is that after implementing your Iteration 1 functionality or your Cards and decks and connected to the cli.The lecturer is really impressed with you, what you've done and he's like, yo, you wanna come work with me and integrate this into a CMS one of my other students is building.And so you of course agree because you want marks Federation too, right?Unfortunately that cms, it's a bit incomplete, it's a bit vibe coded and maybe conveniently that main dev has gone.So it's up to you to fix up that cms, it's a class management system and integrate it within Yankee.So thumbs up.
By the way, does Anyone know what webcms3 is?Or am I just like really old?Okay, we have one person.This is a bit of a CSE law, but there is a class management system called WebCMS3 that CSE used to use.Wow.Ancient relic of the past.It wasn't that long ago.Some courses still use it.But yeah, you're building WebCMS4.So the next version of this class management tool.
Cool.So from iteration one you have all your types of TypeScript functions and all your tests call them directly through interface ts.Hopefully you did call them through.Hopefully you didn't make an interface TS and call your test through it.Right?
Thumbs up if you called your test directly.May want to revisit that, but that's okay.We also use VTEST to test them.And all our data kind of lives in memory, which means as soon as your program stops everything, all the class, sorry, all the card and deck data is kind of wiped from memory, which is bad, right?If you think about Google and if they have like a massive data outage, if they have a massive power outage, you wouldn't want all your data to be lost or if your computer dies because the battery ran out, right?
You wouldn't want all your everything like all your files just go gone.So that's kind of one of the limitations of iteration one.We'll be solving that and adding a lot more function in iteration 2.So for iteration 2 we still have typescript functions.Yippee.
Except now the test will call them through HTTP endpoints exposed through a file called Server ts.We have given you a very bare bones minimum server TS with an example route.I'll step through this in just a sec.But you are supposed to add onto this.There's also some other some other things to do.So look at the existing webcms3.4 and debug that and integrate.You're supposed to get familiar with integrating unfamiliar code with your own group's code.Because it's very rare in industry that you understand an entire service, right?You may understand a very small part of that service, and when you're forced to integrate it with something else, you're like, I got to learn this other service now.So, yeah, real industry experience, guys.
Covers the first core tasks: continuous integration, debugging WebCMS4, and understanding the provided API documentation. It also explains how to use curl, request examples, and the Swagger UI to test server endpoints.
Speaker F
You'll also be required to persist, persist data, add some more cicd.So if you did the CI part from iteration two, this will be a bit easier.You'll just add one more thing, type check, onto it.There's also a bit of planning, which we'll go over what that entails in a sec, and then a little challenge, which I'll briefly touch.But this challenge, it's like a challenge for real this time, though, guys, it's not like challenge from iteration one where it's, like, easy.
This is challenge for real.Okay, so just a brief overview of how iteration one works.We've got a little diagram here.Pretty simple.You have your Iteration 1 functions.
They get exposed through Interface TS by imports, and then your Iteration 1 test should have called them through Interface TS.Probably should have made that a bit more clear, but thumbs up.Okay, so iteration two is gonna work in a very similar way where, wow, the diagram's, like, pretty much identical in shape.The only difference is that now we have our iteration 1 and 2 functions as defined in the spec, and then we have our server TS instead of an interface ts.So now the level of abstraction has kind of shifted, Right?We've gone from calling our functions directly through the CLI to, oh, maybe there's like a backend web server here.And we'll look at how we can test that in a bit.Cool.Okay, this kind of, like, notes the that I wrote.Let's go over the spec because it'll be a lot nicer.
Okay, so we've given you a kind of a plan to follow because a little bit of guidance.Of course, some functionality is going to be a bit harder than others, and we just want to highlight what is easy to do and what is needed to do first, and then maybe what some of the more challenging things are.So first of all, before we even start doing anything, I want you guys to set up a continuous integration pipeline.If you've done that from iteration iteration one.Good job.
All you need to do is just add, type check if you've done.Oh, sorry.You also need to figure out how to run tests.I'll give you a little hint.Hint, wink, wink there in a sec.
If you have not done this from iteration one, please do it.Otherwise, you cannot get marks or having Master be stable.There's also no point in implementing this.At the end of your iteration, you're going to figure out, oh, shoot, my tests have been failing, failing on Master for like two months.Whoops.My bad.So do this early, please.The first thing you do before you even start planning any code, actually maybe talk to your teammates first.But this should be one of the first things you do.So you will need to manually edit the CI file.I'm sure a lot of you guys have done this already.The easy thing to do is just add tsc.That's just one script.The harder thing to do is how to run your tests.Right.
Because now we can't just run NPM runt as a bit of like a hint, hint, wink, wink.Thank you for coming to the lecture.I will point you to the WebCMS for starter code.
Cool.It can be found here.It is also linked in the spec.I probably should have just shown you in the spec.So if you want to find the webcams for backend, it can be found here.
Click it.Click it.And you'd be in the GitLab.CI file.You can see there's a nice little script that runs your tests.So if you want to understand this, you can also.You don't have to.We don't expect you to, like, write this yourself.We've given it to you for a reason.This is where it is.So anyone who hasn't watched the lecture or didn't come to lectures got to find this out themselves.
Cool.We'll go over what this, I guess what, like, testing entails in a second.Not what order this means, but kind of what it means and why it's a bit more complex.Yeah, what's up?
Speaker D
Something I could understand when I was reading is what Are you using WebCMS for?
What is that?
Is it we're trying to copy it into our one or.
Speaker F
Yeah.So that's the next part of Core, right?Oh, I did not order this.Right.Anyways, that's the next part of Core.So the first part of coding that you get to do is in the core section, and that is debugging the CMS.So we've given you this really buggy WebCMS4.There's bugs in it.We've given you some simple tests just so you get an idea of how the tests kind of work and what they should look like.
But the first step is debug webcms4.This is to get you familiar with HTTP servers instead of just chucking you straight into iteration two, being like, hey, convert your iteration one functions over, we're going to make you debug a bit and hopefully this gets you guys a bit more familiar with how the server works or server TS works and how tests for it work.Does that make sense?Kind of.Is there any ambiguity there?
OK, cool.So, yeah, you want to debug WebCMS 4 now you'll see that this isn't.It's probably in a very different structure to how your existing code base is structured.Right.And that's kind of our next step.We want to integrate that into our existing code base.So this is where it's really important for your teams to discuss how you want to, like, format all your code, how you want to format your files.Do you want to keep the structure in webcms form or do you want to keep the structure that you guys currently have?Right.And so we haven't.There's the reason why we have not merged this into your code, into your starter code, is because it's up to you to figure out how you want to copy and structure the files here into your own existing code base.Does that make sense?
So challenge there, but I'm sure you guys will be able to figure it out.Cool.So, yes, there's also the CMS integration.
So all the.Actually, yes, all the CMS routes have been outlined in the specification part here.They would be under Users courses and all.So if you're like, I need to debug this, but I don't know what the functionality like, what the intended functionality should be.Just look at your spec here.
All the routes in WebCams 4 have been defined here or the behavior has been defined in here.Thumbs up.Actually, now that we're looking at the spec for the first time, let's kind of go over and break this down because it'll be a bit unfamiliar to you guys.I think up until this point, you guys have been very familiar.Familiar with like Swagger files.Right.So we haven't completely taken that away.Actually, no, we haven't taken that away from that.Off.Sorry.We haven't taken that away from you guys at all.If you hit specification here, you can actually find the Swagger UI right there.Wow, nice.Familiar.Right?
So this is one way API documentation can be done.It's a pretty popular way.Another really popular way is to have like a website with all your endpoints.And this format is.This format that we have here is a very common way to format API docs.
So thumbs up to break this down, you have your base URL up here.Now this can be local, it will likely be local host if you're working locally.If you choose to deploy, which is.Oh no, it's an advanced feature.You might want to replace this with like your public URL and then you can test it through this interface.
Other than that, you have your HTTP method, you have your HTTPath here, you have your body here.You can also see the plain JSON if you want.This is pretty high tech stuff, guys.As well as you can see how we can send requests.So there's example code to send requests.
So how many of you guys are familiar with sync request curl?Yeah, we've done our week five labs.So yes, that's a bit concerning.Half the lecture does not know what sync request call is.But that's okay.
Do lab 05T and lab 05 check INS.But sync request curl is what we will be using to make requests to our server.So you can see there's a bit of sample code here that will help you out with that.You can also make curl requests over the command line.Has anyone used curl before?
No.All of you have actually used curl before?
Speaker D
Curl,
Speaker F
yeah.Curl, yeah.Okay, so when you were downloading like nvm, right?Remember week one setup, you use curl, likely use curl, right?And curl just makes a request.So when you were setting up your computers for the first time in week one, you would have made a request to some web server to download NVM and then you would have run probably like a bash script in it to set it up.Yes, all of you guys can use.
You just probably didn't know what it does, but that's fine.But yeah, you can copy this into your command line once you start your server and it will just send a request.Do we know any other methods for sending requests?Yeah, yeah, you can use an API client like ARC or Postman and actually we won't do that today.But yes, that is one method you can use to test.
Cool.You can also see the response bodies here.So for 200 it should look like this.For 400 it will just be your little error response and then, sorry, all the response bodies can be found down here and all the information in it can be found down there.Sometimes this can format it a bit weirdly.
You can see that this is supposed to be like an object, right?If you look at the 400, it is supposed to be an object one with the property error in it.Whereas the 400 here only says error string, right?If you have an array, I think some endpoints return like an array or object with an array in it and it might look a bit funny.I don't know if I can find an example of it now.
List courses maybe 200.Yeah, you might see something like this, right?And you're like, oh, damn, what is this?That is confusing.No worries.That just means it's an array and if you open up, it's an array of objects with these properties.So if you want to use these docs, feel free, this is what we recommend.Otherwise, if you find a part that's a bit confusing, feel free to ask on the forums and then just to unblock yourself for the time being, you can look at the Swagger ui, which you should all be familiar with by now.All good.Cool.
Explains secure password storage and why passwords should be hashed rather than stored in plain text. It also introduces safer session handling and mentions available libraries and crypto tools.
Speaker F
What else do we have?
Cool.All right, let's go back to the spec.
Cool.So that is pretty much.Sorry, that is pretty much nearly all the core features.We have one more feature in core.Well, technically it's not core.None of these are kind of defined in quite advanced, but secure password storage and safety sessions down the hyperlink is broken.Cool, Here we go.We also have secure password storage and safer sessions.So you may notice in webcms4 we introduce users, right?And with users we have user accounts and we start storing like pretty sensitive information like passwords.
So the way passwords are normally stored is it's stored as hashes.We never want to store passwords in plain text because if your dart, if there's a, a data breach and kind of your data gets stolen.Well, great.That's like all of your users passwords and emails just out in the public.Which, you know, that's not really a great idea.
So one way we can kind of.Obviously I cannot pronounce that word hide passwords is by hashing them, Right.Does anyone know what a hash is?Oh, they damn thing.Okay, that's fine.Great.So we're all familiar with what hashes are.Cool.So we want to hash passwords before storing them.Right.
And then you might think, oh, well, now if I'm not storing their password, how am I supposed to know if their password is correct?That's for you to figure out.It's not that bad stealing all the challenge done.No, that's fine.It's good to know.
Yeah, yeah, but it's like, yeah, you need to implement it.Right.Same with sessions.So I'll go over what sessions are in a sec.But just think of sessions as a way that a user authenticates themselves against the API.
So it's something that.It's kind of sensitive information.Right.You don't want that being leaked out to other users.So you can choose to hash these things or you can use like a random ID gem like uuid.
Now, as another hint, hint, wink, wink for coming to the lecture, you can use a NPM package for this.Up to you which NPM package you want to use.Or you can use Node's crypto module, which all the documentation can be found very conveniently right here.So pick what is best for your team.Oh, yep.What's up?
What else would you want to write?Your own hashing algorithm?
Speaker D
No, like R1,2 or Scrypt
Speaker F
or Ecrypt?Oh, yeah, yeah.Those are just other packages you can use, right?Yep.So no, you will lose marks if you write a hashing algorithm that is insecure though, because then it's technically not hashing.Right.So if you.If you want to.Look, if you want to write your own hashing algorithm, I'm not going to stop you.But if your hashing algorithm is just string plus one, you know, that's probably not a hashing algorithm.Cool.Does anyone have any questions about any of the advanced features that we gone over?
No.Great.Cool.
Describes how the marking scheme rewards completing the core features well. The speaker emphasizes that students should prioritize stable, well-tested core functionality over rushing into harder tasks.
Speaker F
So that is all you.Actually, I should have gone over the MAD breakdowns not to scare you guys too much.Okay, man, I'm kind of jumping over the place.But just for doing that, just for debugging the CMS and integrating into your existing code, you can get 60% plus 30%, whatever that is, you can get like over 50% of the automarking and non automark features.So.Wow, that's a pretty good deal, right?You do half the spec, you get like more than half the marks actually.
Less than half the spec actually.And you get more than half the marks.So as we move on to the more challenging features, you'll kind of realize that it's diminishing returns and you might want to discuss with your group whether it's worth doing the more challenging features.Yes.
Speaker D
Is there another iteration?
Speaker F
No, this iteration is the last one.Yeah.No, we want to give you a lot of time for this iteration.So you've got up until like week nine to finish it.So that's a whole three weeks plus one if you include like Flex week where the spec was released.So that's a whole four weeks.
Speaker B
Actually, it wasn't.It was released at the end of week seven.
Speaker F
No, it was released at the start of week six.Question mark.
Speaker B
I'm pretty sure.Because I checked for it.
Speaker F
Week six newsletter
Speaker E
Tuesday.
Speaker F
Oh, okay.
Yeah, it was released like Tuesday, week six.Yeah, look, the announcement.The announcement was out.Yeah, it was out.
Yeah.
Speaker E
My announcements are not popular.
Speaker F
Yeah, It was you.And this is the line.You're not expected to work on it, but we want you to.We release the starter code in week seven.
This is a spec, not the starter code.
Yeah, yeah, but like you know, you read the spec, you cut it.
Yeah.Three weeks is pretty good guys.You know this is us being nice trying to give you like the actual week to like the read spec now that's like a privilege.Okay.We're just so nice.
The due date is week nine.No, week ten Monday if I recall correctly.Read this back as a source of truth.I lowkey might be tripping here itu week 10, Monday.Yes, I was correct.
So yes, you have a whole three weeks plus like one if you count week six.Cool,
Speaker A
go.Let me just reiterate on the marking.So you've got a great deal there, right?
Speaker F
Oh okay.Yeah.Just like re hammer in the marking.Doing only the core features, which is less than 1/3, which is about 1/3 of the spec gives you more than half of the marks.Yeah.
So don't think that you need to complete everything because like some of the challenge things are quite hard and open ended.So.So just keep that in mind.It's better to complete the core and advanced functions really solidly and have them really well than to try rush everything through get the advanced done in a really bad way.Right.Because then you end up with bugs and then that will lose you more marks later.
Introduces persistence and the live quizzes feature as the main advanced work. It explains the quiz state diagram and how invalid state transitions should be handled with errors.
Speaker F
Cool.Ok.I've kind of jumped all over the place.Let's go back to the spec and let's look at the advanced functions.
So advanced.Sorry.Some of the advanced functionality include persistence.If you've done lab 07 memory.How many of you guys have looked at lab 07 memory?
No.Oh, one person.Damn, that's crazy.Right.So before you start persistence, look at Lab 7 memory.
Do Lab 7 memory.Persistence is a bit tricky or Sorry, it's a bit tricky if you don't know how to do it.A very common way to implement persistence that students do is every five seconds I would just write to my database.Right.But an issue with that is let's say you make a database write, some operations happen after the two seconds and then your server crashes.
Well then you've lost all those operations that have happened in the past few seconds before a data after that database write had occurred.So look at lab server memory.Cool.After persistence, we recommend that you complete the advanced features of iteration.Sorry, the advanced functions of iteration two.
So with advanced, it's pretty simple.All you have is live quizzes.You've just got one new.You've got one bit of functionality called live quizzes.And this essentially allows a lecturer to run a live quiz almost like a kahoot, but not really like kahoot because you know, we've done that in the past.
So it allows you to run like a live quiz in a lecture.So if we look at the endpoints from here, there are 10 shiny new endpoints.Most of them post or get requests, so shouldn't be too hard.And they pretty much control the state of a quiz.Right.
We've given you a state diagram here.Hopefully we've done conceptual modeling in lectures, right?Yes.Cool.So you should be familiar with what this means and how this works.Right?So any invalid state transfer transforms should result in like a 400 error.Right?So if I try go to the lobby straight to an answer, well, that doesn't make sense.That should give me a 400.
And pretty much the functions defined in the live quizzes control the actions in the state diagram.Does that make sense to everyone?
Explains the quiz generation feature that pulls questions from an external API. The speaker discusses cursors, pagination, query parameters, and the need to avoid overloading the external service.
Speaker F
Oh, you haven't done conceptual modeling yet.Oh, damn.Sorry for cutting you off there.All good.But yes, this is just new features that you implement to the spec.
So this is as simple as just reading the spec, implementing new HTTP routes.Is everyone okay with that?Actually yeah, that should be pretty straightforward with it.There's also a few smaller things.If you have done iteration, want advanced functions, convert those over as well.Right.If you haven't, then that's okay.You can also write them and just write them from scratch.But there should only be like three or four functions that came from like ITER1 advanced.So if you want to catch up on that, feel free.
But judging by the mark distribution of everyone, I'm pretty sure like most of the course did all the advanced routes anyways.So you guys are chilling.Okay.One more kind of new functionality is generating quizzes.Now this kind of has been separated off into advanced because it requires you to make external API calls.
So if we look at the.Generate a quiz deck.Generate a quiz deck.This is pretty much generating a quiz using questions provided by an API.So up until this point, I guess up until this point in the iteration, you would have been building your own API and making calls to your own API.Right?But what if we want to use other people's AP API?So What?No way.Right.Stealing data from someone else.Real.So we've made a endpoint, a little API for you guys.Yeah, guys, I put so much effort into this.So you can query it by just going, questions.
Where is this?Questions?You give an amount and it's like, damn, you get five questions.Isn't this question cool?There's a bit of difficulty in this, in that this route allows you to generate quizzes with up to like 20 car or 30 cards.
But you can see that this API loki kind of bad.If I try to get more than like five cards, it'll just be like, nah, I can't do that.Right.So you'll need to figure out how do I get multiple cards or how do I get like up to 30 cards from this API?Right.
You may notice in this little response, we've got this little curious thing called a cursor and you might be going, hmm, what's that?Right, What's a cursor?Good luck finding out.
Speaker B
After that we cycle back to one after five.
Speaker F
Sorry, what is it?
Speaker B
Is that enough that we can move the cursor and cycle back to the same questions after five cards?
Speaker F
Not the same questions.
Speaker B
So you have like five questions, right?
Speaker F
Yeah.
Speaker B
So you see we have 10 cards.
Speaker F
Yeah, yeah.I think you've got the idea.Yes.Yeah.So, okay, sorry guys, I'm not going to leave you out in the code like that.There is documentation here.So it pretty much returns a cursor which you can pass back into this cursor field to ensure that fetch down.That's a typo.Fetch questions are not refetched.Right.
So you know, I've made it a bit easier.You guys don't need to like keep hitting the
Speaker D
endpoint.
Speaker F
Yes, it will fetch questions or not really starting, but it's like there's no concept of order.Right?
Speaker D
Yeah, as in if you pass it, say.Well, if you pass on the cursor, then it won't give you the same questions again.
Speaker F
Yes,
Speaker D
you fresh questions.You don't have to add like a filter to double check.
Speaker F
Yes, yeah, there you go.
Speaker D
Cool.
Speaker F
Now, a cursor is a very common thing within APIs and web dev.
So if you're a bit confused about anything we just talked about here.Google.Right, cool.It's a very common thing.This is not like a very top secret 1-531 concept that we've just introduced.
It is a very common thing used in a lot of web APIs.And this is like one of the last advanced functions.So a bit of research for you guys to do there.
Covers the final advanced feature: continuous deployment. It explains deploying to Vercel, exposing endpoints for marking, and automatically deploying changes pushed to master.
Speaker F
Cool.There's also a few other query parameters you can use.
So you can see that your endpoint is supposed to take in a few optional query parameters like category, difficulty type, which you can all just pass back into the API here.When testing this, please do not not DDoS the CSC servers.Please do not like attest and put it on loop for like 24 hours.I'm sure the people at CSG will not be too happy about that.Yeah me when I can't DDoS the CSC servers.
So yeah, I kind of put in a requirement here.That is it here.No, it's not here.I've kind of put in a requirement in the spec that persistence.Nope, that's features.
Where is it during quizzes.Yeah, cross entire test suite.Please limit the API calls to no more than two requests per test suite.Yeah.What's up?
Speaker D
Can you release the code for the thing so we could like set it up on our local machine if it crashes at some point?
Speaker F
Just like
Speaker D
we could round or like a different port and just request that port?
Speaker F
Yeah, it's like you set up in a way.Ok.The way things are deployed on the CSV servers are a bit funny actually.
Ok. Yeah, I will think about releasing the code for it.I will think about
Speaker D
it.
Speaker F
But this wouldn't be a problem if you just mocked the API calls, which may be a challenge feature.Okay, that didn't come gather that much.Okay, that's fine.So that's kind of like your last advanced function.And then we have one more piece of advanced functionality which is continuous deployment.You guys probably aren't familiar with continuous deployment yet.I'm going to assume you aren't.
Ok, cool.So it's kind of like continuous integration, but integration kind of performs the checks.Deployment deploys it for you.This can be something that you do later down the iteration.You don't have to do this like at the very beginning.
But you may find Lab 09 deploy helpful for this.So please do Lab and deploy before doing this.Please also deploy to Vercel.So the bunch of requirements are here.Don't think that you need to go set up like AWS or some GCP stuff.
Just Vercel.It's free.Right?You also need to expose your endpoint endpoint through deployment MD so that your tutors can actually see yes, this was deployed and so we can actually test the endpoint as part of this.You also need to build the CD pipeline.So I think Library 9 Deploy will tell you how to Deploy.I think it has an optional step of how to set up a CD pipeline.But yeah, for the project, it is a requirement that you both deploy and set up a CD pipeline if you want marks for this.So CD pipeline will pretty much just deploy any code that gets pushed to master or merge into master.So it'll just automatically deploy it.Right.And now you can kind of see why keeping master is so stable.Right.If you think of your deployed code as like, customer facing.
Right.You don't want to push code up to master that breaks.And now your customer's like, damn, I can't use your app anymore.This sucks.Boo.So, yeah, continuous deployment, that's just another part of the software engineering lifecycle.
Introduces the planning stage, where students choose one theme and write a design report instead of implementing it. It covers requirements gathering, user stories, route design, system changes, and submission expectations.
Speaker F
Cool.Okay.I think we have finished all the advanced.We have gone over all the advanced features.Great.
Before we go into the challenge, there is something else I want to show you.There is a stage called planning.So up until now, we've done.We've got a lot of experience with like, implementation and testing of the sdlc.Right.
Do you remember what the SDLC is?
Yeah.Right.It's this little funny diagram here that outlines how kind of software is created.Right.So up until now, we've done a lot of implementation, we've done a lot of testing.
Right.But you can see that's like a very small part of the software development life cycle.We also got to look at planning, analysis and design.Right.So kind of what's involved in planning, analysis and design?
That is pretty much what planning PDF is.So we'll give you a bunch of requirements here.There are five themes.Sorry?There are five themes which we've designed requirements around.
You can find the sources of, like, this data from, like, either a lecture, interview transcript or student survey.Right.I'm not going to play the interview transcript.You can kind of look at what the survey looks like.So it's a survey that we've sent out to, like, hypothetical students asking them questions about Yankee Dash webcam.
And they may have some complaints.They might.They have found something's really good.It is up to you guys to look at the starter and figure out what can we improve.Right.
We have given you sort of a rough initial, like, plan of like five mini themes that you can go with.So study reminders, live leaderboards, badges and rewards, space, repetition, deck, version history.You only need to do one.So in a team, you only.Each member only does one, don't do two.You won't get additional marks for it.And if you're in a group of four or three.You don't have to do all of them.Right.You just do four of them or three of them.
So this is individually marked as well, so don't feel pressured to do another task just because a teammate hasn't finished theirs.Right.This is individually marked.Got it.Cool.
So we want you to explore these themes and come come up with requirements and propose a design to implement them.You don't actually have to implement them, sorry.You just have to write a design.So everyone will produce their own little PDF which will get pushed up to the repo.You do not need to get merge request approval to merge this into your master branch because it is an individual thing.
Your tutors know this, so don't worry about getting approval for that.The report should include requirements, route, discuss, design and system changes.Right.So have we done requirements analysis and lectures yet?Yeah.Okay, 60%.Cool.Great.You should be able to start with requirements.So you're just looking at your.Either the video interview or the forum and getting responses and eliciting requirements from them.Right.Once you have requirements, you get user stories, acceptance criteria.You put all this in the PDF.Just read.I don't want to read this back again.You guys have it there.Sorry.From your requirements and your user stories and all that, you're going to design routes.So you're going to design new V2 routes to support the feature.
This may mean like some of these routes may mean.Sorry, they may require you to change existing routes.Right.So instead of changing the existing, maybe like login routes, you may want to create a V2 login route and change the functionality of that.
Speaker D
So here instead of.It's like for every view route that we're defining to whatever the local Host or whatever, V2.And then slash ones and then if there's similar ones.
Speaker F
Yes.So you'll see from the original routes, they all prefix with V1.
Speaker D
Yeah,
Speaker F
so.Oh, sorry.I probably should have made that more clear, actually.In all the routes here, they'll be prefixed with V1.This just means they're version one routes.When you design new routes on top of them, instead of V1, you're going to replace them with V2.And this just allows you to change the functionality while making both of these routes accessible or work.
Yeah.Cool.Okay.That is something I will add to the spec then, because I assume a lot of students are going to be confused by that.Cool.
New routes.Okay.Yeah.So you can choose to write a swagger file if you want, although that is not required.A table is sufficient if you want to go the extra mile in writer swagger, up to you.
But again, a table, just like a Microsoft Word table, is sufficient.Just make sure it has all the information that you would normally find in a swag.So this includes the route, the method responsibilities, any conditions for like, failure, all that other stuff.Got it.Cool.
Okay.Once we have designed the route, we're going to see how this impacts our system.Right.So from iteration 0 and 1, you would have designed a data MD file, right?Yeah.
With these, with your new routes that you propose and with your new functionality that you propose, tell me how this impacts that data MD file.Right.If this change impacts the state diagram from the live quizzes.Right.Tell me how that impacts the state diagram from the live quizzes.
So any information about the state of the program changing should be documented.And that's just part of system changes.Yep.
Speaker D
In the process, before we've done iteration two, is it like after iteration two's kind of already been implemented, it's getting on top of that or what.When just so, like.Or how we're writing it, what do we need to kind of already have in our hands?
Speaker F
Yeah.So with this, we kind of put it after the advanced features, because the intention is that you do your core, you do your advance, and then once you kind of have like an MVP for Yankee WebCMS for this app gets sent out to other people and we collect feedback from it, that's kind of where it sits in the whole thing of the project.Yeah.If you also, like, some groups may choose not to do advanced and that's fine.And they may want to do planning.That is also fine.Fine.Right.This planning doesn't actually require you to implement like any of the core advanced features.Right?It's
Speaker D
not.
Speaker F
Yeah, that's fair.I think it requires you to have a knowledge of the core and advanced features, but you don't have to implement those advanced features.Right.But yes, the idea is that with this, the core and advanced features have been implemented to create a minimum viable product.And now this has been sent out for feedback.
And this is the.Sorry.This has been sent out to gather feedback and this is just the feedback that you've got from it.Does that make
Speaker D
sense?
Speaker F
No.You'll submit this to your repo.Oh, is
Speaker D
that.
Speaker F
I hope this has been defined.
Yes, it has.Okay.Yeah.So produce.Oh, that's report.
Oh, submission.Yes.So in the submission predipedia submit
Speaker D
it.
Speaker F
Please do not submit a PDF with a Google Drive link that will not be marked.Please actually Submit a PDF.Right.The problem with Google Drive links is that you can edit it after the iteration has ended and we just don't know.So if you just give us a PDF with the Google Drive link that will not be marked, Please actually give us the PDF report.
Discusses the open-ended challenge tasks, including mocking API calls and handling content-type headers. The speaker stresses that these tasks are worth relatively few marks and that strong testing matters more.
Speaker F
Yes.Is
Speaker D
there a reason why it's getting put onto here and not Moodle?
Speaker F
We don't use Moodle.Yeah, yeah.So like, yeah, Moodle is kind of just like if we set up Moodle just to accept PDF submissions, it's kind of like that's more things to maintain.
Yeah.All your submissions have been through GitLab anyway, so it's just familiar.Cool, cool, cool.I think that is it from planning.Does anyone have any questions about planning?
No.Cool.Oh, damn.I've got like five minutes that went by really quickly.Okay.
You know, that's fine because like challenge.Oh, it's mysterious, it's hard.You're going to get very little tutor guidance for this.Right.So just know that these are meant to be hard.They're designed to be open ended and they're designed for you to go and do research.We have linked a few resources here for you to look into, but you're really going to have to go and do your own research.Right.So one of these is mocking.So mocking API calls.What does that mean?I don't know.Google.All right, look it up, figure it out.Also, content type and accept headers.
What is xml?That's some funny letters there.This is all open ended for you guys to research.Just keep in mind this is worth in less.Less than 10% of iteration too.
Even less if you factor in like the team work marks like in the entire project.This is probably worth like 2 to 4 marks for both of them.Right.So just keep in mind it's like diminishing returns.Yes.What's up?
Speaker B
So because I'm guessing that there's more than one way to solve each challenge task, so I'll be graded on how optimized we make it or it's just if we end up finishing it.
Speaker F
So you have to follow the requirements here.Some of these requirements help you make it a bit more optimized.So for example, for xml, you must make effective use of middleware.
So you can like technically you can modify every single route to accept xml.Right.But that wouldn't be very efficient or nor would it be very maintainable.Right.So we've kind of helped give guardrails there by saying you must use middleware and hopefully, hopefully this will make it a Bit nicer.What's up?
How bad can you mess up middleware?I don't know.Like, I am intrigued to see how students solve this.It does say effective use.Yeah, it's a challenge.Right?
Speaker C
That's what brings me back to my original question.Are you seeing how different students solve
Speaker B
or whether they just end up solving?
Speaker F
We're going to look at whether it's probably going to be whether you end up solving it, but then also just make sure it says effective.Right.So if you're, like, parsing like something through, like 10 different levels of middleware without any good reason as to why you're doing that, you know, that's.You probably won't get the mark for effective, but yeah, you just need to make sure you satisfy these requirements.Also, like, writing clean code is just something that is marked throughout your iteration, like code cleanliness.So if you're writing it and it's really jank and everything's kind of put together or weird, then, you know, you probably won't get as much marks with code cleanliness.
So that's why I kind of stress it's really important to have really good foundations for core in advance.Yeah, core in advance before moving on to challenge.Because if you try to put bad code onto more bad code, you know your marks are going to stop in other places.And you know this is only worth like two marks in the whole two or three, three or four months in the grand scheme of things.So, yeah, just keep that in mind.
There will be a front end coming soon.We are writing that it's coming soon.That'll be one way you can test your iterative backend when it comes out.There will also be a demonstration in lab 10.So along with all your regular standups, there will be a demonstration in lab 10, which you will need to complete.And this just allows you to demo all your features to your tutor so that your tutor doesn't have to run your code at home and just click through things.The marking criteria can be here.I think we went over very briefly before, but yeah, just want to stress again, doing the core in advance will get you, like, most of the marks here.Right.Please don't stretch, like, not don't stretch yourself.Do challenge yourself.But, like, don't rush into things and just think, I need to get everything done right because you end up losing more marks in, like, other areas.
Auto marking formula can be found here.It's mostly the same to iteration one.The only difference now is that it's coverage plus five, which means that you need at least 95% coverage in your code.
And we've also cubed it.Does anyone know what cubing that does means?Ok, so let's do a bit of math here.Right?So let's say you had 70% coverage in iteration one.Right.Let's ignore that.Let's ignore the 15% whatever we added on.Let's just go 0.7 cube.So whatever your mark is.
Oh, sorry.Whatever your mark was for iteration 2 would get multiplied by 0.49.For iteration 3, it gets multiplied by even lower.Right.So this is a place of really great emphasis on tests and writing tests.Right.It can be very tempting to just rush all the implementation and be like, yes, we have our product.Send it out.Right.But tests are really important to maintain to ensure that your code base is maintainable and like works.
So that's why we put cube three.Please write tests.Right.You're going to lose a lot more in bad test writing than you will in not doing the challenge.So that's what I mean.
Just don't rush the challenge.Focus on doing all this well.
Gives final reminders about dry runs, previews, submission rules, and late penalties. The lecture ends with a final check for questions and a closing goodbye.
Speaker F
Yeah, we don't hate you.So here's extra 5%.Cool.Automarking config.This is the same as iteration one.
Read through it.Low key.Running over time here.Dry run will be available in week eight.That's the same as iteration one.
And previews will run in whenever the preview runs.You can find the information here.Cool.Submission is the same as iteration one.Submit to master anything by the deadline is a thumbs up with iteration two.We do have a late penalty, so you can submit up to 24 hours late for core components only.So not the open ended or challenge because those are challenging with the.With a 5% penalty.Cool.I hope I've gone through everything.Does anyone have any questions?No.Cool.Everyone's ready to start iteration two.Yeah, Epic already started.
Even better.Okay, cool.It was great seeing you guys.Anyways, if no questions, then, yeah, lecture done.Thumbs up.Did you have anything to say?Cool.
Sam.
Sa.