Recent Posts
Archives

Posts Tagged ‘DevoxxFR’

PostHeaderIcon [DevoxxFR2026] Invisible Disabilities: Making Meetings Accessible Starts with Simple Practices (and AI Helps)

Lecturer

Anaïs Moulin is a Product Owner at Ippon Technologies with nearly five years of experience. As a person with hearing impairment, she brings firsthand insight into accessibility challenges in professional environments and advocates for inclusive practices using both human-centered approaches and AI tools.

Abstract

Meetings that drag on, lost information, and mental fatigue affect many participants, particularly those with invisible disabilities. Anaïs Moulin shares immediately applicable techniques for making daily standups, team meetings, and conferences more accessible. Combining proven facilitation methods with AI-powered tools for transcription, subtitling, and summarization, she demonstrates how small adjustments significantly improve inclusion and productivity. Based on her experience as a hearing-impaired Product Owner, the talk illustrates that accessibility enhances overall meeting quality for everyone.

The Prevalence and Impact of Invisible Disabilities in Professional Settings

According to French disability statistics, over nine million people live with invisible disabilities—one in seven individuals. These include sensory impairments, neurodivergence, chronic illnesses, and more. In workplace meetings, participants frequently encounter barriers: information delivered solely verbally, poor acoustics in open spaces, lack of visual aids, and insufficient opportunities for alternative participation.

Such obstacles lead to missed details, increased cognitive load, stress, and disengagement. The problem extends beyond those with diagnosed conditions—fatigue, language barriers, or suboptimal environments affect broad audiences. Making meetings inclusive benefits the entire team by improving information retention and collective understanding.

Common Obstacles in Everyday Meetings

Verbal-only delivery of critical information poses immediate challenges for hearing-impaired individuals and those with different memory preferences. Noisy environments, such as open-plan offices with adjacent meeting rooms, compound difficulties in focusing and comprehending speech. The absence of real-time tools for following discussions—chat, transcription, or shared visuals—further excludes participants. Finally, dominant speaking patterns that fail to include everyone reduce engagement and motivation.

These issues are not insurmountable. Simple, low-effort changes can transform meeting dynamics.

Actionable Checklist for Inclusive Meetings

Preparation forms the foundation. Sharing agendas, objectives, and supporting documents in advance allows participants to familiarize themselves with content and arrive mentally ready. Visual supports—shared backlogs, diagrams, or live demonstrations—provide reference points that complement verbal explanations.

During meetings, structured speaking turns ensure everyone has opportunities to contribute. Speakers should maintain a moderate pace, clear articulation, and direct engagement with all attendees. Offering alternatives to verbal participation, such as chat contributions or emoji reactions, accommodates different comfort levels.

Technical setup matters significantly. Ensure quality microphones, proper camera positioning for lip-reading support, and reliable audio sources. Post-meeting summaries with action items create a shared record, reducing reliance on real-time comprehension alone.

These practices require minimal additional effort yet yield substantial improvements in clarity and inclusion.

Leveraging AI Tools to Enhance Accessibility

Modern AI capabilities remove many traditional barriers without significant overhead. Platforms like Microsoft Teams and Google Meet offer real-time subtitling that aids comprehension in noisy or multilingual settings. Transcription features in tools such as Notion or dedicated services capture discussions for later review.

NotebookLM enables users to upload meeting recordings or documents and generate concise summaries or even podcast-style explanations tailored to specific needs. Large language models can challenge draft summaries for completeness or suggest overlooked discussion angles.

These tools complement human practices rather than replace them. For instance, combining live subtitling with visual agendas creates multiple pathways to the same information.

Broader Applications and Measurable Benefits

The same principles apply beyond internal meetings to conferences and external presentations: clear slides, subtitles, moderated pacing, and interaction opportunities. Teams adopting these approaches report faster alignment, fewer misunderstandings, and higher overall productivity.

Accessibility should be considered from project inception, involving product owners, designers, developers, and testers. Treating it as an afterthought increases costs and reduces effectiveness. When implemented thoughtfully, inclusive practices benefit not only those with disabilities but enhance communication for the entire organization.

Conclusion

Creating accessible meetings requires neither complex overhauls nor specialized expertise. Through preparation, mindful facilitation, visual supports, and strategic use of AI assistance, teams can foster environments where information flows effectively to everyone. Small, consistent adjustments compound into significant improvements in collaboration quality and inclusivity. As remote and hybrid work persists, these practices become essential components of effective teamwork.

Links:

PostHeaderIcon [DevoxxFR2026] GitHub Actions as a Supply Chain Security Time Bomb: Real-World Attacks and Defensive Strategies

Lecturer

Thierry Abalea is the co-founder and CEO of Shipfox, a French AI Factory platform specializing in coding agent workflows. With a background in software development and security, he focuses on practical approaches to securing modern CI/CD pipelines in cloud-native environments.

Abstract

GitHub Actions has become a cornerstone of modern CI/CD practices, yet it remains insecure by default. Recent supply chain attacks such as those targeting tj-actions, s1ngularity, GhostAction, and Shai-Hulud have demonstrated how adversaries systematically exploit workflows to exfiltrate secrets and compromise downstream projects. This presentation dissects concrete attack vectors observed in 2025, explains why traditional mitigations fall short, and outlines actionable defenses including scoped secrets with approval workflows, minimal GITHUB_TOKEN permissions, egress controls, runner hardening, and runtime protection tools. Attendees gain a clear understanding of the current threat landscape and practical steps to secure their pipelines.

The Critical Role and Inherent Risks of CI/CD in Modern Development

Continuous integration and continuous deployment pipelines manage extraordinarily sensitive assets: source code manipulation, secret handling for production access, and package publishing. Any compromise here can lead to widespread downstream damage. Thierry Abalea emphasizes that while GitHub Actions provides powerful automation, its permissive default configuration creates a vast attack surface. Workflows often run with broad permissions, handle long-lived secrets, and interact with external networks without sufficient restrictions.

The 2025 attack wave—including Singularity targeting Nx builds, Shai-Hulud as the first npm-propagating worm, and multiple incidents against Trivy—highlighted how GitHub Actions serves as both an entry point for initial compromise and a vector for secret exfiltration and lateral movement. These incidents affected hundreds of organizations, underscoring that CI/CD security can no longer be treated as secondary to application security.

Dissecting Major Supply Chain Attacks via GitHub Actions

Several high-profile incidents illustrate common exploitation patterns. The Singularity attack combined batch injection vulnerabilities in pull request workflows with the pull_request_target trigger. This allowed attackers to exfiltrate secrets from forked repositories, including NPM tokens used to publish malicious packages. Downstream consumers of the compromised Nx tool were subsequently affected.

Shai-Hulud represented a novel worm-like propagation through npm. Attackers gained secrets via similar workflow vulnerabilities, published malicious packages, and leveraged maintainer permissions across multiple projects. This created cascading compromises as infected packages spread through dependency trees.

Trivy, a widely used open-source security scanner, suffered repeated attacks. Initial exploitation via pull_request_target and unsafe interpolation led to remote code execution, secret exfiltration (including high-privilege GITHUB_TOKENs), repository privatization, and deletion of releases. A follow-up attack succeeded due to incomplete secret rotation, enabling further malicious package publications.

These cases reveal recurring themes: overly permissive triggers, secret exposure in workflows, and insufficient isolation between CI environments and production assets.

Why Default GitHub Actions Security Falls Short

GitHub Actions operates with broad defaults that favor convenience over security. Workflows can trigger on untrusted events like pull_request_target, granting access to repository secrets. The GITHUB_TOKEN often possesses excessive permissions, especially in repositories created before 2023. Actions referenced by mutable tags (e.g., v3) can be hijacked by attackers controlling upstream repositories. Self-hosted runners, if not properly isolated, allow one compromised job to affect the entire machine.

Network egress remains largely unrestricted, enabling easy data exfiltration to attacker-controlled servers or even private repositories. Traditional advice—pinning actions and limiting secrets—proves insufficient against sophisticated chained exploits.

Practical Defenses: Hardening GitHub Actions Workflows

Effective protection requires a defense-in-depth approach. Begin by scoping secrets with approval rules, ensuring only necessary workflows can access them. Minimize GITHUB_TOKEN permissions on a per-workflow basis, adhering to the principle of least privilege. Implement egress controls to restrict outbound connections from runners.

For self-hosted runners, enforce ephemeral instances and strong isolation. Tools like Step Security provide runtime hardening and firewall-like controls around runners, while GitHub’s upcoming Level 7 runner protections promise kernel-level isolation outside the runner’s reach.

Static analysis tools such as CodeQL (free for open source) and Zizmor detect workflow vulnerabilities. Dependency review bots help manage pinned versions. Organizations should treat CI/CD as production-equivalent, applying the same scrutiny to workflows as to application code.

Runtime protections and regular secret rotation further reduce the blast radius of potential breaches. Automation of security scanning within pull requests ensures issues are caught early.

Conclusion: Treating CI/CD as Production Infrastructure

GitHub Actions represents both a productivity powerhouse and a significant supply chain risk. By understanding real attack patterns and implementing layered defenses—from minimal permissions and scoped secrets to runtime controls and automated analysis—teams can substantially reduce their exposure. Security must be integrated from the outset of workflow design rather than bolted on afterward. As attackers increasingly target the CI layer, proactive hardening becomes essential for maintaining trust in modern software delivery pipelines.

Links:

PostHeaderIcon [DevoxxFR2026] Common Expression Language (CEL): A Fast, Portable, and Secure Expression Language for Modern Applications

Lecturer

Alex Snaps is a Tech Lead at Red Hat working on the Quarkus project. He maintains the Rust implementation of CEL and contributes to the broader ecosystem, bringing deep expertise in language runtimes, performance, and secure extensibility.

Abstract

Alex Snaps introduces the Common Expression Language (CEL), a domain-agnostic expression language designed for safe, high-performance evaluation within larger applications. Originating from Google, CEL emphasizes strong typing, sandboxed execution, and extensibility while maintaining portability across implementations in Go, Java, C++, Rust, and others. Through syntax exploration, type checking, cost estimation, and practical integration examples, the talk demonstrates why CEL excels for policy enforcement, validation, filtering, and authorization in cloud-native and API-driven environments.

Origins and Design Philosophy of CEL

CEL emerged from Google’s need for a lightweight, embeddable expression evaluator capable of running safely in performance-critical paths. First released around 2017 (with earlier internal variants), it targets scenarios where user-provided or configuration-driven logic must execute with predictable latency and strict safety guarantees. Unlike general-purpose scripting languages, CEL deliberately restricts Turing-completeness to prevent denial-of-service through infinite loops or excessive computation.

Core tenets include:

  • Strong Static Typing: All expressions are type-checked before evaluation.
  • Predictable Performance: Cost estimation and constant folding occur at check time.
  • Portability: Abstract Syntax Tree (AST) format enables cross-language evaluation.
  • Extensibility: Custom functions, macros, and types can be added per domain.

These properties make CEL ideal for Kubernetes (Custom Resource Definition validation), API gateways, authorization systems, and configuration engines.

Syntax and Core Language Features

CEL syntax resembles a blend of C-style expressions and modern collection comprehensions. Basic operations, conditionals, and field access feel familiar:

  • Arithmetic and comparisons
  • Logical operators
  • Ternary expressions
  • Optional chaining with ? and or
  • Collection operations via macros like exists, all, map

Notable features include:

  • Macros: all(resources, r, r.startsWith('email')) binds variables and applies predicates.
  • Optional Navigation: obj.?field.or(0) safely accesses potentially absent fields.
  • Message Construction: Direct construction of Protocol Buffer messages within expressions.
  • Strict Typing: No implicit coercion; uint(1) == 1 fails type checking.

The language integrates seamlessly with Protocol Buffers, treating well-known types like timestamps and durations as first-class citizens.

The Evaluation Pipeline: Parse, Check, Evaluate

CEL processing follows a clear separation optimized for control-plane versus data-plane workloads:

  1. Parse: Validates syntax and produces an AST. Feature flags can disable risky syntax (e.g., optional navigation).
  2. Check: Performs type resolution, overload selection, constant folding, and cost estimation. This phase catches errors early and enables optimization.
  3. Evaluate: Executes the (potentially optimized) AST against a bound environment in the hot path.

Environments declare variables and functions available to expressions. Cost limits prevent expensive evaluations in production.

Portability shines here: an AST checked in one language can be evaluated in another, facilitating polyglot systems.

Extensibility and Real-World Integration

CEL’s power emerges through domain-specific extensions. Custom functions, member overloads, and macros allow tailoring to specific needs without compromising safety.

In the Quarkus/Gateway API context, CEL evaluates policies attached to Kubernetes resources. Expressions navigate complex object graphs, enforce authorization, and implement fine-grained controls. The Rust implementation (maintained by Snaps) demonstrates low-level integration, including trait-based value handling and flexible indexing.

Examples illustrate adding domain functions like isPrime or complex policy logic matching gateways and routes.

Performance, Security, and Ecosystem Maturity

CEL achieves high performance through ahead-of-time type checking, constant folding, and minimal runtime overhead. Implementations in Go and Java (reference) are mature; Rust and others continue evolving toward full specification compliance.

Security model emphasizes sandboxing: no arbitrary code execution, bounded computation, and explicit environment control. This makes CEL suitable for untrusted user input in API filters, validation rules, and authorization decisions.

The ecosystem includes playgrounds, conformance test suites, and codelabs across languages, lowering the barrier to adoption.

Conclusion

Common Expression Language offers a compelling balance of expressiveness, safety, and speed for embedding dynamic logic in applications. Its strong typing, cost awareness, and extensibility address real challenges in cloud-native policy and configuration management. As organizations seek safer alternatives to full scripting engines, CEL provides a mature, battle-tested solution that continues gaining traction across diverse technology stacks.

Links:

PostHeaderIcon [DevoxxFR2026] Evolution of Linux I/O APIs: From poll to io_uring

Lecturers

Youssef Nait Belkacem is a Java developer with a strong interest in low-level systems and performance optimization. Jean-Eudes Couignoux brings extensive experience as a Java and DevOps consultant, with a deep passion for Linux internals and system programming.

Abstract

Youssef Nait Belkacem and Jean-Eudes Couignoux guide the audience through the historical progression of Linux input/output APIs, illustrating how each generation addressed limitations of its predecessors in handling high-concurrency network and file operations. Beginning with basic blocking models and advancing through multiplexing interfaces like poll and epoll, the talk culminates in the revolutionary io_uring subsystem. Through practical coding examples centered on socket handling, performance benchmarks, and Java integration, the presenters reveal fundamental shifts in kernel-user space interaction, memory management, and asynchronous processing that power modern scalable applications.

The Challenge of High-Concurrency I/O in Modern Systems

Contemporary applications, from social networks to real-time collaboration platforms, demand the ability to manage thousands of concurrent connections efficiently. Early web architectures relied on simplistic request-response patterns, but today’s interactive experiences require persistent connections and rapid data exchange. A single server handling 10,000 simultaneous clients cannot afford per-connection operating system threads due to prohibitive memory consumption and context-switching overhead.

Linux’s “everything is a file” philosophy provides a unifying abstraction: sockets, files, timers, signals, and more are represented by file descriptors—integer handles managed by the kernel. This Virtual File System (VFS) layer allows uniform operations like read and write across diverse resources. However, naive implementations quickly encounter performance walls, necessitating increasingly sophisticated notification and completion mechanisms.

Blocking I/O and the Limitations of Synchronous Models

Initial implementations used blocking I/O, where operations like accept, read, or write would halt the calling thread until completion. While simple, this approach fails under load: a thread blocked waiting for one client cannot accept new connections. Non-blocking sockets mitigate this by returning immediately if data is unavailable, but require constant polling in a tight loop. This leads to 100% CPU utilization as the process repeatedly checks descriptors with no work to do.

Performance measurements on such a model reveal exponential degradation. With increasing numbers of open connections, median response times for new requests rise dramatically due to the linear scan of the descriptor list in each iteration. High volatility and resource waste make this unsuitable for production.

poll and the Introduction of Multiplexing

The POSIX-compatible poll (and its predecessor select) introduced kernel-assisted multiplexing. Instead of busy-waiting, applications register a list of file descriptors and block until the kernel reports activity on any of them. This dramatically reduces CPU usage during idle periods.

