Techlist.io - Korean Tech Blog Curator

figma3 min readCurated summary

Can designers make a political difference? | Figma Blog

The post argues that designers can make a political difference by applying their skills, platforms, and creative work to support vulnerable communities and challenge political ideas. After Trump’s election, many designers moved from grief to action through pro-bono services, fundraising, public art, and political satire. Their work may not change policy directly, but it can strengthen organizations, shape public conversation, and build solidarity. ## Visible: Design Support for Grassroots Organizations - Portland agency The Beauty Shop responded to the 2016 election by offering free design work to organizations serving women, people of color, Hispanic, Muslim, immigrant, and LGBTQ communities. - The response quickly grew: - Their Instagram following quadrupled in two days. - Around 300 designers and studios volunteered, including a Facebook design team. - The founders created Visible, a coalition connecting designers with grassroots organizations. - Its initial twelve partners included: - The Iowa Abortion Access Fund - Nightingale, a healthcare-focused publication - The Yemen Peace Project, whose website had been attacked by hackers - The designers argued that strong branding and visual structure can make organizations appear more legitimate and help them succeed. ## Creative Action Network: Celebrating Shared Values - Creative Action Network (CAN) organizes artists around social-good campaigns for groups such as the National Parks Conservation Association and the New York Public Library. - After the election, CAN launched a project to publish one poster per day for the first 100 days of the Trump administration. - The posters celebrated elements of American life including jazz and religious freedom. - Rather than focusing only on protest, CAN emphasized celebrating the values and communities people wanted to preserve, creating common ground. ## Hallie Bateman: Art as Fundraising and Personal Resistance - Illustrator Hallie Bateman questioned whether her usual focus on ordinary moments still fit a changed political reality. - After reflecting on art’s role during periods of conflict, she began using her illustrations to raise money. - She sold a limited-edition drawing and donated the proceeds, excluding printing costs, to Planned Parenthood, raising $2,000. - She later created another print to support the Sierra Club. - Bateman acknowledged that her approach was informal and could become more strategic, but viewed creative fundraising as a meaningful way to contribute. ## Ben Barry: Political Satire Through Design - Former Facebook designer Ben Barry accepted a freelance assignment from The New York Times to design a satirical job application mocking Trump. - He explored several visual directions, including: - A poorly formatted elementary-school field-trip flyer - A document styled like an internal Russian government memo - An exaggerated, gold-and-brassy design reflecting Trump’s public image - The project allowed Barry to use design and humor in one of the country’s largest newspapers to criticize an administration he opposed. Designers can contribute politically by offering practical expertise, amplifying causes, raising funds, celebrating shared values, and using visual communication to expose or ridicule political power. The examples suggest that meaningful action does not require a single grand strategy; individual creative efforts can support broader movements.

Read original(opens in new tab)
figma3 min readCurated summary

Team Libraries in Figma | Figma Blog

Team Libraries bring shared, synchronized components to Figma, addressing the difficulty of maintaining design systems across separate files. The feature builds on Figma’s components, constraints, and web-based collaboration to create a single source of truth that teams can reuse and update efficiently. Its workflow—Publish, Insert, and Update—combines engineering-style structure with an accessible design workflow. ## The Problems with Traditional Design Tools - Many design tools were modeled on print and illustration software rather than interactive applications. - They lack meaningful support for application behavior, platform constraints, and reusable interface structures. - Copying symbols between files creates disconnected versions that must be updated manually. - Large organizations such as Facebook, Google, and Airbnb have had to build custom tools and dedicate staff to maintaining design systems. - Designers need synchronized, compounding component structures to create scalable systems. ## Bridging Design and Dynamic Interfaces - Figma’s earlier features established the foundation for reusable design systems: - Reliable vector editing - Constraints that reflect system behavior - Dynamic, reusable components - Team Libraries extend these capabilities across files and team members. - Because Figma operates online, shared components have effectively no synchronization delay. - Teams can reuse structured components across devices, platforms, layouts, and user flows. ## An Engineering-Inspired Design Workflow - Figma draws on software concepts such as modular composition and frameworks like React. - Structuring interfaces from discrete, clearly defined parts makes products easier to maintain. - The feature adapts engineering principles for designers rather than copying programming workflows directly. ## Publishing Components - Designers select components and choose **Add to Library** in the inspector sidebar. - Multiple components can be collected and reviewed before being published. - Permissions separate the source of truth from its consumers: - Editors of the source file can modify the original components. - Anyone with view access can use the published components. - This lets specialized teams control assets such as icons, colors, or brand guidelines while others reuse them without changing the rules. ## Inserting and Nesting Components - Published components are available in any file for users who can view the source file. - Users insert them through Figma’s components tool. - Components can be nested inside larger components or modules. - Nested structures allow teams to build complex views from reusable source elements while preserving a predictable single source of truth. ## Updating Shared Components - Changes are made to the original component and published again. - Figma provides a confirmation step and a visual diff showing what changed. - Deleting a component from the source file and publishing removes it from the team library. - The update process includes an additional safeguard because changes may affect multiple design explorations and could otherwise cause users to lose work.

