Recent Posts
Archives

Archive for the ‘en-US’ Category

PostHeaderIcon [KotlinConf2018] Taming State with Sealed Classes: Patrick Cousins’ Approach at Etsy

Lecturer

Patrick Cousins is a software engineer at Etsy with nearly 20 years of programming experience, passionate about new patterns and languages. He is known for his work on state management and seal-related puns. Relevant links: Etsy Code as Craft Blog (publications); LinkedIn Profile (professional page).

Abstract

This article examines Patrick Cousins’ use of Kotlin sealed classes to manage complex state in Etsy’s mobile apps. Contextualized in event-driven architectures, it explores methodologies for event streams with RxJava and when expressions. The analysis highlights innovations in exhaustiveness and type safety, contrasting Java’s limitations, with implications for robust state handling.

Introduction and Context

Patrick Cousins spoke at KotlinConf 2018 about sealed classes, inspired by his blog post on Etsy’s engineering site. Etsy’s mobile apps juggle complex state—listings, tags, shipping profiles—forming a “matrix of possibilities.” Sealed classes offer a type-safe way to model these, replacing Java’s error-prone instanceof checks and visitor patterns. This narrative unfolds where mobile apps demand reliable state management to avoid costly errors.

Methodological Approaches to State Management

Cousins modeled state as sealed class hierarchies, emitting events via RxJava streams. Using filterIsInstance and when, he ensured exhaustive handling of state types like Loading, Success, or Error. This avoided Java’s polymorphic indirection, where unrelated types forced artificial interfaces. Sealed classes, confined to one file, prevented unintended extensions, ensuring safety.

Analysis of Innovations and Features

Sealed classes innovate by guaranteeing exhaustiveness in when, unlike Java’s instanceof, which risks missing branches. Kotlin’s final-by-default classes eliminate Liskov substitution issues, avoiding polymorphic pitfalls. RxJava integration enables reactive updates, though requires careful ordering. Compared to Java, sealed classes simplify state logic without forced commonality, though complex hierarchies demand discipline.

Implications and Consequences

Cousins’ approach implies safer, more maintainable state management, critical for e-commerce apps. It reduces bugs from unhandled states, enhancing user experience. Consequences include a shift from polymorphic designs, though developers must adapt to sealed class constraints. The pattern encourages adoption in reactive systems.

Conclusion

Cousins’ use of sealed classes redefines state handling at Etsy, leveraging Kotlin’s type safety to create robust, readable mobile architectures.

Links

PostHeaderIcon [DotCSS2018] DotCSS 2018: Florian Rivoal – Mastering Line Breaking in CSS

Florian Rivoal, a distinguished expert in web standards and co-editor of the CSS Text Module Level 3 specification, delivered an insightful presentation at DotCSS 2018 in Paris. His talk demystifies the intricate world of line breaking in CSS, shedding light on the white-space property and related mechanisms that govern text layout. Florian’s expertise provides a clear lens through which developers can understand and manipulate text wrapping, ensuring both aesthetic and functional precision in web design. This post explores the key concepts Florian presented, offering practical insights for developers aiming to enhance their typographic control.

Understanding the White-Space Property

At the heart of Florian’s discussion lies the white-space property, a cornerstone of text layout in CSS. This property dictates how sequences of spaces, tabs, and line feeds are handled within an element. Florian emphasized its versatility, noting that it applies not only to block elements like paragraphs but also to inline elements such as spans. This flexibility allows developers to fine-tune text behavior across diverse contexts.

For instance, with white-space: normal, spaces around line feeds are collapsed, and line feeds themselves are converted to spaces, enabling natural wrapping. In contrast, white-space: nowrap eliminates wrapping opportunities, keeping text on a single line. Florian also introduced white-space: pre-line, which preserves line breaks as forced breaks while collapsing spaces, and white-space: pre, which retains all whitespace characters, including tabs, without allowing wrapping unless explicitly permitted. The nuanced white-space: pre-wrap and break-spaces variants further refine this behavior, with the latter allowing breaks within sequences of preserved spaces.

These distinctions are critical for developers working on layouts where precise control over text flow is essential, such as in code snippets or poetic formats. By mastering these values, developers can ensure that text aligns with both design intent and user expectations.

