Jonathan Lalou's Blog

The strategic decision regarding how an organization structures and manages its source code repositories is far more than a mere technical implementation detail; it is a fundamental architectural choice with profound and wide-ranging implications for development workflow efficiency, team collaboration dynamics, the ease of code sharing and reuse, and the effectiveness of the entire software delivery pipeline, including crucial aspects like Continuous Integration and deployment. The prevailing trend in recent years, particularly amplified by the widespread adoption of microservices architectures and the facilitation of distributed teams, has often leaned towards organizing code into numerous independent repositories (commonly known as the multi-repo approach). In this model, it is typical to have one repository per application, per service, or even per library. However, as Thierry Abaléa highlighted in his concise yet highly insightful and provocative talk at DevoxxFR 2017, some of the most innovative, productive, and successful technology companies in the world, including industry giants like Google, Facebook, and Twitter, operate and maintain their vast and complex codebases within a single, unified repository – a practice referred to as using a monorepo. This striking divergence in practice between the common industry trend and the approach taken by these leading technology companies prompted the central and compelling question of his presentation: what significant advantages, perhaps not immediately obvious, drive these large, successful organizations to embrace and actively maintain a monorepo strategy despite its perceived complexities and challenges, and are these benefits transferable and applicable to other organizations, regardless of their size, industry, or current architectural choices?

Thierry began by acknowledging the intuitive appeal and the perceived simplicity of the multi-repo model, where the organization of source code often appears to naturally mirror the organizational structure of teams or the architectural decomposition of applications into independent services. He conceded that for very small projects or nascent organizations, the multi-repo approach can seem straightforward. However, he sharply contrasted this with the monorepo approach favored by the aforementioned tech giants. He argued that while creating numerous small, independent repositories might seem simpler initially, this perceived simplicity rapidly erodes and can introduce significant friction, overhead, and complexity as the number of services, applications, libraries, and development teams grows within an organization. Managing dependencies between dozens, hundreds, or even thousands of independent repositories, coordinating changes that span across service boundaries, and ensuring consistent tooling, build processes, and deployment pipelines across a highly fragmented codebase become increasingly challenging, time-consuming, and error-prone in a large-scale multi-repo environment.

Unpacking the Compelling and Often Underestimated Advantages of the Monorepo

Thierry articulated several compelling and often underestimated benefits associated with adopting and effectively managing a monorepo strategy. A primary and perhaps the most impactful advantage is the unparalleled ease and efficiency of code sharing and reuse across different projects, applications, and teams within the organization. With all code residing in a single, unified place, developers can readily discover, access, and incorporate libraries, components, or utility functions developed by other teams elsewhere within the company without the friction of adding external dependencies or navigating multiple repositories. This inherent discoverability and accessibility fosters consistency in tooling and practices, reduces redundant effort spent on reinventing common functionalities, and actively promotes the creation and adoption of a shared internal ecosystem of high-quality, reusable code assets.

Furthermore, a monorepo can significantly enhance cross-team collaboration and dramatically facilitate large-scale refactorings and code modifications that span multiple components or services. Changes that affect several different parts of the system residing within the same repository can often be made atomically in a single commit, simplifying the process of coordinating complex updates across different parts of the system and fundamentally reducing the challenges associated with managing version compatibility issues and dependency hell that often plague multi-repo setups. Thierry also highlighted the simplification of dependency and version management; in a monorepo, there is typically a single, unified version of the entire codebase at any given point in time, eliminating the complexities and potential inconsistencies of tracking and synchronizing versions across numerous independent repositories. This unified view simplifies dependency upgrades and helps prevent conflicts arising from incompatible library versions. Finally, he argued that a monorepo inherently facilitates the implementation of a more effective and comprehensive cross-application Continuous Integration (CI) pipeline. Changes committed to the monorepo can easily trigger automated builds and tests for all affected downstream components, applications, and services within the same repository, enabling comprehensive testing of interactions and integrations between different parts of the system before changes are merged into the main development line. This leads to higher confidence in the overall stability and correctness of the entire system.

Addressing Practical Considerations, Challenges, and Potential Drawbacks

