Abstract
Documentation is an important part of the captured knowledge of a software project, providing a flexible and effective way of recording informal contents. However, maintaining documentation's consistency requires a considerable effort. Existing solutions encompass different tools and approaches that support the process of creating, evolving and using documents and other artifacts derived from the software development process. Based on existing literature and expertise, we have identified the key problems and solutions for documentation consistency. In concrete, four distinct patterns and their relations were identified, which are here described - Information Proximity, Co-Evolution, Domain-Structured Information and Integrated Environment. Copyright 2009.

Abstract
The Adaptive Object-Model (AOM) architectural pattern has been significantly documented in literature, but there is not yet enough documentation explaining how to design and build a full AOMbased system. A AOM framework would need to address an additional number of issues that go well beyond individual software patterns. In this paper, we propose a design for a AOM framework that addresses several issues of building AOM-based systems, namely: integrity, runtime co-evolution, persistency, user-interface generation, communication and concurrency. We borrow concepts from distributed version-control systems. We show how applications based on a concrete realization of this framework, called Oghma, helps to avoid a traditional two-level domain classification, reduces accidental complexity, and directly exposes confined model evolution to the end-user.

Abstract

Abstract
The process of developing Dockerfiles is perceived by many developers as slow and based on trial-and-error, and it is hardly immediate to see the result of a change introduced into a Dockerfile. In this work we propose a plugin for Visual Studio Code, which we name Dockerlive, and that has the purpose of shortening the length of feedback loops. Namely, the plugin is capable of providing information to developers on a number of Dockerfile elements, as the developer is writing the Dockerfile. We achieve this through dynamic analysis of the resulting container, which the plugin builds and runs in the background. © 2022 IEEE.

Abstract
The quality of the digital experiences delivered by engineers and their business success depends on empowering developers and operators with an effective method for continuously assessing a system's health, diagnosing possible issues, and recovering from service outages. In other words, monitoring is essential to ensure the quality of an application. However, monitoring best practices may not be apparent to everyone and, most of the time, are not sufficiently explained or documented to be learned quickly and communicated effectively. Therefore, practices usually lack formalisation and a standard structure that would make all of them easy to communicate and share among practitioners. To tackle this issue, this paper describes three proactive monitoring practices as design patterns: Liveness Endpoint, Readiness Endpoint and Synthetic Testing. Design patterns provide enough structure and detail to be easily reused by practitioners and have space to accommodate different needs and quirks depending on the usage context. The proposed patterns are based on existing literature and tools, stemming from industry best practices that are further detailed and adapted to design patterns. Relations to existing monitoring patterns are also analysed to point the reader to more patterns that complement the ones proposed in this work. © 2022 Owner/Author.

Abstract
As the benefits and applicability of microservice architectures become better understood by the software industry, and this architecture becomes increasingly more adopted for building stable, independent and scalable cloud applications, a new set of concerns have alerted developers regarding communication between the different microservices. A service mesh tries to address this issue by creating a clear separation of concerns between application logic and the infrastructure needed for the communication between the different services. This is accomplished by abstracting the cross-cutting concerns related with communication out of the internal services making it possible to be reused by the different services. Existing literature describes a service mesh pattern and a sidecar pattern. This paper leans on these patterns and proposes six patterns found by observing the, what is commonly called, good practices. The six patterns are service mesh, shared communication library, node agent, sidecar, service mesh team and control plane per cluster. © 2022 Owner/Author.