Jonathan Lalou's Blog

Archive for the ‘General’ Category

Noel Welsh, co-founder of Underscore VC and a respected voice in the Scala community, known for his educational contributions including the books “Creative Scala” and “Essential Scala,” shared his valuable insights on “Techniques for Teaching Scala” at ScalaDays Lausanne 2019. His presentation moved beyond the technical intricacies of the language to explore the pedagogical approaches that make learning Scala more effective, engaging, and accessible to newcomers.

• Creative Scala (Book by Noel Welsh & Dave Gurnell)
• Essential Scala (Book by Noel Welsh & Dave Gurnell)
• Scala Lang Official Website

Hashtags: #ScalaDays2019 #Scala #Education #Teaching #Pedagogy #NoelWelsh #CreativeScala

At ScalaDays Lausanne 2019, Nicolas Rinaudo, CTO of Besedo, delivered a candid and insightful talk on Scala best practices, drawing from his experience merging Node, Java, and Scala teams. Speaking at EPFL’s 10th anniversary conference, Nicolas shared pitfalls he wished he’d known as a beginner, from array comparisons to exceptions, offering practical solutions. His interactive approach—challenging the audience to spot code issues—drew laughter, applause, and questions on tools like Scalafix, making his session a highlight for developers seeking to write robust Scala code.

Array Comparisons and Type Annotations

Nicolas began with a deceptive array comparison using ==, which fails due to arrays’ reference equality on the JVM, unlike other Scala collections. Beginners from Java or JavaScript backgrounds often stumble here, expecting value equality. The fix, sameElements, ensures correct comparisons, while Scala 3’s immutable arrays behave sanely. Another common error is omitting type annotations on public methods. Without explicit types, the compiler may infer overly broad types like Some instead of Option, risking binary compatibility issues in libraries. Nicolas advised always annotating public members, noting Scala 3’s requirement for implicit members, though the core issue persists, emphasizing vigilance for maintainable code.

Sealed Traits and Case Classes

Enumerations in Scala, Nicolas warned, are treacherous, allowing non-exhaustive pattern matches that compile but crash at runtime. Sealed traits, with subtypes declared in the same file, enable the compiler to enforce exhaustive matching, preventing such failures. He recommended enabling fatal warnings to catch these issues. Similarly, non-final case classes can be extended, leading to unexpected equality behaviors, like two distinct objects comparing equal due to inherited methods. Making case classes final avoids this, though Scala’s default remains unchanged even in Scala 3. Nicolas also noted that sealed traits aren’t foolproof—subtypes can be extended unless final, a subtlety that surprises learners but is manageable with disciplined design.

Exceptions and Referential Transparency

Exceptions, common in Java, disrupt Scala’s referential transparency, where expressions should be replaceable with their values without altering behavior. Nicolas likened exceptions to goto statements, as their origin is untraceable, and Scala’s unchecked exceptions evade compile-time checks. For instance, parsing a string to an integer may throw a NumberFormatException, but most inputs fail, making it a common case unsuitable for exceptions. Instead, use Option for absent values, Either for errors with context, or Try for Java interop. These encode errors in return types, enhancing predictability. Scala 3 offers no changes here, so Nicolas’s advice remains critical for writing transparent, robust code.

Enforcing Best Practices

To prevent these pitfalls, Nicolas advocated rigorous code reviews, citing research showing reduced defects. Automated tools like WartRemover, Scalafix, Scapegoat, and Scalastyle detect issues during builds, though some, like WartRemover’s strict defaults, may need tuning. Migrating to Scala 3 addresses many problems, such as implicit conversions and enumeration ambiguities, with features like the enum keyword and explicit import rules. Nicolas invited the audience to share additional practices, pointing to his companion website for detailed articles. His acknowledgment of Scala contributors, especially for Scala 3 insights, underscored the community’s role in evolving best practices, making his talk a call to action for cleaner coding.

Links:

• Session Video
• Session Abstract
• Scalafix Repository
• WartRemover Repository
• Nicolas’s Best Practices Site

Hashtags: #ScalaDays2019 #Scala #BestPractices #FunctionalProgramming

At ScalaDays Lausanne 2019, Manohar Jonnalagedda and Jakob Odersky, researchers turned industry innovators, unveiled a Scala-powered approach to secure multi-party computation (MPC) at EPFL’s 10th anniversary conference. Their talk, moments before lunch, captivated attendees with a protocol to average salaries without revealing individual data, sparking curiosity about privacy-preserving applications. Manohar and Jakob, from Inpher, detailed a compiler transforming high-level code into secure, distributed computations, addressing real-world challenges like GDPR-compliant banking and satellite collision detection, earning applause and probing questions on security and scalability.

A Privacy-Preserving Protocol

Manohar opened with a relatable scenario: wanting to compare salaries with Jakob without disclosing personal figures. Their solution, a privacy-preserving protocol, lets three parties—Manohar, Jakob, and their CTO Dmitar—compute an average securely. Each generates three random numbers summing to zero, sharing them such that each party holds a unique view of partial sums. In Scala, this is modeled with a SecretValue type for private integers and a SharedNumber list, accessible only by the corresponding party. Each sums their shares, publishes the result, and the final sum reveals the average without exposing individual salaries. This protocol, using random shares, ensures no single party can deduce another’s data unless all communications are intercepted, balancing simplicity and security.

Secure Multi-Party Computation

Jakob explained MPC as a cryptographic subfield enabling joint function computation without revealing private inputs. The salary example used addition, but MPC supports multiplication via Beaver triplets, precomputed by a trusted dealer for efficiency. With addition and multiplication, MPC handles polynomials, enabling linear and logistic regression or exponential approximations via Taylor polynomials. Manohar highlighted Scala’s role in modeling these operations, with functions for element-wise addition and revealing sums. The protocol achieves information-theoretic security for integers, where masked values are indistinguishable, but floating-point numbers require computational security due to distribution challenges. This flexibility makes MPC suitable for complex computations, from machine learning to statistical analysis, all while preserving privacy.

Real-World Applications

MPC shines in domains where data sensitivity or legal constraints, like GDPR, restrict sharing. Manohar cited ING, a bank building credit-scoring models across European countries without moving user data across borders, complying with GDPR. Another compelling case involved satellite operators—American, Russian, or Chinese—secretly computing collision risks to avoid incidents like the 2009 Iridium-Cosmos crash, which threatened the International Space Station. Jakob emphasized that Inpher’s XOR platform, legally vetted by Baker McKenzie, ensures GDPR compliance by keeping data at its source. These use cases, from finance to defense, underscore MPC’s value in enabling secure collaboration, with Scala providing a robust, type-safe foundation for protocol implementation.

Building a Compiler for MPC

To scale MPC beyond simple embeddings, Manohar and Jakob’s team developed a compiler at Inpher, targeting a high-level language resembling Python or Scala for data scientists. This compiler transforms linear algebra-style code into low-level primitives for distributed execution across parties’ virtual machines, verified to prevent data leaks. It performs static analysis to optimize memory and communication, inferring masking parameters to minimize computational overhead. For example, multiplying masked floating-point numbers risks format explosion, so the compiler uses fixed-point representations and statistical bounds to maintain efficiency. The output, resembling assembly for MPC engines, manages memory allocation and propagates data dimensions. While currently MPC-focused, the compiler’s design could integrate other privacy techniques, offering a versatile platform for secure computation.

Links:

• Session Video
• Session Abstract
• Inpher XOR Platform
• SP DZ Protocol Reference

Hashtags: #ScalaDays2019 #Scala #Privacy #MPC

A 22-minute fireside chat at VivaTech 2019, moderated by Harry Stebbings, Founder of Stride VC and The Twenty Minute VC, featured Pär-Jörgen Pärson, General Partner at Northzone, available on YouTube. Connected via LinkedIn and LinkedIn, Harry and Pär-Jörgen discussed VC decision-making. This 1000–1200-word post, for VCs, startup founders, and tech enthusiasts, explores lessons from market cycles and Spotify’s success.

