标签：#UX

This is a condensed version of my preprint ( DOI: 10.5281/zenodo.21345310 , CC BY 4.0). Reference implementation: askbar.pro . The library problem For thirty years the website has been a library: a visitor arrives with one question and is expected to find the answer themselves, navigating menus, pages, and filters. Visitors read a small fraction of site content. Most leave without doing the thing the site owner hoped for. Chat widgets bolted onto such sites change nothing: the maze remains, the widget just answers questions about the maze. The pattern The Librarian Pattern inverts the relationship. The site does not present itself; it asks what you need and assembles the answer. The bar as the primary interface. One persistent input, text and hold-to-talk voice. It replaces navigation. Scene reassembly (generative UI). The center of the screen is not a page but a scene, composed per recognized intent. Transitions morph rather than reload. A guide with a plan. The conversational layer is a consultant with a goal ladder, asking one next question, never presenting menus of three options. Two button systems. Global suggestion chips above the bar are visually separated from in-scene action cards. This prevents the "six buttons" degeneration of chat UIs. The static shadow. Every live scene has a server-rendered twin page: full text in the DOM, question-shaped headings, FAQ schema, llms.txt, freshness stamps. Humans get the agent; crawlers and AI answer engines get complete, citable pages, generated from the same content source. Structural GEO-readiness. Content already organized as questions and answers matches how generative engines retrieve and cite, by construction. The result that surprised me 24 hours after the discoverability layer went public, Yandex Alice (the largest Russian AI answer engine) began citing the reference implementation as its prime example for the "next-generation website" query, describing the mechanics correctly and distinguishing it from "a chat

Developers flagged a freshly filed, reproducible issue that should make anyone running background agents pause: Claude Code's background Opus subagents intermittently stall on their first turn and, instead of producing useful work, emit system-prompt fragments — including text shaped like authorization data — as their only output. It's labeled a security issue, it has a reproduction, and it's open. That's enough to treat it as a real, if intermittent, class of failure. Here's the mental model that matters: a subagent is not a trusted subprocess. It's an autonomous loop with access to a context window, a toolset, and — too often — the same credentials as its parent. When that loop stalls and dumps its prompt instead of its result, anything that was in context is now in output. Authorization-shaped text leaking is the canary: if the prompt carried a token, a session string, or an internal endpoint, that's what surfaces. The fix is structural, not reactive. Three rules: 1. Scope credentials per subagent, not per session. A background agent that only needs to read a repo shouldn't hold deploy keys. Hand it the narrowest token that completes its task and revoke it when the task ends. If the tooling can't scope credentials, that's a gap to close before you scale subagents. 2. Treat subagent output as untrusted. Anything a subagent returns — including error text, logs, and especially "stalled" dumps — should be parsed and sanitized before it touches shared state. Don't pipe raw subagent output into a context that feeds other agents or into any log that leaves your machine. 3. Separate the system prompt from the working context. The leak happened because authorization-shaped content sat in the same window the subagent could echo. Keep credentials and internal routing data out of the prompt that a stalled loop might surface. Put them in a side channel the model can call, not text it can print. The deeper lesson is about failure modes, not one bug. Most agent setups assume th

The feed showed a new entrant worth watching: Tencent has launched Hy3, a coding-focused AI model, with input tokens priced at $0.14 per million. For developers who live in the terminal running coding agents, that price point lands well below the per-token rates most frontier models charge, and it puts a major lab's coding model into the "cheap enough to leave running" category. What makes this interesting isn't just the number — it's the positioning. Hy3 is being pitched specifically as a coding AI, not a general chatbot, which suggests vendors are starting to carve out developer-facing models with their own pricing tiers rather than forcing coders to pay general-purpose rates. Developers spotted the launch in the daily AI news roundup and immediately started comparing it against the cost of running their existing agents. The catch, as always, is what the headline price doesn't tell you: output token cost, context-window limits, and how the model actually performs on real repository tasks all remain open questions. A low input price is meaningless if output is expensive or if the model needs five retries to get a diff right. Still, a credible cheap coding model from a major player is exactly the kind of pressure that nudges the whole category toward per-token transparency. If nothing else, it gives every other vendor a new number to justify theirs against.

