Review 3: From Code to the Web
- Terminology and concepts to look out for: source code · commit · deploy
- Relevance to me: The final exam is tomorrow. Today you review how code gets from a programmer to the web, and you finish your study guide.
- Board Question: A classmate missed November. Explain, in order, how source code becomes a page that anyone can open, using no more than four steps.
Open the discussion form on the right and answer Section 1 from your first reading.
From Source Code to the Web
This section reviews how a small web page goes from a plan to the web.
What the Page Must Do
The case is an example made up for this review: a small page for a school robotics club, which shows the room for the club's next meeting. Like every computer tool, the page has an input, processing and an output. When a member clicks Ask, the click is the input, the page's code that checks whether the meeting is canceled does the processing, and the message on the screen is the output. In a tool that uses a model, the model does the processing.
A specification says what the page must do before anyone builds it. A specification is made of requirements, and each requirement names a result that a person can observe. The requirement "The page shows the room number of the next meeting" can be tested by opening the page and looking, while the wish "The page should be fast" cannot be tested, because it names no number to check. A test has three parts: an input, an expected output and a comparison with what the page actually does. When the page changes, the same test inputs are run before and after the change, and each new output is set beside the old one.
Writing the Source Code
Source code is the text a programmer writes in a programming language. The club's page uses three languages, each with its own job. HTML says what is on the page, such as the Ask button and the line with the room. CSS says how each part looks, such as the font and color of the Ask button. JavaScript says what the page does when something happens, and that behavior is written as an event, a condition and an action. For example, the sentence "When a member clicks Ask, if the meeting is canceled, show 'No meeting this week'" names all three parts in that order.
The page a visitor sees in the browser is not the source code. The source code is the text the programmer wrote, which the browser reads to draw the page. For this reason, a wrong room number is fixed in the source code, not on the page a visitor sees.
A model can also generate source code from a specification, and wherever the specification is silent, the model fills the gap anyway with a choice of its own, called an assumption. In November, a model asked for a birthday program with no name given wrote "Friend" where a name belonged. An audit checks generated code against the specification: it tests each requirement and writes down "met" or "not met" for each one. (For Java, the compiler turns source code into bytecode, which runs on the Java Virtual Machine.)
Saving Each Version
The club's source code is kept in files, and each file's extension tells the computer what kind of file it is, so style.css holds CSS and gear.png holds a picture. A file path is the route from one file to another. For example, the page shows the club's logo with the path images/gear.png, which means the folder images and then the file gear.png inside it.
A commit saves a snapshot of the whole project at one moment, with a short message from the builder. Changing a file does not save it in the history, but committing does, and a repository holds the project's files together with their full history of commits. When the club moved its meeting, the builder changed one line of index.html and committed it with the message "Move the next meeting to Room 108." The diff of that commit marks each changed line with a sign: the removed line names Room 214 and starts with a minus sign, and the added line names Room 108 and starts with a plus sign. Figure 1 shows this diff under the commit step.
Putting the Page on the Web
To deploy a project means copying its files to a host, which is the step that puts the page on the web at its address. A host is a server that stays connected to the internet, and it stores a site's files and sends them to browsers. A committed file that has not been deployed is not on the live site, because until the next deploy the host keeps sending browsers the old page with Room 214, so members still see that room. Figure 1 shows the whole path in one row, from specification to live page.
Summary
A specification lists requirements that can be tested, and source code is the text a programmer writes to meet them. An audit tests each requirement, and a commit saves a snapshot of the project in its history, which a diff can show line by line. Deploying copies the files to a host, which puts the page on the web at its address.
Sources: Franchitti, Introduction to Computer Science, OpenStax (2024); NASA, Appendix C: How to Write a Good Requirement and 5.3 Product Verification (n.d.); Mozilla, What is JavaScript?, Introduction to events, Dealing with files, What is a web server? and Publishing your website (n.d.); Oracle, About the Java Technology (n.d.); Chacon and Straub, Pro Git (2014); Git project, git-diff Documentation (n.d.); CS I passages, Oct 26 to Nov 16 (2026); classroom data, the robotics club example repository (2026).
-
notebook cue: source code
The club's page shows last month's room. Is the fix made in the source code or on the page a visitor sees, and why?
Check
The fix is made in the source code. The page a visitor sees is drawn by the browser from the source code, so changing what one screen shows would change nothing, and the next visitor would still see the old room. See Writing the Source Code, paragraph 2.
-
notebook cue: commit
The builder changes the source code and runs the tests again. What still has to happen before the change is in the history?
Check
The builder has to commit the change with a message. Changing a file does not save it in the history, but a commit saves a snapshot of the project in the repository. See Saving Each Version, paragraph 2.
-
notebook cue: deploy
Which step puts the changed page where club members can open it?
Check
Deploying puts it there, because a deploy copies the files to the host, which sends them to any browser that opens the club's address. A committed change that has not been deployed is not on the live site. See Putting the Page on the Web and the last step of Figure 1.
-
notebook cue: source code
The club's page shows last month's room. Is the fix made in the source code or on the page a visitor sees, and why?
Check
The fix is made in the source code. The page a visitor sees is drawn by the browser from the source code, so changing what one screen shows would change nothing, and the next visitor would still see the old room. See Writing the Source Code, paragraph 2.
-
notebook cue: commit
The builder changes the source code and runs the tests again. What still has to happen before the change is in the history?
Check
The builder has to commit the change with a message. Changing a file does not save it in the history, but a commit saves a snapshot of the project in the repository. See Saving Each Version, paragraph 2.
-
notebook cue: deploy
Which step puts the changed page where club members can open it?
Check
Deploying puts it there, because a deploy copies the files to the host, which sends them to any browser that opens the club's address. A committed change that has not been deployed is not on the live site. See Putting the Page on the Web and the last step of Figure 1.
From Source Code to the Web
This section reviews how a small web page goes from a plan to the web.
What the Page Must Do
The case is an example made up for this review: a small page for a school robotics club, which shows the room for the club's next meeting. Like every computer tool, the page has an input, processing and an output. When a member clicks Ask, the click is the input, the page's code that checks whether the meeting is canceled does the processing, and the message on the screen is the output. In a tool that uses a model, the model does the processing.
A specification says what the page must do before anyone builds it. A specification is made of requirements, and each requirement names a result that a person can observe. The requirement "The page shows the room number of the next meeting" can be tested by opening the page and looking, while the wish "The page should be fast" cannot be tested, because it names no number to check. A test has three parts: an input, an expected output and a comparison with what the page actually does. When the page changes, the same test inputs are run before and after the change, and each new output is set beside the old one.
Writing the Source Code
Source code is the text a programmer writes in a programming language. The club's page uses three languages, each with its own job. HTML says what is on the page, such as the Ask button and the line with the room. CSS says how each part looks, such as the font and color of the Ask button. JavaScript says what the page does when something happens, and that behavior is written as an event, a condition and an action. For example, the sentence "When a member clicks Ask, if the meeting is canceled, show 'No meeting this week'" names all three parts in that order.
The page a visitor sees in the browser is not the source code. The source code is the text the programmer wrote, which the browser reads to draw the page. For this reason, a wrong room number is fixed in the source code, not on the page a visitor sees.
A model can also generate source code from a specification, and wherever the specification is silent, the model fills the gap anyway with a choice of its own, called an assumption. In November, a model asked for a birthday program with no name given wrote "Friend" where a name belonged. An audit checks generated code against the specification: it tests each requirement and writes down "met" or "not met" for each one. (For Java, the compiler turns source code into bytecode, which runs on the Java Virtual Machine.)
Saving Each Version
The club's source code is kept in files, and each file's extension tells the computer what kind of file it is, so style.css holds CSS and gear.png holds a picture. A file path is the route from one file to another. For example, the page shows the club's logo with the path images/gear.png, which means the folder images and then the file gear.png inside it.
A commit saves a snapshot of the whole project at one moment, with a short message from the builder. Changing a file does not save it in the history, but committing does, and a repository holds the project's files together with their full history of commits. When the club moved its meeting, the builder changed one line of index.html and committed it with the message "Move the next meeting to Room 108." The diff of that commit marks each changed line with a sign: the removed line names Room 214 and starts with a minus sign, and the added line names Room 108 and starts with a plus sign. Figure 1 shows this diff under the commit step.
Putting the Page on the Web
To deploy a project means copying its files to a host, which is the step that puts the page on the web at its address. A host is a server that stays connected to the internet, and it stores a site's files and sends them to browsers. A committed file that has not been deployed is not on the live site, because until the next deploy the host keeps sending browsers the old page with Room 214, so members still see that room. Figure 1 shows the whole path in one row, from specification to live page.
Summary
A specification lists requirements that can be tested, and source code is the text a programmer writes to meet them. An audit tests each requirement, and a commit saves a snapshot of the project in its history, which a diff can show line by line. Deploying copies the files to a host, which puts the page on the web at its address.
Sources: Franchitti, Introduction to Computer Science, OpenStax (2024); NASA, Appendix C: How to Write a Good Requirement and 5.3 Product Verification (n.d.); Mozilla, What is JavaScript?, Introduction to events, Dealing with files, What is a web server? and Publishing your website (n.d.); Oracle, About the Java Technology (n.d.); Chacon and Straub, Pro Git (2014); Git project, git-diff Documentation (n.d.); CS I passages, Oct 26 to Nov 16 (2026); classroom data, the robotics club example repository (2026).
Each table agrees on the steps in order, and on the step a newcomer would find hardest.
Chromebooks stay closed while your table talks. Sections 1 and 2 of the discussion form are already done. After you talk, finish Section 3 right here under My View. Submit before the exit ticket.
This form has three sections. Section 1: answer today's Board Question. Section 2: after the reading. Section 3 opens later in class. Today's Board Question: A classmate missed November. Explain, in order, how source code becomes a page that anyone can open, using no more than four steps.
CR 1. Board Question: A classmate missed November. Explain, in order, how source code becomes a page that anyone can open, using no more than four steps. Give your answer and one reason.
Write your answer in your lab notebook, labeled CR 1.
MC 1. Think about your answer to the board question. A classmate missed November. Explain, in order, how source code becomes a page that anyone can open, using no more than four steps. Which position is closest to yours now?
- The programmer writes the source code, and it goes on the web by itself.
- The source code is tested, committed to a repository, and deployed to a host.
- The source code is uploaded, and it turns into a page.
MC 2. (Reading claim 1) A commit saves a snapshot of the project in its history.
- Agree
- Disagree
MC 3. (Reading claim 2) A commit puts a page on the web.
- Agree
- Disagree
MC 4. (Reading claim 3) An audit tests each requirement.
- Agree
- Disagree
MC 5. (Reading claim 4) The page a visitor sees in the browser is the club's source code.
- Agree
- Disagree
MC 6. (Reading claim 5) In Figure 1, the diff under the commit step shows one line removed and one line added.
- Agree
- Disagree
MC 7. (Reading claim 6) In the club's example, "The page should be fast" is a requirement that can be tested.
- Agree
- Disagree
MC 8. (Reading claim 7) When a specification leaves out part of a page, a model asked for the code writes an assumption of its own into that part.
- Agree
- Disagree
MC 9. (Reading claim 8) After a commit and before the next deploy, a member who opens the club's address still sees Room 214.
- Agree
- Disagree
CR 2. (A different view) Write the view at your table that was most different from yours. If everyone agreed, write the strongest argument against your table's answer.
Write your answer in your lab notebook, labeled CR 2.
CR 3. Think about the Board Question again: A classmate missed November. Explain, in order, how source code becomes a page that anyone can open, using no more than four steps. Do you have the same opinion as when you first answered the board question? If it is the same, what from the reading or table talk reaffirmed your opinion? If it is different, what from the reading or table talk changed your opinion?
Write your answer in your lab notebook, labeled CR 3.