Automated accessibility tools can find useful problems, but a passing scan does not prove that a page is accessible. This lab asks students to use an AI-assisted scan, verify one finding independently and document the limits of the tool.

Goal

Use an accessibility scanner as evidence—not as an answer—and connect one reported issue to the page’s HTML and a relevant WCAG principle.

Activity

1. Choose a small public practice page or a local HTML file containing no private or student information. Save an untouched copy.
2. Start Stark’s no-card two-week trial and add the Stark connector from Claude’s connector directory.
3. Ask Claude and Stark to scan one URL or source file. Have Claude group the findings by severity and explain the highest-priority item in plain language.
4. Independently check one finding. Use the HTML inspector plus a manual test such as keyboard-only navigation, heading-outline review, form-label inspection or alternative-text review.
5. Correct one confirmed problem in the HTML. Scan again and compare the result.
6. Identify one thing the automated scan could not establish, such as whether alternative text communicates the image’s purpose or whether the keyboard order makes sense to a person.

Deliverable

Submit:

• the original and revised HTML fragment;
• the scanner’s finding and the applicable accessibility principle;
• the result of the independent manual check;
• a 100–150 word note explaining whether the AI-assisted recommendation was correct, incomplete or misleading.

Do not submit credentials, private URLs, student records or a full AI conversation containing sensitive context.

Discussion and safety

• Why is “no detected violations” different from “accessible”?
• Who remains responsible when an AI tool proposes a code change?
• What evidence should accompany an accessibility claim?
• Set a reminder to cancel or evaluate the Stark trial before it ends. The trial is not a permanently free plan.

Source material

This lab was first developed from the PTIR Morning Briefing for August 22, 2026. Stark’s announcement introduced a Claude connector that can scan URLs, source code, Figma files, mobile builds and Storybook libraries, then surface and discuss violations inside Claude. That workflow generated the lab because beginning web students need practice separating automated findings from independently verified accessibility evidence.

Consult the original announcement: Stark brings accessibility to Claude.

Floating-point arithmetic follows finite computer representations, not the exact rules of real-number algebra. This short lab makes that difference visible.

Goal

Show that regrouping the same floating-point values can change the computed result, then explain why a performance optimization may trade away reproducibility.

Activity

Run this Kotlin program:

fun main() {
    val a = 1.0e16
    val b = -1.0e16
    val c = 1.0

    println((a + b) + c)
    println(a + (b + c))
}

Then:

1. Record both outputs.
2. Calculate both expressions as exact real-number arithmetic.
3. Identify where the small value is lost in the computer calculation.
4. Read the Rust 1.98 explanation of its new algebraic floating-point methods. Those methods permit reordering for optimization and may produce different results across compiler choices.

Deliverable

Submit the two outputs and a three-sentence explanation:

• Why are the mathematical expressions equivalent?
• Why can the computer results differ?
• When would speed matter more than bit-for-bit reproducibility, and when would reproducibility matter more?

Discussion

Floating-point addition is not associative in ordinary computer arithmetic. Reordering can enable faster vectorized work, but it may change results. Financial totals, scientific comparisons, tests and preserved data pipelines may need stricter reproducibility than graphics or approximate simulations.

Source material

This lab first appeared in the PTIR Morning Briefing for August 21, 2026. Rust 1.98 introduced explicit algebraic floating-point methods that let the compiler reorder operations for optimization while warning that the result can be nondeterministic. That made the release a useful starting point for a language-independent lesson on representation, optimization and reproducibility.

Consult the authoritative source: Rust 1.98 release announcement.

This short lab shows why an old link can become unsafe even when the page containing it never changes.

Goal

Explain how domain expiration changes the ownership and trust boundary of a link.

Safety rule

Use only the reserved domains in the supplied mock inventory, such as example.com and names ending in .invalid. Do not register, purchase, probe, or visit an expired domain.

Activity

1. Create a small link inventory with these fields: source page, linked domain, purpose, owner, renewal status, and replacement.
2. Add five fictional links. Include one project download, one image, one JavaScript library, one old organization, and one email domain.
3. Mark two domains as expired and reassigned to an unknown owner.
4. For each affected link, identify the possible impact: misleading redirect, malware delivery, lost image, compromised dependency, misdirected email, or broken historical evidence.
5. Choose the safest response: remove the link, replace it with a verified official source, preserve a non-executable archival copy, or keep it with a warning and date.

Deliverable

Submit the completed inventory and a short paragraph answering: Why can a trusted old page become risky without being edited?

Discussion

• Which is more serious: a broken citation, a script loaded from an abandoned domain, or mail sent to an expired domain?
• When does an archived copy preserve history without preserving an unsafe live dependency?
• What should an organization record before intentionally retiring a domain?

Source material

First spotted in PTIR: August 20, 2026, Morning Briefing.