Notes from bringing up a PCIe WiFi module on i.MX8MQ; symptoms and how to diagnose them. Phy link never came up — what does this mean? This message is typically seen in dmesg as shown below. [ 3.828121] imx6q-pcie 33800000.pcie: iATU: unroll T, 4 ob, 4 ib, align 64K, limit 4G [ 4.807241] imx6q-pcie 33c00000.pcie: Phy link never came up [ 4.841482] imx6q-pcie 33800000.pcie: Phy link never came up [ 5.821279] imx6q-pcie 33c00000.pcie: Phy link never came up [ 5.830481] imx6q-pcie 33c00000.pcie: PCI host bridge to bus 0001:00 [ 5.854997] imx6q-pcie 33800000.pcie: Phy link never came up [ 5.862205] imx6q-pcie 33800000.pcie: PCI host bridge to bus 0000:00 It means one of the following The PCIe peripheral is not powered up. PCIe reset is not deasserted, so the chip is in reset. This could be because the DTB is deasserting an incorrect GPIO. Reference clock is not enabled Using the incorrect PCIe controller in the device tree. As we can see that both the PCIe controllers can report this. So first determine which controller is the peripheral hooked to. More on this in the next section. Which PCIe controller is my device on? ( &pcie0 vs &pcie1 ) The rule here is to match by address and not by label/name. If the schematic calls out controllers as PCIE1 and PCIE2, and the device tree lists pcie0 and pcie1, understand the mapping. The DTS label is arbitrary - match by register base ( @address in the node name), which is the same in the DTS reg and the reference memory map. For definitive addresses look in the .dtsi , as sometimes the manuals are misleading. Given below is a mapping table for i.MX8MQ DTS. | ADDRESS (in .dtsi) | Silicon (RM) Label &pcie0 | 0x33800000 | PCIe1 &pcie1 | 0x33c00000 | PCIe2 The addresses are listed in the chip’s memory layout are from processor reference manual. Below is snapshot from the i.MX8MQ reference manual, where the layout for the core A-53 is listed. Start Address | End Address | Size | Description 3381_0000 | 3381_3FFF | 4MB | PCIe-2 << inco

Most of us treat design systems as a functional problem: consistent colors, consistent spacing, consistent components. That part's solved for most teams now. The part nobody writes down is tone. How should this loading state feel? Should this error feel scary or manageable? Is this confirmation message robotic or human? Here's what I've learned paying attention to that layer. Four moments that carry the emotional weight In any app, four states do most of the emotional work: Loading Error Empty Success Get these four right and the whole product feels better, even if nothing about the actual functionality changed. ** Loading: ambiguity feels worse than the wait itself** jsx // Vague, slightly anxious < Spinner /> // Specific, calmer < div className = "loading-state" > < Spinner /> < p > Fetching your latest data... </ p > </ div > A spinner with no context makes people wonder if something's frozen. A spinner with a short label tells them exactly what's happening. Same wait time, different feeling. Errors: same bug, different emotional outcome jsx // Robotic " Error: Request failed with status 500 " // Human " Something went wrong on our end. Your changes weren't lost, try again in a moment. " The second version does three things the first doesn't: it's plain language, it removes blame from the user, and it tells them what to do next. That's the difference between an error that frustrates and one that reassures. Success: robotic vs genuine jsx // Robotic " Action completed successfully. " // Human " Done! Your changes are saved. " This message shows up constantly across a typical app. If it reads like a system log every time, the product feels cold. A small rewrite makes it feel like a person is on the other end. Micro-interactions: timing is part of tone too `jsx// No feedback during the wait, feels broken <button onClick={handleSave}>Save</button> // Immediate feedback, feels responsive <button onClick={handleSave}> {isSaving ? "Saving..." : "Save"} </button>` A butt

