标签：#java

GitHub热门项目 | A high-performance, 100% client-side tool for removing Gemini AI image & video watermarks. Built with pure JavaScript using mathematically precise Reverse Alpha Blending. / 基于 JavaScript 的纯浏览器端 Gemini AI 图像和视频无损去水印工具，使用数学精确的反向 Alpha 混合算法 | Stars: 4,749 | 27 stars today | 语言: JavaScript

GitHub热门项目 | Sample Whatsapp App - Jasper's Market | Stars: 508 | 10 stars today | 语言: JavaScript

Introduction When learning JavaScript, one of the first concepts you’ll encounter is functions. Functions are the building blocks of JavaScript. They help you organize code, avoid repetition, and make your programs easier to understand. If variables store data, functions define behavior . You’ll use functions everywhere: handling user input, processing data, calling APIs, and structuring your code. In this article, we’ll cover: What is a function Function declarations Function expressions Parameters vs arguments Return values Arrow Functions Why Functions Matter 1. What is a Function? A function is a reusable block of code designed to perform a specific task. Think of it like a machine: Input → Process → Output function greet () { console . log ( " Hello! " ); } To run the function, you call it: greet (); // Hello! 2. Function Declaration This is the most common way to define a function: function add ( a , b ) { return a + b ; } 💡 Explanation: Defined using the function keyword Can be called before it is declared (because of hoisting) Key parts: function → keyword add → function name a, b → parameters return → output value add (); // ✅ Works! function add ( a , b ) { return a + b ; } 💡 Why does this work? JavaScript reads the code first, and function declarations are stored in memory during the initial phase (hoisting) . That’s why you can call the function even before it’s defined in the code. 3. Function Expressions Functions can also be stored in variables: function add ( a , b ) { return a + b ; } 💡 Explanation: Assigned to a variable Cannot be used before initialization add (); // ❌ Error: Cannot access before initialization const add = function ( a , b ) { return a + b ; }; 💡 Why does this cause an error? Because: const add has not been initialized yet when it is called. The function itself is not in memory at that moment . 4. Parameters vs Arguments This is a common beginner confusion: Parameter: variable in function definition Argument: actual value passed i

Software architecture debates have a problem that most other engineering disciplines don't: the alternative was never built. When a bridge fails, the failure is physical, attributable, and measurable against every other bridge that didn't. The engineering decisions that caused it can be isolated, traced, and corrected — not just in theory, but in the next bridge, because the material itself produces feedback that no amount of professional opinion can override. Steel deflects. Concrete cracks. Physics doesn't care what the architect believed. Software produces no equivalent feedback. A system built around the wrong abstractions compiles, runs, ships, and passes its tests just as readily as one built around the right ones. A bug introduced by a misaligned domain model looks identical, from the outside, to a bug introduced by a typo. A feature that took three times longer than it should have, because the structure made it harder than the business logic warranted, produces no artifact that distinguishes it from a feature that was simply difficult. The cost is real. The cause is invisible. This is the unfalsifiability problem, and it runs deeper than "we can't measure everything." It means that when a system becomes expensive to change, the diagnosis almost always lands on the wrong variable. The domain is complex. The requirements changed. The previous team was careless. Almost never: the structure was wrong, and the structure was wrong because nobody ever built the other version of it to compare against. That version doesn't exist, it never will, and every architectural argument in the industry is conducted in its absence. This would be a purely philosophical problem if there were nothing to do about it. There is something to do about it — but it requires accepting that the standard metric for software quality, whether it works, is measuring the wrong thing entirely. The Metric That Hides the Problem The natural substitute for "is this good engineering" is "does it wor

I built JSON Utility Kit as a small browser-based toolkit for everyday JSON tasks. The CSV to JSON converter recently got an update for nested JSON structures. For example, headers like user.name, user.email, order.id can be converted into nested objects instead of flat keys. What it supports: CSV to JSON conversion Nested object output from dot notation headers Browser-side processing No signup JSON formatting and validation tools nearby Tool: https://jsonutilitykit.com/tools/csv-to-json/ GitHub: https://github.com/kejie1/json_utility_kit

