标签：#p

The free screen recorder that cannot upload your video Discussion | Link

submitted by /u/Either_Collection349 [link] [留言]

Handify ai Like many side projects, this one started because I had a simple problem to solve. I wanted a way to convert digital text into realistic handwritten notes without spending hours writing everything manually. Most existing tools I tried either looked too robotic or offered very little customization. So I decided to build my own. The Goal Instead of just changing a font, I wanted the output to actually feel handwritten. Some of the features I focused on were: 📝 Convert typed text into realistic handwriting 📄 Upload your own notebook or paper template ✍️ Multiple handwriting styles 🔀 Mix two handwriting fonts for a more natural appearance 🎲 Character variation so repeated letters don't always look identical 📥 Export high-quality PDFs ready for printing Challenges Making handwriting look "real" is much harder than simply rendering a handwriting font. Some of the biggest challenges were: Preventing repeated letters from looking identical. Keeping line spacing and word wrapping natural. Supporting different paper templates. Generating high-resolution PDFs without losing quality. Making the experience fast enough to generate pages within seconds. Small details make a surprisingly big difference when people compare AI-generated handwriting with actual handwriting. * Tech Stack * The project is built using: React TypeScript Firebase Vite Capacitor (Android App) Google Analytics What I Learned Building the product was only half the work. The harder challenge has been: SEO Google Search indexing Play Store optimization Improving conversion rates Understanding user behavior through analytics A great product doesn't automatically get users—you also need to make it discoverable. Current Progress The project is still growing, but it's already receiving organic traffic from Google and users have started using it for: Study notes College assignments Personal journals Printable handwritten documents Seeing people use something you built is incredibly motivating. I'd Love Yo

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry . Every developer has experienced that moment when a project works perfectly but doesn't feel perfect. That was exactly what happened while I was building my Gem Price Estimator , a web application designed to estimate gemstone values based on multiple characteristics and pricing rules. The calculations were accurate. The interface looked good. But something bothered me. It wasn't as responsive as I wanted it to be. That small delay was enough to make the application feel slower than it should, and I knew there had to be a better way. This wasn't about fixing a crash or a broken feature. It was about finding the hidden performance bottleneck. The Project The Gem Price Estimator analyses several gemstone properties and combines them to generate an estimated market value. The estimation process considers multiple factors, including: Carat weight Color Clarity Cut Other pricing adjustments Every user interaction triggered a complete recalculation of the estimated value. Initially, this approach worked well while the project was small. As the pricing logic became more sophisticated, however, the application started doing significantly more work than necessary. The First Sign Something Was Wrong Nothing was technically broken. There were no JavaScript errors. No failed requests. No database issues. The application simply felt slower every time users adjusted the estimator. Those tiny delays might seem insignificant individually, but together they reduced the smoothness of the overall experience. I wanted every adjustment to feel nearly instant. That became my goal. Investigating the Problem My first assumption was that the issue was caused by database operations. So I started checking: Database queries Network activity Browser Developer Tools Console logs Individual calculation steps Surprisingly... None of those were the real problem. The application wasn't waiting on the database. It wasn'

Most AI applications wait for the model to generate the complete answer before showing anything to the user. For short answers, that may be acceptable. For longer responses, it can make the application feel slow—even when the model is already generating tokens. Streaming solves this by displaying each part of the response as soon as it arrives. The non-streaming version A standard OpenAI-compatible request may look like this: import os from openai import OpenAI client = OpenAI ( api_key = os . environ [ " AI_API_KEY " ], base_url = os . environ [ " AI_BASE_URL " ], ) response = client . chat . completions . create ( model = os . environ [ " AI_MODEL " ], messages = [ { " role " : " user " , " content " : " Explain API gateways in three sentences. " , } ], ) print ( response . choices [ 0 ]. message . content ) This works, but nothing is printed until the complete response has arrived. Stream the response Enable streaming by adding stream=True : stream = client . chat . completions . create ( model = os . environ [ " AI_MODEL " ], messages = [ { " role " : " user " , " content " : " Explain API gateways in three sentences. " , } ], stream = True , ) The request now returns a sequence of chunks instead of one completed response. Loop through those chunks and print the available content: for chunk in stream : content = chunk . choices [ 0 ]. delta . content if content : print ( content , end = "" , flush = True ) print () The user can now see the answer while it is being generated. Complete example import os from openai import OpenAI client = OpenAI ( api_key = os . environ [ " AI_API_KEY " ], base_url = os . environ [ " AI_BASE_URL " ], ) stream = client . chat . completions . create ( model = os . environ [ " AI_MODEL " ], messages = [ { " role " : " user " , " content " : " Explain API gateways in three sentences. " , } ], stream = True , ) for chunk in stream : content = chunk . choices [ 0 ]. delta . content if content : print ( content , end = "" , flush = True )