Infoblox Threat Intel documented criminal acquisition of expired domains that retained traffic, backlinks, reputation, email, and other lingering connections from prior owners. The report generated this lab because link maintenance sits at the intersection of web development, cybersecurity, software supply chains, and digital preservation. The classroom version uses fictional records and reserved domains so students can reason about the risk without touching live infrastructure.

Consult the original Infoblox Threat Intel report

AI watermarks can provide evidence, but students need to distinguish what the evidence supports from what people may assume it proves.

Goal

Evaluate the strength and limits of a machine-readable AI provenance signal.

Activity

1. Read Anthropic’s descriptions of a detected mark and an absent mark.
2. Evaluate these four cases:
   • Claude generated an entire response.
   • Claude proofread a student’s original paragraph.
   • Claude translated human-written text.
   • AI-generated text was heavily edited or mixed with human writing.
3. For each case, write what a detected Claude mark would support, what it would not prove, and what additional evidence would be needed.
4. Compare text watermarking with C2PA metadata on a generated image or file. Identify one way each signal can be lost or changed.

Deliverable

Submit a four-row evidence table and a 100-word policy recommendation explaining how an instructor should—and should not—use watermark detection.

Discussion and safety

A detected mark indicates that supported Claude technology may have processed the content. It does not establish who originated the ideas, how much AI assistance occurred, or whether a course rule was violated. An absent mark does not prove that content is human-authored. Do not use a detector result alone to accuse or penalize a student.

Source material

First spotted in PTIR: August 12, 2026, Morning Briefing.

Anthropic documented embedded text watermarks and signed C2PA provenance metadata for supported Claude models and files. Its limitations are what generated this lab: a positive result may reflect generation, proofreading, translation, summarization, or file conversion, while heavy editing, short passages, older models, unsupported platforms, or stripped metadata can produce no detectable mark.

Consult Anthropic’s official marking documentation

Different programming interfaces can make the same language feel easier or harder without changing the underlying concepts.

Goal

Compare a frame-based Python editor with ordinary text editing using the same small program.

Activity

1. Open Strype and a normal text editor or browser Python editor.
2. Build the same short program in both environments. Include at least one loop and one nested conditional.
3. In each version, make the same structural change—for example, move a condition inside the loop or add another branch.
4. Export or inspect the resulting Python source from Strype.
5. Compare the two experiences.

Questions

• Which interface made nesting easier to see?
• Which made editing faster?
• Which errors were harder to create?
• Did the frame interface reduce confusion or add extra steps?
• Does exporting standard Python reduce lock-in concerns?

Deliverable

Submit both versions and a short recommendation: Which interface would you give a beginning student first, and why?

Source material

First spotted in PTIR: August 10, 2026, Evening Briefing.

Strype is a free, open-source browser-based Python editor that represents program structure with nested code frames while still exporting ordinary Python source. PTIR identified it as a possible bridge from block-style programming to text Python, especially because it requires no installation or account. The lab turns that claim into something students can test directly by solving the same nested problem in both interfaces.

Consult the Strype editor · Creative Python Programming with Strype preview

A confirmation dialog can slow down an action. It does not necessarily reduce the permissions available to the process that performs it.

Goal

Distinguish confirmation from authorization in an agent-assisted Kubernetes workflow.

Scenario

A local Kubernetes tool asks for confirmation before deleting a resource, but it uses a kubeconfig with cluster-admin privileges.

Activity

1. List what the confirmation gate protects against.
2. List what cluster-admin still allows if the gate is bypassed, misclassified, or approved accidentally.
3. Design a service account for a narrower task, such as reading Pods and logs in one namespace.
4. Compare the maximum damage possible with the narrow service account versus cluster-admin.
5. Add one audit or review control that would help reconstruct what happened after an action.

Deliverable

Submit a short table with three columns: Control, What it prevents, and What it does not prevent.

Discussion

Why should a safe interface use both confirmation for consequential actions and least-privilege authorization underneath?

Source material

First spotted in PTIR: August 10, 2026, Morning Briefing.

srelens was highlighted as a local-first Kubernetes workspace with terminal, manifest, Helm, metrics, and MCP capabilities. Its documentation describes confirmation-gated mutations, but the application still operates through the permissions available in the local kubeconfig. PTIR used that contrast to separate two security concepts: confirmation can reduce accidental actions, while Kubernetes RBAC and narrowly scoped credentials determine what the tool is actually authorized to do.

Consult the srelens repository and documentation

Small devices force visible tradeoffs that are easy to hide on larger computers.

Goal

Explain how a model can be made to fit within limited memory without assuming that fitting the model makes it intelligent or useful for every task.

Activity

1. Review the ESP32-AI project as a case study.
2. Draw three storage tiers: fast/small working memory, larger/slower external RAM, and nonvolatile flash/storage.
3. Place frequently accessed state, model weights, temporary buffers, and persistent files where you think they belong.
4. Explain what quantization changes and what it does not change.
5. List three capability questions that parameter count alone cannot answer.