While making a strong and persuasive case for the advantages of a monorepo, Thierry also presented a balanced and realistic view by addressing the practical considerations, significant challenges, and potential drawbacks associated with this approach. He acknowledged that managing and scaling the underlying tooling (such as version control systems like Git or Mercurial, build systems like Bazel or Pants, and Continuous Integration infrastructure) to handle a massive monorepo containing millions of lines of code and potentially thousands of developers requires significant investment in infrastructure, tooling development, and specialized expertise. Companies like Google, Facebook, and Microsoft have had to develop highly sophisticated custom solutions or heavily adapt and extend existing open-source tools to manage their enormous repositories efficiently and maintain performance. Thierry noted that contributions from these leading companies back to open-source projects like Git and Mercurial are gradually making monorepo tooling more accessible and performant for other organizations.

He also pointed out that successfully adopting, implementing, and leveraging a monorepo effectively necessitates a strong and mature engineering culture characterized by high levels of transparency, trust, communication, and effective collaboration across different teams and organizational boundaries. If teams operate in silos with poor communication channels and a lack of awareness of work happening elsewhere in the codebase, a monorepo can potentially exacerbate issues related to unintentional breaking changes or conflicting work rather than helping to solve them. Thierry suggested that a full, immediate, “big bang” switch to a monorepo might not be feasible, practical, or advisable for all organizations. A phased or incremental approach, perhaps starting with new projects, consolidating code within a specific department or domain, or gradually migrating related services into a monorepo, could be a more manageable and lower-risk way to transition and build the necessary tooling, processes, and cultural practices over time. The talk provided a nuanced and well-rounded perspective, encouraging organizations to carefully consider the significant potential benefits of a monorepo for improving collaboration, code sharing, and CI efficiency, while being acutely mindful of the required investment in tooling, infrastructure, and, critically, the importance of fostering a collaborative and transparent engineering culture.

Links:

• Video URL: https://www.youtube.com/watch?v=7Dfes-qJQ54
• Thierry Abaléa LinkedIn: https://www.linkedin.com/in/thierry-abalea/

Hashtags: #Monorepo #CodeOrganization #EngineeringPractices #ThierryAbalea #SoftwareArchitecture #VersionControl #ContinuousIntegration #Collaboration #Google #Facebook #Twitter #DeveloperProductivity

At DevoxxUS2017, Martin Lippert, a pivotal figure at Pivotal and co-lead of the Spring Tool Suite, delivered an engaging presentation on advanced tooling for Spring Boot development within the Eclipse IDE. With a rich background in crafting developer tools, Martin showcased how recent updates to Spring IDE and Spring Tool Suite streamline microservice development, particularly for Spring Boot and Cloud Foundry. His live demos and coding sessions highlighted features that enhance productivity and transform the IDE into a hub for cloud-native development. This post explores the key themes of Martin’s presentation, offering insights into optimizing Spring Boot workflows.

Streamlining Spring Boot Development

Martin Lippert opened by demonstrating the ease of initiating Spring Boot projects within Eclipse, leveraging the Spring Tool Suite. He showcased how developers can quickly scaffold applications using Spring Initializr integration, simplifying setup for microservices. Martin’s live demo illustrated generating a project with minimal configuration, emphasizing how these tools reduce boilerplate code and accelerate development cycles, aligning with Pivotal’s mission to empower developers with efficient workflows.

Advanced Configuration Management

Delving into configuration, Martin highlighted enhanced support for Spring Boot properties in YAML and property files. Features like content-assist, validation, and hover help simplify managing complex configurations, crucial for microservices. He demonstrated real-time synchronization between local projects and Cloud Foundry manifests, showcasing how the Spring Boot dashboard detects and merges configuration changes. These capabilities, Martin noted, ensure consistency across development and deployment environments, enhancing reliability in cloud-native applications.

Spring Boot Dashboard and Cloud Integration

A centerpiece of Martin’s talk was the Spring Boot dashboard, a powerful tool for managing multiple microservice projects. He showcased its ability to monitor, start, and stop services within the IDE, streamlining workflows for developers handling distributed systems. Martin also explored advanced editing of Cloud Foundry manifest files, illustrating seamless integration with cloud runtimes. His insights, drawn from Pivotal’s expertise, underscored the dashboard’s role in transforming Eclipse into a microservice development powerhouse.

Links:

• Pivotal company website
• Spring Tool Suite website
• Cloud Foundry website

Michael Nash, co-author of Applied Akka Patterns, delivered an insightful exploration of scalability at Scala Days New York 2016, distinguishing it from performance and outlining strategies to achieve near-linear scalability using the Lightbend ecosystem. Michael’s presentation delved into architectural principles, real-world patterns, and tools that enable systems to handle increasing loads without failure.