I got tired of SSHing into the box every time I shipped something, just to watch the logs come up. So I wanted a page in the admin panel where the lines scroll past as they happen, no dashboard, no Grafana, just the raw tail. The surprising part was how little I had to build for it, most of the pieces were already sitting on the server waiting for me to connect them. Here's the whole idea. The app writes JSON to stdout, systemd grabs that stdout and drops every line into the journal, and journalctl can follow the journal and hand the lines back live. All three of those already exist on an Ubuntu box. So the "live log viewer" is really just me spawning journalctl on the server and piping its output to the browser over an EventSource , which is a lot less code than it sounds like. journald is boring and well understood. SSE is boring and well understood (it's been in browsers since about 2011). Nobody gets excited about either one on its own. But snap the two together and you get a real-time log tail with no agent, no log shipper, no vendor, and nothing new to keep alive. Two defaults meeting each other and pretending to be a feature. Systemd thing People have opinions about systemd. Some of them are that you should avoid every part of it that you can, run your own supervisor, ship logs somewhere with your own daemon, and treat journald as a thing to route around. That's a fine hobby if you have the time for it. I don't. The box boots, systemd starts my unit, and when the unit writes to stdout the line ends up in the journal without me configuring anything. Being a purist here costs real hours and buys me a philosophy. Being pragmatic costs nothing and buys me a log tail. So this is the pragmatic path. If you're on a distro where journald is the default (Ubuntu, Debian, Fedora, most of them now) the setup below is basically free. Getting logs into the journal Here is the part most people overcomplicate. You do not "set up journald". You do not open a socket to it or p

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is free and source-available on Github. Star git-lrc to help devs discover the project. Do give it a try and share your feedback. You've been using the terminal for months/ years. Maybe you cd into a folder, ls around, run your script, and call it a day. That's fine. That's like knowing how to boil water and calling yourself a chef. But the terminal has layers . It's basically an onion that occasionally makes you cry, usually around 12 AM when a script fails silently and you have no idea why. So grab your coffee and let's talk about the command line tricks that actually make your life better. Not the "did you know ls -la shows hidden files" tier tips. Your Terminal Has A Memory. Use It. Most devs mash the up arrow like it's 2007 and they're trying to beat a Flash game. Stop that. Press ctrl-r instead. It searches your command history live. Type a few letters, it finds the last matching command. Press ctrl-r again to cycle back further. Found it? Hit Enter to run it, or the right arrow to drop it into your prompt so you can edit it first. ctrl-r ( reverse-i-search ) ` docker run ` : docker run -it --rm -v $( pwd ) :/app node:20 bash Pair this with ctrl-w (delete last word) and ctrl-u (nuke the line back to the cursor) and you'll start editing commands like you're speedrunning a text adventure. And if you're the type who types a whole essay of a command and then realizes you forgot something at the start, ctrl-a jumps to the beginning of the line and ctrl-e jumps to the end. No more holding the left arrow key like it owes you money. Pro tip: if you're a TUI fan and ctrl-r's default search feels a bit flat, check out McFly xargs Is The Friend Who Actually Shows Up Pipes ( | ) are great. They pass output from one command into another. But sometimes you don't want to pass output as input , you want to pass it as arguments . That's where xargs comes in, and once you get it,

The Linux Foundation has launched Akrites, a new industry-wide initiative aimed at defending the world's most critical open source software against a rapidly evolving generation of AI-enabled cyber threats. By Craig Risi