Deliverable

Submit the memory diagram and a paragraph answering: Why can an engineering achievement in model placement still produce a model with limited practical capability?

Extension

Compare the same problem with a desktop local-LLM system. Which constraints disappear, and which remain?

Source material

First spotted in PTIR: August 9, 2026, Evening Briefing.

ESP32-AI demonstrates a 28.9-million-parameter, 4-bit model running entirely on an ESP32-S3 by treating SRAM, PSRAM, and flash as distinct memory tiers. The project’s own documentation is especially useful because it separates the engineering accomplishment of fitting and running the model from claims about model usefulness or intelligence. That distinction became the core of this lab.

Consult the ESP32-AI repository · Measured results

An AI-generated answer becomes more useful when students can trace its claims back to the underlying data.

Goal

Practice verification using a tool that exposes its data or tool trail.

Activity

1. Open Cloudflare Radar and, where available, its AI-assisted research interface.
2. Ask one narrow factual question, such as comparing IPv6 adoption or traffic patterns between two locations.
3. Identify one specific numerical or factual claim in the answer.
4. Open the tool trace, chart, or source data used for that claim.
5. Compare the prose with the underlying result.
6. Record whether the evidence supports the claim fully, partly, or not at all.

Deliverable

Submit the question, the claim checked, the source evidence, and a one-paragraph verification judgment.

Grading principle

Grade the quality of the evidence trail and the student’s verification—not how polished or confident the generated prose sounds.

Source material

First spotted in PTIR: August 7, 2026, Evening Briefing.

Cloudflare Radar Researcher introduced a natural-language interface to public Internet datasets that can generate charts while exposing the tool/API trace used to support its answer. That transparency makes it a useful teaching case: students can inspect the underlying data and judge whether a generated claim is actually supported instead of grading the confidence of the prose.

Consult the Radar Researcher announcement · Open Cloudflare Radar

Telling an agent what it should not do is different from making the prohibited action impossible.

Scenario

A school uses an AI agent to summarize documents. The requirement is: Never send private student data outside the school.

Activity

Classify each proposed control as an instruction, preventive control, approval control, or evidence/detection control:

• A system prompt that says not to send private data.
• A credential that can read only one approved folder.
• An outbound network allowlist.
• A tool allowlist.
• Human approval before an external write.
• Structured output that rejects unexpected fields.
• Audit logs of tool and network activity.
• A short-lived task-specific credential.

Then answer: Which controls actually reduce what the agent is capable of doing?

Six-outcome check

Map the same scenario to the Agent Baseline draft:

1. Discover: List the agent’s owner, purpose, model, tools, data, credentials, and effective access.
2. Constrain: Name one filesystem, network, tool, data, compute, or time boundary.
3. Authorize: Define a consequential action that requires short-lived, task-specific authority.
4. Observe: Choose a run ID and list the events that must be correlated under it.
5. Validate: Describe one prompt-injection test against the configuration the agent will actually use.
6. Respond: Specify how to stop the run, revoke authority, preserve evidence, scope affected records, and continue essential work safely.

Deliverable

Draw a simple boundary diagram showing the model, tools, credentials, filesystem/data source, network, approval point, and logs. Add a six-row table with one concrete control or response for each Agent Baseline outcome.

Discussion

Why can a prompt still be useful even though it is not an access-control boundary? Which of the six outcomes would expose a control that exists only on paper?

Safety

Use a fictional school, synthetic records, and dummy credentials. Do not test prompt injection against production systems, real student data, or services you do not own and have permission to test.

Source material

First spotted in PTIR: August 6, 2026, Morning Briefing.

Cloudflare’s Agent Access Model proposes task-bound, short-lived credentials; enforcement in the agent harness and network instead of prompts; selective approval for consequential actions; evidence-backed grant review; and a one-way reduction of capabilities as sensitive data enters the workflow. The lab turns those architecture ideas into a simple classification exercise about which controls express intent and which actually bound capability.

Consult Cloudflare’s Agent Access Model

Follow-up source added from PTIR: August 12, 2026, Evening Briefing.

Docker, Snyk, and Keycard’s Agent Baseline v1.0 draft organizes 35 controls into six outcomes—Discover, Constrain, Authorize, Observe, Validate, and Respond. Its support-ticket prompt-injection scenario adds a practical lifecycle and incident-response pass to the original boundary exercise. The draft is open for community review through September 30, 2026.

Consult the official Agent Baseline overview

Coding agents produce several kinds of evidence. They do not all support the same claims.

Goal

Learn to separate what an agent says, what it did, and what was verified afterward.

Activity

Use a disposable repository and one small maintenance task. Collect four artifacts:

1. The original request given to the agent.
2. The agent’s activity or tool log, if available.
3. The final Git diff.
4. Test, build, or static-analysis results.