Scalability vs. Performance

Michael Nash clarified that scalability is the ability to handle greater loads without breaking, distinct from performance, which focuses on processing the same load faster. Using a simple graph, Michael illustrated how performance improvements shift response times downward, while scalability extends the system’s capacity to handle more requests. He cautioned that poorly designed systems hit scalability limits, leading to errors or degraded performance, emphasizing the need for architectures that avoid these bottlenecks.

Avoiding Scalability Pitfalls

Michael identified key enemies of scalability, such as shared databases, synchronous communication, and sequential IDs. He advocated for denormalized, isolated data stores per microservice, using event sourcing and CQRS to decouple systems. For instance, an inventory service can update based on events from a customer service without direct database access, enhancing scalability. Michael also warned against overusing Akka cluster sharding, which introduces overhead, recommending it only when consistency is critical.

Leveraging the Lightbend Ecosystem

The Lightbend ecosystem, including Scala, Akka, and Spark, provides robust tools for scalability, Michael explained. Akka’s actor model supports asynchronous messaging, ideal for distributed systems, while Spark handles large-scale data processing. Tools like Docker, Mesos, and Lightbend’s ConductR streamline deployment and orchestration, enabling rolling upgrades without downtime. Michael emphasized integrating these tools with continuous delivery and deep monitoring to maintain system health under high loads.

Real-World Applications and DevOps

Michael shared case studies from IoT wearables to high-finance systems, highlighting common patterns like event-driven architectures and microservices. He stressed the importance of DevOps in scalable systems, advocating for automated deployment pipelines and monitoring to detect issues early. By embracing failure as inevitable and designing for resilience, systems can scale across data centers, as seen in continent-spanning applications. Michael’s practical advice included starting deployment planning early to avoid scalability bottlenecks.

Links:

• Lightbend company website

Lecturer

The Opening Keynote of KotlinConf 2017 features Maxim Shafirov, Andrey Breslav, Dmitry Jemerov, and Stephanie Cuthbertson. Maxim Shafirov, CEO of JetBrains, has led the company’s efforts in developing innovative developer tools, including IntelliJ IDEA and Kotlin. Andrey Breslav, Kotlin’s lead designer, brings a deep understanding of language design, focusing on pragmatic solutions for JVM developers. Dmitry Jemerov, a senior developer at JetBrains, contributes technical expertise to Kotlin’s development. Stephanie Cuthbertson, involved with Android’s adoption of Kotlin, offers insights into its mobile ecosystem impact. Their collective leadership has driven Kotlin’s growth as a modern programming language.

• JetBrains company website
• Maxim Shafirov on LinkedIn
• Andrey Breslav on LinkedIn

Abstract

The Opening Keynote of KotlinConf 2017, delivered in San Francisco from November 1–3, 2017, set the tone for the inaugural Kotlin conference. This article examines the keynote’s exploration of Kotlin’s rapid rise, its strategic vision, and its impact on the developer community. Led by JetBrains’ leadership, the keynote highlighted Kotlin’s adoption in Android, its multiplatform ambitions, and the collaborative efforts driving its ecosystem. The analysis delves into the context of Kotlin’s emergence, the technical and community-driven advancements presented, and the implications for its future in software development.

Context of Kotlin’s Emergence

KotlinConf 2017 marked a significant milestone as the first conference dedicated to Kotlin, a language developed by JetBrains to enhance Java’s capabilities while ensuring seamless JVM interoperability. Held in San Francisco, the event attracted 1,200 attendees and sold out, reflecting Kotlin’s growing popularity. The keynote, led by Maxim Shafirov, emphasized the language’s recent endorsement by Google as a first-class language for Android development, a pivotal moment that accelerated its adoption. With 150 talk submissions from 110 speakers, the conference required an additional track, underscoring the community’s enthusiasm and the language’s broad appeal.

The keynote contextualized Kotlin’s rise within the evolving landscape of software development, where developers sought modern, concise languages to address Java’s verbosity and complexity. Maxim and Andrey highlighted Kotlin’s design philosophy, focusing on readability, type safety, and ease of adoption. The event’s organization, supported by Trifork and a program committee, ensured a diverse range of topics, from Android development to server-side applications, reflecting Kotlin’s versatility and the community’s collaborative spirit.

Technical Advancements and Multiplatform Vision

