Archive for the ‘en-US’ Category
[KotlinConf2019] Putting Down the Golden Hammer: Pragmatic Kotlin with Huyen Tue Dao
Learning a new programming language, especially one as rich and expressive as Kotlin, often comes with the temptation to use every new feature and syntactic sugar—the “golden hammer”—everywhere. Huyen Tue Dao, a prominent Android developer then known for her work at Trello and her insightful contributions to the Kotlin community, addressed this phenomenon at KotlinConf 2019. Her talk, “Putting Down the Golden Hammer,” shared valuable lessons learned from nearly three years of full-time Kotlin development, emphasizing the importance of pragmatism, readability, and maintainability over merely clever code. Huyen’s insights can often be found on her blog, randomlytyping.com.
Huyen began by acknowledging the allure of Kotlin’s advanced features. While these constructs can be powerful and lead to concise code, she cautioned that their overuse or misuse can sometimes negatively impact code clarity and long-term maintainability. The journey of a developer learning Kotlin often involves an initial phase of enthusiasm for these new tools, followed by a more mature understanding of when and how to apply them judiciously.
The Evolution of a Kotlin Developer’s Approach
Huyen Tue Dao shared her personal evolution in approaching various Kotlin features. She reflected on how code written early in her Kotlin journey might look different from her current practices, shaped by experience, trial, and error. This evolution is natural and signifies a deeper understanding of the language’s nuances and the trade-offs involved in different coding styles.
One key area she touched upon (common in such discussions) is the balance between conciseness and readability. Kotlin allows for very compact code, but sometimes a slightly more verbose approach can be easier for others (and one’s future self) to understand and maintain. She stressed that while Kotlin’s features are designed to make developers more productive, this productivity should not come at the expense of creating code that is difficult to reason about or debug. The goal should be to write “better Kotlin,” which implies code that is not only functionally correct and efficient but also clear, pragmatic, and maintainable.
Pragmatism in Feature Usage: Scope Functions, Nullability, and More
Huyen Tue Dao delved into specific Kotlin features and utilities, discussing both their “fun and shiny” aspects and how they can be overused or even abused. For instance, scope functions (let, run, with, apply, also) are powerful tools for executing a block of code within the context of an object. However, excessive nesting or unclear usage can lead to code that is hard to follow. Huyen advocated for intentionality: choosing the right scope function for the task and ensuring its use enhances clarity rather than obscuring it.
Null safety is another cornerstone of Kotlin, designed to prevent NullPointerExceptions. Huyen discussed the importance of being deliberate about nullability. While Kotlin’s type system helps manage nulls effectively, developers still need to make conscious decisions about whether a type should be nullable and handle nullable types appropriately, without resorting to excessive safe calls (?.) or non-null asserted calls (!!) that might hide underlying design issues. She emphasized being clear about why something is nullable and documenting such decisions when necessary, especially when assumptions about nullability change or when interacting with APIs where null safety guarantees might be different.
Towards Readable and Maintainable Kotlin
Ultimately, Huyen Tue Dao’s message was a call for mindful Kotlin development. She encouraged the audience to revel in Kotlin’s wonderful syntax and features but to always keep readability, maintainability, and pragmatism at the forefront. Understanding the underlying implementation of certain features can also be crucial to avoid potential performance issues.
The aim is not to write code that merely feels “sexy and Kotlin-y” but to craft solutions that are robust, easy for a team to work with, and stand the test of time. Recognizing the potential pitfalls of overusing certain constructs and consciously choosing simpler, clearer alternatives when appropriate leads to what Huyen termed “even better and even more fun Kotlin”. Her talk served as a valuable reminder that true mastery of a language lies not just in knowing its features, but in knowing when and how to use them wisely.
Links:
[DevoxxFR 2019] Micronaut: The Ultra-Light JVM Framework of the Future
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:
Hashtags: #Micronaut #Microservices #DevoxxFR2019 #OlivierRevial #JVMFramework #CloudNative
[VivaTech 2019] Funding and Growing Tomorrow’s Unicorns
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.
[DotCSS2018] DotCSS 2018: Dan Cederholm – Reflections on Two Decades with CSS
Dan Cederholm, a pioneering figure in web design and founder of SimpleBits, reflected deeply on his journey with CSS during his presentation at DotCSS 2018. Drawing from over two decades of experience, he shared lessons that extend far beyond syntax and selectors, touching on resilience, community, and the ephemeral nature of digital creation. Cederholm’s candid recounting of triumphs and setbacks offers timeless wisdom for developers navigating the ever-evolving landscape of web technologies.
Embracing Bold Steps and Community Sharing
Cederholm’s narrative begins in the early 2000s, a period marked by the shift from table-based layouts to CSS-driven designs. He vividly recalls the 2002 redesign of Wired News, a landmark project that propelled the industry forward by abandoning support for outdated browsers like Netscape 4. Inspired by Jeffrey Zeldman’s provocative article “To Hell with Bad Browsers,” Cederholm approached his then-employer, Fast Company magazine, with a proposal to follow suit. To his surprise, his forward-thinking boss greenlit the initiative, leading to a 2003 overhaul that, despite backlash from a shrinking cohort of legacy users, cemented Cederholm’s commitment to progressive standards.
This pivotal moment not only honed his technical skills but also ignited a passion for documentation and mentorship. While iterating on the Fast Company site, Cederholm chronicled his process on a rudimentary blog, despite lacking formal writing credentials. This habit of sharing raw, in-progress insights—complete with the era’s notorious browser bugs—fostered unexpected connections. Invitations to speak and collaborate followed, transforming personal experimentation into professional opportunities. Cederholm underscores a key takeaway: vulnerability in sharing imperfect knowledge builds bridges, turning solitary coding sessions into collaborative dialogues that propel collective advancement.
Moreover, these early risks taught him the value of persistence amid imperfection. The browser wars demanded ingenious workarounds, yet each hack refined his problem-solving acumen. Today, as frameworks proliferate, Cederholm urges newcomers to view challenges not as barriers but as catalysts for growth, reminding us that mastery emerges from repeated trial and adaptation.
Navigating Evolution and Impermanence
As the web matured, so did Cederholm’s toolkit, evolving from vanilla CSS to preprocessors like Sass. Initially resistant—citing concerns over code readability and the philosophy of keeping CSS accessible for novices—he eventually embraced Sass after a colleague’s pragmatic suggestion to simply rename files. This incremental adoption, starting with variables for vendor prefixes and nesting for media queries, revolutionized his responsive workflows. The experience with Sass, much like his initial foray into CSS, highlighted the pitfalls of premature dismissal; what begins as reluctance often blossoms into indispensable efficiency.
Cederholm also touches on broader philosophical shifts, such as his evolving stance on methodologies like Atomic CSS. Initially skeptical of utility class names, he came to appreciate their utility in rapid prototyping, especially within team environments. This openness stems from a core principle: prioritize tools that minimize code volume and maximize clarity. Yet, he tempers enthusiasm with caution, advocating for mindful integration rather than wholesale overhaul.
Ultimately, Cederholm’s reflections circle back to transience. In an industry where innovations cascade rapidly—rendering yesterday’s hacks obsolete—he finds solace in impermanence. Echoing the sentiment of his Adventure pin design, “Everything is stardust,” he posits that the pressure to master every novelty dissipates when viewed against the web’s fleeting canvas. This perspective liberates creators to experiment joyfully, unburdened by the fear of obsolescence. As he concludes, the true legacy of CSS lies not in enduring code but in the enduring habits of curiosity and camaraderie it instills.
Links:
[KotlinConf2019] KotlinConf 2019 Keynote: People, Ideas, and Software in the Kotlin Ecosystem with Andrey Breslav
The opening keynote of KotlinConf 2019, delivered by Andrey Breslav, the then Lead Language Designer for Kotlin at JetBrains, set an inspiring tone for the conference. Addressing a packed room of 1,700 attendees, with many more watching online, Andrey articulated a vision of Kotlin that extends beyond mere syntax and features, emphasizing it as an ecosystem built upon three pillars: people, ideas, and software. His presentation underscored the collaborative spirit that fuels Kotlin’s growth and the continuous feedback loop that shapes its evolution. The official Kotlin language website, central to this ecosystem, is kotlinlang.org.
Andrey Breslav began by reflecting on Kotlin’s journey and its burgeoning community. He highlighted that the success and adoption of Kotlin are deeply intertwined with the people who use it, contribute to it, and advocate for it. This “people-first” perspective was a recurring theme, as he stressed that Kotlin is designed to bring developers together, fostering a common way of working and shared values. The vibrant interactions at KotlinConf itself, with developers from around the world sharing experiences and knowledge, served as a living testament to this community-centric approach.
The Power of Ideas and Continuous Improvement
A core tenet of Kotlin’s development philosophy, as outlined by Andrey Breslav, is the importance of ideas and the relentless pursuit of improvement. He emphasized that the Kotlin team at JetBrains actively seeks and values feedback from the developer community. This feedback loop is critical, whether it comes through direct communication, bug reports, feature requests, or even passively through anonymized usage statistics collected by JetBrains’ IDEs. These statistics, he explained, help the team understand how Kotlin is used in real-world scenarios, identify pain points (like slow code completion in specific environments), and prioritize areas for enhancement.
This data-informed approach allows the Kotlin team to make more effective decisions about the language’s future direction. Andrey encouraged attendees to participate in this feedback process, assuring them that their input, no matter how small, contributes to making Kotlin better for everyone. He cited examples where community feedback directly influenced language features and tooling improvements, reinforcing the idea that Kotlin’s evolution is a collaborative effort. This commitment to listening and adapting ensures that Kotlin remains a pragmatic and powerful tool that addresses the real-world needs of developers.
Software as a Collaborative Endeavor
The third pillar, software, encompasses not only the Kotlin language itself but also the rich ecosystem of libraries, tools, and frameworks that surround it. Andrey Breslav highlighted the importance of this broader ecosystem in making Kotlin a productive and enjoyable language to work with. He acknowledged the contributions of the community in building these resources, from open-source libraries to educational materials and tutorials.
Furthermore, Andrey spoke about JetBrains’ ongoing efforts to enhance the Kotlin tooling, including the compiler and IDE support, to improve performance, stability, and developer experience. He touched upon initiatives aimed at making Kotlin more versatile, enabling its use across various platforms—JVM, Android, JavaScript, Native—and for different types of applications, from server-side systems to mobile apps and web frontends. The keynote celebrated the milestones achieved, such as the growing adoption of Kotlin Multiplatform, while also looking ahead to future challenges and opportunities. Andrey concluded by reiterating that every form of participation, from writing code and tutorials to sharing experiences and even simple social media interactions, adds value to the Kotlin community and contributes to its collective success.
Links:
Navigating the Application Lifecycle in Kubernetes
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
[DotCSS2018] DotCSS 2018: Natalya Shelburne – CSS at the Intersection of Mental Models
Natalya Shelburne, a designer-turned-software-engineer, delivered a thought-provoking talk at DotCSS 2018, exploring CSS as a nexus of diverse mental models. Drawing from her experience as an educator and career switcher, Natalya examines why CSS sparks debates about its efficacy and ownership, advocating for tools that foster collaboration across disciplines.
The Clash of Mental Models
Natalya frames CSS as a battleground where designers and developers, shaped by distinct prior knowledge, encounter cognitive dissonance. A designer accustomed to global styling may find CSS’s cascade intuitive, while a programmer seeking control flow might view it as chaotic. This dissonance, while a natural part of learning, can lead to public frustrations that reinforce silos between job roles.
Natalya argues that these debates—whether CSS is “broken” or “awesome”—stem from the intersection of mental models. By embracing cognitive dissonance as a learning opportunity, developers and designers can grow beyond their comfort zones, fostering a more cohesive industry.
Building Collaborative Tools
To bridge the gap between design and development, Natalya advocates for tools like design systems and prototype environments. She shares an example from a project where a designer proficient in HTML/CSS but not JavaScript collaborated with a JavaScript-focused developer. By creating a style guide and a private prototype route, the team enabled the designer to contribute semantic HTML and CSS, which the developer then connected to data and abstractions. This approach minimized handoff gaps, allowing both team members to expand their skills.
Natalya’s Harvard Extension course further illustrates this philosophy. By assigning roles outside students’ expertise (e.g., a JavaScript developer designing UI), she created a safe space for experimentation, resulting in improved collaboration and skill growth. These tools and practices empower teams to transcend arbitrary barriers, enhancing productivity and creativity.
Embracing Flexibility for Growth
Natalya emphasizes that above-average learning requires deliberate flexibility. By challenging assumptions and embracing discomfort, individuals can become “unicorns”—professionals adept at multiple disciplines. This flexibility not only enhances personal growth but also enables the creation of inclusive tools that empower entire teams. Natalya’s call to action is clear: build interfaces that accommodate diverse mental models, fostering a collaborative and innovative web community.
Links:
[DevoxxFR 2019] Back to Basics: Stop Wasting Time with Dates
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:
Hashtags: #DateTime #TimeZones #DST #ISO8601 #UTC #DevoxxFR2019 #FrédéricCamblor #4SH #Java #JavaScript
Gradle: A Love-Hate Journey at Margot Bank
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 :
Hashtags: #Gradle #KotlinDSL #BuildTools #DavidWursteisen #JeremyMartinez #DevoxxFrance2019
[KotlinConf2019] A Vibrant Gathering of the Global Kotlin Community
KotlinConf 2019, held in Copenhagen, Denmark, from December 4-6, marked a significant moment for the Kotlin ecosystem, bringing together a passionate global community of developers, enthusiasts, and industry leaders. With over 1,600 attendees on-site and many thousands more joining via live stream, the conference was a testament to Kotlin’s burgeoning popularity and its expanding footprint across various domains of software development. The event, meticulously organized by JetBrains, the creators of Kotlin, served as a vibrant hub for knowledge sharing, networking, and celebrating the language’s latest advancements and future directions. The official Kotlin language website, a key resource for developers, is kotlinlang.org.
The atmosphere, as captured in highlight reels and attendee testimonials, was electric, filled with excitement and a shared enthusiasm for the language’s capabilities. Attendees praised the depth of technical talks, the relatability of the content to their daily work, and the motivating nature of keynote presentations that often held an element of suspense regarding new feature announcements. More than just a series of lectures, KotlinConf fostered a strong sense of community, a recurring theme in participants’ feedback, who often cited the community itself as one of the best parts of their Kotlin experience. This collective energy underscored Kotlin’s journey from a promising JVM language to a versatile tool impacting Android development, backend systems, web frontends, and multiplatform projects.
A Hub for Learning and Innovation
KotlinConf 2019 provided a rich learning environment, offering a diverse range of sessions that catered to various skill levels and interests. From in-depth explorations of Kotlin’s newest features to practical workshops and discussions on best practices, the conference was a platform for developers to enhance their skills and gain new perspectives. The content was designed to be both insightful and applicable, with many attendees noting the direct relevance of the talks to their ongoing projects and challenges. This focus on practical application, combined with a forward-looking vision for the language, made the event invaluable for professionals seeking to stay at the forefront of software development.
The conference also served as a crucial touchpoint for JetBrains to engage with the Kotlin community, gather feedback, and share their roadmap for the language’s evolution. This open dialogue is a hallmark of Kotlin’s development philosophy, ensuring that the language continues to meet the needs of its users and adapt to the ever-changing technological landscape. The excitement around new announcements and the opportunity to interact directly with the minds behind Kotlin added an extra layer of dynamism to the event, reinforcing its status as a premier conference for anyone invested in the Kotlin ecosystem. The success of such an event relies heavily on the engagement of its community, from the speakers sharing their expertise to the attendees bringing their curiosity and passion, all contributing to what many described as an “industrial revolution” in software development.