TechVani: Semester 5 Labs and Mini-Project

Semester 5 - Page 6: Labs and Mini Project. 24 numbered practical topics, highlighted rules, worked cases, answered viva questions, workflow diagrams, evidence tables and a complete Python task-rule demo. General practical guide, not an official lab list, syllabus or submission rule. Match stack and assessment requirements to your current faculty handout.

Offline demo: Python 3, standard library only; nine behavior assertions are executed. It has an in-memory store and simulated owner names, not real authentication, API or durable storage. Existing Full Stack, Networks and ML lab links below have their own browser/Node/C/Python runtime requirements.

Topic map

Scope, faculty sheet and honest evidence
Experiment record and reproducibility
Safety, permissions and private data
Full-stack vertical slice
Form validation and accessible UI
API contract and request handling
Ownership and security boundary tests
Persistence, errors and recovery
Browser, Node and deployment runtimes
Network addressing and subnet practical
Protocol trace and diagnosis
Network code and socket limitations
.NET event-driven practical
.NET binding and boundary cases
ML task, baseline and data permissions
ML split and train-only fitting
ML metrics and limitations
Mini-project problem and scope
Requirements, design and traceability
Version control, roles and integration
Test matrix and failure demonstration
README, report and citations
Demo, viva and fallback
Final practical checklist

1. Scope, faculty sheet and honest evidence

This practical guide covers reusable Semester 5 workflows, not a fixed official experiment list. Match required stack, report, dataset and deadlines to your actual department sheet.

Worked example: Choose a small study-planner flow and identify which subject skills it demonstrates; do not claim every idea is mandatory.

Exam question: Can this guide replace the current faculty handout?
Answer: No. The assessed experiment list and submission rules come from your department.

2. Experiment record and reproducibility

Record aim, assumptions, prerequisites, method, code/configuration, actual output, tests, conclusion and limitations. Keep instructions usable by a new person.

Worked example: A network calculation names prefix and host conventions; a Python experiment names interpreter and inputs.

Exam question: Does a screenshot alone prove the expected result?
Answer: No. Include assertions or a clear expected-versus-actual check.

3. Safety, permissions and private data

Use synthetic/test data and permitted systems. Exclude passwords, keys, private records and auth tokens from source, screenshots and logs.

Worked example: Use fictitious task owners Asha and Ravi; do not use classmates' private scores without permission.

Exam question: Does a lab assignment grant permission to scan any network?
Answer: No. Network and account access must be explicitly permitted.

4. Full-stack vertical slice

Build one flow through UI, API and persistence before adding decorative features. The server owns validation and authorization; the browser provides feedback.

Worked example: Create one task, receive its real stored identifier, fetch it and confirm it remains after the expected persistence restart behavior.

Exam question: Can an optimistic UI card alone prove the database write committed?
Answer: No. Verify the response and durable state.

UI form -> API contract
        -> identity + rules
        -> persistent store
        <- confirmed result

One vertical slice needs real boundary evidence, not only a rendered card.

5. Form validation and accessible UI

Use labels, keyboard order, clear errors and responsive layout. Validate syntax and meaning on client and server; preserve input on failure.

Worked example: Blank title shows a useful error and causes no write. Complete the form without a mouse and inspect narrow/wide screens.

Exam question: Can hiding a submit button enforce a business rule?
Answer: No. The server must reject invalid/prohibited actions.

6. API contract and request handling

Define methods, endpoints, data shape, status and error behavior. Distinguish HTTP failure from network failure and resolve uncertain writes before repeating them.

Worked example: A lost response after create may hide a successful commit; check state/idempotency rather than blindly creating twice.

Exam question: Does Fetch reject every HTTP 400 or 500 response?
Answer: No. Check response.ok/status in normal Fetch handling.

7. Ownership and security boundary tests

Every protected object action needs server-side permission checks. Test an allowed owner and another signed-in user changing the identifier.

Worked example: Asha can complete Asha's task; Ravi is denied even with the correct task ID. The offline demo models this rule only.

Exam question: Does the demo prove a real web authentication system is secure?
Answer: No. Actual identity/session/database integration needs separate tests.

8. Persistence, errors and recovery

Use suitable schema constraints, parameterized access and transaction boundaries. Test storage failure and preserve input instead of showing false success.

Worked example: A simulated failed store returns a visible error; a real test store confirms no partial related writes.

Exam question: Does a local array demonstrate durable storage?
Answer: No. Label it in-memory and test the actual persistence separately.

9. Browser, Node and deployment runtimes

