You should have completed the prep listed in Welcome to CodeYourFuture. If you haven’t done that yet, go back and complete it now.

🧠 You must always do the prep.

If you have worked through the Welcome prep, begin the prep for the first Onboarding sprint (which starts here!).

Recall that a commit is a snapshot of our project at some point in time.

Therefore, we should be able to check out a previous version of our project and look at the files and folders there. We can use the Github interface to check out the files and folders at a previous commit.

We can view the different commits of a project on Github. This means we can see what an application looked like before, in previous versions.

Often we want to take an existing project and start working on it independently. In other words: we start making our own versions of the project separate from the original project.

We can create a fork. A fork is a copy of a repository that exists on Github.

A GitHub repository’s url looks like this:

https://github.com/CodeYourFuture/cyf-demo-repo

Like any url it is made up of different parts.

When the user EagerLearner forks this repo, the path changes from CodeYourFuture to EagerLearner.

Before we can work on it we need to get a local copy of the education blog repo. A repository on GitHub is said to be remote and a repository on our own computer is said to be local.

We call a local copy of a GitHub repository a clone. The process of copying a remote repository on to a local machine is called cloning.

Here is a diagram representing how the repositories interact after forking and cloning:

Sketch this diagram in your notebook. If you get confused about where your changes are you can refer back to this diagram to help you understand what’s happening.

How can we get a copy of an existing GitHub repository on our local machine?

Once you’ve got a local copy of a codebase on your local machine you can start to view the files and folders in that codebase using VSCode.

We can check the commits on the remote repository as before:

On the left page of the page, we see additional information:

So what is main?

main is a branch.

Commits form a sequence that look like this:

A branch represents a particular history of development in a project - the different versions there have been.

There can be different branches with different names, which may have different versions.

For example, if we were testing out some different visual styles, maybe we would have one branch with some extra changes which make the website more blue, and a different branch with some extra changes which make the website more purple. These branches may share some commits in history, but have some extra different commits separately.

The main branch is often treated as a special branch - it’s where we put commits which people working on the project have agreed on. Other branches (e.g. the try-purple branch) may have extra changes that have not been agreed on. If people working on the project agree the changes from the purple branch are good, we’ll add those changes to the main branch.

When we’re working on something new, we haven’t agreed with other people that our new thing is good yet, so we often don’t add our changes to the main branch straight away. Instead we make our own branch to experiment on.

We can start to create independent branches like this:

In the diagram above, we can continue to commit on the “week-1-coursework” branch without altering the history of the main branch.

TODO:

• Define “merging”
• Show GitHub UI for a branch compared to main
• Show PR UI
• Show merging

These questions and answers are compiled from recorded sessions on HTML forms, and are the collective contribution of several mentors and students. This time we’ve included a trainee answer and a mentor answer, per question.

10 Things About Forms

So let's go deep on forms. What is a form? What does form mean?

🧑🏿‍💻💬 Trainee: What does form mean? It’s like a set of options for a user to choose from on a website.

👩🏻‍💻💬 Mentor: Yes, that is true, that is a correct answer. A deeper answer might be form means shape. It’s how we define the shape of data. So, imagine a shape sorter. You put a square thing in the square hole; you put a round thing in the round hole. Each form field is a different shape in the shape sorter lid. That’s what we’re doing when we write forms. We are forming data with fields.

Why do we do that? Why do we bother grouping and shaping data in that way?

🧑🏿‍💻💬 Trainee: Of course because it makes it easier to sort it out.

👩🏻‍💻💬 Mentor: Yeah, absolutely! Because you know we’re going to post that data to a database. Our database doesn’t know what all these strings mean. We have to define the data. We have to label the data. We have to group it, and we have to do something with it: to post it to a database or in some cases, get it from a database.

So that’s the point of all this.

What does field mean?

👩‍💻💬 Trainee: Field? It means like the window is completed with some information. A piece of data.

👩🏻‍💻💬 Mentor: Right! You put a piece into a form field; you just put one thing in there. A form has many fields, and a field is a single piece of data. It is the smallest piece.

So we structure data with forms. And we do that by defining form fields with semantic HTML.

📝Now practise with

Now practise with How to structure a web form

What else do we structure, when we write an HTML form?

🧑🏻‍💻💬 Trainee: Gathering data you mean? I’d be doing a search…