Navigating Line Breaking and Overflow

Beyond the white-space property, Florian explored additional tools for managing line breaks, particularly the overflow-wrap property (formerly word-wrap). This property becomes vital when text exceeds its container’s boundaries, provided wrapping is permitted by the white-space setting. For example, overflow-wrap: anywhere allows the browser to break text at any point to prevent overflow, a feature particularly useful in responsive designs.

Florian also delved into the hyphens property, which introduces wrapping opportunities within words. By setting hyphens: auto and specifying the lang attribute, browsers can insert hyphens based on language-specific dictionaries, enhancing readability in languages like English or French. However, he cautioned that incomplete browser support, particularly in Chrome for certain platforms, can pose challenges. Similarly, the word-break and line-break properties offer advanced control, especially for languages like Japanese, where breaking rules differ due to the absence of spaces.

These tools empower developers to craft layouts that respect linguistic nuances while maintaining visual harmony. Florian’s examples, such as preventing unwanted breaks in Japanese text or ensuring poetic line breaks, underscored the practical applications of these properties in real-world scenarios.

Links:

PostHeaderIcon [KotlinConf2018] Implementing Raft with Coroutines and Ktor: Andrii Rodionov’s Distributed Systems Approach

Lecturer

Andrii Rodionov, a Ph.D. in computer science, is an associate professor at National Technical University and a software engineer at Wix. He leads JUG UA, organizes JavaDay UA, and co-organizes Kyiv Kotlin events. Relevant links: Wix Engineering Blog (publications); LinkedIn Profile (professional page).

Abstract

This article analyzes Andrii Rodionov’s implementation of the Raft consensus protocol using Kotlin coroutines and Ktor. Set in distributed systems, it examines leader election, log replication, and fault tolerance. The analysis highlights innovations in asynchronous communication, with implications for scalable, fault-tolerant key-value stores.

Introduction and Context

Andrii Rodionov presented at KotlinConf 2018 on implementing Raft, a consensus protocol used in systems like Docker Swarm. Distributed systems face consensus challenges; Raft ensures agreement via leader election and log replication. Rodionov’s in-memory key-value store demo leveraged Kotlin’s coroutines and Ktor for lightweight networking, set against the need for robust, asynchronous distributed architectures.

Methodological Approaches to Raft Implementation

Rodionov used coroutines for non-blocking node communication, with async for leader election and channel for log replication. Ktor handled HTTP-based node interactions, replacing heavier JavaNet. The demo showcased a cluster tolerating node failures: Servers transition from follower to candidate to leader, propagating logs via POST requests. Timeouts triggered elections, ensuring fault tolerance.

Analysis of Innovations and Features

Coroutines innovate Raft’s asynchronous tasks, simplifying state machines compared to Java’s thread-heavy approaches. Ktor’s fast startup and lightweight routing outperform JavaNet, enabling efficient cluster communication. The demo’s fault tolerance—handling node crashes—demonstrates robustness. Limitations include coroutine complexity for novices and Ktor’s relative immaturity versus established frameworks.

Implications and Consequences

Rodionov’s implementation implies easier development of distributed systems, with coroutines reducing concurrency boilerplate. Ktor’s efficiency suits production clusters. Consequences include broader Kotlin adoption in systems like Consul, though mastering coroutines requires investment. The demo’s open-source nature invites community enhancements.

Conclusion

Rodionov’s Raft implementation showcases Kotlin’s strengths in distributed systems, offering a scalable, fault-tolerant model for modern consensus-driven applications.

Links

PostHeaderIcon [DotCSS2018] DotCSS 2018: Fabien Zibi – Prioritizing Semantic Order in Markup

Fabien Zibi, an accessibility champion with a keen eye for structural integrity, presented a cautionary tale at DotCSS 2018 on the perils of CSS-orchestrated reordering. Analogizing to George Lucas’s nonlinear Star Wars saga, he warns against scripting HTML in defiance of perceptual flow, advocating for markup that stands resilient, styled or stripped. Zibi’s concise admonition bridges styling prowess with equitable reading paths, ensuring assistive technologies mirror visual intent.

The Trap of Layout-Driven Markup