Read original(opens in new tab)
datadog2 min readCurated summary

The trouble with mounting

Datadog found that some agents stopped reporting all metrics because they became stuck in an unkillable state during disk checks. The root cause was `os.statvfs`, whose glibc implementation can hang while inspecting NFS mounts configured with hard-mount behavior. Since agents run in unpredictable customer environments, Datadog isolated the call in a separate thread and allowed the main process to continue after a timeout. ## Detecting the Hang - Customers reported gaps across every metric, indicating that the agent—not an individual check—had stopped functioning. - Logs showed the agent sometimes hung without producing an error. - A watchdog failed to terminate it because the process was stuck in an unkillable system call. - Developer-mode timing data identified `os.statvfs` as the consistently slow operation. ## How NFS Causes Unkillable Processes - `os.statvfs` calls the Linux `statvfs` function through CPython and glibc. - `statvfs` can hang when examining a remote directory mounted through NFS. - NFS hard mounts retry indefinitely and do not time out system calls. - Soft mounts eventually return an error, while the `intr` option allows interruption of the calling process. - Hard mounts may be appropriate when reads and writes must eventually succeed, but they are risky with unreliable NFS connections because they are the default in many configurations. ## The `/proc/mounts` Complication - Glibc’s `statvfs` implementation checks each directory listed in `/proc/mounts` until it finds the requested mount. - Consequently, a disconnected NFS mount can block `statvfs` even when the agent is checking a different filesystem. - This made changing NFS mount options impractical as a universal fix because Datadog cannot control customers’ system configurations. ## Datadog’s Workaround - The agent now runs `statvfs` on a separate thread. - If the call exceeds a timeout, the main agent thread continues operating. - This approach avoids total metric loss across heterogeneous environments. - The trade-off is a modest increase in memory usage on systems with hard-mounted NFS volumes. The practical lesson is to treat filesystem statistics as potentially blocking operations, especially in environments with NFS. Isolating such calls behind timeouts provides more reliable monitoring than assuming system calls will always return promptly.

Read original(opens in new tab)
datadog2 min readCurated summary

The trouble with mounting | Datadog