🧑🏿‍💻💬 Trainee: Can I say? We can structure… an action, a connection.

👩🏻‍💻💬 Mentor: Ooh, that’s a great answer. We can structure interaction. We tell the user, what to put in the form field, and how to put that data in. We structure a really specific kind of interaction. We guide them and tell them what to do. And the way that we structure those interactions is, again, using form fields. Using HTML form elements, attributes, and values.

That’s really important to think about, because when you’re deciding what to write in a form, you need to start with ‘what data do I need.’ It’s better to do that than to try and memorise all the different types of form fields. If you think:

flowchart LR 1[What data do I need] --> 2[What interaction am I building] --> 3[What element do I need to achieve 1 and 2]

Then look up that last part. That’s more effective than trying to memorise all the different types of form fields.

But saying that, let's name some form fields now -- some elements in HTML that we can use to structure data. I'm going to say, input of type text. Name a bunch more.

🧑🏿‍💻💬 Trainee: Yeah, maybe checkbox?

👩🏼‍💻💬 Trainee: radio button.

👨🏿‍💻💬 Trainee: submit input type, could be submit or button itself.

👩🏽‍💻💬 Trainee: autocomplete?

👨🏻‍💻💬 Trainee: I think autocomplete is an attribute, but it’s not itself an element or element type? How about textarea ?

🧑🏿‍💻💬 Trainee: select and option

👨‍💻💬 Trainee: The input of type password…

👩🏻‍💻💬 Mentor: The point being that there are absolutely loads of different form elements!

What you need to focus on is what you’re actually doing. We’re structuring data: you are defining, naming and then grouping data. Keep that goal front and center, then your forms will work well.

📝Now practise with

Test Your Skills

Oh and... what does input mean?

🧑🏿‍💻💬 Trainee: Input means to put something in. In this case the data we put in the form.

👩🏻‍💻💬 Mentor: Bang on.

What happens when things don't work well. What happens when the user puts the wrong thing in a field?

🧑🏿‍💻💬 Trainee: Do you mean validation? Don’t we need JavaScript for that?

🧑🏾‍💻💬 Mentor: We’ll learn about validation with JavaScript later on, but there’s actually a lot of validation built in to HTML. For example, if you put a required attribute on a field, the browser will not let you submit the form until you fill in that field. That’s validation: it checks against rules and rejects the data if it doesn’t meet the rules.

🧑🏿‍💻💬 Trainee: But then aren't all form elements validation?

🧑🏽‍💻💬 Mentor: You could say that all the rules you make about what the user can put in a field are also validation. Every type we just named - input type checkbox, input type email, number, date… are rules about data.

I think the difference is that there’s no way to type into a checkbox: there’s no error message, you just can’t do it. If you type your birthday into an email field, the browser will tell you that’s not a valid email address. So one is just impossible to do and the other gives you an error message, and that’s normally what we mean by validation.

Why is it important to validate data?

👨🏻‍💻💬 Trainee: Because if you don’t validate it, you might not be able to use it?

🧑🏾‍💻💬 Mentor: Right. Forms go wrong when you are vague. You must enforce input with validation, because if users can get it wrong, they will.

What will happen if you put a type of text on an input you label with email?

👨🏾‍💻💬 Trainee: Oh well then people will write in things that aren’t email addresses?

🧑🏿‍💻💬 Trainee: And you won’t know until you try to send them an email…

👩🏻‍💻💬 Mentor: Yeah they will. You can be absolutely guaranteed that users will do that. You have to save them from themselves, and save your database from your users!

📝Now practise with

Now try some of the built in form validation examples

In software development, we break down complex projects into smaller, manageable parts, which we work on for a week or two. These periods are called “sprints.”

A sprint backlog is like a to-do list. It lists what the team has decided to work on this sprint. It’s chosen from a larger list, usually called the “product backlog,” which holds the entire project to-do list.

In this course, the backlog is a set of work designed to build understanding beyond the concepts introduced in the course prep. For your course, we have prepared a backlog of mandatory work for each sprint. You will copy these tasks into your own backlog. You can also add any other tickets you want to work on to your backlog, and schedule all of the tasks according to your own goals and capacity. Use your planning board to do this.

You will find the backlog in the Backlog view on every sprint.

Copy the tickets you are working on to your own backlog. Organise your tickets on your board and move them to the right column as you work through them. Here’s a flowchart showing the stages a ticket goes through: