Posts Tagged ‘DevoxxFR’

Introduction

In “Les tests, un investissement pour l’avenir,” presented at Devoxx France 2023, Julien Deniau, a developer at Amadeus, champions software testing as a cornerstone of sustainable development. This 14-minute quickie draws from his work on airline reservation systems, where reliability is non-negotiable. Deniau’s passionate case for testing offers developers practical strategies to ensure code quality while accelerating delivery.

Key Insights

Deniau frames testing as an investment, not a cost, emphasizing its role in preventing regressions and enabling fearless refactoring. At Amadeus, where systems handle billions of transactions annually, comprehensive tests are critical. He outlines a testing pyramid:

• Unit Tests: Fast, isolated tests for individual components, forming the pyramid’s base.

• Integration Tests: Validate interactions between modules, such as APIs and databases.

• End-to-End Tests: Simulate user journeys, used sparingly due to complexity.

Deniau shares a case study of refactoring a booking system, where a robust test suite allowed the team to rewrite critical components without introducing bugs. He advocates for Test-Driven Development (TDD) to clarify requirements before coding and recommends tools like JUnit and Cucumber for Java-based projects. The talk also addresses cultural barriers, such as convincing stakeholders to allocate time for testing, achieved by demonstrating reduced maintenance costs.

Lessons Learned

Deniau’s talk provides key takeaways:

• Test Early, Test Often: Writing tests upfront saves time during debugging and refactoring.

• Balance the Pyramid: Prioritize unit tests for speed, but don’t neglect integration tests.

• Sell Testing: Highlight business benefits, like faster delivery and fewer outages, to gain buy-in.

These insights are crucial for teams in high-stakes industries or those struggling with legacy code. Deniau’s enthusiasm makes testing feel like an empowering tool rather than a chore.

Conclusion

Julien Deniau’s quickie reframes testing as a strategic asset for building reliable, maintainable software. His Amadeus experience underscores the long-term value of a disciplined testing approach. This talk is a must-watch for developers seeking to future-proof their codebases.

Introduction

Julien Topçu, a tech lead at LesFurets, delivers a concise yet powerful Devoxx France 2023 quickie titled “L’architecture hexagonale en 15 minutes.” In this 17-minute talk, Topçu introduces hexagonal architecture (also known as ports and adapters) as a solution for building maintainable, testable systems. Drawing from his experience at LesFurets, a French insurance comparison platform, he provides a practical guide for developers navigating complex codebases.

Key Insights

Topçu explains hexagonal architecture as a way to decouple business logic from external systems, like databases or APIs. At LesFurets, where rapid feature delivery is critical, this approach reduced technical debt and improved testing. The architecture organizes code into:

• Core Business Logic: Pure functions or classes that handle the application’s rules.

• Ports: Interfaces defining interactions with the outside world.

• Adapters: Implementations of ports, such as database connectors or HTTP clients.

Topçu shares a refactoring example, where a tightly coupled insurance quote system was restructured. By isolating business rules in a core module, the team simplified unit testing and swapped out a legacy database without changing the core logic. He highlights tools like Java’s interfaces and Spring’s dependency injection to implement ports and adapters efficiently. The talk also addresses trade-offs, such as the initial overhead of defining ports, balanced by long-term flexibility.

Lessons Learned

Topçu’s insights are actionable:

• Decouple Early: Separating business logic prevents future refactoring pain.

• Testability First: Hexagonal architecture enables comprehensive unit tests without mocks.

• Start Small: Apply the pattern incrementally to avoid overwhelming teams.

These lessons resonate with developers maintaining evolving systems or adopting Domain-Driven Design. Topçu’s clear explanations make hexagonal architecture accessible even to newcomers.

Conclusion

Julien Topçu’s quickie offers a masterclass in hexagonal architecture, proving its value in real-world applications. His LesFurets example shows how to build systems that are robust yet adaptable. This talk is essential for developers aiming to create clean, maintainable codebases.

At Devoxx France 2022, Mathieu Humbert, a tech lead at Accenture with over 15 years of development experience, navigates the complex landscape of HTTP security headers. Mathieu demystifies headers like CSP, HSTS, XFO, and CORS, explaining their role in protecting web applications from threats like XSS, CSRF, and SSRF. Through a clear and engaging presentation, he outlines common attacks, their risks, and how specific headers can mitigate them, concluding with practical tools and resources for implementation.

Understanding HTTP Security Headers

Mathieu begins by introducing HTTP security headers as critical tools for safeguarding web applications. He explains headers like Content Security Policy (CSP), which restricts the sources from which content can be loaded, and HTTP Strict Transport Security (HSTS), which enforces HTTPS connections. These headers, though complex, are essential for mitigating risks in an ever-evolving threat landscape. Mathieu’s experience at Accenture informs his approach, emphasizing that understanding the purpose of each header is key to effective implementation.

By mapping headers to specific threats, Mathieu provides clarity on their practical applications. For instance, Cross-Site Scripting (XSS) attacks, where malicious scripts are injected into web pages, can be mitigated with CSP, while Cross-Site Request Forgery (CSRF) risks are reduced through proper header configurations. His accessible explanations make the technical subject approachable, ensuring developers grasp the importance of these defenses.

Mitigating Common Web Attacks

Delving into specific attacks, Mathieu outlines how headers counter vulnerabilities. He discusses XSS, where attackers exploit input fields to inject harmful code, and CSRF, where unauthorized actions are triggered on behalf of users. Headers like X-Frame-Options (XFO) prevent clickjacking by restricting how pages are framed, while CORS configurations ensure safe cross-origin requests. Mathieu also addresses Server-Side Request Forgery (SSRF), highlighting headers that limit unauthorized server requests.

Through real-world examples, Mathieu illustrates the consequences of neglecting these headers, such as data breaches or session hijacking. He stresses that proactive header implementation can significantly reduce these risks, providing a robust first line of defense for web applications. His insights, drawn from years of tackling technical challenges, underscore the necessity of staying vigilant in a dynamic threat environment.

Practical Implementation and Tools

Mathieu offers actionable guidance for integrating security headers into development workflows. He recommends starting with tools like OWASP’s Security Headers Project, which provides comprehensive documentation for configuring headers effectively. For testing, he suggests platforms like WebGoat, designed to simulate vulnerabilities, allowing developers to practice identifying and fixing issues. Mathieu also highlights the importance of automated scanners, such as Burp Suite, to detect missing or misconfigured headers.

His experience with distributed architectures and agile teams at Accenture informs his practical approach. Mathieu advises incremental implementation, starting with critical headers like HSTS and CSP, and regularly reviewing configurations to adapt to new threats. This methodical strategy ensures that security remains a priority without overwhelming development teams.

Links:

• Accenture company website
• Mathieu Humbert’s blog
• OWASP Security Headers Project

Hashtags: #WebSecurity #HTTPHeaders #Cybersecurity #DevoxxFR2022 #MathieuHumbert #Accenture #OWASP

At Devoxx France 2022, Emmanuel Lécharny, Jean-Baptiste Onofré, and Hervé Boutemy, all active contributors to the Apache Software Foundation, tackle the infamous Log4Shell vulnerability that shook the tech world in December 2021. Their collaborative presentation dissects the origins, causes, and responses to the Log4J security flaw, addressing whether the Apache Foundation bears responsibility. By examining the incident’s impact, the trio provides a transparent analysis of open-source security practices, offering insights into preventing future vulnerabilities and fostering community involvement. Their expertise and candid reflections make this a vital discussion for developers and organizations alike.

Unpacking the Log4Shell Incident

Emmanuel, Jean-Baptiste, and Hervé begin by tracing the history of Log4J and the emergence of Log4Shell, a critical vulnerability that allowed remote code execution, impacting countless systems worldwide. They outline the technical root causes, including flaws in Log4J’s message lookup functionality, which enabled attackers to exploit untrusted inputs. The presenters emphasize the rapid response from the Apache community, which released patches and mitigations under intense pressure, highlighting the challenges of maintaining widely-used open-source libraries.

The session provides a sobering look at the incident’s widespread effects, from internal projects to global enterprises. By sharing a detailed post-mortem, the trio illustrates how Log4Shell exposed vulnerabilities in dependency management, urging organizations to prioritize robust software supply chain practices.

Apache’s Security Practices and Challenges

The presenters delve into the Apache Foundation’s approach to managing Common Vulnerabilities and Exposures (CVEs). They explain that the foundation relies on a small, dedicated group of volunteer committers—often fewer than 15 per project—making comprehensive code reviews challenging. Emmanuel, Jean-Baptiste, and Hervé acknowledge that limited resources and the sheer volume of contributions can create gaps, as seen in Log4Shell. However, they defend the open-source model, noting its transparency and community-driven ethos as strengths that enable rapid response to issues.

They highlight systemic challenges, such as the difficulty of auditing complex codebases and the reliance on volunteer efforts. The trio calls for greater community participation, emphasizing that open-source projects like Apache thrive on collective contributions, which can enhance security and resilience.

Solutions and Future Prevention

To prevent future vulnerabilities, Emmanuel, Jean-Baptiste, and Hervé propose several strategies. They advocate for enhanced code review processes, including automated tools and mandatory audits, to catch issues early. They also discuss the potential for increased funding to support open-source maintenance, noting that financial backing could enable more robust security practices. However, they stress that money alone is insufficient; better organizational structures and community engagement are equally critical.

The presenters highlight emerging regulations, such as those in the U.S. and Europe, that hold software vendors accountable for their dependencies. These laws underscore the need for organizations to actively manage their open-source components, fostering a collaborative relationship between developers and users to ensure security.

Engaging the Community

In their closing remarks, the trio urges developers to become active contributors to open-source projects like Apache. They emphasize that even small contributions, such as reporting issues or participating in code reviews, can significantly enhance project security. Jean-Baptiste, Emmanuel, and Hervé invite attendees to engage with the Apache community, noting that projects like Log4J rely on collective effort to thrive. Their call to action underscores the shared responsibility of securing the open-source ecosystem, making it a compelling invitation for developers to get involved.

Links:

• Apache Software Foundation website

Hashtags: #Log4Shell #OpenSource #Cybersecurity #DevoxxFR2022 #EmmanuelLécharny #JeanBaptisteOnofré #HervéBoutemy #Apache

Do You Really Know JWT? Insights from Devoxx France 2022

Karim Pinchon, a backend developer at Ornikar, delivered an illuminating talk titled “Do You Really Know JWT?” (watch on YouTube). With a decade of experience across Java, PHP, and Go, Karim dives into JSON Web Tokens (JWT), a standard for secure data transfer in authentication and authorization. This session explores JWT’s structure, cryptographic foundations, vulnerabilities, and best practices, moving beyond common usage in OAuth2 and OpenID Connect.

Understanding JWT Structure and Cryptography

Karim begins by demystifying JWT, a compact, secure token for transferring JSON data, often used in HTTP headers for authentication. A JWT comprises three parts—header, payload, and signature—encoded in Base64 and concatenated with dots. The header specifies the cryptographic algorithm (e.g., HMAC, RSA), the payload contains claims (data), and the signature ensures integrity. Karim demonstrates this using jwt.io, showing how decoding reveals JSON objects.

He distinguishes token types: reference tokens (database-backed) and value tokens (self-contained, like JWT). JWT supports two forms: compact (Base64-encoded) and JSON (with additional features like multiple signatures). Karim introduces related standards under JOSE (JSON Object Signing and Encryption), including JWS (signed tokens), JWE (encrypted tokens), JWK (key management), and JWA (algorithms). Cryptographic operations like signing (for integrity) and encryption (for confidentiality) underpin JWT’s security.

Payload Claims and Use Cases

The payload is JWT’s core, divided into three claim types:

• Registered Claims: Standard fields like issuer (iss), audience (aud), expiration (exp), and token ID (jti) for validation.
• Public Claims: Defined by IANA for protocols like OpenID Connect, carrying user data (e.g., name, email) in ID tokens.
• Private Claims: Custom data agreed upon by parties, kept minimal for compactness.

Karim highlights JWT’s versatility in:

• API Authentication: Tokens in Authorization headers validate requests without database lookups.
• OAuth2: Access tokens may be JWTs, carrying authorization data.
• OpenID Connect: ID tokens propagate user identity.
• Stateless Sessions: Storing session data (e.g., e-commerce carts) client-side, enhancing scalability.

He cautions that stateless sessions require careful implementation to avoid complexity.

Security Vulnerabilities and Attacks

Karim dedicates significant time to JWT’s security risks, demonstrating attacks via a PHP library on his GitHub. Common vulnerabilities include:

• Unsecured Tokens: Setting the header’s algorithm to none bypasses signature verification, a flaw exploited in some libraries. Karim shows a test where a modified token passes validation due to this.
• RSA Public Key as Shared Key: An attacker changes the algorithm from RSA to HMAC, using the public key as a shared secret, tricking servers into validating tampered tokens.
• Brute Force: Weak secrets (e.g., “azerty”) are vulnerable to brute-force attacks.
• Encrypted Data Modification: Some encryption algorithms allow payload tampering (e.g., flipping is_admin from false to true) without breaking the cipher.
• Token Substitution: Using a token from one service (where the user is admin) on another without proper audience validation.

Karim emphasizes the JWT paradox: the header, which specifies validation details, can’t be trusted until the token is validated. He attributes these issues to developers’ reliance on unvetted libraries, not poor coding.

Best Practices for Secure JWT Usage

To mitigate risks, Karim offers practical advice:

• Protect Secrets: Use strong, rotated keys. Avoid sharing symmetric keys with external partners; prefer asymmetric keys (e.g., RSA).
• Restrict Algorithms: Servers should only accept predefined algorithms (e.g., one or two), ignoring the header’s alg field.
• Validate Claims: Check iss, aud, and exp to ensure the token’s legitimacy. Reject tokens not intended for your service.
• Use Trusted Libraries: Avoid custom implementations. Modern libraries require explicit algorithm whitelists, reducing none algorithm risks.
• Short Token Lifespans: Minimize revocation needs with short-lived tokens. Avoid external revocation lists, as they undermine JWT’s autonomy.
• Ensure Confidentiality: Since JWS payloads are Base64-encoded (readable), avoid sensitive data. Use JWE for encryption if needed, and transmit over HTTPS.

Karim also mentions alternatives like Biscuits (from Clever Cloud), PASETO, and Google’s Macaroons, which address JWT’s flaws, such as untrusted headers.

Links

• YouTube Video: Do You Really Know JWT?
• Karim Pinchon: LinkedIn, Twitter, GitHub
• Ornikar: Official Website
• JWT: Official Website

Hashtags: #DevoxxFrance #KarimPinchon #JWT #Security #Cryptography #Authentication #Authorization #OAuth2 #OpenIDConnect #JWS #JWE #JWK #Ornikar #PHP #Java

Lors de Devoxx France 2022, David Aparicio, Data Ops chez OVHcloud, a partagé une conférence de 44 minutes sur l’apprentissage à partir des échecs en opérations informatiques. David a analysé les post-mortems d’incidents majeurs survenus chez des géants comme GitHub, Amazon, Google, OVHcloud, Apple, Fastly, Microsoft, GitLab et Facebook. En explorant les causes racines, les remédiations et les bonnes pratiques, il a montré comment tirer des leçons des erreurs pour renforcer la résilience des systèmes. Suivez OVHcloud sur ovhcloud.com et twitter.com/OVHcloud.

Comprendre les post-mortems

David a commencé par expliquer ce qu’est un post-mortem : un document rédigé après un incident pour comprendre ce qui s’est passé, identifier les causes et prévenir les récurrences. Il inclut l’historique de l’incident, les flux d’information, l’organisation (qui a agi, avec quelle équipe), les canaux de communication avec les clients, l’utilisation des ressources et les processus suivis. David a souligné l’importance de la transparence, citant des initiatives comme les meetups de développeurs où les échecs sont partagés pour démystifier les incidents.

Il a illustré son propos avec une histoire fictive d’Elliot, un junior qui, par erreur, supprime une base de données de production en suivant une documentation mal structurée. Cet incident, inspiré de cas réels chez AWS (2017), GitLab et DigitalOcean, montre les dangers d’un accès non contrôlé à la production. David a recommandé des garde-fous comme des approbations manuelles pour les commandes critiques (par exemple, DROP TABLE), des rôles RBAC stricts, et des tests réguliers des backups pour garantir leur fiabilité.

Les incidents personnels : le legacy à l’épreuve

David a partagé une expérience personnelle chez OVHcloud, où il gère le data lake pour répliquer les données internes. Lors d’une astreinte, un week-end d’été, il a été alerté d’un problème sur une infrastructure legacy sans documentation claire. Un service saturait sa file de connexions (1024 clients maximum), provoquant des refus. Sans réponse des développeurs, David a opté pour une solution KISS (Keep It Simple, Stupid) : une sonde vérifiant la connectivité toutes les cinq minutes, redémarrant le service si nécessaire. Ce script, en place depuis un an et demi, a redémarré le service 70 fois, évitant de nouveaux incidents.

Un autre incident concernait une application Java legacy, tombant après 20 à 40 minutes malgré des redémarrages. Les logs montraient des déconnexions ZooKeeper et des crashs JVM. Plutôt que d’ajuster la mémoire (heap tuning), David a découvert un script de nettoyage propriétaire dans l’historique. Appliqué deux fois par semaine, ce script a résolu le problème durablement. Ces cas illustrent l’importance de comprendre le legacy, d’éviter les solutions complexes et de documenter les correctifs.

Les pannes majeures : CDN et réseaux

David a analysé l’incident Fastly de juin 2021, où une erreur 503 a touché des sites comme The Guardian, The New York Times, Amazon, Twitter et la Maison Blanche. La cause : une configuration client déployée sans test le 8 juin, activée par une demande du 12 mai, révélant un point de défaillance unique (SPoF) dans le CDN. Résolu en 45 minutes, cet incident souligne l’importance de tester les changements en pré-production (par exemple, via blue-green deployments ou shadow traffic) et de personnaliser les messages d’erreur pour améliorer l’expérience utilisateur.

Un autre cas marquant est la panne Facebook de septembre 2021, causée par une mise à jour du protocole BGP (Border Gateway Protocol). Les serveurs DNS, incapables d’accéder aux datacenters, se sont mis en mode protection, coupant l’accès à Facebook, Instagram, WhatsApp et même aux outils internes (Messenger, LDAP). Les employés ne pouvaient ni badger ni consulter la documentation, obligeant une intervention physique avec des disqueuses pour accéder aux racks. David a recommandé des TTL (Time To Live) plus longs pour les DNS, des canaux de communication séparés et des routes de secours via d’autres cloud providers.

Bonnes pratiques et culture de l’échec

David a conclu en insistant sur la nécessité de ne pas blâmer les individus, comme dans le cas d’Elliot, mais de renforcer les processus. Il a proposé des tests réguliers de backups, des exercices de chaos engineering (par exemple, simuler une erreur 500 un vendredi après-midi), et l’adoption de pratiques DevSecOps pour intégrer la sécurité dès les tests unitaires. Il a également suggéré de consulter les post-mortems publics (comme ceux de GitLab ou ElasticSearch) pour s’inspirer et d’utiliser des outils comme Terraform pour automatiser les déploiements sécurisés. Enfin, il a encouragé à rejoindre OVHcloud pour expérimenter et apprendre des incidents dans un environnement transparent.

Lors de Devoxx France 2022, Brice Dutheil a présenté une conférence de 28 minutes sur le Projet Panama, une initiative visant à simplifier l’appel de fonctions natives depuis Java sans les complexités de JNI ou de bibliothèques tierces. Brice, contributeur actif à l’écosystème Java, a introduit l’API Foreign Function & Memory (JEP-419), montrant comment elle relie le monde géré de Java au code natif en C, Swift ou Rust. À travers des démonstrations de codage en direct, Brice a illustré le potentiel de Panama pour des intégrations natives fluides. Suivez Brice sur Twitter à twitter.com/Brice_Dutheil pour plus d’insights Java.

Simplifier l’intégration de code natif

Brice a débuté en expliquant la mission du Projet Panama : connecter l’environnement géré de Java, avec son garbage collector, au monde natif de C, Swift ou Rust, plus proche de la machine. Traditionnellement, JNI imposait des étapes laborieuses : écrire des classes wrapper, charger des bibliothèques et générer des headers lors des builds. Ces processus étaient sujets aux erreurs et chronophages. Des alternatives comme JNA et JNR amélioraient l’expérience développeur en générant des bindings au runtime, mais elles étaient plus lentes et moins sécurisées.

Lancé en 2014, le Projet Panama répond à ces défis avec trois composantes : les API vectorielles (non couvertes ici), les appels de fonctions étrangères et la gestion de la mémoire. Brice s’est concentré sur l’API Foreign Function & Memory (JEP-419), disponible en incubation dans JDK 18. Contrairement à JNI, Panama élimine les complexités du build et offre des performances proches du natif sur toutes les plateformes. Il introduit un modèle de sécurité robuste, limitant les opérations dangereuses et envisageant de restreindre JNI dans les futures versions de Java (par exemple, Java 25 pourrait exiger un flag pour activer JNI). Brice a souligné l’utilisation des method handles et des instructions d’invocation dynamique, inspirées des avancées du bytecode JVM, pour générer efficacement des instructions assembleur pour les appels natifs.

Démonstrations pratiques avec Panama

Brice a démontré les capacités de Panama via du codage en direct, commençant par un exemple simple appelant la fonction getpid de la bibliothèque standard C. À l’aide du SystemLinker, il a effectué une recherche de symbole pour localiser getpid, créé un method handle avec un descripteur de fonction définissant la signature (retournant un long Java), et l’a invoqué pour récupérer l’ID du processus. Ce processus a contourné les lourdeurs de JNI, nécessitant seulement quelques lignes de code Java. Brice a insisté sur l’activation de l’accès natif avec le flag –enable-native-access dans JDK 18, renforçant le modèle de sécurité de Panama en limitant l’accès à des modules spécifiques.

Il a ensuite présenté un exemple plus complexe avec la fonction crypto_box de la bibliothèque cryptographique Libsodium, portable sur des plateformes comme Android. Brice a alloué des segments de mémoire avec un ResourceScope et un NativeAllocator, garantissant la sécurité mémoire en libérant automatiquement les ressources après usage, contrairement à JNI qui dépend du garbage collector. Le ResourceScope prévient les fuites mémoire, une amélioration significative par rapport aux buffers natifs traditionnels. Brice a également abordé l’appel de code Swift via des interfaces compatibles C, démontrant la polyvalence de Panama.

Outils et potentiel futur

Brice a introduit jextract, un outil de Panama qui génère des mappings Java à partir de headers C/C++, simplifiant l’intégration de bibliothèques comme Blake3, une fonction de hachage performante écrite en Rust. Dans une démo, il a montré comment jextract créait des bindings compatibles Panama pour les structures de données et fonctions de Blake3, permettant aux développeurs Java de tirer parti des performances natives sans bindings manuels. Malgré quelques accrocs, la démo a souligné le potentiel de Panama pour des intégrations natives transparentes.

Brice a conclu en soulignant les avantages de Panama : simplicité, rapidité, compatibilité multiplateforme et sécurité mémoire renforcée. Il a noté son évolution continue, avec JEP-419 en incubation dans JDK 18 et une deuxième preview prévue pour JDK 19. Pour les développeurs d’applications desktop ou de systèmes critiques, Panama offre une solution puissante pour exploiter des fonctions spécifiques aux OS ou des bibliothèques optimisées comme Libsodium. Brice a encouragé le public à expérimenter Panama et à poser des questions, renforçant son engagement via Twitter.