React Doctor es un linter de cero instalación que escanea un codebase de React buscando problemas de correctitud, seguridad, accesibilidad, rendimiento y mantenibilidad, luego los rankea y te entrega una lista de arreglos con forma de agente. Este post es un reporte de campo: lo corrí sobre una SPA real de React 18 + Vite + TypeScript (~50 rutas, TanStack Query, react-hook-form) y separé lo que de verdad me atrapó. El resultado honesto: 1,249 hallazgos, cinco que valía la pena arreglar, incluyendo dos bugs de seguridad reales. Los otros 1,244 fueron una mezcla de ruido, decisiones de criterio, y falsos positivos. TL;DR Categoría Reportados Vale la pena actuar Por qué la brecha Seguridad 18 warnings 2 13 eran sinks saneados en el servidor (falsos positivos); 1 mina de código muerto + 1 XSS real fueron el oro Bugs 24 errores, 487 warnings 2 1 fuga de timer, 1 key/spread; ~27 exhaustive-deps piden criterio humano Accesibilidad 434 warnings, 1 error 1 el 1 error ( aria-selected faltante) era real; los 434 son ruido de <Label> / <button type> Rendimiento 110 warnings 0 nada caliente; candidatos pero sin impacto medido Mantenibilidad 176 warnings 0 opiniones de estilo tipo "componente grande" Total 1,249 5 señal-a-ruido ≈ 1 en 250 El puntaje que imprimió: 39 / 100 . Dos cosas que ese encuadre esconde: los cinco que sacó a la superficie eran de alto valor (una fuga de token en localStorage y un sink de XSS almacenado), y el conteo no es determinista : una segunda corrida del mismo commit reportó 1,254, no 1,249. El veredicto en una línea: excelente generador de hipótesis, pésima compuerta. Úsalo para encontrar candidatos, verifica cada uno contra el código, y nunca conectes el conteo al CI. Qué es React Doctor Un solo binario que corres por npx / pnpm dlx , sin agregar dependencia a tu proyecto, sin archivo de configuración obligatorio. Parsea tu src/ , hace match contra un conjunto de reglas (sus familias: Seguridad, Bugs, Accesibilidad, Rendimiento, Mantenibilidad), e im

Everything worked. I'd wired up useOptimistic on a task list, the checkbox flipped the instant you...

I rebuilt aesencryption.net so text AES (128/192/256) runs fully in the browser - the key and plaintext never leave the page. The hard part is staying byte-compatible with common server-side AES libraries (mode, IV, padding, base64 output), so I ship copy-paste equivalents in PHP, Java, Python, Go, Rust, Kotlin and JS. Live tool (mine, free): https://aesencryption.net - feedback on the crypto choices welcome. My own site.

GitHub热门项目 | All parts of Claude Code's system prompt, 27 builtin tool descriptions, sub agent prompts (Plan/Explore/Task), utility prompts (CLAUDE.md, compact, statusline, magic docs, WebFetch, Bash cmd, security review, agent creation). Updated for each Claude Code version. | Stars: 11,638 | 28 stars today | 语言: JavaScript

GitHub热门项目 | 🦸 AI 编程超能力 · 中文增强版 — superpowers（116k+ ⭐）完整汉化 + 6 个中国原创 skills，让 Claude Code / Copilot CLI / Hermes Agent / Cursor / Windsurf / Kiro / Gemini CLI 等 16 款 AI 编程工具真正会干活 | Stars: 6,504 | 66 stars today | 语言: JavaScript

