The Working Application

Three of those answers are worth having in front of you, in the application's own words. Check 1 and check 8 are the health route's two answers, {"status":"ok","database":"ok"} and, with 503, {"status":"down","database":"unreachable"}; the second tells you in one second that the application is up and MySQL is not. Check 9 answers:

Port 3000 is already in use. Stop whatever is using it, or set PORT in .env to another number.

Check 9 exists because of what writing this chapter found: the start-up code had a friendly message for a port in use that could never be printed, because listen's callback is never handed an error. The fix is four lines, and the checklist is what would have caught it on the day.

Check 11 is the one students assume and should prove. In this project it holds by design: there is not one script, stylesheet or font fetched from anywhere, so the pages render with the network cable out. A project that loads a stylesheet or an icon set from the internet has a demonstration that depends on the college Wi-Fi, and it will be the Wi-Fi that fails, not the project.

Data worth demonstrating with

The seeded data of sql/seed.sql exists for this: fourteen dishes with real names, real prices in paise and sensible stock, three roles and six people. Compare a demonstration with that against one with item1 at Rs 1 and users a@a.com and test, and the difference is a mark or two for nothing.

Four rules for demonstration data:

• Believable. Real dish names, real prices, plausible quantities. It takes ten minutes and it makes the system look finished.
• Enough of it, and not too much. A menu of fourteen and a handful of orders shows structure; two hundred rows shows nothing and scrolls.
• Never a real person's. Reset to the seeded accounts before the day; no real student's name, address or order in front of an audience.
• Set up so the interesting cases exist. One dish already sold out, one down to two, one switched off for the day: that is how the refusals can be shown without pretending.

And one that only a project with a clock needs. The counter's screens exist during the lunch break, and an examination is rarely at 12:35, so DEMO_TIME in .env stops the clock where you need it (Chapter 68 has the three instants). The server prints at start-up that the clock stands still, so nobody demonstrates with a frozen clock by accident, and you can say out loud that it is set, which is more impressive than hoping nobody notices.

When the network fails, and it will

The rule is simple: the demonstration runs entirely on the machine in your hands. Server, database and browser on one laptop, reaching each other on 127.0.0.1, exactly as the six steps set it up. Nothing in the room matters except the laptop and its charger.

The phone is the only part that needs two machines to talk. Three ways, in order of reliability:

Whichever you choose, do it the day before and leave it set up. The APK's address is fixed when it is built (SERVER_URL in android/app/build.gradle.kts), so discovering on the day that it points at the lab desktop means rebuilding an APK in front of an examiner.

Two more things in the bag: a USB drive with the whole project, the PDF and the APK, in case the laptop dies and a friend's machine must be used, and a printed page with the seeded accounts and the demonstration steps, so that nobody has to remember a password while being watched.

The cold start, as a drill

Practise this until it takes three minutes and nobody has to think:

sudo systemctl start mysql              # or the local MySQL service
cd ~/canteen-preorder
npm start                               # the server says where it is running
curl localhost:3000/api/health          # {"status":"ok","database":"ok"}

Then, in the browser: sign in as the owner, check the day's stock is set, sign in as a student in a second window, and place one order to prove the loop before anybody is watching. If you have to reset, npm run db:setup puts the seeded data back in seconds, which is why nothing in the demonstration should depend on data you cannot recreate.

When something breaks in front of the examiner

It happens to good projects, and how you handle it is itself assessed, because it shows whether you understand your own system.

• Say what you expected. "That should have moved to Ready; the list refreshes every ten seconds, so let me reload it." An examiner who hears the mechanism knows you built it.
• Give it one minute. Beyond that, move on to the next part of the demonstration and come back. Nobody's marks improve while four students crowd a keyboard.
• Show the log if it helps you. The server prints a line for every request, including every refusal; being able to point at it is evidence, not an apology.
• Never blame the machine without checking. Half of all demonstration failures are the network, and you have removed that dependency; the other half are the two mistakes in the checklist above, which is why they are on it.

Do this for your project

1. Decide the demonstration machine and prepare only that one.
2. Run the twelve checks two days before, on that machine, and write the answers down.
3. Seed believable data, and set up the interesting cases so refusals can be shown honestly.
4. Fix the clock if your system depends on the time of day, and say so out loud.
5. Remove every dependency on the network: nothing fetched from the internet, database local.
6. Prepare the phone the day before, and leave it set up.
7. Practise the cold start until it takes three minutes.
8. Carry a USB drive with everything, and a printed page of accounts and steps.

Mistakes that cost marks

A demonstration that needs the Wi-Fi, usually because a stylesheet or font is loaded from the internet.

Data that looks like a test: item1, a@a.com, prices of Rs 1.

A first start in front of the examiner, and a start-up error nobody has seen before.

No way to reset, so a mistake in the first minute spoils everything after it.

The APK pointing at the college lab's address, demonstrated from a room on the other side of the college.

Demonstrating from a laptop that has never run the clean clone, so the system works only where it was written.

Four people at one keyboard when something fails.

Quick revision

• Working means: starts from cold, does the whole loop, refuses nonsense visibly, survives a restart, needs nothing outside the room.
• Run the twelve checks two days before, on the machine you will bring.
• The health route answers 503 and "database":"unreachable" when MySQL is down; a second start says the port is already in use.
• Believable seeded data, the interesting cases prepared, never a real person's.
• DEMO_TIME fixes the clock, and the server says at start-up that it is fixed.
• Everything on one laptop; the phone joins a hotspot, prepared the day before.
• Practise the cold start; carry a USB drive and a printed page of accounts and steps.
• When it breaks: say what you expected, one minute, move on.

Questions you must be able to answer

1. What does an examiner mean by a working application? One that starts from cold on the machine you brought, carries out the whole main path with believable data, refuses invalid input with a message a user could act on, keeps its data across a restart, and depends on nothing outside the room.

2. How do you prove the application is not dependent on the network? By disconnecting it and reloading every page. In this project it holds because nothing is fetched from the internet: every script, stylesheet and image is served by the application itself, and the database is on the same machine, reached on 127.0.0.1.

3. Why does the health route matter at a demonstration? Because it separates two failures that look the same. {"status":"ok","database":"ok"} says the application is up and can reach its database; a 503 with "database":"unreachable" says the application is up and MySQL is not, which is a thirty-second fix rather than a mystery.

4. Why fix the clock with DEMO_TIME, and why announce it? Because the counter's screens exist only during the lunch break and an examination is rarely at 12:35. It is announced because the server prints it at start-up and because saying so is honest: a demonstration at a fixed instant shows the system, and pretending otherwise is the thing that looks bad.

5. What data should a demonstration use? The seeded demonstration data: real dish names and prices, sensible quantities, the three roles, and the interesting cases already set up, one dish sold out and one nearly so. Never a real person's data, and never so much of it that the screens are just scrolling.

6. What do you do when something fails while the examiner is watching? Say what you expected and why, give it about a minute, use the log if it helps, and then move on and return to it. How a failure is handled shows whether the team understands the system it built.