At Devoxx France 2021, François Mockers, an IoT enthusiast, delivered a 32-minute talk titled IoT open source à la maison (YouTube). This session shared his decade-long journey managing over 300 open-source IoT devices at home, likening home automation to production IT challenges. From connected light bulbs to zoned heating and sunlight-responsive shutters, Mockers explored protocols (ZigBee, Z-Wave, 433MHz, Wi-Fi) and tools (Home Assistant, ESPHome, Node-RED, Ansible, InfluxDB, Grafana). Aligned with Devoxx’s IoT and cloud themes, the talk offered practical insights for developers building cost-effective, secure home automation systems.

IoT: A Growing Home Ecosystem

Mockers began by highlighting the ubiquity of IoT devices, asking the audience how many owned connected devices (00:00:30–00:00:45). Most had over five, some over 50, and Mockers himself managed ~300, from Philips Hue bulbs to custom-built sensors (00:00:45–00:01:00). He started with commercial devices a decade ago but shifted to DIY solutions five years ago for cost savings and flexibility (00:00:15–00:00:30). His setup mirrors production environments, with “unhappy users” (family), legacy systems, and protocol sprawl, making it a relatable challenge for developers.

IoT Protocols: A Diverse Landscape

Mockers provided a technical overview of IoT protocols, each with unique strengths and challenges (00:01:00–00:08:15):

• ZigBee: Used by Philips Hue and IKEA, ZigBee supports lights, switches, plugs, motion sensors, and shutters in a mesh network for extended range. Devices like battery-powered switches consume minimal power, while plugged-in bulbs act as repeaters. Security issues, like a past Philips Hue hack allowing remote on/off control, highlight risks (00:01:15–00:02:15).
• Z-Wave: Similar to ZigBee but less common, used by Fibaro and Aeotec. It supports up to 232 devices (vs. ZigBee’s 65,000) with similar mesh functionality (00:02:15–00:02:45).
• 433.92 MHz: A frequency band hosting protocols like Oregon Scientific (sensors), Somfy (shutters), and Chacon/DIO (switches). These are cheap (~€10 vs. €50 for ZigBee/Z-Wave) but insecure, allowing neighbors’ devices to be controlled with a powerful transceiver. Car keys and security boxes also use this band, complicating urban use (00:02:45–00:04:00).
• Wi-Fi: Popular for startups like Netatmo (weather, security), LIFX (bulbs), and Tuya (garden devices). Wi-Fi devices are plug-and-play but power-hungry and reliant on external cloud APIs, posing risks if internet or vendor services fail. Security is a concern, as hacked Wi-Fi devices fueled major botnets (00:04:15–00:06:00).
• Bluetooth: Used for lights, speakers, and beacons, Bluetooth offers localization but requires phone proximity, limiting automation (00:06:00–00:06:30).
• Powerline (CPL) and Fil Pilote: Protocols like X10 and fil pilote (for electric radiators) use electrical wiring but depend on home wiring quality. Infrared signals control AV equipment and air conditioners but require line-of-sight and lack status feedback (00:06:45–00:08:00).
• LoRaWAN/Sigfox: Long-range protocols for smart cities, not home use (00:08:00–00:08:15).

Open-Source Tools for Home Automation

Mockers detailed his open-source toolchain, emphasizing flexibility and integration (00:08:15–00:20:45):

Home Assistant

Home Assistant, with 1,853 integrations, is Mockers’ central hub, supporting Alexa, Google Assistant, and Siri. It offers mobile apps, automation, and dashboards but becomes unwieldy with many devices. Mockers disabled its database and UI, using it solely for device discovery (00:08:30–00:09:45). It integrates with OpenHAB (2,526 integrations) and Domoticz (500 integrations) for broader device support.

ESPHome

ESPHome deploys ESP8266/ESP32 chips for custom sensors, connecting via Wi-Fi or Bluetooth. Mockers builds temperature, humidity, and light sensors for ~€10 (vs. €50 commercial equivalents). Configuration via YAML files integrates sensors directly into Home Assistant (00:10:00–00:11:45). Example:

esphome:
  name: sensor_t1_mini
  platform: ESP8266
api:
  services:
    - service: update
      then:
        - logger.log: "Updating firmware"
output:
  - platform: gpio
    pin: GPIO4
    id: led
sensor:
  - platform: bme280
    temperature:
      name: "Temperature"
    pressure:
      name: "Pressure"
    humidity:
      name: "Humidity"

Node-RED

Node-RED, with 3,485 integrations, handles automation via low-code event-driven flows. Mockers routes all Home Assistant events to Node-RED, creating rules like bridging 433MHz remotes to ZigBee bulbs. Its responsive dashboard outperforms Home Assistant’s (00:12:00–00:14:00).

InfluxDB and Grafana

InfluxDB stores time-series data from devices, replacing Home Assistant’s PostgreSQL. Mockers experimented with machine learning for anomaly detection and room occupancy prediction, though the latter was unpopular with his family (00:14:15–00:15:15). Grafana visualizes historical data, like weekly temperature trends, with polished dashboards (00:15:15–00:15:45).

