Web Technologies Capstone and Placement

🎯Learning Objectives

• Bring HTML, CSS, browser programming, application contracts, data, security and deployment into one coherent project.
• Build a small complete user journey, explain responsibility boundaries and present reproducible evidence.
• Finishing a reading lesson is different from verifying an implemented project.

useful feature → explicit contract → implementation
positive and negative tests → reviewed demonstration

Capstone outcomes: By the end, describe one design decision, one observed failure and one limitation using your own project evidence.

🧭Choose a Small Useful Project

• Use a study-task tracker as the reference project: a learner can list tasks, create a bounded title, mark a task complete and filter pending work.
• Start with one user journey before adding accounts, reports or file uploads.
• A local practice prototype and a shared private application have different requirements.

As a learner, I can add a study task and see it in my list.
Acceptance: valid title creates one task; invalid input creates none.
Out of scope initially: payments, uploads and notifications.

• User story and scope: Pick a scope you can finish and explain.
• A class team may choose a workshop-registration or reading-list project with similarly explicit operations.

🧱Map Responsibilities Before Coding

• The browser provides presentation and interaction.
• A backend is needed to enforce shared/private operations beyond a single browser.
• The database stores durable relationships under application constraints.
• A static page can demonstrate local state, but hidden buttons cannot enforce multi-user authorization.

browser: render + collect input + show outcomes
backend: validate + authorize + apply allowed operation
store: persist accepted data with constraints

• Architecture worksheet: The planner offers static, PHP and Java paths to organize responsibilities.
• It does not generate or deploy a backend.

🧾Specify the Data Contract

• For a shared task tracker identify task ID, trusted owner ID, bounded title and completion flag.
• Give fields explicit types and constraints.
• Let the server assign identifiers and ownership from trusted identity; writable JSON should contain only the fields the caller is allowed to change.

tasks(id PRIMARY KEY, owner_id FOREIGN KEY,
      title NOT NULL, completed NOT NULL)
Writable create fields: title
Writable complete field: completed

• Driver-neutral schema sketch: Choose the actual database types, title bounds and boolean representation for your platform.
• Document what happens if a requested ID does not exist or belongs to another user.

🪟Build a Semantic and Responsive Interface

• Use meaningful headings, labels and buttons with visible focus.
• Show loading, empty, success and failure states in readable text.
• Keep essential actions available on a small screen and through the keyboard.
• Stable layout and contrast matter as much as decorative polish.

<label for="taskTitle">Study task title</label>
<input id="taskTitle" maxlength="80">
<button type="button" id="addTask">Add task</button>
<p id="taskFeedback" role="status"></p>

• Task input illustration: This fragment is not a complete form: connect explicit validation and feedback in the project.
• A frontend maxlength does not replace a backend limit.

⚙️Implement a Local Vertical Slice

• Before connecting a backend, implement bounded title input, a single accepted state change and safe rendering.
• Keep state separate from the DOM so that filtering does not accidentally delete tasks.
• Give reset and removal their own deliberate behaviors.

const item = document.createElement("li");
item.textContent = task.title;
list.append(item);

• Plain text presentation fragment: Choose an ID allocation policy and a maximum task count for your prototype.
• Explain whether a page reload discards state; do not claim durability if you only use an in-memory array.

📨Define Backend Request Outcomes

• For the shared project define collection and item routes, allowed methods, input shape and response behavior before writing handlers.
• A client must handle denial and failure explicitly.
• Avoid assuming every response contains JSON, especially a completed204 operation.

GET /api/tasks → caller-owned tasks
POST /api/tasks {title} → created task
PATCH /api/tasks/:id {completed} → changed owned task
DELETE /api/tasks/:id → completed empty response

• Example contract — project-specific: Unlike an executable lab API, this is a specification you must implement.
• Document actual statuses, serialization, bounds and retry behavior in your chosen backend.

🔐Protect Ownership and State Changes

• Resolve identity with maintained authentication/session infrastructure.
• Authorize each read and change against the requested object, then validate the exact writable fields.
• Apply suitable framework CSRF protection for cookie-authenticated writes.
• Render task titles as text and bind database values.

UPDATE tasks SET completed = :completed
WHERE id = :task_id AND owner_id = :trusted_owner;

• Authorized update — conceptual SQL: Use real driver parameters, check affected rows and implement appropriate atomic behavior.
• A valid session or CSRF token never grants ownership of another user’s task.

🗄️Make Persistence and Failures Explicit

• A shared persistence layer must preserve accepted changes according to a documented transaction boundary.
• Roll back failed grouped operations.
• Treat browser storage as a local convenience with failure handling, not a cross-device database or proof of identity.
• Decide how a client recovers from an uncertain request outcome.

operation accepted? response lost?
retry may duplicate creation?
state read back? conflict handled?

• Failure worksheet: For a create operation, define any retry/idempotency policy and enforce it on the backend.
• Do not silently retry mutations while assuming that a lost response means nothing changed.

🧪Write Tests That Check Behavior

• Give each test its initial state, action, expected outcome and observed result.
• Check empty/valid/boundary/invalid inputs, owner and other-user access, persistence and error display.
• Snapshot data around denied changes so a displayed error cannot hide a partial mutation.

Initial: two tasks owned by A; one task owned by B.
Action: A attempts to complete B task.
Expected: denied; B task unchanged; no private details returned.
Observed: record actual status/body/store and tested release.