Implementation involves creating a listener socket, accepting connections to obtain new descriptors, and maintaining an array passed to poll on each iteration. While an improvement, poll still suffers from scalability issues:

  • The entire descriptor list must be re-registered with the kernel on every call.
  • User-space to kernel-space copying of large arrays occurs repeatedly.
  • Linear traversal of results remains necessary.

Benchmarks show linear but steadily increasing latency as connection counts grow, confirming O(n) behavior in registration and processing phases.

epoll: Event-Driven Efficiency in the Kernel

Linux’s epoll addresses poll’s shortcomings through a more stateful, incremental model. An epoll instance (created via epoll_create) maintains a kernel-side interest list. Applications add or remove descriptors once using epoll_ctl, then block on epoll_wait to receive only active events.

This design minimizes data copying and eliminates repeated full-list traversals. The kernel tracks state internally, notifying user space solely for relevant changes. Performance graphs demonstrate near-constant response times regardless of concurrent connection volume, fulfilling the C10K challenge effectively. Most modern application servers, including those in the Java ecosystem via NIO selectors, leverage epoll under the hood.

io_uring: A Paradigm Shift to Asynchronous Submission and Completion

Introduced in 2019, io_uring represents a fundamental rethinking of I/O. It bypasses traditional VFS read/write paths in favor of a double-queue architecture: a submission queue (SQ) for commands and a completion queue (CQ) for results. Applications prepare operations (accept, read, write, etc.) directly into shared ring buffers, minimizing system calls and eliminating unnecessary memory copies through pre-registered buffers.

Key innovations include:

  • Shared Buffers: User-space and kernel access the same memory regions.
  • Batching: Multiple operations can be submitted and completed in batches.
  • Linkage and Chaining: Dependent operations can be linked for sequential execution without intermediate round-trips.
  • Asynchronous Model: Submission is fire-and-forget; completion is polled or waited upon separately.

Code examples reveal a more complex but powerful API compared to predecessors. While requiring careful management of user data for correlating submissions and completions, the reduction in context switches and copies yields significant gains. Filesystem benchmarks, notably in PostgreSQL, show up to 6x improvements in write throughput after io_uring integration.

Java Integration and Broader Implications

The Java ecosystem has embraced io_uring through Project Loom and Netty 4.2+, with frameworks like Quarkus, Micronaut, and Vert.x offering configuration flags for its activation. While the programming model demands greater rigor around state management, the performance benefits are compelling for high-throughput services.

Security considerations remain important; as a relatively new interface, io_uring continues to undergo hardening against potential exploits. Nevertheless, its adoption signals a new era of efficient, low-overhead asynchronous I/O in Linux.

Conclusion

The journey from blocking I/O through poll, epoll, and finally io_uring illustrates Linux’s continuous evolution toward handling massive concurrency with minimal overhead. Each advancement reduced user-kernel transitions, optimized memory movement, and pushed more intelligence into the kernel. Understanding this progression equips developers to make informed architectural choices and appreciate the low-level foundations powering today’s scalable applications.

Links:

PostHeaderIcon [DevoxxFR 2025] Be More Productive with IntelliJ IDEA

Presented by Marit van Dijk (JetBrains)

IntelliJ IDEA is renowned for being a powerful and intelligent Integrated Development Environment (IDE) designed to help developers stay in the flow and maximize their productivity. With its rich set of features, including a smart editor, powerful refactorings, seamless navigation, and integrated tools for various technologies, IntelliJ IDEA aims to provide a comprehensive development experience without the need to leave the IDE. Marit van Dijk from JetBrains showcases how to leverage these capabilities to become a happier and more productive developer.

Marit’s talk delves into the myriad of features that contribute to developer productivity in IntelliJ IDEA. She highlights how the IDE supports various workflows and provides tools for everything from writing and reading code to debugging, testing, and working with databases and version control systems.

Staying in the Flow with a Smart IDE

Maintaining focus and staying in the “flow state” is crucial for developer productivity. Frequent context switching, interruptions, and wrestling with inefficient tools can easily break this flow. Marit van Dijk emphasizes that IntelliJ IDEA is designed to minimize these distractions and help developers stay focused on writing code.

She showcases the IDE’s intelligent code editor, which provides smart code completion, code analysis, and quick fixes. Features like intention actions and context-aware suggestions help developers write code more efficiently and accurately, reducing the need to manually search for syntax or API usage.

Powerful Refactorings and Navigation

Refactoring code is an essential part of maintaining code quality and improving the design of an application. IntelliJ IDEA offers a wide range of powerful automated refactorings that can significantly speed up this process and reduce the risk of introducing errors. Marit demonstrates some of the most useful refactorings, such as renaming variables or methods, extracting methods or interfaces, and changing method signatures.

Seamless navigation within a codebase is also critical for understanding existing code and quickly jumping between different parts of the project. Marit highlights IntelliJ IDEA’s navigation features, such as jumping to declarations or usages, navigating through recent files and locations, and searching for symbols or files by name. These features allow developers to explore their codebase efficiently and find the information they need quickly.

Integrated Tools for a Comprehensive Workflow