Welcome back to the React Mastery Series ! In the previous article, we learned how React applications communicate with backend services using Fetch API and Axios , along with best practices like service layers, interceptors, and error handling. Today, we'll explore one of the most common features you'll build as a React developer: Forms in React Whether it's: User Login Registration Profile Update Payment Details Contact Forms Search Filters Forms are everywhere. Learning how to build performant, scalable, and validated forms is an essential skill for every React developer. Understanding Forms in React A form is a collection of input elements used to collect user data. Example: Login Form Email,Password and Login Button React provides multiple ways to manage form data. The two most common approaches are: Controlled Components Uncontrolled Components Controlled Components In a controlled component, React controls the input value through state. Example: import { useState } from " react " ; function Login () { const [ email , setEmail ] = useState ( "" ); return ( < input type = "email" value = { email } onChange = { ( e ) => setEmail ( e . target . value ) } /> ); } Flow: User Types ↓ onChange ↓ React State ↓ Input Updates The input value always comes from React state. Why Controlled Components? Benefits: Easy validation Easy formatting Predictable state Better debugging Example: if ( email . length < 5 ) { // Show validation message } Since the value is stored in state, validation becomes straightforward. Uncontrolled Components In uncontrolled components, the DOM manages the input value. React accesses it using a ref. Example: import { useRef } from " react " ; function Login () { const emailRef = useRef < HTMLInputElement > ( null ); function handleSubmit () { console . log ( emailRef . current ?. value ); } return ( <> < input ref = { emailRef } /> < button onClick = { handleSubmit } > Login </ button > </> ); } Use uncontrolled components when you don't need Reac

Git is the ultimate tool for developers. Yet, branching strategies still confuse many of us. Commands like merge, rebase, and cherry-pick manipulate your commit history in completely different ways. If you just guess what they do, you risk ruining your team's shared history or losing track of your changes. The easiest way to understand Git is to visualize it. Let us look at exactly what happens to your Git graph when you run these three critical commands. 🏗️ Starting Point: Our Example Repository Imagine we have a standard repository. We branched off the main branch from commit B to work on a new feature in a feature branch. While we worked on our feature, someone else pushed commit C and D to main. Here is what our history looks like right now: C --- D [main] / A --- B \ E --- F [feature] main has two new commits: C and D. feature has two new commits: E and F. 🔀 1. Git Merge (The Safe Record Keeper) When you merge main into your feature branch (or vice versa), Git creates a special, brand-new commit called a merge commit. git checkout feature git merge main The Visual Graph After Merge: C ------- D ------ [main] / \ A --- B \ \ v E --- F --- G [feature] What happened under the hood? Git looked at the common ancestor (B), took the history of main (C and D), took the history of feature (E and F), and combined them. Commit G is the merge commit. It has two parent commits: F and D. Pros: 100% non-destructive. It preserves the exact historical timeline of when things actually happened. Cons: Your Git graph can quickly become a messy "train track" web if you have many developers merging constantly. 🚀 2. Git Rebase (The Clean History Rewriter) Rebase takes all the commits from your current branch, lifts them up, and replants them on top of the very last commit of the target branch. git checkout feature git rebase main The Visual Graph After Rebase: C --- D [main] / \ A --- B E' --- F' [feature] What happened under the hood? Git temporarily blew away commits E and F. It ca

