# module Published articles for module. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Java 27 Delivers Post-Quantum Cryptography, Future Language Innovation, Helidon 27, JavaFX 27 DevFeed: [Java 27 Delivers Post-Quantum Cryptography, Future Language Innovation, Helidon 27, JavaFX 27]() Original publisher: [Read original article]() Author: Michael Redlich Published: 2026-09-16T10:00:00Z Content type: news Language: en Sources: [InfoQ]() Topics: [Java](), [java-27](), [Post-quantum cryptography](), [Cryptography](), [Security](), [Programming](), [releases]() Tags: [application-security](), [architecture-design](), [cryptography](), [development](), [digital-signature](), [helidon](), [java](), [java-27](), [java27-released](), [javafx](), [jdk-27](), [jdk-28](), [lattice](), [module](), [news](), [oracle](), [portfolio](), [post-quantum-cryptography](), [preview](), [project-valhalla](), [quantum-computing](), [release](), [security](), [structured-concurrency](), [vector]() ### AI overview Oracle released Java 27, the second non-LTS release since JDK 25. Its final feature set contains nine JEPs, including post-quantum hybrid key exchange for TLS 1.3, structured concurrency, compact object headers, JFR data redaction, the Vector API, and PEM encodings for cryptographic objects. Five features remain in preview or incubator stages. ### Source excerpt Oracle has released version 27 of the Java programming language and virtual machine. As the second non-LTS release since JDK 25, the final feature set includes nine JEPs, five of which are still progressing through the preview and incubator stages. This release focuses on strengthening security, future language innovation, and projects under the auspices of the Java Verified Portfolio. By Michael Redlich ## Starting Android at Khan Academy DevFeed: [Starting Android at Khan Academy]() Original publisher: [Read original article]() Author: Khan Academy Published: 2016-02-29T23:00:00Z Content type: article Language: en Sources: [Khan Academy]() Topics: [Android](), [android-development](), [Development](), [Library](), [modules](), [ci](), [Mocking]() Tags: [android](), [android-development](), [development](), [engineering](), [libraries](), [mobile](), [mocking](), [module](), [modules](), [news](), [open-source](), [picasso](), [play-store](), [pre-commit](), [retrofit](), [test](), [tests]() ### AI overview Khan Academy describes its first Android app, launched in August 2015, and the engineering practices used to build it. The team adopted established Android and open-source libraries, separated Android-independent core code from the app module, and used fast JVM tests and continuous integration. ### Source excerpt By Ben Komalo The journey of a thousand miles... In March, 2015--almost 1 year ago to the day--we ... Read more ## CVITEK CV1842H-P-based edge AI camera module offers night vision and AI-ISP support (Crowdfunding) DevFeed: [CVITEK CV1842H-P-based edge AI camera module offers night vision and AI-ISP support (Crowdfunding)]() Original publisher: [Read original article]() Author: Debashis Das Published: 2026-09-16T00:00:55Z Content type: news Language: en Sources: [CNX Software - Embedded Systems News]() Topics: [Artificial Intelligence](), [Embedded Systems](), [AI Inference](), [V](), [Arm](), [cpu](), [Open Source](), [Ethernet](), [Linux](), [Toit]() Tags: [ai](), [arm](), [artificial-intelligence-ai](), [camera](), [computer-vision](), [cpu](), [debug](), [edge-ai](), [embedded](), [ethernet](), [hardware](), [inference](), [kickstarter](), [linux](), [module](), [open-source](), [real-time](), [risc-v](), [robotics](), [rt-thread](), [soc](), [sophgo](), [tinyml](), [usb](), [video](), [vision]() ### AI overview The AIMORELOGY Ovis is an open-source modular AI vision camera built around the CVITEK CV1842H-P SoC. It provides full-color 1080p night vision, 1.5 TOPS edge AI inference, USB and Ethernet connectivity, and a dual-OS environment using Linux and RT-Thread. ### Source excerpt The AIMORELOGY Ovis is an open-source AI vision camera module built around the CVITEK CV1842H-P SoC, with full-color 1080p night vision and 1.5 TOPS edge AI inference in a compact modular design. It is designed for drones, robotics, security systems, smart cameras, and custom embedded vision products. The camera features a compact stacked design, with a 20 x 20 mm Core board that includes the CVITEK CV1842H-P SoC, 2 Gbit NAND flash, USB, and UART debug pads. A Sensor board with the SC235HAI image sensor connects on top and also adds Ethernet and UART interfaces. An optional CVBS board goes between the Sensor board and the Ovis Core board. AIMORELOGY Ovis specifications: Ovis Core Board SoC - CVITEK CV1842H-P CPU - 1x Arm Cortex-A53 core @ 1.1 GHz, 1x RISC-V C906 core @ 800 MHz NPU - 1.5 TOPS @ INT8 with BF16 support ISP - AI-ISP with real-time 1080p [...] The post CVITEK CV1842H-P-based edge AI camera module offers night vision and AI-ISP support (Crowdfunding) appeared first on CNX Software - Embedded Systems News. ## How to Write a Linux Kernel Module That Actually Builds DevFeed: [How to Write a Linux Kernel Module That Actually Builds]() Original publisher: [Read original article]() Author: Chris Roy Published: 2026-09-15T21:10:57Z Content type: tutorial Language: en Sources: [freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More]() Topics: [Kernel](), [Linux](), [modules](), [Compiler](), [Secure Boot]() Tags: [compiler](), [kernel](), [linux](), [linux-kernel](), [module](), [secure-boot](), [tutorial]() ### AI overview This tutorial explains how to build and load a Linux kernel module, including the generated object files, metadata, symbols, debug information, required kernel headers and compiler setup, and common Secure Boot and kernel lockdown restrictions. ### Source excerpt A Linux kernel module is a small piece of code that can be loaded into the running kernel without rebuilding the entire kernel. That sounds simple enough, but even a minimal module produces a surprisi ## The Android Startup Pattern: A Lifecycle-Aware, Multi-Module Approach DevFeed: [The Android Startup Pattern: A Lifecycle-Aware, Multi-Module Approach]() Original publisher: [Read original article]() Author: Ehab Elwan Published: 2026-09-13T05:31:09Z Content type: tutorial Language: en Sources: [ProAndroidDev - Medium]() Topics: [Android](), [modules](), [Jetpack](), [Framework]() Tags: [android](), [android-development](), [app-startup](), [architecture](), [framework](), [jetpack](), [kotlin](), [mobile-architecture](), [module](), [privacy](), [software-architecture]() ### AI overview This tutorial presents a lifecycle-aware, dependency-injection-driven startup pattern for modular Android applications. It contrasts a centralized startup anti-pattern with Jetpack App Startup and discusses process lifecycles, testability, and delaying tracking SDK initialization until privacy consent is evaluated. ### Source excerpt A Clean, DI-Driven Architecture for Managing Cold Starts, Background Wakeups, and Privacy Compliance in Modern Android Apps Image generated by AIDisclosure: This article was drafted by me and refined with the help of AI tools. Every growing Android project eventually spawns a two-headed "God Class." On one side, your Application class becomes a dumping ground for global infrastructure--third-party SDKs, crash reporters, and tracking tools. On the other side, your main entry point (typically the MainViewModel) gets choked with UI-blocking startup logic. It usually looks something like this: The Anti-Pattern: The Two-Headed God Class class MyApplication : Application() { override fun onCreate() { super.onCreate() // The framework dumping ground CrashReportingSDK.getInstance().setCollectionEnabled(true) HeavyUiSDK.initialize(context = this, ...) AnalyticsSDK.initialize(this, "API_KEY") // ... 50 more lines of spaghetti } }class MainViewModel : ViewModel() { init { // The UI-blocking dumping ground updateRemoteConfigs() checkUserSessionToken() processPendingDeepLinks() prefetchHomeFeedData() // ... UI cannot render until this finishes } } Splitting initialization across these two files creates major problems: It breaks the Single Responsibility Principle: The app's entry points are forced to orchestrate the inner workings of every single feature, tightly coupling your modules. It ignores process lifecycles: Application tasks run indiscriminately on every silent background wakeup, while MainViewModel tasks fail to re-trigger when the app returns to the foreground. It destroys testability: Hardcoding SDK initializations directly into your entry points makes it incredibly difficult to write isolated unit tests without complicated mocking setups. It complicates privacy compliance: A centralized dumping ground makes it extremely difficult to dynamically suspend tracking SDKs until user consent under global privacy regulations (such as GDPR, CCPA, and CPRA) is explicitly grant ## M5Stack Module13.2 LoRa-1262 expansion board integrates 14x10 mm Stamp LoRa-1262 module DevFeed: [M5Stack Module13.2 LoRa-1262 expansion board integrates 14x10 mm Stamp LoRa-1262 module]() Original publisher: [Read original article]() Author: Debashis Das Published: 2026-09-13T05:02:54Z Content type: news Language: en Sources: [CNX Software - Embedded Systems News]() Topics: [lora](), [systems]() Tags: [connectivity](), [development-board](), [embedded-systems](), [hardware](), [i2c](), [io](), [iot](), [lora](), [lorawan](), [low-power](), [lpwan](), [m5stack](), [module](), [news](), [power-management](), [routing](), [series](), [smart-agriculture](), [smart-city](), [spi](), [wireless]() ### AI overview M5Stack has launched the Stamp LoRa-1262 SMD module and the stackable Module13.2 LoRa-1262 expansion board for M5Stack Core controllers. Based on the Semtech SX1262, the module supports several modulation modes across 868-923 MHz, with up to +22 dBm transmit power and -147 dBm receive sensitivity. Module13.2 adds an RP-SMA antenna interface, M5IOE1 I/O expansion, configurable pin routing, and selectable I2C addresses for multi-module stacking. ### Source excerpt After launching the SX1262-based M5Stamp C6LoRa tiny module, M5Stack has launched two SX1262-based LoRa add-ons for the 868-923 MHz band: the tiny Stamp LoRa-1262 SMD module for custom PCBs, and the stackable Module13.2 LoRa-1262 module for the M5Stack Core series. The Stamp LoRa-1262 supports LoRa, FSK, GFSK, MSK, GMSK, and OOK modulation, with up to +22 dBm transmit power and -147 dBm receive sensitivity. The Module13.2 adds an RP-SMA antenna interface, an M5IOE1 IO expansion chip for reset and power management, and DIP switches for flexible pin routing and configurable I2C addresses, enabling multi-module stacking. Stamp LoRa-1262 SMD module M5Stack Stamp LoRa-1262 specifications: LoRa Transceiver - Semtech SX1262 Wireless Connectivity (LoRa) Frequency Band - 868 to 923 MHz Modulation Modes - LoRa, FSK, GFSK, MSK, GMSK, OOK Bitrate - Up to 300 kbps (programmable) Transmit power (Tx) - Up to +22 dBm Receive sensitivity (Rx) - Down to -147 dBm [...] The post M5Stack Module13.2 LoRa-1262 expansion board integrates 14x10 mm Stamp LoRa-1262 module appeared first on CNX Software - Embedded Systems News. ## Quiz: Python 3.15 Preview: Lazy Imports DevFeed: [Quiz: Python 3.15 Preview: Lazy Imports]() Original publisher: [Read original article]() Author: Real Python Published: 2026-09-09T12:00:00Z Content type: article Language: en Sources: [Real Python]() Topics: [Python](), [.NET 11]() Tags: [module](), [python](), [time]() ### AI overview An interactive 12-question quiz tests understanding of Python 3.15 Preview lazy imports, including the lazy keyword, __lazy_modules__, deferred module loading, startup-time savings, restrictions, older-Python alternatives, and imports that must remain eager. ### Source excerpt Test your understanding of Python 3.15 lazy imports, from the lazy keyword and __lazy_modules__ to the imports that have to stay eager. ## Setting Up Koin in a Real Kotlin Multiplatform Project: A Step-by-Step Guide DevFeed: [Setting Up Koin in a Real Kotlin Multiplatform Project: A Step-by-Step Guide]() Original publisher: [Read original article]() Author: Gabriel Bronzatti Moro Published: 2026-09-07T12:01:03Z Content type: tutorial Language: en Sources: [Koin developers - Medium]() Topics: [Kotlin Multiplatform](), [compose-multiplatform](), [Kotlin](), [Android](), [iOS](), [ui]() Tags: [android](), [compose-multiplatform](), [dependencies](), [guide](), [implementation](), [ios](), [kmp](), [koin](), [kotlin](), [kotlin-multiplatform](), [mobile-app-development](), [module](), [viewmodel]() ### AI overview A step-by-step tutorial for setting up Koin in a Kotlin Multiplatform project targeting Android and iOS. It covers dependencies, data, domain, and UI modules, a platform bridge, platform entry points, and dependency injection in Composables. ### Source excerpt Hi everyone! 👋 In this article, we'll take a practical, step-by-step approach to setting up Koin in a real-world Kotlin Multiplatform (KMP) project. Instead of starting with an isolated example or a simple Hello World, we'll work with a project created by the CodandoTV community: the World Cup Best Team Simulator. The app allows users to browse football players by country and build their own dream team. It runs on both Android and iOS, using Kotlin Multiplatform for sharing business and data logic, and Compose Multiplatform to share the UI across platforms. Step 1: Add Koin Dependencies Add the Koin libraries to your version catalog: # gradle/libs.versions.toml [versions] koin = "4.2.2" [libraries] koin_core = { group = "io.insert-koin", name = "koin-core", version.ref = "koin" } koin_android = { group = "io.insert-koin", name = "koin-android", version.ref = "koin" } koin_compose = { module = "io.insert-koin:koin-compose", version.ref = "koin" } koin_compose_viewmodel = { module = "io.insert-koin:koin-compose-viewmodel", version.ref = "koin" } In the shared module shared/build.gradle.kts, split the dependencies by source set -- commonMain gets the shared Koin libraries, androidMain gets the Android-specific one: // shared/build.gradle.kts sourceSets { commonMain.dependencies { implementation(libs.koin.core) implementation(libs.koin.compose) implementation(libs.koin.compose.viewmodel) } androidMain.dependencies { implementation(libs.koin.android) } } In the Android app module androidApp/build.gradle.kts , add the Android Koin dependency: // androidApp/build.gradle.kts dependencies { implementation(libs.koin.android) implementation(libs.koin.core) }Step 2: Create the Data Module Create shared/src/commonMain/.../data/DataModule.kt . This module provides singleton instances -- repositories, and data sources that live for the entire app lifecycle. val dataModule = module { single { WorldCupRepositoryImpl(ioDispatcher = Dispatchers.IO) } }Step 3: Create ## State divergence enables unauthorized access DevFeed: [State divergence enables unauthorized access]() Original publisher: [Read original article]() Author: "Paweł Płatek"; "Denys Pakizh" Published: 2026-08-25T11:00:00Z Content type: article Language: en Sources: [The Trail of Bits Blog](), [The Trail of Bits Blog]() Topics: [bug](), [Blockchain](), [Authorization](), [Transactions](), [SDKs]() Tags: [2026](), [access-control](), [audits](), [authorization](), [blockchain](), [bug](), [financial-services](), [module](), [tokens](), [transactions](), [vulnerabilities]() ### AI overview The article describes a Provenance Blockchain authorization bug that allowed users to grant themselves admin control over marker accounts without holding tokens. The flaw affected non-fixed-supply markers because the access check read a stale zero-valued supply field instead of the live circulating supply. The issue was mitigated in v1.28.0 and fixed in v1.29.0. ### Source excerpt We found and reported a bug in Provenance Blockchain, a public proof-of-stake chain built on Cosmos SDK, that lets any user grant themselves admin control over marker accounts without holding a single token. Provenance covers a range of financial services, including on-chain tokenized loans, private equity tokens, bridged assets, and asset registries. Our bug affected 82 markers representing live financial assets on mainnet. We found the bug, which affects versions before 1.28.0, in March 2026, and reported it to Provenance on April 1. It was mitigated in PR #2627 (commit c81fd65), which shipped in v1.28.0 on May 1, 2026, and fixed in PR #2734, which shipped in v1.29.0 on June 8, 2026. What is a marker? The marker module is Provenance's core primitive for fungible tokens. Chain participants can issue a new asset on Provenance by submitting a MsgAddMarkerRequest transaction; the chain creates a dedicated account for that asset, called a marker. Each marker is a special account type that controls: A denomination (e.g., uusd.trading, cusd.deposit, cguaranteedrateomni) An access control list governing who can mint, burn, withdraw, deposit, or administer the token A supply field recording the canonical token count An escrow balance (the marker account can hold any asset, not just its own denomination) Markers are either supply_fixed (the supply field is enforced as a hard cap) or non-fixed (the bank module is the source of truth; the supply field is informational). This distinction is central to the bug. The bug: An access check anyone can pass AddAccess is the Cosmos SDK message handler that processes requests to modify a marker's access control list. It checks whether the caller is authorized using three conditions, any one of which is sufficient: The caller is the marker's designated manager and the marker is in Finalized state. The caller already holds ACCESS_ADMIN on the marker. The caller controls 100% of the marker's circulating supply. case types.StatusFinalized, ## Keep Kotlin Multiplatform bindings at the platform boundary DevFeed: [Keep Kotlin Multiplatform bindings at the platform boundary]() Original publisher: [Read original article]() Published: 2026-08-18T00:00:00Z Content type: tutorial Language: en Sources: [Koin - Cloud-Inject.io -Kotzilla]() Topics: [Kotlin Multiplatform](), [Kotlin](), [implementation](), [modules](), [configuration](), [test]() Tags: [configuration](), [implementation](), [kotlin](), [kotlin-multiplatform](), [module](), [multiplatform](), [test](), [verification]() ### AI overview A guide to keeping Kotlin Multiplatform dependency bindings at platform boundaries. It recommends defining small capability interfaces in common code, implementing them in platform source sets, organizing modules around capabilities and product features, and testing both shared contracts and real platform bindings. ### Source excerpt Kotlin Multiplatform makes source-set boundaries visible, but a dependency container can blur them again. A shared module should state a capability such as secure storage, HTTP transport, or local time. The platform source set should supply the implementation. Put contracts where consumers can see them Define the smallest useful interface in common code. Avoid copying a platform API into that interface. A storage contract might expose read, write, and remove; it does not need to expose Android preferences or an Apple keychain type. ## jetc.dev Newsletter Issue #322 DevFeed: [jetc.dev Newsletter Issue #322]() Original publisher: [Read original article]() Author: CommonsWare Published: 2026-07-14T14:00:00Z Content type: article Language: en Sources: [jetc.dev | Issues]() Topics: [Jetpack Compose](), [compose-for-desktop](), [multiplatform](), [Android](), [navigation]() Tags: [android](), [compose](), [compose-for-desktop](), [compose-multiplatform](), [dev](), [jetpack-compose](), [module](), [navigation]() ### AI overview This newsletter issue rounds up recent Jetpack Compose developments and related community content, including Compose updates, TV Compose performance, navigation, filter bars, settings-screen DSLs, Compose Multiplatform with SwiftUI, and Compose for Desktop performance. ### Source excerpt SubcomposeLayout! TV Compose! Nav3! Filter bars! Setting screens! And... can we make Compose for Desktop better?!? ## Practical Kotlin Multiplatform: Setting up the Kotlin Multiplatform Networking Module with Ktor DevFeed: [Practical Kotlin Multiplatform: Setting up the Kotlin Multiplatform Networking Module with Ktor]() Original publisher: [Read original article]() Author: hitherejoe Published: 2026-07-10T16:16:31Z Content type: tutorial Language: en Sources: [Joe Birch]() Topics: [Kotlin Multiplatform](), [Kotlin](), [Ktor](), [networking](), [REST API](), [Authentication](), [Firebase](), [Gradle](), [implementation](), [Android](), [iOS]() Tags: [android](), [android-app-development](), [android-development](), [androiddev](), [app-development](), [authentication](), [firebase](), [gradle](), [implementation](), [ios](), [jetpack-compose](), [kotlin](), [kotlin-multiplatform](), [ktor](), [library](), [mobile-app-development](), [module](), [networking](), [rest-api]() ### AI overview A tutorial series installment that sets up a Kotlin Multiplatform networking module with Ktor for shared Android and iOS code. It describes building a portable Firebase Authentication and Firestore REST API layer without relying on platform-specific SDKs. ### Source excerpt This post is part one of a series adapted from Practical KMP, my book on building production Kotlin Multiplatform apps for Android and iOS. Part 1: Creating the Kotlin Multiplatform Module In this part of the book, we'll build the complete authentication remote store, defining a repository that handles every operation our app needs for... Continue reading -> ## How AI agents could shift software work from code changes to specifications and module rebuilds DevFeed: [How AI agents could shift software work from code changes to specifications and module rebuilds]() Original publisher: [Read original article]() Author: Kaushik Gopal Published: 2026-05-04T16:00:00Z Content type: opinion Language: en Sources: [Kaushik Gopal's Site]() Topics: [Artificial Intelligence](), [Software Engineering](), [Agent Skills](), [Software](), [Refactoring](), [modules](), [patches]() Tags: [agents](), [ai](), [code](), [module](), [patches](), [refactoring](), [software-engineering]() ### AI overview This opinion article argues that AI agents may act like compilers, turning detailed specifications into software and reducing the need to write implementation code directly. Drawing on examples where the author changed implementations while preserving behavior, it suggests that agents could make rebuilding entire modules more practical than incremental patching and refactoring. ### Source excerpt Linus Torvalds recently said1 AI will be to code what compilers were to assembly -- freeing us from writing it by hand. Around the same time, I talked with Jesse Vincent (creator of one of the most popular agent skills out there -- superpowers). Something he said stuck with me: Specs are going to be the new code. I realize those two ideas snap together a little too neatly. Agents are compilers2 and specs will become code. Software engineering is moving up another level of abstraction and we've seen this play out before. Specs as source ## I saw this first-hand with my tiny USB-C cable checker -- usbi. It started as a shell command over macOS's system_profiler, then became Go when I wanted a proper binary, then Rust because I wanted to practice Rust, and later a .kts version. The code kept changing. The thing I cared about did not: parse the USB tree, identify the attached devices, report the speed, and make bad cables obvious. Podsync, my voice track sync program, followed the same pattern. It started in Python because the audio libraries were there. Then I moved it to Rust because I didn't want to ship a Python runtime or care which Python version happened to be on a machine. Again, the implementation changed. The behavior stayed boringly stable: take a master track and local tracks, find the offset, pad or trim each file, and drop aligned audio into the DAW. Compilers freed us from writing assembly. Agents may free us from writing code because it becomes an artifact the spec produces. The somewhat recent push around detailed exec plans could be an early signal of the looming shift at bigger scale. Rebuilds instead of patches ## Push that thought further. We might get comfortable rebuilding whole modules instead of patching and refactoring them. We preserved the old shape of a system because throwing it away cost too much. Even when you know the module is wrong, you sand it down: extract an interface, migrate one caller at a time, add tests around behavior nobody full ## Upgrade Cypress To TypeScript v6 DevFeed: [Upgrade Cypress To TypeScript v6]() Original publisher: [Read original article]() Author: Gleb Bahmutov Published: 2026-04-23T04:00:00Z Content type: tutorial Language: en Sources: [Gleb Bahmutov]() Topics: [Cypress](), [TypeScript](), [upgrade](), [Webpack]() Tags: [cypress](), [import](), [module](), [products](), [typescript](), [upgrade](), [webpack]() ### AI overview This tutorial explains how to upgrade Cypress projects to TypeScript v6. It recommends using bundler module resolution with Webpack and adjusting transpilation and path-alias options when needed. ### Source excerpt Finally, it has happened. Cypress v15.14 supports TypeScript v6. This is a big deal ## Introducing the Koin Migration Skills DevFeed: [Introducing the Koin Migration Skills]() Original publisher: [Read original article]() Author: Arnaud Giuliani Published: 2026-04-22T13:23:59Z Content type: article Language: en Sources: [Koin developers - Medium]() Topics: [migration](), [Kotlin](), [Claude Code](), [Android](), [Dagger]() Tags: [android](), [claude-code](), [compiler](), [dagger](), [dagger-hilt](), [dependency-injection](), [gradle](), [koin](), [kotlin](), [migration](), [module](), [verification]() ### AI overview The article introduces the Koin Migration Skill, a Claude Code plugin for migrating Kotlin and Android projects from Hilt, Dagger, Toothpick, Kodein, or older Koin versions to Koin 4.x and the Koin Compiler Plugin. It describes module-by-module inventory, ranked migration planning, compile-time verification, and human checkpoints. ### Source excerpt Hello all 👋 Migrating a Kotlin or Android project between DI frameworks (Hilt, Dagger, Toothpick, Kodein, or older Koin versions) is one of those strategic refactors that every team puts off. It touches every module, the call sites are everywhere, and the migration plan never quite survives contact with the real codebase. We wanted to take the pain out of it. So we built the Koin Migration Skill: a Claude Code plugin that automates DI migrations to Koin 4.x and the Koin Compiler Plugin, module by module, with compile-time verification and a human-in-the-loop at every step. Koin Migration Project -- 1.0.0What it covers Initially, this project is intended to help Koin developers to migrate to use the new Koin Compiler Plugin. The skill supports every realistic migration path into modern Koin, with Koin Compiler if possible. This uses either annotations or the safe DSL: Hilt -> Koin (with koin-android-dagger bridging during migration) Dagger -> Koin Toothpick -> Koin Kodein -> Koin Koin 3.x -> Koin 4.x upgrade Classic Koin DSL -> Safe DSL Koin KSP Annotations -> Koin Compiler Plugin All paths converge on the same target: Koin 4.x with Annotations or Safe DSL, powered by the Koin Compiler Plugin for compile-time DI graph verification. How it works Project documentation is available: https://github.com/InsertKoinIO/koin-migration. Point Claude at your project and describe what you want to migrate. /plugin marketplace add InsertKoinIO/koin-migration /plugin install koin-migration@koin-migrationAdding Skill in current project The skill opens with a full inventory of your DI setup: every module, binding, qualifier, and scope. It immediately produces a ranked migration table. The NowInAndroid project below has 35 DI files across core, feature, app, and sync layers. The skill maps each one: bindings count, downstream dependants, complexity rating, and a recommended order. Modules inventory, DI features usage and mapping You can't go "big-bang" in that kind of approach. You need to st ## Leveraging @RequireOptIn to create composables that can be used only in previews DevFeed: [Leveraging @RequireOptIn to create composables that can be used only in previews]() Original publisher: [Read original article]() Author: Leonidas Partsas Published: 2026-03-22T14:32:15Z Content type: tutorial Language: en Sources: [le0nidas]() Topics: [Kotlin](), [Jetpack Compose](), [Code]() Tags: [android](), [compilation-error](), [components](), [how-to](), [jetpack-compose](), [know-your-tools](), [kotlin](), [module](), [preview](), [production](), [requireoptin]() ### AI overview This tutorial explains how to use Kotlin's @RequiresOptIn mechanism with a @PreviewOnly annotation to expose composables for preview rendering across modules while preventing their use in production code. Explicit opt-in is required at each call site, otherwise compilation fails. ### Source excerpt Anyone working with Kotlin, especially in the android world, has dealt with RequireOptIn. Actually they had to deal with the consequence of its application which is to explicitly opt-in into using a piece of code that is annotated with it. @RequiresOptIn In a nutshell, if you want the consumer of your code to be fully ... Continue reading Leveraging @RequireOptIn to create composables that can be used only in previews -> ## Waiting for PostgreSQL 19 - Add pg\_plan\_advice contrib module. DevFeed: [Waiting for PostgreSQL 19 - Add pg\_plan\_advice contrib module.]() Original publisher: [Read original article]() Author: depesz Published: 2026-03-22T13:44:10Z Content type: tutorial Language: en Sources: [select \* from depesz;]() Topics: [PostgreSQL](), [systems]() Tags: [advice](), [hint](), [module](), [pg-plan-advice](), [pg19](), [plan](), [planner](), [postgresql](), [statistics](), [uncategorized](), [waiting]() ### AI overview This article examines PostgreSQL's proposed pg_plan_advice contrib module, explaining why query planners sometimes choose suboptimal plans, how plan hints could stabilize or override those choices, and how to load and test the extension. ### Source excerpt On 12nd of March 2026, Robert Haas committed patch: Add pg_plan_advice contrib module. Provide a facility that (1) can be used to stabilize certain plan choices so that the planner cannot reverse course without authorization and (2) can be used by knowledgeable users to insist on plan choices contrary to what the planner believes ... Continue reading "Waiting for PostgreSQL 19 - Add pg_plan_advice contrib module." ## 11ty Hacks for Fun and Performance DevFeed: [11ty Hacks for Fun and Performance]() Original publisher: [Read original article]() Author: Alex Russell Published: 2025-10-04T00:00:00Z Content type: tutorial Language: en Sources: [Alex Russell]() Topics: [Script](), [Nunjucks](), [Markdown](), [Web Development](), [Code]() Tags: [11ty](), [async](), [blog](), [blogging](), [build](), [code](), [fun](), [hacks](), [how-to](), [js](), [module](), [performance](), [script](), [web](), [webdev]() ### AI overview A developer shares techniques for improving performance in an 11ty site, including selectively loading shortcode resources through the 11ty Bundle plugin, avoiding duplicate scripts, and handling Nunjucks and Markdown preprocessing. ### Source excerpt This blog really isn't just for beating up on Apple for the way it harms users, the web, standards, and society to maintain power and profits. So here's some fun stuff I've been doing in my 11ty setup to improve page performance. Contents Page-Specific Resources via Shortcodes and the 11ty Bundler Mo Pagination, Mo Problems Build Time Impact Scroll-Position Based Delayed Code Loading Faster CSS Selectors for 11ty Syntax Highlighting Lean Rada's CSS-only Low-Quality Image Previews Bonus Hack: Global Acronyms for Better Abbreviations Does It Work? Page-Specific Resources via Shortcodes and the 11ty Bundler You know how it gets once you've got a mature 11ty setup: shortcodes proliferate, and some generate output that might depend on JS or CSS. If your setup is anything like mine, you might also feel conflicted about including some of those resources globally. It's important to have them available for the posts that need them, but it's not great to bring a charting library, e.g., into every page when only 1 in 20 will need it. This blog has grown many such shortcodes that generate expansions for features like: Web Components for YouTube and Vimeo embeds WebPageTest.org test embeds plot.js based charts Here, for instance, is how a Vimeo embed looks in the markdown of a page, using Nunjucks for Markdown pre-processing: {% vimeo "VIDEOID", "TITLE" %} This expands to: TITLE But this also requires script; e.g.: And the list keeps growing. To avoid having the weight of these components clogging up every page, a system for selectively pulling in their code would be helpful. It'd also be grand if we could make sure scripts appear just once, even if shortcodes are invoked multiple times per page. Included code should preferably also be located towards the top of the document. The 11ty Bundle plugin ## Multi-Module Projects with Cangjie DevFeed: [Multi-Module Projects with Cangjie]() Original publisher: [Read original article]() Author: Jasper Morgan Published: 2025-09-02T12:39:21Z Content type: tutorial Language: en Sources: [Snapp Mobile - Medium]() Topics: [Package manager](), [modules](), [configuration](), [Code](), [Command-line interface]() Tags: [building](), [cangjie](), [cli](), [configuration](), [huawei](), [init](), [module](), [programming](), [run](), [structure]() ### AI overview A tutorial on using the Cangjie package manager, cjpm, to create and configure multi-module projects. It covers initializing a workspace, adding executable and library modules, registering them in the workspace configuration, adding source code, building, and running the project. ### Source excerpt The Cangjie package manager cjpm is a cli tool which can be used to setup multi-module projects. A module is simply a folder with a cjpm.toml file - whilst these can also be created by hand, the cli tool simplifies the process. The approach to the setup is to create a cjpm workspace at the project root and then separate module within the workspace. It will look like this: my-project (workspace) -- module-1 -- module-2 -- module-3Create the workspace In the root of your project, initialise a workspace: # create a project folder mkdir cat-pic-downloader cd cat-pic-downloader # initialise the workspace cjpm init --workspace At this stage, your project directory will have a cjpm.toml which is the configuration for your workspace. A newly initialised workspace config will look like this. [dependencies] [workspace] build-members = [] compile-option = "" link-option = "" members = [] target-dir = "" test-members = []Add the modules To add a module to the project, use the cjpm init command but with the options to specify the type of module to create (executable, a static library or a dynamic library). Let's add a couple of modules to our sample project. # create a static lib module called 'downloader' cjpm init --type=static --path downloader # create a static lib module called 'img-processor' cjpm init --type=static --path img_processor # create an executable module called 'runner' cjpm init --type=executable --path runner By default, a newly created module has a src directory and it's own cjpm.toml to configure the module. (Static library modules will have no source code. Executable modules will have a main.cj file.) Add the modules to the workspace So that the workspace is aware of the modules we created, we need to add them to the members field of the workspace's cjpm.toml. Edit the cjpm.toml as follows. [dependencies] [workspace] build-members = [] compile-option = "" link-option = "" members = ["./runner", "./downloader", "./img_processor"] target-dir = "" test-member ## How Imports Work in RSC DevFeed: [How Imports Work in RSC]() Original publisher: [Read original article]() Published: 2025-06-05T00:00:00Z Content type: tutorial Language: en Sources: [Dan Abramov]() Topics: [modules](), [JavaScript](), [Back end](), [Front end](), [Programming]() Tags: [article](), [code](), [components](), [deep-dive](), [javascript](), [module]() ### AI overview This deep dive explains how JavaScript module systems split code between frontend and backend environments, and how React Server Components use import-related semantics to support applications spanning both sides. ### Source excerpt A layered module system. ## Python 3.14 Adds compression.zstd for Zstandard Support DevFeed: [Python 3.14 Adds compression.zstd for Zstandard Support]() Original publisher: [Read original article]() Author: Abhimanyu Saharan Published: 2025-05-22T00:00:00Z Content type: article Language: en Sources: [Abhimanyu Saharan]() Topics: [Python 3.14](), [Compression](), [Python]() Tags: [compression](), [module](), [python](), [python-3-14]() ### AI overview Python 3.14 introduces a native compression.zstd module for Zstandard support, bringing high-performance zstd compression and existing standard-library compressors together under one namespace. ### Source excerpt Python 3.14 adds a native Zstandard module under compression.zstd, unifying high-performance zstd support and existing stdlib compressors under one namespace. ## Vector Sets are part of Redis DevFeed: [Vector Sets are part of Redis]() Original publisher: [Read original article]() Published: 2025-04-03T18:01:20Z Content type: article Language: en Sources: [Antirez]() Topics: [Redis](), [Data structures](), [API](), [Programming]() Tags: [api](), [data-structure](), [design](), [modularity](), [module](), [native](), [redis](), [vector]() ### AI overview The article announces that Vector Sets have been merged into Redis. It describes them as a new Set-like data type that stores vectors, supports vector-similarity queries, and will be available as a native data type in Redis 8 while retaining modular internal boundaries. The feature is still in beta. ### Source excerpt Yesterday we finally merged vector sets into Redis, here you can find the README that explains in detail what you get: https://github.com/redis/redis/blob/unstable/modules/vector-sets/README.md The goal of the new data structure is, in short, to create a new "Set alike" data type, similar to Sorted Sets, where instead of having a scalar as a score, you have a vector, and you can add and remove elements the Redis way, without caring about anything except the properties of the abstract data structure Redis implements, ask for elements similar to a given query vector (or a vector associated to some element already in the set), and so forth. But more about that later, a bit of background, first: From the path of the README itself, you can see the implementation is into "modules", but actually, Vector Sets are not a module, it's a part of the Redis core, the thing is that I started developing them as a module, and later I suggested that the implementation should still use the modules API, in order to promote modularity of the internals of Redis, in order to have both the advantages: every Redis instance starting from Redis 8 will have Vector Sets as a native data type, and there are clear boundaries between the core and the implementation ## The first new main data type of Redis after... some time I think that the latest big data structure of Redis were Streams, also developed by me. I resigned, returned, forks happened in the meantime, and it still it looks like the burden to introduce a new data type in Redis is mine :D I must say: I'm ok with that, because as much as I like programming, I also like design, a lot, and I had a feeling, that vectors, and vector similarity, are conceptually very simple, so they deserved a very simple API. And that was what I tried to do. Vector Sets are still a beta feature but I can tell you something, I can guarantee you can learn the API in 3 minutes. I decided that a fundamental requirement for implementing vector similarity was to also ## Assorted NixOS things DevFeed: [Assorted NixOS things]() Original publisher: [Read original article]() Author: Harsh Shandilya Published: 2024-12-07T20:19:00Z Content type: article Language: en Sources: [Posts on Harsh Shandilya]() Topics: [Nix](), [Command-line interface](), [systems](), [tailscale](), [Virtual Private Network](), [Text-based user interface]() Tags: [cli](), [commands](), [configuration](), [dependencies](), [errors](), [git](), [module](), [nix](), [nixos](), [nixpkgs](), [packages](), [repl](), [tailscale]() ### AI overview A running log of practical NixOS, Nix, and Nixpkgs notes covering flake metadata, the module system, package updates, the Nix language, REPL builds, fixed-output derivations, and Tailscale exit nodes. ### Source excerpt Running log of random things I've learned about Nix/NixOS/Nixpkgs ## Kermit 2.0.5 updates OSLogWriter and adds file logging - Kevin Schildhorn DevFeed: [Kermit 2.0.5 updates OSLogWriter and adds file logging - Kevin Schildhorn]() Original publisher: [Read original article]() Published: 2024-11-22T00:00:00Z Content type: release Language: en Sources: [Touchlab | Enterprise Mobile Innovation & Development]() Topics: [Logging](), [iOS](), [IO](), [Kotlin](), [Library](), [file]() Tags: [added](), [automatic](), [features](), [io](), [ios](), [kermit](), [kotlin](), [kotlin-multiplatform](), [library](), [logging](), [logs](), [module](), [sample](), [swift](), [update](), [updates]() ### AI overview Kermit 2.0.5 has been released with updates to OSLogWriter, an upgrade to Kotlin 2.0.10, and a new Kermit-IO module for writing logs to files. The release also adds configurable iOS log categorization, filtering, grouping, and public-versus-redacted log behavior. ### Source excerpt The 2.0.5 update for Kermit is out now and features various updates to OSLogWriter, as well as the ability to log to a file. [Next page]()