Modern software development involves working with a variety of tools and technologies beyond just the code editor. IntelliJ IDEA integrates with a wide range of popular tools, providing a unified experience within the IDE. Marit van Dijk showcases how IntelliJ IDEA seamlessly integrates with:

  • Build Tools: Maven and Gradle for managing project dependencies and building applications.
  • Version Control Systems: Git and others for managing code changes and collaborating with team members.
  • Databases: Tools for connecting to databases, Browse schemas, writing and executing queries, and managing data.
  • Test Tools: Integration with testing frameworks like JUnit and TestNG for writing, running, and debugging tests.
  • Debugging: A powerful debugger for stepping through code, inspecting variables, and diagnosing issues.

By providing these integrated tools, IntelliJ IDEA allows developers to perform most of their tasks without leaving the IDE, minimizing context switching and improving productivity.

AI-Powered Assistance

In addition to its traditional features, IntelliJ IDEA is also incorporating AI-powered assistance to further enhance developer productivity. Marit touches upon features like the AI Assistant, which can provide code suggestions, generate documentation, and even explain complex code snippets.

She might also mention tools sounding like “Juny”, a coding agent that can perform more complex coding tasks, such as generating boilerplate code or creating prototypes. These AI-powered features aim to automate repetitive tasks and provide developers with intelligent assistance throughout their workflow.

Conclusion: A Happier and More Productive Developer

Marit van Dijk concludes by reinforcing the message that leveraging the features of IntelliJ IDEA can make developers happier and more productive. By providing a smart editor, powerful refactorings, seamless navigation, integrated tools, and AI-powered assistance, the IDE helps developers stay in the flow, write better code, and focus on delivering value.

The talk encourages developers to explore the full potential of IntelliJ IDEA and customize it to fit their specific workflows. By making the most of the IDE’s capabilities, developers can significantly improve their efficiency and enjoy a more productive and fulfilling coding experience.

 

Hashtags: #DevoxxFR2025 #IntelliJIDEA #IDE #DeveloperProductivity #Java #Coding #Refactoring #Debugging #AI #JetBrains #MaritvanDijk

 

PostHeaderIcon (temporary testing) Mapping pages

PostHeaderIcon [DevoxxFR 2024] Debugging Your Salary: Winning Strategies for Successful Negotiation

At Devoxx France 2024, Shirley Almosni Chiche, an independent IT recruiter and career agent, delivered a dynamic session titled “Debuggez votre salaire ! Mes stratégies gagnantes pour réussir sa négociation salariale.” With over a decade of recruitment experience, Shirley unpacked the complexities of salary negotiation, offering actionable strategies to overcome common obstacles. Through humor, personas, and real-world insights, she empowered developers to approach salary discussions with confidence and preparation, transforming a daunting process into a strategic opportunity.

Shirley opened with a candid acknowledgment: salary discussions are fraught with tension, myths, and frustrations. Drawing from her role at Build RH, her recruitment firm, she likened salary negotiation to a high-stakes race, where candidates endure lengthy recruitment processes only to face disappointing offers. Common employer excuses—“we must follow the salary grid,” “we can’t pay more than existing staff,” or “the budget is tight”—often derail negotiations, leaving candidates feeling undervalued.

To frame her approach, Shirley introduced six “bugs” that justify low salaries, each paired with a persona representing typical employer archetypes. These included the rigid “Big Corp” manager enforcing salary grids, the team-focused “Didier Deschamps” avoiding pay disparities, and the budget-conscious “François Damiens” citing financial constraints. Other personas, like the overly technical “Elon” scrutinizing code, the relentless negotiator “Patrick,” and the discriminatory “Hubert,” highlighted diverse challenges candidates face.

Shirley shared market insights, noting a 2023–2024 tech slowdown with 200,000 global layoffs, reduced venture funding, and a shift toward cost-conscious industries like banking and retail. This context, she argued, demands strategic preparation to secure fair compensation.

Countering the Bugs: Tactical Responses

For each bug, Shirley offered counter-arguments rooted in empathy and alignment with employer priorities. Against the salary grid, she advised exploring non-salary benefits like profit-sharing or PERCO plans, common in large firms. Using a “mirror empathy” tactic, candidates can frame salary needs in the employer’s language—e.g., linking pay to productivity. Challenging outdated grids by highlighting market research or internal surveys also strengthens arguments.

For the “Didier Deschamps” persona, Shirley suggested emphasizing unique skills (e.g., full-stack expertise in a backend-heavy team) to justify higher pay without disrupting team cohesion. Proposing contributions like speaking at conferences or aiding recruitment can further demonstrate value. She shared a success story where a candidate engaged the team directly, securing a better offer through collective dialogue.

When facing “François Damiens” and financial constraints, Shirley recommended focusing on risk mitigation. For startups, candidates can negotiate stock options or bonuses, arguing that their expertise accelerates product delivery, saving recruitment costs. Highlighting polyvalence—combining skills like development, data, and security—positions candidates as multi-role assets, justifying premium pay.

For technical critiques from “Elon,” Shirley urged immediate feedback post-interview to address perceived weaknesses. If gaps exist, candidates should negotiate training opportunities to ensure long-term fit. Pointing out evaluation mismatches (e.g., testing frontend skills for a backend role) can redirect discussions to relevant strengths.

Against “Patrick,” the negotiator, Shirley advised setting firm boundaries—two rounds of negotiation max—to avoid endless haggling. Highlighting project flaws tactfully and aligning expertise with business goals can shift the dynamic from adversarial to collaborative.

Addressing Discrimination: A Sobering Reality

Shirley tackled the “Hubert” persona, representing discriminatory practices, with nuance. Beyond gender pay gaps, she highlighted biases against older candidates, neurodivergent individuals, those with disabilities, and career switchers. Citing her mother’s experience as a Maghrebi woman facing a 20% pay cut, Shirley acknowledged the harsh realities for marginalized groups.