Building an AI agent locally is an exciting first step. Running that same agent reliably in production is a different challenge. Once real users and external services are involved, the application needs more than working code. It needs repeatable deployments, secure configuration, health checks, monitoring, controlled updates, and a clear recovery process. This article is part of my MCP series. If you are new to the topic, start with my first article: Model Context Protocol (MCP) Servers Explained: A Complete Beginner’s Guide . In this article, I will outline a practical architecture for taking a Model Context Protocol, or MCP-based, AI agent from a local development environment to Kubernetes. This is a production architecture blueprint. The exact implementation will depend on the AI provider, MCP servers, cloud platform, and security requirements used by the application. What Is an MCP-Based AI Agent? The Model Context Protocol provides a standardized way for AI applications to connect with external tools, services, and data sources. An MCP-based agent may interact with: Internal APIs Databases File systems Search services Monitoring platforms Business applications Custom automation tools A basic implementation might work well on a developer's machine. In production, however, every dependency introduces operational questions: How will the application be deployed? Where will credentials be stored? How will failed requests be detected? Can the service handle additional traffic? How can a broken release be rolled back? What happens when an MCP server becomes unavailable? These are familiar DevOps and Site Reliability Engineering problems applied to a new type of workload. Target Architecture A practical delivery flow could look like this: Developer ↓ GitHub Repository ↓ GitHub Actions ↓ Container Registry ↓ Kubernetes Cluster ↓ MCP Servers and External Services ↓ Logs, Metrics, Traces, and Alerts Each component has a clear responsibility: GitHub stores the application

A few weeks ago Boris Cherny, who leads development on Claude Code, mentioned during a talk at Acquired Unplugged that he doesn't really write prompts for Claude anymore. Instead he writes loops that keep prompting Claude until the work is actually done. The clip went viral on X, racked up nearly 700k views in under 24 hours, and Loop Engineering became the latest term making the rounds in AI development circles. The core idea is straightforward enough. Rather than obsessively tuning a single prompt to get a perfect output on the first try, you build an iterative system around the model: give it a clear goal, feed it the right context, give it tools to work with, evaluate what it produces, and define conditions for when it can stop. Wire those pieces together and the agent stops being a one-shot call and becomes something that iterates, self-corrects, and keeps working until the output actually meets your bar. The efficiency gains over prompt-tuning are real, and that is why the concept resonated so quickly. What struck us as we built and shipped the loop system for our own platform Octo is that almost all of the current conversation around Loop Engineering stays at the single-agent level. You have one model, one cleverly designed loop, one sandbox, and the agent grinds away iteratively until its output passes whatever checks you have set up. That solves a real problem: how one person works faster with AI. But real work, especially inside an organization, rarely fits cleanly inside a single agent loop. A product feature going from idea to shipped code needs someone defining requirements, someone designing the approach, someone writing the implementation, someone verifying quality, someone feeding back results. Those are not different iterations of the same loop. They are interconnected loops that need to pass context and outputs between each other. When loops need to share state, trigger each other, and respect organizational boundaries, single-agent loop design sto

Single agent capabilities have expanded pretty dramatically over the last year. Tool calling went from flaky function selection to reliable multi-step planning. Code generation moved from snippet completion to full module implementations. Desktop GUI control crossed from demo territory into OSWorld benchmark numbers that actually mean something, Mano CUA 1.1 hitting 58.2 percent on the specialized model track, about 13 points ahead of opencua 72b in second place, and WebRetriever NavEval at 41.7, edging past Gemini 2.5 Pro Computer Use at 40.9 and Claude 4.5 Computer Use at 31.3. Those numbers would have been hard to believe a year ago. But the ceiling on single agent systems is getting easier to see. Once a task needs more than one role operating in the same loop, problems stack up fast. A competitor analysis that needs parallel research across three sources before cross-referencing. Code that goes through independent security review after being written. Creative work where you want two independent drafts before picking one. People have tried shoving multiple role descriptions into a single system prompt and having the model switch hats, but in practice the attention bleed between roles is hard to contain. The agent doing the writing naturally overestimates its own output quality. The reviewer sharing the same context chain goes soft on issues it watched get created. We saw this repeatedly in early Mano AFK testing where coding and testing lived in the same agent context. Tests became ceremonial, obvious logic errors slipped through, and things only got better once we split the agents apart. Splitting work across multiple agents is not a new idea. It has been in papers for years. What changed is the cost structure. A year ago running three GPT 4 level instances on a multi-step task meant token bills that added up fast, especially on iterative dev work where the meter kept running across rounds of fixes. That equation looks different now. Small and on device models