Sparrow is Raku automation framework comes with useful plugins people can use to automate infrastructure. Scc plugin allows to check Linux essential configuration files for security compliance. Here some examples: Sysctl $ sudo sysctl -a | s6 --plg-run scc@check = sysctl 12:24:07 :: [task] - run plg scc@check=sysctl 12:24:07 :: [task] - run [scc], thing: scc@check=sysctl [task run: task.bash - scc] [task stdout] 12:24:08 :: abi.cp15_barrier = 1 12:24:08 :: abi.setend = 1 12:24:08 :: abi.swp = 0 12:24:08 :: abi.tagged_addr_disabled = 0 12:24:08 :: debug.exception-trace = 0 12:24:08 :: dev.cdrom.autoclose = 1 12:24:08 :: dev.cdrom.autoeject = 0 12:24:08 :: dev.cdrom.check_media = 0 12:24:08 :: dev.cdrom.debug = 0 12:24:08 :: dev.cdrom.info = CD-ROM information, Id: cdrom.c 3.20 2003/12/17 12:24:08 :: dev.cdrom.info = 12:24:08 :: dev.cdrom.info = drive name: 12:24:08 :: dev.cdrom.info = drive speed: 12:24:08 :: dev.cdrom.info = drive # of slots: 12:24:08 :: dev.cdrom.info = Can close tray: 12:24:08 :: dev.cdrom.info = Can open tray: 12:24:08 :: dev.cdrom.info = Can lock tray: 12:24:08 :: dev.cdrom.info = Can change speed: 12:24:08 :: dev.cdrom.info = Can select disk: 12:24:08 :: dev.cdrom.info = Can read multisession: 12:24:08 :: dev.cdrom.info = Can read MCN: 12:24:08 :: dev.cdrom.info = Reports media changed: 12:24:08 :: dev.cdrom.info = Can play audio: 12:24:08 :: dev.cdrom.info = Can write CD-R: 12:24:08 :: dev.cdrom.info = Can write CD-RW: 12:24:08 :: dev.cdrom.info = Can read DVD: 12:24:08 :: dev.cdrom.info = Can write DVD-R: 12:24:08 :: dev.cdrom.info = Can write DVD-RAM: 12:24:08 :: dev.cdrom.info = Can read MRW: 12:24:08 :: dev.cdrom.info = Can write MRW: 12:24:08 :: dev.cdrom.info = Can write RAM: 12:24:08 :: dev.cdrom.info = 12:24:08 :: dev.cdrom.info = 12:24:08 :: dev.cdrom.lock = 0 12:24:08 :: dev.raid.speed_limit_max = 200000 12:24:08 :: dev.raid.speed_limit_min = 1000 12:24:08 :: dev.scsi.logging_level = 68 12:24:08 :: dev.tty.ldisc_autoload = 1 12:24:08

Users judge a mobile app in the first few seconds, and they judge it harshly. A slow launch, stuttering scroll, or a device that runs hot will sink an otherwise good app faster than a missing feature. Performance isn't one metric — it's four distinct areas, each with its own causes and fixes. Here's how to keep all of them healthy. Startup time — the first impression Time from tap to usable screen is the metric users feel most. Every extra second measurably increases abandonment. The usual culprits are doing too much before the first frame: heavy synchronous work at launch, loading data you don't yet need, and oversized bundles. Fixes: Defer non-essential initialization until after the first screen renders Lazy-load features and screens instead of loading everything upfront Show a real first screen fast, then hydrate data — don't block on the network Trim your dependency footprint; every library adds to startup cost Rendering — kill the jank Smooth means hitting the device's frame budget (about 16ms per frame for 60fps). Dropped frames show up as stutter during scrolling and animation. The main causes are doing heavy work on the UI thread and rendering more than you need. Virtualize long lists so only visible rows render (FlatList, RecyclerView equivalents) Move expensive work off the main thread Avoid unnecessary re-renders — in React Native, memoize and keep render functions cheap Optimize images: right-sized, cached, and in efficient formats Memory — don't get killed The OS terminates apps that use too much memory, and users read that crash as your bug. Leaks and oversized assets are the main offenders. Watch for retained references, unbounded caches, and full-resolution images held in memory. Load and decode images at display size, release resources when screens unmount, and cap in-memory caches. Battery and network — the invisible costs Users blame the app that drains their battery even if they can't name why. The big drains are aggressive polling, chatty netwo

Abertura Eu sempre participei de comunidades de tecnologia: grupos de estudo do Google,...

Both vulnerabilities allow untrusted users to gain root privileges.