For each artifact, write down one claim it can support and one claim it cannot support.

Example questions

• Does the activity log prove the final code is correct?
• Does a clean diff prove the requested behavior works?
• Do passing tests prove there are no security problems?
• Can the agent’s explanation be trusted without comparing it with observable changes?

Deliverable

Create a four-row evidence table and finish with a short review decision: accept, revise, or reject the change, with evidence.

Source material

First spotted in PTIR: August 5, 2026, Evening Briefing.

Meta’s Muse Code beta emphasized an exportable event log that records edits, tool calls, and decisions while coding agents work. PTIR treated that trace as useful evidence of activity—but not evidence that the resulting code is correct. The lab generalizes that distinction by comparing the request, agent log, Git diff, and test/build results, each of which supports different claims.

Consult Meta’s Muse Code announcement · Muse Code product page

Software maintenance is easier to evaluate when there is a baseline and a reversible path.

Goal

Practice a controlled dependency upgrade instead of treating “latest” as automatically better.

Activity

1. Choose a small, non-production web project.
2. Create a Git branch for the experiment.
3. Record a baseline: current dependency version, successful build, important routes or tests, and one measurable characteristic such as build time.
4. Upgrade one dependency.
5. Rebuild and run the same checks.
6. Compare the result with the baseline.
7. Demonstrate how you would return to the known-good state.

Deliverable

Submit a short change record containing the before version, after version, tests performed, observed difference, and rollback command or Git operation.

Discussion

Why is “the build passed” useful evidence but not proof that every behavior is correct?

Source material

First spotted in PTIR: August 4, 2026, Morning Briefing.

The Next.js 16.3 release emphasized lower development memory use, faster builds/rendering, and other framework changes. PTIR’s recommendation was not to accept those claims blindly, but to test the upgrade on a branch against a measured baseline. That maintenance workflow became the lab: isolate one change, compare before/after behavior, and preserve a known rollback path.

Consult the Next.js 16.3 release notes

This lab demonstrates why secret removal and secret remediation are different tasks.

Safety rule

Use a fake token only. Never put a real password, API key, student credential, or production secret into the repository.

Activity

1. Create a disposable Git repository.
2. Add a text file containing an obvious fake value such as DEMO_API_KEY=not-a-real-secret-12345.
3. Commit the file.
4. Scan the repository with a secret-scanning tool such as TruffleHog, or inspect the history manually if the scanner does not flag the intentionally simple value.
5. Remove the fake token from the current file and commit again.
6. Use git log, git show, or the scanner’s history mode to locate the earlier committed value.

Deliverable

Explain why deleting a secret from the latest version of a file is not enough after a genuine credential has been exposed.

Key conclusion

For a real secret, the response includes revocation or rotation. History cleanup may also be appropriate, but rewriting history does not make an already exposed credential safe again.

Extension: secrets in browser bundles

A secret can be exposed even when it never appears in the visible page.

1. In the same disposable repository, create config.js containing a deliberately fake value such as DEMO_AWS_KEY=FAKE-ONLY-DO-NOT-USE.
2. Copy or bundle that file into a dist/ directory, simulating a production build.
3. Search the build output with rg -n "DEMO_AWS_KEY|FAKE-ONLY" dist or your editor’s search.
4. Open the generated JavaScript in a browser and confirm that anyone who can download the asset can read the value.
5. Remove the fake value from the source, rebuild, and scan both the output directory and Git history again.

Deliverable: A two-column note identifying where the fake value existed before and after rebuilding. Explain why environment-variable syntax does not make a value secret once a build tool inserts it into client-side JavaScript.

Discussion: Which values belong in browser code, and which operations must move behind a server-side API? Why must a genuinely exposed cloud credential be revoked or rotated even after the public asset is replaced?

Source material

First spotted in PTIR: August 3, 2026, Evening Briefing.

Truffle Security reported finding more than 221,000 live credentials while scanning public Hugging Face datasets, illustrating how secrets can persist in repositories and data even after the current copy appears clean. The PTIR turned that into a safer classroom demonstration using a deliberately fake token so students can see the difference between deleting a line, preserving Git history, and actually remediating a compromised credential.

Consult the original Truffle Security study · TruffleHog repository

August 18, 2026 extension source

The browser-bundle extension was added after the August 18 PTIR reviewed the Beacon CRM incident and the broader credential-hygiene failure mode. UK Charity Commission guidance confirmed the incident’s potential impact on charities, while OWASP’s CI/CD guidance explains why credentials in code, build artifacts, and pipeline contexts require strict secret management. The classroom activity uses only a fake value and does not reproduce access to any real system.

UK Charity Commission guidance · OWASP: Insufficient Credential Hygiene

This exercise focuses on the programming cycle rather than software installation.

Goal

Practice prediction, execution, modification, and explanation with a short Python program.

Activity