Navigating Market Cycles

Pär-Jörgen, having weathered the 2001–2003 dot-com crash (95% value loss) and 2008–2009 cleantech wipeout, emphasized resilience. These cycles taught him to prioritize sustainable growth over hype-driven valuations. Europe’s VC ecosystem, now complete with angel-to-growth financing, avoids early exits (e.g., $60 million sales once deemed successes). In 2018, six of eight global IPOs were European, reflecting a maturing market. Pär-Jörgen advises founders to choose investors wisely, ensuring alignment for tough times, as market booms tempt over-valuation risks.

Aligning Interests in VC

Pricing, Pär-Jörgen argued, hinges on aligned interests, often undermined by high valuations with anti-dilution clauses. These misalignments strain founder-VC partnerships during downturns. He recommends founders stress-test investor alignment pre-investment, prioritizing resilience over maximizing valuation. Northzone avoids consensus-driven decisions, relying on individual conviction to back founders like Spotify’s Daniel Ek. This approach, coupled with transparent, meritocratic fund structures, has driven Northzone’s success, including three multi-billion-dollar exits, despite long-term performance uncertainty in VC.

Lessons from Spotify’s Growth

Pär-Jörgen’s early bet on Spotify, led by Daniel Ek, hinged on Daniel’s vision and ability to oscillate between granular details (e.g., instant playback UX) and strategic abstraction. Initially reluctant to lead, Daniel’s paranoia and customer focus—balancing creators, consumers, and labels—built a two-sided marketplace over a decade. Spotify’s near-death moments, resolved in hours, underscore the value of experienced VCs who remain calm. Pär-Jörgen’s latest unannounced investment in group travel reflects his knack for spotting young, serial founders with high-growth potential.

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

A 25-minute panel at VivaTech 2019, moderated by Emmanuelle Duten of Les Echos/Capital Finance, featured Philippe Botteri, Partner at Accel, Virginie Morgon, CEO of Eurazeo, and David Thevenon, Partner at SoftBank Investment Advisers, available on YouTube. Connected via LinkedIn, LinkedIn, and LinkedIn, they discussed Europe’s unicorn boom. This 1000–1200-word post, for investors, entrepreneurs, and policymakers, explores the drivers of unicorn growth.

Europe’s Unicorn Momentum

Philippe highlighted Europe’s unicorn surge, with 17–18 created in 2018, fueled by $23 billion in investments. Accel’s $575 million fund targets 22 European cities, a shift from London-Tel Aviv dominance 15 years ago. Virginie noted that two-thirds of 2018’s new unicorns were European, driven by ambitious founders and growing growth capital. David emphasized Europe’s robust ecosystem, with SoftBank’s investments in Germany and beyond, signaling that the region now rivals global hubs, supported by professional early-stage and growth investors.

Characteristics of Unicorn Founders

Virginie stressed that unicorn founders, like Farfetch’s José Neves, exhibit exceptional execution and ambition, mastering complex platforms (e.g., logistics, delivery). Philippe cited Doctolib’s Stan, whose passion for transforming European healthcare inspired Accel’s Series A investment, now a unicorn. David pointed to OYO’s Ritesh Agarwal, scaling from 13 to 200,000 hotel rooms since 2015, driven by urgency and global vision. These founders combine strategic thinking, platform-building (e.g., Grab’s shift to financial services), and relentless focus, distinguishing them in competitive markets.

Supporting Unicorn Growth

Beyond capital, VCs provide operational support. Philippe’s Accel leverages its global network (Silicon Valley, London, India) to help software startups relocate to the U.S., hiring top sales talent. Virginie’s Eurazeo offers strategic guidance, from commercial partnerships to U.S. expansion, as seen with ContentSquare. David’s SoftBank provides long-term capital (12-year funds) and market access (China, Latin America), fostering peace of mind for innovation. This hands-on partnership—$100 million on average to reach unicorn status—ensures rapid scaling, even if profitability lags behind growth.