Andrey Breslav’s segment of the keynote outlined Kotlin’s technical strengths and future directions, particularly its multiplatform capabilities. Kotlin’s ability to simplify functional programming and reduce boilerplate code was a key focus, with the compiler handling complex type inference to enhance developer productivity. The keynote introduced plans for common native libraries, enabling shared code for I/O, networking, and serialization across platforms like iOS and Android. This multiplatform vision aimed to unify development workflows, reducing fragmentation and enabling developers to write platform-agnostic code.

The keynote also addressed Kotlin’s experimental features, such as coroutines, which were in active development. Andrey emphasized backward compatibility, ensuring that even experimental features would remain stable in production environments. This commitment to reliability, coupled with tools to facilitate migration to finalized designs, reassured developers of Kotlin’s suitability for enterprise applications. The technical advancements presented underscored Kotlin’s potential to bridge diverse development ecosystems, from mobile to native platforms.

Community Engagement and Ecosystem Growth

The keynote highlighted the pivotal role of the Kotlin community in driving the language’s success. Maxim and Dmitry acknowledged the contributions of partners like Gradle and Spring, which enhanced Kotlin’s interoperability with existing tools. The conference provided platforms for engagement, including office hours for bug reporting and voting mechanisms to gather feedback. These initiatives empowered developers to influence Kotlin’s evolution, fostering a sense of ownership within the community.

The keynote also celebrated the social aspects of KotlinConf, with events like the keynote party featuring live music and networking opportunities. These gatherings strengthened community ties, encouraging collaboration among developers, startups, and Fortune 500 companies adopting Kotlin. The emphasis on community-driven growth highlighted Kotlin’s role as a collaborative project, with JetBrains actively seeking feedback to refine features and address pain points, ensuring the language’s relevance and adaptability.

Implications for Software Development

KotlinConf 2017’s keynote underscored Kotlin’s transformative potential in software development. Its adoption by 17% of Android projects at the time signaled its growing influence in mobile development, where it simplified tasks like UI design and asynchronous programming. The multiplatform vision promised to extend these benefits to iOS and other platforms, reducing development complexity and fostering code reuse. For enterprises, Kotlin’s production-readiness and support for high-quality codebases offered a compelling alternative to Java.

The keynote’s focus on community engagement set a precedent for inclusive development, encouraging contributions from diverse stakeholders. The promise of recorded sessions ensured global accessibility, amplifying the conference’s impact. For the industry, KotlinConf 2017 highlighted the shift toward modern languages that prioritize developer experience, positioning Kotlin as a leader in this transition. The keynote’s strategic vision laid the groundwork for Kotlin’s continued growth, influencing both individual developers and large-scale projects.

Conclusion

The Opening Keynote of KotlinConf 2017 encapsulated the excitement and ambition surrounding Kotlin’s rise as a modern programming language. By highlighting its technical strengths, multiplatform potential, and vibrant community, Maxim, Andrey, Dmitry, and Stephanie positioned Kotlin as a transformative force in software development. The keynote’s emphasis on collaboration, innovation, and developer empowerment underscored Kotlin’s role in shaping the future of programming. As JetBrains continues to evolve Kotlin, the insights from KotlinConf 2017 remain a cornerstone of its journey, inspiring developers to embrace its capabilities.

Links

• KotlinConf 2017 Opening Keynote Video
• JetBrains company website
• Maxim Shafirov on LinkedIn
• Andrey Breslav on LinkedIn

In the arcane atelier of application assurance, where user whims whirl into wicked whimsy, wielding wards against web’s wicked whims demands diligence and dexterity. Ingrid Epure, a frontend alchemist at Intercom, invoked this incantation at dotSecurity 2017, transmuting tales of Ember’s exigencies into elixirs for Ember’s endurance. A Romanian expatriate ensconced in Dublin’s digital demesne, Ingrid’s immersion—four-year Ember opus, Rails’ rearward rampart—yields yarns of 55 scribes scripting 2,000 shifts, 100 deploys diurnal.

Ingrid’s invocation opened with Intercom’s incantus: real-time runes for messaging’s mosaic, 250 commits cascading 30K additions—vulnerabilities’ vortex in velocity’s vortex. XSS’s xanthic xanthoma: inline sorcery (Ember’s {{}} incantations) inviting injection’s infestation—’s sorcery, CSP’s countercharm. Ingrid illuminated Ember’s ember: helpers’ hygiene (HTML-escapers’ aegis), bindings’ bulwark (triple braces’ taboo). Tools’ talisman: npm’s audit, ember-cli’s eldritch eyes—vulnerabilities’ vigil, dependencies’ divination.