The post explains why filesystem mounting becomes surprisingly complex in containerized Linux environments. Datadog’s Agent needs to inspect host filesystems from inside a container, but mount namespaces, bind mounts, and propagation rules can make the host’s view incomplete or inconsistent. The conclusion is that reliable mounting requires understanding namespace boundaries and deliberately configuring mount propagation rather than treating mounts as ordinary directory mappings. ## Linux Mount Namespaces - Each process can have its own mount namespace, isolating its view of mounted filesystems. - A container therefore sees a filesystem tree that may differ substantially from the host’s tree. - Bind-mounting a directory into a container does not necessarily expose mounts created beneath that directory. - This is particularly problematic for paths such as `/proc`, `/sys`, `/var/lib/docker`, and other locations containing nested mounts. ## The Problem with Bind Mounts - A bind mount initially exposes only the directory tree visible at the time it is created. - Later mounts beneath the source directory may not appear in the container. - Recursive bind mounts can copy nested mounts, but they introduce their own behavior and compatibility concerns. - Mounts can also be shared, private, or “slave,” determining whether mount and unmount events propagate between namespaces. ## Mount Propagation - Linux mount propagation controls how changes in one namespace are reflected in another. - Shared mounts propagate events in both directions, while slave mounts receive changes without sending them back. - Private mounts isolate changes completely. - Choosing the wrong propagation mode can cause the Agent to miss newly mounted filesystems or, worse, allow container-side changes to affect the host. ## Datadog’s Engineering Challenge - Datadog needs host-level visibility while keeping the monitoring container isolated and safe. - The Agent must account for mounts that appear after startup, including dynamically created container and volume mounts. - Correct behavior depends on both the container runtime configuration and the host’s existing mount topology. - A robust implementation must inspect mount metadata and handle namespace and propagation details explicitly. The practical recommendation is to treat mounting as a namespace and event-propagation problem, not merely a path-sharing mechanism. Systems that need host visibility should use carefully selected recursive mounts and propagation modes, validate the resulting mount tree, and test behavior when mounts are created or removed dynamically.

Read original(opens in new tab)
datadog2 min readCurated summary

Engineering spotlight: Marie-Laure Bardonnet

Datadog’s Notebooks feature demonstrates that interns can make substantial contributions when given meaningful ownership and effective mentorship. Marie-Laure Bardonnet progressed from small bug fixes to prototyping the feature, gaining hands-on experience with React, Redux, and Redux Saga. Her experience ultimately led to continued part-time work and a full-time role at Datadog. ## From Bug Fixes to Feature Ownership - Marie-Laure initially handled small issues, such as fixing a dashboard favorite-star interaction. - Gradually more complex tasks helped her learn Datadog’s codebase and application architecture. - Rather than limiting her to routine maintenance, Datadog assigned her a major project earlier than expected. ## Building Datadog Notebooks - Notebooks let users save graphs from a specific point in time alongside text and other contextual information. - The feature is designed to preserve and share organizational knowledge, helping teams respond more quickly. - Marie-Laure built most of the prototype during her seven-month internship. - The project introduced her to: - React for the frontend - Redux for state management - Redux Saga for handling side effects ## The Role of Mentorship - Team lead Ivan DiLernia gave Marie-Laure substantial autonomy while remaining available for difficult architectural decisions. - He encouraged her to investigate ideas independently, then collaborated with her when problems required deeper discussion. - Marie-Laure identified this balance between independence and guidance as one of the most valuable parts of the internship. ## Lasting Impact - The internship changed how Marie-Laure viewed her academic coursework, helping her distinguish practical engineering skills from more theoretical material. - After returning to France, she continued working part-time on Notebooks and other web-platform projects. - She later completed her studies and accepted a full-time position at Datadog. Datadog’s experience suggests that internships are most effective when they combine gradual onboarding, meaningful technical ownership, and thoughtful mentorship rather than restricting interns to low-impact tasks.

Read original(opens in new tab)
datadog1 min readCurated summary

Engineering spotlight: Marie-Laure Bardonnet | Datadog

The provided text contains Datadog’s navigation and promotional banner announcing its recognition as a Leader in the 2026 Gartner® Magic Quadrant™ for Observability Platforms. It does not include the actual blog post about Marie-Laure Bardonnet, so its argument, technical details, and conclusion cannot be reliably summarized. ## Available Content - Datadog promotes its observability platform and Gartner recognition. - The navigation lists products covering: - Infrastructure and application monitoring - Logs, databases, and data observability - Security and cloud protection - Digital experience monitoring - CI/CD and software delivery - Incident and service management - AI-powered observability and investigation - The page URL suggests the article is an “Engineering Spotlight” featuring Marie-Laure Bardonnet. Please provide the article body or a complete extraction of the page for a substantive summary.

Read original(opens in new tab)
figma3 min readCurated summary