1. Open Code.org Python Lab.
2. Run a short starter program containing a variable, a loop, and visible output.
3. Before running it a second time, predict what will happen if one variable or loop bound changes.
4. Make the change and run the program.
5. If the prediction was wrong, identify which assumption was wrong.
6. Make one additional change that deliberately causes unexpected output, then fix it.

Deliverable

Submit the original prediction, the changed code, the actual output, and a two- or three-sentence explanation of any difference.

Discussion

What did you learn from the wrong prediction that you would not have learned by only copying a working example?

Source material

First spotted in PTIR: August 1, 2026, Evening Briefing.

Code.org’s Python Lab was highlighted as a zero-install browser environment for real Python 3, including common data/science libraries and a visual Painter mode. The useful classroom implication was reduced setup friction: students can spend the exercise predicting, changing, running, and debugging code rather than installing a local toolchain first.

Consult Code.org Python Lab

An SBOM is more useful when students can explain what information it contains and what questions it still cannot answer.

Goal

Evaluate an SBOM as evidence about a software supply chain rather than treating its existence as proof of security.

Activity

1. Obtain an SBOM from a small sample project or instructor-provided example.
2. Open CISA’s 2026 Minimum Elements for a Software Bill of Materials.
3. Build a two-column checklist: Present and Missing/unclear.
4. Locate fields such as component identity/version, supplier or author information, relationships, hashes, licenses, generation context, and SBOM tool information when applicable.
5. Pick one missing field and explain what risk or uncertainty it creates.

Deliverable

Submit the checklist and a paragraph answering: What can this SBOM support confidently, and what still requires another source or control?

Safety note

Use a classroom project or public sample. Do not upload proprietary software inventories or credentials to third-party services for this exercise.

Source material

First spotted in PTIR: August 1, 2026, Morning Briefing.

CISA’s July 2026 SBOM update expanded the minimum baseline beyond package names and versions to include fields such as component hashes, licenses, the SBOM-generation tool, and generation context. The source is valuable for teaching because students can treat an SBOM as structured evidence and ask which supply-chain questions it can—and cannot—answer.

Consult CISA’s 2026 SBOM minimum-elements resource · Official PDF

A prototype is useful when it makes an interface idea testable before code is written.

Goal

Convert an existing website plan or wireframe into a small clickable prototype and use peer feedback to improve one design decision.

Activity

1. Choose a site or app idea with at least three screens or states.
2. Build three connected frames in Figma.
3. Add only enough interaction to let another person complete one simple task.
4. Ask a classmate to use the prototype without coaching.
5. Record one place where the user hesitates, takes the wrong path, or asks what to do next.
6. Revise the prototype to address that observation.

Deliverable

Submit the prototype link plus a short note identifying the observed problem, the change made, and why the change should improve the experience.

Discussion

What did the clickable prototype reveal that a static sketch did not?

Source material

First spotted in PTIR: July 30, 2026, Evening Briefing.

Figma’s free educator series focused on moving classroom design work from initial setup through clickable digital-product prototypes, collaboration, classroom workflow, assessment, and portfolios. The PTIR Teaching Corner distilled that material into a small assignment that keeps prototyping connected to later HTML/CSS implementation rather than treating Figma as the final product.

Consult Figma’s educator livestream schedule

A repository can look legitimate, build correctly, and still execute code you did not intend to trust.

Goal

Practice pre-execution inspection before running an unfamiliar development project.

Activity

Use an instructor-provided benign sample repository. Do not use known malware.

1. Read the README without executing anything.
2. Inspect package.json, especially scripts, dependencies, and development dependencies.
3. Identify which commands would execute during common steps such as install, start, build, or test.
4. Look for shell commands, downloaded binaries, post-install hooks, encoded data, unexpected network access, or scripts that reach outside the project directory.
5. Decide what isolation you would use before running the project: disposable VM/container, low-privilege account, no production credentials, restricted network, or another control.
6. Only after review, run a safe instructor-approved command if the lab environment permits it.

Deliverable

Write a short pre-execution risk assessment: what you inspected, what would execute, what you still do not know, and what control would reduce the remaining risk.

Discussion

Why is “it came from GitHub” not a security assessment?

Source material

First spotted in PTIR: July 30, 2026, Morning Briefing.

Elastic Security Labs documented a campaign in which working coding-challenge repositories concealed malware chunks inside SVG files. Normal-looking npm start/dev workflows reconstructed credential theft, file theft, remote-access, and clipboard-stealing components. The durable teaching point is that a repository’s appearance, host, or ability to run successfully does not establish trust; execution paths and package scripts need inspection first.

Consult the Elastic Security Labs report

This lab turns standards alignment into a concrete revision task rather than a paperwork exercise.

Goal

Take one assignment you already teach and identify what it actually asks students to know and do. Then make one small revision that strengthens alignment without replacing the assignment.