CSRF’s chicanery: Ember’s CSRF tokens, Rails’ requiem—double-submit’s duality, synchronizer’s sentinel. Ingrid invoked interceptors: Ember’s data’s dominion, Rails’ requital. Content Security Policy’s codex: v2’s vigilance (nonces’ nebula, hashes’ heraldry), v3’s valor—scripts’ scrutiny, inline’s inquisition. Ingrid’s imprecation: Ember addon’s aegis, Node’s nexus—alerts’ alarum, anomalies’ augury.

This conjury: clean code’s creed, tools’ tome—CSP’s citadel, vulnerabilities vanquished.

Vulnerabilities’ Vortex and Wards’ Weave

Ingrid invoked Intercom’s incantus: Ember’s exigencies, XSS’s xanthoma—helpers’ hygiene, bindings’ bulwark.

CSRF’s Chicanery and CSP’s Codex

Tokens’ talisman, interceptors’ insight—v2’s vigilance, v3’s valor. Ingrid’s imprecation: addon’s aegis, Node’s nexus.

Links:

• Ingrid Epure on LinkedIn
• Intercom

EN_DotSecurity2017_006_009.md

At DevoxxUS2017, Ramki Ramakrishna, a Staff Engineer at Twitter, delivered a compelling session on optimizing microservices performance using machine learning. Collaborating with colleagues, Ramki shared insights from Twitter’s platform engineering efforts, focusing on Bayesian optimization to tune microservices in data centers. His talk addressed the challenges of managing complex workloads and offered a vision for automated optimization. This post explores the key themes of Ramki’s presentation, highlighting innovative approaches to performance tuning.

Challenges of Microservices Performance

Ramki Ramakrishna opened by outlining the difficulties of tuning microservices in data centers, where numerous parameters and workload variations create combinatorial complexity. Drawing from his work with Twitter’s JVM team, he explained how continuous software and hardware upgrades exacerbate performance issues, often leaving resources underutilized. Ramki’s insights set the stage for exploring machine learning as a solution to these challenges.

Bayesian Optimization in Action

Delving into technical details, Ramki introduced Bayesian optimization, a machine learning approach to automate performance tuning. He described its application in Twitter’s microservices, using tools derived from open-source projects like Spearmint. Ramki shared practical examples, demonstrating how Bayesian methods efficiently explore parameter spaces, outperforming manual tuning in scenarios with many variables, ensuring optimal resource utilization.

Lessons and Pitfalls

Ramki discussed pitfalls encountered during Twitter’s optimization projects, such as the need for expert-defined parameter ranges to guide machine learning algorithms. He highlighted the importance of collaboration between service owners and engineers to specify tuning constraints. His lessons, drawn from real-world implementations, emphasized balancing automation with human expertise to achieve reliable performance improvements.

Vision for Continuous Optimization

Concluding, Ramki outlined a vision for a continuous optimization service, integrating machine learning into DevOps pipelines. He noted plans to open-source parts of Twitter’s solution, building on frameworks like Spearmint. Ramki’s forward-thinking approach inspired developers to adopt data-driven optimization, ensuring microservices remain efficient amidst evolving data center demands.

Links:

• Twitter company website
• Spearmint GitHub repository

At DevoxxUS2017, Baruch Sadogursky and Viktor Gamov, from JFrog and Hazelcast respectively, entertained attendees with a lively exploration of Java 8 and 9 puzzlers. Known for their engaging style, Baruch, a Developer Advocate, and Viktor, a Senior Solution Architect, presented complex coding challenges involving streams, lambdas, and Optionals. Their session combined humor, technical depth, and audience interaction, offering valuable lessons for Java developers. This post examines the key themes of their presentation, highlighting strategies to navigate Java’s intricacies.

Decoding Java 8 Complexities

Baruch Sadogursky and Viktor Gamov kicked off with a series of Java 8 puzzlers, focusing on streams and lambdas. They presented scenarios where seemingly simple code led to unexpected outcomes, such as subtle bugs in stream operations. Baruch emphasized the importance of understanding functional programming nuances, using examples to illustrate common pitfalls. Their interactive approach, with audience participation, made complex concepts accessible and engaging.

Navigating Java 9 Features