Components in Figma | Figma Blog

Figma’s 2016 Components release applies software-engineering ideas such as composition, inheritance, and overrides to interface design. Components let designers reuse shared elements as linked instances, so updates remain consistent while local customizations are preserved. The result is a design workflow that supports both systematic reuse and creative flexibility. ## Designing with Components - Components help designers break complex interfaces into smaller, understandable parts. - Reusable elements can appear in multiple locations, at different sizes and with local modifications. - Unlike duplicated copies, component instances remain connected to their source. - Updates to the original component are automatically reflected across all instances, improving consistency and reducing repetitive work. - Examples include repeated address-book rows containing shared typography, spacing, icons, and graphics. ## Figma’s Design Goals Figma aimed to make Components: - Easy for new users to learn. - Powerful enough for advanced design systems. - Flexible throughout the design process. - Low-overhead, so systematic design improves speed without limiting experimentation. ## Creating and Using Instances - Any frame or selected object can be converted into a component through the toolbar. - Duplicating, copying, pasting, or Alt-dragging a component creates instances rather than independent copies. - Instances can move independently on the canvas while retaining their connection to the source component. - Changes made to the main component propagate immediately to its instances. - Certain internal properties, such as the position and size of nested objects, are restricted to make components easier to maintain. ## Style and Property Overrides - Instance changes are treated as overrides of the original component’s properties. - Designers can override fills, strokes, colors, widths, and properties of nested layers. - Overrides remain intact when the source component changes. - Properties that were not overridden continue to update from the source component. - Overrides can be removed with the “Reset Instance” action. ## Complex and Nested Components - Components can contain instances of other components. - Combining nested components makes it possible to build larger systems from smaller, reusable parts. - Designers can add instances to an existing component or create a new component from selected instances. - Nested components are intended to work like other Figma objects, keeping complex systems manageable. ## Constraints - Components can be combined with Figma’s Constraints feature. - Constraints allow elements to respond to changes in size and position. - Together, components and constraints support reusable designs that adapt more intelligently across layouts. Components provide a practical bridge between design and software development: create shared building blocks once, reuse them widely, and preserve controlled customization through overrides. Teams building consistent, evolving interfaces can use them to reduce duplication while keeping designs adaptable.

Read original(opens in new tab)
figma2 min readCurated summary

Delete and Heal for Vector Networks | Figma Blog

Figma’s “delete and heal” feature removes a vertex while preserving the surrounding shape as much as possible. What begins as a simple graph-editing operation becomes complex for curved segments and vector networks, where vertices may connect to many edges. Figma addresses this by fitting replacement Bézier curves and pairing edges according to their geometry. ## Basic Deletion and Healing - Standard deletion removes the selected vertex, its incident edges, and any fills that depend on those edges. - “Delete and heal” instead attempts to connect the neighboring vertices. - If a vertex touches only one edge, that edge is removed because no meaningful healing is possible. - Triangles and other small paths require special-case decisions about whether healing produces one edge or multiple edges. - The behavior differs between open and closed paths. ## Preserving Curvature - Curved segments are represented as cubic Bézier curves. - Deleting a vertex joins two cubic curves into one replacement curve. - Figma keeps the original endpoints fixed but adjusts the neighboring control handles to preserve the original curvature. - The algorithm: - Samples points along both original Bézier curves. - Treats the shared vertex as a single point. - Fits a new cubic Bézier curve through the resulting samples. - Figma uses a curve-fitting technique from Philip J. Schneider’s “An Algorithm for Automatically Fitting Digitized Curves,” published in *Graphics Gems*. ## Healing Vector Networks - Unlike traditional path-based editors, Figma models vector objects as undirected multigraphs with edge identity. - A vertex can therefore have more than two incident edges. - If the vertex has an odd number of connected edges, Figma removes all incident edges because no complete pairing is possible. - With an even number of edges, the edges are paired and replaced with new edges. - To determine which edges are “opposite,” the incident edges are sorted by their angles around the deleted vertex. - This graph-based approach allows delete-and-heal to work on branching vector networks, not just simple paths. Figma’s implementation combines graph topology, geometric pairing, Bézier sampling, and curve fitting to make deletion feel intuitive while retaining as much of the original design as possible.