Telegraf

Telegraf runs scripts for devices lacking Home Assistant integration, sending data to InfluxDB. It also monitors network and CPU usage .

Ansible and Pi-hole

Ansible automates Docker container deployment on Raspberry Pis, with roles for each service and a web page listing services . Pi-hole, a DNS-based ad blocker, caches queries and logs IoT device DNS requests, exposing suspicious activity.

Security and Deployment

Security is critical with IoT’s attack surface. Mockers recommends:

• A separate Wi-Fi network for IoT devices to isolate them from PCs .
• Limiting internet access for devices supporting local mode .
• A VPN for remote access, avoiding open ports .
• Factory-resetting devices before disposal to erase Wi-Fi credentials .

Deployment uses Docker containers on Raspberry Pis, managed by Ansible. Mockers avoids Kubernetes due to Raspberry Pi constraints, opting for custom scripts. Hardware includes Raspberry Pis, 433MHz transceivers, and Wemos ESP8266 boards with shields for sensors (00:19:45–00:20:45).

Audience Interaction and Lessons

Mockers engaged the audience with questions (00:00:30) and a Q&A , addressing:

• Usability for family (transparent for his wife, usable by his six-year-old)
• Home Assistant backups via Ansible and hourly NAS snapshots
• Insecure 433MHz devices (cheap but risky)
• Air conditioning control via infrared and fil pilote for radiators
• A universal remote consolidating five protocols, reducing complexity
• A humorous “divorce threat” from a beeping device, emphasizing user experience

Conclusion

Mockers’ talk showcased IoT as an accessible, developer-friendly domain using open-source tools. His setup, blending ZigBee, Wi-Fi, and DIY sensors with Home Assistant, Node-RED, and Grafana, offers a scalable, cost-effective model. Security and automation align with Devoxx’s cloud and IoT focus, inspiring developers to experiment safely. The key takeaway: quality data and user experience are critical for home automation success.

Resources

• Full Video
• Home Assistant
• ESPHome
• Node-RED
• InfluxDB
• Grafana
• Telegraf
• Ansible
• Pi-hole

In an enlightening session at Devoxx France 2021, Alexandre Navarro, a seasoned Java backend developer, captivated the audience with a deep dive into the world of programmable ergonomic keyboards. His presentation, titled “Maximizing Your Productivity with a Programmable Ergonomic Keyboard,” unveils the historical evolution of keyboards, the principles of ergonomic design, and practical strategies for customizing keyboards to enhance coding efficiency. Alexandre’s expertise, honed over eleven years of typing in the Bépo layout and eight years on a TextBlade, offers developers a compelling case for rethinking their primary input device. This post explores the key themes of his talk, providing actionable insights for programmers seeking to optimize their workflow.

A Journey Through Keyboard History

Alexandre begins by tracing the lineage of keyboards, a journey that illuminates why our modern layouts exist. In the 1870s, early typewriters resembled pianos with alphabetical key arrangements, mere prototypes of today’s devices. By 1874, the Sholes and Glidden typewriter introduced a layout resembling QWERTY, a design often misunderstood as a deliberate attempt to slow typists to prevent jamming. Alexandre debunks this myth, explaining that QWERTY was shaped by practical needs, such as placing frequent English digraphs like “TH” and “ER” for efficient typing. The addition of a number row and user feedback further refined the layout, with quirks like the absence of dedicated “0” and “1” keys—substituted by “O” and “I”—reflecting telegraphy influences.

This historical context sets the stage for understanding why QWERTY persists despite its limitations. Alexandre notes that modern keyboards, like the iconic IBM model, retain QWERTY’s staggered rows and non-aligned letters, a legacy of mechanical constraints irrelevant to today’s technology. His narrative underscores a critical point: many developers use keyboards designed for a bygone era, prompting a reevaluation of tools that dominate their daily work.

Defining Ergonomic Keyboards

Transitioning to ergonomics, Alexandre outlines the hallmarks of a keyboard designed for comfort and speed. He categorizes ergonomic features into three domains: physical key arrangement, letter layout, and key customization. Physically, an ergonomic keyboard should be orthogonal (straight rows, unlike QWERTY’s stagger), symmetrical to match human hand anatomy, flat to reduce tendon strain, and accessible to minimize finger travel. These principles challenge conventional designs, where number pads skew symmetry and elevated keys stress wrists.

Alexandre highlights two exemplary models: the Keyboardio Model 01 and the ErgoDox. The Keyboardio, which he uses, boasts orthogonal, symmetrical keys and accessible layouts, while the ErgoDox offers customizable switches and curvature. These keyboards prioritize user comfort, aligning with the natural positioning of hands to reduce fatigue during long coding sessions. By contrasting these with traditional keyboards, Alexandre emphasizes that ergonomic design is not a luxury but a necessity for developers who spend hours typing.

Optimizing with Programmable Keyboards