Transitioning to Java 9, Viktor explored new puzzlers involving modules and CompletableFutures, highlighting how these features introduce fresh challenges. He demonstrated how the module system can lead to compilation errors if misconfigured, urging developers to read documentation carefully. Their examples, drawn from real-world experiences at JFrog and Hazelcast, underscored the need for precision in adopting Java’s evolving features.

Tools for Avoiding Pitfalls

Baruch and Viktor stressed the role of tools like IntelliJ IDEA in catching errors early, noting how its inspections highlight potential issues in lambda and stream usage. They advised against overusing complex constructs, advocating for simplicity to avoid “WTF” moments. Their practical tips, grounded in their extensive conference-speaking experience, encouraged developers to leverage IDEs and documentation to write robust code.

Community Engagement and Resources

Concluding with a call to action, Baruch and Viktor invited developers to contribute puzzlers to JFrog’s puzzlers initiative, fostering community-driven learning. They shared resources, including their slide deck and blog posts, encouraging feedback via Twitter. Their enthusiasm for Java’s challenges inspired attendees to dive deeper into the language’s intricacies, embracing both its power and pitfalls.

Links:

• JFrog company website
• Hazelcast company website
• JFrog puzzlers initiative

Wade Waldron, a senior consultant at Lightbend and co-author of Applied Akka Patterns, presented a compelling case for combining Domain-Driven Design (DDD) and Onion Architecture at Scala Days New York 2016. Using the relatable example of frying an egg, Wade illustrated how these methodologies enhance code clarity, maintainability, and portability, leveraging Scala’s expressive features to model complex domains effectively.

Defining the Core Domain

Wade Waldron introduced DDD as a methodology that prioritizes the core domain—the sphere of knowledge central to a system—over peripheral concerns like user interfaces or databases. Using the egg-frying case study, Wade demonstrated how Scala’s case classes and traits enable rapid prototyping of domain models, such as eggs, frying pans, and cooking processes. By focusing on domain rules rather than technology, developers can create stable, reusable code. Wade emphasized that DDD does not require CQRS or event sourcing, though these patterns complement it, allowing flexibility in implementation.

Leveraging Onion Architecture

Onion Architecture, Wade explained, organizes code into concentric layers, with the domain model at the core and infrastructure, like databases, at the outer layers. This structure ensures portability by isolating the domain from external dependencies. In the egg-frying example, repositories and services abstract interactions with external systems, allowing seamless swaps of databases or APIs without altering the core logic. Wade showcased how Scala’s concise syntax supports this layering, enabling developers to maintain clean package structures and focus on business logic.

Enhancing Portability and Testability

A key benefit of combining DDD with Onion Architecture, as Wade highlighted, is the ability to refactor implementations without impacting consumers. By defining clear APIs and using repositories, developers can switch databases or rewrite domain models transparently. Wade shared real-world examples where his team performed live migrations and database swaps unnoticed by users, thanks to the abstraction layers. This approach also simplifies testing, as in-memory repositories can mimic real data stores, enhancing test efficiency and reliability.

Engaging Stakeholders with Domain Language

Wade stressed the importance of using a ubiquitous language in DDD to align developers and stakeholders. In the egg-frying scenario, terms like “fry” and “cook” bridge technical and non-technical discussions, ensuring clarity. However, Wade acknowledged challenges in large organizations where stakeholders may focus on technical details. He advised persistently steering conversations back to the domain level, fostering a shared understanding that drives effective collaboration and reduces miscommunication.

Links:

• Lightbend company website
• Wade Waldron on LinkedIn

For many software development teams, managing feature branches in version control can be a source of significant pain and delays, particularly when branches diverge over long periods, leading to complex and time-consuming merge conflicts. Morgan LEROI proposed an alternative strategy: minimize or eliminate long-lived feature branches in favor of using Feature Toggles. His presentation explored the concepts behind feature toggles, their benefits, and shared practical experience on how this approach can streamline development workflows and enable new capabilities like activating features on demand.

Morgan opened by illustrating the common frustration associated with merging branches that have diverged significantly, describing it as a “traumatic experience”. This pain point underscores the need for development practices that reduce the time code spends in isolation before being integrated.

Embracing Feature Toggles

Feature Toggles, also known as Feature Flags, are a technique that allows developers to enable or disable specific features in an application at runtime, without deploying new code. The core idea is to merge code frequently into the main development branch (e.g., main or master), even if features are not yet complete or ready for production release. The incomplete or experimental features are wrapped in toggles that can be controlled externally.

