Abstract
Ensuring privacy while sharing sensitive data is critical, particularly in fields such as healthcare, and everywhere compliance with data protection regulations is required. Anonymization and pseudonymization techniques are essential for preserving individual privacy but it is challenging to select the most appropriate methods given particular privacy and utility requirements. We conducted a focus group during the EuroPLoP 2024 conference that aimed to obtain feedback on patterns that we documented in this space and on a pattern map we outlined, and to identify patterns related to anonymization or pseudonymization of data that have not yet been documented. Some of the patterns we documented were not known by participants. On the other hand, we found some techniques that are potentially privacy-preserving patterns that have not yet been documented, and framed these techniques according to the category in our pattern map. Although the results suggest that our current patterns address some recurring privacy challenges, further exploration and documentation of the techniques are necessary to capture the full range of privacy-preserving solutions.

Abstract
While a wide range of resources is available on orchestration techniques and best practices for containerized software systems, many are not documented clearly or in detail. This complicates the process of selecting the most suitable methods for various usage scenarios. To address this gap, we documented a set of orchestration patterns. This paper reports the results of a focus group conducted during the EuroPLoP 2024 conference, where we aimed to obtain feedback on that group of patterns and on a wider pattern map we outlined. We also aimed to identify container orchestration patterns that have not yet been documented. We found that participants knew most of the patterns we included on the pattern map. Additionally, one of the practices mentioned by the participants (Node Balancing) was previously documented as a pattern by us with the name of Service Balancing. Finally, we found important insights into container orchestration patterns, expanding our pattern map to include eight new proto-patterns.

Abstract
Logging has long been a pillar for monitoring and troubleshooting software systems. From server and infrastructure to application-specific data, logs are an easy and quick way to collect information that may prove useful in diagnosing future issues. When systems become distributed, as is common on the cloud, logs are harder to collect and process. This paper presents three design patterns for logging in cloud-native applications. Standard Logging advises using a standard format for logs across all services and teams so they are easier to process by humans and machines. Audit Logging suggests that important user actions and system changes are recorded in a data store to ensure regulatory compliance or help investigate user-reported issues. Lastly, Log Sampling is about prioritizing logs to maintain a manageable amount of storage. These patterns were mined from existing literature on logging and cloud best practices to make them simpler to communicate, more detailed, and easier for all practitioners to understand.

Abstract
Although service-based architectures offer significant advantages, some aspects of service orchestration remain challenging, particularly for new adopters. Despite the availability of resources on orchestration techniques, many lack clarity or detail. As a result, best practices are often not well explained or standardized, making them difficult to implement and hindering broader adoption within the software industry. To address these concerns, we looked into existing literature and tools to identify common practices. We used our findings to describe as patterns two patterns focused on orchestration configuration, which we present in this paper, and that serve as a stepping stone for other orchestration practices: labeling and resource reserve and limit. These patterns contribute to configuring a system; the former consists of defining key-value pairs to express identifiable properties of system components, and the latter is about supporting two bounds for each resource type: the amount of resources reserved for the service to operate and the maximum amount of resources it can use.

Abstract

Abstract
Incidental visualizations are meant to be perceived at-a-glance, on-the-go, and during short exposure times, but are not seen on demand. Instead, they appear in people's fields of view during an ongoing primary task. They differ from glanceable visualizations because the information is not received on demand, and they differ from ambient visualizations because the information is not continuously embedded in the environment. However, current graphical perception guidelines do not consider situations where information is presented at specific moments during brief exposure times without being the user's primary focus. Therefore, we conducted a crowdsourced user study with 99 participants to understand how accurate people's incidental graphical perception is. Each participant was tested on one of the three conditions: position of dots, length of lines, and angle of lines. We varied the number of elements for each combination and the display time. During the study, participants were asked to perform reproduction tasks, where they had to recreate a previously shown stimulus in each. Our results indicate that incidental graphical perception can be accurate when using position, length, and angles. Furthermore, we argue that incidental visualizations should be designed for low exposure times (between 300 and 1000 ms).