Lost an evening to this, so you don't have to. The fix everyone hands you is a single checkbox that quietly downgrades how your Mac stores its password. The clean alternative — Kerberos, the exact thing your iPhone already uses — is "impossible" according to three sources I dug up, one of them Apple's own Heimdal source. They're wrong. What follows is the whole path: why it breaks, why the popular fix is the bad one, and the two setups that actually work (a one-shot command and a hands-off automount). My Mac mini shares a folder over SMB. My iPhone mounts it fine. My Linux box: $ smbclient -L 192.168.0.153 -U tmlr%remote session setup failed: NT_STATUS_LOGON_FAILURE Same username, same password, rejected. Every "fix" on the internet ends with "turn on Windows File Sharing for that user on the Mac." That works, and it's the wrong answer. Here's why, and what to do instead. The problem The credentials are correct — the iPhone's connecting just fine. The handshake even completes; run it with -d3 and you'll see the full NTLMSSP exchange finish before the Mac rejects you. So this isn't networking, isn't the password, isn't the SMB dialect. It's authentication, and only Linux hits it. Why: two doors, one account macOS keeps several credentials for a local account, not one. Look: $ dscl . -read /Users/tmlr AuthenticationAuthority AuthenticationAuthority: ; ShadowHash ; HASHLIST:<SALTED-SHA512-PBKDF2,SRP-RFC5054-4096-SHA512-PBKDF2> ; Kerberosv5 ;; tmlr@LKDC:SHA1.XXXX ; LKDC:SHA1.XXXX ; Two things matter in there: HASHLIST is SALTED-SHA512-PBKDF2 (login) and an SRP verifier. There is no NT hash. There's a Kerberosv5 identity in a realm called LKDC:SHA1.<40 hex> . SMB auth has two doors into this account: NTLMv2 — validates against a stored NT hash. Linux smbclient and mount.cifs knock here. Kerberos — validates against the Mac's built-in Local KDC (LKDC), which every Mac runs. Apple clients knock here. Your iPhone walks through the Kerberos door and never touches the NT hash

I wanted to understand how malloc actually works under the hood. Most explanations I found online described what an allocator does, but completely skipped over the "why" behind its design decisions. Rather than stopping at theory, I decided to build a cross-platform allocator in C that implements malloc , calloc , realloc , and free from scratch. This article documents the design of that allocator, the architectural tradeoffs I faced, and the core concepts I had to learn along the way. Table Of Contents Design Decisions Architecture Modern Allocator Strategies Core Concepts What's Next Project Overview A custom memory allocator does not create physical memory. Instead, it requests pages of raw virtual memory from the operating system and manages how that memory is partitioned, reused, resized, and released by the application. The goal of this educational project is to implement C's core memory management API using a modular, cross-platform architecture inspired by design principles found in modern allocators, rather than relying on legacy, single-platform tricks. Design Decisions #1: Why I am Skipping sbrk While many classic tutorials use sbrk for educational implementations, I deliberately chose a 100% mmap -based approach for two major reasons: sbrk is a fragile global bottleneck. It works by moving a single pointer (the program break) up and down. This means the allocator assumes it owns a contiguous line of memory. If a third-party library or another thread in the program secretly calls sbrk behind the scenes, the allocator's memory layout can break instantly. mmap , by contrast, provides isolated, independent chunks of memory. Cross-Platform Symmetry. Windows has absolutely no equivalent to sbrk , but it has a direct equivalent to mmap : VirtualAlloc . If we used sbrk , our architectural abstraction ( os_alloc ) would become awkward because Linux would deal with a moving pointer while Windows dealt with independent pages. Using mmap keeps the abstraction perfec