Morgan explained that this approach addresses the merge hell problem by ensuring code is integrated continuously in small increments, minimizing divergence. It also decouples deployment from release; code containing new features can be deployed to production disabled, and the feature can be “released” or activated later via the toggle when ready.

Practical Benefits and Use Cases

Beyond simplifying merging, Feature Toggles offer several tangible benefits. Morgan highlighted their use by major industry players, including Amazon, demonstrating their effectiveness at scale. A key advantage is the ability to activate new features on demand, for specific user groups, or even for individual users. This enables phased rollouts, A/B testing, and easier rollback if a feature proves problematic.

Morgan detailed the application of feature toggles in A/B testing scenarios. By showing different versions of a feature (or the presence/absence of a feature) to different user segments, teams can collect metrics on user behavior and make data-driven decisions about which version is more effective. This allows for continuous experimentation and optimization based on real-world usage. He suggested that even a simple boolean configuration toggle (if (featureIsEnabled) { ... }) can be a starting point. Morgan encouraged developers to consider feature toggles as a powerful tool for improving development flow, reducing merge pain, and gaining flexibility in releasing new functionality. He challenged attendees to reflect on whether their current branching strategy is serving them well and to consider experimenting with feature toggles. Morgan Leroi is a Staff Software Engineer at Algolia.

Links:

• Morgan LEROI’s Twitter
• Morgan LEROI’s LinkedIn
• Morgan Leroi morganleroi – GitHub
• Tuez vos branches, faites des Feature Toggles (Morgan LEROI) – YouTube
• Video URL: https://www.youtube.com/watch?v=btrTtVWInc0

Hashtags: #FeatureToggles #BranchingStrategy #ContinuousDelivery #DevOps #SoftwareDevelopment #Agile #MorganLEROI #DevoxxFR2017

In the quest for novel ways to enable communication between web pages running on different machines without relying on a central server, Hubert SABLONNIERE embarked on a truly unique and fascinating experiment: using ultrasonic sound emitted and received through web browsers. This adventurous project leveraged modern web audio capabilities to explore an unconventional method of initiating a peer-to-peer connection, pushing the boundaries of what’s possible with web technologies.

Hubert’s journey began with a seemingly simple question that led down an unexpected path. The idea was to use audible (or in this case, inaudible) sound as a signaling mechanism to bootstrap a WebRTC connection, a technology that allows direct browser-to-browser communication.

Signaling with Ultrasound

The core concept involved using the Web Audio API to generate audio signals at frequencies beyond the range of human hearing – ultrasounds. These signals would carry encoded information, acting as a handshake or discovery mechanism. A web page on one machine would emit these ultrasonic signals through the computer’s speakers, and a web page on another nearby machine would attempt to detect and decode them using the Web Audio API and the computer’s microphone.

Once the two pages successfully exchanged the necessary information via ultrasound (such as network addresses or session descriptions), they could then establish a direct WebRTC connection for more robust and higher-bandwidth communication. Hubert’s experiment demonstrated the technical feasibility of this imaginative approach, turning computers into acoustic modems for web pages.

Experimentation and Learning

Hubert emphasized that the project was primarily an “adventure” and an excellent vehicle for learning, rather than necessarily a production-ready solution. Building this ultrasonic communication system provided invaluable hands-on experience with several cutting-edge web technologies, specifically the Web Audio API for generating and analyzing audio and the WebRTC API for peer-to-peer networking.

Personal projects like this, free from the constraints and requirements of production environments, offer a unique opportunity to explore unconventional ideas and deepen understanding of underlying technologies. Hubert shared that the experiment, developed over several nights, allowed him to rapidly learn and experiment with WebRTC and Web Audio in a practical context. While the real-world applicability of using ultrasound for web page communication might be limited by factors like ambient noise, distance, and device microphone/speaker capabilities, the project served as a powerful illustration of creative problem-solving and the potential for unexpected uses of web APIs. Hubert made the project code available on GitHub, encouraging others to explore this ultrasonic frontier and potentially build upon his adventurous experimentation.

Links:

• Hubert SABLONNIERE’s Twitter
• Hubert SABLONNIERE’s LinkedIn
• Hubert SABLONNIERE’s GitHub
• Video URL: https://www.youtube.com/watch?v=rfEJY7lRrbM

Hashtags: #WebAudio #WebRTC #Ultrasound #Experimentation #JavaScript #HubertSablonniere #DevoxxFR2017