In this lesson students will conduct a small amount of research to explore a computing innovation that leverages the use of data. Students will research a topic of personal interest and respond to questions about about how that innovation produces, uses, or consumes data. The lesson is intended to give students practice with doing research of this nature and provides a small amount of scaffolding to help students figure out what to look for.

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 generate ideas for exploration later when students complete the actual Explore PT later in the year.

Students begin this lesson by investigating some of the world’s biggest data breaches to get a sense for how frequently data breaches happen within companies and organizations, and what kinds of data and information is lost or given up. Afterwards, students will use the Data Privacy Lab tool to investigate just how easily they could be uniquely identified with a few seemingly innocuous pieces of information. At the conclusion of the lesson, students will research themselves online to determine just how much someone could learn about them by conducting the same searches and “connecting the dots.”

This lesson focuses on the economic and consumer concerns around apps and websites that collect and track data about you in exchange for providing you a service free of cost. Often the quality of the service itself is dependent on having access to data about many people and their behavior. The main take-away of the lesson is that students should be more informed consumers of the technology around them. They should be able to explain some of the tradeoffs between maintaining personal privacy and using innovative software free of cost.

In this lesson, students are introduced to the need for encryption and simple techniques for breaking (or cracking) secret messages. Students try their own hand at cracking a message encoded with the classic Caesar cipher and also a Random Substitution Cipher. Students should become well-acquainted with idea that in an age of powerful computational tools, techniques of encryption will need to be more sophisticated. The most important aspect of this lesson is to understand how and why encryption plays a role in all of our lives every day on the Internet, and that making good encryption is not trivial. Students will get their feet wet with understanding the considerations that must go into making strong encryption in the face of powerful computational tools that can be used to crack it. The need for secrecy when sending bits over the Internet is important for anyone using the Internet.

In this lesson, students examine a classic problem in computer science, the Traveling Salesperson Problem (TSP). Students solve small instances of the problem, try to formulate algorithms to solve it, and discuss why these algorithms take a long time for computers (and humans) to compute. Students see how the TSP grows in size much faster than the problem of adding characters to a password. Even though we use encryption to motivate a desire to learn about computationally hard problems, they are valuable to know about, in and of themselves. This lesson covers some territory about how we reason formally and mathematically about algorithms and figuring out how “hard” something is for a computer to do.

In this lesson, students continue their exploration of computationally hard problems as they investigate a one-way function, a problem which is easy to construct in such a way that you know the solution, but it is computationally hard to solve. Students will begin the lesson by trying to solve the “Wireless Hotspot Problem” (also know as the vertex cover or dominating sets problem) to experience first-hand the challenge of solving it. They will then be instructed on how easy it is to create such a problem and will practice doing so themselves. In the Wrap-up, students are introduced to the concept of a one-way function and consider why such problems might be useful tools when constructing methods of encryption. If it’s easy to create a problem that is hard for a computer (or human!) to solve, then perhaps it is possible to make truly secure encryptions.

In this lesson, students learn about the relationship between cryptographic keys and passwords. Students explore the Vigenère cipher with a widget to examine how a cryptographic "key" can be used to encrypt and decrypt a message. Then, students use a tool that shows them about how long it would take to crack a given password using a standard desktop computer. Students experiment with what makes a good password and answer questions about the “human components” of cybersecurity.

This is a big multi-part lesson that introduces the concept of public key cryptography which is an answer to the crucial question: *How can two people send encrypted messages back and forth over insecure channels (the Internet) without meeting ahead of time to agree on a secret key?* In a nutshell, there are two main principles we want students to understand:

1. The mechanics of communication with public key cryptography
2. The basic mathematical principles that make it possible

The lesson gets at these two core ideas through a deliberate chain of thought experiments, demonstrations, activities and widgets. All parts are building blocks that lead to deeper understanding of how it works.

This lesson attempts to walk students through the iterative development process of building an app (basically) from scratch that involves the use of `if` statements. Following an imaginary conversation between two characters - Alexis and Michael - students follow the problem solving and program design decisions they make for each step of constructing the app. Along the way they decide when and how to break things down into functions, and of course discuss the logic necessary to make a simple game.

The last step - writing code that executes an end-of-game condition - students must do on their own. How they decide to use `if` statements to end the game will require some creativity. The suggested condition - first to score 10 points - is subtly tricky and can be written many different ways.

At the conclusion of the lesson there are three practice Create PT-style questions as well as resources explaining the connection between this lesson and the actual Create PT. Depending on how you use these materials they can easily add an additional day to this lesson.

This lesson demonstrates how a slight manipulation of a conditional statement can allow for the creation of a new and powerful tool in constructing programs, a **while** loop. Students are introduced to a **while** loop by analyzing the flow chart of a conditional statement in which the "true" branch leads back to the original condition. Students design their own flowcharts to represent a real-world situation that could be represented as a **while** loop, and they learn how to recognize common looping structures, most notably infinite loops. Students then move to App Lab, creating a **while** loop that runs exactly some predetermined number of times. While learning about creating **while** loops, students will be introduced to many of the common mistakes early programmers make with **while** loops and will be asked to debug small programs. They finally progress to putting if statements inside a while loop to count the number of times an event occurs **while** repeating the same action. This activity will recall the need for counter variables and foreshadows their further use in the following lesson.