If you've been monitoring Linux servers for any length of time, there's a good chance node_exporter was the first thing you installed. It's lightweight, reliable, and exposes a huge amount of machine metrics for Prometheus to scrape. For years, it has been the default answer. As your infrastructure grows, though, your monitoring stack usually grows with it. First comes log collection. Then traces. Before long you're running node_exporter , a log shipper, and maybe another telemetry agent. Each component has its own configuration, service unit, upgrade cycle, and failure modes. Grafana Alloy changes that by consolidating those responsibilities into a single telemetry agent. This post walks through migrating from node_exporter to Alloy on a real fleet, one server at a time, while maintaining continuous visibility throughout the process. These are the exact steps that survived contact with production on the Irin monitoring stack, not the idealized version that looks clean in a diagram. TL;DR If you're already running node_exporter , don't replace it overnight. Install Grafana Alloy alongside it, configure Alloy's built-in prometheus.exporter.unix component, verify that metrics are reaching your remote Prometheus instance, and only then retire node_exporter. Migrating one server at a time minimizes risk, preserves visibility, and positions your infrastructure for logs, traces, and future telemetry without deploying additional agents. The real difference is the direction of travel Before getting started, it's worth understanding what actually changes. This isn't simply replacing one monitoring agent with another. node_exporter is a server. It listens on a port, typically 9100,and waits for Prometheus to connect and scrape metrics. That means every monitored machine needs an open endpoint, network connectivity from Prometheus, firewall rules, and scrape configurations. Alloy flips that model around. Instead of waiting for Prometheus to connect, Alloy collects metrics loca

Installing Docker on Ubuntu should be simple, but in practice several Docker-shaped options compete for the same command name, each with different packaging, upgrade behavior, and security implications. This guide compares every major install path so you can pick the one that fits your machine. The options you will encounter include: docker.io from Ubuntu repositories docker-ce from Docker's official APT repository Docker from Snap Docker Desktop manually downloaded .deb packages the Docker convenience script rootless Docker Although they all provide container tooling, they are not interchangeable packages. The best choice depends on whether the machine is a developer workstation, a CI runner, a small server, a self-hosting box, or a production host. My default recommendation is calm but firm: for most technical users on normal Ubuntu machines, install Docker Engine from Docker's official APT repository. Use Ubuntu's docker.io only when distribution integration matters more than upstream Docker packaging. Avoid the Snap package unless you specifically want Snap behavior and understand its limits. Rootless Docker is worth knowing about, but it is not automatically the best default for every machine. This guide explains the tradeoffs, covers post-install security, and gives you clean installation paths for each method. Once Docker Engine is running, the Docker Cheatsheet is your daily command reference, and the Docker Compose Cheatsheet covers multi-container setups. Both sit alongside Git, VS Code, and CI/CD guides in Developer Tools: The Complete Guide to Modern Development Workflows . Quick Recommendation The table below summarizes which install path fits common scenarios. Use case Recommended install Developer workstation Docker official APT repo CI runner Docker official APT repo, version pinned if needed Small self-hosted server Docker official APT repo Production server Docker official APT repo, controlled upgrades Ubuntu-only conservative system Ubuntu docker.

Redpanda is a Kafka-API-compatible streaming platform written in C++ with no JVM and no ZooKeeper. This guide installs Redpanda on Ubuntu 24.04, secures it with a Let's Encrypt certificate and SASL/SCRAM authentication, tunes the kernel for production, verifies with a producer/consumer test, and exposes Redpanda Console behind Nginx basic auth. By the end, you'll have a secured, production-tuned single-node Redpanda cluster with a web console. Prerequisite: Ubuntu 24.04 server sized per Redpanda's CPU/memory requirements , non-root sudo user, and a domain A record (e.g. redpanda.example.com ). Install Redpanda $ sudo apt update $ curl -1sLf 'https://dl.redpanda.com/nzc4ZYQK3WRGd9sy/redpanda/cfg/setup/bash.deb.sh' | sudo -E bash Warning: Only run vendor setup scripts you trust — piped curl | sudo bash runs with root privileges. $ sudo apt install redpanda -y $ rpk --version Open the Firewall Port Service Purpose 9092 Kafka API Producer/consumer traffic 8082 Pandaproxy (HTTP) REST access for non-Kafka clients 8081 Schema Registry Avro/Protobuf schema versioning 9644 Admin API Monitoring, config, health checks 33145 Internal RPC Inter-node communication $ sudo ufw allow 9092,8082,8081,9644,33145/tcp $ sudo ufw allow 80/tcp $ sudo ufw allow 443/tcp $ sudo ufw reload Issue a Let's Encrypt Certificate Redpanda ships with plaintext networking by default, fine for a lab, not for anything else. $ sudo apt install certbot -y $ DOMAIN = redpanda.example.com $ EMAIL = admin@example.com $ sudo certbot certonly --standalone -d $DOMAIN --non-interactive --email $EMAIL Certbot stores certs under /etc/letsencrypt/live , readable only by root. Redpanda runs as its own redpanda user, so copy the certs into a dedicated directory: $ sudo mkdir /etc/redpanda/certs $ sudo cp /etc/letsencrypt/live/ $DOMAIN /fullchain.pem /etc/redpanda/certs/node.crt $ sudo cp /etc/letsencrypt/live/ $DOMAIN /privkey.pem /etc/redpanda/certs/node.key $ sudo cp /etc/letsencrypt/live/ $DOMAIN /chain.pem /etc/re

