Students get their first look at the inside of their own video games. They will start development by substituting in new Images, Strings, and Numbers for existing variables.

Returning to the Big Game we started in stage 7, students will use the Design Recipe to develop functions that animate the Target and Danger sprites in their games.

Booleans are the fourth and final data type that students will learn about in this course. In this stage, students will learn about Boolean (true/false) values, and explore how they can be used to evaluate logical questions.

Using Boolean operators, students will write code that compares values to make logical decisions.

Using Boolean operators, students will write code that checks the location of a sprite to make sure it doesn't go off-screen.

Using the same logic from the previous lesson, students will write code that checks whether their Target and Danger sprites have left the screen. If their function determines that a sprite is no longer visible on screen, it will be reset to the opposite side.

Currently, even when passing parameters to functions, our outputs follow a very rigid pattern. Now, suppose we want parameters with some values to create outputs using one pattern, but other values to use a different pattern. This is where conditionals are needed. In this stage students will learn how conditional statements can create more flexible programs.

Using conditionals, students will write functions and programs that change their behavior based on logical evaluation of input values.

In this lesson students explore the benefits (and potential security concerns) associated with routing traffic across the Internet. Building on their introduction to IP addresses in the previous lesson, students use a version of the Internet Simulator that allows messages to be sent only to an intended recipient, as indicated by the IP address. The Internet Simulator also allows students to examine the traffic that goes through all of the (simulated) routers on the network. They will discover that messages go through many different routers, may not always take the same path to reach the final destination, and that the routers (and their owners) can *see all of this traffic*!

In this and the subsequent lesson, we consider some of the strategies used to construct networks and find paths for data in them. While this has a connection to ideas about the Internet, the focus of these lessons is on algorithms, formal techniques, and processes for solving problems. Students will explore and solve the Minimum Spanning Tree (MST) problem, first, in an unplugged fashion on paper. The real challenge is not in solving a particular instance of the minimum spanning tree, but to develop an algorithm, a clear series of steps, that if followed properly, will solve any instance of the problem. There is a possible misconception to look out for: the MST has a definite, verifiable optimal solution, as opposed to the Text Compression problem (from Unit 1), which does not.

In this lesson students will explore the Single Source Shortest Path problem, by solving the problem with pencil and paper first, then by following a famous algorithm that solves the shortest path problem known as Dijkstra’s Algorithm. Even though this is an algorithms detour, there is a strong connection in this lesson to routing algorithms used on the Internet. This lesson also introduces ideas about how we analyze algorithms: looking for correctness, efficiency and running time. As foreshadowing: in the next lesson students will act out another distributed shortest path algorithm used by routers to learn about the Internet dynamically.

This lesson is the last of the algorithm series. Building off of the previous lesson about shortest path algorithms, the activity in this lesson shows how routers learn about the rest of the Internet in order to route traffic so it takes the shortest path. In the previous lessons, students use the Internet Simulator to send packets to other students through simulated routers. The path that the packet follows, and how the router knows where to send it, however, has been largely untouched. Today, students simulate the process of a router joining a network and generating a router table that would allow them to send packets to anyone else in their network as efficiently as possible. They then reflect on the process by comparing the similarities between the SSSP problem and the process the used today, and how it facilitates the structure of the Internet.

In this lesson student develop a protocol for reliably sending a message over an unreliable internet. The Internet Simulator has been setup for this lesson to restrict messages to no more than 8 characters each, and messages get dropped messages with some probability on every hop.

Students are given time to experiment with the Internet Simulator and develop their own protocol, possibly testing or demonstrating their protocol to their peers. At the conclusion of the lesson, students watch a short video explaining how these challenges are addressed in the real world with [v TCP] - the Transmission Control Protocol.

The core idea of this lesson occurs in the unplugged activity that kicks off the lesson, in which students try to keep track of IP addresses that had been randomly assigned to each student in the class, while at the same time the teacher occasionally changes students' addresses. This leads to identifying the need for an authoritative system for name-to-address mappings, known as the Domain Name System or [v DNS].

Students then briefly experiment with a DNS protocol in the Internet Simulator. The activity is similar, in that students will have to grapple with IP addresses changing in real time and use the built in DNS protocol to resolve the issues.

The lesson ends with students doing some rapid research about DNS and some of its vulnerabilities, particularly what are known as Denial of Service Attacks.

In this lesson students are introduced to another high-level protocol of the Internet, [v HTTP]. The lesson begins with a review of the layers of the Internet covered thus far, before transitioning to a video covering high-level protocols of the Internet, most notably HTTP. Students will investigate HTTP traffic generated within their own browser by accessing the browser’s developer tools and visiting a variety of websites. A handout summarizing the structure of HTTP is provided to help students understand the components of the HTTP requests and responses they will observe. The lesson concludes with students sharing their findings with their classmates and a reflection on how the layers of the Internet make use of abstraction.

This lesson is a capstone to the Internet unit. Students will research and prepare a flash talk about an issue facing society: either **[v Net Neutrality]** or **Internet Censorship**. Developing an informed opinion about these issues hinges on an understanding of how the Internet functions as a system. Students will prepare and deliver a flash talk that should combine forming an opinion about the issue and an exhibition of their knowledge of the internet.

This lesson is good *practice* for certain elements of the AP Explore Performance Task.1 The primary things practiced here are: doing a bit of research about impacts of computing (though here it’s specifically about the Internet), explaining some technical details related to ideas in computer science, and connecting these ideas to global and social impacts. Students will practice synthesizing information, and presenting their learning in a flash talk.

1**Note:** This is NOT the official AP® Performance Task that will be submitted as part of the Advanced Placement exam; it is a practice activity intended to prepare students for some portions of their individual performance at a later time.

Welcome to Computer Science Principles! The first lesson is about getting students excited about the course and connecting their own personal interests to computer science. Students are asked to share something they know a lot about and teach it to a small group. Groups make a “rapid” prototype of an innovative idea and share it. Students watch a brief video about computing innovations. The lesson ends with students logging into the Code.org CSP course web site, and answering a brief prompt about what “computer science” means to them.

In this lesson students work in groups using classroom supplies and everyday objects to develop their own systems for encoding and sending simple binary messages, messages that only have two possible values. Students will think about what can be usefully conveyed in such a simple message and build a “device” to communicate the message over some physical distance.
Then students are asked to consider how to use their binary messaging devices to send a more complex message - a message with more than two possibilities, say four, or eight, or even thousands of different messages. Students will collaborate in an iterative design process in the “maker ethos” of rapidly building and improving their “device” for sending messages.

In this lesson, students will be introduced to how bits are transmitted over the most common mediums (copper wire, fiber-optic cable, and radio waves) used to connect devices on the Internet. They then chose a device that transmits bits and research that device and the system it uses. Students create a poster presenting their findings, and the lesson concludes with a gallery walk of the posters.

Students are introduced to the Internet Simulator, a tool they will return to many times in the first two units of the course. Today, the Internet Simulator will be used to simulate a single shared wire, connecting two people. The wire can only be in one of two possible states (state A or state B) and either partner may set or read the state of the wire at any time, but this is the only way in which students may communicate. Students must invent a binary call-response [v protocol] using this system. Coordination, speed and timing are problems that need to be solved. At the conclusion of the lesson, students compete to demonstrate the speed and accuracy of their protocols, and calculate the [v bit rate] of their message exchange.