







Advantages and pitfalls of Infrastructure as Code, and the distinction between IaC and Declarative Configuration.
Local Env as Code: Is it possible yet
Guest post by Jan Van Bruggen, Developer Relations Lead at itopia In the past decade, we’ve seen the rise, standardization and meme-ification of “as code”: Infrastructure as Code, Monitoring as Code…


Mitigating Geopolitical Risks with Local-First Software and atproto
Martin Kleppmann discusses the urgent need for technological sovereignty in modern infrastructure. Exploring the shifting landscape of global tech dependencies, he shares how engineering leaders can leverage multi-cloud architecture, de facto API standardization, the AT Protocol, and local-first development paradigms to reclaim user agency and build highly resilient systems.

Infrastructure as Code is Artisanal Automation
“Artisanal” refers to something made in a traditional way by hand by a skilled craftsman, requiring both time and expertise.

Code Is Cheap Now, And That Changes Everything | Pere Villega
AI coding agents have made code production nearly free. Drawing on insights from Kent Beck, Paul Ford, and Simon Willison, this post argues that the value has shifted from writing code to defining systems — contracts, invariants, SLAs, and verification.

The Path to a Sovereign Tech Stack is Via a Commodified Tech Stack | TechPolicy.Press
Strategic standardization of cloud infrastructure backed by procurement power and market forces is the right way to tame the hyperscalers, writes David Eaves.


Random Tech Thoughts
This article is about standardisation, particularly how it relates to understanding code. I’ll first go into an historical example that highlights the lack of standardisation in an area where we take it for granted today. After that I’ll get into code, and how understanding code is like understanding data via visualisations. In both the historic … Continue reading Standardisation and code

Resugaring | Proceedings of the 35th ACM SIGPLAN Conference on Programming Language Design and Implementation
Syntactic sugar plays a crucial role in engineering programming languages. It offers convenient syntax and higher-level of abstractions, as witnessed by its pervasive use in both general-purpose and domain-specific contexts. Unfortunately, the ...

Conway's Law | Laws of Software Engineering
Organizations design systems that mirror their own communication structure.

Protocols and Power
If "context" is king, we need to ensure it remains fluid and accessible by third-party developers

Enshittification, Despotification, and the Open Internet
It’s not about whether technology is inherently good or bad, liberating or oppressive. Architecture shapes incentives; incentives shape outcomes.

Designing and Programming Malleable Software
User needs for software features and interfaces are diverse and changing, motivating the goal of making it as easy as possible for users themselves to change software, or to have it changed on their behalf in response to their developing needs. However, in my opinion, current approaches do not address this issue adequately: software engineering promotes flexible code, but in practice this does not help end-users effect change in their software. End-user and live programming systems help users customize their interfaces by accessing and modifying the underlying source code. I take a different approach, seeking to maximize the kinds of modifications that can take place through regular interactions, e.g. direct manipulation of interface elements. I call this approach malleable software. To understand contemporary needs for and barriers to modifying software, I study how it is produced, maintained, adopted, and appropriated in a network of communities working with biodiversity data. I find that the mode of software production, i.e. the technologies and economic relations that produce software, is biased towards centralized, one-size-fits-all systems. This leads me to propose a long-term, interdisciplinary research program in reforming the tools of software development to create infrastructures for plurality. These tools should help multiple communities collaborate without forcing them to consolidate around identical interfaces or data representations. Malleable software is one such infrastructure, in which interactive systems are dynamic constellations of interfaces, devices, and programs assembled at the site of use. My technological contribution is a reconstruction of the programming mechanisms used to create interactive behavior. I generalize existing control structures for interaction as entanglements, and develop a higher-order control structure, entanglers, which produces entanglements when particular pre-conditions, called co-occurrences, are met. Entanglers cause interactions to be assembled dynamically as system components come and go. I develop these mechanisms in Tangler, a prototype environment for building malleable interactive software. I demonstrate how Tangler supports malleability through a set of benchmark cases illustrating how users can modify systems by themselves or with programmer assistance. This thesis is an early step towards a paradigm for programming and designing malleable software that can keep up with human diversity.
What Istio Got Wrong: Learnings from the Last Seven Years of Service Mesh - C. Posta, L. Ryan
Architectural mismatch: why reuse is so hard
Why isn't there more progress toward building systems from existing parts? One answer is that the assumptions of the parts about their intended environment are implicit and either don't match the actual environment or conflict with those of other parts. The authors explore these problems in the context of their own experience with a compositional approach.<>
Information Civics
An exploration of computer-network architectures as civic structures.