Activity

1. Choose one current programming, web, Linux, cybersecurity, or computing assignment.
2. Open the 2026 CSTA PK–12 Standards resources.
3. Identify one content standard that clearly matches the assignment.
4. Identify one practice or student behavior the assignment already requires.
5. Find one worthwhile practice the assignment does not make explicit—for example ethical analysis, human-centered design, inclusive collaboration, evaluation of evidence, or reflection.
6. Add one prompt, checkpoint, or deliverable that makes that missing practice observable.

Deliverable

Submit a short before-and-after note containing the assignment name, the standard selected, the practice selected, and the exact revision made.

Discussion

Why is “this assignment covers programming” weaker evidence than identifying what students must actually demonstrate?

Source material

First spotted in PTIR: July 30, 2026, Morning Briefing.

CSTA’s 2026 standards package expands high-school computing outcomes across foundational and specialty areas including AI, cybersecurity, data science, software development, APIs, human-centered design, and computing’s social impacts. The standards are useful here because they let an instructor compare what an assignment actually requires students to demonstrate against an external curriculum benchmark.

Consult the official 2026 CSTA standards resources · High-school foundational standards

Archive note: This schedule is retained as a record of the Summer 2026 ITSE-1301 course. It is not a current course schedule and is excluded from the current Education Blog and feed.

ITSE-1301 Summer 2026 weekly course calendar.

Assignments for each chapter include Apply Your Knowledge, Consider This: Your Turn, and a chapter quiz. Week 1 also includes the Coding IDE Prerequisite and Pre-Course Assessment. Week 10 includes the Post-Course Assessment and Final Website Submission.

Final grades are due August 17, 2026.

This schedule provides a general course outline. Students should check eCampus for announcements and any changes during the term.

Don’t ask me how many classes I’ve taken in my life, or who my teachers were… but I like to think that I manage to keep something from every encounter, even if it’s not something directly related to the class.

For example, in my high school physical science class, our teacher liked to answer all kinds of questions, no matter how outlandish they might be. If he couldn’t answer he had a go-to phrase that I still use in a regular basis: “It’s possible, but not probable.” Maybe he thought he didn’t want to be the one person that stopped someone from developing a teleportation machine or flying car.

My first year in college is mostly a blur, but I’ll never forget this one maxim my Chemistry I teacher: “Two, four, six, eight — who do we appreciate? Valence electrons! I don’t remember why valence electrons are important, but I can’t help but cheer for them every now and again.

A Calculus professor explained many basics the first day, including the importance of zero when it’s used to measure distance, particularly when talking about two objects occupying the same space. After presenting a couple more “That being said, what is the shortest distance between two points?, to which many in the class mechanically answered “a straight line! More annoyed than disgusted he calmly replied, “what did we just learn about zero?”

While I quote some of these regularly, the one the comes up the most is one from the only newspaper design class I ever took (the only one offered during my time studying journalism): The first and probably only rule of newspaper design is “Beg, borrow and steal.” I apply this to many enterprises.

References

• Valence Electrons
• Can the distance between a point and a line ever be zero?
• Beg, Borrow and Steal

I went looking for the programming proverbs Henry F. Ledgard collected in his programming books from the 1970s. The exercise is still useful because good programming advice tends to outlive particular languages and tools.

The ideas I keep coming back to are less about syntax than habits of mind:

• Clarity matters. Clever code is not automatically good code.
• Complexity needs discipline. Being inventive is useful; controlling that invention is what keeps a program understandable.
• Editing matters. Programs, like prose, usually improve when unnecessary material is removed and the remaining structure becomes easier to follow.
• Read other people’s work critically. Examples and libraries are valuable, but using code you did not write does not remove the need to understand what you are trusting.
• Build a library of ideas. Patterns, examples, documentation, and previous solutions become more valuable when they are organized well enough to find again.

Ledgard’s Programming Proverbs belongs to an earlier era of computing, but its premise remains relevant: programming is not merely telling a machine what to do. It is expressing a solution precisely enough that people can understand, test, maintain, and improve it.

Last reviewed: August 9, 2026.

Archived glossary: This 2016 vocabulary list is retained as a historical teaching artifact, not as the current idtprof.net cybersecurity glossary. Several definitions are simplified, dated, or too narrow for present-day instruction. In particular, firewalls do more than block malware, modern malware terminology is broader than the examples used here, and authentication terminology has changed substantially since this was written.

A cybersecurity glossary

The original list covered antivirus software, backups, bandwidth, botnets, computer networks and viruses, DDoS, encryption, firewalls, hacktivism, ISPs, keyloggers, malware, phishing, ransomware, servers, software, patches, vulnerabilities, spam, and USB devices. It also included Doxnet, a fictional teaching example modeled on Stuxnet.

The original vocabulary was adapted from a Khan Academy/NOVA cybersecurity presentation. Rather than silently modernizing those historical definitions, this page now preserves their provenance while preventing them from being presented as current instructional reference material.