I love Nuxt and I really like TanStack Start. But which one is better? Or are they about the same? And if they are about the same, does it do anything my Nuxt setup can't, and is that worth leaving Vue for React? So I decided to build the same app in both frameworks and take a look. Read on below to find out! If you'd rather watch a video, check out the video on the same topic! The app In both frameworks I built a small GitHub user lookup app. You type a username, the profile gets fetched on the server, and the username lands in the URL as a ?user= query param so the result is shareable. Type ErikCH , hit enter, and the card renders. Refresh the page and it's still there. It has the same behaviour so the difference lies in the code. Difference one: server functions vs server routes On the Nuxt side we call a server route from useAsyncData . Server are the more idiomatic way to use Nuxt to call things on the server. <!-- app/pages/index.vue --> < script setup lang= "ts" > import { z } from ' zod ' import type { GithubUser } from ' ~~/server/api/github.get ' definePageMeta ({ props : route => z . object ({ user : z . string (). default ( '' ) }). parse ( route . query ), }) const props = defineProps < { user : string } > () const router = useRouter () const input = ref ( props . user ) const { data , error } = await useAsyncData ( ' github-user ' , () => props . user ? $fetch < GithubUser > ( ' /api/github ' , { query : { user : props . user } }) : Promise . resolve ( null ), { watch : [() => props . user ] }, ) function lookup () { router . push ({ query : { user : input . value . trim () } }) } </ script > The props option on definePageMeta maps the query into a typed page prop and re-runs on client navigation. useAsyncData fetches when there's a username and refetches whenever it changes. The conditional that returns Promise.resolve(null) skips the request on an empty query param, (or when you first load). The server route does the outbound call: // server/api/gith

Everyone knows Next.js is the default full-stack JavaScript framework in 2026. The job ads say so,...

Redux setup is a ceremony. You create a store, compose your reducers into a root tree, wrap your app in a Provider, register middleware, and configure enhancers — all before you write a single line of feature logic. SDuX Vault™ replaces that entire ceremony with two function calls and zero root configuration. Redux Store Ceremony A typical Redux application requires several files and configuration steps before state management is operational. Here is what a minimal Redux setup looks like for a single feature: // store.ts import { createStore , combineReducers , applyMiddleware } from ' redux ' ; import thunk from ' redux-thunk ' ; import { userReducer } from ' ./reducers/userReducer ' ; const rootReducer = combineReducers ({ users : userReducer , }); export const store = createStore ( rootReducer , applyMiddleware ( thunk ) ); // App.tsx — Provider wrapper required import { Provider } from ' react-redux ' ; import { store } from ' ./store ' ; function App () { return ( < Provider store = { store } > < UserList /> < /Provider > ); } That is 20+ lines of configuration across multiple files — and it only covers one feature. Add a second feature and you are back in the combineReducers file, composing another slice into the tree. Add middleware and you are threading enhancers through applyMiddleware . Add DevTools and you are composing composeWithDevTools on top. Every new feature touches the root configuration. Redux Requirement What It Does createStore() Creates the single global store instance combineReducers() Composes feature reducers into a root tree applyMiddleware() Registers middleware (thunk, saga, etc.) Provider Makes the store available to all components via context composeWithDevTools() Enables Redux DevTools integration ⚠️ Warning: Every entry in that table is root-level configuration. Adding a new feature means editing the root reducer composition, possibly the middleware stack, and potentially the Provider hierarchy. Root configuration is a shared depende