At the end of the previous chapter, I teased that we were about to dive straight into the heavy machinery of DAO implementation - hooking up Spring Data JPA and Hibernate under the hood. If you look at our original roadmap, concrete implementation was supposed to be right here. But after laying down our domain models, data contracts, and reading some of your feedback, I realized that we need to address an unspoken architectural trap first: data mapping and transformation . Most teams blindly adopt automated tools - whether runtime reflection wrappers or compile-time generators like MapStruct - until an architectural mismatch or production incident breaks their service. Before we wire up our database infrastructure, let’s see why we chose to completely bypass mapping "magic" in favor of pure, explicit Java transformers. And yes, some will say that writing explicit transformers is boilerplate - why write it manually when we can just use an annotation? The answer is simple: we’re not building a simple CRUD application that gets thrown to a support team and forgotten. We’re building an enterprise-ready microservice, built for deployment in Kubernetes, integrated with Kafka, Redis, and multi-tenant authorization layers - a product designed to be actively developed and maintained over years, not weeks. This is where the real value shines: spending a little more time writing explicit transformers - as I call them, rather than standard Mappers. I call them transformers because they actively reshape data. A "mapping" usually implies just copying a field from ClassA to ClassB (whether with the same or a different name). We aren't doing that here because at an enterprise level, field names, types, and structural representations will diverge significantly between your database entities, domain models, and external DTOs. The Architectural Trap Across my 11 years in Enterprise Java, I've seen team after team reach for automated mappers to "save time." To understand why we banned

Animated SVG mascot studios for apps that need a personality Discussion | Link

One thing Microsoft is not good at is naming things, and sadly it's happened again. But let's go back to the beginning: what are Skills? Skills are targeted prompts/context that are modular, so they are not always included in the LLM session. They are Markdown files with selected metadata in YAML, all in a file normally named skill.md (the parent folder and YAML metadata identify it). They were created by Anthropic (Claude) and were designed for both the user to add in a prompt ( /Skill ), or for the LLM to decide. Similar to Skills are Plug-ins. These can (and often do) include skill.md files, but can also have scripts, MCP servers, and other tools. So back to Microsoft naming things badly. Copilot Studio (Azure Bot Framework version) had skills, but they were not skills. The new Copilot Studio has Skills, but they are not Skills, they are actually Plug-ins. Plug-ins include Skills, so why does it matter? Well, it doesn't really, but I like to moan, and it means sometimes cool functionality can be left on the table because we presume Microsoft names things accurately. Anyway I digress (I like to do that), now we understand what Skills/Plug-ins are I wanted to dive into them within Copilot Studio and cover: Why Are They Cool Building Powerful Skills Adding Scripts/Templates Using Skills 1. Why Are They Cool I often go on about skills being cool, but why? There are a few reasons. Context Management Before skills, the standard approach was to give the LLM everything and let it figure out what it needed. The problem with this is twofold. First, more context equals more tokens, which equals more cost. Second—and more importantly—too much unrelated context can have a detrimental impact on the LLM response. LLMs work by using input tokens to predict the next token, so polluted input tokens can make the LLM predict the wrong next token (this is a huge simplification, but you get what I mean). Transferable As skills are simple Markdown files, they can easily be transferred

Microsoft has released TypeScript 7.0, featuring a native compiler that improves build speeds by 8x to 12x. Notable performance enhancements were evidenced in real codebases. The version lacks a stable programmatic API, anticipated in 7.1. Transitioning includes a compatibility package for existing tooling, and TypeScript remains an open-source project. By Daniel Curtis

Turn your Mac into a spinning vinyl player. Discussion | Link