Current security terminology should be based on maintained authoritative sources such as the NIST Computer Security Resource Center and OWASP.

Last reviewed: August 9, 2026.

Archived campaign post: This 2016 entry promoted greater participation by girls and women in computing through a contemporary advertising campaign. The original third-party video embed and workforce projection are time-bound, so they are not presented as current evidence.

The durable point is straightforward: computing education benefits when barriers to participation are reduced and students who have historically been underrepresented in technology can see a place for themselves in the field.

The original post’s slogan and embedded campaign are retained only as historical context; current teaching and workforce claims should rely on current sources rather than a decade-old projection.

Last reviewed: August 9, 2026.

Archived link-post: The original 2016 entry consisted almost entirely of an embedded social-media post. The external embed is intentionally no longer required for this page to function.

The point I saved was simple: learning to program requires becoming comfortable with abstraction. You cannot understand every implementation detail before you begin using a language, library, framework, operating system, or network service productively.

That remains a useful teaching idea, but the original third-party embed was too fragile to justify presenting this as a maintained instructional article.

Last reviewed: August 9, 2026.

Online courses require more than access to a computer. Students need enough technical fluency to work independently, recover from ordinary problems, communicate clearly, and manage course files without losing their work.

Core technology skills

Students should be comfortable with:

• using a current web browser and navigating web applications;
• downloading, uploading, renaming, moving, organizing, and backing up files;
• recognizing common file types and choosing appropriate applications to open them;
• installing or updating software when a course requires it;
• copying and pasting text, URLs, and files without losing track of the source;
• creating and submitting documents in requested formats;
• using email, discussion tools, video meetings, and learning-management systems;
• searching the web and library resources critically rather than treating the first search result as authoritative;
• applying basic security practices such as software updates, multifactor authentication, and careful handling of links and attachments.

For web-development and programming courses, students should also understand folders, relative paths, plain-text files, and the difference between source files and generated/output files.

Reading, writing, and communication

Online learning still depends heavily on reading and writing. Students should be able to follow written instructions, explain a technical problem precisely, ask questions when something is unclear, and distinguish between an assignment problem and a technology problem.

When asking for technical help, include what you were trying to do, what happened instead, the exact error message when available, and what you already tried.

Self-management

Online courses offer scheduling flexibility, but they are not self-paced by default. Check the course regularly, follow the published schedule, begin work early enough to recover from technical problems, and avoid treating the due date as the starting date.

A useful routine is to reserve recurring blocks of time each week for reading, practice, assignments, and review. The amount of time varies by course and student; plan for consistent weekly work rather than a last-minute session.

Ask for help early

Technical problems compound when they are ignored. Contact the instructor or the appropriate support service when a problem prevents progress. Describe the problem clearly and keep working on portions of the assignment that are not blocked.

The goal is not to know every application before the course begins. The goal is to have enough digital literacy to learn new tools without the tool itself becoming the main obstacle.

Last reviewed: August 9, 2026.

This resource list began in 2016. It has been reduced to maintained references that are useful for learning and teaching standards-based HTML and CSS today.

Core references

• MDN Learn Web Development — structured tutorials and reference material from MDN.
• MDN HTML — current HTML reference and guides.
• MDN CSS — current CSS reference and guides.
• web.dev Learn HTML — modern HTML fundamentals from the Chrome team.
• web.dev Learn CSS — modern CSS fundamentals, including layout and responsive design.

Practice and supplementary learning

• freeCodeCamp — hands-on web-development exercises and projects.
• Khan Academy: HTML/CSS — introductory browser-based practice.

The original page linked to several useful resources from the 2010s, but some have since disappeared, changed ownership, or teach workflows that no longer reflect the way I teach web development. Those links have been retired instead of preserved as current recommendations.

Last reviewed: August 9, 2026.

Archive note: Preserved as a site-era artifact. This post is not part of the current idtprof.net Education Blog or feed.

Yes, and now what?

Archived context: This short 2016 post referred to Chrome ending support for the NPAPI browser plug-in architecture used by Java applets. That browser issue is unrelated to whether Java remains useful as a programming language, so the post is preserved as a historical artifact rather than current Java guidance.

Sure enough, just as I finally decided to take a Java class — OK, so it was decided for me — browser support for Java plug-ins was disappearing.

I guessed I would still learn Java, out of spite.

The joke survives better than the technical premise. Modern Java development does not depend on running Java applets inside Chrome.

Last reviewed: August 9, 2026.

Archived teaching anecdote: This 2016 post depended on Blackboard and Internet Explorer behavior that is no longer useful as current technical guidance. It remains here as a record of the troubleshooting lesson: test assumptions and isolate variables before escalating a problem.

