[reClojure2025] Brain Data in Clojure: Navigating the BCI Frontier
Lecturer
Lorelai Lyons is an interdisciplinary developer and researcher focused on the intersection of neuroscience and computer science. Her work centers on making the complex domain of Brain-Computer Interfacing (BCI) accessible to the broader programming community. Lorelai has chronicled her journey from the foundational areas of BCI research to the practical implementation of neural signal parsing and visualization using Clojure. She is the creator of the “BCI Reference Sheet” and is currently developing a Clojure wrapper for the OpenBCI API to facilitate brain-based application development.
Abstract
Brain-Computer Interfacing (BCI) remains one of the most mysterious and inaccessible fields in human-computer interaction. This article analyzes Lorelai Lyons’ journey into processing brain data using Clojure, highlighting the unique advantages of functional programming in neural signal analysis. By examining the methodology for parsing and visualizing real-world brain data, the article demonstrates how Clojure can corroborate authoritative BCI studies through practical, accessible techniques. Furthermore, it addresses the ethical and controversial nature of BCI technology, advocating for a multidisciplinary approach involving programmers, neuroscientists, and medical professionals to ensure responsible innovation in neurotechnology.
The Challenge of Brain-Computer Interfacing
Human-computer interaction has evolved from mechanical computing to AI and cloud-based social networking. However, BCIs represent a daunting leap because they involve direct communication between the human brain and an external device. Lorelai points out that BCI research is often perceived as an “impossible field” for independent developers to enter due to its multidisciplinary complexity.
The primary technical challenge lies in processing “Brain Flow”—the stream of data representing wave signatures from the brain. These neural signals are noisy, high-frequency, and require significant filtering and analysis to become meaningful. Lorelai argues that the goal should not just be recording data, but developing “brain-based applications” that can respond to specific wave signatures in real-time.
Methodology: Parsing Neural Signals with Clojure
Lorelai’s approach involves using Clojure to parse and visualize neural signals, making the domain accessible through functional abstractions. The methodology focuses on “wave signatures,” the distinct patterns in brain activity (such as Alpha, Beta, or Theta waves) that correlate with different mental states.
Clojure is particularly well-suited for this task because:
* Data Transformation: The sequence-oriented nature of Clojure allows for elegant pipelines to filter and transform raw EEG data.
* Concurrency: Processing real-time brain data requires handling multiple streams of information without blocking the UI, a strength of Clojure’s concurrency model.
* Interoperability: By building a wrapper around the OpenBCI API, developers can leverage existing hardware while using a more expressive language for the application logic.
Lorelai notes that while machine learning (ML) can improve the accuracy of BCI systems, high-quality results can be achieved through traditional signal processing and data filtering techniques implemented directly in Clojure.
Ethical Implications and Responsible Innovation
The development of BCIs is not merely a technical problem; it is a “controversial” field with significant ethical concerns. Lorelai emphasizes that the potential for revolutionary medical applications—such as restoring mobility or communication to those with disabilities—must be balanced against the risks of privacy invasion and cognitive manipulation.
She advocates for “responsible innovation,” which requires a shared lexicon and framework for discussion among stakeholders. Because no single person can tackle the complexities of BCIs alone, she highlights the importance of collaboration across multidisciplinary teams, including:
* Programmers: To build the infrastructure and processing pipelines.
* Neuroscientists: To interpret the physiological meaning of the data.
* Ethics and Medical Professionals: To oversee the impact on human health and rights.
Links:
[DevoxxFR2026] Digital Watermarking for Generative AI: Techniques, Applications, and Challenges
Lecturers
Pierre Fernandez and Tom Sander are researchers at Meta specializing in generative AI safety and content provenance. Their work focuses on developing robust, invisible watermarking solutions to address the challenges of AI-generated content detection and traceability at scale.
Abstract
As generative AI systems produce increasingly realistic content across images, video, audio, and text, the need for reliable provenance and detection mechanisms grows urgent. Pierre Fernandez and Tom Sander present Meta Seal, an open-source framework for embedding imperceptible digital watermarks into various media types. The session covers PixelSeal for images and video, AudioSeal for real-time audio streaming, and TextSeal for textual content. Beyond technical details, they explore the transition from research to large-scale production deployment on platforms like Instagram and Facebook, future directions such as dataset watermarking, and current limitations of invisible watermarking approaches.
The Rising Need for Content Provenance in the Age of Generative AI
Generative AI has transformed content creation, enabling rapid production of high-quality images, videos, audio, and text. However, this capability brings significant risks including misinformation, deepfakes, scams, and the pollution of online spaces with low-quality AI-generated material. Distinguishing authentic human-created content from AI-generated outputs has become essential for maintaining trust in digital media.
Traditional passive detection methods, which train classifiers to identify generated content, struggle as models improve and outputs approach photorealism. Digital watermarking offers a proactive alternative by embedding detectable signals directly during or after generation. This approach provides statistical guarantees about content origin while remaining invisible to human observers.
Core Principles and Evaluation Criteria for Watermarking Systems
Effective watermarking systems must balance three critical properties: imperceptibility, payload capacity, and robustness. Imperceptibility ensures modifications do not degrade visual, auditory, or semantic quality. Payload refers to the amount of information (typically binary bits) that can be reliably embedded. Robustness measures the ability to recover the watermark despite transformations such as compression, cropping, or noise addition.
Watermarking can occur at different stages. Post-generation watermarking modifies existing content, while generation-time watermarking integrates the signal during the creation process. Model-level watermarking embeds signals into the model weights themselves, ensuring all outputs carry the trace.
Statistical testing provides confidence in detection. By comparing extracted signals against expected distributions, systems calculate p-values indicating the likelihood that content was generated by a specific model. This controls false positive rates precisely, crucial for platforms processing billions of items daily.
Meta Seal: Open-Source Watermarking Framework
Meta Seal provides production-ready tools for multiple modalities. PixelSeal targets images and video through adversarial training that maintains high perceptual quality. The system modulates watermark signals based on human visual system sensitivities, concentrating changes in textured regions where they remain imperceptible.
AudioSeal addresses real-time streaming constraints. Unlike frame-by-frame image approaches, it predicts watermark presence at each time step, enabling detection of partial audio segments. This proves valuable for scenarios where only short clips are available.
TextSeal extends watermarking to language models. It leverages token probability distributions to embed signals without significantly impacting generation quality. Green-red token partitioning based on private keys creates detectable statistical biases while preserving coherence.
All components are available under permissive licenses, facilitating research and adoption. Production deployment at Meta demonstrates scalability across platforms serving billions of users.
Production Integration and Real-World Applications
Integrating watermarking into production pipelines requires careful consideration of latency, quality impact, and detection reliability. Meta applies these technologies to content generated on Instagram and Facebook, enabling provenance tracking and moderation support.
Watermark signals persist through common transformations including recompression, resizing, and minor edits. Detection runs efficiently at scale, supporting real-time analysis of uploaded content. The framework also aids in identifying training data usage, helping prevent unauthorized model training on proprietary datasets.
Challenges remain. Open-source models risk watermark removal through fine-tuning or distillation. Black-box versus white-box attack scenarios differ significantly in difficulty. Interoperability between providers requires standardized detection mechanisms while protecting proprietary keys.
Future Directions and Research Frontiers
Ongoing research explores dataset watermarking for tracing training data provenance. Model watermarking aims to embed persistent signals in open weights. Multi-modal watermarking seeks unified approaches across content types.
Adversarial robustness continues improving through advanced training techniques. Statistical guarantees strengthen with refined detection methods. Integration with content authenticity initiatives promotes broader ecosystem adoption.
As generative AI proliferates, watermarking represents a critical tool for responsible development. It balances innovation with accountability, enabling creators to maintain control while fostering transparency in the digital ecosystem.
Conclusion
Digital watermarking provides essential provenance for AI-generated content. Through frameworks like Meta Seal, organizations can embed robust, imperceptible signals across modalities. Production deployment demonstrates practical viability at scale. Continued research addressing current limitations will strengthen these protections, supporting trustworthy AI development.
Links:
[VoxxedDaysAmsterdam2026] Taming Microservice Overload: The Journey to Modular Monoliths at the Port of Rotterdam
Lecturer
Mario Klaver is a solution architect at the Port of Rotterdam, responsible for digital systems supporting Harbour Master operations. With a background as a developer, he remains actively involved in programming and puzzle-solving.
Abstract
Mario Klaver recounts the evolution of the Port of Rotterdam’s mission-critical harbor management system from a monolithic application through an explosion of microservices to a more sustainable modular monolith architecture. Using Domain-Driven Design (DDD) techniques such as EventStorming and bounded contexts, combined with Spring Modulith, the team consolidated over 90 microservices into fewer, well-bounded services aligned with business domains. The presentation details the motivations, challenges, implementation approach, migration strategy, and lessons learned, offering practical insights for organizations facing similar architectural fatigue.
From Monolith to Microservices: The Growth of Complexity
In 2010, the Port of Rotterdam initiated a new 24/7 mission-critical system for the Harbour Master division using then-contemporary technologies like Java and Swing (with offline requirements precluding full HTML5 adoption). By 2015, a single backend had become unmaintainable spaghetti code with lengthy manual regression tests.
Following conventional wisdom, the team adopted microservices in 2016, starting with 10 services. By 2018 this grew to 50, and eventually exceeded 90. Every new feature or subject—vessel visits, inspections, dangerous goods, waste handling—spawned additional services, sometimes multiple per domain. Rather than reducing complexity, microservices distributed it, creating tight coupling, high cloud costs (exacerbated by multiple environments and ports), extensive update overhead, and paradoxically slower delivery despite supposed team autonomy.
Anonymized architecture diagrams revealed that services appeared logically separated by responsibility (vessel visits, conflict signaling, clearance) yet events and synchronous calls created a web of dependencies where boundaries were unclear or misplaced. The realization emerged: microservices had not fixed the architecture; they had merely distributed the mess.
Rediscovering Domain Boundaries with EventStorming and DDD
The turning point involved shifting focus from technical partitioning to domain alignment. EventStorming workshops proved instrumental—a collaborative, chaotic yet powerful technique using brown paper, stickies, and domain events to map complex business processes. Participants from business, development, architecture, UX, and operations contributed partial knowledge to build a shared understanding.
Pivotal events, parallel flows, and heuristics helped surface natural subdomains (e.g., Visit, Clearance) and bounded contexts within them. Digitized results clarified responsibilities that differed markedly from existing service implementations. Good boundaries were defined by low coupling (changes mostly contained within a module or service) and high cohesion (modules focused on a clear purpose).
The decision was made to move toward one (larger) service per subdomain, implemented as modular monoliths to prevent internal spaghetti while preserving clear interfaces.
Implementing Modular Monoliths with Spring Modulith
Spring Modulith aligns perfectly with DDD bounded contexts. After adding the dependency, packages directly under the application entry point become modules by convention. Public APIs (Spring beans or events) are exposed in designated packages or via @NamedInterface annotations, while other packages remain private and inaccessible across modules.
IntelliJ provides excellent visual support with green/red indicators for public/private elements. The @ApplicationModule annotation enforces allowed dependencies and prevents cycles. An open/closed mode facilitates gradual migration. Crucially, architecture tests (using @ApplicationModuleTest) verify module boundaries, API usage, and absence of cycles—failing builds if violated.
Inter-module communication prefers Spring’s event publishing and consumption mechanisms. Synchronous listeners use @TransactionalEventListener, while asynchronous ones leverage Modulith’s @ApplicationModuleListener, which persists events for reliability across restarts and decouples transactions. This design eases future extraction of modules into separate services if needed.
Module-specific tests spin up isolated Spring contexts, enabling verification of event flows (e.g., publishing a security clearance event and asserting a downstream vessel movement decision).
Migration Strategy and Architectural Trade-offs
A full green-field rebuild was deemed impractical given a roughly five-year horizon. Instead, the team adopted an incremental “heart surgery while the patient lives” approach: create walking skeletons for new modular services, migrate relevant legacy services as modules, reroute connections, and decommission old instances using feature flags to avoid duplicate processing. Databases initially remain shared before eventual per-module schema separation and a broader Oracle-to-PostgreSQL migration.
Takeaways include faster development and simpler debugging within a single service, reduced infrastructure, but larger deployables requiring broader regression testing, reduced independent scalability, and greater impact during outages.
Lessons Learned and Broader Implications
Key lessons encompass inclusive EventStorming participation to avoid blind spots, ongoing domain exploration and validation with real scenarios, and persistence with clean architectures (e.g., onion/hexagonal) despite mapping overhead—which AI may eventually alleviate. Boundaries matter more than the number of services. A modular monolith often serves as the ideal starting point or interim step before microservices, as correcting boundaries post-split is far costlier.
Mario concludes that microservices distribute complexity, whereas well-designed boundaries control it. The Port of Rotterdam’s journey illustrates a pragmatic path for organizations overwhelmed by service proliferation.
Code Sample: Spring Modulith Module Configuration
@ApplicationModule(
allowedDependencies = {"securityClearance", "vesselVisit"},
type = ApplicationModule.Type.OPEN // during migration
)
public class PortClearanceApplication { ... }
Code Sample: Event Consumption
@TransactionalEventListener
public void onSecurityClearanceCompleted(SecurityClearanceCompletedEvent event) {
// process within transaction
}
@ApplicationModuleListener
public void onAsyncEvent(AnotherEvent event) {
// decoupled, persisted for reliability
}
These patterns enforce architectural integrity while leveraging familiar Spring mechanisms.
In reflecting on the Port of Rotterdam’s experience, Mario Klaver delivers a compelling case study in architectural modernization. By realigning services with domain realities through DDD and enforcing modularity with Spring Modulith, the organization has regained clarity, ownership, and sustainable evolution capacity without sacrificing the benefits of service-oriented thinking.
Links:
[VoxxedDaysBucharest2026] Breaching LLM-Powered Applications: Brian Vermeer on Security and Privacy Challenges in AI Systems
Lecturer
Brian Vermeer is a Staff Developer Advocate at Snyk, where he focuses on developer security, DevSecOps practices, and emerging risks in modern application architectures. A recognized Java Champion and active community leader who co-leads the Netherlands Java User Group (NLJUG), Brian brings extensive experience in application security, secure coding, and helping organizations build more resilient systems. He frequently speaks at international conferences on topics ranging from traditional web vulnerabilities to the novel attack surfaces introduced by artificial intelligence and large language models.
Abstract
As organizations rapidly integrate Large Language Models into production applications, new categories of security and privacy vulnerabilities emerge alongside familiar web application risks. Brian Vermeer provides a compelling, demonstration-heavy exploration of these challenges through a fictional car rental application called “Really Good Rentals.” He demonstrates practical attack vectors such as prompt injection, RAG poisoning, memory manipulation, and tool abuse, while outlining layered mitigation strategies including input/output guardrails, scoped permissions, human-in-the-loop verification, and architectural defenses essential for building trustworthy LLM-powered systems.
The Allure and Inherent Risks of LLMs in Production Applications
Brian begins by drawing a relatable analogy: just as children enthusiastically misuse new toys in unexpected ways, developers often rush to incorporate powerful new technologies like LLMs without fully appreciating the expanded attack surface they create. While LLMs offer remarkable capabilities for natural language processing, code generation, and intelligent automation, they introduce significant risks when granted access to tools, user data, or execution privileges.
He presents a simplified architecture of a typical LLM-powered application, highlighting key components: user prompts, system instructions, conversation memory, retrieval-augmented generation (RAG) pipelines, and tool-calling mechanisms. Because LLMs are fundamentally stateless, the surrounding application bears responsibility for maintaining context, which creates multiple points where malicious actors can influence behavior through carefully crafted inputs.
Context Poisoning Through RAG and Memory Manipulation
A central demonstration revolves around the “Really Good Rentals” application. Brian shows how a seemingly innocuous file upload feature with inadequate path validation allows attackers to perform directory traversal and overwrite critical documents stored in the vector database, such as terms-of-service files. By injecting a modified cancellation policy containing trigger phrases like “vroom vroom,” the attacker can later invoke this policy through normal chat interactions, tricking the LLM into granting unauthorized credits or violating business rules.
This technique, termed RAG poisoning, illustrates how tainted retrieval sources can persistently influence model behavior across conversations. Similar vulnerabilities arise through traditional injection attacks in search functionality, where SQL injection not only extracts data but also poisons the conversation memory fed to the LLM on subsequent interactions. Brian emphasizes that classic web vulnerabilities gain dramatically amplified impact when they shape the context provided to powerful generative models.
Abusing Permissions, Tool Calling, and Advanced Prompt Injection
Brian demonstrates how overly broad tool permissions create dangerous scenarios. In older models like GPT-3.5, carefully crafted prompts could coerce the LLM into executing arbitrary SQL statements with destructive consequences. Even with more recent, safety-aligned models, insufficient scoping of available tools allows privilege escalation and unauthorized actions.
Advanced prompt injection techniques go beyond simple overrides. Multi-turn attacks gradually extract personally identifiable information by leveraging accumulated conversation memory. When combined with tool calling capabilities, especially with locally hosted models, attackers can trigger hallucinations that inadvertently expose sensitive data during operations such as account creation or data processing.
The presentation underscores that granting LLMs access to powerful tools without rigorous permission boundaries and validation is equivalent to giving untrusted code broad system access.
Mitigation Strategies and Architectural Defenses
Brian outlines a comprehensive defense-in-depth approach spanning multiple layers:
-
Input and Output Guardrails: Deploying dedicated LLM-as-a-Judge mechanisms that evaluate both incoming prompts and generated outputs for malicious content, policy violations, or harmful instructions. These guardrails act as critical safety nets.
-
Limited-Scope and Permission-Aware Tools: Designing tools with granular permissions, explicit user confirmation flows for sensitive operations, and runtime validation of actions against the authenticated user’s privileges.
-
Structured Outputs and Schema Enforcement: Using techniques that force models to produce responses conforming to predefined schemas, significantly reducing the potential for unexpected or harmful outputs.
-
Model Selection and Routing: Strategically routing sensitive operations to private, self-hosted models while reserving more powerful commercial models for less critical tasks.
-
Traditional Security Foundations: Maintaining rigorous input sanitization, dependency updates, secure file handling, and regular security scanning. Brian stresses that foundational web application security remains non-negotiable even in AI-enhanced systems.
Additional considerations include implementing rate limiting to prevent “denial of pocket money” attacks that exhaust token quotas through malicious prompting, as well as comprehensive auditing of all tool invocations and model interactions.
Broader Implications for Secure AI Development
The talk concludes with forward-looking guidance for organizations adopting LLM technologies. Brian encourages treating LLMs as powerful but inherently unpredictable components requiring the same rigorous engineering discipline applied to any critical system. Key principles include careful context management, strict permission boundaries, deterministic fallback mechanisms where possible, and continuous security education for development teams.
By sharing concrete attack demonstrations and corresponding defenses, Brian equips attendees with actionable insights to build more secure, privacy-preserving AI applications while continuing to harness their transformative potential.
Links:
[AWSReInvent2025] Building at Global Scale: The Engineering Principles of AWS Expansion
Lecturer
AWS Infrastructure Engineering Leadership comprises a cohort of senior principal engineers and software architects dedicated to the physical and logical expansion of the world’s most comprehensive cloud platform. This team is responsible for the transition from manual infrastructure provisioning to fully automated, software-driven regional deployments. Their expertise lies in distributed systems at planetary scale, resilient architectural patterns, and the “static stability” model used to ensure service availability during environmental shifts. While individual names are often synonymous with specific service launches, the collective leadership represents decades of experience in high-availability computing and global logistics automation.
Abstract
The rapid expansion of global cloud infrastructure requires a sophisticated departure from traditional data center management. This article analyzes the evolution of Amazon Web Services (AWS) regional expansion, moving from manual, human-centric processes to an automated, software-engineered methodology. We explore the architectural design patterns that facilitate this growth, focusing specifically on the concept of “static stability” and the implementation of cell-based architectures. The discussion examines the operational culture required to manage projects spanning multiple years and geographies, emphasizing the “escalation culture” that aligns technical challenges with leadership oversight. By investigating the engineering frameworks and testing protocols utilized during region builds, this paper highlights how AWS maintains high security and reliability standards while accelerating the pace of global distribution.
The Evolution of Regional Proliferation: From Manual to Automated
In the nascent stages of cloud computing, the deployment of a new geographic region was a bespoke, labor-intensive endeavor. It involved manual configuration of networking equipment, custom scripts for server provisioning, and human-led verification of security protocols. However, as the demand for localized data residency and lower latency increased, this “artisanal” approach became a bottleneck. The methodology shifted toward “Infrastructure as Code” (IaC) at an unprecedented scale, where an entire region—consisting of multiple Availability Zones (AZs), transit gateways, and thousands of services—is treated as a single, deployable software artifact.
This transition necessitated a fundamental change in testing frameworks. Engineering teams now utilize “digital twins” of regional environments to simulate the deployment process before physical hardware is even unboxed. These simulations verify that the logical dependencies between foundational services—such as Amazon EC2, Amazon S3, and Amazon DynamoDB—are met in the correct sequence. The goal is to create a “blueprint” that can be stamped out across the globe, ensuring that a region in Zurich behaves identically to one in Melbourne, despite differences in local hardware generations or physical constraints.
Static Stability and the Physics of Resilience
A cornerstone of AWS’s global scaling strategy is the principle of “static stability.” In highly distributed systems, the most dangerous moments occur during transitions—scaling up, scaling down, or failing over. A statically stable system is designed to handle failure without needing to change its state or configuration in real-time. For instance, if a network link between two Availability Zones fails, the system should already have the capacity and routing logic in place to ignore the failure, rather than triggering a complex re-convergence protocol that might introduce new bugs.
This architectural pattern is deeply rooted in the “Amazon Builder’s Library” philosophies. By over-provisioning certain critical paths and using “cell-based architectures,” engineers can isolate failures within a small subset of the infrastructure. A “cell” is a complete, independent instance of a service. If a cell fails, it does not impact the rest of the region. Scaling, therefore, becomes a matter of adding more cells rather than making a single cell larger. This modularity is essential for global expansion, as it allows AWS to increase capacity incrementally without increasing the “blast radius” of potential incidents.
// Conceptual illustration of a Cell-Based Deployment Configuration
region_config:
name: "eu-central-2"
architecture: "cell-based"
cells:
- cell_id: "cell-01"
az_distribution: ["az-a", "az-b", "az-c"]
capacity_multiplier: 1.0
- cell_id: "cell-02"
az_distribution: ["az-a", "az-b", "az-c"]
capacity_multiplier: 1.0
static_stability:
overprovision_ratio: 0.2
heartbeat_interval_ms: 500
The Human Element: Escalation Culture and Strategic Alignment
While software automates the deployment, the complexity of global builds requires a robust human operational framework. AWS employs a “healthy escalation culture” as a primary tool for risk management. In many organizations, escalation is viewed as a failure of the local team. At AWS, it is treated as a mechanism for rapid alignment. When an engineer identifies a systemic friction point—such as a recurring delay in hardware delivery or a software bug that prevents regional parity—the culture dictates that leadership must be informed immediately.
This culture ensures that the “builders” (engineers) and the “leaders” (executives) are synchronized on the path forward. Given that regional builds can span years, maintaining this alignment is critical to meeting customer commitments. The escalation process is not about assigning blame; it is about resource allocation and priority shifting. This transparency allows for the prioritization of fixes that have the highest impact on global reliability, ensuring that lessons learned during a build in the United States are immediately applied to a build in Asia.
Future Horizons: Maintaining Reliability at Hyperscale
As AWS continues to expand into ever more diverse geographic and regulatory environments, the engineering challenges evolve. The focus is shifting toward “zero-touch” operations, where the system can self-heal and self-optimize based on real-time telemetry from the global fleet. The integration of advanced AI models into the infrastructure management layer promises to further reduce the time required to bring new regions online while enhancing the predictive maintenance of physical hardware.
Ultimately, the engineering of AWS expansion is a testament to the power of standardized design patterns and rigorous operational discipline. By treating infrastructure as a living software system and prioritizing static stability, AWS has created a framework that allows for massive scale without a corresponding increase in complexity or risk. This methodology provides a blueprint for any organization seeking to build resilient, globally distributed systems that can withstand the unpredictable nature of the physical world.
Links:
[PyConUS2026] Fall in Love with CSS: Reclaiming a Declarative Language for Modern Web Development
Lecturer
Piper Thunstrom is a long-standing participant in the Python community, a frequent conference speaker, an open-source maintainer, and a practicing web developer. She serves as one of the primary maintainers of PursuedPyBear (commonly abbreviated PPB), an education-oriented game engine implemented entirely in Python, and is co-founder of Tea House Hosting, a service designed to restore simplicity to static site hosting. Her professional trajectory includes freelance web development beginning in 2014 and later roles as a staff engineer. She regularly addresses topics that span community building, game development with Python, and practical aspects of contemporary web technologies.
Public resources associated with her work include the personal site https://piper.thunstrom.dev, a Bluesky presence, the GitHub account pathunstrom, the Tea House Hosting platform at https://teahouse.cafe, and the educational project Steal This Website at https://stealthiswebsite.art. The latter offers pre-constructed layouts under open terms so that learners may examine and adapt real examples.
Abstract
This article provides a detailed examination of Piper Thunstrom’s presentation on the conceptual foundations and recent evolution of Cascading Style Sheets. It positions CSS as a declarative language whose behavior is governed by transparent, learnable rules rather than opaque magic. The discussion covers the document model, the anatomy of rule sets, the full cascade including origin and specificity, media queries, custom properties, native nesting, modern color systems, and the two principal layout models—Flexbox and Grid. Cultural attitudes that have historically discouraged deep engagement with CSS receive critical attention, and practical patterns for responsive design without heavy frameworks are illustrated.
Understanding CSS as a Declarative System and the Mechanics of the Cascade
For many software engineers, Cascading Style Sheets occupy a peripheral status. The language is frequently treated as an unavoidable ancillary technology, the subject of jokes, and the target of successive generations of frameworks and preprocessors whose primary selling point is the reduction of direct contact with CSS itself. Thunstrom begins by rejecting that framing. She invites the audience to regard CSS as a declarative language comparable to SQL: the author states the desired visual outcome, and the browser’s rendering engine determines an efficient way to realize it. The translation rules that convert declarations into pixels are systematic and therefore capable of being mastered.
CSS operates on documents. A typical HTML document contains a hierarchy of elements. Those elements fall into two principal categories. Block-level elements generate boxes that participate in the block axis (top-to-bottom in languages that use horizontal writing systems) and ordinarily expand to fill the available inline size. Inline-level elements generate boxes that flow along the inline axis (left-to-right in English) and wrap when necessary. The most generic block element is the div; the most generic inline element is the span. Contemporary practice favors semantic elements over generic containers, yet a thorough treatment of semantic markup lies outside the scope of a single presentation.
The atomic unit of author-written CSS is the rule set. A rule set consists of a selector followed by a declaration block delimited by curly braces. Inside the block appear one or more property declarations, each formed by a property name, a colon, a value or list of values, and a terminating semicolon. Values may be simple keywords or lengths, comma-separated lists of related tokens (as in font-family), or complex shorthand values that compress several related longhand properties into a single statement. Should any individual declaration prove invalid—whether because of an unrecognized property name, an incorrect value type, or a missing semicolon that merges two properties—the browser discards only the faulty declaration and continues to apply every remaining valid declaration in the same block.
Selectors determine which elements receive the declarations. Basic selectors include type selectors that match element names, class selectors introduced by a period, and ID selectors introduced by a hash. Compound selectors combine several basic selectors without intervening combinators, thereby requiring an element to satisfy multiple conditions simultaneously. Complex selectors join simple or compound selectors with combinators; the most common combinator is the space character, which denotes the descendant relationship. Other combinators express direct-child, adjacent-sibling, and general-sibling relationships. Attribute selectors enclosed in square brackets match the presence or specific values of HTML attributes. Pseudo-classes, written with a single colon, select elements according to state or structural position. Pseudo-elements, written with a double colon, generate or target fragments that do not exist as independent elements in the document tree, such as ::before and ::after. Finally, a comma-separated list of selectors functions as a logical disjunction: the declarations apply if any of the listed selectors match. An important caveat is that an invalid selector anywhere in the list renders the entire rule set inert.
The cascade is the algorithm that resolves conflicts when multiple rule sets claim the same element. The first filter is relevance: only rule sets whose selectors actually match the element under consideration are retained. Surviving rule sets are then ordered by origin. Author styles (those written by the site developer) outrank user styles (historically supplied by the visitor for accessibility customization) which in turn outrank the user-agent styles that constitute the browser’s default presentation. Within the author origin, cascade layers may further subdivide priority, although a full treatment of layers exceeds the time available in the talk. Specificity supplies the next ordering criterion. Specificity is conventionally represented as a three-component tuple. The first component counts ID selectors, the second counts class selectors, attribute selectors, and pseudo-classes, and the third counts type selectors and pseudo-elements. Comparison proceeds component-wise from left to right; a higher value in an earlier component decides the contest regardless of later components. Combinators themselves do not increment any specificity component, yet every simple selector they connect does contribute. The !important flag inverts the normal origin order and should be employed only as a last resort; the preferred alternatives are carefully layered cascade layers and consistently low-specificity author styles that remain easy to override with modest increases in specificity.
Media queries, an older yet still essential feature, allow entire groups of rule sets to be activated or deactivated according to characteristics of the output medium or the user’s preferences. Queries may test media type (screen or print) and features such as minimum or maximum viewport width, preferred color scheme, and reduced-motion settings. The :root pseudo-class selects the document’s root element—almost always the html element—with a specificity of (0,1,0), slightly higher than a bare type selector. It therefore serves as a convenient and slightly sticky location for the declaration of default custom properties.
Modern Capabilities: Variables, Nesting, Color, and Layout
Custom properties, officially known as CSS variables, are any property whose name begins with two hyphens. Their values may be any syntactically valid CSS value, they inherit by default, and they are retrieved by means of the var() function. Because inheritance walks the document tree, a custom property declared on an ancestor is visible to all descendants unless overridden closer to the element. Placing a set of default custom properties on :root therefore establishes a global theme that any subtree may refine. The var() function may itself appear inside other functions such as calc(), permitting arithmetic composition of custom values.
Native nesting, long a feature of preprocessors, is now part of the CSS standard. An outer rule set is termed the parent; any rule sets written inside its declaration block are children. The selectors of child rules are automatically combined with the parent selector, most often by inserting a descendant combinator. The nesting selector & makes the combination explicit and permits the construction of compound selectors or the repositioning of the parent selector to the end of a complex selector. The resulting syntax remains compact while preserving the cascade’s ordinary specificity rules.
Color management has advanced markedly. The color-scheme property informs the browser which color schemes the page supports; the order of the keywords conveys author preference. When only the scheme is declared and no explicit colors are supplied, the browser may automatically adapt its own user-agent styles. The light-dark() function accepts two values and resolves to one or the other according to the active scheme, eliminating the need for a separate media query in many common cases. By storing both the light and dark values inside custom properties declared on :root and then applying those properties via the universal selector, an author can establish a coherent theme for the entire document. Re-declaring the same custom properties on a subtree instantly re-themes that portion of the page. Newer color spaces such as OKLCH and OKLab are designed so that equal numerical distances correspond more closely to equal perceptual differences. Relative color syntax further allows extraction of individual channels from an existing color and the construction of derived colors through arithmetic or replacement of those channels.
Layout is the domain in which modern CSS most dramatically reduces historical complexity. Flexbox supplies a one-dimensional model. Setting display: flex on a container causes its children to become flex items. The flex-direction property chooses the main axis (row or column, optionally reversed). justify-content distributes free space along the main axis; useful values include space-between and space-around. align-items controls alignment on the cross axis and is the reliable answer to the perennial question of vertical centering. When multiple lines of flex items appear, align-content governs the distribution of those lines. The flex-wrap property determines whether items may wrap; omitting an explicit wrap value is a frequent source of unexpected single-line compression.
Grid supplies the complementary two-dimensional model. After display: grid, the author defines the track structure with grid-template-rows and grid-template-columns. The optional grid-template-areas property assigns names to rectangular regions of the grid; those names must form contiguous, non-overlapping rectangles. Children are then placed by setting grid-area to the corresponding name. Because the visual structure is expressed declaratively in the template, responsive redesign often reduces to the redefinition of only the track sizes and the area map at successive breakpoints. A mobile-first approach leaves elements in ordinary document flow; a medium breakpoint activates Grid with a modest number of columns; a larger breakpoint merely adjusts the column tracks and rewrites the area template. The resulting style sheet remains short, readable, and free of the deep nesting of presentational wrappers that many component frameworks impose.
Thunstrom’s own preferred pattern for responsive Grid layouts illustrates the economy of the approach. The same three content regions—header, main, and footer—can be arranged as a single column on small screens, a two-column intermediate layout, and a three-column wide layout solely by changing the template definitions. No additional markup is required, and the cascade continues to operate in its ordinary fashion.
Cultural attitudes receive explicit treatment. The phrase “contempt culture,” introduced in a blog post approximately a decade earlier, describes the social practice of dismissing technologies or communities that fall outside a currently prestigious narrative. Within the Python community one occasionally hears the claim that Python is “just a learning language”; analogous dismissals have long been directed at CSS. Thunstrom regards such contempt as corrosive. CSS is a capable language whose feature set has expanded substantially over the past fifteen years. Mastery of its rules restores direct expressive power to developers who had previously felt obliged to route every visual decision through the abstractions of a framework.
Two short code examples demonstrate the practical outcome of the techniques discussed. The first shows a progressive Grid layout; each line is kept under the required character limit:
.container {
display: grid;
grid-template-columns: 1fr;
grid-template-areas:
"header"
"main"
"footer";
}
@media (min-width: 45em) {
.container {
grid-template-columns:
1fr 3fr 1fr;
grid-template-areas:
"header header header"
"nav main aside"
"footer footer footer";
}
}
.header { grid-area: header; }
.main { grid-area: main; }
.nav { grid-area: nav; }
.aside { grid-area: aside; }
.footer { grid-area: footer; }
The second fragment illustrates a reliable centering utility that exploits Flexbox:
.center {
display: flex;
justify-content: center;
align-items: center;
}
Taken together, custom properties for theming, nesting for organization, and the two layout systems for structure constitute a lightweight, standards-based toolkit. Developers who internalize these tools regain the ability to express visual intent directly, to maintain that expression over time, and to adapt it to changing viewport sizes without the overhead of large framework abstractions.
Links:
[VoxxedDaysLuxemburg2026] AI-Augmented IDEs: Coding and Reviewing with Intelligent Agents
Lecturer
Lucian Precup is an experienced software architect, technologist, and entrepreneur. He is the founder and CTO of Adelean, a French consulting and software engineering firm specializing in search engine technologies, large-scale data engineering, and enterprise search implementations since 2010. Lucian is a regular speaker at European developer conferences, sharing insights on Elasticsearch, Apache Solr, search relevance, and the evolving role of AI agents in software development.
Abstract
As the closing session at Voxxed Days Luxembourg 2026, this presentation explores how Artificial Intelligence is transforming software development workflows, developer tooling, and engineering organization models. Drawing from real-world experiences at Adeline—a company specializing in search engines since 2010—the talk examines the evolution of developer productivity, moving from historical command-line editors to modern AI-assisted IDEs.
The presentation analyzes how AI models interact with standardized recruitment tests, online technical documentation, local CLI tools, and automated code generation. Key discussions center on Specification-Driven Development (SDD), Test-Driven Development (TDD), technical debt management, economic implications for SaaS platforms, and the evolving roles of junior software engineers and non-technical team members.
Evolution of Developer Workflows Across Eras
Software development paradigms have shifted significantly over recent decades, driven by changes in tooling, feedback loops, and infrastructure costs.
+---------------------------------------------+
| Era 1: Pre-Dot-Com Era |
| |
| Tools: |
| - VI, Emacs, MAN pages |
| - Reference documentation |
| |
| Debugging: |
| - Print statements |
| (System.out.println) |
| |
| Cycle: |
| - High compile times (1–5+ mins) |
| - High pre-planning required |
+---------------------------------------------+
|
v
+---------------------------------------------+
| Era 2: Modern IDE & Cloud Native |
| |
| Tools: |
| - Feature-rich IDEs |
| - Autocompletion |
| - Stack Overflow |
| |
| Debugging: |
| - Integrated debuggers |
| - Near-instant compilation |
| |
| Focus: |
| - Rapid time-to-market |
| - Production monitoring |
| - Continuous delivery |
+---------------------------------------------+
|
v
+---------------------------------------------+
| Era 3: AI-Augmented IDEs & Agents |
| |
| Tools: |
| - LLM-backed prompts |
| - Integrated CLI terminals |
| - Agent/Skill specs (`AGENTS.md`) |
| |
| Debugging: |
| - Automated LLM analysis |
| - Anomaly & bug detection |
| |
| Focus: |
| - Natural language prompts |
| - SDD / TDD frameworks |
| - Rapid application generation |
+---------------------------------------------+
| Operational Dimension | Pre-Dot-Com Era | Modern IDE Era | AI-Augmented Era |
|---|---|---|---|
| Primary Interfaces | Text Editors (VI/Emacs), CLI, MAN pages. | Feature-rich IDEs, Web Search, Stack Overflow. | Prompt Interfaces, Integrated CLI, LLM Agents. |
| Feedback Loop | 1 to 5+ minute compilation cycles. | Real-time background compilation. | Rapid multi-file generation (e.g., full apps in ~2 mins). |
| Debugging Method | Manual print statements (System.out.println). |
Integrated IDE Debuggers, Production APM. | Direct LLM algorithmic analysis & anomaly detection. |
| Primary Constraint | High cost of compilation/planning errors. | Time-to-Market pressure. | Specification clarity & generated code maintainability. |
AI Performance in Technical Recruitment Benchmarks
Adeline has utilized a standardized recruitment assessment process since 2016 to evaluate candidates on code comprehension, cross-language syntax parsing such as XSLT, algorithmic reasoning, typing proficiency, and implementation.
+---------------------------------------------+
| Historical Recruitment Funnel vs. AI |
| |
| Candidate Funnel: |
| |
| [ Stage 1: Basic HTTP & Tech Questions ] |
| --> 10% Candidate Drop-off |
| |
| [ Stage 2: XSLT / Algorithm Analysis ] |
| --> 50% Candidate Drop-off |
| |
| [ Stage 3: Program Implementation ] |
| --> 30% Candidate Drop-off |
| |
| Final Results: |
| - Human Pass Rate: ~10% |
| - LLM Result: 100% Completion |
| - LLM Edge Case Detection: |
| Identifies recursion limits and |
| infinite loops on empty strings |
+---------------------------------------------+
Key Assessment Observations
The recruitment assessment deliberately employs obscure or legacy syntaxes, such as XSLT, to evaluate a candidate’s ability to read unfamiliar code, extract underlying semantics, and determine operational logic like recursive string replacement. Modern LLMs easily solve complex algorithmic questions, accurately describe time and space complexity, and autonomously detect subtle edge cases, such as potential infinite loops triggered by empty string inputs.
Clear and unambiguous specifications are essential for precise LLM execution, as AI models regularly produce optimal implementations when requirements are properly structured. Historical recruitment data shows a strong correlation between developer proficiency and typing speed, typically above 45 words per minute. While voice-to-text plugins like Whisper Flow can increase input speed, maintaining keyboard fluency remains vital for effective software engineering workflows.
The Paradigm Shift in Technical Documentation
Technical documentation formats are shifting rapidly to accommodate direct consumption by AI agents rather than human developers.
+---------------------------------------------+
| Evolution of Technical Documentation |
| |
| Traditional Human Documentation: |
| - Man pages |
| - JavaDoc APIs |
| - Web Forums |
| - Fragmented Wiki / Slack Archives |
| |
| AI-First Documentation Architecture: |
| - Structured Vector Embeddings |
| - Context-Aware In-Product Assistants |
| - Model Context Protocol (MCP) Servers |
| - Machine Configs (`AGENTS.md`, `SKILLS.md`)|
+---------------------------------------------+
Third-party vendor platforms and legacy software projects often feature fragmented documentation split across multiple platforms, including Apache Solr versions, Slack channels, dynamic wikis, and static PDFs. Commercial products like ElasticSearch integrations increasingly route technical documentation through dedicated AI endpoints or Model Context Protocol (MCP) servers, which allow LLMs to query, synthesize, and resolve technical issues directly.
Within agent framework configuration files, AGENTS.md serves as an AI-oriented README that provides high-level operational context, coding standards, and project constraints for autonomous coding agents. Similarly, SKILLS.md operates like an Ansible playbook by defining executable, task-specific instructions such as web documentation lookups and index querying workflows for AI assistants.
Practical Engineering Patterns: CLI, Prototyping, and Review
1. High-Efficiency CLI Script Generation
AI excels at generating complex, single-line terminal commands and devops utilities that would otherwise require deep manual documentation checks.
# Complex Network Latency Profiling with cURL + Awk
curl -s -w "%{time_connect} %{time_starttransfer} %{time_total}\n" \
-o /dev/null https://target-api.internal/health \
| awk '{sum1+=$1; sum2+=$2; sum3+=$3} \
END {print "Avg Connect:", sum1/NR, \
"| Avg Transfer:", sum2/NR, \
"| Avg Total:", sum3/NR}'
# Rapid Test Data Generation for Elasticsearch/Search Systems
python3 -c "
import random, json
for i in range(1000):
val = random.gauss(mu=50.0, sigma=15.0)
print(json.dumps({'id': i, 'metric': max(0.0, min(100.0, val))}))
" | curl -H "Content-Type: application/x-ndjson" \
-XPOST "localhost:9200/test_index/_bulk" \
--data-binary @-
2. Specification-Driven & Test-Driven Development (SDD / TDD)
When using AI agents for data generation or throwaway utility scripts, code internal structures may vary or appear messy. Enforcing rigorous verification mechanisms ensures reliability.
+---------------------------------------------+
| Iterative SDD/TDD Loop for AI Agents |
| |
| 1. High-Precision Specification |
| - Detailed Prompts & Constraints |
| |
| 2. Automated Test Suite (TDD) |
| - Define Assertions & Verification |
| |
| 3. Code Generation Loop |
| - LLM Emits Draft Implementation |
| |
| 4. Verification Check |
| - Automated Run of Acceptance Test |
| |
| 5. Merge vs. Discard Decision |
| - Keep logic if verified |
| - Discard if unmaintainable |
+---------------------------------------------+
Non-production scripts such as mock data generators and environment setup tools can be generated on-demand by AI and safely discarded after execution, provided acceptance tests pass. However, large auto-generated Pull Requests that introduce complex or unmaintainable logic should be rejected or revised. Teams should use AI primarily for rapid feature validation, followed by strict refactoring against architectural standards before merging into primary production branches.
3. Impact on Software Business Models & SaaS Verticals
+---------------------------------------------+
| Micro-SaaS Disruption Dynamics |
| |
| Standard SaaS Solution: |
| - Dedicated Subscription Model |
| - Hosted Third-Party Web Infrastructure |
| - Monthly Per-User Pricing |
| |
| v |
| |
| AI Rapid Generation Alternative: |
| - Single Prompt to Full-Stack App |
| - Client UI + Backend (PostgreSQL) |
| - Self-Hosted in ~2 Minutes |
+---------------------------------------------+
Low-complexity software services such as Sprint Review boards, scheduling apps, or basic metric dashboards can now be built autonomously in minutes using platforms like Lovable. Product managers and non-engineering personnel can bypass static wireframes to generate functional client-server prototypes directly from natural language specifications. Consequently, the primary value of software teams shifts from writing repetitive boilerplate to architectural design, system integration, continuous integration guardrails, domain modeling, and maintenance.
Resource Economics and Developer Growth
Economics of AI Model Usage
Early-stage AI tools and promotional compute tiers often subsidize API consumption costs for developers. While high-volume enterprise deployments across large engineering organizations incur significant API costs, experimental usage remains accessible for individual developers.
Developer Progression & Analogy of the Master Chef
+---------------------------------------------+
| The "Master Chef" Developer Paradigm |
| |
| Junior Stage: Fundamentals |
| +-----------------------------------------+ |
| | - Core Syntax Knowledge | |
| | - Manual Code Parsing | |
| | - Low-level Debugging | |
| | - Basic Scripting Utilities | |
| | - (Peeling Potatoes) | |
| +-----------------------------------------+ |
| | |
| v |
| Executive Stage: Orchestration |
| +-----------------------------------------+ |
| | - Prompt Engineering | |
| | - System Design & Architecture | |
| | - Output Verification & Quality Checks | |
| | - LLM Agent Orchestration | |
| +-----------------------------------------+ |
+---------------------------------------------+
Relying strictly on AI generation without understanding underlying systems risks creating developers who cannot operate independently when AI tooling is offline. Senior engineers orchestrate AI agents effectively because they previously built systems manually. Therefore, developing strong foundational skills like manual debugging, syntax comprehension, and system architecture remains critical for junior engineers, even as AI automates routine tasks.
Links
- Voxxed Days Luxembourg Talk Schedule : Official session page for the lecture IDEs augmentés par l’IA : Coder et relire avec des agents intelligents.
- Lucian Precup’s Speaker Profile : Developer session biography and speaker details.
- Adelean Authors – Lucian Precup : Technical articles, search architecture insights, and background on the speaker.
- Adelean Official Site : Main website for Adelean, specializing in enterprise search engines and AI data integration.
- Voxxed Days Luxembourg Video Presentation : YouTube video recording of the presentation session.
- Building Next-gen Search With OpenSearch : Additional technical talk by Lucian Precup covering LLMs, intelligent agents, and search architectures.
[MunchenJUG] Reliability in Enterprise Software: A Critical Analysis of Automated Testing in Spring Boot Ecosystems (27/Oct/2025)
Lecturer
Philip Riecks is an independent software consultant and educator specializing in Java, Spring Boot, and cloud-native architectures. With over seven years of professional experience in the software industry, Philip has established himself as a prominent voice in the Java ecosystem through his platform, Testing Java Applications Made Simple. He is a co-author of the influential technical book Stratospheric: From Zero to Production with Spring Boot and AWS, which bridges the gap between local development and production-ready cloud deployments. In addition to his consulting work, he produces extensive educational content via his blog and YouTube channel, focusing on demystifying complex testing patterns for enterprise developers.
Abstract
In the contemporary landscape of rapid software delivery, automated testing serves as the primary safeguard for application reliability and maintainability. This article explores the methodologies for demystifying testing within the Spring Boot framework, moving beyond superficial unit tests toward a comprehensive strategy that encompasses integration and slice testing. By analyzing the “Developer’s Dilemma”—the friction between speed of delivery and the confidence provided by a robust test suite—this analysis identifies key innovations such as the “Testing Pyramid” and specialized Spring Boot test slices. The discussion further examines the technical implications of external dependency management through tools like Testcontainers and WireMock, advocating for a holistic approach that treats test code with the same rigor as production logic.
The Paradigm Shift in Testing Methodology
Traditional software development often relegated testing to a secondary phase, frequently outsourced to separate quality assurance departments. However, the rise of DevOps and continuous integration has necessitated a shift toward “test-driven” or “test-enabled” development. Philip Riecks identifies that the primary challenge for developers is not the lack of tools, but the lack of a clear strategy. Testing is often perceived as a bottleneck rather than an accelerator.
The methodology proposed focuses on the Testing Pyramid, which prioritizes a high volume of fast, isolated unit tests at the base, followed by a smaller number of integration tests, and a minimal set of end-to-end (E2E) tests at the apex. The innovation in Spring Boot testing lies in its ability to provide “Slice Testing,” allowing developers to load only specific parts of the application context (e.g., the web layer or the data access layer) rather than the entire infrastructure. This approach significantly reduces test execution time while maintaining high fidelity.
Architectural Slicing and Context Management
One of the most powerful features of the Spring Boot ecosystem is its refined support for slice testing via annotations. This allows for an analytical approach to testing where the scope of the test is strictly defined by the architectural layer under scrutiny.
- Web Layer Testing: Using
@WebMvcTest, developers can test REST controllers without launching a full HTTP server. This slice provides a mocked environment where the web infrastructure is active, but business services are replaced by mocks (e.g., using@MockBean). - Data Access Testing: The
@DataJpaTestannotation provides a specialized environment for testing JPA repositories. It typically uses an in-memory database by default, ensuring that database interactions are verified without the overhead of a production-grade database. - JSON Serialization:
@JsonTestisolates the serialization and deserialization logic, ensuring that data structures correctly map to their JSON representations.
This granular control prevents “Context Bloat,” where tests become slow and brittle due to the unnecessary loading of the entire application environment.
Code Sample: A Specialized Controller Test Slice
@WebMvcTest(UserRegistrationController.class)
class UserRegistrationControllerTest {
@Autowired
private MockMvc mockMvc;
@MockBean
private UserRegistrationService registrationService;
@Test
void shouldRegisterUserSuccessfully() throws Exception {
mockMvc.perform(post("/api/users")
.contentType(MediaType.APPLICATION_JSON)
.content("{\"username\": \"priecks\", \"email\": \"philip@example.com\"}"))
.andExpect(status().isCreated());
}
}
Managing External Dependencies: Testcontainers and WireMock
A significant hurdle in integration testing is the reliance on external systems such as databases, message brokers, or third-party APIs. Philip emphasizes the move away from “In-Memory” databases (like H2) for testing production-grade applications, citing the risk of “Environment Parity” issues where H2 behaves differently than a production PostgreSQL instance.
The integration of Testcontainers allows developers to spin up actual Docker instances of their production infrastructure during the test lifecycle. This ensures that the code is tested against the exact same database engine used in production. Similarly, WireMock is utilized to simulate external HTTP APIs, allowing for the verification of fault-tolerance mechanisms like retries and circuit breakers without depending on the availability of the actual external service.
Consequences of Testing on Long-term Maintainability
The implications of a robust testing strategy extend far beyond immediate bug detection. A well-tested codebase enables fearless refactoring. When developers have a “safety net” of automated tests, they can update dependencies, optimize algorithms, or redesign components with the confidence that existing functionality remains intact.
Furthermore, Philip argues that the responsibility for quality must lie with the engineer who writes the code. In an “On-Call” culture, the developer who builds the system also runs it. This ownership model, supported by automated testing, transforms software engineering from a process of “handing over” code to one of “carefully crafting” resilient systems.
Conclusion
Demystifying Spring Boot testing requires a transition from viewing tests as a chore to seeing them as a fundamental engineering discipline. By leveraging architectural slices, managing dependencies with Testcontainers, and adhering to the Testing Pyramid, developers can build applications that are not only functional but also sustainable. The ultimate goal is to reach a state where testing provides joy through the confidence it instills, ensuring that the software remains a robust asset for the enterprise rather than a source of technical debt.
Links:
[DevoxxBE2025] Unleashing Vector Search with Spring AI, LangChain4J, Hibernate Vector, and the Oracle Database 23ai
Lecturer
Juarez Barbosa Junior is a Developer Evangelist at Oracle, with over 30 years in software engineering and relations. He organizes workshops, participates in hackathons, and speaks on cloud technologies, focusing on AI and databases.
Abstract
This article investigates building generative AI applications in Java using Oracle AI Vector Search in Database 23ai, integrated with extensions like Hibernate Vector, Spring AI, and LangChain4j. It explains the VECTOR type for embeddings, contextualized by needs for efficient similarity searches. Through demonstrations of storage, querying, and RAG patterns, the narrative highlights tactics for data handling and application construction. The exploration assesses factors in vector databases, ramifications for scalability and precision, and offers perspectives on leveraging Java frameworks for AI-driven solutions.
Innovations in Vector Data Management
Oracle Database 23ai introduces the VECTOR type, enabling storage of high-dimensional embeddings for semantic searches. This innovation supports AI applications by allowing similarity queries on unstructured data like texts or images.
Context: Traditional databases struggle with vectors; 23ai’s native support eliminates separate systems, simplifying architectures. Methodologically, embeddings generate via models like Cohere, stored as VECTOR(1536,*).
Demonstrations: Creating tables with VECTOR columns, inserting embeddings. Implications: Unified storage reduces latency, enhancing real-time AI.
Integration with Java Frameworks
Hibernate Vector maps VECTOR types to Java entities, enabling ORM for embeddings. Annotations like @Vector define dimensions.
Spring AI abstracts AI services, integrating with Oracle for vector stores. Code:
@Bean
public VectorStore vectorStore(EmbeddingModel embeddingModel, DataSource dataSource) {
return new OracleVectorStore(embeddingModel, dataSource);
}
LangChain4j enhances with chains for RAG, retrieving contexts for prompts.
Analysis: Frameworks bridge databases and AI, streamlining development. Implications: Faster prototyping, consistent integrations.
Retrieval-Augmented Generation Patterns
RAG combines retrieval with generation: embeddings query vectors, augmenting prompts for accuracy.
In demos, documents embed, stored in 23ai. Queries retrieve similar chunks, feeding models for responses.
Methodologically, similarity metrics like cosine compute relevance. Implications: Reduces hallucinations, crucial for factual AI.
Scalability and Performance Considerations
23ai’s indexes accelerate searches, supporting billions of vectors. Java integrations leverage this for efficient apps.
Analysis: Hybrid storage (relational + vector) unifies queries. Ramifications: Cost savings, improved precision in large-scale deployments.
Ethical and Practical Implications
AI demands responsible use: Oracle’s programs recognize community contributions. Free tiers enable experimentation.
Future: Deeper integrations enhance capabilities.
In summary, these tools empower Java for AI, merging databases with frameworks for innovative applications.
Links:
- Lecture video: https://www.youtube.com/watch?v=hVd8iUnLp8A
- Juarez Barbosa Junior on LinkedIn: https://www.linkedin.com/in/juarezjunior/
- Juarez Barbosa Junior on Twitter/X: https://twitter.com/juarezjunior
- Oracle website: https://www.oracle.com/
[SpringIO2026] New in Spring Security 7: MFA, OAuth2 and more
Lecturer
Daniel Garnier-Moiroux is a software engineer on the Spring team at Broadcom, focusing on Spring Security, identity, and SSO concerns. He contributes actively to Spring Security and related projects, including work on one-time tokens, passkeys, multi-factor authentication, and Model Context Protocol security. He is also writing the Manning book Testing Spring Boot Applications (early access). Previously affiliated with VMware Tanzu, he has spoken widely on Spring Security architecture, passwordless authentication, and practical security patterns. He maintains an active presence through his personal site and open-source contributions under the handle Kehrlann.
Abstract
Spring Security 7 delivers a long-requested multi-factor authentication capability together with modular configuration improvements, OAuth 2 enhancements on both the authorization-server and client sides, stricter defaults such as mandatory PKCE, dynamic client registration, and experimental support for securing Model Context Protocol endpoints. This article examines the design of the new MFA APIs built around factor granted authorities and authorization-manager factories, shows how modular customizers avoid overwriting Spring Boot defaults, details the OAuth 2 changes, and outlines migration considerations from version 6.
Multi-Factor Authentication APIs
Multi-factor authentication had been requested since issue 2603 was opened in 2013. Spring Security 7 finally ships first-class support. Authentication factors are modelled as special GrantedAuthority instances of type FactorGrantedAuthority. Each successful login method (password, one-time token, passkey, and so on) records both the factor type and the timestamp at which it was obtained.
The annotation @EnableMultiFactorAuthentication installs the necessary infrastructure and accepts a list of required factors. When the list is supplied at the global level, every protected endpoint demands those factors. For finer control the same requirement can be expressed per endpoint by obtaining an AuthorizationManager from a multi-factor factory:
AuthorizationManagerFactory mfa =
AuthorizationManagerFactories.multiFactor()
.requireFactors(
FactorGrantedAuthority.PASSWORD,
FactorGrantedAuthority.OTT)
.build();
http.authorizeHttpRequests(authz ->
authz.requestMatchers("/admin/**")
.access(mfa.hasRole("ADMIN")));
Because the underlying API is the familiar access(AuthorizationManager), arbitrary combinations become possible. The utility AuthorizationManagers.allOf and anyOf allow mixing recent-password checks with role checks, or applying MFA only to administrators while ordinary users need only a password. Time-based constraints are expressed with AllRequiredFactorsAuthorizationManager and a duration; an authentication older than the chosen window is rejected and the user is forced to re-authenticate with the missing factor.
The design deliberately re-uses the existing authorization infrastructure rather than inventing a parallel authentication pipeline. Consequently any custom AuthorizationManager already written for complex access rules can be composed with factor requirements without further framework changes.
Modular Configuration and Safer Defaults
A common pain point in earlier versions was that declaring a single SecurityFilterChain bean completely replaced Spring Boot’s auto-configured security. Spring Security 7 introduces Customizer<HttpSecurity> (and the corresponding customizers for individual configurers such as OAuth2AuthorizationServerConfigurer or CsrfConfigurer). Applications that need only a small adjustment—making one path public, adding a claim to the OpenID Provider Configuration endpoint, or tweaking CSRF—now supply a focused customizer bean. Boot defaults remain intact and the change is applied on top of them.
Several legacy constructs have been removed or relocated. The classic “and()” DSL that closed configuration blocks is gone; lambda style is mandatory. The OAuth 2 password grant has been dropped from the client because the OAuth 2 security best-current-practice document has long discouraged it. Kerberos support and the Spring Authorization Server project itself have been aligned to the same version numbering as the core Spring Security modules, simplifying release coordination.
OAuth 2 Enhancements on Server and Client
On the authorization-server side PKCE is now required by default. Clients that cannot yet produce a code challenge can disable the requirement, but the recommended posture is to keep it enabled even for confidential clients. Dynamic client registration, driven by the need to support Model Context Protocol agents that self-register, has been added. An admin client holding the client.create scope (or, for the more open MCP use-case, an unauthenticated registration endpoint) can POST a registration request and receive a generated client identifier and secret. Tokens used for registration are single-use, limiting abuse.
On the client side Spring Framework 7’s HTTP service clients receive first-class OAuth 2 support. A single bean of type OAuth2RestClientHttpServiceGroupConfigurer wires an OAuth2AuthorizedClientManager and a client-registration identifier into every declarative HTTP interface. The resulting code is free of manual RestClient interceptors yet still obtains and refreshes tokens automatically.
MCP Security and Migration Guidance
Because the Model Context Protocol specification continues to evolve rapidly, MCP security lives in a dedicated Spring AI community project rather than in core Spring Security. The same team members maintain both, and the intention is to graduate the work once the protocol stabilises. Starters on start.spring.io already expose experimental MCP server and client security options that rely on the OAuth 2 features described above.
Migration from Spring Security 6 is documented in a dedicated guide. Most applications that already use the lambda DSL and modern authorization managers require only dependency updates and the removal of the password-grant client code. Applications still relying on the old access-decision voters must move to the authorization-manager model; the deprecated classes remain available in a separate module for a transitional period.
Taken together, the release strengthens the security baseline while giving developers precise, composable tools for multi-factor scenarios and modern authorization flows.