Room booking for universities. Find a room on the map, book it in one pop-up, and let the system catch the double bookings.
Booking a room at a university usually means a spreadsheet, a portal nobody likes, or walking the corridors looking for an empty one. EduRoom was our semester project to do it properly: a map of the buildings, every room on it, and one pop-up to book.
The sketch on the right of the whiteboard became the real thing almost one to one. Click room 5123 on the map, and the pop-up asks for the date, start and end time, a title and description, files and guests. Then Book.
The hard part isn't the form. It's making sure two people can't book the same room at the same time.
We designed it before we built it: system context, container and component diagrams, an ER diagram, class diagrams for each part of the domain, state machines for users and admins, and sequence diagrams for every important flow. They live in the repo next to the code.
Rooms sit on a map of the campus. Search or filter, and the map flies to the building. Click the room you want.
Date, start and end time, a title and description. Attach files and invite guests.
The server checks that the room exists, the times make sense and nothing overlaps. If something clashes, you're told why.
A booking series books the same room on chosen weekdays between two dates, for a whole course in one go. Every date is checked for conflicts.
Subscribe once and your bookings show up in Apple Calendar, Google or Outlook, and stay up to date.
Book study and group rooms, see their bookings and the bookings they're invited to.
Book lecture halls, including repeating series for a whole semester.
Add and remove buildings and rooms, and edit anyone's bookings.
Rooms are found where they are, not in a long dropdown.
A personal subscription link (webcal:// on Apple devices) with your bookings and invitations.
Files attached to a booking are encrypted before they reach the database.
The backend is split into four layers, and dependencies only point inwards. Business rules know nothing about the database or HTTP.
Each rule fails with its own named error, so the frontend can say exactly what went wrong instead of “something failed”.
Each file is encrypted with AES-GCM using a fresh random nonce, and stored as one blob. The tag at the end means a tampered file is refused when it's read back.