Read original(opens in new tab)
datadog3 min readCurated summary

Redux-Doghouse: Creating reusable React-Redux components through scoping

Redux-Doghouse is a Redux library for creating scoped actions and reducers, allowing reusable React/Redux components to coexist without responding to one another’s actions. It preserves Redux’s ability to coordinate state across an application while ensuring that component-local actions affect only the instance that dispatched them. Datadog developed it to support reusable Query Editors within larger editors such as dashboards and Expression Editors. ## The Problem with Reusable Redux Components - Redux reducers respond to actions based on their `TYPE`. - If multiple instances of the same component share a Redux store, an action such as `MY_ACTION` can update every instance. - This is useful for application-wide events, but incorrect when an action should affect only one component instance. - Refactoring each component to use unique action types would undermine its reusability and independence. ## Scoped Actions and Reducers - Redux-Doghouse adds a unique scope to each component instance’s actions. - Reducers are wrapped so that a scoped action is routed only to the matching component instance. - A component can therefore continue using generic action types such as `MY_ACTION` while remaining isolated from sibling instances. - Higher-level components can still observe and respond to those actions, preserving Redux’s cross-component coordination. - The parent can extend a child component’s behavior without requiring the child to know about its parent. ## Datadog’s Query Editor Use Case - Datadog’s dashboards contain Query Editor components for editing individual metrics. - Query Editors were rebuilt as miniature React/Redux applications so they could be reused in: - Dashboard graph editors - Monitor editors - Notebook editors - Other application contexts - The Expression Editor needed to render an arbitrary number of Query Editors and combine their queries with expressions such as `a + b / c`. ## Coordinating Child Editors The Expression Editor needed to: - Validate that expressions reference existing query labels, rejecting inputs such as `a + d` when query `d` does not exist. - Enforce compatible `group by` values across queries: - Queries may share a value such as `host`. - Some queries may have no grouping. - Non-empty groupings such as `host` and `device` cannot be mixed. - Ensure that a `SET_GROUP` action from Query Editor A affects only A, not Query Editor B. - Allow the Expression Editor itself to observe `SET_GROUP` and enforce rules across all queries. - Keep Query Editors independent so they remain usable outside an Expression Editor. ## How Doghouse Solves It - The parent assigns each Query Editor a scope, such as `A`, `B`, or `C`. - Actions dispatched by each editor receive metadata identifying that scope. - The parent wraps each editor’s reducers and routes actions only to the reducer with the matching scope. - The Expression Editor can still listen to the same actions at a higher level and apply cross-editor validation or coordination. Redux-Doghouse is most useful when reusable Redux components need isolated local behavior while still participating in a shared application state. It lets teams organize actions and reducers by component, rather than forcing all Redux logic to be structured around entire views.

Read original(opens in new tab)
datadog2 min readCurated summary

Redux-Doghouse: Creating reusable React-Redux components through scoping | Datadog

Redux Doghouse presents a way to make React/Redux components genuinely reusable by giving each component instance its own scope. The approach addresses collisions in Redux action types, state, and selectors when the same component appears multiple times. Its conclusion is that scoped Redux logic can preserve the benefits of a centralized store while allowing components to behave like isolated, reusable units. ## The Reuse Problem in React and Redux - Redux state is global by default, while reusable components often need instance-specific state. - Reusing a connected component can cause: - Action types from one instance affecting another - Selectors reading the wrong state - Reducers sharing or overwriting unrelated data - Boilerplate for manually generating unique identifiers - Components therefore become tightly coupled to the shape and location of the application’s Redux store. ## Scoping Redux State - Redux Doghouse introduces scopes that associate actions, reducers, and selectors with a particular component instance. - Each instance receives an isolated section of state, even when multiple copies of the same component are rendered. - Actions are scoped so dispatching an event in one component does not unintentionally update another instance. - Selectors resolve data within the current scope rather than relying on hard-coded global paths. ## Reusable React Components - Components can package their Redux behavior alongside their React UI. - The parent application supplies or creates a scope when mounting the component. - The same component can then be embedded in different parts of an application without duplicating Redux wiring. - This approach keeps implementation details—state shape, action handling, and selectors—inside the reusable component. ## Benefits and Trade-offs - Scoping reduces naming conflicts and makes component behavior easier to reason about. - It supports modular development by separating local component state from application-wide state. - Shared global data can still remain in ordinary Redux state where appropriate. - Developers must manage scope identity and lifecycle carefully, particularly when components are dynamically mounted or removed. Redux Doghouse is best viewed as an architectural pattern for combining Redux’s centralized data flow with component-level isolation. Teams building reusable or multiply-instantiated React components can use scoped state and behavior to avoid collisions without abandoning Redux.