Like most developers, I have a handful of small utilities I reach for every day — formatting JSON, decoding a JWT, generating a UUID, testing a regex. For years I just googled "json formatter" and pasted my data into whatever site came up first. Then one day I caught myself pasting a production JWT into a random online parser that POSTs everything to its server. That felt bad. So I built my own toolbox that never sends data anywhere. It's called WeTool — free, no login, and every tool runs 100% in your browser . You can open DevTools → Network and confirm there are zero requests while you use it. Here are the 15 I use most: Everyday JSON formatter / validator URL encode / decode Base64 encode / decode Timestamp ↔ date converter Security & encoding Hash calculator (MD5 / SHA) JWT parser UUID generator QR code generator Text & format Regex tester Text diff Markdown preview SQL formatter Debugging Cron expression parser Color converter User-agent parser Two things that matter to me and might to you: Nothing is uploaded. No backend, no login, no tracking of what you type. Local-only. 15 languages. Most tool boxes are English-only; this one isn't. It's free and I'm actively adding tools — if something you use daily is missing, tell me in the comments and I'll add it. 👉 wetool.site

The first question I ask when reviewing a frontend architecture is: where does the state live relative to where it is used? In most codebases I have reviewed, the answer is "in a global store, regardless of scope." This is the wrong default. The rule State should live as close to its consumers as possible. If only one component needs it, it is component state. If a subtree needs it, it is a context or service scoped to that subtree. Global state is for truly global concerns: authentication, locale, theme.

Most async code in frontend apps has a hidden bug: it doesn't stop when it should. A user navigates away mid-request. A component unmounts. A newer search query supersedes the previous one. The old network call keeps running, eventually resolves, and tries to update state that no longer exists. In React, that's the infamous warning: "Can't perform a React state update on an unmounted component." In vanilla JS, it silently delivers stale data. AbortController is the browser's built-in solution. It's been in every major browser since 2018 — old enough that there's no excuse not to use it. But most tutorials skip it, most codebases use it inconsistently, and most devs reach for it only after they've debugged a flicker one too many times. Here's the pattern, end to end. The race condition you already have function SearchResults ({ query }: { query : string }) { const [ results , setResults ] = useState < Result [] > ([]); useEffect (() => { fetch ( `/api/search?q= ${ query } ` ) . then ( r => r . json ()) . then ( data => setResults ( data )); // runs even if query changed }, [ query ]); return < ul > { results . map ( r => < li key = { r . id } > { r . name } </ li >) } </ ul >; } When the user types "re" and then "rea" before the first request finishes, two fetches are in flight simultaneously. The request for "re" might complete after the request for "rea" — and when it does, setResults silently overwrites the correct result with the stale one. The component shows the wrong data. No error, no warning, no clue. This is a race condition, not a hypothetical. It happens on slow networks, during fast typing, on underpowered devices, and in staging environments right before a demo. AbortController: the three-line fix An AbortController is a pair: a controller object and a signal. You pass the signal into any abort-aware API; you call abort() to cancel it. useEffect (() => { const controller = new AbortController (); fetch ( `/api/search?q= ${ query } ` , { signal : control

Node.js 26 has been released, featuring the Temporal API enabled by default, an updated V8 engine to version 14.6, and the Undici HTTP client upgraded to 8.0. The release also removes deprecated legacy APIs. Developers should note migration points related to NODE_MODULE_VERSION changes. Node.js 26 is current for six months before entering long-term support. By Daniel Curtis

This week's Java roundup for June 29th, 2026, features news highlighting: a new JEP candidate, Strict Field Initialization; point releases of GraalVM, JReleaser, RefactorFirst and Java Operator SDK; maintenance releases of GlassFish and Micronaut; the second milestone release of Grails 8.0; and the beta release of Open Liberty 26.0.0.7. By Michael Redlich

