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.

Students will explore the properties of number systems by effectively inventing a base-3 number system using circles, triangles and squares as the symbols instead of arabic numerals. Students are asked to create rules that explain how each arrangement of symbols can be generated or predicated as an orderly, logical series. The objective is to understand that you can represent *any* number with any agreed-upon set of symbols that appear in an agreed-upon order. This is as true for circles, triangle and squares as it is for the digits 0-9, or the number systems we commonly see in computer science (binary and hexadecimal).

In this lesson, students will gain more familiarity with binary numbers. The lesson will transition away from the number systems that students created in the the circle-triangle-square activity, and begin to focus on representing numeric values using the binary number system. Though students have communicated with binary before, developing a *number system* is a little different. Previously, students mapped patterns of binary values to a small set of fixed messages. A number system is infinite, and also has rules for counting - or how to get from one value to the next.

In this lesson, students explore some fascinating stories from the news and history (and the future) about number encodings in computers. These stories should serve to illuminate how the kinds of decisions students have been making about number encodings are the same kinds of things that real scientists in the world have to worry about, sometimes with disastrous consequences. While this lesson has the possibility of running long, it is meant only as a short excursion into real-world application and should be limited to one class period.

In this lesson students will return to the Internet Simulator in order to send a simple line drawing to a classmate. Students will be presented a grid on which they will draw an image (connecting 3-7 dots with straight lines). They must develop a protocol which will allow them to send any image they might create on their grids, paying particular attention to how many bits are used to represent each binary number. Students will therefore have additional practice encoding and decoding binary numbers and develop further intuitions about the properties of binary numbers in a hands-on way. The lesson concludes by testing protocols using a teacher-supplied test-image to transmit.

In this lesson, students create their own system for representing text in binary and explore how their newfound ability to convert between binary and decimal numbers helps in this process. In the warm up students quickly create a system for representing the 50 states in binary. They then move to the main activity where they create a system for representing text using only numbers while communicating on the Internet Simulator. At the end of the main activity they briefly review the ASCII system. The wrap up discussion introduces the concept of abstraction and its connection to the chapter. Following this lesson there is a chapter assessment that reviews the contents of this and the previous lessons.

This lesson sets the the stage for why we want to learn about how the Internet works. First students share what they currently know about how the Internet works through a KWL activity.

Then students watch a short video the introduces Vint Cerf and the Internet at high level. Students then skim a memo written to the Internet Engineering Task Force (IETF) by Vint Cerf in 2002 entitled “The Internet is for Everyone,” which calls out a series of threats to the prospect that the Internet should be an open, easily and cheaply accessible resource for everyone on the planet.

Finally we foreshadow the practice PT at the end of the unit. Many of the questions and challenges raised by Vint Cerf still apply today, and students will be asked to research and present on one for the Practice PT.

In this lesson, students explore more deeply how communication between multiple computers can work over the Internet. They do this by playing a simplified game of Battleship, in which the first game is played unplugged, in their table groups, and the second game is played using the Internet Simulator, so that multiple students can connect to each other and see each other’s messages. Students must devise a messaging protocol that makes it clear who is sending the message and who the intended recipient is.

Students then devise a *binary protocol* for playing this game which will entail developing an addressing system for players, as a well as a formal packet structure for transmitting data about the state of the game.

**NOTE**: this is a large lesson that will likely need to span 2 days of class.

In this lesson students are introduced to the standard units for measuring the sizes of digital files, from a single byte, all the way up to terabytes and beyond. Students begin the lesson by comparing the size of a plain text file containing “hello” to a Word document with the same contents. Students are introduced to the units kilobyte, megabyte, gigabyte, and terabyte, and research the sizes of files they make use of every day, using the appropriate terminology. This lesson foreshadows an investigation of compression as a means for combatting the rapid growth of digital data.

At some point we reach a physical limit of how fast we can send bits and if we want to send a large amount of information faster, we have to find a way to represent the same information with fewer bits - we must **compress** the data.

In this lesson, students will use the Text Compression Widget to compress segments of English text by looking for patterns and substituting symbols for larger patterns of text. After some experimentation students are asked to come up with a process (or algorithm) for arriving at a "good" amount of compression despite the fact that there is no way to know what is best or optimal. In developing a so-called "[v heuristic] approach" to this problem, students will grapple with the tradeoffs in compressing data and begin to develop a sense of computing problems that are “hard” to solve.

