NextgenBytes
NOTES • WRITE-UPS • DEBUGGING

Real write-ups, not request placeholders.

These notes explain how I think about auth, scheduling, and embedded filtering so the portfolio has depth beyond screenshots.

Back to portfolio Jump to first note
Phoenix Scheduling Embedded filtering Readable write-ups
Phoenix / Auth

Phoenix Auth: test-friendly session and redirect flow

When auth logic gets hidden behind too many branches, the tests become fragile and the user experience starts to drift. I prefer to keep the current scope explicit, then let controllers and components read from that one source of truth.

That pattern makes it easier to reason about redirects, flash messages, and edge cases like sudo mode because the same state drives both the implementation and the expectations in tests.

The practical goal is consistency: if the UI says a user is authenticated, the test should prove exactly how that state was reached.
  • Keep the auth state in one place instead of branching across templates.
  • Assert the exact flash and redirect path in tests so regressions are obvious.
  • Prefer small helpers that make the controller flow easier to scan.
Scheduling

Round-robin scheduling: what the overhead actually costs

Round-robin is easy to describe and easy to misread. A small quantum improves responsiveness, but the context-switch overhead starts eating into throughput if the scheduler interrupts work too often.

The useful mental model is not just fairness versus speed. It is also how much time the system spends deciding and reshuffling instead of finishing useful work. That tradeoff matters because user perception and raw efficiency can pull in different directions.

The quantum should be small enough to feel fair, but large enough that the machine still gets real work done.
  • Small quanta improve interaction feel but increase switching cost.
  • Large quanta reduce overhead but can make interactive tasks feel sticky.
  • The right answer depends on workload mix, not a single universal rule.
Embedded

Servo scan plus ultrasonic filtering for a radar UI

Raw ultrasonic readings jump around. The fix is not to hide that noise, but to smooth it enough that the interface can represent the pattern without looking jittery. I like to treat the sensor stream like a UI problem, not just a hardware one.

Mapping the servo angle into a radar sweep gives the user an immediate sense of direction and distance. Once the readings are filtered and the motion is translated into a visual arc, the hardware starts to feel like a product.

The best embedded UI often does two jobs at once: it makes the hardware readable and it makes the project memorable.
  • Smooth the readings just enough to remove noisy spikes.
  • Translate angle and distance into a visual language people recognize quickly.
  • Use the interface to tell the story of the hardware, not just expose raw numbers.