At Devoxx France 2019, Charles Sabourdin and Jean-Christophe Sirot, seasoned professionals in cloud-native technologies, delivered an extensive exploration of managing application lifecycles within Kubernetes. Charles, an architect with over 15 years in Linux and Java, and Jean-Christophe, a Docker expert since 2002, combined their expertise to demystify Docker’s underpinnings, Kubernetes’ orchestration, and the practicalities of continuous integration and delivery (CI/CD). Through demos and real-world insights, they addressed security challenges across development and business-as-usual (BAU) phases, proposing organizational strategies to streamline containerized workflows. This post captures their comprehensive session, offering a roadmap for developers and operations teams navigating Kubernetes ecosystems.

Docker’s Foundations: Isolation and Layered Efficiency

Charles opened the session by revisiting Docker’s core principles, emphasizing its reliance on Linux kernel features like namespaces and control groups (cgroups). Unlike virtual machines (VMs), which bundle entire operating systems, Docker containers share the host kernel, isolating processes within lightweight environments. This design achieves hyper-density, allowing more containers to run on a single machine compared to VMs. Charles demonstrated launching a container, highlighting its process isolation using commands like ps within a containerized bash session, contrasting it with the host’s process list. He introduced Docker’s layer system, where images are built as immutable, stacked deltas, optimizing storage through shared base layers. Tools like Dive, he noted, help inspect these layers, revealing command histories and suggesting size optimizations. This foundation sets the stage for Kubernetes, enabling efficient, portable application delivery across environments.

Kubernetes: Orchestrating Scalable Deployments

Jean-Christophe transitioned to Kubernetes, describing it as a resource orchestrator that manages containerized applications across node pools. Kubernetes abstracts infrastructure complexities, using declarative configurations to maintain desired application states. Key components include pods—the smallest deployable units housing containers—replica sets for scaling, and deployments for managing updates. Charles demonstrated creating a namespace and deploying a sample application using kubectl run, which scaffolds deployments, replica sets, and pods. He showcased rolling updates, where Kubernetes progressively replaces pods to ensure zero downtime, configurable via parameters like maxSurge and maxUnavailable. The duo emphasized Kubernetes’ auto-scaling capabilities, which adjust pod counts based on load, and the importance of defining resource limits to prevent performance bottlenecks. Their demo underscored Kubernetes’ role in achieving resilient, scalable deployments, aligning with hyper-density goals.

CI/CD Pipelines: Propagating Versions Seamlessly

The session delved into CI/CD pipelines, illustrating how Docker tags facilitate version propagation across development, pre-production, and production environments. Charles outlined a standard process: developers build Docker images tagged with version numbers (e.g., 1.1, 1.2) or environment labels (e.g., prod, staging). These images, stored in registries like Docker Hub or private repositories, are pulled by Kubernetes clusters for deployment. Jean-Christophe highlighted debates around tagging strategies, noting that version-based tags ensure traceability, while environment tags simplify environment-specific deployments. Their demo integrated tools like Jenkins and JFrog Artifactory, automating builds, tests, and deployments. They stressed the need for robust pipeline configurations to avoid resource overuse, citing Jenkins’ default manual build triggers for tagged releases as a safeguard. This pipeline approach ensures consistent, automated delivery, bridging development and production.

Security Across the Lifecycle: Development vs. BAU

Security emerged as a central theme, with Charles contrasting development and BAU phases. During development, teams rapidly address Common Vulnerabilities and Exposures (CVEs) with frequent releases, leveraging tools like JFrog Xray and Clair to scan images for vulnerabilities. Xray integrates with Artifactory, while Clair, an open-source solution, scans registry images for known CVEs. However, in BAU, where releases are less frequent, unpatched vulnerabilities pose greater risks. Charles shared an anecdote about a PHP project where a dependency switch broke builds after two years, underscoring the need for ongoing maintenance. They advocated for practices like running containers in read-only mode and using non-root users to minimize attack surfaces. Tools like OWASP Dependency-Track, they suggested, could enhance visibility into library vulnerabilities, though current scanners often miss non-package dependencies. This dichotomy highlights the need for automated, proactive security measures throughout the lifecycle.