Zibi spotlights CSS Grid’s grid-area as a seductive snare, where named slots tempt authors to scatter content chronologically—say, Star Wars episodes in production sequence—only to reshuffle via styles for release chronology. This sleight, while visually adroit, fractures linear traversal: tabbing or screen reader sweeps adhere to source order, stranding users in narrative disarray.

His exemplar unfolds a gallery of film posters: initial HTML aligns with timeline genesis (Episodes IV-VI preceding prequels), mapped to grid slots via grid-area: movie-one. A stylistic pivot—reassigning areas to broadcast precedence—inverts display sans amending markup, yielding a facade of coherence atop navigational chaos. Keyboard focus leaps erratically, and vocal synthesizers recite anachronisms, eroding trust and efficiency.

Zibi stresses that CSS’s layout lexicon, potent as it is, must defer to HTML’s declarative primacy. Robust documents, he contends, derive meaning intrinsically, unyielding to visual whims— a principle fortifying not just accessibility but future-proof adaptability across devices and parsers.

Forging Resilient, Intent-Aligned Structures

To circumvent such pitfalls, Zibi implores authoring in the precise sequence of consumption: chronological for timelines, hierarchical for documents. This semantic fidelity ensures assistive flows—be they auditory or sequential—echo cognitive journeys, irrespective of stylistic interventions.

Even as Grid and Flexbox liberate from float follies, vigilance persists; properties like order in flex contexts pose analogous risks, demanding source-order primacy. Zibi’s ethos resonates universally: CSS embellishes, but HTML narrates. By embedding intent in markup’s marrow, creators safeguard inclusivity, transforming potential fractures into seamless continuums.

Links:

PostHeaderIcon [KotlinConf2018] Performant Multiplatform Serialization in Kotlin: Eric Cochran’s Approach to Code Sharing

Lecturer

Eric Cochran is an Android developer at Pinterest, focusing on performance across the app stack. He contributes to open-source projects, notably the Moshi JSON library. Relevant links: Pinterest Engineering Blog (publications); LinkedIn Profile (professional page).

Abstract

This article analyzes Eric Cochran’s exploration of Kotlin Serialization for multiplatform projects, emphasizing its role in enhancing code reuse across platforms. Set in the context of Pinterest’s performance-driven Android development, it examines methodologies for integrating serialization with data formats and frameworks. The analysis highlights innovations in type safety and performance, with implications for cross-platform scalability and library evolution.

Introduction and Context

Eric Cochran presented at KotlinConf 2018, focusing on Kotlin Serialization’s potential to unify code in multiplatform environments. As an Android developer at Pinterest, Cochran’s work on serialization formats like Moshi informed his advocacy for Kotlin’s experimental library. The context is the growing need for shared logic in apps targeting JVM, JS, and Native, where serialization ensures seamless data handling across diverse runtimes.

Methodological Approaches to Serialization

Cochran outlined Kotlin Serialization’s setup: Annotate data classes with @Serializable to generate compile-time adapters, supporting JSON, Protobuf, and CBOR. Integration with frameworks like OkHttp or Ktor involves custom serializers for complex types. He demonstrated parsing dynamic JSON structures, emphasizing compile-time safety over Moshi’s runtime reflection. Performance optimizations included minimizing allocations and leveraging inline classes. Cochran compared Moshi’s factory-based API, noting its JVM-centric limitations versus Kotlin Serialization’s multiplatform readiness.

Analysis of Innovations and Features

Kotlin Serialization innovates with compile-time code generation, avoiding reflection’s overhead, unlike Moshi’s Java type reliance. It supports multiple formats, enhancing flexibility compared to JSON-centric libraries. Inline classes reduce boxing, boosting performance. Limitations include poor dynamic type handling and manual serializer implementation for custom cases. Compared to Moshi, it offers broader platform support but lacks mature metadata APIs.

Implications and Consequences

The library implies greater code sharing in multiplatform apps, reducing duplication and maintenance. Its performance focus suits high-throughput systems like Pinterest’s. Consequences include a shift toward compile-time solutions, though experimental status requires caution. Future integration with Okio’s multiplatform efforts could resolve reflection issues, broadening adoption.

Conclusion

Cochran’s insights position Kotlin Serialization as a cornerstone for multiplatform data handling, offering a performant, type-safe alternative that promises to reshape cross-platform development.

