Every argument in the week's reading, written out for someone who has not opened the source, plus a cheat sheet before each exam. Three exams and no essays.
Convolution, Fourier series and transforms, sampling and Laplace, from Oppenheim and Willsky. A quiz at the start of every Friday tutorial and three lab quizzes carry a quarter of the mark between them, and the nine problem sets are the practice for those.
Four laboratories, five assignments with the best four counted, a term project whose details have not been published, and three quizzes.
The Adjustable Bed Canvas Holder, one client project carried across the term on a budget of 75 dollars, with ten deliverables, four in-class tests and no final exam. The team sets its own dates for deliverables B through J.
Every exam and test across the four courses, in the order they fall, with the deliverable that opens the design project and the day that closes it. Three dates are still with the Registrar. Each course hub carries its own laboratories, weekly quizzes and assignments.
| When | Course | Assessment | Weight | Where |
|---|---|---|---|---|
| Fri 18 Sept | GNG2101 | Project deliverable A, which includes setting the team's dates for B through J | — | Brightspace |
| Wed 7 Oct | PHI2394 | Exam 1, covering every reading and lecture so far | 30% | In class |
| Fri 9 Oct | GNG2101 | Design Test 1 | 5% | In class, lecture 9 |
|
Two midterms in two days
Signal and System Analysis on the Wednesday afternoon, Digital Systems II the following evening. They arrive two weeks after the first philosophy exam, so the October study load wants planning ahead of it.
|
||||
| Wed 21 Oct 14:30 to 15:50 | ELG3125 | Midterm, covering chapters 1 to 3 | 25% | STE H0104 |
| Thu 22 Oct 19:00 to 20:20 | CEG3155 | Midterm, which cannot be transferred to the final | 20% | FSS 1007 |
| Tue 10 Nov | GNG2101 | Design Test 2 | 5% | In class, lecture 16 |
| Wed 11 Nov | PHI2394 | Exam 2, covering the material after Exam 1 | 30% | In class |
| Tue 17 or Fri 20 Nov | GNG2101 | Lab Test, hands-on skills. Listed on both dates, so the day still needs confirming | 10% | Skills labs |
| Tue 24 Nov | GNG2101 | Economics Test | 10% | In class, lecture 20 |
| Thu 3 Dec | GNG2101 | Design Day | — | Final showing of the project |
| Set by Registrar | ELG3125 | Final exam, covering the material after the midterm | 50% | To be announced |
| Set by Registrar | CEG3155 | Final exam | 40% | To be announced |
| Set by Registrar | PHI2394 | Final exam, covering all class material | 40% | To be announced |
Engineering Design has no final exam. Its marks come from the project deliverables and the four tests in the table, which is why it carries the most rows and finishes on Design Day.
Every open piece of work on the hub, for all four courses, kept here beside the course pages. A closed item shows its heading and one line. Opening it gives the reasoning and the steps. Ticking an item moves it into Done at the foot of the list, and unticking it puts it back where it was.
Work that serves every course page at once.
Where the ticks are now. Every tick box and every highlight is saved by the browser under a key for this site. It survives a reload and a restart. It is lost when site data is cleared, it never reaches a second device, and one browser knows nothing about the other.
The proposal. Google Firestore holds the state and Firebase Authentication handles the sign-in, arranged so the page keeps working with no account at all. The browser stays the default, and the page behaves signed out exactly as it does today. Signing in with Google copies what is in the browser up to Firestore, and from then on both are written together. A second device signed in to the same account opens with the same ticks.
Why the sign-in comes with it. A database with no sign-in has to allow writes from anyone who finds the address, and this repository is public, so the address is findable. With sign-in, a Firestore rule of the shape "a signed-in person may read and write only the documents under their own user id" means a stranger who signs in gets an empty private space of their own, and can neither see nor change hers.
What it costs to run. The Firebase configuration values are identifiers, so publishing them in a public repository is safe, and the security rule is what protects the data. The free tier covers a workload this size with room to spare.
How the data is shaped. One small document per course. A Firestore document stops at one megabyte, and the philosophy highlights are the part that grows, so a single document holding all four courses reaches that ceiling first.
The seam is already there. shared/tasks.js routes every read and every write through one object called store, so the change is that object plus a sign-in button.
elg3125/pages/ still carry their own copy of the design system.
Tidying
What each page carries. Its own colour tokens in all three theme states, its own type scale, its own table and its own toggle, around sixty lines repeated ten times. The only shared file any of them links today is shared/nav.css.
The change, per page. Delete the duplicated block, add <link rel="stylesheet" href="../../shared/hub.css"> above the nav stylesheet, and leave in the page's own <style> block only what belongs to that page: the ELG3125 accent and the column classes the problem table uses.
What to check afterwards. The figure and scan images, which the shared file says nothing about, and the back link at the top of each page. Do one page end to end in both themes before the other nine are touched.
What it saves. A change to a colour, a table or a toggle is one edit today. With these ten pages holding copies it is eleven, and the copies drift the first time one of the eleven is missed.
The philosophy guides stay as they are. They are published from a separate repository, so reaching this file would mean loading a stylesheet across origins, and that is a separate decision from tidying these ten.
What is built.
index.html, the front page, one card per course in a fixed order, with the dates table above this listshared/hub.css, the design system every page in the repository importsshared/nav.css and the course bar across the top of every pageshared/tasks.js, the tick boxes, the meters and the print behaviour of these toggleselg3125/, moved in from its own folder and stripped of the inline design system it used to carryceg3155/ and gng2101/, each holding the course facts with a banner naming what is absentmyermcat.github.io/phi-reading-hub.nojekyll, so GitHub Pages serves the files untouchedA new repository was built, leaving the philosophy one alone. The repository phi-reading-hub already serves published pages at a URL that has been shared, its week 1 guide is a 285 KB page carrying saved highlights, and its browser storage keys are tied to that origin. Renaming it breaks the published address and every stored highlight. A new umbrella repository costs nothing, and philosophy is reached from it by a link.
Extracting the shared stylesheet is the part that stops work being redone. The ELG3125 page carried its own copy of the tokens and the components until it moved here, and the philosophy hub in its separate repository still carries one. A single file, imported by every page here, means a change to the card or the dark palette happens once. Each hub keeps only its own accent colour.
What is left.
README.md still lists elg3125/index.html as "still to be moved in", and it says nothing about shared/nav.css.course-hub skill still gives the ELG3125 page as ELG3125/elg-hub/index.html on disk and calls it the last page carrying its own design system inline. The ten pages under elg3125/pages/ hold that title now.What exists now. The original skill was written for reading philosophy. Separating what every hub shares from what belongs to one kind of course left three pieces.
course-hub, the shared one. The design tokens, every component in shared/hub.css, the interaction rules, browser storage, the folder convention and the publishing steps. Both course skills point at it.course-readings, kept as it was. Its heart is narrating an argument for someone who will not read the source, which suits philosophy and suits nothing in an engineering course. It keeps the guide specification, the explanation standard and the optical character recognition pipeline for scans.course-problem-sets, new. The assignment table, the problem index, marking up source pages, worked solutions, and preparing for a weekly quiz.Why one general skill was rejected. The explanation standard in the philosophy skill exists to stop summaries that teach nothing about an argument. A problem set has no argument to narrate, and folding the two together would either bury that standard or apply it where it does not belong. The parts genuinely shared are the interface and the prose, which is what course-hub holds.
What is left. The shared skill describes files that keep moving, and nothing checks it for drift. Its course table still gives the ELG3125 page at its old path, and its component list has to gain a row every time shared/hub.css gains a component. Both are a read-through after any change to the stylesheet or to where a page lives.
Work that belongs to one course. The first pill on each item says which.
CEG3155. The schedule, the fifteen dated items, the marking scheme, the topic list and the toolchain are on the page, taken from the outline dated 17 July 2026, the notes from the first class on 12 September and the Lab 1 handout. Two things are absent. The project description, worth 10 percent, was promised in class and has not been published. The laboratory detail, meaning what each of the four labs builds and what has to be prepared for it, is on Brightspace and has been worked through for Lab 1 only.
GNG2101. The ten deliverables and their dates are complete. The project record is in GNG2101-context.md in the course folder: the client brief, the benchmarking, the price landscape, the approaches already ruled out and the questions for the client. None of it has been brought onto the page.
Each one is a working session of its own, and each ends with the banner at the top of that page coming off.
The copy in use. Second edition, ISBN 9780136511755, in the course folder. Problem 1.21 is on printed page 59, which matches the pages scanned for Assignment 1. Printed page plus 22 gives the page in the file.
uOttawa Omni returns six results for the author and title. One is the book that matters: Signals & systems, Oppenheim, Willsky and Nawab, 1997, on Reserve at Morisset plus other locations. A 1983 first edition with Young as third author is in the General Collection at QA 402 .O63 1983, and its problem numbering does not match what the assignments ask for.
There is no electronic copy through the library. The only results offering online access are a 1985 journal review of the book and two unrelated book chapters. A 2015 printing shows as not available locally.
The route taken was a Reserve loan, with the problem pages for chapters 1 to 3 photographed first because those carry the midterm.
The book is never read into a conversation. A script walks the pages and writes a small table; the conversation only ever sees the handful of pages a given assignment needs, so the index cost almost nothing to build.
ocrmypdf, which adds a searchable text layer without changing how the pages look.^(\d+)\.(\d+)\., and record chapter, problem and page.Working files/problem-index.json as a map from problem number to page.A whole textbook is far too large to read directly. The index makes the cost of a lookup independent of the size of the book.
What was built. Ten pages under elg3125/pages/, one per assignment except set 6 which runs to two, reached from the Questions column of the table on that hub.
Each problem appears twice, as typed text and as a picture, because neither alone is enough. Typed text renders the mathematics properly, can be searched, and costs almost nothing to revisit. Many problems refer to a figure, such as Figure P1.21 in the first assignment, and a figure has to be an image.
Drawing the rings. PyMuPDF searches a page for the problem label, for example 1.21, which returns the rectangle holding it. Widening that rectangle to the column and adding page.add_rect_annot in the accent colour draws a ring around the problem. Rendering afterwards bakes the ring into the image. Only the assigned parts are ringed: for Assignment 1 that means 1.21 (c)(d)(e), 1.22 (b)(d)(e), 1.23 (b), 1.24 (c) and 1.25 (a)(c)(e), leaving the unassigned parts plain.
The marking was built and checked on the Assignment 1 scan first, because those three pages were downloaded while the rest of the book was still being sourced.
Where they go. One text file per deck in Working files in the course folder on disk. The decks are Prof. Yao's, so they stay out of this repository and so do the transcripts.
How. PyMuPDF walks the pages of the deck and writes the text out. A deck takes seconds and needs no optical character recognition, because the slides carry a real text layer.
Where extracted text goes wrong. A slide whose content is an equation, a plot or a block diagram comes back as scattered symbols or as nothing at all. Rendered page images are kept for those slides and read directly, which is the expensive route and is used only where the text version fails.
What it buys. Finding which lecture covered a topic becomes a search across a folder of text files, with no deck opened and nothing large read.
It runs once per deck, so the item stays open all term and is cleared a lecture at a time.
Why they matter. The midterm falls on Wednesday 21 October, covers chapters 1 to 3 and carries 25 percent of the course mark. These two papers are the closest thing available to a practice paper for it.
Where they are. On Prof. Yao's own page at site.uottawa.ca/~jpyao, the same page the Solution column of the assignments table links to. The files are served from a folder named for the old course code, ELG3120, which is a stale label on current material.
How to use them. Work the midterm paper through with the solution closed, then mark it against the posted one and write down every question that needed the solution. That list is what the last week before 21 October is for.
They stay on disk. The papers and their solutions are Prof. Yao's, so the hub links across to them and keeps no copy.
Nothing is done yet. An item moves down here when its box is ticked.
One stylesheet serves every hub. The colours, the type, the cards, the tables and the task lists live in shared/hub.css, and each course page sets only its own accent colour: green for philosophy, blue for signals, amber for digital systems, purple for design. Changing how a card looks is one edit for all four.
Philosophy keeps its own repository. Its reading guides are published at an address that has already been shared and is written into four other files, so moving them would leave every one of those links pointing at nothing. The card above goes across to them instead.
Tick boxes are saved in this browser. Marking a task done on any of these pages writes to the browser you are using and survives a reload and a restart. The state does not travel to another computer, it is never sent anywhere, and clearing browsing data for the site removes it.
These pages were built with Claude from Brightspace, the course pages and the lecture decks. They are dependable on dates, rooms and weightings, all of which were read off a published source. Check anything that decides an answer against the course page itself, because a date can move after a page is written.