Organizational Strategies: Balancing Complexity and Responsibility

Drawing from their experiences, Charles and Jean-Christophe proposed organizational solutions to manage Kubernetes complexity. They introduced a “1-2-3 model” for image management: Level 1 uses vendor-provided images (e.g., official MySQL images) managed by operations; Level 2 involves base images built by dedicated teams, incorporating standardized tooling; and Level 3 allows project-specific images, with teams assuming maintenance responsibilities. This model clarifies ownership, reducing risks like disappearing maintainers when projects transition to BAU. They emphasized cross-team collaboration, encouraging developers and operations to share knowledge and align on practices like Dockerfile authorship and resource allocation in YAML configurations. Charles reflected on historical DevOps silos, advocating for shared vocabularies and traceable decisions to navigate evolving best practices. Their return-of-experience underscored the importance of balancing automation with human oversight to maintain robust, secure Kubernetes environments.

Links:

• Devoxx France 2019 Video
• Kubernetes Documentation
• Docker Documentation
• JFrog Xray Documentation
• Clair GitHub Repository
• OWASP Dependency-Track
• Dive GitHub Repository

Hashtags: #Kubernetes #Docker #DevOps #CICD #Security #DevoxxFR #CharlesSabourdin #JeanChristopheSirot #JFrog #Clair

At Devoxx France 2019, Frédéric Camblor, a web developer at 4SH in Bordeaux, delivered an insightful session on mastering date and time handling in software applications. Drawing from years of noting real-world issues in a notebook, Frédéric aimed to equip developers with the right questions to ask when working with dates, ensuring they avoid common pitfalls like time zone mismatches, daylight saving time (DST) quirks, and leap seconds.

Understanding Time Fundamentals

Frédéric began by exploring the historical context of time measurement, contrasting ancient solar-based “true time” with modern standardized systems. He introduced Greenwich Mean Time (GMT), now deprecated in favor of Coordinated Universal Time (UTC), which is based on International Atomic Time. UTC, defined by the highly regular oscillations of cesium-133 atoms (9,192,631,770 per second), is geopolitically agnostic, free from DST or seasonal shifts, with its epoch set at January 1, 1970, 00:00:00 Greenwich time.

The distinction between GMT and UTC lies in the irregularity of Earth’s rotation, affected by tidal forces and earthquakes. To align astronomical time (UT1) with atomic time, leap seconds are introduced every six months by the International Earth Rotation and Reference Systems Service (IERS). In Java, these leap seconds are smoothed over the last 1,000 seconds of June or December, making them transparent to developers. Frédéric emphasized the role of the Network Time Protocol (NTP), which synchronizes computer clocks to atomic time via a global network of root nodes, ensuring sub-second accuracy despite local quartz oscillator drift.

Time Representations in Software

Frédéric outlined three key time representations developers encounter: timestamps, ISO 8601 datetimes, and local dates/times. Timestamps, the simplest, count seconds or milliseconds since the 1970 epoch but face limitations, such as the 2038 overflow issue on 32-bit systems (though mitigated in Java). ISO 8601 datetimes (e.g., 2019-04-18T12:00:00+01:00) offer human-readable precision with time zone offsets, enhancing clarity over raw timestamps. Local dates/times, however, are complex, often lacking explicit time zone or DST context, leading to ambiguities in scenarios like recurring meetings.

Each representation has trade-offs. Timestamps are precise but opaque, ISO 8601 is readable but requires parsing, and local times carry implicit assumptions that can cause bugs if not clarified. Frédéric urged developers to choose representations thoughtfully based on application needs.

Navigating Time Zones and DST