Links

PostHeaderIcon [KotlinConf2018] Fostering Collaborative Learning: Maria Neumayer and Amal Kakaiya’s Approach to Team-Based Kotlin Adoption

Lecturers

Maria Neumayer is an Android developer at Deliveroo, specializing in UI since 2010. Originally from Austria, she has worked in London at Citymapper, Path, Saffron Digital, and Rummble. Amal Kakaiya, also an Android engineer at Deliveroo, has coded professionally since 2012. A Glasgow native, he is a triathlete based in East London. Relevant links: Deliveroo Tech Blog (publications); Maria Neumayer’s LinkedIn; Amal Kakaiya’s LinkedIn (professional pages).

Abstract

This article examines Maria Neumayer and Amal Kakaiya’s insights on adopting Kotlin collaboratively within Deliveroo’s Android team. Set against the backdrop of transitioning to Kotlin in production, it explores methodologies like dedicated learning hours and enhanced code reviews. The analysis highlights innovations in fostering openness, combating imposter syndrome, and improving engineering culture, with implications for team dynamics and code quality.

Introduction and Context

At KotlinConf 2018, Maria Neumayer and Amal Kakaiya shared their team’s journey of adopting Kotlin for Deliveroo’s consumer Android app. About one and a half years prior, the team embraced Kotlin, recognizing its learning curve as an opportunity for collective growth. This narrative unfolds in a context where individual learning styles vary, yet collaborative approaches can unify teams, enhance code quality, and nurture a culture of inquiry and knowledge-sharing.

Methodological Approaches to Team Learning

The team implemented structured learning strategies. They allocated weekly Kotlin hours for hands-on practice, encouraging experimentation with features like coroutines. Code reviews shifted from mere correctness checks to learning platforms, where developers shared insights on Kotlin idioms. Pair programming and mob sessions facilitated real-time knowledge exchange, while attending cross-disciplinary talks (e.g., backend conferences) broadened perspectives. They also created forums like “Kotlin Era” to discuss and upskill, ensuring inclusivity.

Analysis of Innovations and Features

The innovation lies in treating learning as a team endeavor, not an individual task. Structured Kotlin hours fostered experimentation, reducing fear of failure. Code reviews as learning tools encouraged constructive feedback, leveraging Kotlin’s concise syntax to highlight best practices. Cross-disciplinary exposure added diverse insights, unlike traditional siloed learning. Compared to solo learning, this approach mitigated imposter syndrome by normalizing questions. Challenges included balancing learning with delivery and ensuring all team members engaged equally.

Implications and Consequences

This collaborative model implies stronger team cohesion and faster Kotlin adoption. By sharing knowledge, teams produce idiomatic, maintainable code, enhancing app quality. The cultural shift toward openness reduces psychological barriers, fostering inclusivity. Consequences include improved processes, though maintaining momentum requires sustained effort and leadership support.

Conclusion

Neumayer and Kakaiya’s approach demonstrates that collaborative learning accelerates Kotlin adoption while strengthening engineering culture. By learning together, teams create not only better code but also a supportive, innovative environment.

Links

PostHeaderIcon [KotlinConf2018] Reflections on Kotlin’s Future: Insights from the KotlinConf 2018 Closing Panel

Lecturers

The panel featured JetBrains and community experts, including Kotlin developers and contributors like Jake Wharton and Venkat Subramaniam. Relevant links: JetBrains Blog (publications); Jake Wharton’s LinkedIn; Venkat Subramaniam’s LinkedIn (professional pages).

Abstract

This article synthesizes the KotlinConf 2018 Closing Panel’s discussions on Kotlin’s roadmap, features, and community growth. Contextualized in Kotlin’s rapid adoption, it examines questions on version 1.3, multiplatform, and concurrency models. The analysis highlights innovations like coroutines, with implications for accessibility, tooling, and future development.

Introduction and Context

The KotlinConf 2018 Closing Panel convened experts to reflect on Kotlin’s trajectory post-version 1.2. Topics ranged from release timelines to Kotlin/Native’s concurrency model and beginner accessibility. Set against Kotlin’s appeal to Java developers and its expanding multiplatform scope, the panel addressed community concerns and future directions, emphasizing JetBrains’ commitment to a robust ecosystem.