Rather than dismissing discriminatory offers outright, she advised viewing them as career stepping stones. Candidates can leverage such roles for training or experience, using “mirror empathy” to negotiate non-salary benefits like remote work or learning opportunities. While acknowledging privilege, Shirley urged resilience, encouraging candidates to “lend an ear to learning” and rebound from setbacks.

Mastering Preparation: Anticipating the Negotiation

Shirley emphasized proactive preparation as the cornerstone of successful negotiation. Understanding one’s relationship with money—shaped by upbringing, traumas, or social pressures—is critical. Some candidates undervalue themselves due to impostor syndrome, while others see salary as a status symbol or family lifeline. Recognizing these drivers informs negotiation strategies.

She outlined key preparation steps:

  • Job Selection: Target roles within your expertise and in high-paying sectors (e.g., cloud, security) for better leverage. Data roles can yield 7–13% salary gains.
  • Market Research: Use resources like Choose Your Boss or APEC barometers to benchmark salaries. Shirley noted Île-de-France salaries exceed regional ones by 10–15K, with a 70K ceiling for seniors in 2023.
  • Company Analysis: Assess financial health via LinkedIn or job ad longevity. Long-posted roles signal negotiation flexibility.
  • Recruiter Engagement: Treat initial recruiter calls as data-gathering opportunities, probing team culture, hiring urgency, and technical expectations.
  • Value Proposition: Highlight impact—product roadmaps, technical migrations, or team mentoring—early in interviews to set a premium tone.

Shirley cautioned against oversharing personal financial details (e.g., current salary or expenses) during salary discussions. Instead, provide a specific range (e.g., “around 72K”) based on market data and role demands. Mentioning parallel offers tactfully can spur employers to act swiftly.

Sealing the Deal: Confidence and Coherence

In the final negotiation phase, Shirley advised a 48-hour reflection period after receiving an offer, consulting trusted peers for perspective. Counteroffers should be fact-based, reiterating interview insights and using empathetic language. Timing matters—avoid Mondays or late Fridays for discussions.

Citing APEC data, Shirley noted that 80% of executives who negotiate are satisfied, with 65% securing their target salary or higher. She urged candidates to remain consistent, avoiding last-minute demands that erode trust. Beyond salary, consider workplace culture, inclusion, and work-life balance to ensure long-term fit.

Shirley closed with a rallying call: don’t undervalue your skills or settle for less. By blending preparation, empathy, and resilience, candidates can debug their salary negotiations and secure rewarding outcomes.

Hashtags: #SalaryNegotiation #DevoxxFrance #CareerDevelopment #TechRecruitment

PostHeaderIcon [DevoxxFR 2024] Staff Engineer: A Vital Role in Technical Leadership

My former estimated colleague François Nollen, a technical expert at SNCF Connect & Tech, delivered an engaging talk at Devoxx France 2024 on the role of the Staff Engineer. Often overshadowed by the more familiar Engineering Manager position, the Staff Engineer role is gaining traction as a critical path for technical leadership without management responsibilities. François shared his journey and insights into how Staff Engineers operate at SNCF Connect, offering a blueprint for developers aspiring to influence organizations at scale. This post explores the role’s responsibilities, its impact, and its relevance in modern tech organizations.

Defining the Staff Engineer Role

The Staff Engineer role, rooted in Silicon Valley’s tech giants, represents a senior technical contributor who drives impact across multiple teams without managing them directly. François described Staff Engineers as versatile problem-solvers, blending deep technical expertise with strong collaboration skills. Unlike Engineering Managers, who focus on team management, Staff Engineers tackle complex technical challenges, set standards, and foster innovation. At SNCF Connect, they are called “Technical Expertise Referents,” reflecting their role in guiding technical strategy and mentoring teams.

A Day in the Life

Staff Engineers at SNCF Connect enjoy significant autonomy, with no fixed daily tasks. François outlined a typical day, which begins with monitoring communication channels like Slack to identify team challenges. They contribute code, conduct reviews, and drive strategic initiatives, such as defining best practices or evaluating technical risks. Unlike team-bound developers, Staff Engineers operate at an organizational level, collaborating with engineering, HR, and communication teams to align technical and business goals. This broad scope requires a balance of technical depth and interpersonal finesse.

Impact and Collaboration

The influence of a Staff Engineer stems from their expertise and ability to inspire trust, not formal authority. François highlighted their role in unblocking teams, accelerating projects, and shaping technical strategy alongside Principal Engineers. At SNCF Connect, Staff Engineers work as a collective, amplifying their impact on cross-cutting initiatives like DevOps and continuous delivery. This collaborative approach contrasts with traditional roles like architects, who may be disconnected from delivery, making Staff Engineers integral to dynamic, agile environments.

Is It Right for You?

François posed a reflective question: is the Staff Engineer role suited for everyone? It demands extensive technical experience, organizational awareness, and strong communication skills. Developers who thrive on solving complex problems, mentoring others, and driving systemic change without managing teams may find this path rewarding. For organizations, Staff Engineers offer a framework to retain and empower experienced developers, avoiding the pitfalls of promoting them into unsuitable management roles, as per the Peter Principle.

Hashtags: #StaffEngineer #TechnicalLeadership #DevoxxFrance #FrançoisNollen #SNCFConnect #Engineering #Agile

PostHeaderIcon [DevoxxFR 2024] Going AOT: Mastering GraalVM for Java Applications