Browser DOM, Node console, Node HTTP and database examples have different prerequisites. Use the matching environment and document limitations.

Worked example: A DOM button exercise runs in a browser; a Node server needs Node and port permission; a compiler box may not support either UI/server behavior.

Exam question: Can every JavaScript lab run in a generic console compiler?
Answer: No. Required APIs and allowed runtime behavior differ.

10. Network addressing and subnet practical

Calculate prefix mask, block range, broadcast and ordinary usable hosts with stated exceptions. Distinguish address membership from host eligibility.

Worked example: 192.0.2.42/26 belongs to a 64-address block ending.63; ordinary host count 62. Reuse the core-note calculation before packet tools.

Exam question: Should two always be subtracted for /31 or /32?
Answer: No. Point-to-point and host-route conventions differ.

11. Protocol trace and diagnosis

Trace DNS, transport, authenticated TLS and HTTP separately for one permitted request. Connection reuse/cache and HTTP/3 can alter the path.

Worked example: DNS succeeds but 404 occurs: name resolution worked and the resource/HTTP route needs inspection.

Exam question: Does ping establish that the web application works?
Answer: No. It tests limited reachability, not the whole service.

12. Network code and socket limitations

Portable arithmetic/simulation labs differ from POSIX socket programs. Socket tests need compatible OS, process behavior and local network permission.

Worked example: Run a loopback server/client only where permitted; state partial-read/write handling, cleanup and port assumptions.

Exam question: Can socket output be invented when the compiler lacks networking?
Answer: No. Report the environment limitation and actual observed result.

13. .NET event-driven practical

Keep handlers small; validate through reusable code; manage subscription lifetime and UI-thread rules. Use the actual course framework.

Worked example: Save click validates marks and awaits storage; failed work retains input. Console validation tests are not GUI checks.

Exam question: Does Mono console execution verify WPF layout?
Answer: No. WPF/Windows Forms need their Windows target environment.

14. .NET binding and boundary cases

Use framework-supported property/collection notifications and test domain boundaries apart from the form. Parameterization does not replace authorization.

Worked example: Test blank name, noninteger and marks below/at/above allowed boundaries; then inspect focus and error placement in the actual UI.

Exam question: Can changing a plain field always refresh bound controls?
Answer: No. Notification behavior depends on framework and binding design.

15. ML task, baseline and data permissions

Define target, input timing, unit, split and baseline before selecting a model. Use permitted synthetic/public data with license and provenance.

Worked example: A quiz demonstration predicts future outcomes from earlier features; a majority baseline uses training labels only.

Exam question: Does high training accuracy make a student prediction fit for consequences?
Answer: No. Evaluation, uncertainty and responsible use are separate duties.

16. ML split and train-only fitting

Keep tuning out of final test data; respect student groups/time. Fit scaling, encoding and feature selection inside training folds.

Worked example: A later quiz score is forbidden as an earlier prediction input. Document the split so another student can reproduce it.

Exam question: Does splitting after all-data scaling prevent leakage?
Answer: No. The preprocessing already used held-out information.

Allowed historical features
 -> unit/time split
 -> train-only fitting
 -> validation choices
 -> frozen final test

No future outcome enters earlier prediction features.

17. ML metrics and limitations

Report positive class, confusion counts, metric convention and split. Regression and clustering need their own suitable measures; toy scores are not production promises.

Worked example: TP 30, FP 10, FN 5 gives precision.75 and recall 6/7; say which mistake matters and why.

Exam question: Can accuracy alone settle an imbalanced support task?
Answer: No. It can conceal missed positive cases.

18. Mini-project problem and scope

Choose one real user problem with a small feasible core flow and explicit out-of-scope list. Prefer a working explainable slice to many unfinished claims.

Worked example: A planner creates/views/completes tasks; offline sync and notifications remain clearly listed future work.

Exam question: Can a slide list count as implemented features?
Answer: No. Demonstrate actual behavior and state unfinished work honestly.

19. Requirements, design and traceability

Write testable functional/quality requirements and map them to design/tests. Model entities and permissions without scattering rules across screens.

Worked example: Task ownership maps to server identity, object check and positive/negative tests; keyboard use maps to actual interaction evidence.

Exam question: Does every requirement need the same kind of test?
Answer: No. Choose evidence appropriate to behavior, quality and deployment scope.

20. Version control, roles and integration

Use small reviewed changes, agreed interfaces and clear individual contributions. Keep dependencies/configuration reproducible without secrets.

Worked example: Two teammates agree task JSON fields and errors before separately implementing UI and API.

Exam question: Does being in a team allow claiming every teammate's code as solely yours?
Answer: No. Credit actual authorship and explain your own work.