In this lesson, students will begin to explore the way digital images are encoded in binary. The class begins by asking students to invent their own image encoding protocol in order to familiarize themselves with some of the subtle complications of encoding images, namely the need for other data, called [v metadata], that describes properties of the image necessary for rendering it. Students will learn about pixels, raster images, and what an image file format is. Students will encode binary image data using a widget in Code Studio.

In this lesson students are asked to consider how color is represented on a computer and to imagine how it might be encoded in binary. Students then learn about how color is actually represented on a computer - using the RGB color scheme - and create their own images in an new version of the pixelation widget that allows you use more than 1 bit per pixel to represent color information. After grappling with the prospect of possibly many bits just to represent a single pixel, students are shown how using hexadecimal allows us to represent many bits with fewer characters. Students use a new version of the pixelation tool to encode an image with color and create a personal favicon.

Students learn the difference between lossy and lossless compression by experimenting with a simple lossy compression widget for compressing text. Students then research three real-world compressed file formats to fill in a research guide. Throughout the process they review the skills and strategies used to research computer science topics online, in particular to cope with situations when they don't have the background to fully understand everything they're reading (a common situation even for experienced CS students).

In this lesson students will conduct a small amount of research to explore a file format either currently in use or from history. Students will conduct research in order to complete a "one-pager" that summarizes their findings. They will also design a computational artifact (video, audio, graphic, etc.) that succinctly summarizes the advantages of their format over other similar ones.

This lesson is intended to be a quick, short version of a performance task in which students rapidly do some research and respond in writing. It might take 2 class days but should not take more. The goal is to develop skills that students will use when they complete the actual Explore PT later in the year.

To conclude their introduction to programming, students will design a program that draws a digital scene of their choosing. Students will be working in groups of 3 or 4 and will begin by identifying a scene they wish to create. They will then use Top-Down Design to identify the high-level functions necessary to create that image. The group will then assign these components to individual members of the group to program. After programming their individual portion, students will combine all of their code to compose the whole scene. The project concludes with reflection questions similar to those students will see on the AP® Performance Tasks.

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.

AP® is a trademark registered and/or owned by the College Board, which was not involved in the production of, and does not endorse, this curriculum.

At the beginning of a new unit we jump right into an activity - building a small arrangement of LEGO® blocks and then creating text instructions a classmate could follow to construct the same arrangement. Groups will then trade instructions to see if they were clear enough to allow reconstruction of the original arrangement. The wrap-up discussion is used to highlight the inherent ambiguities of human language and call out the need for the creation of a programming language which leaves no room for interpretation.

This is the 2nd day of a 3-lesson sequence in which we attempt to show the "art" of programming and introduce the connection between programming and algorithms. In the previous lesson we established the need for a common language with which express algorithms to avoid ambiguity in how instructions would be interpreted. In this lesson we continue to establish the connection between programming and algorithms, with more emphasis on the "art" of algorithms.

First students are presented with a new task for the “human machine” - to write a set of instructions to identify the smallest (lowest value) card in row of cards on the table. Once again we try to establish a set of fundamental commands for doing this, and develop a more formal set of “low-level” commands for manipulating playing cards. Students are presented with a "Human Machine Language" that includes 5-commands and then must figure out how to use these primitive commands to “program” the same algorithm.

At the conclusion several points about programming can be made, namely: 1. Different algorithms can be developed to solve the same problem 2. Different programs can be written to implement the same algorithm.

This is the third of three lessons that make the connection between programming and algorithms. In this lesson students continue to work with the "Human Machine Language" to get creative designing more algorithms for playing cards. One command is added to the language from the previous lesson (SWAP) that allows positions of cards to change. With the addition of swap the challenge is to design an algorithm that will move the minimum card to the front of the list while keeping the relative order of all the other cards the same. If that is achieved some other Human Machine Language challenges are available.

This lesson is a student's first exposure to programming in App Lab. The lesson begins with a quick reflection prompt. Then students are introduced to the practice of pair programming before beginning to program. For this lesson the students' view is limited to only a very few simple “turtle” commands to draw graphics on the screen. After a few warm up exercises, using only combinations of four drawing commands, students must figure out the most “efficient” way to draw an image of a 3x3 grid. The lesson concludes with a sense-making discussion about the meaning of efficiency in programming and the reason behind beginning with such a limited set of programming tools.