Alina Yurenko 🇺🇦 , a developer advocate at Oracle Labs, captivated audiences at Devoxx France 2024 with her deep dive into GraalVM’s ahead-of-time (AOT) compilation for Java applications. With a passion for open-source and community engagement, Alina explored how GraalVM’s Native Image transforms Java applications into compact, high-performance native executables, ideal for cloud environments. Through demos and practical guidance, she addressed building, testing, and optimizing GraalVM applications, debunking myths and showcasing its potential. This post unpacks Alina’s insights, offering a roadmap for adopting GraalVM in production.

GraalVM and Native Image Fundamentals

Alina introduced GraalVM as both a high-performance JDK and a platform for AOT compilation via Native Image. Unlike traditional JVMs, GraalVM allows developers to run Java applications conventionally or compile them into standalone native executables that don’t require a JVM at runtime. This dual capability, built on over a decade of research at Oracle Labs, offers Java’s developer productivity alongside native performance benefits like faster startup and lower resource usage. Native Image, GA since 2019, analyzes an application’s bytecode at build time, identifying reachable code and dependencies to produce a compact executable, eliminating unused code and pre-populating the heap for instant startup.

The closed-world assumption underpins this process: all application behavior must be known at build time, unlike the JVM’s dynamic runtime optimizations. This enables aggressive optimizations but requires careful handling of dynamic features like reflection. Alina demonstrated this with a Spring Boot application, which started in 1.3 seconds on GraalVM’s JVM but just 47 milliseconds as a native executable, highlighting its suitability for serverless and microservices where startup speed is critical.

Benefits Beyond Startup Speed

While fast startup is a hallmark of Native Image, Alina emphasized its broader advantages, especially for long-running applications. By shifting compilation, class loading, and optimization to build time, Native Image reduces runtime CPU and memory usage, offering predictable performance without the JVM’s warm-up phase. A Spring Pet Clinic benchmark showed Native Image matching or slightly surpassing the JVM’s C2 compiler in peak throughput, a testament to two years of optimization efforts. For memory-constrained environments, Native Image excels, delivering up to 2–3x higher throughput per memory unit at heap sizes of 512MB to 1GB, as seen in throughput density charts.

Security is another benefit. By excluding unused code, Native Image reduces the attack surface, and dynamic features like reflection require explicit allow-lists, enhancing control. Alina also noted compatibility with modern Java frameworks like Spring Boot, Micronaut, and Quarkus, which integrate Native Image support, and a community-maintained list of compatible libraries on the GraalVM website, ensuring broad ecosystem support.

Building and Testing GraalVM Applications

Alina provided a practical guide for building and testing GraalVM applications. Using a Spring Boot demo, she showcased the Native Maven plugin, which streamlines compilation. The build process, while resource-intensive for large applications, typically stays within 2GB of memory for smaller apps, making it viable on CI/CD systems like GitHub Actions. She recommended developing and testing on the JVM, compiling to Native Image only when adding dependencies or in CI/CD pipelines, to balance efficiency and validation.

Dynamic features like reflection pose challenges, but Alina outlined solutions: predictable reflection works out-of-the-box, while complex cases may require JSON configuration files, often provided by frameworks or libraries like H2. A centralized GitHub repository hosts configs for popular libraries, and a tracing agent can generate configs automatically by running the app on the JVM. Testing support is robust, with JUnit and framework-specific tools like Micronaut’s test resources enabling integration tests in Native mode, often leveraging Testcontainers.

Optimizing and Future Directions

To achieve peak performance, Alina recommended profile-guided optimizations (PGO), where an instrumented executable collects runtime profiles to inform a final build, combining AOT’s predictability with JVM-like insights. A built-in ML model predicts profiles for simpler scenarios, offering 6–8% performance gains. Other optimizations include using the G1 garbage collector, enabling machine-specific flags, or building static images for minimal container sizes with distroless images.

Looking ahead, Alina highlighted two ambitious GraalVM projects: Layered Native Images, which pre-compile base images (e.g., JDK or Spring) to reduce build times and resource usage, and GraalOS, a platform for deploying native images without containers, eliminating container overhead. Demos of a LangChain for Java app and a GitHub crawler using Java 22 features showcased GraalVM’s versatility, running seamlessly as native executables. Alina’s session underscored GraalVM’s transformative potential, urging developers to explore its capabilities for modern Java applications.

Links:

Hashtags: #GraalVM #NativeImage #Java #AOT #AlinaYurenko #DevoxxFR2024

PostHeaderIcon [DevoxxFR 2024] Super Tech’Rex World: The Assembler Strikes Back

Nicolas Grohmann, a developer at Sopra Steria, took attendees on a nostalgic journey through low-level programming with his talk, “Super Tech’Rex World: The Assembler Strikes Back.” Over five years, Nicolas modified Super Mario World, a 1990 Super Nintendo Entertainment System (SNES) game coded in assembler, transforming it into a custom adventure featuring a dinosaur named T-Rex. Through live coding and engaging storytelling, he demystified assembler, revealing its principles and practical applications. His session illuminated the inner workings of 1990s consoles while showcasing assembler’s relevance to modern computing.

A Retro Quest Begins

Nicolas opened with a personal anecdote, recounting how his project began in 2018, before Sopra Steria’s Tech Me Up community formed in 2021. He described this period as the “Stone Age” of his journey, marked by trial and error. His goal was to hack Super Mario World, a beloved SNES title, replacing Mario with T-Rex, coins with pixels (a Sopra Steria internal currency), and mushrooms with certifications that boost strength. Enemies became “pirates,” symbolizing digital adversaries.