Embabel has reached its 1.0 release, providing a framework for AI agents on Java It allows Java and Kotlin developers to define agents as typed domain objects. Built on Spring AI, Embabel supports multiple model providers and combines planning with predefined state machines, offering flexibility for agent workflows. By Erik Costlow

Qwen’s most capable model for coding and cowork Discussion | Link

# suddo (superuser don't do) Sometimes AI needs to run commands with sudo (installing a package, reading a file in /etc, etc). But most MCP clients don't support creating a PTY, so you end up having to open a separate terminal just to type your password: claude code $ sudo cat /etc/hosts AI: blabla password: > ! sudo cat /etc/hosts AI: please open a new terminal. Annoying. With suddo: AI calls the tool `execute_command` The server asks you, rejects, or allows it based on your rules If allowed: If you don't have a valid sudo timestamp, it asks for your password The command runs safely More detail and usage: https://github.com/sunu15712/suddo

I often see people using the term "namespace" incorrectly. Even when explanations of what a namespace is are presented, they only go as far as describing its function, neglecting to properly define the name "namespace" itself. Definition of the Namespace A namespace is literally the space to which a name belongs . If we were to classify the term namespace, it would be a specification (concept), not a tool. In namespaces, the higher level is represented as outer and the lower level as inner . In terms of class structure, this corresponds to outer classes and inner classes. In other words, to explain it from a different perspective, it looks like this. Representation of namespaces from the outer perspective Build namespaces (best) Define namespaces (to fit many programming language implementations) Open namespaces (such as Ruby's class definition and module definition ) Create namespaces (such as the pseudo-namespace hack in older JavaScript) Declare namespaces (such as the package declaration in Java or the namespace declaration in PHP) Representation of namespaces from the inner perspective Belong to a namespace (best) Entering the namespace (This is entirely from an inner perspective, so it might feel out of place depending on the context) Be included in the namespace (this is a reasonable explanation if explained objectively). Incorrect expression From the definition above, it is clear that the following expressions are incorrect. Add/Paste a namespace (the expression "add/paste a space" is grammatically incorrect). Use namespaces (not to the point of being completely broken, but treating namespaces as a tool) Separate/Cut namespaces (While "Separated by namespaces" is understandable, "separate/cut" can be misleading) Meaning of "Name" in Namespace The "names" referred to here can be class names, module names, or package names. What they represent varies depending on the language that implements namespaces. For example, in Ruby, it refers to constant names. In Rub

The lost-update bug that quietly corrupts homegrown wallet balances — and the five disciplines we used across PayWithToken to make money movement correct under concurrency. There is a bug that lives in a large share of the world's homegrown wallet systems. It doesn't throw an error. It doesn't show up in tests. It surfaces months later as a balance that is quietly, inexplicably wrong — and in a payments system, a wrong balance is either a customer who has lost money or a company that has given it away. This is the story of that bug, why the "obvious" wallet code causes it, and the handful of disciplines we used across PayWithToken to make money movement correct under concurrency. The bug: lost updates Here is wallet code almost everyone writes first. Credit a user's balance: // DON'T do this $row = $db->query("SELECT balance FROM users WHERE id = $id")->fetch(); $new = $row['balance'] + $amount; $db->exec("UPDATE users SET balance = $new WHERE id = $id"); Read the balance, add to it in PHP, write it back. It works perfectly — until two things happen at the same time. Picture a wallet at ₦1,000. Two credits of ₦500 arrive simultaneously — say a bank webhook and the user tapping "confirm" on their phone: Request A reads balance = 1000. Request B reads balance = 1000 (A hasn't written yet). A computes 1500, writes 1500. B computes 1500, writes 1500. Two credits landed; the balance rose by ₦500. ₦500 vanished. This is a lost update, and it is a race condition, which means it is invisible until you have real concurrent traffic — exactly when you can least afford it. The debit version of the same bug lets a balance go negative or double-spends a token. Fix #1: let the database do the arithmetic The read-modify-write happened in PHP, across three round trips, with a gap where another request could interleave. The fix is to make the update a single atomic statement and let the database's row lock serialise it: // DO this — one atomic statement $db->prepare("UPDATE users SET