21. Test matrix and failure demonstration

Include normal, boundary, permission, duplicate, unavailable-service and uncertain-response cases. Separate planned tests from passed evidence.

Worked example: The offline task demo rejects blank input and other-user access; a real project also needs concurrent/durable/API/UI tests.

Exam question: Does a planned test marked in a table mean it passed?
Answer: No. Record run, actual result and environment.

Task rules and permission checks with exact assertions

tasks = {}
next_id = 1

def create(owner, title):
    global next_id
    if not isinstance(title, str) or not title.strip():
        return "invalid title"
    key = next_id
    tasks[key] = {"owner": owner, "title": title.strip(), "done": False}
    next_id += 1
    return key

def complete(user, key):
    if key not in tasks:
        return "not found"
    if tasks[key]["owner"] != user:
        return "forbidden"
    tasks[key]["done"] = True
    return "completed"

assert create("Asha", "  ") == "invalid title"
assert len(tasks) == 0
key = create("Asha", " Revise subnetting ")
assert key == 1 and tasks[key]["title"] == "Revise subnetting"
assert complete("Ravi", key) == "forbidden"
assert tasks[key]["done"] is False
assert complete("Asha", key) == "completed"
assert complete("Asha", key) == "completed"
assert len(tasks) == 1
assert complete("Asha", 999) == "not found"
print("9 behavior assertions passed")
print("stored tasks:", len(tasks))
print("task:", tasks[key])
print("In-memory rule demo only; no real identity, API or durable database.")

Checked output:

9 behavior assertions passed
stored tasks: 1
task: {'owner': 'Asha', 'title': 'Revise subnetting', 'done': True}
In-memory rule demo only; no real identity, API or durable database.

22. README, report and citations

Document purpose, setup, runtime, sample data, test commands, limits and contributions. Cite libraries/data and distinguish your work from reused material.

Worked example: A new person starts the demo using the README without needing a hidden credential in chat.

Exam question: Should a real API key be included to make setup convenient?
Answer: No. State the environment variable and safe setup, not the secret.

23. Demo, viva and fallback

Show one complete user story, an error case and a test, then explain architecture and limitations. Prepare a local fallback without inventing hosted success.

Worked example: Explain why task ownership is checked on the server and which storage failure behavior was actually tested.

Exam question: What if the hosted service fails during demo?
Answer: Use the prepared honest fallback and say what it does and does not verify.

Demo: one complete story
   -> invalid/permission case
   -> actual test evidence
   -> honest limits + contribution

Fallbacks keep a demo useful without claiming unverified hosted behavior.

24. Final practical checklist

Confirm faculty requirements, runnable setup, actual evidence, originality, permissions and private-data removal. Keep unfinished features out of completion claims.

Worked example: A peer follows setup, tests the core flow and checks citations; screenshots and assertions agree on the same version.

Exam question: When is the submission ready?
Answer: When the required version, report and demo are verified under the actual submission rules.

Subject-to-practical evidence

Subject	Practice	Evidence
Full Stack	UI/API/persistence slice	Request, real stored state, keyboard check
Networks	Subnet and request trace	Units, prefix boundaries, permitted observations
.NET	Event-driven form	Domain tests plus actual Windows GUI check
ML	Baseline and safe split	Input timing, metric counts, limitations
Software Engineering	Requirement-to-test trace	Design, tests, change and release evidence

Test matrix

Case	Expected	Actual evidence needed
Valid create	One stored task	Response + durable readback
Blank title	No write; useful error	Input/result + unchanged state
Other owner	Server denial	Actual object permission test
Repeated completion	Stated consistent behavior	Duplicate-operation check
Storage failure	No false success	Controlled failure + retained input
Lost response	Reconcile commitment	State/idempotency check

Runtime distinctions

Exercise	Environment	Limit
Browser DOM	Browser HTML/JS	Not plain Node console
Node HTTP	Node + permitted port	Not every online compiler
Portable C calculation	C compiler	Not POSIX socket evidence
POSIX loopback socket	Suitable local OS/network	Requires permission/process support
C# GUI	Course Windows framework	Console compile is not GUI proof
Offline Python rules	Python3	No actual authentication/persistence

Submission and viva checklist

Verify required experiments and format, run setup from a clean state, keep actual outputs and error cases, cite data/code, credit contributors and remove secrets/private records. Present only features that actually work. No elective list is inferred from a generic semester hub.

Resources and sources

Existing practical links are preserved. Core notes explain the theory; linked lab files specify their own code and runtime assumptions.