To set the stage, Nicolas showcased the SNES, a 1990s console with a CPU, ROM, and RAM—components familiar to modern developers. He launched an emulator to demonstrate Super Mario World, highlighting its mechanics: jumping, collecting items, and battling enemies. A modified ROM revealed his custom version, where T-Rex navigated a reimagined world. This demo captivated the audience, blending nostalgia with technical ambition.

For the first two years, Nicolas relied on community tools to tweak graphics and levels, such as replacing Mario’s sprite with T-Rex. However, as a developer, he yearned to contribute original code, prompting him to learn assembler. This shift marked the “Age of Discoveries,” where he tackled the language’s core concepts: machine code, registers, and memory addressing.

Decoding Assembler’s Foundations

Nicolas introduced assembler’s essentials, starting with machine code, the binary language of 0s and 1s that CPUs understand. Grouped into 8-bit bytes (octets), a SNES ROM comprises 1–4 megabytes of such code. He clarified binary and hexadecimal systems, noting that hexadecimal (0–9, A–F) compacts binary for readability. For example, 15 in decimal is 1111 in binary and 0F in hexadecimal, while 255 (all 1s in a byte) is FF.

Next, he explored registers, small memory locations within the CPU, akin to global variables. The accumulator, a key register, stores a single octet for operations, while the program counter tracks the next instruction’s address. These registers enable precise control over a program’s execution.

Memory addressing, Nicolas’s favorite concept, likens SNES memory to a city. Each octet resides in a “house” (address 00–FF), within a “street” (page 00–FF), in a “neighborhood” (bank 00–FF). This structure yields 16 megabytes of addressable memory. Addressing modes—long (full address), absolute (bank preset), and direct page (bank and page preset)—optimize code efficiency. Direct page, limited to 256 addresses, is ideal for game variables, streamlining operations.

Assembler, Nicolas clarified, isn’t a single language but a family of instruction sets tailored to CPU types. Opcodes, mnemonic instructions like LDA (load accumulator) and STA (store accumulator), translate to machine code (e.g., LDA becomes A5 for direct page). These opcodes, combined with addressing modes, form the backbone of assembler programming.

Live Coding: Empowering T-Rex

Nicolas transitioned to live coding, demonstrating assembler’s practical application. His goal: make T-Rex invincible and alter gameplay to challenge pirates. Using Super Mario World’s memory map, a community-curated resource, he targeted address 7E0019, which tracks the player’s state (0 for small, 1 for large). By writing LDA #$01 (load 1) and STA $19 (store to 7E0019), he ensured T-Rex remained large, immune to damage. The # denotes an immediate value, distinguishing it from an address.

To nerf T-Rex’s jump, Nicolas manipulated controller inputs at addresses 7E0015 and 7E0016, which store button states as bitmasks (e.g., the leftmost bit for button B, used for jumping). Using LDA $15 and AND #$7F (bitwise AND with 01111111), he cleared the B button’s bit, disabling jumps while preserving other controls. He applied this to both addresses, ensuring consistency.

To restore button B for firing projectiles, Nicolas used 7E0016, which flags buttons pressed in a single frame. With LDA $16AND #$80 (isolating B’s bit), and BEQ (branch if zero to skip firing), he ensured projectiles spawned only on B’s press. A JSL (jump to subroutine long) invoked a community routine to spawn a custom sprite—a projectile that moves right and destroys enemies.

These demos showcased assembler’s precision, leveraging memory maps and opcodes to reshape gameplay. Nicolas’s iterative approach—testing, tweaking, and re-running—mirrored real-world debugging.

Mastering the Craft: Hooks and the Stack

Reflecting on 2021, the “Modern Age,” Nicolas shared how he mastered code insertion. Since modifying Super Mario World’s original ROM risks corruption, he used hooks—redirects to free memory spaces. A tool inserts custom code at an address like $A00, replacing a segment (e.g., four octets) with a JSL (jump subroutine long) to a hook. The hook preserves original code, jumps to the custom code via JML (jump long), and returns with RTL (return long), seamlessly integrating modifications.

The stack, a RAM region for temporary data, proved crucial. Managed by a stack pointer register, it supports opcodes like PHA (push accumulator) and PLA (pull accumulator). JSL pushes the return address before jumping, and RTL pops it, ensuring correct returns. This mechanism enabled complex routines without disrupting the game’s flow.

Nicolas introduced index registers X and Y, which support opcodes like LDX and STX. Indexed addressing (e.g., LDA $00,X) adds X’s value to an address, enabling dynamic memory access. For example, setting X to 2 and using LDA $00,X accesses address $02.

Conquering the Game and Beyond

In a final demo, Nicolas teleported T-Rex to the game’s credits by checking sprite states. Address 7E14C8 and the next 11 addresses track 12 sprite slots (0 for empty). Using X as a counter, he looped through LDA $14C8,X, branching with BNE (branch if not zero) if a sprite exists, or decrementing X with DEX and looping with BPL (branch if positive). If all slots are empty, a JSR (jump subroutine) triggers the credits, ending the game.

Nicolas concluded with reflections on his five-year journey, likening assembler to a steep but rewarding climb. His game, nearing release on the Super Mario World hacking community’s site, features space battles and a 3D boss, pushing SNES limits. He urged developers to embrace challenging learning paths, emphasizing that persistence yields profound satisfaction.

Hashtags: #Assembler #DevoxxFrance #SuperNintendo #RetroGaming #SopraSteria #LowLevelProgramming