This morning I had an issue creating a new content folder using the Blackboard software we used at the college. After the usual troubleshooting — logging out, restarting the browser, and restarting the computer — I finally asked myself the same question I would have asked someone calling for support: What browser are you using?

I used Chrome almost exclusively and had not considered trying Internet Explorer. The same operation worked there immediately.

The browser names and software environment are now historical. The useful part of the story is not: troubleshooting often fails because the person diagnosing the problem has unconsciously excluded one of the variables.

Last reviewed: August 9, 2026.

Archived guidance: This 2016 article is retained as a historical teaching artifact, but its password advice is no longer current. Modern NIST guidance does not recommend routine password changes solely because a fixed period has elapsed. Current practice emphasizes long passwords, blocking commonly used or compromised passwords, password managers, and stronger authentication methods such as MFA and passkeys.

Hello, Monday (Wednesday — actually, Friday)!

As we all get ready for the new year, and then again 90 days from now, and in yet another three months, ad nauseum — the computer system will ask you to pick a new password to access the information you so desperately need right now.

Although this may seem like a burden — and by all means, maybe it is — you should take a couple of minutes to take care of the computer’s request to change your password and pick a secure code that is hard to decipher and easy for you to remember.

The remainder of the original article recommended password-management practices and linked to contemporary 2015–2016 password lists. Those links and recommendations have been retired rather than presented as current security instruction.

For current authentication guidance, consult NIST SP 800-63B-4 and the OWASP Authentication Cheat Sheet.

Last reviewed: August 9, 2026.

Archive note: This short 2015 post records a teaching-technology transition ahead of Spring 2016. It is retained as historical context rather than current instructional guidance.

It’s new to me, anyway.

Starting with the Spring 2016 semester, I’ll be moving toward more open-source software options in my classes, ergo my Photoshop may include some GIMP, my Dreamweaver will have some bootstrap, etc.

Gotta get some reading done.

Historical teaching note: This post records a 2015 curriculum transition. The specific tools have continued to evolve, but the shift toward source control and standards-based web-development workflows remains relevant.

So Python was finally in the books: we had moved it into the dual-credit curriculum, installed it on our machines, and had a lot of fun making it work.

Next came another change. CSS frameworks were going to replace Dreamweaver in Web Design II, and GitHub offered a much better foundation for teaching students how modern web projects are actually managed.

The details of the classroom workflow have changed since 2015. The larger idea has not: students benefit from learning source control, publishing from a repository, and working with the same basic development practices they will encounter beyond a single course.

This list began in 2015. It has been revised to favor maintained, authoritative resources for learning and teaching modern Python 3.

Start here

• Python.org Beginner’s Guide — the Python Software Foundation’s starting point for new Python users.
• The Python Tutorial — the official language tutorial. It is best suited to readers who already understand basic programming concepts.
• Python Documentation — the official documentation hub, including the tutorial, FAQs, language reference, library reference, and packaging guidance.

For teaching Python

• Python in Education — the Python Software Foundation’s education hub, including open educational resources and guidance for instructors.
• Getting Started — Python in Education — teaching toolkits, platform-selection guidance, and instructional resources curated for educators.

Additional practice and reference

• Learn X in Y Minutes: Python 3 — a compact syntax-oriented reference for readers who already know another programming language.
• Full Stack Python — a broad reference for applying Python to web development and related tooling.

Older links to Python 2 material, abandoned tutorials, and resources whose maintenance status could not be established have been removed.

Last reviewed: August 9, 2026.

And so after months of harping about how great it would be to switch from DarkBASIC to Python in my game design classes, the time has come to put up or shut up and start designing the class itself. It will be split in two, starting with Python and ending with JavaScript.

Now to figure out how all this is going to work…

Archive note: Full-body review changed the earlier title-based disposition. This post is primarily about experimenting with Markdown/GitHub and wondering how students might respond, so it remains with the idtprof.net historical teaching record rather than moving to paco.org.

Nobody knows you’re a pack of dogs, is more like it.

I wonder if my students could understand this process? Or if they’re even interested. This is so retro.

Much more to read at Mastering Markdown.

Next target could be paco.org, but I think I’d rather do idtprof.com.

Archive note: Preserved as a site-era artifact. This post is not part of the current idtprof.net Education Blog or feed.

What this guy said:

With only about a month left between now and the final day of classes, I hope my students are getting visits from that misunderstood muse, Panic. She might be the last hope for some people. Taken from imgur.

Just some guy at the chicken farm rounding up a herd.

Actually, just a creative guy with some free time that saw the opportunity to have some fun with Photoshop and created a scene out of a Saturday morning cartoon (remember those? ever hear of a Saturday morning cartoon?). It’s small, projects like this that allow graphic artists to experiment and flex some creative muscles. Taked from imgur.

Acquiring Photoshop expertise means never having to worry about your Halloween pictures. Taken from imgur.

Taken from weknowmemes.com.

Swiped from imgur.com