Posts Tagged ‘OpenSource’
[PyDataGlobal2025] Tools, Empathy, and the Craft of Building Delightful Data Experiences
Lecturer
Isabel Zimmerman is a Senior Software Engineer at Posit, PBC (formerly RStudio). She was the first full-time Python open-source hire at the company and began her tenure building MLOps packages before shifting focus to the Python experience inside interactive development environments. Her current work centers on Positron, a next-generation data-science IDE. Beyond computing she is an avid fantasy reader and bookbinder, interests that inform her view of tools as objects that can carry quiet power across generations of users.
Abstract
Every practitioner occupies a position on the continuum between tool user and tool builder. This keynote explores that continuum through the dual lenses of technical excellence and human empathy. Drawing on concrete examples from the Positron IDE and the broader open-source Python ecosystem, it articulates a set of “hard skills” (modularity, reproducibility, flexibility) and “soft skills” (knowing the user, discoverability, small improvements with large impact, and explaining one’s work). The argument is that tools become delightful only when both categories are deliberately cultivated, and that the barrier to becoming a builder has never been lower.
From Consumer to Creator: Reframing Everyday Practice
A tool is defined simply as anything that carries out a particular function. Under that definition most data scientists already build tools—whether a Git alias that corrects a habitual typo, a reusable function shared in Slack, a dashboard that informs business decisions, or a private utility that solves a personal measurement problem. The psychological barrier that prevents many practitioners from identifying as builders is therefore largely artificial. Framing the act of extraction and encapsulation as tool construction lowers that barrier and simultaneously improves personal productivity and future reproducibility.
The transition from pure consumer to occasional creator is further eased by contemporary language models. Functions that once required manual packaging can now be sketched in natural language and refined iteratively. The resulting artifacts need not be public; a private package that accelerates one’s own daily workflow is already a contribution to the wider ecosystem because it reduces friction for at least one user—oneself.
Hard Skills of Tool Design
Three technical properties form the backbone of robust tools. Modularity allows a system to grow with its users. By leaning on existing community infrastructure—FastAPI for REST endpoints, Code OSS for the editor substrate—builders can concentrate effort on the distinctive value they wish to add. The same modular surface also supplies clear extension points, encouraging specialized packages that solve narrow, high-value problems.
Reproducibility remains a foundational requirement of trustworthy science. Graphical exploration interfaces are powerful, yet they risk introducing non-reproducible click sequences. Positron’s data explorer illustrates one resolution: every filter and sort operation is internally represented so that a single button can emit executable code that recreates the identical view. The cycle of exploration is thereby closed inside a language rather than left as a sequence of manual steps.
Flexibility must be tempered by the Zen of Python’s preference for simplicity. Functions that accept an ever-expanding union of input types quickly become unmaintainable. Preferring a small number of well-defined entry points and composing them later yields systems that remain extensible without collapsing under their own complexity. Context windows supplied to language models follow the same principle: start with a carefully chosen default set of information and allow the user to add or remove context explicitly.
Soft Skills and the Human Side of Interfaces
Technical excellence alone does not produce tools that people love. Empathy for the intended user is equally decisive. Data work is characterized by iterative exploration of uncharted territory, whereas classical software engineering often constructs well-specified structures in known domains. An interface optimized solely for the latter will frustrate the former. Permanent, always-available consoles, column-aware completions, and language-server optimizations tuned to data-frame idioms are concrete expressions of that empathy.
Discoverability ensures that high-impact features do not remain secret passages. Action bars that surface “render on save,” one-click code-cell insertion, and help panes that render richly formatted docstrings bring frequently needed capabilities into immediate view. Small ergonomic improvements—running a Streamlit or Dash application with the correct launcher rather than a plain Python invocation—accumulate into large reductions in daily friction.
Finally, the act of explaining one’s work closes a vital feedback loop. Writing documentation, type annotations, or even lightweight notes in a project file forces clarity of thought. The same artifacts later serve both future collaborators and future selves. The principle “if your writing helps even one person it is worth doing, especially if that person is you” applies equally to private architectural notes and public getting-started guides.
Closing the Loop Between Building and Using
Tools improve through continuous cycles of use, observation of pain points, and iterative refinement. Feedback—whether GitHub issues, hallway conversations, or structured user testing—supplies the raw material for those cycles. Because every practitioner is simultaneously a consumer and a potential contributor, each unique perspective enriches the shared ecosystem. The mission is not the construction of a final, perfect package but the ongoing cultivation of experiences that feel beautiful, empowering, and precisely fitted to the work at hand.
Links:
[MunchenJUG] Evolution of Static Analysis: The Journey to PMD 7 (7/Oct/2024)
Lecturer
Andreas Dangel is a distinguished software engineer with extensive expertise in Java, Spring, SQL, and agile methodologies. With a professional career spanning several decades, he has significantly contributed to the IoT consumer electronics industry. Andreas has been a pivotal figure in the open-source community, serving as a maintainer of PMD since 2012 and a committer at the Apache Software Foundation for the Maven project. Currently based in Munich, he continues his professional endeavors at MicroDoc.
Abstract
This article explores the comprehensive transformation of PMD, a leading multi-language static code analyzer, through its significant transition to version 7. It examines the fundamental principles of PMD—including its rule-based architecture and copy-paste detection—while detailing the modernization of its core engine to support evolving language features and improved performance. The analysis highlights the challenges faced during this decade-long development cycle, the shift in architectural paradigms to accommodate complex language parsing, and the strategic roadmap for the future of automated code quality assurance.
The Architecture of Static Analysis: Understanding PMD
PMD serves as a sophisticated static code analyzer designed to identify problematic patterns, common mistakes, and stylistic inconsistencies across various programming languages. Originally established in 2002 as the “Project Mistake Detector,” the tool has evolved into a robust, rule-based ecosystem supporting over ten languages. The system’s utility is grounded in its ability to detect issues that often elude standard compilers, categorized into domains such as error-prone constructs, best practices, code style, and performance.
The engine operates on a rule-based methodology where every detectable problem is governed by a specific rule. PMD offers users more than 400 predefined rules, including 270 specifically for Java. These rules can be customized through two primary methods: writing custom Java classes or utilizing XPath expressions to query the source code’s Abstract Syntax Tree (AST). To facilitate the latter, the PMD ecosystem includes a “Rule Designer” application, allowing developers to visualize code structures and test XPath queries in real-time.
Beyond standard rule checking, PMD includes a specialized Copy-Paste Detector (CPD). Unlike the core engine, which requires deep language parsing, CPD utilizes a different technological approach that allows it to support an even broader range of languages for identifying duplicated code blocks.
Implementation and Integration Strategies
PMD’s versatility is reflected in its diverse integration options within the modern software development lifecycle. Written in Java, the tool can be executed via a simple command-line interface (CLI) or integrated into various build and development environments.
Build Tool Integration
For Java-centric projects, integration via build automation tools is the standard approach:
- Maven: Utilizing the
maven-pmd-plugin, developers can automate code verification and copy-paste detection as part of the build process. - Gradle and Ant: Similar plugins exist to ensure code quality is maintained continuously without manual intervention.
- Quality Gates: By configuring the build to fail upon rule violations, PMD serves as a mandatory quality gate, ensuring that no substandard code reaches the repository.
IDE and CI/CD Ecosystems
To provide immediate feedback, PMD supports major Integrated Development Environments (IDEs) including Eclipse, IntelliJ IDEA, and VS Code. Furthermore, it is deeply integrated into Continuous Integration (CI) services. For instance, Jenkins utilizes specialized plugins to visualize results and track the history of violations across builds, providing insights into whether code quality is improving or deteriorating over time. Modern cloud services and GitHub Apps also leverage PMD to perform automatic code reviews during pull requests, providing comments directly on the affected code blocks.
Innovations in PMD 7: Redesigning the Engine
The transition to PMD 7 represents a fundamental shift in how the tool processes source code. The primary driver for this major release was the need to overcome the limitations of the aging architecture that had been in place for nearly two decades.
The internal redesign focuses on several key areas:
- Parsing Modern Java: As Java’s release cadence accelerated, PMD needed a more flexible way to handle new language features like records, sealed classes, and pattern matching.
- Performance Optimization: The new version introduces architectural changes that improve the speed of analysis, particularly for large-scale projects with hundreds of rules.
- Language Support Expansion: While Java remains a core focus, PMD 7 strengthens its multi-language capabilities, including better support for languages like Salesforce’s Apex.
One of the significant challenges in this journey was maintaining backward compatibility while significantly altering the AST structure. The development team had to balance the introduction of more descriptive node types with the risk of breaking existing custom rules written by the community.
Future Directions and Sustainability
Looking ahead, the PMD project aims to enhance its analysis capabilities by incorporating more data-flow and control-flow sensitivity. This would allow the tool to detect more complex logic errors that require understanding the state of variables across different execution paths.
Sustainability remains a focal point for the project. As an open-source initiative maintained by a small core team of three individuals and occasional contributors, the “Journey to PMD 7” also serves as a case study in open-source lifecycle management. The roadmap includes simplifying the process of writing and maintaining rules to encourage more community participation and ensuring the tool remains relevant in an era of increasing automated development.
Links:
[VoxxedDaysTicino2026] May the Control Plane Be with You: Kamaji and the Rise of Kubernetes at Scale
Lecturer
Dario Tranchitella serves as the Chief Technology Officer at Clastix, a startup he co-founded in 2020 during the global pandemic. With a background as a site reliability engineer and software developer, Dario specializes in Kubernetes engineering and multi-tenancy solutions. He has extensive experience managing large-scale Kubernetes fleets and contributes to open-source projects, drawing from his prior roles in the tech industry. Relevant links include his LinkedIn profile (https://it.linkedin.com/in/dariotranchitella) and Clastix’s website (https://clastix.io/).
Abstract
This article explores Dario Tranchitella’s insights into scaling Kubernetes through Kamaji, an open-source initiative transforming Kubernetes into a control-plane-as-a-service platform. Originating from real operational challenges, the discussion dissects Kubernetes architecture, the hosted control plane model, community-driven evolution, and adoption by major entities. It analyzes methodologies for multi-tenancy, resource optimization, and resilience, while considering implications for large-scale deployments in cloud-native environments.
Origins and Challenges in Kubernetes Management
Dario’s journey with Kamaji began amid personal and professional turmoil, exemplified by an outage during his father’s wedding that required restoring a Kubernetes cluster. This incident underscored the operational and financial hurdles of scaling Kubernetes beyond a few clusters. As a former site reliability engineer managing a fleet for a U.S. company, Dario encountered the complexities of multi-tenancy, where infrastructure or applications are shared among tenants—be they customers or internal teams—while ensuring fair resource allocation and preventing privilege escalation.
Kubernetes, donated to the Cloud Native Computing Foundation (CNCF), orchestrates containers in a distributed system comprising a control plane and worker nodes. The control plane acts as the “brain,” maintaining application states, while worker nodes provide computational power. Dario likens this to a reconciliation loop: users specify desired states, and Kubernetes aligns current states accordingly, handling tasks like load balancing without manual intervention. It runs ubiquitously—on laptops, clouds, bare metal, or edge devices—abstracting deployment details.
However, scaling introduces bottlenecks. The control plane includes the API server for information handling, the controller manager for reconciliation loops, the scheduler for pod placement to avoid single points of failure, and etcd for state storage using the Raft consensus algorithm. Etcd requires at least three instances for fault tolerance (n/2 + 1), making it resource-intensive and a primary challenge in multi-tenant setups.
In multi-tenancy, Dario emphasizes dividing resources imperatively, akin to apartments in a building: tenants occupy their spaces without infringing on others. Kubernetes excels here, but traditional setups demand separate clusters per tenant to isolate workloads, leading to overhead. Dario’s prior experience revealed inefficiencies, prompting Kamaji’s creation to address these pain points.
The Kamaji Architecture and Hosted Control Plane Model
Kamaji redefines Kubernetes by running control planes as regular pods within a management cluster, adopting a hosted control plane architecture. This separates control planes from worker nodes, allowing a single management cluster to host multiple tenant control planes efficiently. Worker nodes join via the management cluster’s API endpoint, optimizing resources and reducing costs.
Dario contrasts this with traditional setups: instead of dedicating machines per control plane, Kamaji leverages Kubernetes’ scheduling for etcd and other components as pods. This “Kubernetes-in-Kubernetes” approach, inspired by Google’s 2017 Kubernetes Engine, avoids vendor lock-in by supporting tools like kubeadm for certificate management and cluster bootstrapping.
Key innovations include multi-tenant datastores: Kamaji supports etcd, PostgreSQL, or MySQL, allowing collision of databases into single instances for optimization, though Dario advises multiple clusters to minimize blast radius. Scalability tests show a single management cluster handling up to a thousand control planes, but he recommends diversification for resilience.
Methodologically, Kamaji integrates with community projects like Cluster API for node provisioning across providers (Azure, AWS, Google). It avoids reinventing orchestration, focusing solely on control planes while enabling seamless worker node integration. Code samples illustrate simplicity:
apiVersion: kamaji.clastix.io/v1alpha1
kind: TenantControlPlane
metadata:
name: example
spec:
kubernetes:
version: v1.25.0
dataStore:
name: default
This YAML defines a tenant control plane, specifying Kubernetes version and datastore, demonstrating declarative management.
Implications include cost savings—reducing dedicated machines—and operational ease, as upgrades affect only the management cluster without tenant disruption.
Community Collaboration and Evolution of Kamaji
Kamaji’s growth stems from open-source collaboration since its 2022 launch at KubeCon Valencia. Dario highlights cross-pollination with organizations like NVIDIA, Rackspace, OVH, Ionos, and the CNCF community. Early adopters provided feedback, debunking scalability myths and proving PostgreSQL viability as an etcd alternative.
Dario’s philosophy: “Do what you love,” drove pursuits like running Kubernetes on PostgreSQL, challenging skeptics. Community tools like Kine (etcd shim) enabled alternative datastores, enhancing flexibility.
Evangelism involved panels at conferences, demystifying hosted control planes alongside Red Hat’s Hypershift and Mirantis’ K0s. Despite similarities, Kamaji’s vanilla Kubernetes focus and multi-datastore support differentiate it.
Code integration with kubeadm ensures portability:
kamaji create --kubeadm-config /path/to/config.yaml
This command bootstraps clusters, allowing imports from existing setups without lock-in.
Consequences: Kamaji fosters a collaborative ecosystem, reducing proprietary dependencies and promoting standards. Adoption by giants validates its scalability, though Dario cautions against over-reliance on single clusters.
Implications for Cloud-Native Scalability and Future Directions
Kamaji addresses Kubernetes’ scaling pains by commoditizing control planes, lowering barriers for multi-tenant platforms. It optimizes resources, crucial in cloud environments where costs accumulate. By hosting control planes as pods, it leverages Kubernetes’ strengths for self-management, a meta-approach enhancing resilience.
Broader implications include democratizing large-scale deployments: smaller teams manage vast fleets without proportional infrastructure. However, Dario stresses evaluating trade-offs—colliding datastores risks contention, necessitating careful architecture.
Future directions involve deeper community integration, potentially expanding to more datastores or advanced scheduling. Kamaji’s open-source ethos ensures evolution through contributions, avoiding silos.
In conclusion, Dario’s work with Kamaji exemplifies pragmatic innovation in cloud-native computing, balancing efficiency, resilience, and community-driven progress.
Links:
[RivieraDev2025] Moustapha Agack – One Pixel at a Time: Running DOOM on an E-Reader
Moustapha Agack regaled the Riviera DEV 2025 crowd with a tale of audacious tinkering in his session, chronicling his quest to resurrect the iconic DOOM on a humble Kindle e-reader. Lacking embedded systems expertise, Moustapha embarked on this odyssey driven by whimsy and challenge, transforming a 25-euro thrift find into a retro gaming relic. His narrative wove through hardware idiosyncrasies, software sorcery, and triumphant playback, celebrating the open-source ethos that fuels such feats.
The Allure of DOOM: A Porting Phenomenon
Moustapha kicked off by immersing attendees in DOOM’s lore, the 1993 id Software opus that pioneered first-person shooters with its labyrinthine levels and demonic foes. Its source code, liberated in 1997 under GPL, has spawned thousands of ports—from pregnancy tests to analytics dashboards—cementing its status as internet folklore. Moustapha quipped about the “Run DOOM on Reddit” subreddit, where biweekly posts chronicle absurd adaptations, like voice-powered variants or alien hardware hypotheticals.
The game’s appeal lies in its modular C codebase: clean patterns, hardware abstraction layers, and raycasting renderer make it portable gold. Moustapha praised its elegance—efficient collision detection, binary space partitioning—contrasting his novice TypeScript background with the raw C grit. This disparity fueled his motivation: prove that curiosity trumps credentials in maker pursuits.
Decoding the Kindle: E-Ink Enigmas
Shifting to hardware, Moustapha dissected the Kindle 4 (2010 model), a $25 Boncoin bargain boasting 500,000 pixels of e-ink wizardry. Unlike LCDs, e-ink mimics paper via electrophoretic microspheres—black-and-white beads in oil, manipulated by electric fields for grayscale shades. He likened pixels to microscopic disco balls: charged fields flip beads, yielding 16-level grays but demanding full refreshes to banish “ghosting” artifacts.
The ARM9 processor (532 MHz), 256MB RAM, and Linux kernel (2.6.31) promise viability, yet jailbreaking—via USB exploits—unlocks framebuffer access for custom rendering. Moustapha detailed framebuffer mechanics: direct memory writes trigger screen updates, but e-ink’s sluggish 500ms latency and power draw necessitate optimizations like partial refreshes. His setup bypassed Amazon’s sandbox, installing a minimal environment sans GUI, priming the device for DOOM’s pixel-pushing demands.
Cross-Compilation Conundrums and Code Conjuring
The crux lay in bridging architectures: compiling DOOM’s x86-centric code for ARM. Moustapha chronicled toolchain tribulations—Dockerized GCC cross-compilers, dependency hunts yielding bloated binaries. He opted for Chocolate Doom, a faithful source port, stripping extraneous features for e-ink austerity: monochrome palettes, scaled resolutions (400×600 to 320×240), and throttled framerates (1-2 FPS) to sync with refresh cycles.
Input mapping proved fiendish: no joystick meant keyboard emulation via five tactile buttons, scripted in Lua for directional strafing. Rendering tweaks—dithered grayscale conversion, waveform controls for ghost mitigation—ensured legibility. Moustapha shared war stories: endless iterations debugging endianness mismatches, memory overflows, and linker woes, underscoring embedded development’s unforgiving precision.
Triumph and Takeaways: Pixels in Motion
Victory arrived with a live demo: DOOM’s corridors flickering on e-ink, demons dispatched amid deliberate blips. Moustapha beamed at this personal milestone—a 2000s internet kid etching his port into legenddom. He open-sourced everything: binaries, scripts, slides via Slidev (Markdown-JS hybrid for interactive decks), inviting Kindlers to replicate.
Reflections abounded: e-ink’s constraints honed creativity, cross-compilation demystified low-level ops, and DOOM’s legacy affirmed open-source’s democratizing force. Moustapha urged aspiring hackers: embrace imperfection, iterate relentlessly, and revel in absurdity. His odyssey reminds that innovation blooms in unlikely crucibles—one pixel, one port at a time.
Links:
[PyConUS2025] Lessons from 503 Days of Full-Time Free and Open-Source Software Development
Lecturer
Rodrigo Girão Serrão is a Python educator, author, and independent trainer. He maintains an extensive body of writing on Python, programming, and mathematics at mathspp.com and has published multiple independently produced books on these subjects. Serrão has spoken at major conferences including PyCon US, EuroPython, and various European national PyCons. In late 2024 he established a Guinness World Record for the largest programming lesson. He previously spent 503 consecutive days as a full-time contributor to the Textual terminal-user-interface framework. His professional site is https://mathspp.com and his GitHub handle is rodrigogiraoserrao.
Abstract
Drawing on a continuous year-and-a-half of full-time employment on the Textual open-source project, Rodrigo Girão Serrão reflects on non-technical lessons acquired in that environment. The presentation examines the role of public online activity in obtaining technical work, the management of personal ego within a stronger team, constructive responses to error and code review, the practical demands of user and contributor interaction, and strategies for navigating a large codebase that exceeds individual working memory. The account is explicitly subjective yet offers transferable observations for anyone collaborating on substantial software, whether proprietary or free.
Obtaining Work and Managing Ego in Collaborative Settings
Serrão begins by stressing that every public artifact—blog posts, code repositories, conference talks, social-media interactions—functions as a continuous advertisement of one’s capabilities and temperament. In his own case, sustained technical writing created intermittent contact with the eventual employer; over time that contact matured into an offer of full-time open-source employment. He is careful to acknowledge the element of chance while simultaneously insisting that chance can be cultivated: consistent public output raises the probability that a future opportunity will intersect with an existing relationship. Attendance at events such as PyCon further multiplies those intersections.
Once inside a team that contained stronger Python practitioners than himself, Serrão confronted the necessity of subordinating ego. Previously the sole Python developer in smaller organizations, he had been simultaneously the best and the worst practitioner by definition. The new environment inverted that status. Rather than experience the change as loss, he reframed it as an accelerated learning opportunity. The presence of more experienced colleagues meant that disagreements could be treated as tuition rather than threats. Code reviews, in particular, became occasions to inquire why a particular solution was preferred, thereby converting potential confrontation into knowledge transfer. The discipline required is emotional as much as technical: one must deliberately set aside the impulse to defend one’s first draft and instead treat every requested change as data about better practice.
Honest mistakes are inevitable and, within a healthy team, permissible; repetition of the same mistake is not. Serrão illustrates the point with self-deprecating examples, including a pull-request history that initially appeared to worsen rather than improve and an issue report whose essence reduced to the complaint that “Python ran when I ran Python.” The episode, quickly closed in embarrassment, underscores both the ubiquity of error and the protective value of a non-punitive culture. The operative rule is simple: never make the identical error twice.
Interacting with Users and Navigating Large Codebases
Users are simultaneously the justification for open-source labor and a persistent source of friction. Interaction consumes time and emotional energy, especially when bug reports lack minimal reproducible examples or when pull requests ignore project conventions. Serrão’s central recommendation is the creation of a thorough contributing guide, not because contributors will read it voluntarily, but because the document can be cited in responses. Issue templates that solicit terminal version, operating-system details, and other project-specific context further reduce diagnostic cycles. The first reply to any issue or pull request should be rapid—even if it consists only of an acknowledgment and a pointer to the guide—because prolonged silence communicates indifference and can discourage first-time contributors.
Kindness that borders on the excessive is advised. Textual communication strips away tone; what feels playful to the writer may read as curt or sarcastic to the recipient. Over-compensation with explicit warmth therefore functions as insurance. When a pull request must be declined, Serrão attempts to extract any salvageable fragment, open a new pull request containing that fragment, and credit the original author as co-author. The gesture preserves the contributor’s sense of impact and avoids the appearance of appropriation.
A large codebase cannot be held entirely in working memory. Serrão therefore maintains four persistent heuristics while making changes: (1) prioritize the experience of the end user over the convenience of the implementer; (2) attend to the spirit rather than the letter of an issue description; (3) accept the burden of tedious or difficult work so that downstream developers face fewer obstacles; and (4) evaluate every design decision for the reasonable future possibilities it might foreclose. Before opening a pull request he converts it to draft status and performs a self-review, catching many defects before they reach colleagues. Finally, he insists on running the full test suite; the project’s complexity guarantees that untested changes will break something.
The cumulative effect of these practices is a posture of continuous, ego-light learning. Public writing may open doors; humility and systematic kindness keep them open. A contributing guide and disciplined self-review protect both the project’s quality and the psychological safety of its participants. Although Serrão no longer works full-time on open source, the habits formed during those 503 days continue to shape his work as an educator and independent practitioner.
Links:
[RivieraDev2025] Olivier Poncet – Anatomy of a Vulnerability
Olivier Poncet captivated the Riviera DEV 2025 audience with a detailed dissection of the XZ Utils attack, a sophisticated supply chain assault revealed on March 29, 2024. Through a forensic analysis, Olivier explored the attack’s two-year timeline, its blend of social and technical engineering, and its near-catastrophic implications for global server security. His presentation underscored the fragility of open-source software supply chains, urging developers to adopt rigorous practices to safeguard their systems.
The XZ Utils Attack: A Coordinated Threat
Olivier introduced the XZ Utils attack, centered on the CVE-2024-3094 vulnerability, which scored a critical 10/10 severity. XZ Utils, a widely used compression library integral to Linux distributions and kernel boot processes, was compromised with malicious code embedded in its upstream tarballs. Discovered fortuitously by Andres Freund, a PostgreSQL engineer at Microsoft, the attack aimed to weaken the SSH daemon, potentially granting attackers access to countless exposed servers. Olivier highlighted the serendipitous nature of the discovery, as Andres stumbled upon the issue during routine benchmarking, revealing suspicious behavior that led to a deeper investigation.
The attack’s objectives were threefold: corrupt the software supply chain, undermine SSH security, and achieve widespread system compromise. Olivier emphasized that this was not a mere flaw but a meticulously planned operation, exploiting the trust inherent in open-source ecosystems.
Social and Technical Engineering Tactics
The XZ Utils attack leveraged a blend of social and technical manipulation. Olivier detailed how the attacker, over two years, used social engineering to infiltrate the project’s community, likely posing as a trusted contributor to introduce malicious code. This included pressuring maintainers and exploiting the project’s reliance on a small, often unpaid, team. Technically, the attack involved injecting backdoors into the tarballs, which were then distributed to Linux distributions, bypassing standard security checks.
Olivier’s analysis, conducted through extensive virtual machine testing post-discovery, revealed the attack’s complexity, including obfuscated code designed to evade detection. He stressed that the human element—overworked maintainers and community trust—was the weakest link, highlighting the need for robust governance in open-source projects.
Supply Chain Vulnerabilities in Open Source
A key focus of Olivier’s talk was the broader vulnerability of open-source supply chains. He cited examples like the npm package “is-odd,” unnecessarily downloaded millions of times, and the “colors” package, whose maintainer intentionally broke builds worldwide by introducing malicious code. These incidents illustrate how transitive dependencies and unverified packages can introduce risks. Olivier also referenced a recent Hacker News report about over 200 malicious GitHub repositories targeting developers, underscoring the growing threat of supply chain attacks.
He warned that modern infrastructures, heavily reliant on open-source software, are only as strong as their weakest link—often a single maintainer. Tools like Docker Hub, npm, and pip, while convenient, can introduce unvetted dependencies, amplifying risks. Olivier advocated for heightened scrutiny of external repositories and dependencies to mitigate these threats.
Mitigating Risks Through Best Practices
To counter supply chain vulnerabilities, Olivier proposed practical measures. He recommended using artifact repositories like Artifactory to locally store and verify dependencies, ensuring cryptographic integrity through hash checks. While acknowledging the additional effort required, he argued that such practices significantly enhance security by reducing reliance on external sources. Auditing direct and transitive dependencies, questioning their necessity, and reimplementing simple functions locally were also advised to minimize exposure.
Olivier concluded with a call to action, urging developers to treat supply chain security as a priority. By fostering a culture of vigilance and investing in secure practices, organizations can protect their systems from sophisticated attacks like XZ Utils, preserving the integrity of the open-source ecosystem.
Links:
[DevoxxFR2025] Simplify Your Ideas’ Containerization!
For many developers and DevOps engineers, creating and managing Dockerfiles can feel like a tedious chore. Ensuring best practices, optimizing image layers, and keeping up with security standards often add friction to the containerization process. Thomas DA ROCHA from Lenra, in his presentation, introduced Dofigen as an open-source command-line tool designed to simplify this. He demonstrated how Dofigen allows users to generate optimized and secure Dockerfiles from a simple YAML or JSON description, making containerization quicker, easier, and less error-prone, even without deep Dockerfile expertise.
The Pain Points of Dockerfiles
Thomas began by highlighting the common frustrations associated with writing and maintaining Dockerfiles. These include:
– Complexity: Writing effective Dockerfiles requires understanding various instructions, their order, and how they impact caching and layer size.
– Time Consumption: Manually writing and optimizing Dockerfiles for different projects can be time-consuming.
– Security Concerns: Ensuring that images are built securely, minimizing attack surface, and adhering to security standards can be challenging without expert knowledge.
– Lack of Reproducibility: Small changes or inconsistencies in the build environment can sometimes lead to non-reproducible images.
These challenges can slow down development cycles and increase the risk of deploying insecure or inefficient containers.
Introducing Dofigen: Dockerfile Generation Simplified
Dofigen aims to abstract away the complexities of Dockerfile creation. Thomas explained that instead of writing a Dockerfile directly, users provide a simplified description of their application and its requirements in a YAML or JSON file. This description includes information such as the base image, application files, dependencies, ports, and desired security configurations. Dofigen then takes this description and automatically generates an optimized and standards-compliant Dockerfile. This approach allows developers to focus on defining their application’s needs rather than the intricacies of Dockerfile syntax and best practices. Thomas showed a live coding demo, transforming a simple application description into a functional Dockerfile using Dofigen.
Built-in Best Practices and Security Standards
A key advantage of Dofigen is its ability to embed best practices and security standards into the generated Dockerfiles automatically. Thomas highlighted that Dofigen incorporates knowledge about efficient layering, reducing image size, and minimizing the attack surface by following recommended guidelines. This means users don’t need to be experts in Dockerfile optimization or security to create robust images. The tool handles these aspects automatically based on the provided high-level description. Thomas might have demonstrated how Dofigen helps in creating multi-stage builds or incorporating user and permission best practices, which are crucial for building secure production-ready images. By simplifying the process and baking in expertise, Dofigen empowers developers to containerize their applications quickly and confidently, ensuring that the resulting images are not only functional but also optimized and secure. The open-source nature of Dofigen also allows the community to contribute to improving its capabilities and keeping up with evolving best practices and security recommendations.
Links:
- Thomas DA ROCHA: https://www.linkedin.com/in/thomasdarocha/
- Lenra: https://www.lenra.io/
- Dofigen on GitHub: https://github.com/lenra-io/dofigen
- Devoxx France LinkedIn: https://www.linkedin.com/company/devoxx-france/
- Devoxx France Bluesky: https://bsky.app/profile/devoxx.fr
- Devoxx France Website: https://www.devoxx.fr/
[RivieraDev2025] Stanley Servical and Louis Fredice Njako Molom – Really Inaccessible
At Riviera DEV 2025, Stanley Servical and Louis Fredice Njako Molom presented an immersive workshop titled “Really Inaccessible,” designed as an escape game to spotlight the challenges of digital accessibility. Through a hands-on, interactive experience, Stanley and Louis guided participants into the perspectives of users with visual, auditory, motor, and cognitive disabilities. Their session not only highlighted the barriers faced by these users but also provided practical strategies for building inclusive digital solutions. This engaging format, combined with a focus on actionable improvements, underscores the critical role of accessibility in modern software development.
Immersive Learning Through an Escape Game
Stanley and Louis kicked off their workshop with an innovative escape game, inviting participants to navigate a digital environment deliberately designed with accessibility flaws. The game, accessible via a provided URL, immersed attendees in scenarios mimicking real-world challenges faced by individuals with disabilities. Participants were encouraged to use headphones for a fully immersive experience, engaging with tasks that highlighted issues like poor color contrast, missing link styles, and inaccessible form elements. The open-source nature of the game, as Stanley emphasized, allows developers to adapt and reuse it, fostering broader awareness within teams and organizations.
The escape game served as a powerful tool to simulate the frustrations of inaccessible interfaces, such as navigating without a mouse or interpreting low-contrast text. Feedback from participants underscored the game’s impact, with one developer noting how it deepened their understanding of motor and auditory challenges, reinforcing the need for inclusive design. Louis highlighted that the game’s public availability enables it to be shared with colleagues or even non-technical audiences, amplifying its educational reach.
The State of Digital Accessibility
Following the escape game, Stanley and Louis transitioned to a debrief, offering a comprehensive overview of digital accessibility’s current landscape. They emphasized that accessibility extends beyond screen readers, encompassing motor, cognitive, and visual impairments. The European Accessibility Act, effective since June 28, 2025, was cited as a pivotal legal driver, mandating inclusive digital services across public and private sectors. However, they framed this not as a mere compliance obligation but as an opportunity to enhance user experience and reach broader audiences.
The speakers identified common accessibility pitfalls, such as unstyled links or insufficient color contrast, which disrupt user navigation. They stressed that accessibility challenges are highly individualized, requiring flexible solutions that adapt to diverse needs. Tools like screen readers and keyboard navigation aids were discussed, with Stanley noting their limitations when applications lack proper semantic structure. This segment underscored the necessity of integrating accessibility from the earliest stages of design and development to avoid retrofitting costs.
User-Centric Testing for Inclusive Design
A core theme of the workshop was the adoption of a user-centric testing approach to ensure accessibility. Louis introduced tools like Playwright and Cypress, which integrate accessibility checks into end-to-end testing workflows. By simulating user interactions—such as keyboard navigation or form completion—these tools help developers identify and address issues like focus traps in pop-ups or inaccessible form inputs. For instance, Louis demonstrated a test scenario where a form’s number input required specific accessibility roles to ensure compatibility with assistive technologies.
The speakers emphasized that user-centric testing aligns accessibility with functional requirements, enhancing overall application quality. They showcased how tools like Axe-core can be embedded in testing pipelines to scan single-page applications (SPAs) for accessibility violations on a per-use-case basis, rather than just page-level checks. This approach, as Stanley noted, ensures that tests remain relevant to real-world user interactions, making accessibility a seamless part of the development process.
Practical Strategies for Improvement
Stanley and Louis concluded with actionable strategies for improving accessibility, drawing from real-world case studies. They advocated for simple yet impactful practices, such as ensuring proper focus management in pop-ups, using semantic HTML, and maintaining high contrast ratios. For example, they highlighted the importance of updating page titles dynamically in SPAs to aid screen reader users, a practice often overlooked in dynamic web applications.
They also addressed the integration of accessibility into existing workflows, recommending manual testing for critical user journeys and automated checks for scalability. The open-source ecosystem around their escape game, including plugins and VS Code extensions, was presented as a resource for developers to streamline accessibility testing. Louis emphasized collaboration between developers and manual testers to avoid redundant efforts, ensuring that accessibility enhancements align with business goals.
Leveraging Open-Source and Community Feedback
The workshop’s open-source ethos was a recurring theme, with Stanley and Louis encouraging participants to contribute to the escape game’s evolution. They highlighted its flexibility, noting that developers can tailor scenarios to specific accessibility challenges, such as color blindness or motor impairments. The inclusion of a “glitch code” to bypass bugs in the game demonstrated their commitment to practical usability, even in an educational tool.
Participant feedback was actively solicited, with suggestions like adding a menu to navigate specific game sections directly. Stanley acknowledged this as a valuable enhancement, noting that relative URLs for individual challenges are already available in the game’s repository. This collaborative approach, paired with the workshop’s emphasis on community-driven improvement, positions the escape game as a living project that evolves with user input.
Legal and Ethical Imperatives
Beyond technical solutions, Stanley and Louis underscored the ethical and legal imperatives of accessibility. The European Accessibility Act, alongside frameworks like the RGAA (Référentiel Général d’Amélioration de l’Accessibilité), provides a structured guide for compliance. However, they framed accessibility as more than a regulatory checkbox—it’s a commitment to inclusivity that enhances user trust and broadens market reach. By designing for the most marginalized users, developers can create applications that are more robust and user-friendly for all.
The speakers also addressed emerging trends, such as voice-activated navigation, referencing tools like Dragon NaturallySpeaking. While not yet fully integrated into their framework, they expressed openness to exploring such technologies, inviting community contributions to tackle these challenges. This forward-looking perspective ensures that accessibility remains dynamic, adapting to new user needs and technological advancements.
Empowering Developers for Change
The workshop closed with a call to action, urging developers to apply their learnings immediately. Stanley and Louis encouraged attendees to share the escape game, integrate accessibility testing into their workflows, and advocate for inclusive design within their organizations. They emphasized that small, consistent efforts—such as verifying keyboard navigation or ensuring proper ARIA roles—can yield significant improvements. By fostering a culture of accessibility, developers can drive meaningful change, aligning technical innovation with social responsibility.
Links:
- None available
[PyConUS2025] Rediscovering Play as an Antidote to Burnout: Lynn Root
Lecturer
Lynn Root is a Staff Engineer at Spotify and tech lead on the company’s machine-learning and artificial-intelligence platform. She serves as Chair of the PyLadies Global Council, is a former Director and current Fellow of the Python Software Foundation, and is a member of the Django Software Foundation. Root founded the San Francisco chapter of PyLadies and maintains the open-source package interrogate, which measures docstring coverage. She is an adjunct professor in the Industrial Engineering and Operations Research department at Columbia University’s Graduate School of Engineering, where she teaches Python. An active speaker on distributed systems and developer tooling, she describes herself as an “engineer’s engineer.” Outside of work she cultivates houseplants, plays bass guitar, and pursues knitting projects. Her professional site is roguelynn.com and her GitHub handle is econchick.
Abstract
Lynn Root reflects on personal burnout and the cultural pressures that equate adulthood with the abandonment of play. Drawing on developmental psychology, ethology, and historical anecdote, she argues that play—defined by process orientation, self-direction, flexible rules, imaginative framing, and a relaxed yet alert mental state—is essential for resilience, creativity, and social bonding across the lifespan. Through concrete personal practices—skydiving, a hundred-day painting project, and participation in an employee cover band—Root demonstrates how deliberate reclamation of play can restore joy and counteract the exhaustion produced by relentless productivity demands.
The Cultural Myth of Adulthood and the Definition of Play
Root begins with a vivid personal image: being pushed from an airplane over New Zealand. The photograph, she explains, conceals the exhaustion that preceded it. Months earlier, seated in a middle seat on a long-haul flight, she experienced an abrupt emotional collapse—tears triggered by a trivial oversight of a flight attendant yet rooted in deeper disconnection from self and from joy. The episode was not ordinary burnout but “bone-deep exhaustion.”
The proximate cause was professional overextension following promotion to staff engineer. Root had become the internal authority on Python, shepherded numerous projects into open source, and still felt compelled to protect team capacity by expanding her own working hours, often arriving before seven in the morning. Earlier, she had cancelled a conference appearance in Russia because of an overwhelming desire simply to be home with her cat, an act that left residual shame.
Root situates these experiences within a pervasive cultural narrative that treats childhood as mere preparation for adulthood and play as disposable filler. Adolescents internalize the demand to become “well-rounded” and productive; Root herself once declared to her mother that she could not wait to grow up so she could pay her own bills—an emblem of independence that adulthood rapidly complicated. A quotation from C. S. Lewis crystallizes the insight: the frantic desire to appear grown-up is itself a mark of immaturity. True maturity includes the capacity to embrace paradox, imagination, and “second naïveté”—a stage in which adults reclaim the wonder they once discarded.
If childhood is preparation, Root asks, why do so many well-adjusted adults exhibit bitterness, anxiety, depression, and creative atrophy? An alternative framing is more accurate: adults are atrophied children who have unlearned play in the pursuit of seriousness. Contemporary slang—“adulting,” “I can’t adult today”—reveals that competence often feels like a costume rather than an authentic state.
Play itself is rigorously defined by psychologist Peter Gray of Boston College through five features. First, play is process-oriented; the goal is the activity, not an external product or victory. Second, it is self-chosen and self-directed; external compulsion converts it into work. Third, it possesses rules, yet those rules are flexible, negotiated, and revisable by the players. Fourth, it is imaginative, operating in the realm of “what if.” Fifth, it occurs in a mental state that is both relaxed and alert—the optimal zone for risk-taking and learning without paralyzing fear of failure.
These features are observable across mammalian species. Young animals deliberately expose themselves to controlled fear and excitement, acquiring motor skills, emotional regulation, and social competence. Animals deprived of play become fearful, aggressive, or socially inept. Human play is simply an extreme elaboration of the same adaptive mechanism, producing cooperative, resilient, and inventive adults.
Historical Sparks, Animal Intelligence, and Personal Recovery
Play has repeatedly catalyzed scientific advance. Luke Howard, a nineteenth-century chemist and member of a London debating society that fined members who failed to present papers, improvised a classification of clouds rather than pay the penalty. Employing Latin terms—stratus, cumulus, cirrus—he inadvertently founded modern meteorology. A contemporaneous French attempt by Jean-Baptiste Lamarck that named clouds after vegetables was ignored, partly because of political disfavor. The episode illustrates that playful improvisation, rather than solemn intentionality, often produces lasting knowledge.
Corvids display analogous capacities. A widely circulated video shows a crow repeatedly sliding down a snowy roof on a plastic lid, adjusting its starting position after failed attempts. The behavior yields no caloric or reproductive reward; it is pure exploration of friction and tool use—unrewarded object exploration that nevertheless builds physical and cognitive skill. Crows further demonstrate rule-guided decision-making, tool manufacture, numerical competence, and even an understanding of grammatical recursion. Playfulness and intelligence are therefore mutually reinforcing.
Root’s own recovery followed the same logic. Skydiving supplied an initial jolt of freedom, yet sustained restoration required ongoing, low-stakes practices. She joined a hundred-day creative project, producing a daily watercolor without any intention of improvement or sale. Early efforts were aesthetically poor; gradual accumulation of process yielded both technical progress and genuine pride in self-directed making. Subsequently she resumed playing bass guitar—abandoned since high-school orchestra—and joined a Spotify employee cover band called Fake Muse. The band set its own repertoire, aesthetics, and performance rules; the experience was defined by enjoyment rather than professional aspiration. Practice nights, the presence of supportive friends, and an eventual personal relationship with the band’s drummer illustrated the social and affective returns of play.
Root emphasizes that recovery was not achieved by intensifying productivity, optimizing habits, or “adulting” more rigorously. It emerged from successive layers of activity whose only purpose was joy. Each form of play scaffolded the next, gradually restoring connection to self. She therefore advocates a personal ethic: play before promotion, before perfection, before process, and before panic. Cultural injunctions to abandon play are, in her view, simply nonsense.
A closing anecdote from Kurt Vonnegut underscores the stance. Vonnegut insists on purchasing a single envelope in person rather than ordering a bulk package online, precisely because the errand affords encounters with strangers, babies, fire engines, and dogs. The moral, in his phrasing, is that “we are here on Earth to fart around.” Legacy is measured not in commits or promotions but in moments of pure presence, the joy created, the connections fostered, and the play dared despite every message urging seriousness.
Root concludes by inviting the audience to reclaim that permission and to enjoy the remainder of the conference in the same spirit.
Links:
[DotAI2024] DotAI 2024: Maxim Zaks – Mojo: Beyond Buzz, Toward a Systems Symphony
Maxim Zaks, polymath programmer from IDEs to data ducts, and FlatBuffers’ fleet-footed forger, interrogated Mojo’s mettle at DotAI 2024. As Mojo’s communal curator—contributing to its canon sans corporate crest—Zaks, unyoked to Modular, affirmed its ascent: not ephemeral éclat, but enduring edifice for AI artisans and systems smiths alike.
Echoes of Eras: From Procedural Progenitors to Pythonic Prodigies
Zaks zested with zeitgeist: Married… with Children’s clan conjuring C’s centrality, Smalltalk’s sparkle, BASIC’s benevolence—80s archetypes amid enterprise esoterica. Fast-forward: Java’s juggernaut, Python’s pliant poise—yet performance’s plaint persists, Python’s pyrotechnics paling in precision’s precinct.
Mojo manifests as meld: Python’s patois, systems’ sinew—superset sans schism, scripting’s suavity fused with C’s celerity. Zaks zinged its zygote: 2023’s stealthy spawn, Howard’s herald as “decades’ dawn”—now TIOBE’s 48th, browser-bound for barrierless baptism.
Empowering Engineers: From Syntax to SIMD
Zaks zoomed to zealots: high-performance heralds harnessing SIMD sorcery, data designs deftly dispatched—SIMD intrinsics summoning speedups sans syntax strain. Mojo’s mantle: multithreading’s mastery, inline ML’s alchemy—CPUs as canvases, GPUs on horizon.
For non-natives, Zaks zapped a prefix-sum parable: prosaic Python plodding, Mojo’s baseline brisk, SIMD’s spike surging eightfold—arcane accessible, sans secondary syntaxes like Zig’s ziggurats or Rust’s runes.
Community’s crucible: inclusive incubus, tools transcendent—VS Code’s vassal, REPL’s rapture. Zaks’ zest: Mojo’s mirthful meld, where whimsy weds wattage, inviting idiomatic idioms.
In finale, Zaks flung a flourish: browser beckons at mojo.modular.com—forge futures, unfettered.