The heart of Alexandre’s talk lies in programming keyboards to unlock productivity. Programmable keyboards, like the ErgoDox and Keyboardio, emerged around 2011, powered by microcontrollers that developers can flash with custom firmware, often using Arduino-based C code or graphical tools. This flexibility allows users to redefine key functions, creating layouts tailored to their workflows.

Alexandre introduces key programming concepts, such as layers (up to 32, akin to switching between QWERTY and number pad modes), macros (single keys triggering complex shortcuts like “Ctrl+F”), and tap/hold behaviors (e.g., a key typing “A” when tapped but acting as “Ctrl” when held). These features enable developers to streamline repetitive tasks, such as navigating code or executing IDE shortcuts, directly from their home row. Alexandre’s personal setup, using the Bépo layout optimized for French, exemplifies how customization can enhance efficiency, even for English-heavy programming tasks.

Why Embrace Ergonomic Keyboards?

Alexandre concludes by addressing the “why” behind adopting ergonomic keyboards. Beyond speed, these devices offer comfort, reducing the risk of repetitive strain injuries—a concern for developers typing extensively. He shares his experience with the Bépo layout, which, while not optimized for English, outperforms QWERTY and AZERTY due to shared frequent letters and better hand alternation. For those hesitant to switch, Alexandre suggests starting with a blank keyboard to learn touch typing, ensuring all fingers engage without glancing at keys.

His call to action resonates with developers: mastering your keyboard is as essential as mastering your IDE. By investing in an ergonomic, programmable keyboard, programmers can transform a mundane tool into a productivity powerhouse. Alexandre’s insights, grounded in years of experimentation, inspire a shift toward tools that align with modern coding demands.

Links:

• Watch the full presentation: https://www.youtube.com/watch?v=zCMra9RgCzw
• Follow Devoxx France on LinkedIn: https://www.linkedin.com/in/devoxxfrance/
• Follow Devoxx France on Twitter: https://twitter.com/DevoxxFR
• Visit Devoxx France: https://www.devoxx.fr/

At Devoxx France 2019, Olivier Revial, a developer at Stackeo in Toulouse, presented Micronaut: The Ultra-Light JVM Framework of the Future. This session introduced Micronaut, a modern JVM framework designed for microservices and serverless applications, offering sub-second startup times and a 10MB memory footprint. Through slides and demos, Revial showcased Micronaut’s cloud-native approach and its potential to redefine JVM development.

Limitations of Existing Frameworks

Revial began by contrasting Micronaut with established frameworks like Spring Boot and Grails. While Spring Boot simplifies development with auto-configuration and standalone applications, it suffers from runtime dependency injection and reflection, leading to slow startup times (20–25 seconds) and high memory usage. As codebases grow, these issues worsen, complicating testing and deployment, especially in serverless environments where rapid startup is critical. Frameworks like Spring create a barrier between unit and integration tests, as long-running servers are often relegated to separate CI processes.

Micronaut addresses these pain points by eliminating reflection and using Ahead-of-Time (AOT) compilation, performing dependency injection and configuration at build time. This reduces startup times and memory usage, making it ideal for containerized and serverless deployments.

Micronaut’s Innovative Approach

Micronaut, created by Grails’ founder Graeme Rocher and Spring contributors, builds on the strengths of existing frameworks—dependency injectiaon, auto-configuration, service discovery, and HTTP client/server simplicity—while introducing innovations. It supports Java, Kotlin, and Groovy, using annotation processors and AST transformations for AOT compilation. This eliminates runtime overhead, enabling sub-second startups and minimal memory footprints.

Micronaut is cloud-native, with built-in support for MongoDB, Kafka, JDBC, and providers like Kubernetes and AWS. It embraces reactive programming via Reactor, supports GraalVM for native compilation, and simplifies testing by allowing integration tests to run alongside unit tests. Security features, including JWT and basic authentication, and metrics for Prometheus, enhance its enterprise readiness. Despite its youth (version 1.0 released in 2018), Micronaut’s ecosystem is rapidly growing.

Demonstration

Revial’s demo showcased Micronaut’s capabilities. He used the Micronaut CLI to create a “hello world” application in Kotlin, adding a controller with REST endpoints, one returning a reactive Flowable. The application started in 1–2 seconds locally (6 seconds in the demo due to environment differences) and handled HTTP requests efficiently. A second demo featured a Twitter crawler storing tweets in MongoDB using a reactive driver. It demonstrated dependency injection, validation, scheduled tasks, and security (basic authentication with role-based access). A GraalVM-compiled version started in 20 milliseconds, with a 70MB Docker image compared to 160MB for a JVM-based image, highlighting Micronaut’s efficiency for serverless use cases.

Links:

• Micronaut Official Website
• Stackeo Official Website
• Olivier Revial’s GitHub

Hashtags: #Micronaut #Microservices #DevoxxFR2019 #OlivierRevial #JVMFramework #CloudNative