Time zones, defined by the IANA database, are geopolitical regions with uniform time rules, distinct from time zone offsets (e.g., UTC+1). Frédéric clarified that a time zone like Europe/Paris can yield different offsets (UTC+1 or UTC+2) depending on DST, which requires a time zone table to resolve. These tables, updated frequently (e.g., nine releases in 2018), reflect geopolitical changes, such as Russia’s abrupt time zone shifts or the EU’s 2018 consultation to abolish DST by 2023. Frédéric highlighted the importance of updating time zone data in systems like Java (via JRE updates or TZUpdater), MySQL, or Node.js to avoid outdated rules.

DST introduces further complexity, creating “local time gaps” during spring transitions (e.g., 2:00–3:00 AM doesn’t exist) and overlaps in fall (e.g., 2:00–3:00 AM occurs twice). Libraries handle these differently: Moment.js adjusts invalid times, while Java throws exceptions. Frédéric warned against scheduling tasks like CRON jobs at local times prone to DST shifts (e.g., 2:30 AM), recommending UTC-based scheduling to avoid missed or duplicated executions.

Common Pitfalls and Misconceptions

Frédéric debunked several myths, such as “a day is always 24 hours” or “comparing dates is simple.” DST can result in 23- or 25-hour days, and leap years (every four years, except centurial years not divisible by 400) add complexity. For instance, 2000 was a leap year, but 2100 won’t be. Comparing dates requires distinguishing between equality (same moment) and identity (same time zone), as Java’s equals() and isEqual() methods behave differently.

JavaScript’s Date object was singled out for its flaws, including inconsistent parsing (dashes vs. slashes shift time zones), zero-based months, and unreliable handling of pre-1970 dates. Frédéric recommended using libraries like Moment.js, Moment-timezone, or Luxon to mitigate these issues. He also highlighted edge cases, such as the non-existent December 30, 2011, in Samoa due to a time zone shift, which can break calendar applications.

Best Practices for Robust Date Handling

Frédéric shared practical strategies drawn from real-world experience. Servers and databases should operate in UTC to avoid DST issues and expose conversion bugs when client and server time zones differ. For searches involving local dates (e.g., retrieving messages by date), he advocated defining a date range (e.g., 00:00–23:59 in the user’s time zone) rather than a single date to account for implicit time zone assumptions. Storing future dates requires capturing the user’s time zone to handle potential rule changes.

For time-only patterns (e.g., recurring 3:00 PM meetings), storing the user’s time zone is critical to resolve DST ambiguities. Frédéric advised against storing times in datetime fields (e.g., as 1970-01-01T15:00:00), recommending string storage with time zone metadata. For date-only patterns like birthdays, using dedicated data structures prevents inappropriate operations, and storing at 12:00 UTC minimizes time zone shift bugs. Finally, he cautioned against local datetimes without time zones, as they cannot be reliably placed on a timeline.

Frédéric concluded by urging developers to question assumptions, update time zone data, and use appropriate time scales. His engaging talk, blending humor, history, and hard-earned lessons, left attendees ready to tackle date and time challenges with confidence.

Links:

• 4SH website
• Frédéric on GitHub
• Frédéric on LinkedIn
• Frédéric’s blog

Hashtags: #DateTime #TimeZones #DST #ISO8601 #UTC #DevoxxFR2019 #FrédéricCamblor #4SH #Java #JavaScript

At Devoxx France 2019, David Wursteisen and Jérémy Martinez, developers at Margot Bank, delivered a candid talk on their experience with Gradle while building a core banking system from scratch. Their 45-minute session, “Gradle, je t’aime: moi non plus,” explored why they chose Gradle over alternatives, its developer-friendly features, script maintenance strategies, and persistent challenges like memory consumption. This post dives into their insights, offering a comprehensive guide for developers navigating build tools in complex projects.

Choosing Gradle for a Modern Banking System