Read original(opens in new tab)
figma2 min readCurated summary

Debugging Data Corruption with Emscripten | Figma Blog

Figma encountered intermittent save-file corruption caused by an elusive C++ memory-safety bug. Conventional debugging tools failed because the web app’s asynchronous behavior made the problem nondeterministic. A keyboard-and-mouse fuzzer eventually produced reproducible failures, while understanding Emscripten’s C++-to-JavaScript memory model helped narrow the investigation. ## Detecting the Corruption - Invalid save files appeared occasionally and could not be reliably reproduced. - Figma’s files used ZIP containers around Google FlatBuffers documents. - The serialized bytes looked mostly valid, but some offsets were unexpectedly zeroed. - Data being written to the wrong location suggested a memory-safety violation such as: - Use before initialization - Use after free - Out-of-bounds access ## Why C++ Made the Bug Difficult - C++ was valuable for Figma because it provided: - Access to libraries such as FreeType, HarfBuzz, and Skia - Low-level control suitable for graphics software - Mature debugging and optimization tools - However, C++ offers no built-in protection against memory errors. - The team tried avoiding deallocation, enabling malloc diagnostics, fixing Valgrind and Clang Analyzer findings, and upgrading the compiler, but none exposed the corruption. ## Reproducing the Failure with Fuzzing - The team planned to eliminate nondeterminism by recording user events and replaying them deterministically. - Building a complete session recorder was too large a project, so they limited inputs to keyboard and mouse events. - A fuzzer generated random event sequences and ran them against the application. - After several days, it produced multiple save failures, providing reproducible cases for debugging. ## Emscripten’s Emulated Memory Model - Figma’s C++ editor ran in the browser through Emscripten, which compiled C++ into JavaScript. - JavaScript typed arrays and shared `ArrayBuffer` storage allowed Emscripten to emulate contiguous C++ memory. - In the generated code: - Pointer loads became typed-array reads. - Pointer stores became typed-array writes. - Registers became local variables. - Shared buffers enabled pointer reinterpretation between types. - Emscripten generated asm.js-style JavaScript, using type annotations and operations optimized for JavaScript JIT compilers. The combination of deterministic fuzzing and knowledge of Emscripten’s low-level memory representation provided the path toward isolating the corruption, even though the ultimate fix was reportedly only a three-line change.

Read original(opens in new tab)
datadog2 min readCurated summary

Cheering on coworkers: Building culture with Datadog dashboards

Christian’s colleagues built a Datadog dashboard to remotely track his progress in a six-day, 850 km ultramarathon. They scraped live race data from the event website, converted it into Datadog metrics, and visualized his distance, ranking, and elapsed time alongside video and other dashboard elements. At publication, Christian was leading by more than 47 km with 44 hours remaining. ## Extracting Race Data - The event website regularly published runners’ statistics and race progress in plain HTML. - A Python crawler using `Requests` retrieved the webpage. - `BeautifulSoup` parsed the HTML to extract: - Current ranking - Total distance run - Elapsed time - Other race information ## Sending Metrics to Datadog - The team used the Datadog Python client and StatsD to emit metrics through the Datadog Agent. - For each runner, the script sent gauge metrics for: - `runner.distance` - `runner.ranking` - `runner.elapsed_time` - Metrics were tagged with each runner’s name, enabling individual tracking and comparisons. ## Building the Dashboard - The collected metrics were combined into a Datadog dashboard. - The dashboard included: - Live race statistics - A live video feed - Animated GIFs for entertainment - Visualizations of meaningful progress metrics - Screens displaying the dashboard were placed in the company’s New York and Paris offices so colleagues could follow and encourage Christian throughout the race. The project demonstrates how a lightweight web scraper, StatsD metrics, and a monitoring dashboard can turn publicly available data into a live, engaging team experience.

