← The Naistro work02 / NAISTRO · CONTRIBUTION

Product guides the team could maintain.

Let teams maintain guidance as the product changes.

Where this work fits

An operator might need to pause several players or change a venue’s volume. Some devices could be connected while another was unavailable. A dashboard needed to make that situation understandable.

MY CONTRIBUTION

I built backend operations for ordered guide steps and editable content. Reordering used a transaction so related positions changed together, while loading defaults checked for existing steps to avoid adding them twice.

THE IDEA, ILLUSTRATED

Find the records that need attention

CATALOGUE FILTERING · A SMALLER, USEFUL VIEW

ProductQty.Status

Desk lampIn Stock

12Published

Reading lampLimited Stock

4Draft

Floor lampPre-Order

0Published

3 of 3 products

Filters combine: choose a status and an exact name to narrow the records. The backend also supports category and item-type filters.

THE ENGINEERING DECISION

A group command can have mixed results.

One unavailable device should not erase successful sends to the others. I returned per-operation delivery results and worked on aging connection state so a disconnected player would not look active indefinitely. A sent command still needed to be distinguished from observed playback.

The skills behind the work

DynamoDB: Store and retrieve device or application records using defined access patterns.
Transactions: Save related changes together, or roll them back together when a step fails.
Data modeling: Give different product concepts clear records and relationships so updates have predictable meaning.

THE WIDER RESULT

Operators could control players remotely and see more useful information about their availability. The backend supported venue-level actions without treating the entire fleet as one device.

READ THIS IN CONTEXTI connected dashboard controls to the players in each venue. →

Related contributions

Remote controls with per-device resultsI built WebSocket playback controls for individual players and groups of devices in a venue. A group operation could reach some devices while another was unavailable, so its result needed to preserve that distinction instead of returning one blanket success.Device status that ages with the connectionI worked on device heartbeats, reconnection state, and cleanup of stale connections. The fleet view needed to stop treating an old connection as an active player while retaining useful device context when it reconnected.The right notice for each playerI built targeted player-notification behavior for different platforms and software versions. This helped clients receive messages and actions appropriate to the device they were running.A venue view shaped by responsibilityI worked on authentication and role-aware access to venue resources. Establishing who someone is and deciding which locations or devices they may access are related but different responsibilities.