In JavaScript and TypeScript, object references are often treated as disposable. An object is created, assigned to a variable, passed around, replaced, copied, spread, cloned, and eventually discarded. That is normal language behavior, but in larger mutable systems it creates a specific class of bugs: stale aliases. A stale alias appears when one part of the program still holds a reference to an old object while another part has already replaced that object with a new one. The old reference is still valid JavaScript, but it no longer points to current data. Hard Object References is a discipline for avoiding that class of bugs. The idea is simple: Object and array references should be stable. Do not replace them as a normal update mechanism. Copy data into existing objects instead. This rule is useful for application state, but it is not limited to global stores. It applies to ordinary variables, local component state, nested fields, arrays, drafts, snapshots, runtime models, and temporary objects. The broader principle is: Replace primitive values. Do not replace object and array references. The First Rule: const for Objects and Arrays The first level is variable bindings. If a variable holds an object or array, it should normally be declared with const : const user = { /* ... */ }; const items = [ /* ... */ ]; not: let user = { /* ... */ }; let items = [ /* ... */ ]; The point is not that the object becomes immutable. It does not. This is still possible: user . name = ' Alex ' ; items . push ( nextItem ); The point is that the variable should not be rebound to a different object: user = nextUser ; items = nextItems ; That replacement changes which object the variable points to. Any other code that still holds the old reference now points to obsolete data. So the first rule is: Use const for object and array references. Mutate or copy data into the object. Do not rebind the reference. This rule also applies to temporary objects. A temporary object may be short-live

In my previous articles, I’ve consistently emphasized a core architectural principle: once the render layer no longer dictates the entire data flow, the boundaries between State, Derived State, and Effects become critical. When we fall into the habit of stuffing every UI-affecting variable into generic "state," the system quickly loses its semantic structure. In modern frontend applications, this architectural gap becomes most glaring when dealing with asynchronous work. Async data is never merely "a value that will appear in the future." It carries complex semantics regarding its source, temporal validity, cancellation, error recovery, and invalidation. If these semantics aren't modeled explicitly, they inevitably get pushed down into the UI framework’s lifecycle—indirectly patched together through component mounts, effect dependencies, and callback guards. This brings us to the core question of this article: What does a system lose when the correctness of async work is forced to depend on the UI lifecycle? We are all incredibly familiar with this pattern: const data = await fetchSomething () setState ( data ) Or, using a standard UI framework hook: useEffect (() => { let cancelled = false fetchSomething (). then ( result => { if ( ! cancelled ) { setData ( result ) } }) return () => { cancelled = true } }, []) There is nothing inherently wrong with this code for simple use cases. It’s intuitive and perfectly aligns with how Promises are designed to work: trigger the operation, wait for the resolution, and write the result back into state. However, this mental model has a subtle downside. It encourages us to think of async work as simply calling setState after a Promise resolves. That may hold up for simple screens, but as an application grows, the model starts to expose structural problems. Promise Only Describes Completion, Not Ownership A Promise solves a very specific problem: A piece of work will complete in the future, and it will either succeed or fail. It c

📦 Code: github.com/USER/hls-multi-audio - replace before publishing TL;DR We'll add a working language picker to an HLS player. The hard part isn't the dropdown, it's the manifest. We'll author alternate audio with EXT-X-MEDIA audio groups, package it correctly, debug the classic "zero audio tracks" bug, and wire a switcher on hls.js v1.7 . Adaptive video, captions, the whole pipeline already works. Now someone wants an English/Spanish audio toggle. In HLS, "which audio can the viewer pick" is decided at packaging time and written into the master playlist. The player just displays it. Let's build it in that order. 1. Understand the structure (audio groups) HLS decouples video variants from audio renditions: Each audio rendition is an #EXT-X-MEDIA:TYPE=AUDIO entry pointing at its own media playlist. Renditions are bundled into a named audio group via GROUP-ID . Each video variant ( #EXT-X-STREAM-INF ) references a group with AUDIO="..." . A correct master playlist: #EXTM3U #EXT-X-VERSION:6 #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aud",NAME="English",LANGUAGE="en",DEFAULT=YES,AUTOSELECT=YES,CHANNELS="2",URI="audio/en.m3u8" #EXT-X-MEDIA:TYPE=AUDIO,GROUP-ID="aud",NAME="Espanol",LANGUAGE="es",DEFAULT=NO,AUTOSELECT=YES,CHANNELS="2",URI="audio/es.m3u8" #EXT-X-STREAM-INF:BANDWIDTH=2128000,CODECS="avc1.640028,mp4a.40.2",AUDIO="aud" video/720p.m3u8 #EXT-X-STREAM-INF:BANDWIDTH=1128000,CODECS="avc1.640020,mp4a.40.2",AUDIO="aud" video/480p.m3u8 Every attribute earns its place: LANGUAGE - BCP-47 code, used for the label. DEFAULT - plays when the viewer has no preference. AUTOSELECT - may be auto-picked from the OS language. CHANNELS - needed so the player can reason about stereo vs surround. BANDWIDTH on each video variant must include the audio group's bitrate , or your ABR logic works from a wrong total. 2. Author the renditions with FFmpeg Extract/encode each language's audio, then package. First, encode video-only and audio-only renditions: # video only (no audio), two ladder rungs

