OneView Compression

The map plots every compressor as a status-coloured marker, grouped into clusters. The first clustering approach compared every marker with every other one, so its cost grew with the square of the fleet size, and zooming and panning got sluggish on large fleets. The map also lost its zoom and cluster state whenever someone opened an asset and came back.

• Rewrote clustering as a hybrid: small sets keep exact pairwise grouping; above a size cutoff, markers drop into grid cells and only neighbouring cells are compared.
• A quick pass over the data's spread picks the cluster threshold for each zoom level.
• Memoized derived data, rendered only on-screen clusters when there are many, debounced interactions and cut unnecessary DOM updates.
• Added click-to-zoom on clusters, a reset-zoom that re-clusters and state preservation across asset drill-downs. The status KPI cards and filters now drive the markers.

Clustering cost dropped from quadratic to roughly linear for typical fleets, and the map stayed responsive as fleets grew. It became one of the product's core screens.

Loading sensor time series for every asset in a large fleet fired so many parallel requests that the browser rejected them with a resource-exhaustion error, and readings never loaded.

• Worked it out by experiment in one evening. Firing every request at once failed outright.
• Identified the browser's per-origin connection limit as the real constraint, then tried progressively smaller caps to see whether more parallelism paid off. It didn't.
• Settled on 6 and grouped work into batches.
• Wrote a small reusable worker-pool helper that returns the same result shape as Promise.allSettled, plus one app-wide limiter so every caller shares a single cap.

Sensor data loads reliably for large fleets, and both data-loading paths share the helper and the limiter.

Engineers scan hundreds of readings per compressor to spot what's abnormal relative to alarm limits and downtime history. Time zones and number formatting kept producing bugs.

• Built a resizable split view: a reading list with sparklines, range bars that place each value between its low and high alarm setpoints, and average, variance and z-score columns.
• Beside it, a trend chart with a secondary axis, shaded downtime overlays, and preset and custom ranges with cached 24h / 7d / 30d windows.
• Reworked the half-circle alarm gauge to handle negative ranges and zone logic, and to show “unknown” instead of a false “normal” when data is missing.
• Wrote down the team's time rule (UTC to the API, local time for display) and introduced a shared helper for parsing thousands separators, which guarded against a class of bug that could read “1,518 RPM” as 1.

These screens became the core asset-detail experience.

Some users work across more than one organization. A switch had to reset the whole app, with no leftover screens or late responses from the previous organization, and every other open tab had to stay consistent.

• Data providers wait until the active organization is resolved before loading.
• On a switch, every in-flight request is cancelled through the shared HTTP client and the providers reload.
• BroadcastChannel tells other open tabs so they can prompt a refresh; a user on an asset page returns to the fleet root.
• Organization logos fall back to deterministic, hash-coloured avatars showing the organization's initials, with proper empty and no-access states.

Shipped to production and documented as a core pattern in the team's architecture guide.

The team needed a front end it could demo quickly, and AI-generated prototypes rarely hold up as a long-term codebase.

• Directed an AI coding agent to build the whole shell in about two and a half weeks: sidebar shell, fleet overview, map, downtime timeline, asset detail, first gauges.
• Made the architecture calls: JavaScript with JSDoc (agreed with the team), front end only, one shared HTTP client, Context plus hooks instead of a state library, consistent file naming.
• Rewrote the prototype code over the following months with the team. Wrote the architecture guide and the AI-assistant context files and was primary author of the styling guide, so later contributors follow the same rules.

Very little prototype-era code survives unchanged. The conventions did: they are the team's reference for new work.

A new design specification gave separate colours to roles the code had carried in a single “primary” colour: actions, links, destructive states and more. Swapping the variable would have quietly recoloured badges, links and panels with the wrong meaning.

• Worked with an AI pair programmer to compare the spec with the code and plan the migration in phases, keeping product decisions apart from mechanical edits.
• Audited about 90 usages and classified each by meaning before changing anything.
• Contrast checks showed some proposed status hues fell well below WCAG AA as text on tinted backgrounds, so darker text shades were kept and lighter hues reserved for fills, borders and icons.
• Documented every deliberate deviation in the style guide and consolidated table rows onto one shared style.

The migration landed as one reviewable changeset with a clean build, plus a written list of what was adopted and what wasn't.