Methodological Approaches to Panel Discussion

Panelists addressed audience queries systematically. On version 1.3, they outlined stabilization goals, followed by post-1.3 focus on multiplatform libraries. Kotlin/Native’s distinct memory model was justified for safety, contrasting JVM threads. For beginners, they recommended community resources like Kotlin Slack. Coroutines were compared to RxJava, favoring simplicity for sequential tasks. Dokka improvements and GPU programming were acknowledged as future explorations.

Analysis of Innovations and Features

Kotlin 1.3 introduced stable coroutines, enhancing asynchronous programming versus RxJava’s complexity. Kotlin/Native’s concurrency model avoids shared mutable state, unlike iOS or JVM, ensuring safety but requiring adaptation. Multiplatform libraries promise code reuse, though Angular integration remains unexplored. The panel emphasized restraint in using Kotlin’s vast features to maintain readability, addressing its steep learning curve.

Implications and Consequences

The panel’s insights imply Kotlin’s evolution toward a versatile, beginner-friendly language. Coroutines simplify concurrency, but Native’s model may slow adoption. Enhanced tooling like Dokka and potential GPU support could broaden applications. Consequences include a growing community, though developers must balance feature richness with clarity to avoid complexity.

Conclusion

The KotlinConf 2018 Closing Panel illuminated Kotlin’s path as a multiplatform powerhouse, balancing innovation with accessibility, poised for continued growth with community feedback shaping its future.

Links

PostHeaderIcon [KotlinConf2018] Advancing Metaprogramming with Kotlin and TornadoFX: Amanda Hinchman-Dominguez’s Exploration

Lecturer

Amanda Hinchman-Dominguez, a Grinnell College ’17 alum, specializes in UI development for sales enablement. With experience at Prudential and Cisco, she is also a sculptor. Relevant links: TornadoFX GitHub (project); LinkedIn Profile (professional page).

Abstract

This article analyzes Amanda Hinchman-Dominguez’s exploration of Kotlin and TornadoFX for metaprogramming, addressing crosscutting concerns in software design. Contextualized in the limitations of Java’s OOP, it examines Aspect-Oriented Programming (AOP) via TornadoFX’s type-safe builders. The analysis highlights innovations in UI automation and test generation, with implications for scalability and modularity.

Introduction and Context

At KotlinConf 2018, Amanda Hinchman-Dominguez presented her early research on Kotlin and TornadoFX, a JavaFX framework leveraging Kotlin’s features. Software complexity demands modular, scalable solutions, but Java’s OOP struggles with crosscutting concerns like logging or UI consistency. TornadoFX’s type-safe builders and Kotlin’s low-ceremony syntax offer a foundation for AOP and metaprogramming, set in the context of her work to automate UI development and testing.

Methodological Approaches to Metaprogramming

Hinchman-Dominguez used TornadoFX’s builders to create declarative UI code, reducing boilerplate. She experimented with metaprogramming to generate UI tests dynamically, collecting data to predict bugs or suggest designs. Her approach involved defining aspects (e.g., validation rules) to separate concerns, using Kotlin’s lambdas and extensions for fluent APIs. Examples included generating UI components and tests, leveraging TornadoFX’s community-driven development.

Analysis of Innovations and Features

TornadoFX innovates with type-safe, declarative UI construction, contrasting Java’s verbose reflection. Kotlin’s lambdas enable AOP-like separation, addressing crosscutting issues. Test generation predicts bugs, a step toward reinforcement learning. Compared to JavaFX alone, TornadoFX simplifies UI logic. Limitations include her project’s early stage and messy code, requiring community contributions for maturity.

Implications and Consequences

This approach implies automated, scalable UI development, reducing repetitive tasks. It could lead to data-driven design tools, enhancing productivity. Consequences include a steeper learning curve for AOP, but open-source collaboration mitigates this, fostering innovation in Kotlin’s ecosystem.

Conclusion

Hinchman-Dominguez’s work with TornadoFX showcases Kotlin’s potential for metaprogramming, paving the way for modular, automated software design with significant future impact.

Links