Read original(opens in new tab)
datadogOriginal article

Cheering on coworkers: Building culture with Datadog dashboards | Datadog (opens in new tab)

Datadog engineers developed a real-time tracking dashboard to monitor a colleague’s progress during an 850km, six-day ultra-marathon challenge. By scraping public race statistics and piping the data into their monitoring platform, the team created a centralized visualization tool to provide remote support and office-wide engagement. ### Data Extraction and Parsing The team needed to harvest race data that was only available as plain HTML on the event’s official website. * A crawler was built using the Python `Requests` library to automate the retrieval of the webpage's source code. * The team utilized `BeautifulSoup` to parse the HTML and isolate specific data points, such as the runner's current ranking and total distance covered. ### Ingesting Metrics with StatsD Once the data was structured, it was converted into telemetry using the Datadog agent and the `statsd` Python library. * The script utilized `dog.gauge` to emit three primary metrics: `runner.distance`, `runner.ranking`, and `runner.elapsed_time`. * Each metric was assigned a "name" tag corresponding to the runner, allowing the team to filter data and compare participants within the Datadog interface. * The data was updated periodically to ensure the dashboard reflected the most current race standings. ### Dashboard Visualization and Results The final phase involved synthesizing the metrics into a high-visibility dashboard displayed in the company’s New York and Paris offices. * The dashboard combined technical performance graphs with multimedia elements, including live video feeds and GIFs, to create an interactive cheering station. * The system successfully tracked the athlete's 47km lead in real-time, providing the team with immediate updates on his physical progress and elapsed time over the 144-hour event. This project demonstrates how standard observability tools can be repurposed for creative "life-graphing" applications. By combining simple web scraping with metric ingestion, engineers can quickly build custom monitoring solutions for any public data source.

figma3 min readCurated summary

Multiplayer Editing in Figma | Figma Blog

Figma’s multiplayer editing release made real-time collaboration a core part of its design workflow. The company replaced a simple whole-document save-and-upload model after it caused overwrites, stale links, and confusing collaboration problems. Although multiplayer required major changes to conflict resolution, undo/redo, layout behavior, file formats, and performance, Figma concluded that it ultimately simplified the user experience. ## Why the Original Saving Model Failed - Early Figma downloaded documents locally, let users edit in the browser, and periodically uploaded the entire document. - This approach was easy to build and familiar to users of syncing services such as Dropbox. - In team settings, however: - Users could unknowingly overwrite one another’s work. - Shared links could display an outdated version while changes were still saving. - Version history preserved data, but did not prevent collaboration mistakes. - Alternatives such as “baton-passing,” where only one person could edit at a time, lacked the simplicity and flexibility Figma wanted. ## How Figma’s Multiplayer Engine Works - Each user’s changes are sent to the server and broadcast to other participants in real time. - Independent simultaneous changes can coexist. - When users modify the same property on the same object, Figma resolves the conflict by selecting the latest change. - Implementing this model required changing fundamental parts of the editor rather than adding multiplayer as a separate synchronization layer. ## Undo, Redo, and Conflict Resolution - Undo becomes ambiguous when other users modify the same objects afterward. - Figma adopted a guiding principle: undoing actions, copying something, and redoing back to the present should leave the document unchanged. - Redo therefore cannot simply reapply the original edits, since that might overwrite newer work by collaborators. - Conflict resolution also had to account for: - Related properties that must be changed together. - Actions that indirectly affect multiple objects. - Layout operations where apparently unrelated edits can interact. - These requirements led Figma to revise aspects of its layout system. ## Performance and File-Format Changes - Professional-quality multiplayer required extensive measurement and tuning. - Figma overhauled its file format because the previous representation was inefficient for transmitting small incremental messages. - The team expected additional challenges as new collaborative features were introduced. ## A Simpler Collaborative Experience - Multiplayer reduced UX complexity by eliminating workarounds for stale files, overwrites, and coordination. - Users can see collaborators’ mouse cursors and selections, providing immediate context about who is present and where they are working. - Cursors can also serve as lightweight communication tools, such as pointing at an object or getting someone’s attention. - Each participant appears as an avatar in the top-right corner. - Clicking an avatar lets one user present to another, making presentations opt-in rather than forcing a single presenter and synchronized viewing mode. Figma’s experience suggests that real-time collaboration is best treated as a foundational part of the editor. Despite the substantial engineering investment, multiplayer editing can make collaborative software both more powerful and easier to use.

