# dsl Published articles for dsl. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Refactoring Should NOT Touch Your Acceptance Tests DevFeed: [Refactoring Should NOT Touch Your Acceptance Tests]() Original publisher: [Read original article]() Author: Valentina Jemuović Published: 2026-09-03T06:00:37Z Content type: opinion Language: en Sources: [Optivem Journal]() Topics: [Refactoring](), [Pull Request](), [test]() Tags: [change](), [dsl](), [refactor](), [refactoring](), [test](), [tests]() ### AI overview The article argues that a refactoring pull request should not change acceptance tests or their DSL, because doing so changes behavior rather than merely restructuring code. ### Source excerpt A "refactor" PR that changes the acceptance test or the DSL isn't a refactor -- it's a behavioral change ## Three Gradle Talks from KotlinConf 2026 (and What to Steal from Each) DevFeed: [Three Gradle Talks from KotlinConf 2026 (and What to Steal from Each)]() Original publisher: [Read original article]() Author: Laura Kassovic Published: 2026-07-28T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [Kotlin](), [Groovy](), [ide](), [Scripting](), [Refactoring]() Tags: [2026](), [best-practices](), [build](), [build-tool](), [conference](), [developer](), [dsl](), [event](), [gradle](), [groovy](), [ide](), [kotlin](), [kotlinconf](), [refactoring](), [script](), [scripting](), [talk](), [talks]() ### AI overview The article reviews three Gradle talks from KotlinConf 2026. It explains the progression from Groovy build scripts to the Kotlin DSL and early Declarative Gradle, emphasizing the problems each approach addresses. It also introduces Gradle best practices for organizing and optimizing builds. ### Source excerpt Every year I tell myself I'll watch every conference talk I missed. Every year I get through maybe three before a build breaks and I get pulled back into real life. KotlinConf is the one event where I actually follow through, partly because the talks are short and dense, and partly because a good chunk of my coworkers and friends are on stage. This year in Munich, three of them talked about Gradle: Paul Merlin on the history of our DSLs, Stefan Wolf on best practices, and Marcin Mycek on Declarative Gradle for Kotlin. I watched all three so you can decide which ones are worth your fifteen minutes. A Tale of the Gradle DSLs -- Paul Merlin Paul has been inside Gradle's DSL machinery for years, which makes him exactly the right person to tell this story and exactly the wrong person to pretend the early days were clean. The talk traces how build logic went from Groovy, to the Kotlin DSL, to Declarative Gradle. The useful part isn't the timeline. It's that each of those was solving a real problem the previous one couldn't. Groovy gave us a flexible, dynamic scripting language, which was great right up until you wanted your IDE to tell you what was valid. The Kotlin DSL brought static typing, real autocompletion, and refactoring that doesn't rely on hope. That's why the Kotlin DSL is now the default for new Gradle builds. Declarative Gradle is the next swing: describe what your build is rather than script how it runs. The honest through-line is that none of these fully replaces the last one. Kotlin DSL is where most people should be today. Groovy still runs an enormous amount of the world's build logic and isn't going anywhere fast. Declarative Gradle is early but points at where things are headed. Real talk: if your build scripts are still Groovy and still working, you don't have to panic-migrate this weekend. But if you're starting something new, reach for the Kotlin DSL and let the IDE carry some of the weight. 📺 Watch the talk 10 Gradle Best Practices Every Kotlin Deve ## A Practical guide to building a parser in Go DevFeed: [A Practical guide to building a parser in Go]() Original publisher: [Read original article]() Author: Tom Published: 2026-01-04T00:00:00Z Content type: tutorial Language: en Sources: [Tomasz Gągor]() Topics: [Go Language](), [Parser](), [Programming](), [Programming language]() Tags: [bnf](), [compilers](), [dsl](), [go](), [guide](), [left-recursion](), [lexer](), [packrat-memoization](), [parsing](), [programming](), [recursive-descent-parser]() ### AI overview A developer describes building a recursive descent parser in Go to validate strings against a BNF-like grammar. The project began as an attempt to implement a simple BNF syntax analyzer and led to exploring parser and compiler concepts, including left recursion and Packrat memoization. ### Source excerpt A developer's journey of building a recursive descent parser in Go, from basic concepts to tackling left recursion with Packrat memoization. ## Rafinad: сахар для UI-тестирования iOS-приложений DevFeed: [Rafinad: сахар для UI-тестирования iOS-приложений]() Original publisher: [Read original article]() Author: almazrafi (hh.ru) Published: 2025-05-26T08:35:00Z Content type: tutorial Language: ru Sources: [HeadHunter RU]() Topics: [iOS](), [Open Source](), [ui]() Tags: [dsl](), [ios](), [open-source](), [source](), [swift](), [swiftui](), [tag-e932065bc8da](), [ui](), [ui-3e41457d883f](), [ui-5cd5d1ae7fcb](), [uikit](), [xctest](), [xcuitest]() ### AI overview The article introduces Rafinad, an open-source project from hh for UI testing of iOS applications. It explains why the company is revisiting its older testing approach and demonstrates common UI-test implementations, including explicit element identification and shared identifier sources. ### Source excerpt Мы в hh очень любим UI-тесты, ими покрывается практически вся функциональность наших приложений, и даже backend-разработчики прогоняют тесты мобильных платформ перед развертыванием своих фич. Однако наши механизмы UI-тестирования разрабатывались более 8 лет назад и с тех пор почти не изменились. Кто-то скажет, что старые решения прошли проверку временем и что "работает -- не трогай"... Возможно, и так. Но сейчас мы внедряем новую дизайн-систему, а новые компоненты требуют адаптации всех тестов -- не лучшее ли время для перемен? Поэтому мы пересмотрели наши подходы к UI-тестированию и теперь готовы поделиться наработками с сообществом в виде open-source проекта -- Rafinad. В этой статье расскажем, что он умеет и как им пользоваться. Читать далее ## Configure Karabiner on macOS with Kotlin DevFeed: [Configure Karabiner on macOS with Kotlin]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2025-05-17T20:23:40Z Content type: tutorial Language: en Sources: [Kaushik Gopal's Site]() Topics: [Kotlin](), [macOS](), [configuration](), [JSON](), [TypeScript]() Tags: [configuration](), [dsl](), [how-to](), [json](), [keyboard](), [kotlin](), [macos](), [open-source](), [productivity](), [re](), [repo]() ### AI overview This tutorial introduces karabiner-kt, a Kotlin-based DSL for managing Karabiner keyboard configurations on macOS. It addresses the difficulty of maintaining large karabiner.json files and shows how Kotlin rules can generate the JSON consumed by Karabiner. ### Source excerpt If you're obsessed with productivity hacks, you've probably heard of Karabiner - the ultimate tool for keyboard customization on macOS. But maintaining Karabiner's config is a pain. In this post I'll show you a simpler, Kotlin-powered way to wrangle your Karabiner setup, so you don't have to wrestle with massive, unwieldy JSON. On Karabiner ## Here's the gist: Karabiner lets you intercept any keystroke and remap it to... well, pretty much anything. Want to turn Caps Lock into a Hyper key? Make your keyboard launch confetti? It's all possible. Take the classic usecase: remap Caps Lock to Hyper (⌘⌥⌃⇧) when held, Escape when tapped. That's easy to do but just scratches the surface. With Karabiner, you can build many more customizations that supercharge your workflow. Maintaining that karabiner.json ## I was watching a video by Max Stoiber where he uses Raycast1 & Karabiner. But what struck me was how he customized and maintained his karabiner setup. Karabiner runs off a single .json config file. But that .json configuration can become unwieldy and difficult to manage, as your rules grow in complexity. For example: I require a ~2700 line .json for all my hacks. It's impossible to maintain it as pure json. Max uses TypeScript to maintain his rules -which then compiles down to a .json file- that Karabiner can consume. I really like this approach. If you read my previous blog post, I also ran into a very similar problem and used goku, which in turn used the very esoteric and terse edn format. I like TypeScript over edn but you know what I'd like even better? Kotlin! So on a ✈ ride back home, I decided to whip up karabiner-kt. I'm really happy with my solution. Kotlin affords a much more pleasant DSL than most other2 languages. Here's what a Karabiner rule looks like in Kotlin : karabinerRule { description = "Right Cmd -> Ctrl (Enter alone)" mapping { fromKey = RightCommand toKey = RightControl toKeyIfAlone = KeyCode.ReturnOrEnter forDevice { identifiers = DeviceIdentifier.A ## First look at Declarative Gradle DevFeed: [First look at Declarative Gradle]() Original publisher: [Read original article]() Author: Sterling Greene Published: 2024-07-24T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [configuration](), [developer tooling](), [Groovy](), [Kotlin]() Tags: [beginners](), [blog-post](), [community](), [configuration](), [developer-tooling](), [dsl](), [eap](), [experimental](), [gradle](), [groovy](), [improvements](), [kotlin](), [preview]() ### AI overview This article introduces the first early access preview of Declarative Gradle, an experimental project aimed at providing a clearer, developer-first declarative build language for Gradle. It describes the Declarative Configuration Language, its relationship to Kotlin syntax, the .gradle.dcl file format, and the restrictions that exclude imperative constructs such as loops, conditionals, and functions. The preview is intended for feedback and is not ready for production use. ### Source excerpt Introduction In our update in November 2023, we announced a new experimental project called Declarative Gradle. That post introduced our ideas for a developer-first software definition and how we planned to fulfill our vision for a declarative build language for Gradle. Since then, we've been working hard to create the first early access preview (EAP) of Declarative Gradle. This blog post provides an update on the project's progress and outlines how you can try it out, provide feedback, and influence our next steps. What is Declarative Gradle? Part of our vision for Gradle Build Tool is to deliver an elegant and extensible declarative build language that allows developers to describe any kind of software in a clear and understandable way. Gradle's build language is already extensible in the most fundamental ways, which results in a high degree of flexibility, but it's not always fully declarative, clear, and understandable. We believe that Declarative Gradle will offer a fundamental advancement in the Gradle user experience for software developers thanks to a developer-first software definition, a declarative DSL, and improvements in developer tooling made possible by these. Note that Declarative Gradle is still in an experimental stage and is not ready for production use. We are providing an early access preview to gather initial feedback from the community. Declarative Configuration Language Gradle's existing Kotlin and Groovy DSLs give users access to a full programming language and ecosystem. This makes build scripts very powerful, but it can also make it harder for beginners to understand them and for vendors to provide tooling on top of Gradle. With Declarative Gradle, we're introducing a new configuration language. In addition to .gradle and .gradle.kts build files, Gradle will also recognize .gradle.dcl, where DCL stands for "Declarative Configuration Language". This language falls into the family of declarative configuration languages, meaning it is non-pro ## Why you should consider migrating your Gradle scripts to Kotlin DSL DevFeed: [Why you should consider migrating your Gradle scripts to Kotlin DSL]() Original publisher: [Read original article]() Published: 2023-05-10T00:00:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [Gradle](), [Kotlin](), [domain-specific language](), [Development]() Tags: [build](), [code-analysis](), [code-completion](), [dependencies](), [development-process](), [dsl](), [gradle](), [interoperability](), [kotlin](), [migrate](), [workshop-learning-programming]() ### AI overview This article explains Gradle Kotlin DSL, describing its benefits over Groovy-based Gradle scripts, including static typing, code completion, type-safe APIs, concise syntax, and improved maintainability. It also outlines steps for migrating build scripts to Kotlin DSL. ### Source excerpt Discover the benefits of migrating your Gradle scripts to Kotlin DSL and streamline your development process. ## Leveraging the Plain Old Python Function DevFeed: [Leveraging the Plain Old Python Function]() Original publisher: [Read original article]() Published: 2022-12-14T09:00:00Z Content type: article Language: en Sources: [Stitch Fix]() Topics: [Python](), [MLOps](), [Data Science](), [Framework](), [Deployment]() Tags: [apis](), [blog-post](), [dsl](), [functional](), [microservices](), [mlops](), [model-deployment](), [python]() ### AI overview Stitch Fix describes a function-first approach to data science APIs and MLOps. Instead of building custom model-deployment mechanisms, microservices, and tightly coupled data transformations, data scientists can use plain Python functions backed by platform infrastructure. ### Source excerpt The role of the full-stack-data-scientist is not what it once was. With the advent of more powerful tooling, new industry standards in MLOps, and greater investment in platforms, the day-to-day of a data scientist has changed significantly at Stitch Fix. The difference, however, is subtle. The structure of their job remains the same - engineers still do not write ETLs and data scientists function as generalists, but they now have to think on a higher level. Their job is constantly getting more and more complex--the business needs are in flux and the infrastructure they use is more powerful than it ever was. The old strategy of cobbling together complex systems will only end in stressed-out data scientists with too much infrastructure on their plate. To avoid this cycle of complexity, Stitch Fix invests in a platform team to innovate new ways of supporting a data scientist's engineering needs. Rather than constructing custom model-deployment mechanisms, building microservices from the ground up, and managing highly interdependent chains of data transformations, data scientists at Stitch Fix can leverage powerful infrastructure by constructing plain old Python functions to represent their needs. In this blog post we're going to take a different approach than usual. Rather than digging into a specific piece of technology, we'll present our philosophy of functions for data science APIs and back it up with some motivating examples. We'll explain the power of functions as a DSL, share some successes we've had using functional interfaces to build our MLOps stack, and connect our approach with external, open-source frameworks that the industry is beginning to adopt. Our goal is to convince you that a function-first approach will enable data practitioners to do more while doing less. The functional approach allows them to plug into the business in a scalable manner while avoiding the complexity of managing infrastructure and architectural decisions. On Functions and Functiona ## DSL type-safe builders DevFeed: [DSL type-safe builders]() Original publisher: [Read original article]() Published: 2022-09-09T00:04:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [domain-specific language](), [Kotlin](), [Gradle](), [Programming](), [Jetpack Compose](), [React](), [SwiftUI](), [JavaFX]() Tags: [domain-specific-language](), [domain-specific-languages](), [dsl](), [gradle](), [groovy](), [how-to](), [javascript](), [jetpack-compose](), [kotlin](), [programming](), [swift](), [swiftui](), [type](), [workshop-learning-programming]() ### AI overview A tutorial on type-safe DSL builders in Kotlin. It explains how Gradle configurations moved from Groovy toward Kotlin DSLs, covering static typing, editor suggestions, typo detection, helper functions, classes, and lambda expressions. It also discusses DSL use in React, backend HTML, SwiftUI, Jetpack Compose, and desktop applications. ### Source excerpt How to define type-safe DSL builders in Kotlin. ## A Brief Overview over the Most Common jOOQ Types DevFeed: [A Brief Overview over the Most Common jOOQ Types]() Original publisher: [Read original article]() Author: lukaseder Published: 2022-09-06T12:30:37Z Content type: tutorial Language: en Sources: [jOOQ]() Topics: [SQL](), [API](), [Databases](), [Structured-data]() Tags: [api](), [api-design](), [cheat-sheet](), [configuration](), [context](), [dependency-injection](), [dsl](), [jdbc](), [jooq](), [jooq-3-17](), [jooq-in-use](), [logging](), [overview](), [queryparts](), [r2dbc](), [sql](), [syntax](), [type-system](), [types]() ### AI overview This tutorial provides a cheat sheet of the most important types in the jOOQ API, covering configuration, scopes, settings, and DSL APIs. It notes that jOOQ 3.17 includes more than 160 settings and explains how several type groups support query construction, execution, lifecycle management, and dependency injection. ### Source excerpt For new users working with jOOQ for the first time, the number of types in the jOOQ API can be overwhelming. The SQL language doesn't have many such "visible" types, although if you think about SQL the way jOOQ does, then they're there just the same, but hidden from users via an English style syntax. ... Continue reading A Brief Overview over the Most Common jOOQ Types -> ## Exploring Kotlin's Context Receivers DevFeed: [Exploring Kotlin's Context Receivers]() Original publisher: [Read original article]() Author: Simon Vergauwen Published: 2022-02-17T00:00:00Z Content type: article Language: en Sources: [nomisRev]() Topics: [Kotlin](), [ide](), [context]() Tags: [compiler](), [dsl](), [effect](), [extension-function](), [fp](), [function](), [ide](), [kotlin](), [scope-functions](), [suspend]() ### AI overview A tutorial on Kotlin Context Receivers, introduced as a preview in Kotlin 1.6.20-M1. It explains how additional receivers work, how the compiler handles them, and how they can support scope-based programming patterns such as effect handlers and logging contexts. ### Source excerpt Last week a long awaited feature was released as a preview in Kotlin 1.6.20-M1. In this blogpost we're going to explore what Context Receivers are, and some benefits and patterns they'll enable. To try it out in your IDE, follow this guide ## Kotlin's inline and suspend features DevFeed: [Kotlin's inline and suspend features]() Original publisher: [Read original article]() Author: Simon Vergauwen Published: 2022-01-18T00:00:00Z Content type: article Language: en Sources: [nomisRev]() Topics: [Kotlin](), [inlining](), [async](), [Compiler]() Tags: [async](), [callback](), [compiler](), [concurrency](), [continuation](), [dsl](), [function](), [hof](), [inlining](), [kotlin](), [suspend]() ### AI overview This article explains Kotlin's inline feature and suspend functions, focusing on how their combination supports efficient higher-order functions and imperative code for asynchronous workflows. It also describes compiler checks for suspending calls. ### Source excerpt Over the last several years I've seen many discussions on Kotlin's features. Nullability is always a very high ranked one. I like it, but it's definitely not my favorite feature. ## Introducing PathQuery, Google's Graph Query Language DevFeed: [Introducing PathQuery, Google's Graph Query Language]() Original publisher: [Read original article]() Published: 2021-06-30T13:23:37Z Content type: article Language: en Sources: [Lambda the Ultimate]() Topics: [Graphs](), [Query (disambiguation)](), [Google](), [data](), [Code](), [Latency](), [Optimization](), [modules](), [Object-relational mapping]() Tags: [code](), [data](), [declarative](), [dsl](), [google](), [graph](), [latency](), [mapping](), [module](), [optimization](), [semantics]() ### AI overview The article introduces PathQuery, a graph query language developed at Google to handle large query and data volumes and support its internal developer community. It describes declarative graph-traversal syntax, a foundation in a custom relational algebra variant, optimization opportunities, and a module and compilation system for reuse across projects. ### Source excerpt Introducing PathQuery, Google's Graph Query Language We introduce PathQuery, a graph query language developed to scale with Google's query and data volumes as well as its internal developer community. PathQuery supports flexible and declarative semantics. We have found that this enables query developers to think in a naturally "graphy" design space and to avoid the additional cognitive effort of coordinating numerous joins and subqueries often required to express an equivalent query in a relational space. Despite its traversal-oriented syntactic style, PathQuery has a foundation on a custom variant of relational algebra -- the exposition of which we presently defer -- allowing for the application of both common and novel optimizations. We believe that PathQuery has withstood a "test of time" at Google, under both large scale and low latency requirements. We thus share herein a language design that admits a rigorous declarative semantics, has scaled well in practice, and provides a natural syntax for graph traversals while also admitting complex graph patterns. Things that are somewhat interesting to me, from an engineering standpoint: 1. PathQuery has a module/compilation system, enabling re-use of PathQuery modules across projects. (Someone had mentioned that Google has around 40,000 PathQuery modules already, internally...) 2. PathQuery supports native functions so that some query pieces can be evaluated procedurally (peephole optimization) 3. Use of relational algebra to enable a lot of known optimizations, plus future optimizations Also, from a socio-linguistic perspective, Graph Languages are effectively the new Object-Relational Mapping layer, but they solve an interesting organizational problem of allowing multiple teams to code in different languages, without needing to re-write / re-implement entities and mapping configurations in each language. It's the Old New Thing again... ## Writing First-Class Features: BDD and Gherkin. DevFeed: [Writing First-Class Features: BDD and Gherkin.]() Original publisher: [Read original article]() Author: Fernando Cejas (me@fernandocejas.com) Published: 2021-01-23T00:00:00Z Content type: tutorial Language: en Sources: [Fernando Cejas Blog]() Topics: [Behavior-driven development](), [domain-specific language](), [Development](), [Programming]() Tags: [android](), [bdd](), [communication](), [culture](), [development](), [domain-specific-language](), [dsl](), [engineering](), [feature](), [framework](), [infrastructure](), [ios](), [java](), [kotlin](), [linux](), [open-source](), [organization](), [processes](), [programming](), [python](), [rust](), [scala](), [software](), [software-development](), [web-development](), [writing]() ### AI overview The article explains how behavior-driven development (BDD) and the Gherkin domain-specific language can establish a shared vocabulary for writing software features. It presents BDD as a collaborative process involving developers, QA, and business participants, and describes how structured natural-language scenarios can express behavior and acceptance criteria. ### Source excerpt As our product evolves, **there is the need to adopt a common vocabulary**, interpreted by all the moving parts of our organization: business users, analysts, managers, engineers, etc. **A technique like BDD and the Gherkin language can help us to achieve this goal**. ## Collection like objects in python DevFeed: [Collection like objects in python]() Original publisher: [Read original article]() Published: 2020-04-15T00:00:00Z Content type: tutorial Language: en Sources: [Paweł Chudzik]() Topics: [Python](), [Programming](), [Protocol (disambiguation)](), [Code]() Tags: [behavior](), [class](), [collections](), [dsl](), [functional](), [list](), [programming-language](), [protocol](), [python](), [set](), [slices]() ### AI overview A tutorial on implementing Python collection-like objects using the collections protocol. It discusses slices and methods such as __getitem__, __setitem__, __delitem__, __iter__, __contains__, and __missing__, including how they support collection behavior and domain-specific language extensions. ### Source excerpt Collections are an important part of every programming language. In python, there is a couple of built-in collections like list, set, dictionary but I'm not going to dig into them now. In this post, I'll explore what it takes to implement collection like objects on your own using collections protocol. Read more ## Making OpenAPI / Swagger Bearable With Your Own DSL DevFeed: [Making OpenAPI / Swagger Bearable With Your Own DSL]() Original publisher: [Read original article]() Author: Sebastien Armand Published: 2019-08-02T19:00:00Z Content type: tutorial Language: en Sources: [Square Corner Blog](), [Square Corner Blog RSS Feed]() Topics: [OpenAPI Specification](), [Racket](), [Programming]() Tags: [domain-specific-language](), [dsl](), [engineering](), [json](), [openapi](), [swagger](), [yaml]() ### AI overview The article explains how to use Racket to create a domain-specific language for defining OpenAPI documents. It addresses the verbosity, limited composability, and multi-file maintenance problems of handwritten OpenAPI, describing a DSL that produces YAML or JSON and reduced specification files from about 1,000 lines to about 100. ### Source excerpt Taming OpenAPI using Racket to create a DSL ## GPIO port for Raspberry Pi DevFeed: [GPIO port for Raspberry Pi]() Original publisher: [Read original article]() Author: Nenad Rakocevic (noreply@blogger.com) Published: 2019-07-18T16:08:00Z Content type: release Language: en Sources: [Red]() Topics: [Raspberry Pi](), [Hardware](), [API](), [Code](), [Software](), [GTK]() Tags: [3](), [api](), [code](), [dsl](), [gpio](), [hardware](), [led](), [port](), [pwm](), [raspberry-pi](), [raspberrypi]() ### AI overview The article announces a GPIO driver for Raspberry Pi boards implemented as Red's gpio:// scheme. It describes board detection, GPIO state access, hardware PWM, and a command DSL, and demonstrates the functionality with a joypad project running on a Raspberry Pi 3. ### Source excerpt As part of the R&D work on port! datatype in port-type branch, we have implemented a GPIO driver for Raspberry Pi boards, as a gpio:// scheme (no third-party library needed). This work helped define the low-level API for ports written in purely Red/System or a mix of Red and Red/System. The Raspberry Pi is a very popular board with millions of units sold, so this is a market where Red could be potentially helpful to developers. We could run Red on such boards for years but did not have proper GPIO support, so this is now fixed! The current features supported by the GPIO port are: auto-detecting the Raspberry Pi board type uses /dev/mem or/dev/gpiomem for direct and fast access. reading a GPIO pin state. writing to a GPIO pin state. hardware PWM output support (on capable pins). a simple DSL for sending commands. Planned (but not scheduled) future features include: generating events when a pin state changes. software PWM on all GPIO pins. a higher-level reactive object layer for a API-less interface. various drivers for common peripherals. The source code for the gpio:// scheme can be found there. In the short video below, you can find a little pet project meant for testing some of the features. It implements a simple joypad with 4 directions support, a red LED indicating when the pad is active and a green one for notifying when a level is completed. The game is the Red port contributed by Huang Yongzhao of Rebox!, my old clone of BoxWorld written in Rebol. In the video below, it is running on a Raspberry Pi 3 using our work-in-progress red/GTK backend for Red (contributed by Rcqls), locally merged with the red/port-type development branch (EDIT: that branch has been merged into master now). You can find the breadboard layout below made using Fritzing. Sorry for the messy wiring, it is my first try with such kind of tool. If you have the skills to improve it, here is the sketch file. The buttons rely on the internal pull-down resistors. Note that in the video, the bo ## Creating Kotlin DSLs DevFeed: [Creating Kotlin DSLs]() Original publisher: [Read original article]() Author: Wolfram Rittmeyer Published: 2018-12-29T03:05:09Z Content type: tutorial Language: en Sources: [Grokking Android]() Topics: [Kotlin]() Tags: [android](), [domain-specific-languages](), [dsl](), [dsls](), [extension](), [groovy](), [kotlin](), [languages](), [scala](), [sql](), [tutorials](), [unit-tests](), [yaml]() ### AI overview This article explains how Kotlin can be used to create internal domain-specific languages by combining core language features. It distinguishes internal DSLs from external DSLs and discusses benefits such as concise, readable APIs, with examples including Gradle and KotlinTest. ### Source excerpt Kotlin has many nice things going for it - be it null safety, data classes, extension functions, immutable collections or many other things. For me one additional thing is very interesting: The ability to create domain specific languages (DSLs) easily. Easily, because creating a DSL with Kotlin means that you simply choose to combine several [...] Continue Reading "Creating Kotlin DSLs" The post Creating Kotlin DSLs appeared first on Grokking Android. ## From Java Builders to Kotlin DSLs DevFeed: [From Java Builders to Kotlin DSLs]() Original publisher: [Read original article]() Author: Márton Braun Published: 2018-07-11T06:00:00Z Content type: tutorial Language: en Sources: [zsmb.co]() Topics: [Kotlin](), [Java]() Tags: [builder](), [dsl](), [dsls](), [existing](), [guide](), [java](), [kotlin]() ### AI overview A step-by-step guide to wrapping an existing Java Builder-based API in a neat Kotlin DSL. ### Source excerpt A step by step guide to wrapping an existing Builder-based API into a neat Kotlin DSL. ## Kotlin DSL to write Gradle scripts on Android: Step by step walkthrough DevFeed: [Kotlin DSL to write Gradle scripts on Android: Step by step walkthrough]() Original publisher: [Read original article]() Published: 2017-11-10T00:00:00Z Content type: tutorial Language: en Sources: [Antonio Leiva]() Topics: [Gradle](), [Kotlin](), [Android](), [Script](), [Groovy](), [ide]() Tags: [android](), [dsl](), [gradle](), [groovy](), [how-to](), [ide](), [kotlin]() ### AI overview A step-by-step tutorial on using Kotlin DSL to write Gradle scripts for Android projects. It explains the author's experience converting Bandhook-Kotlin's Gradle files, discusses Kotlin DSL's IDE and language benefits, and outlines drawbacks including limited documentation and conversion difficulties. ### Source excerpt Everything Android, Kotlin and other random topics ## Kotlin DSL design with VillageDSL DevFeed: [Kotlin DSL design with VillageDSL]() Original publisher: [Read original article]() Author: Márton Braun Published: 2017-09-20T18:00:00Z Content type: tutorial Language: en Sources: [zsmb.co]() Topics: [Kotlin](), [Code](), [Java](), [GitHub]() Tags: [android](), [article](), [code](), [dsl](), [examples](), [formatting](), [github](), [kotlin](), [marton-braun](), [zsmb](), [zsmb-co](), [zsmb13](), [zsmbco]() ### AI overview This companion article explores Kotlin DSL design through simple and advanced fantasy-village models. It compares direct object construction, a limited formatting-based approach, and several DSL approaches for expressing model hierarchies. ### Source excerpt A companion article for a talk I've given on Kotlin DSL design possibilities, with many code examples. ## The Road to Gradle Script Kotlin 1.0 DevFeed: [The Road to Gradle Script Kotlin 1.0]() Original publisher: [Read original article]() Author: Rodrigo B. de Oliveira Published: 2016-10-26T04:00:00Z Content type: article Language: en Sources: [The Gradle Blog]() Topics: [Gradle](), [Kotlin](), [ide](), [releases](), [Programming language]() Tags: [build](), [compiler](), [configuration](), [dsl](), [gradle](), [groovy](), [ide](), [interoperability](), [kotlin](), [plugins](), [programming](), [programming-language](), [release](), [releases](), [tooling]() ### AI overview The article reviews the progress of Gradle Script Kotlin from its first pre-release toward version 1.0. It describes successive pre-releases, improvements to imports, dependency configuration, IDE support, plugins, Kotlin interoperability, and inclusion in Gradle 3.0. ### Source excerpt Five months ago we announced the first pre-release of Gradle Script Kotlin, and we thought now would be a good time to review the progress we've made since. We have shipped eight additional pre-releases during that time, and the road to 1.0 is looking clearer every day. So let's take a look at the ground we've covered so far and where we're going from here, shall we? v0.1.0 As you may recall, this is what our hello-world sample looked like at the time of our first release: import org.gradle.api.plugins.* import org.gradle.script.lang.kotlin.* apply() configure { mainClassName = "samples.HelloWorld" } repositories { jcenter() } dependencies { "testCompile"("junit:junit:4.12") } Oh, that annoying org.gradle.script.lang.kotlin.* import! The publicly condemned, IDE unfriendly, string-based "testCompile" dependency configuration! And of course--for those souls brave enough to have tried them--the infamous generateKtsConfig and patchIdeaConfig tasks required to get Kotlin-based build scripts working in IDEA. These were early days, no doubt, and they brought with them a few rough edges. But despite its flaws, the programming language and IDE experience in 0.1.0 was already so good it got us hooked. As for the rough edges, we could already see ways to smooth them out, which led to the release of 0.2.0 one month later. v0.2.0 With implicit imports and a tooling-friendly alternative to string-based dependency configurations, hello-world 0.2.0 started looking clean and concise: apply() configure { mainClassName = "samples.HelloWorld" } repositories { jcenter() } dependencies { testCompile("junit:junit:4.12") } Seamless project imports meant that Kotlin-based builds in IDEA started working out of the box, and the days of mistyping generateKtsConfig and patchIdeaConfig were no more. Perhaps most importantly, 0.2.0's support for build script dependencies and external plugins made Gradle