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.

In this lesson, students learn to define and call procedures (in JavaScript, procedures are called “functions”) in order to create and give a name to a group of commands for easy and repeated use in their code. They will be introduced to functions as a form of abstraction that enables them to write code in larger, more logical chunks and focus on what something does, rather than how it does it. As they explore the use of functions through a sequence of activities in App Lab, they will be asked to think about where they see the need for functions and how these functions can make their code clearer or more concise.

At the end of the lesson students review the concept of abstraction and are introduced to elements of the Create PT in preparation for the Practice PT at the end of the unit.

This lesson presents a top-down problem-solving strategy for designing solutions to programming problems. Students use a worksheet to learn about top-down design, and then on paper, design a solution to a new turtle drawing challenge with a partner. Having practiced this approach on paper and in code, students will be re-presented with the 3x3 square challenge from an earlier lesson and asked to improve upon their old solution by designing multiple layers of functions.

Students will learn to read App Lab’s API documentation and will use functions that accept parameters in order to complete a series of drawing puzzles which require them to make use of the App Lab API documentation to learn new drawing commands. Many of these commands will require the use of parameters. The final challenge asks students to design a personal monogram making use of the commands they learned during the lesson.

In this lesson, students practice using and creating functions with parameters. Students learn that writing functions with parameters can generalize solutions to problems even further. Especially in situations where feel like you are about to duplicate some code with only a few changes to some numbers, that is a good time to write a function that accepts parameters. In the second half of the lesson, students make a series of modifications to a program that creates an “Under the Sea” scene by adding parameters to functions to more easily add variation to the scene. Lastly, students are introduced to App Lab’s random number functions to supply random values to function calls so the scene looks a little different every time the program runs.

Students learn to use random values and looping to create variation in their drawings and quickly duplicate objects they wish to appear in their digital scenes many times. Students will be presented with a version of the for loop which only enables them to change the number of times the loop runs. This block is essentially a "repeat" block and will be presented that way. Students will also be presented with blocks which enable them to choose a random number within a given range. Together these blocks enable students to create more complex backgrounds for digital scenes by randomly placing simple objects within the background of their scene. Students use these tools to step through the Under the Sea exemplar digital scene.

To conclude their study of big data and cryptography, students will complete a small research project related to a dilemma presented by Big Data or Cybersecurity, in the form of a Practice Performance Task. Students will pick one of two issues to research more deeply - either an issue related to big data, or one related to cybersecurity. Students will need to identify appropriate online resources to learn about the functionality, context, and impact of the technological innovation that gave rise to the dilemma they are investigating. After completing their research, students will present their findings both in a written summary and with an audio / visual artifact they found online. The written components students must complete are similar to those students will see in the AP Performance Tasks.

This project is an opportunity to practice many of the skills students will use when completing the Explore Performance Task on the AP® Exam at the end of the year. While an open-ended research project might be intimidating, students have built all the skills they need to complete this task.

**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.

**Note for 2017-18 School Year:** This Practice PT has NOT been updated to reflect changes to the [Explore PT Scoring Guidelines](https://apcentral.collegeboard.org/pdf/2018-explore-performance-tasks-sg.pdf) released in Fall 2017. We recommend you review those guidelines to understand the similarities between this project and the actual Explore PT.