Margot Bank, a startup redefining corporate banking, embarked on an ambitious project in 2017 to rebuild its IT infrastructure, including a core banking system (CBS) with Kotlin and Java modules. The CBS comprised applications for payments, data management, and a central “core” module, all orchestrated with microservices. Selecting a build tool was critical, given the need for speed, flexibility, and scalability. The team evaluated Maven, SBT, Bazel, and Gradle. Maven, widely used in Java ecosystems, lacked frequent updates, risking obsolescence. SBT’s Scala-based DSL added complexity, unsuitable for a Kotlin-focused stack. Bazel, while powerful for monorepos, didn’t support generic languages well. Gradle emerged as the winner, thanks to its task-based architecture, where tasks like compile, jar, and assemble form a dependency graph, executing only modified components. This incremental build system saved time, crucial for Margot’s rapid iterations. Frequent releases (e.g., Gradle 5.1.1 in 2019) and a dynamic Groovy DSL further cemented its appeal, aligning with Devoxx’s emphasis on modern build tools.

Streamlining Development with Gradle’s Features

Gradle’s developer experience shone at Margot Bank, particularly with IntelliJ IDEA integration. The IDE auto-detected source sets (e.g., main, test, integrationTest) and tasks, enabling seamless task execution. Eclipse support, though less polished, handled basic imports. The Gradle Wrapper, a binary committed to repositories, automated setup by downloading the specified Gradle version (e.g., 5.1.1) from a custom URL, secured with checksums. This ensured consistency across developer machines, a boon for onboarding. Dependency management leveraged dynamic configurations like api and implementation. For example, marking a third-party client like AmazingMail as implementation in a web app module hid its classes from transitive dependencies, reducing coupling. Composite builds, introduced in recent Gradle versions, allowed local projects (e.g., a mailer module) to be linked without publishing to Maven Local, streamlining multi-project workflows. A notable pain point was disk usage: open-source projects’ varying Gradle versions accumulated 4GB on developers’ machines, as IntelliJ redundantly downloaded sources alongside binaries. Addressing an audience question, the team emphasized selective caching (e.g., wrapper binaries) to mitigate overhead, highlighting Gradle’s balance of power and complexity.

Enhancing Builds with Plugins and Kotlin DSL

For script maintainers, standardizing configurations across Margot’s projects was paramount. The team developed an internal Gradle plugin to centralize settings for linting (e.g., Ktlint), Nexus repositories, and releases. Applied via apply plugin: 'com.margotbank.standard', it ensured uniformity, reducing configuration drift. For project-specific logic, buildSrc proved revolutionary. This module housed Kotlin code for tasks like version management, keeping build.gradle files declarative. For instance, a Versions.kt object centralized dependency versions (e.g., junit:5.3.1), with unused ones grayed out in IntelliJ for cleanup. Migrating from Groovy to Kotlin DSL brought static typing benefits: autocompletion, refactoring, and navigation. A sourceSet.create("integrationTest") call, though verbose, clarified intent compared to Groovy’s dynamic integrationTest {}. Migration was iterative, file by file, avoiding disruptions. Challenges included verbose syntax for plugins like JaCoCo, requiring explicit casts. A buildSrc extension for commit message parsing (e.g., extracting Git SHAs) exemplified declarative simplicity. This approach, inspired by Devoxx’s focus on maintainable scripts, empowered developers to contribute to shared tooling, fostering collaboration across teams.

Navigating Performance and Memory Challenges

Gradle’s performance, driven by daemons that keep processes in memory, was a double-edged sword. Daemons reduced startup time, but multiple instances (e.g., 5.1.1 and 5.0.10) occasionally ran concurrently, consuming excessive RAM. On CI servers, Gradle crashed under heavy loads, prompting tweaks: disabling daemons, adjusting Docker memory, and upgrading to Gradle 4.4.5 for better memory optimization. Diagnostics remained elusive, as crashes stemmed from either Gradle or the Kotlin compiler. Configuration tweaks like enabling caching (org.gradle.caching=true) and parallel task execution (org.gradle.parallel=true) improved build times, but required careful tuning. The team allocated maximum heap space (-Xmx4g) upfront to handle large builds, reflecting Margot’s resource-intensive CI pipeline. An audience question on caching underscored selective imports (e.g., excluding redundant sources) to optimize costs. Looking ahead, Margot planned to leverage build caching for granular task reuse and explore tools like Build Queue for cleaner pipelines. Despite frustrations, Gradle’s flexibility and evolving features—showcased at Devoxx—made it indispensable, though memory management demanded ongoing vigilance.