Read original(opens in new tab)
datadog3 min readCurated summary

Restroom hacks

Datadog built an office bathroom-availability monitor to reduce contention without compromising privacy or existing door functionality. Raspberry Pi 2 devices, GPIO-connected sensors, and simple Unix tools provided a low-maintenance way to report whether bathrooms were occupied. The project showed that the hardest parts were adapting to varied real-world hardware, mounting sensors cleanly, and dealing with unreliable Wi-Fi—not writing software. ## Project Goals - Avoid intrusive monitoring: - No cameras or sensors that could feel invasive. - Provide reliable occupancy information with minimal false positives and negatives. - Use door-lock status where possible as the occupancy signal. - Avoid interfering with existing locks and doors. - Keep devices secure, professional-looking, easy to maintain, and remotely updateable. - Treat the project as a fun hardware experiment. ## Adapting to Different Bathrooms - Bathrooms differed significantly in: - Lock styles, including push-button handles and rotary stall locks. - Number of rooms or stalls. - Availability and location of power outlets. - Wi-Fi quality, especially near concrete walls and older electrical equipment. - These variations required different sensor designs rather than one universal installation. ## Raspberry Pi and Sensor Hardware - Raspberry Pi 2 Model Bs served as the project’s controllers because they: - Ran Linux. - Supported Wi-Fi and SSH administration. - Were compact enough to conceal. - The team used several sensor types: - Magnetic reed switches for detecting door position. - Pin switches for detecting sliding stall-lock positions. - Photoresistors were purchased as a possible way to detect darkness but were not needed in the MVP. - For push-button locks, reed switches detected whether the door was open or closed. Although this could theoretically misreport a closed but unoccupied bathroom, it worked reliably in practice. - Stall-lock sensors were hidden inside hollow metal panels. Automotive-style pin switches were mounted using simple carved wooden blocks that contacted the sliding lock without obstructing it. - Wiring was concealed in wiremolding, with Raspberry Pis placed inside outlet boxes where possible. ## GPIO and Unix-Based Monitoring - Raspberry Pi GPIO pins were accessed through files in `/sys/class/gpio/`. - A Python script read sensor values and translated them into bathroom availability. - Configuration handled differences between normally open and normally closed sensors. - The service was exposed through `tcpserver` and managed with `daemontools`. - A basic command-line client could query status with Netcat, for example: ```sh nc 11.bathrooms.datadog-internal.com 50 ``` ## Making Availability Easy to Use - Employees could check status from the command line. - Some added bathroom availability to TextBar. - Datadog dashboards displayed bathroom status throughout the New York office. - The implementation required very little code; most effort went into sensor selection, physical installation, and network troubleshooting. The project demonstrates that inexpensive, hackable hardware combined with simple Linux tools can solve a practical office problem. For similar systems, prioritize non-intrusive sensors, flexible installation designs, and secure remote management; the resulting software can remain remarkably small.

Read original(opens in new tab)