• Task case example: A checklist is not test execution.
• Retain the commands, fixtures or manual reproduction that a reviewer can run.

🛠️Debug Across the Whole Request Journey

• Locate the first boundary with an unexpected observation: control value, browser event, network request, handler, query or rendered outcome.
• Compare expected input/output at that boundary.
• Do not edit every layer at once or remove a permission check merely to make the happy path pass.

reproduce → inspect actual input → locate divergence
make focused change → rerun affected positive/negative cases

• Debugging sequence: Keep secrets and private data out of screenshots and public logs.
• Include enough sanitized evidence to explain a failure without publishing real credentials.

🚀Verify the Release You Demonstrate

• Record the commit, build, domain and backend contract used for the demonstration.
• Smoke-test required routes and interactions on that deployed release.
• Check small screens, keyboard use and representative loading behavior.
• Keep a compatible rollback target.

commit identifier
frontend and backend version
serving domain
smoke results + measurement conditions

• Release evidence: A successful build alone does not verify the application.
• If an update is invisible, identify the serving release and cache layer as practised in Level29.

📁Prepare a Reviewable Project Portfolio

• Provide a README with purpose, features, setup, architecture, test instructions, screenshots and limitations.
• Separate your own work from team responsibilities and third-party components.
• Explain tradeoffs using observed behavior rather than claiming a technology is always best.

Problem and user journey
Local setup and configuration names (no secret values)
Architecture and data contract
Tests and observed results
Limitations and next improvements

README outline: A link to a running demo helps only when the reviewer can also understand how to reproduce the important behavior.

💬Explain the Project in an Interview

• Start with the user problem, describe one end-to-end operation and explain one decision.
• Be ready to show the data model, validation, object permission and error handling for that operation.
• Discuss what you personally implemented and what is still incomplete.

problem → user action → browser/backend/data flow
decision → alternative considered → evidence → limitation

• A concise explanation structure: Do not memorize a claim you cannot demonstrate.
• If asked about an unimplemented feature, explain the planned boundary and label it as future work.

🧩Connect Revision to Project Evidence

• Use the course as a map: HTML and CSS for structure/layout; JavaScript and DOM for interaction; HTTP and backend lessons for contracts; SQL for stored relationships; security and performance for protected reliable delivery.
• Revisit the lesson related to a concrete gap.

inaccessible action → semantic/keyboard lessons
incorrect response handling → APIs lesson
other-owner access → security lesson
old release visible → performance/deployment lesson

• Revision map: Placement preparation benefits from reasoning and evidence, but a capstone or checklist does not guarantee an interview result.
• Practise explaining both accepted and rejected operations.

🧪Premium Interactive — Capstone Contract Planner

• Describe a project and choose its implementation path, data scope, audience and review target.
• The planner checks declared architecture consistency and produces a responsibility/test plan.
• It does not create an app, execute tests, inspect files or verify your evidence.

• Static browser practice supports public local-memory exercises.
• Shared durable data or private per-user operations require an implemented backend in this planner.
• PHP and Java are alternative backend paths, not proof that any backend is secure or durable.

• Project title: trimmed1–80 Unicode code points with no controls.
• Feature brief: trimmed60–600 Unicode code points; line breaks and tabs allowed, other C0/C1 controls and lone surrogates rejected.
• Required review items depend on the selected scope.
• Checkboxes are self-reported evidence reminders; checking every box never certifies the project or guarantees placement.

• Editing any field clears the old result so it cannot be mistaken for the new plan.
• Reset restores the public local static fixture and clears all checkboxes.
• The plan is in memory only; completion is the separate local study marker.

No plan yet.

No review yet.

No contract yet.

🛠️Debugging — Review the Plan Before the Score

• If the planner asks for a backend, compare the chosen shared/private behavior with what a static page can actually enforce.
• Selecting PHP or Java supplies a plan only; you still need to implement and test that boundary.

• If evidence gaps remain, reproduce the relevant case and retain observed results before marking its reminder.
• Items outside the chosen scope are not counted.
• Changing scope clears the old report, but prior checkboxes remain self-reported until you deliberately reset or revise them.

• A ready-for-self-review result means the declared plan is consistent and required reminders are checked.
• It does not mean code, security, persistence, deployment or interview ability was verified.

💬Interview Questions — Flip to Explain

❓MCQ Practice — Explain Capstone Decisions

💻Extra Practice — Turn Claims into Evidence

📌Quick Revision

📖Glossary — Flip to Learn

🏆Final Challenge — Build and Defend a Study-Task Tracker

• Implement list, create, complete and pending-filter actions with bounded titles, stable IDs and explicit empty/error states.
• For local practice, state clearly that memory is temporary.
• For shared private operation, implement maintained identity/session protection, per-owner read/write authorization, writable-field validation and driver-bound persistence.

• Retain tests for valid creation, empty/overlong input, repeated/uncertain requests, owner versus other-owner operations, persistence and failure recovery.
• Record initial state, expected/observed outcomes and unchanged data after rejection.
• Test the actual implementation rather than merely checking planner reminders.

• Provide a README with setup, architecture, data/request contracts, your contribution, actual tests and limitations.
• Identify the release you demonstrate, check keyboard/mobile behavior and prepare a short explanation of one tradeoff and one failure you diagnosed.

• Success criterion: another reviewer can run the project, repeat its important tests and understand the decisions.
• All30 lesson pages are now available in the course; this page’s completion marker records only this lesson on this device.