In the first article of this series, we saw how a custom build-time compiler can transform a legacy Angular.js template into raw, optimized JavaScript. To recap, starting from this template: <!-- simple.html --> <p> Hello {{ name }}! </p> Our Go compiler generates the following JavaScript module: // simple.js export function template () { const p_0 = document . createElement ( " p " ); const text_1 = document . createTextNode ( "" ); p_0 . append ( text_1 ); return { mount ( container ) { container . append ( p_0 ); }, update ( change ) { if ( " name " in change ) { text_1 . data = " Hello " + change . name + " ! " ; } } } } This is incredibly clean. By running template() , we get an object with mount and update methods. Using mount is fully intuitive: we pass a reference to a DOM element, and it injects our empty paragraph ( p_0 ) into it: import { template } from ' ./simple.js ' ; const { mount , update } = template (); const container = document . getElementById ( ' view-container ' ); mount ( container ); // The DOM now contains: <p></p> (waiting for data) However, the paragraph remains empty until we call update with a change object like this: let changes = { name : " Mario " , }; update ( changes ); // The DOM surgically updates to: <p>Hello Mario!</p> But who is responsible for tracking changes in our application state, building this changes object, and calling update ? The answer lies in marrying the legacy Angular.js $scope with the modern JavaScript Proxy API . The Legacy State Pattern In a traditional Angular.js application, developers mutate the state directly inside a controller by assigning properties to the $scope object: // simple-controller.js export function SimpleController ( $scope ) { $scope . name = " Mario " ; } To bridge the gap between this legacy controller and our new build-time template, we need a way to automatically capture the assignment $scope.name = "Mario" and translate it into a structured update: let changes = { name : " Mario " }

Introduction Every post in this series has quietly touched a piece of the same problem. Building Agentic Workflows in Java said toolUse.input() is untrusted and must be validated before it reaches your code. Building Reliable LLM Applications in Java said the model will confidently invent facts, so ground it and get typed output instead of parsing prose. Neither post named the thing underneath both statements: anything that crosses from outside your code into the model, or from the model back into your code, is untrusted input — a request body from the network, not a trusted internal value. This post names that boundary directly and gathers the defenses in one place — prompt injection (direct and indirect), input validation, output validation, and PII redaction — with the SAFE pattern shown beside every unsafe one it replaces, since this is the security-forward capstone of the series. The Trust Boundary: Three Kinds of Untrusted Input An LLM application has three places where untrusted text enters: User input — anything a person types, uploads, or submits through an API. Retrieved content — Making RAG Accurate in Java built a pipeline that ranks and returns chunks from a document store; those chunks were written by whoever authored the source document, not by you, and a malicious or compromised document can carry text aimed at the model reading it, not at a human reader. Model output — untrusted the moment it's about to be used rather than displayed : passed to a tool, interpolated into a query, or fed into another LLM call as context. A model that just read attacker-controlled retrieved text can be manipulated into producing attacker-controlled output. The single rule under all three: text is data until your code has explicitly decided it's safe to use for anything more than display. Nothing below is executed against a live API — every snippet is illustrative, and none of it uses a real key or a real record. Direct Prompt Injection: Defending the System Prompt A di