# abstraction Published articles for abstraction. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Agentic Coding: Bet on the Primitives DevFeed: [Agentic Coding: Bet on the Primitives]() Original publisher: [Read original article]() Author: Robin Wieruch Published: 2026-07-31T06:00:00Z Content type: opinion Language: en Sources: [Robin Wieruch]() Topics: [agentic-coding](), [coding](), [React](), [SVG]() Tags: [abstraction](), [agentic-coding](), [ai-coding-agents](), [ai-engineer](), [build-vs-buy-components](), [coding](), [d3-vs-recharts](), [opinions](), [react](), [svg]() ### AI overview The article argues that agentic coding lowers implementation costs enough to make owning lower-level primitives more practical. It describes an experiment comparing D3 math primitives with React-rendered SVG against Recharts for custom charts: Recharts reached most of the result faster, but its remaining customization needs and an animation issue led to more workarounds than the primitive-based approach. ### Source excerpt Agentic coding collapses the cost of implementation labor. Why the rational bet is moving from high-level libraries back to primitives you own. ## When Duplicated Code Is the Better Tradeoff DevFeed: [When Duplicated Code Is the Better Tradeoff]() Original publisher: [Read original article]() Author: Franco Fernando Published: 2026-07-04T06:05:31Z Content type: opinion Language: en Sources: [The Polymathic Engineer]() Topics: [Software Engineering](), [Code](), [distributed-systems](), [Microservice](), [Library]() Tags: [abstraction](), [bugs](), [code](), [components](), [distributed](), [distributed-systems](), [reusable-code](), [services](), [software](), [software-engineering](), [teams]() ### AI overview This article examines when following the DRY principle creates more cost than value. It argues that duplicated code can be reasonable when abstraction adds coordination overhead, tight coupling, or inflexibility, especially across distributed services and teams whose code may evolve differently. ### Source excerpt When duplicated code is the better tradeoff. ## Beyond Inline Values: Evolving Strata's Storage Engine DevFeed: [Beyond Inline Values: Evolving Strata's Storage Engine]() Original publisher: [Read original article]() Author: Nevin Zheng Published: 2026-06-03T00:00:00Z Content type: article Language: en Sources: [nevzheng]() Topics: [Rust](), [abstraction](), [SQL](), [olap]() Tags: [abstraction](), [block](), [bootstrapping](), [layout](), [migration](), [performance](), [repo](), [rust](), [sql](), [storage](), [storage-engine](), [write-amplification]() ### AI overview This architectural decision record proposes replacing Strata's inline value storage with a block-based abstraction. It describes the current Rust LSM storage engine and SQL layer, identifies flexibility and I/O amplification problems, compares options, and records the proposed direction. ### Source excerpt An architectural decision record: why Strata is moving from inline values to block-based storage. ## Object Oriented Programming - The Key Terms DevFeed: [Object Oriented Programming - The Key Terms]() Original publisher: [Read original article]() Author: Saurabh Dashora Published: 2026-03-24T08:38:43Z Content type: article Language: en Sources: [System Design Codex]() Topics: [Object-oriented programming (OOP)](), [Programming](), [Polymorphism](), [Inheritance](), [implementation](), [interface]() Tags: [abstraction](), [concepts](), [inheritance](), [maintainability](), [object-oriented](), [polymorphism](), [programming](), [security]() ### AI overview This tutorial introduces object-oriented programming through four principles: abstraction, encapsulation, inheritance, and polymorphism. It explains how abstraction hides implementation details, encapsulation controls access to data and methods, and inheritance supports reuse and hierarchical relationships. The supplied text begins its discussion of polymorphism but is truncated. ### Source excerpt The essential concepts ## Pectra Mainnet Announcement DevFeed: [Pectra Mainnet Announcement]() Original publisher: [Read original article]() Author: EF Protocol Support Published: 2025-04-23T00:00:00Z Content type: release Language: en Sources: [Ethereum Foundation Blog]() Topics: [Ethereum](), [releases](), [Transactions](), [Authentication](), [Passkeys](), [Security]() Tags: [2025](), [abstraction](), [authentication](), [batching](), [ethereum](), [protocol-announcements](), [releases](), [security](), [upgrade]() ### AI overview The Pectra network upgrade is scheduled to activate on Ethereum mainnet on May 7, 2025. The article explains how EIP-7702 adds smart contract capabilities to externally owned accounts and outlines related safety mechanisms. ### Source excerpt The Pectra network upgrade is scheduled to activate on the Ethereum mainnet on May 07, 2025 at epoch 364032 (10:05:11 UTC)! Mainnet client releases are listed below.... ## Design is about the abstractions DevFeed: [Design is about the abstractions]() Original publisher: [Read original article]() Author: Mike Published: 2024-08-05T15:55:48Z Content type: article Language: en Sources: [Dev Details]() Topics: [abstraction](), [Architecture & Design](), [software-architecture](), [API](), [interfaces]() Tags: [abstraction](), [api](), [architecture](), [interface](), [software-architecture](), [software-design](), [software-engineering]() ### AI overview The article explains how abstraction helps software and house design by hiding implementation details, defining interfaces and APIs, and indicating when a design contains enough detail to stop. ### Source excerpt Abstractions simplify designs and tell us when to stop designing. ## Item 31: Respect abstraction contracts DevFeed: [Item 31: Respect abstraction contracts]() Original publisher: [Read original article]() Published: 2024-07-22T00:00:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [abstraction]() Tags: [abstraction](), [how-to](), [important](), [workshop-learning-programming]() ### AI overview The article explains why respecting abstraction contracts matters and argues that technical possibility does not by itself justify an action. ### Source excerpt Just because we can do something, does not mean we should. How to respect abstraction contracts and why it is so important. ## Item 30: Define contracts with documentation DevFeed: [Item 30: Define contracts with documentation]() Original publisher: [Read original article]() Published: 2024-07-08T00:00:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [Documentation](), [abstraction](), [Code](), [implementation](), [Library]() Tags: [abstraction](), [code](), [documentation](), [implementation](), [library](), [workshop-learning-programming]() ### AI overview This article explains how documentation defines contracts for library or module elements. It argues that clearly documenting expected behavior lets users depend on an abstraction rather than its current implementation, while allowing creators to change the implementation as long as the contract is preserved. ### Source excerpt How do we express our library or module contracts and why are they so important. ## Naming Code Clearly: Practical Tips for More Readable Identifiers and APIs DevFeed: [Naming Code Clearly: Practical Tips for More Readable Identifiers and APIs]() Original publisher: [Read original article]() Author: Google Testing Bloggers (noreply@blogger.com) Published: 2024-03-26T12:34:00Z Content type: tutorial Language: en Sources: [Google Testing Blog]() Topics: [Code](), [Computer science]() Tags: [abstraction](), [adam-raider](), [code](), [code-health](), [identifier](), [implementation](), [interface](), [tips](), [tott]() ### AI overview This Code Health post explains why unclear identifiers and interfaces increase cognitive load and make code harder to read. It offers naming guidance, including describing behavior, considering the cost of renaming, revealing intent, and preferring precise names. ### 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 Adam Raider "There are only two hard things in computer science: cache invalidation and naming things." --Phil Karlton Have you ever read an identifier only to realize later it doesn't do what you expected? Or had to read the implementation in order to understand an interface? These indirections eat up our cognitive bandwidth and make our work more difficult. We spend far more time reading code than we do writing it; thoughtful names can save the reader (and writer) a lot of time and frustration. Here are some naming tips: Spend time considering names--it's worth it. Don't default to the first name that comes to mind. The more public the name, the more expensive it is to change. Past a certain scale, names become infeasible to change, especially for APIs. Pay attention to a name in proportion to the cost of renaming it later. If you're feeling stuck, consider running a new name by a teammate. Describe behavior. Encourage naming based on what functions do rather than when the functions are called. Avoid prefixes like "handle" or "on" as they describe when and provide no added meaning: button.listen('click', handleClick) button.listen('click', addItemToCart) Reveal intent with a contextually appropriate level of abstraction: High-abstraction functions describe the what and operate on high-level types. Lower-abstraction functions describe the how and operate on lower-level types. For example, logout might call into clearUserToken, and recordWithCamera might call into parseStreamBytes. Prefer unique, precise names. Are you frequently asking for the UserManager? Manager, Util, and similar suffixes are a common but imprecise naming convention. What does it do? It manages! If you're struggling to come up with a more precise name, consider sp ## Item 26: Use abstraction to protect code against changes DevFeed: [Item 26: Use abstraction to protect code against changes]() Original publisher: [Read original article]() Published: 2024-02-26T00:00:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [abstraction](), [Code](), [Software Engineering]() Tags: [abstraction](), [classes](), [code](), [database](), [display](), [password](), [software-engineering](), [sorting](), [threads](), [validation](), [workshop-learning-programming]() ### AI overview This tutorial explains how abstraction protects code from changes. It covers extracting literal values into constants, separating algorithms into functions, and using abstractions to change implementation details without changing how code is used. ### Source excerpt How do we abstract elements, and what are the consequences. ## Item 25: Each function should be written in terms of a single level of abstraction DevFeed: [Item 25: Each function should be written in terms of a single level of abstraction]() Original publisher: [Read original article]() Published: 2024-02-19T00:00:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [abstraction](), [function](), [Programming](), [Computer science]() Tags: [abstraction](), [code](), [computer-science](), [function](), [how-to](), [programming](), [workshop-learning-programming]() ### AI overview The article explains why each function should be written at a single level of abstraction. It introduces abstraction layers from hardware and machine instructions through Assembly, compilers, and higher-level languages, arguing that well-separated layers reduce the need to understand lower-level implementation details. ### Source excerpt Why each function should be written in terms of a single level of abstraction and how to achieve it. ## Abstraction design: Introduction DevFeed: [Abstraction design: Introduction]() Original publisher: [Read original article]() Published: 2024-02-05T00:00:00Z Content type: tutorial Language: en Sources: [Kt. Academy]() Topics: [abstraction](), [Programming](), [Object-oriented programming (OOP)](), [interfaces](), [Functional programming]() Tags: [abstraction](), [concepts](), [core](), [function](), [interfaces](), [object-oriented](), [programming](), [workshop-learning-programming]() ### AI overview This introduction explains abstraction as a form of simplification that hides complexity by deciding what to expose and what to conceal. It discusses abstractions in object-oriented and functional programming, including interfaces, classes, functions, and higher-level operations, with examples involving Java and Kotlin. ### Source excerpt What is abstraction in programming and why is it so important. ## Apollo Federation and GraphOS add support for entity interfaces to streamline collaboration DevFeed: [Apollo Federation and GraphOS add support for entity interfaces to streamline collaboration]() Original publisher: [Read original article]() Author: Korinne Alpers Published: 2023-02-15T08:22:00Z Content type: article Language: en Sources: [Apollo Blog]() Topics: [GraphQL](), [interfaces]() Tags: [abstraction](), [announcement](), [apis](), [apollo](), [apollo-federation](), [architecture](), [collaboration](), [distributed](), [graphos](), [interfaces]() ### AI overview Apollo Federation 2.3 adds entity interfaces, with general availability and support in Apollo GraphOS. The feature lets an interface defined in one subgraph be abstracted as an object type in other subgraphs, where those subgraphs can add and resolve fields directly on the interface. ### Source excerpt Apollo Federation is widely adopted as the standard specification for building distributed GraphQL APIs, called supergraphs, that run on top of one or more underlying subgraphs. Unlike a monolithic graph, a supergraph maintains clear separation of concerns -- each subgraph can be owned independently by separate developers or teams -- allowing it to evolve rapidly as new use cases arrive. ## Introduction to Interfaces DevFeed: [Introduction to Interfaces]() Original publisher: [Read original article]() Author: author@typealias.com (Dave Leeds) Published: 2022-09-12T00:00:00Z Content type: tutorial Language: en Sources: [Dave Leeds on Kotlin - typealias.com]() Topics: [interfaces](), [Kotlin](), [Code]() Tags: [abstraction](), [cast](), [code](), [implementation](), [interface](), [interfaces](), [introduction](), [kotlin](), [language](), [learn-to-program](), [programming](), [safe-cast](), [smart-cast](), [unsafe-cast]() ### AI overview This Kotlin tutorial introduces interfaces as a language feature that lets a single object have more than one type. It builds on Kotlin's built-in and custom types and begins illustrating the concept with a chicken and farmer example. ### Source excerpt Ever since Chapter 1, we've used a variety of built-in Kotlin types, like Int, String, and Boolean. Then in Chapter 4, we introduced our own custom types, like Circle, by writing classes. In this chapter, we'll dive into interfaces, which allow you to declare that a single object has more than one type at a time! Interfaces are a powerful language feature, and when used well, they can take your code to the next level. ## Haskell 101 Lecture Notes DevFeed: [Haskell 101 Lecture Notes]() Original publisher: [Read original article]() Published: 2022-05-04T00:00:00Z Content type: tutorial Language: en Sources: [Romes' Musings]() Topics: [Haskell](), [Functional programming](), [Programming language](), [Programming]() Tags: [abstraction](), [constructor](), [function](), [functional-programming](), [haskell](), [pattern-matching](), [polymorphism]() ### AI overview Haskell 101 lecture notes introducing functions, function abstraction and application, expressions, values, types, algebraic data types, construction and deconstruction, pattern matching, polymorphism, and type constructors. ### Source excerpt Contents 1 Functions, Computations: Abstraction and application 2 Expressions, Values, Types 3 ADTs, Construction, Deconstruction 4 Polymorphism 5 Non-nullary type constructors, Kinds 1 Functions, Computations: Abstraction and application What is a function? f(x) = 4x + 2? And what's function application? f(x) = 4x + 2 f(5) = ? In mathematics, function application is the act of applying a function to an argument from its domain so as to obtain the corresponding value from its range. In this sense, function application can be thought of as the opposite of function abstraction. In functional programming languages, computations are based on function abstraction and application. An abstraction, a.k.a a function, is denoted through the lambda notation (\x -> ...). An application, a.k.a function application, is denoted by juxtaposition: an expression followed by another expression represents the application of the first expression to the following one. f = \x -> 4 * x + 2 -- `f` is an abstraction f 5 -- application of `f` to `5` 2 Expressions, Values, Types Haskell is a purely functional programming language. As such, all computations are done via the evaluation of expressions (syntactic terms) to yield values (abstract entities that we regard as answers). Every value has an associated type (intuitively, we can think of types as sets of values). 5 :: Integer 'a' :: Char inc :: Integer -> Integer [1,2,3] :: [Integer] ('b', 4) :: (Char, Int) sum [1,2,3] :: Integer inc 5 :: Integer sum :: [Integer] -> Integer The :: can be read "has type". All expression evaluate to a value, and all values have types, which means all expressions have types too. Above are some of the common types. Which of the following are expressions, and which are values? What are the types of the expressions? product [1,2,3] product [1,2,3] They are all expressions, and only the first two are values. The first one is a function abstraction, which is a value, the second one is a value constructed with the ## Why the DRY Principle Is Often Misunderstood in Software Design DevFeed: [Why the DRY Principle Is Often Misunderstood in Software Design]() Original publisher: [Read original article]() Author: tobi@techunicorn.builders (Tobias Mende) Published: 2022-04-30T13:13:00Z Content type: opinion Language: en Sources: [Tobias Mende]() Topics: [Software Engineering](), [Architecture & Design](), [abstraction](), [reuse](), [maintenance]() Tags: [abstraction](), [component](), [dependencies](), [maintenance](), [practices-software-development-software-craft](), [reuse](), [software-design]() ### AI overview The article argues that the DRY principle is frequently misapplied in software development. Reusing code can reduce duplication but may introduce dependencies, rigid contracts, and abstractions that are difficult to change, especially when systems evolve independently. ### Source excerpt DRY - DO repeat yourself When I started my career as a software developer and already during university, almost no principle was mentioned as often as the DRY principle: "Do not repeat yourself" ## An introduction to Temporal Workflows DevFeed: [An introduction to Temporal Workflows]() Original publisher: [Read original article]() Author: Dominik Tornow Published: 2022-01-24T07:00:00Z Content type: article Language: en Sources: [Temporal Blog]() Topics: [Developer experience](), [distributed-systems](), [reliability](), [Scalability](), [AWS Lambda]() Tags: [abstraction](), [aws-lambda](), [developer-experience](), [distributed-systems](), [how-to](), [introduction](), [reliability](), [retries](), [scalability](), [workflows]() ### AI overview This introduction explains Temporal Workflows as an abstraction for reliable, scalable execution in distributed systems. It contrasts workflow executions with regular functions using a monthly reminder-email example and describes how workflows address failures, retries, duplication, and idempotence that otherwise require multiple infrastructure services. ### Source excerpt Discover how Temporal workflows offer reliable execution with built-in failure handling, ensuring correct application behavior at scale. ## Latent Effects for Reusable Language Components DevFeed: [Latent Effects for Reusable Language Components]() Original publisher: [Read original article]() Published: 2021-10-14T14:02:48Z Content type: article Language: en Sources: [Lambda the Ultimate]() Topics: [Haskell](), [Programming](), [Development](), [implementation]() Tags: [abstraction](), [deferred](), [effects](), [examples](), [functional](), [haskell](), [modular](), [monad](), [programming-languages](), [semantics](), [theory]() ### AI overview The article discusses latent effects, a generic class of control-flow mechanisms for modular language definitions. It describes how function abstractions, lazy computations, and MetaML-like staging can be expressed and combined, with a full Haskell implementation and examples. ### Source excerpt Latent Effects for Reusable Language Components, by Birthe van den Berg, Tom Schrijvers, Casper Bach Poulsen, Nicolas Wu: The development of programming languages can be quite complicated and costly. Hence, much effort has been devoted to the modular definition of language features that can be reused in various combinations to define new languages and experiment with their semantics. A notable outcome of these efforts is the algebra-based "datatypes "a la carte" (DTC) approach. When combined with algebraic effects, DTC can model a wide range of common language features. Unfortunately, the current state of the art does not cover modular definitions of advanced control-flow mechanisms that defer execution to an appropriate point, such as call-by-name and call-by-need evaluation, as well as (multi-)staging. This paper defines latent effects, a generic class of such control-flow mechanisms. We demonstrate how function abstractions, lazy computations and a MetaML-like staging can all be expressed in a modular fashion using latent effects, and how they can be combined in various ways to obtain complex semantics. We provide a full Haskell implementation of our effects and handlers with a range of examples. Looks like a nice generalization of the basic approach taken by algebraic effects to more subtle contexts. Algebraic effects have been discussed here on LtU many times. I think this description from section 2.3 is a pretty good overview of their approach: LE&H is based on a different, more sophisticated structure than AE&H's free monad. This structure supports non-atomic operations (e.g., function abstraction, thunking, quoting) that contain or delimit computations whose execution may be deferred. Also, the layered handling is different. The idea is still the same, to replace bit by bit the structure of the tree by its meaning. Yet, while AE&H grows the meaning around the shrinking tree, LE&H grows little "pockets of meaning" around the individual nodes remaining in the ## Integration verbosity and good layering DevFeed: [Integration verbosity and good layering]() Original publisher: [Read original article]() Published: 2021-04-07T00:00:00Z Content type: article Language: en Sources: [Jake Wharton]() Topics: [Android](), [XML](), [Dagger](), [SQLite](), [MySQL]() Tags: [abstraction](), [dagger](), [dependency](), [design](), [env-file-security](), [integrations](), [mysql](), [net-conf]() ### AI overview The article argues that integration verbosity can be a consequence of good layering. General-purpose libraries such as view binding, Dagger, SQLDelight, and RecyclerView must leave higher-level integration and configuration decisions to their callers, enabling more flexible libraries and platforms. ### Source excerpt One of my favorite non-features from building view binding is that it lacks integration with activities or fragments. If you use view binding with activities or fragments, however, this fact might be to your disdain. Every activity using view binding is forced to do something along the lines of: override fun onCreate(savedInstanceState: Bundle) { super.onCreate(savedInstanceState) val binding = ProfileViewBinding.inflate(layoutInflater) setContentView(binding.root) // Do stuff with 'binding' } This is textbook verbosity, and some would argue boilerplate. It only gets worse with fragments (due to their poor design and to no specific fault of view binding which works the same as any View reference). View binding exists at a different layer of abstraction than is appropriate for integration with higher-level components like activities or fragments. It serves as a type-safe representation of a schema declared in an XML file and that's it. It has no more knowledge of activities and fragments than the associated R.layout.profile_view integer does. Higher-level libraries like androidx.activity and androidx.fragment have integrations with those R.layout integers. If you're upset that view binding has no turn-key solution for activities and fragments then this is the tree you should be barking up. View binding wasn't built with verbosity in mind. Hell, it's not even that verbose. It ended up this way because it's the design the layer of abstraction it operates at demands. The same pattern occurs in some of my other favorite libraries. Dagger offers you nothing and requires that you build up the dependency injectors, their hierarchy, and their lifecycle entirely yourself. SQLDelight makes you specify database info in the build configuration and a database driver in the runtime API. RecylerView requires at minimum an adapter subtype and to choose and configure a layout manager. The layer at which these tools operate is sufficiently general such that their good design requires ## Applying Semantic Web Principles to Source Code for Better Understanding DevFeed: [Applying Semantic Web Principles to Source Code for Better Understanding]() Original publisher: [Read original article]() Author: Mattt (mattt@nshipster.com) Published: 2020-07-07T07:00:00Z Content type: opinion Language: en Sources: [NSHipster]() Topics: [Code](), [Semantic Web](), [Programming](), [Development](), [Syntax Highlighting](), [Universal Syntax Tree.](), [Website]() Tags: [abstraction](), [code](), [internet](), [miscellaneous](), [programming](), [publications](), [source](), [space](), [syntax-highlighting]() ### AI overview The article proposes applying semantic web principles to source code to improve understanding. It outlines language-agnostic representation, unique URL identifiers for packages, modules, and APIs, and decentralized information distributed across federated data sources. ### Source excerpt What if, instead of lowering source code down for the purpose of execution, we raised it for the purpose of understanding? ## Introducing the Activity Result APIs DevFeed: [Introducing the Activity Result APIs]() Original publisher: [Read original article]() Published: 2020-03-22T09:11:18Z Content type: tutorial Language: en Sources: [Posts on Adam Bennett]() Topics: [API](), [ui](), [Code]() Tags: [abstraction](), [algorithms](), [android](), [apis](), [architecture](), [blog](), [callback](), [camera](), [career](), [code](), [compose](), [data-type](), [development](), [engineering](), [finance](), [functional](), [growth](), [java](), [jetpack](), [kotlin](), [money](), [opinions](), [permission](), [software](), [startups](), [thoughts](), [training](), [tutorial](), [type-parameters](), [ui]() ### AI overview This tutorial introduces Google's Activity Result APIs as a reusable abstraction for handling activity callbacks. It explains the basic workflow, custom contracts, registration, invocation, and built-in contracts for permissions, phone calls, and taking pictures. ### Source excerpt Google has finally released the new Activity Result APIs, which are something I've been looking forward to for a very long time. In this post I'll run through the basics, how you can create your own contracts, and how this allows us to abstract away even more responsibilities from your UI. ## Computers can be understood DevFeed: [Computers can be understood]() Original publisher: [Read original article]() Author: Nelson Elhage Published: 2020-02-16T20:00:00Z Content type: opinion Language: en Sources: [Nelson Elhage]() Topics: [Software](), [systems](), [coding]() Tags: [abstraction](), [architecture](), [browser](), [compilers](), [complexity](), [concepts](), [cpu](), [exploration](), [hardware](), [javascript](), [kernel](), [learning](), [software](), [systems]() ### AI overview The author describes a mindset centered on the belief that computers and software systems can be understood through determined exploration and learning. Although modern systems are highly complex and layered, each layer can be understood at an appropriate level of abstraction, with deeper investigation possible when needed. ### Source excerpt Introduction This post attempts to describe a mindset I've come to realize I bring to essentially all of my work with software. I attempt to articulate this mindset, some of its implications and strengths, and some of the ways in which it's lead me astray. Software can be understood I approach software with a deep-seated belief that computers and software systems can be understood. This belief is, for me, not some abstruse theoretical assertion, but a deeply felt belief that essentially any question I might care to ask (about computers) has a comprehensible answer which is accessible with determined exploration and learning. ## Decoding Handler and Looper in Android DevFeed: [Decoding Handler and Looper in Android]() Original publisher: [Read original article]() Published: 2019-12-24T00:00:00Z Content type: tutorial Language: en Sources: [Vasya Drobushkov]() Topics: [Android](), [class](), [callback](), [interface](), [Code]() Tags: [abstraction](), [android](), [callback](), [class](), [code](), [interface](), [object](), [parcelable](), [payload](), [thread]() ### AI overview This tutorial explains Android's Handler and Looper, describing Looper as an event-loop abstraction that drains a MessageQueue and Handler as an abstraction for posting, removing, and handling queued events. It also covers their relationships and the structure of Message objects. ### Source excerpt Introduction Handler and Looper are one of the main low-level Android OS things, which almost nobody uses directly (at least nowadays). But they are at the core, so many other high-level solutions are based on them. Therefore one should know what Handler and Looper are, what and how they are doing. In this article we'll try to understand Handler and Looper in Android. What, how and why we might need them. We'll start from some basic knowledge on classes and what they are doing, continue with relations between them. Then we'll look at each class separately trying to dive deep into details. And will finish with some canonical examples on where they can be used. ## Space Shuttle style programming DevFeed: [Space Shuttle style programming]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2019-06-05T07:00:00Z Content type: opinion Language: en Sources: [Kaushik Gopal's Site]() Topics: [Programming](), [Kubernetes](), [Code](), [context]() Tags: [abstraction](), [code](), [context](), [kubernetes](), [programming]() ### AI overview This commentary examines "Space Shuttle style" programming, a deliberately verbose approach associated with a Kubernetes controller. The style emphasizes explicit comments, considered branches, and preserving business context so future maintainers can understand complex binding behavior. ### Source excerpt Sometime back I ran across a thread where folks talked about this programming style called "Space Shuttle style" that the Kubernetes codebase followed. // ================================================================== // PLEASE DO NOT ATTEMPT TO SIMPLIFY THIS CODE. // KEEP THE SPACE SHUTTLE FLYING. // ================================================================== // // This controller is intentionally written in a very verbose style. You will // notice: // // 1. Every 'if' statement has a matching 'else' (exception: simple error // checks for a client API call) // 2. Things that may seem obvious are commented explicitly // // We call this style 'space shuttle style'. Space shuttle style is meant to // ensure that every branch and condition is considered and accounted for - // the same way code is written at NASA for applications like the space // shuttle. // // Originally, the work of this controller was split amongst three // controllers. This controller is the result a large effort to simplify the // PV subsystem. During that effort, it became clear that we needed to ensure // that every single condition was handled and accounted for in the code, even // if it resulted in no-op code branches. // // As a result, the controller code may seem overly verbose, commented, and // 'branchy'. However, a large amount of business knowledge and context is // recorded here in order to ensure that future maintainers can correctly // reason through the complexities of the binding behavior. For that reason, // changes to this file should preserve and add to the space shuttle style. // // ================================================================== // PLEASE DO NOT ATTEMPT TO SIMPLIFY THIS CODE. // KEEP THE SPACE SHUTTLE FLYING. // ================================================================== To be clear: I don't follow the Space Shuttle style programming with my own code. However, I've noticed now that when I do comment my code, I'm a little more liberal with m [Next page]()