In this lesson, students gain more practice using **while** loops as they develop a simulation that repeatedly flips coins until certain conditions are met. The lesson begins with an unplugged activity in which students flip a coin until they get 5 heads in total, and then again until they get 3 heads in a row. They will then compete to predict the highest outcome in the class for each statistic. This activity motivates the programming component of the lesson in which students develop a program that allows them to simulate this experiment for higher numbers of heads and longer streaks.

This lesson introduces arrays as a means of storing lists of information within a program. The class begins by highlighting the difficulties that arise when trying to store lists of information in a variable. Students then watch a short video introducing arrays and a subset of the operations that can be performed with them. Students will work in Code Studio for the remainder of the class as they practice using arrays in their programs. At the conclusion of the sequence, students build a simple app which can be used to store and cycle through a list of their favorite things. In the next lesson, students will continue working with a version of this app that can display images and not just text strings.

Students will extend the **My Favorite Things** app they built in the previous lesson so that it now manages and displays a collection of images and responds to key events. Students are introduced to the practice of refactoring code in order to keep programs consistent and remove redundancies when adding new functionality. As part of learning to use key events, students are shown that event handlers pass a parameter which contains additional information about the event. This lesson also serves as further practice at using arrays in programs.

This lesson will probably take two days to complete. It introduces students to algorithms that process lists of data. The students will do two unplugged activities related to algorithms and program some of them themselves in App Lab. The **for** loop is re-introduced to implement these algorithms because it’s straightforward to use to process all the elements of a list. The lesson begins with an unplugged activity in which students write an algorithm to find the minimum value in a hand of cards. Students then move to Code Studio to write programs that use loops and arrays. Students are shown how to use a **for** loop to visit every element in an array. Students use this pattern to process an array in increasingly complex ways. At the end of the progression, students will write functions which process arrays to find or alter information, including finding the minimum value - a problem they worked on in the unplugged activity. Finally, an unplugged activity has students reason about linear vs. binary search and attempt to write pseudocode for a binary search.

In this lesson students are introduced to the **return** command and learn to write their own functions that return values. Students first complete a simple unplugged activity based on the game **Go Fish** to introduce the concept of a return value. They will then complete a short sequence of exercises in Code Studio, which introduces preferred patterns for writing functions that return values. At the end of the sequence, students write and use functions that return values in a simple turtle driver app.

To conclude their introduction to programming, students will design an app based off of one they have previously worked on in the programming unit. Students will choose the kinds of improvements they wish to make to a past project in order to show their ability to make abstractions and implement complex algorithms. The project concludes with reflection questions similar to those students will see on the AP® Create Performance Task. Students can either complete the project individually or with a partner. Every student will need a collaborative partner with whom they will give and receive feedback.

Students continue to practice working with arrays and are introduced to a new user interface element, the canvas. The canvas includes commands for drawing simple geometric shapes (circles, rectangles, lines) and also triggers mouse and key events like any other user interface element. Over the course of the lesson, students combine these features to make an app that allows a user to draw an image while recording every dot drawn on the canvas in an array. By processing this array in different ways, the app will allow students to redraw their image in different styles, like random, spray paint, and sketching. Along the way, students use their knowledge of functions with return values to make code which is easy to manage and reuse.

Students will be introduced to a new feature of App Lab: **Design Mode**. Design Mode allows students to easily design the User Interface (UI) of their apps using a drag-and-drop editor. Students learn how to create UI elements they have seen before such as images, text labels and buttons, but they will see many more options for styling these elements with colors, font sizes and so on. Students also learn how to add **event handlers** - code that listens for and responds to user-events. Students also explore some common errors that come up in event-driven programming and will learn some important skills for debugging programs, chief among them being responding to error messages. Students end the lesson by creating the foundation of a simple "chaser game" which they will add onto in the next lesson.

Students continue learning about Event Driven programming in this lesson by learning how to add multiple "screens" to an app and adding code to switch between them. More techniques of debugging are presented, namely using `console.log`, a command that allows them to print out text which the user cannot see. It is useful for displaying messages to yourself to figure out what is happening as your program runs. Students will end the lesson by creating an improved version of the “chaser” game which has multiple screens.

This lesson gives students time to familiarize themselves with the process of making event-driven apps before we move on to deeper content. They will design and create a (minimum) 4-screen app on a topic of their choosing. There are some other constraints on the project to help guide students in their thinking. Students are also encouraged to do independent work, but alongside a "coding buddy" or "thought partner" to be a help along the way.

**Note:** This activity **is not intended to be a Practice PT** but could be used similarly. The aim is to give an opportunity to get comfortable with Design Mode and the structure of event-driven programming in a creative way. Another goal is to intentionally build in an environment of informal collaboration, even when doing individual work. Suggestions for containing the scope of the project and amount of time allocated to it can be found in the lesson plan.