Links :

• Devoxx France 2019 Video
• Gradle Documentation
• Kotlin DSL Guide
• Margot Bank
• Ktlint Documentation

Hashtags: #Gradle #KotlinDSL #BuildTools #DavidWursteisen #JeremyMartinez #DevoxxFrance2019

Philippe Botteri and Bernard Liautaud, moderated by Emmanuelle Duten, Editor-in-Chief at Les Echos/Capital Finance, explored how venture capitalists foster European unicorns at VivaTech 2018. Recorded in Paris and available on YouTube, this panel from Accel and Balderton Capital discusses creating ecosystems for startups to thrive. This post, with three subsections, delves into their strategies. Connect with Philippe on LinkedIn and Bernard on LinkedIn. Visit VivaTech.

Building a Robust Ecosystem

Philippe highlights Europe’s progress in producing high-value exits, citing Spotify’s $30 billion exit in 2018, surpassing U.S. (Dropbox, $12 billion) and Asian (Flipkart, $20 billion) counterparts. This shift reflects a maturing ecosystem, with Europe’s 25 unicorns trailing the U.S.’s 110 and China’s 60. Bernard emphasizes the ecosystem’s growth since 2006, driven by experienced entrepreneurs, global VCs, and ambitious talent. Top French universities now see 20-30% of graduates joining startups, not banks, signaling a cultural shift toward innovation.

The availability of capital, especially at early stages, supports this growth. Bernard notes that European funds have tripled in size, fostering competition and higher valuations. However, late-stage funding lags, with European champions raising $1.5 billion on average compared to $7.5 billion for U.S. firms. Philippe sees this as a maturity gap, not a failure, with Europe catching up rapidly through global ambitions and talent influx.

Prioritizing Sustainable Growth

Bernard argues that unicorn status, often driven by a single investor’s enthusiasm, is a misleading metric. He advocates focusing on revenue and long-term impact, aiming to build companies with $1-10 billion in revenue over 10-15 years. A billion-dollar valuation doesn’t guarantee sustainability; some firms reach $1 billion with just $50 million in revenue, only to be acquired. Spotify, generating over $1 billion quarterly, exemplifies the ideal: a scalable, high-revenue business.

Philippe counters that valuations reflect potential, not current worth. A $1 billion price tag signals a VC’s belief in a $5-10 billion future outcome, balanced against the risk of failure. Rapid technology adoption drives larger outcomes, justifying higher valuations. Both agree that sustainable growth requires aligning capital, talent, and ambition to create enduring European giants, not fleeting unicorns.

Navigating Capital and Exits

The influx of late-stage capital, like SoftBank’s $100 billion Vision Fund, creates winner-takes-all dynamics in certain sectors. Bernard notes this gives funded companies an edge but doesn’t suit all industries, where multiple players can coexist. Philippe emphasizes liquidity for employees and founders, critical for retaining talent. Late-stage rounds and secondary sales provide this, delaying IPOs but ensuring stakeholders benefit.

Emmanuelle raises audience concerns about overvaluation and bubbles. Both panelists dismiss bubble fears, describing the market as vibrant, not overheated. Philippe notes that competition on hot deals may inflate valuations, but real metrics—consumer and B2B growth—underpin most successes. Bernard predicts cyclical downturns but sees no systemic risk, with Europe’s ecosystem poised to produce innovative, global leaders.

Links

• YouTube
• Accel
• Balderton Capital
• LinkedIn – Philippe Botteri
• LinkedIn – Bernard Liautaud
• VivaTech

Hashtags: #VivaTech #PhilippeBotteri #BernardLiautaud #Accel #BaldertonCapital #Unicorns #VentureCapital #Spotify #EuropeanStartups