PostHeaderIcon [KotlinConf2018] Architecting iOS with Kotlin Multiplatform: Kevin Galligan’s Vision for Mobile Convergence

Lecturer

Kevin Galligan is president of Touchlab, a mobile development firm. He organizes Droidcon NYC and the New York Android meetup, focusing on platform convergence. Relevant links: Touchlab Blog (publications); LinkedIn Profile (professional page).

Abstract

This article traces Kevin Galligan’s overview of Kotlin Multiplatform for Android and iOS. Set in the rise of multiplatform libraries, it examines shared architecture patterns, inspired by Google’s J2ObjC. The analysis highlights methodologies for repositories and concurrency, with implications for cross-platform consistency and library ecosystems.

Introduction and Context

Kevin Galligan addressed KotlinConf 2018, reflecting on 2016’s J2ObjC experiments. Kotlin Multiplatform, enabling shared Android-iOS logic, was poised for growth in 2018-2019. Galligan reviewed libraries, gaps, and resources, set against Touchlab’s mobile expertise and community engagement.

Methodological Approaches

Galligan proposed a shared repository pattern, using expect/actual for platform-specific database access. Concurrency used frozen objects for thread safety, with Android bypassing freezing. Libraries like SQLDelight and Ktor were highlighted, with coroutines noted as immature for Native.

Analysis of Innovations and Features

Multiplatform innovates code reuse, reducing duplication. Expect/actual abstracts platform differences. Compared to J2ObjC, Kotlin offers native compilation. Limitations include coroutine readiness and freezing complexity.

Implications and Consequences

Galligan’s vision implies unified mobile architectures, streamlining development. It fosters a growing library ecosystem.

Conclusion

Galligan’s insights herald Kotlin Multiplatform’s role in mobile convergence, urging library development.

Links

PostHeaderIcon [KotlinConf2018] Crafting Fluent Internal DSLs in Kotlin: Venkat Subramaniam’s Guide to Domain-Specific Languages

Lecturer

Dr. Venkat Subramaniam is an award-winning author, founder of Agile Developer, Inc., and a professor at the University of Houston. He mentors developers globally and has authored books like Practices of an Agile Developer. Relevant links: Agile Developer Website (publications); LinkedIn Profile (professional page).

Abstract

This article delves into Venkat Subramaniam’s exploration of creating internal domain-specific languages (DSLs) in Kotlin. Set in the context of reducing code ceremony, it analyzes Kotlin’s features like infix notation and implicit receivers. Methodologies for fluent APIs and implications for domain-driven design are highlighted, emphasizing Kotlin’s suitability for expressive DSLs.

Introduction and Context

Venkat Subramaniam presented at KotlinConf 2018 on crafting internal DSLs, which offer concise, context-aware syntax for specific domains. Kotlin’s low-ceremony nature and behavioral injection make it ideal for DSLs, unlike Java’s rigidity. This narrative unfolds where developers seek to encapsulate domain logic fluently, enhancing readability and maintainability in agile projects.

Methodological Approaches to DSL Creation

Subramaniam began with DSL characteristics: fluency, conciseness, and implicit context. He used Kotlin’s infix functions for natural syntax (e.g., 1 plus 2). Lambda-with-receiver enabled context objects, allowing methods like left or right within a scope. Extension functions injected behavior, while lexical scoping resolved properties dynamically. Examples included a report DSL, where configurations were set declaratively, and a context-switching DSL for flexible execution.

Analysis of Innovations and Features

Kotlin’s infix notation innovates by mimicking natural language, reducing syntactic noise. Implicit receivers create intuitive contexts, unlike Java’s explicit calls. Extension functions enable seamless domain extensions. Compared to external DSLs, internal DSLs leverage Kotlin’s compiler safety. Limitations include working within Kotlin’s constraints, requiring careful design to avoid ambiguity.

Implications and Consequences

Subramaniam’s DSLs imply more readable domain code, aligning with business logic. They enhance maintainability in complex systems, though require upfront design effort. Consequences include broader adoption of Kotlin for domain-driven projects, with open-source examples fostering community contributions.

Conclusion

Subramaniam’s guide underscores Kotlin’s prowess for internal DSLs, offering a blueprint for fluent, maintainable domain code that elevates software design.

Links