Computing · JC 2

Active learning ideas

NoSQL and Alternative Data Stores

Active learning works for handling user input because students learn best when they see immediate consequences of their code. Typing wrong data into a program makes errors real, not theoretical, so debugging becomes a concrete skill rather than abstract advice. Students remember validation and type conversion when they have to fix a crashing program in real time.

• MOE Syllabus Outcomes
• MOE H2 Computing (Syllabus 9569), Section 3: Data and Information - 3.2 Databases (NoSQL Database Concepts)
• MOE H2 Computing (Syllabus 9569), Section 3: Data and Information - 3.2 Databases (Document-Oriented Databases and JSON)

• 25–45 min
• Pairs → Whole Class
• 4 activities

Activity 01

• Four Corners
• 30 min · Pairs

Pair Programming: Greeting App

Pairs write a program that prompts for a user's name and age, then outputs a personalized message. Add input validation to ensure age is a number. Test with classmates, swapping roles as user and programmer.

What are the limitations of relational databases?

Facilitation Tip

During the Pair Programming Greeting App, have one student act as the driver typing live code while the navigator checks for missing type conversions or empty strings.

What to look for

Provide students with a short code snippet that takes a number as input. Ask them to write down what the output will be if the user enters '10' and what the output will be if the user enters 'ten'. Explain why the outputs differ.

• Understand
• Analyze
• Evaluate
• Self-Awareness
• Social Awareness

Activity 02

• Four Corners
• 45 min · Small Groups

Small Groups: Menu Selector

Groups build a menu-driven program for restaurant orders, using loops to handle choices until 'exit'. Include input sanitization for numbers. Demo to class and note improvements.

How does a document-oriented database store data?

Facilitation Tip

For the Menu Selector, provide a starter file with placeholder options and ask groups to test each branch with invalid inputs like ‘quit’ or ‘exit’ to see which cases crash.

What to look for

Present students with a scenario: 'A program asks for a user's age.' Ask them to list two potential problems with the input and suggest one way to validate the input to prevent those problems.

• Understand
• Analyze
• Evaluate
• Self-Awareness
• Social Awareness

Activity 03

• Four Corners
• 25 min · Whole Class

Whole Class: Input Debug Relay

Project buggy input code on screen. Class suggests fixes in turns, coding live. Vote on best solutions and run tests with volunteer inputs.

When is it more appropriate to use NoSQL over SQL?

Facilitation Tip

In the Input Debug Relay, give each pair a buggy snippet and a set of test inputs; they must run the code, note the failure, and propose a fix in under two minutes.

What to look for

Facilitate a class discussion using the prompt: 'Imagine you are designing a simple quiz program. What are three different ways a user might interact with your program to provide answers, and what are the potential challenges with each input method?'

• Understand
• Analyze
• Evaluate
• Self-Awareness
• Social Awareness

Activity 04

• Four Corners
• 35 min · Individual

Individual: Quiz Validator

Students extend a quiz program to accept answers via input, score them, and reprompt on errors. Share final code via shared drive for peer review.

What are the limitations of relational databases?

Facilitation Tip

For the Quiz Validator, give students a rubric that checks for empty answers, non-numeric quiz scores, and negative numbers, so they learn validation by grading each other’s outputs.

What to look for

Provide students with a short code snippet that takes a number as input. Ask them to write down what the output will be if the user enters '10' and what the output will be if the user enters 'ten'. Explain why the outputs differ.

• Understand
• Analyze
• Evaluate
• Self-Awareness
• Social Awareness

A few notes on teaching this unit

Start by modeling how input() returns strings and why int(input()) can crash if the user types ‘ten’. Avoid the trap of assuming students understand type conversion without concrete examples. Research shows that students retain debugging skills better when errors come from their own code rather than pre-written demos. Emphasize small, tested changes: fix one input case, run, repeat, instead of rewriting everything at once.

Successful learning looks like students writing programs that capture input, validate it, and respond appropriately without crashing. They should explain why input() returns a string, how to convert it safely, and how to loop until correct data arrives. By the end, they can handle both expected mistakes and unexpected empty entries with confidence.

---

Watch Out for These Misconceptions

• During Pair Programming: Greeting App, students may think programs accept numbers directly without conversion.

  While pairs type the greeting, have the navigator deliberately type a number like 5 instead of a name. When the program crashes, pause to rewrite the input line as name = str(input('Enter your name: ')), then show how int(input()) would fail if they tried to use the name as a number.

• During Menu Selector, students may overlook empty menu choices.

  Ask each group to run their menu with an empty string as input. When the program crashes, they must add a condition like if choice == '': choice = menu[0] and rerun to confirm it now handles empty inputs without failing.

• During Input Debug Relay, students may believe user input is safe by default.

  Give pairs a snippet that prints the user’s name directly. Have them type a name containing a SQL quote like O'Reilly. When the output breaks formatting or shows an error, they must sanitize the input by stripping quotes before printing, turning the demo into a teachable moment about injection risks.

---

Methods used in this brief

• Four Corners