# merge Published articles for merge. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## How we shipped a production API out of one Slack thread DevFeed: [How we shipped a production API out of one Slack thread]() Original publisher: [Read original article]() Author: WorkOS Published: 2026-08-27T14:09:14Z Content type: article Language: en Sources: [WorkOS Blog]() Topics: [API](), [Slack](), [CRUD]() Tags: [agents](), [api](), [merge](), [production](), [pull-requests](), [rest](), [security](), [slack]() ### AI overview WorkOS describes how its IT Contact API was shipped from a single Slack thread. Humans made product and design decisions and gated the merge, while agents handled tickets, pull requests, review responses, and merges. The discussion shaped the API from an initial RPC proposal toward REST and resolved security, deletion, and duplicate-creation questions. ### Source excerpt The WorkOS IT Contact API went live on August 18 out of a single Slack thread. Humans made the decisions and gated the merge; agents did everything else. ## Broken Systems Don't Need More Developers DevFeed: [Broken Systems Don't Need More Developers]() Original publisher: [Read original article]() Author: Valentina Jemuović Published: 2026-07-14T09:12:34Z Content type: opinion Language: en Sources: [Optivem Journal]() Topics: [systems](), [legacy](), [Back end](), [Test-driven development]() Tags: [architecture](), [code-reviews](), [developers](), [engineering](), [legacy](), [legacy-code](), [meetings](), [merge](), [onboarding]() ### AI overview Adding developers to a tightly coupled legacy system may slow progress because onboarding, interruptions, meetings, code reviews, and merge conflicts increase. The article argues that architecture, rather than team size, is the main bottleneck. ### Source excerpt If four developers aren't delivering fast enough, why not make it eight? ## Hidden Gems: Part 4 DevFeed: [Hidden Gems: Part 4]() Original publisher: [Read original article]() Author: Joseph Lyons Published: 2026-06-23T00:00:00Z Content type: tutorial Language: en Sources: [Zed Industries - Blog]() Topics: [GUI](), [Command-line interface](), [Terminal](), [Linux](), [macOS](), [Windows]() Tags: [command-line](), [merge](), [projects](), [terminal](), [workflows]() ### AI overview A collection of Zed workflows and lesser-known features covers centered editor layouts, navigating projects, worktrees and branches with keybindings, and configuring Zed as an interactive terminal editor. ### Source excerpt Favorite workflows and hidden features from the Zed team and community. ## Git sync & workspace forks: your entire workspace, version controlled DevFeed: [Git sync & workspace forks: your entire workspace, version controlled]() Original publisher: [Read original article]() Author: Tristan Lécuyer Published: 2026-04-02T00:00:00Z Content type: release Language: en Sources: [Windmill Blog]() Topics: [Git](), [version-control](), [CI/CD](), [GitLab](), [GitHub]() Tags: [azure](), [bitbucket](), [ci-cd](), [fork](), [git](), [gitlab](), [launch-week](), [merge](), [pipelines](), [repository](), [review](), [rollback](), [sync]() ### AI overview Windmill introduces redesigned bidirectional Git sync and workspace forks. Git sync commits and pushes deployed items to a configured repository and can pull updates from Git, while forks provide isolated feature-development workspaces with deployment, merge, and Git-based workflows. ### Source excerpt Introducing improved Git sync and workspace forks: sync workspaces to Git, fork for feature development, and deploy via CI/CD. ## Building an LSM Storage Engine from Scratch in Rust DevFeed: [Building an LSM Storage Engine from Scratch in Rust]() Original publisher: [Read original article]() Author: Nevin Zheng Published: 2026-03-05T00:00:00Z Content type: opinion Language: en Sources: [nevzheng]() Topics: [Rust](), [Databases](), [Data structures]() Tags: [code](), [compaction](), [data-structures](), [database](), [merge](), [mvcc](), [rust](), [storage](), [storage-engine]() ### AI overview A personal engineering account of building an LSM storage engine from scratch in Rust. The author discusses choosing LSM trees, prioritizing correctness and developer experience, versioning keys for possible MVCC exploration, and considering key-value separation to reduce compaction costs. ### Source excerpt Building my own perfectly imperfect LSM storage engine from scratch in Rust. ## In praise of the stacked pull request DevFeed: [In praise of the stacked pull request]() Original publisher: [Read original article]() Author: hi@swizec.com (Swizec Teller) Published: 2026-02-04T00:00:00Z Content type: opinion Language: en Sources: [Swizec Teller]() Topics: [stacked pull requests](), [Code review](), [Code quality](), [Development](), [Git]() Tags: [code-quality](), [code-review](), [git](), [merge](), [pull-request](), [queue](), [soc2](), [stacked-pull-requests](), [team](), [velocity]() ### AI overview An opinion piece argues that stacked pull requests help teams work on larger or dependent changes without creating oversized, difficult-to-review pull requests. It presents small, independent, testable pull requests as units of work that can be reviewed and merged incrementally. ### Source excerpt How fast you do code review is how fast you do everything. Your PR queue is the leading indicator of team velocity. Stacked PRs can help. ## Waiting for PostgreSQL 19 - Implement ALTER TABLE ... MERGE/SPLIT PARTITIONS ... command DevFeed: [Waiting for PostgreSQL 19 - Implement ALTER TABLE ... MERGE/SPLIT PARTITIONS ... command]() Original publisher: [Read original article]() Author: depesz Published: 2026-01-04T17:30:47Z Content type: opinion Language: en Sources: [select \* from depesz;]() Topics: [PostgreSQL](), [function]() Tags: [command](), [locking](), [merge](), [partition](), [partitioning](), [partitions](), [pg19](), [postgresql](), [split](), [uncategorized](), [waiting]() ### AI overview A PostgreSQL 19 development update describes the ALTER TABLE command for merging and splitting partitions. The patch was rolled back after earlier discussion, then recommitted; testing showed it worked as expected, with slightly less locking observed. Further changes may be needed before the feature reaches the final release. ### Source excerpt Important update This has been rolled back after some discussion. On 14th of December 2025, Alexander Korotkov committed patch: Implement ALTER TABLE ... MERGE PARTITIONS ... command This new DDL command merges several partitions into a single partition of the target table. The target partition is created using the new createPartitionTable() function with the ... Continue reading "Waiting for PostgreSQL 19 - Implement ALTER TABLE ... MERGE/SPLIT PARTITIONS ... command" ## Postgres 18 Is Out: Try it on Neon DevFeed: [Postgres 18 Is Out: Try it on Neon]() Original publisher: [Read original article]() Author: Bryan Clark Published: 2025-09-25T18:54:37Z Content type: article Language: en Sources: [Blog -- Neon Docs]() Topics: [Database](), [Optimization](), [Query (disambiguation)](), [Developer experience](), [Structured-data](), [Cache]() Tags: [analytics](), [cache](), [cpu](), [integrity](), [merge](), [native](), [new-features](), [optimization](), [performance](), [postgres](), [preview](), [product](), [schema]() ### AI overview The article announces the Postgres 18 release and its immediate preview availability on Neon's Free plan. It highlights performance and developer-focused improvements including skip scans for multicolumn B-tree indexes, expanded EXPLAIN ANALYZE metrics, virtual generated columns, native UUIDv7 support, access to old and new row values in a single statement, and temporal integrity for keys. ### Source excerpt Postgres 18 just shipped, and as always, it's available in preview on Neon right away. You can try it right now on Neon's Free plan, no credit card or setup required. New Features in Postgres 18 Postgres 18 comes with a ton of other exciting updates around performance, flexibilit... ## first-class merges and cover letters DevFeed: [first-class merges and cover letters]() Original publisher: [Read original article]() Published: 2025-09-11T01:26:47Z Content type: opinion Language: en Sources: [Tony Finch's blog]() Topics: [Git](), [version-control](), [Development](), [pull-requests](), [Code review]() Tags: [branch](), [git](), [merge](), [review](), [version-control](), [workflow]() ### AI overview This commentary examines shortcomings in Git branches and common merge and rebase workflows. It argues that improving merges, rather than branches alone, could make branch-based development more effective, while considering trade-offs between detailed history and clean logical changes. ### Source excerpt Although it looks really good, I have not yet tried the Jujutsu (jj) version control system, mainly because it's not yet clearly superior to Magit. But I have been following jj discussions with great interest. One of the things that jj has not yet tackled is how to do better than git refs / branches / tags. As I underestand it, jj currently has something like Mercurial bookmarks, which are more like raw git ref plumbing than a high-level porcelain feature. In particular, jj lacks signed or annotated tags, and it doesn't have branch names that always automatically refer to the tip. This is clearly a temporary state of affairs because jj is still incomplete and under development and these gaps are going to be filled. But the discussions have led me to think about how git's branches are unsatisfactory, and what could be done to improve them. branch merge rebase squash fork cover letters previous branch workflow questions branch One of the huge improvements in git compared to Subversion was git's support for merges. Subversion proudly advertised its support for lightweight branches, but a branch is not very useful if you can't merge it: an un-mergeable branch is not a tool you can use to help with work-in-progress development. The point of this anecdote is to illustrate that rather than trying to make branches better, we should try to make merges better and branches will get better as a consequence. Let's consider a few common workflows and how git makes them all unsatisfactory in various ways. Skip to cover letters and previous branch below where I eventually get to the point. merge A basic merge workflow is, create a feature branch hack, hack, review, hack, approve merge back to the trunk The main problem is when it comes to the merge, there may be conflicts due to concurrent work on the trunk. Git encourages you to resolve conflicts while creating the merge commit, which tends to bypass the normal review process. Git also gives you an ugly useless canned commit messa ## Expanding a Running Netlab Topology DevFeed: [Expanding a Running Netlab Topology]() Original publisher: [Read original article]() Published: 2025-07-07T06:11:00Z Content type: tutorial Language: en Sources: [ipSpace.net blog]() Topics: [configuration](), [Cisco](), [dell](), [Linux]() Tags: [cisco](), [collect](), [config](), [configuration](), [dell](), [devices](), [ios](), [linux](), [merge](), [mikrotik](), [netlab](), [nx](), [sonic]() ### AI overview This tutorial explains how to expand a netlab topology while preserving configuration changes made to existing devices. It recommends collecting configurations to a separate folder, checking whether they can be reloaded, rebuilding the lab with the modified topology, and applying the saved configurations. The procedure has platform-specific limitations and may fail when device interfaces or configuration formats differ. ### Source excerpt One of the happy netlab users sent me an interesting challenge: He's built a large lab and added tons of extra configuration to the lab devices. Afterwards, he realized he'd like to add a few more devices to the lab and was worried about losing all the changes he had made. Unfortunately, you cannot add new devices to an already-running lab. You must shut down the lab, change the topology description, and start a new lab. However, there are things you can do to preserve the extra work you already did: Read more ... ## Optimizing Jetpack Compose Transform Computations by Merging Functions DevFeed: [Optimizing Jetpack Compose Transform Computations by Merging Functions]() Original publisher: [Read original article]() Author: Romain Guy Published: 2025-05-15T00:00:00Z Content type: tutorial Language: en Sources: [Posts on Romain Guy]() Topics: [Code](), [Compose](), [Jetpack Compose](), [Kotlin](), [inlining]() Tags: [android](), [code](), [compose](), [developer](), [function](), [graphics](), [implementation](), [inlining](), [jetpack-compose](), [kotlin](), [merge](), [performance]() ### AI overview This article explains how merging or manually inlining low-level functions can remove duplicated work in performance-sensitive code. Using Jetpack Compose matrix transformations as an example, it describes eliminating unnecessary temporary matrices and intermediate computations. ### Source excerpt There is a simple but often overlooked technique to optimize performance-sensitive code: merging (or manually inlining) functions. We often build series of low-level functions that execute various computations that we then combine to perform higher-level tasks. When taken in isolation, each of those functions does exactly what it should and might even be perfectly optimized. However, when a series of thosefunctions work together, unnecessary or duplicated work might appear. Let's look at a concrete example taken from the Jetpack Compose code base. To apply the various geometric transforms that may affect a layer, Compose needs to build a matrix that combines all the transformations exposed by its APIs: ## Think About SQL MERGE in Terms of a RIGHT JOIN DevFeed: [Think About SQL MERGE in Terms of a RIGHT JOIN]() Original publisher: [Read original article]() Author: lukaseder Published: 2025-03-13T14:45:53Z Content type: tutorial Language: en Sources: [jOOQ]() Topics: [SQL](), [etl](), [rdbms]() Tags: [databricks](), [etl](), [firebird](), [merge](), [outer-join](), [postgresql](), [right-join](), [schema](), [semantics](), [source](), [sql](), [sql-server](), [statement](), [syntax](), [table](), [target-table](), [when-matched](), [when-not-matched](), [when-not-matched-by-source]() ### AI overview The article explains SQL MERGE by relating its target-and-source behavior to a RIGHT JOIN. It covers updating matching rows, inserting nonmatching rows, deletion behavior, and the restriction against duplicate matches. ### Source excerpt RIGHT JOIN is an esoteric feature in the SQL language, and hardly ever seen in the real world, because almost every RIGHT JOIN can just be expressed as an equivalent LEFT JOIN. The following two statements are equivalent: It's not unreasonable to expect these two statements to produce the same execution plan on most RDBMS, ... Continue reading Think About SQL MERGE in Terms of a RIGHT JOIN -> ## jOOQ 3.20 released with ClickHouse, Databricks, and much more DuckDB support, new modules, Oracle type hierarchies, more spatial support, decfloat and synonym support, hidden columns, Scala 3, Kotlin 2, and much more DevFeed: [jOOQ 3.20 released with ClickHouse, Databricks, and much more DuckDB support, new modules, Oracle type hierarchies, more spatial support, decfloat and synonym support, hidden columns, Scala 3, Kotlin 2, and much more]() Original publisher: [Read original article]() Author: lukaseder Published: 2025-02-20T10:27:54Z Content type: release Language: en Sources: [jOOQ]() Topics: [clickhouse](), [databricks](), [SQL](), [DuckDB](), [modules](), [Oracle Database](), [Kotlin](), [Scala](), [reactive](), [jpa]() Tags: [array](), [clickhouse](), [databricks](), [decfloat](), [dirty-tracking](), [dml-join](), [duckdb](), [hidden-columns](), [jdk-21](), [jooq](), [jooq-3-20](), [jooq-development](), [jpa](), [json](), [kotlin](), [kotlin-2](), [merge](), [modules](), [oracle](), [oracle-plsql-types](), [r2dbc](), [reactive](), [scala](), [scala-3](), [sequences](), [spatial](), [sql]() ### AI overview jOOQ 3.20 introduces experimental ClickHouse and Databricks SQL dialects, improves DuckDB support, adds new integration modules, and expands support for Oracle type hierarchies, spatial features, decfloat, synonyms, hidden columns, Scala 3, and Kotlin 2. ### Source excerpt New dialects: jOOQ 3.20 ships with 2 new experimental dialects: ClickHouse is a fast-moving SQL dialect with a historic vendor-specific syntax that is gradually migrated to a more standards compliant alternative, which is why our support is still experimental. A lot of behaviours differ from what one would expect elsewhere, including NULL handling, which is ... Continue reading jOOQ 3.20 released with ClickHouse, Databricks, and much more DuckDB support, new modules, Oracle type hierarchies, more spatial support, decfloat and synonym support, hidden columns, Scala 3, Kotlin 2, and much more -> ## postmarketOS July 2024 update covers homepage redesign, contributor workflow, and pmbootstrap v3 DevFeed: [postmarketOS July 2024 update covers homepage redesign, contributor workflow, and pmbootstrap v3]() Original publisher: [Read original article]() Published: 2024-07-21T00:00:00Z Content type: news Language: en Sources: [postmarketOS Blog]() Topics: [Maintainers](), [pull-requests](), [patches](), [navigation](), [Usability]() Tags: [experience](), [maintainers](), [merge](), [navigation](), [patches](), [postmarketos](), [redesign](), [release]() ### AI overview The postmarketOS July 2024 update describes a redesigned homepage with reorganized navigation and new team and exploration pages. It also reports new approval requirements for merging patches, plans for automatic maintainer assignment, funding-related news, and improvements from the pmbootstrap v3 patch series. ### Source excerpt Fasten your seatbelts, after skipping the monthly progress report in June because of the v24.06 release, we have at least twice as much news to share! Homepage First, we obviously updated the homepage. The new design is a collaboration between Dika, Markus and Oliver. It's more than just a design change actually. If you take a close look at the links in the top navigation bar you may first notice that it isn't as overloaded with random links anymore as it used to be. And secondly that there is a new explore button that more or less lists the links we had there previously (but now nicely sorted in categories!) as well as a new team button. Bryant spent a whole lot of time and effort on that. The team page shows who makes postmarketOS. Who the Core Contributors (renamed from Core Team for consistency) and Trusted Contributors are and what we are doing in postmarketOS. What we think about, enjoy doing and where you can find us on Matrix etc. The teams page also has the purpose to list the contributor groups and teams we now have, which have grown quite a lot in the last months, in one easy to read overview. So Bryant figured before we add yet another new button to the navigation bar, we should first unclutter the navigation bar and... while at it we just did this whole redesign! Organizational We decided on new approval requirements for merging patches. This addresses problems with good patches not getting merged, that oftentimes were caused by lack of clear understanding of who is supposed to approve and merge patches. With further work we plan to automatically assign maintainers to new merge requests (like it works in Alpine's aports). We apologize to everybody that had a hard time with the previous review process, and we hope this makes the workflow better for everyone. Feel free to reply to #66 if you still experience problems with the new workflow. We wrote a separate blog post about postmarketOS being selected for NGI Zero Core funding, as well as how the European ## In Praise of Small Pull Requests DevFeed: [In Praise of Small Pull Requests]() Original publisher: [Read original article]() Author: Google Testing Bloggers (noreply@blogger.com) Published: 2024-07-16T13:00:00Z Content type: article Language: en Sources: [Google Testing Blog]() Topics: [pull-requests](), [Code review](), [engineering-culture]() Tags: [code-health](), [code-review](), [elliotte-rusty-harold](), [merge](), [pull-requests](), [review](), [tott](), [version-control]() ### AI overview This Google Testing on the Toilet Code Health post explains why pull requests should be small and focused on one self-contained change. It says smaller pull requests are easier and faster to review, make mistakes easier to detect, simplify debugging and rollback, reduce merge conflicts, improve pull request descriptions and revision history, and can increase code coverage. ### Source excerpt This is another post in our Code Health series. A version of this post originally appeared in Google bathrooms worldwide as a Google Testing on the Toilet episode. You can download a printer-friendly version to display in your office. By Elliotte Rusty Harold Note: A "pull request" refers to one self-contained change that has been submitted to version control or which is undergoing code review. At Google, this is referred to as a"CL", which is short for "changelist". Prefer small, focused pull requests that do exactly one thing each. Why? Several reasons: Small pull requests are easier to review. A mistake in a focused pull request is more obvious. In a 40 file pull request that does several things, would you notice that one if statement had reversed the logic it should have and was using true instead of false? By contrast, if that if block and its test were the only things that changed in a pull request, you'd be a lot more likely to catch the error. Small pull requests can be reviewed quickly. A reviewer can often respond quickly by slipping small reviews in between other tasks. Larger pull requests are a big task by themselves, often waiting until the reviewer has a significant chunk of time. If something does go wrong and your continuous build breaks on a small pull request, the small size makes it much easier to figure out exactly where the mistake is. They are also easier to rollback if something goes wrong. By virtue of their size, small pull requests are less likely to conflict with other developers' work. Merge conflicts are less frequent and easier to resolve. If you've made a critical error, it saves a lot of work when the reviewer can point this out after you've only gone a little way down the wrong path. Better to find out after an hour than after several weeks. Pull request descriptions are more accurate when pull requests are focused on one task. The revision history becomes easier to read. Small pull requests can lead to increased code coverage becau ## Campground Pull Request DevFeed: [Campground Pull Request]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2024-07-06T22:52:31Z Content type: opinion Language: en Sources: [Kaushik Gopal's Site]() Topics: [Pull Request](), [Code review](), [Code quality](), [Code]() Tags: [cleanup](), [code](), [code-quality](), [merge](), [pull-request](), [refactor](), [review](), [reviews](), [team]() ### AI overview The article proposes "Campground PRs": separate pull requests for refactoring and clarifying code before implementing a new feature. Because these changes should not alter functionality, they can improve estimates, simplify reviews, and gradually improve codebase quality. ### Source excerpt Before diving into a new feature, I always tell my team to scout the parts of the codebase that will need to change. As we explore, refactor for clarity. These cleanup changes get their own pull request1 (PR) before we touch the new feature. This PR shouldn't change functionality, just tidy up the existing code. This gives us a few big wins: Better estimates: We can estimate the feature's timeline more accurately now that we have a much better sense of what's about to change. Smoother reviews: Campground PRs are quicker to review, since no functionality has changed. Importantly, you don't clutter your feature PR with refactors or distracting changes -- prompting the ire of code reviewers. Codebase quality: You gradually increase the code quality of your codebase -- especially the parts that won't get touched by your feature PR but could use the love. This is not a new concept , you've probably seen versions of it before: Boy Scout Rule: Leave your codebase cleaner than you found it. Broken Windows: Fix small issues before they proliferate through your code base become big. I haven't found a popular name for this specific concept, so I've started calling them "Campground PRs". Don't just leave the code better after your feature, do it before hand. Got a better name? Let me know! Or merge request (MR), for the Gitlab folks. ↩︎ ## Git Version Control Tutorial: A Beginner's Guide to Git Version Control DevFeed: [Git Version Control Tutorial: A Beginner's Guide to Git Version Control]() Original publisher: [Read original article]() Author: admin Published: 2024-05-03T07:28:35Z Content type: tutorial Language: en Sources: [Posts on Chris Banes]() Topics: [Git](), [version-control](), [Tutorial](), [coding](), [Development](), [Code]() Tags: [beginner](), [code](), [coding](), [collaboration](), [commands](), [commit](), [core](), [developers](), [distributed](), [distributed-system](), [efficiency](), [files](), [git](), [guide](), [machine](), [merge](), [projects](), [repository](), [tutorial](), [uncategorized](), [version-control]() ### AI overview A beginner-focused tutorial explaining Git as a distributed version control system for tracking changes, managing repositories, creating commits and branches, and collaborating with other developers. ### Source excerpt Have you ever worked on a project and accidentally overwritten your progress? Maybe you spent hours coding a new feature, then realized you needed to go back to a previous version. This is where git version control can help! Git is a lifesaver for developers, allowing you to track changes, collaborate effectively, and ensure you [...] ## Chainguard patches 3 "silent" Golang CVEs in under 24 hours DevFeed: [Chainguard patches 3 "silent" Golang CVEs in under 24 hours]() Original publisher: [Read original article]() Published: 2024-03-21T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [chainguard](), [Vulnerabilities](), [Go](), [chainguard images](), [Security](), [Automation](), [toolchain](), [DDoS](), [Monitoring](), [Open Source](), [Pull Request](), [Linux]() Tags: [automation](), [chainguard](), [chainguard-images](), [cve](), [cves](), [ddos](), [github](), [go](), [golang](), [golang-patch](), [linux](), [melange](), [merge](), [monitoring](), [safe-source-for-open-source](), [security](), [silent-cve](), [tooling](), [wolfi]() ### AI overview Chainguard describes how it patched three Golang CVEs in under 24 hours. Its automation monitored new Go releases, opened a pull request, rebuilt the Wolfi package, and updated Chainguard Images containing Go. ### Source excerpt See how Chainguard swiftly patched three Golang CVEs in under 24 hours, showcasing rapid response and dedication to secure software. ## Jetpack Compose Clip or Cut a Composable with Custom Image Shape DevFeed: [Jetpack Compose Clip or Cut a Composable with Custom Image Shape]() Original publisher: [Read original article]() Author: Ban Markovic Published: 2024-02-14T17:25:40Z Content type: tutorial Language: en Sources: [Stories by Ban Markovic on Medium]() Topics: [Jetpack Compose](), [Compose](), [Android](), [ui](), [Graphics]() Tags: [alignment](), [android](), [android-app-development](), [androiddev](), [building](), [component](), [compose](), [compose-ui](), [customization](), [extend](), [images](), [jetpack-compose](), [kotlin](), [layout](), [merge](), [ui]() ### AI overview A tutorial showing how to clip a Jetpack Compose composable to a custom image shape. It builds a health-bar example, then uses PorterDuff operators and Modifier.drawWithContent to combine the image shape with colored content. ### Source excerpt As an Android developer, I face all sorts of challenges provided to me by my fellow designers. One of them was actually building an UI component that has a custom shape in a form of an image. This was required because we wanted to display a special type of a progress bar by fulfilling the image shape with gradient. Because I didn't find this functionality trivial to implement, I decided to show how I solved this issue with some fun example. Example Here is a simple game where I utilized cutting of my composable. The game consists of one plane with full health. Upon each hit, it looses 10% of its health. Game is over once the plane remains with no health. Game Setup First, let me show you how I formed the basic layout for this game. It will contain the gray square and Hit button. Column( modifier = Modifier.fillMaxSize().background(Color.Black), verticalArrangement = Arrangement.Center, horizontalAlignment = Alignment.CenterHorizontally ) { Box( modifier = Modifier .size(240.dp) .background(Color.LightGray) ) Spacer(modifier = Modifier.height(40.dp)) Button( onClick = { /* TODO */ } ) { Text("HIT") } } Next step, is to create custom Composable called SquareHealth. SquareHealth is expecting the progress value (from 0.0 to 1.0). This will determine the height of the green area inside my gray square (aligned at bottom). It will represent remaining health for my Square. @Composable fun SquareHealth(healthPercentage: Float) { Box( modifier = Modifier .size(240.dp) .background(Color.LightGray) ) { Box( modifier = Modifier .fillMaxWidth() .height((240 * healthPercentage).dp) .background(Color.Green) .align(Alignment.BottomCenter) ) } } Now, I can call it instead of the static gray Box inside my screen. The basic layout is now set, and I just need to set initial health progress to 1.0, and enable my button to decrease the health percentage by 0.1 on each click. var healthPercentage by remember { mutableStateOf(1.0f) } Column( modifier = Modifier .fillMaxSize() .background(Co ## Keep your Chainguard Images up to date with digestabot DevFeed: [Keep your Chainguard Images up to date with digestabot]() Original publisher: [Read original article]() Published: 2023-12-18T00:00:00Z Content type: article Language: en Sources: [Chainguard: Unchained]() Topics: [chainguard images](), [chainguard](), [GitHub Actions](), [Pull Request](), [Security]() Tags: [also](), [chainguard](), [chainguard-images](), [container](), [continuous-integration](), [digestabot](), [dockerfiles](), [github-action](), [helm](), [make](), [merge](), [oidc](), [security](), [vulnerability-automation](), [vulnerability-management]() ### AI overview Chainguard's digestabot is a free GitHub Action that helps keep Chainguard Images and other container assets current. It detects outdated image digests, opens pull requests, and supports testing and secure updates through continuous integration and optional ephemeral OIDC tokens. ### Source excerpt Experience hassle-free updates with Chainguard's digestabot, ensuring your Images stay secure and up-to-date daily. ## Verkle tree structure DevFeed: [Verkle tree structure]() Original publisher: [Read original article]() Author: Guillaume Ballet; Dankrad Feist Published: 2021-12-02T00:00:00Z Content type: tutorial Language: en Sources: [Ethereum Foundation Blog]() Topics: [Code](), [client]() Tags: [developers](), [how-to](), [implement](), [introduction](), [layout](), [merge](), [post](), [research-development](), [scheme](), [stem](), [storage](), [structure](), [vector]() ### AI overview This developer article explains the structure of draft Verkle tree EIP designs. It describes replacing Merkle tree hashes with vector commitments, merging account and storage tries, using 32-byte keys, and organizing keys into 31-byte stems with one-byte suffixes. ### Source excerpt A Verkle tree is a commitment scheme that works similar to a Merkle tree, but has much smaller witnesses. It works by replacing the hashes in a Merkle tree with a vector commitment, which makes wider branching factors more efficient. Thanks to Kevaundray Wedderburn for feedback on the post.... ## How The Merge Impacts Ethereum's Application Layer DevFeed: [How The Merge Impacts Ethereum's Application Layer]() Original publisher: [Read original article]() Author: Tim Beiko Published: 2021-11-29T00:00:00Z Content type: article Language: en Sources: [Ethereum Foundation Blog]() Topics: [Ethereum](), [Network](), [Tooling](), [Transactions]() Tags: [architecture](), [beacon](), [consensus](), [developers](), [ethereum](), [features](), [merge](), [proof-of-work](), [research-development](), [tooling](), [transactions]() ### AI overview This article explains how Ethereum's transition from proof of work to proof of stake through The Merge affects end users, smart contracts, decentralized applications, and application developers. It describes the Beacon Chain as the new consensus layer, ExecutionPayloads as the post-merge equivalent of blocks, and the minor changes to block fields and transaction infrastructure. ### Source excerpt Ethereum's transition to proof of stake -- The Merge -- is near: devnets are being stood up, specifications are being finalized and community outreach has begun in earnest. The Merge is designed to have minimal impact on how Ethereum operates for end users, smart contracts and dapps. That said, there... ## Kintsugi testnet and Arrow Glacier upgrade advance Ethereum Merge preparations DevFeed: [Kintsugi testnet and Arrow Glacier upgrade advance Ethereum Merge preparations]() Original publisher: [Read original article]() Author: Danny Ryan Published: 2021-11-22T00:00:00Z Content type: news Language: en Sources: [Ethereum Foundation Blog]() Topics: [Ethereum](), [releases](), [Testing](), [client](), [Software]() Tags: [ethereum](), [launch](), [merge](), [node](), [releases](), [research-development](), [tests](), [upgrade]() ### AI overview The article reports progress on the Kintsugi Merge sprint, including plans for a persistent multi-client testnet and ongoing client implementation, testing, and interoperability work. It also explains that validators must upgrade their PoW node for the Arrow Glacier difficulty-bomb delay. ### Source excerpt tl;dr Kintsugi🍵 in progress -- testnet to come Stakers must upgrade for Arrow Glacier... ## Moving from Schema Stitching to Federation: How Expedia improved performance DevFeed: [Moving from Schema Stitching to Federation: How Expedia improved performance]() Original publisher: [Read original article]() Author: David Isquick Published: 2021-07-27T10:16:04Z Content type: article Language: en Sources: [Apollo Blog]() Topics: [GraphQL](), [Graphs](), [Back end](), [Front end]() Tags: [announcement](), [backend](), [core](), [declarative](), [gateway](), [graphql](), [merge](), [performance]() ### AI overview This article recounts Expedia Group's GraphQL journey from schema stitching to federation. It describes why Expedia adopted GraphQL, how a gateway provided one schema and endpoint across independently owned services, and the challenges created by increasing custom stitching code. ### Source excerpt Two weeks ago, we hosted a webinar with Shane Myrick, Senior Software Developer at Expedia Group entitled, "From Schema Stitching to Federation: Expedia's Journey." Shane's talk covered Expedia's motivation for adopting GraphQL and why they needed a distributed approach for managing their graph. Prior to adopting GraphQL, the Expedia Group faced the challenge of delivering a wide array of travel experiences across a growing number of platforms and clients. [Next page]()