标签：#java

Scaling Kafka Consumers in Spring Boot: How We Cut Lag and Saved Latency When scaling high-throughput event-driven microservices in fintech, default Spring Kafka consumer configurations often run into throughput limits under peak loads. Here is the exact production setup we engineered to resolve consumer lag and reduce API processing latency by 35%. 1. Concurrency Tuning Over Single-Threaded Listeners By default, @KafkaListener operates with concurrency = 1. When a partition receives high message volume, processing gets backlogged. @Configuration @EnableKafka public class KafkaConsumerConfig { @Bean public ConcurrentKafkaListenerContainerFactory < String , PaymentEvent > kafkaListenerContainerFactory ( ConsumerFactory < String , PaymentEvent > consumerFactory ) { ConcurrentKafkaListenerContainerFactory < String , PaymentEvent > factory = new ConcurrentKafkaListenerContainerFactory <>(); factory . setConsumerFactory ( consumerFactory ); factory . setConcurrency ( 6 ); // Matches number of partition splits factory . getContainerProperties (). setAckMode ( ContainerProperties . AckMode . MANUAL_IMMEDIATE ); return factory ; } } 2. Explicit Batch Processing and Idempotency Instead of committing offset per message, processing batches with manual acknowledgments ensures atomic handling: @Service public class PaymentEventConsumer { @KafkaListener ( topics = "payment.settlement.v1" , containerFactory = "kafkaListenerContainerFactory" ) public void consume ( ConsumerRecord < String , PaymentEvent > record , Acknowledgment ack ) { try { processPayment ( record . value ()); ack . acknowledge (); } catch ( Exception ex ) { log . error ( "Failed processing record key: {}" , record . key (), ex ); // Route to Dead Letter Queue (DLQ) handleDeadLetter ( record ); ack . acknowledge (); } } } 3. Key Takeaway Scaling Kafka consumer pipelines requires matching topic partition count with container concurrency, tuning database connection pools and implementing dead letter queues for fail

Domain-Driven Design for Microservices: Building Scalable Systems with Clear Domain Boundaries Introduction Domain-Driven Design (DDD) isn't just another architecture pattern—it's a philosophy that aligns technical decisions with business reality. When building microservices at scale, DDD becomes essential. Without it, you end up with services that don't respect business domains, unclear responsibilities, and integration nightmares. Why DDD Matters for Microservices Microservices force you to make decisions about boundaries. The question isn't whether you'll decompose your system—it's whether you'll do it thoughtfully using DDD principles, or accidentally create distributed monoliths. DDD answers three critical questions: Where should a service boundary exist? (Bounded Contexts) How do we communicate across services without coupling? (Domain Events, Anti-Corruption Layers) How do distributed teams understand the same problem? (Ubiquitous Language) Core Concept 1: Bounded Contexts A Bounded Context is a boundary within which a domain model is applicable. Each microservice should typically map to one or more Bounded Contexts. Java Example: E-commerce System // Ordering Context - Bounded Context 1 public class Order { private String orderId ; private List < OrderLineItem > lineItems ; private OrderStatus status ; // PENDING, CONFIRMED, SHIPPED, DELIVERED private LocalDateTime createdAt ; public void confirmOrder () { if ( this . status != OrderStatus . PENDING ) { throw new InvalidOrderStatusException ( "Cannot confirm non-pending order" ); } this . status = OrderStatus . CONFIRMED ; } } // Inventory Context - Bounded Context 2 public class InventoryItem { private String skuId ; private Integer availableQuantity ; private Integer reservedQuantity ; public void reserveStock ( Integer quantity ) { if ( availableQuantity < quantity ) { throw new InsufficientStockException ( "Not enough stock to reserve" ); } this . reservedQuantity += quantity ; this . availableQuantity -

Three parts into this series, and if you'd asked me to define the word sitting underneath every...

In this post I'll show how to merge PDF files entirely in the browser using PDF.js and pdf-lib — no server, no file upload, no backend. Everything runs on the user's machine, which is great for privacy and for keeping hosting costs at zero (it's just a static site). Why process PDFs on the client? Most "free" PDF websites quietly upload your documents to their server, which: Exposes private/sensitive files to third parties Imposes size limits Often slaps a watermark on the output Requires you to trust their storage If you handle PDFs with client-side JavaScript (WebAssembly / WASM + PDF.js), none of that happens. The user's file never leaves their device, and you don't need a backend at all — so it's cheap and private. Caveats pdf-lib works well with standard PDFs; heavily encrypted or unusual documents may need extra handling. Very large PDFs are memory-hungry since everything is client-side, but for typical documents it's fast and free. Some complex PDFs with unusual fonts can lose fidelity — test on your own files first. Try it I packaged this approach (plus split, compress, rotate, unlock, image-to-PDF) into a free no-upload tool: https://yourutilityhub.com/pdf/merge-pdf The whole project is open source: https://github.com/Jalal-khn/utilityhub- If you have questions about the architecture or want a deeper dive on any part, ask away. The basic idea Read the input file with FileReader Parse it with pdf-lib (a pure-JS PDF library) Copy the source pages into a new document Save the merged PDF and trigger a download Here's the core function: js import { PDFDocument } from "pdf-lib"; async function mergePdfs(files) { const merged = await PDFDocument.create(); for (const file of files) { const bytes = await file.arrayBuffer(); const src = await PDFDocument.load(bytes, { ignoreEncryption: true }); const pages = await merged.copyPages(src, src.getPageIndices()); pages.forEach((page) => merged.addPage(page)); } const out = await merged.save(); return new Blob([out], { typ

GitHub热门项目 | | Stars: 317 | 27 stars today | 语言: JavaScript

Our tool transcribes audio in the browser — Whisper running locally via transformers.js , no upload. It worked fine, until analytics showed something too clean to be a coincidence: .mov uploads on mobile failed 100% of the time. Not 90%. Every single one. Desktop had never reported a single .mov failure. This is what I found, and how it got fixed without pulling in ffmpeg.wasm or WebCodecs. The 30-second reproduction I took one AAC audio track and put it in two containers — same encoder, same bytes for the audio itself, only the wrapper differs: const buf = await file . arrayBuffer (); await new AudioContext (). decodeAudioData ( buf ); On an iPhone 17 Pro simulator (iOS 18.7 / Safari 26.5): File iOS Safari Chromium sample.mov (ftyp qt ) EncodingError: Decoding failed OK sample.mp4 (ftyp isom ) OK OK So it isn't the codec. It's the container. The obvious fix that doesn't work First instinct: it's the brand in the ftyp box. Patch qt → isom , four bytes, done. It still fails. I'm writing this down so nobody else burns an afternoon on it. The ftyp brand is not what Safari looks at. The difference lives inside moov . The actual root cause Dig down to moov → trak → mdia → minf → stbl → stsd — the sample description that tells the decoder how the audio is encoded. Both files carry an mp4a entry. They are not the same mp4a entry: QuickTime writes: MP4 expects: version = 1 <— version = 0 compressionID = -2 (fffe) <— compressionID = 0 + 16 bytes of v1 extension <— (absent) esds wrapped in a 'wave' box <— esds is a direct child extra 'chan' channel layout (absent) iOS Safari's decodeAudioData only accepts a version 0 audio sample entry. Chromium accepts both — which is exactly why desktop never saw this and mobile never survived it. That version field is a uint16 . Two bytes decide whether the file plays. The fix: rebuild the container, don't touch the codec Since the audio bitstream is already valid AAC, nothing needs to be re-encoded. The job is pure byte plumbing: extract

Hi everyone! 👋 I just published v1.0.0 of my very first web project: an installable Progressive Web App (PWA) built from scratch using HTML, CSS, and Vanilla JavaScript. I designed it to be extra accessible and versatile, especially for older adults, shopkeepers, students, and everyday users. ✨ Key Features Multiple Modes: Standard, Scientific, Sales, Interest (Simple & Compound), Unit Conversions, BMI, Age, and Adjustable Percentage. Customization: Adjustable button sizes and custom background themes (including Dark and Light modes). Offline PWA Support: Service worker caching allows full offline functionality and direct installation on mobile or desktop devices. 🔗 Try It Out & Explore Code 🚀 Live Demo: mdalif027-tech.github.io/easy-calculator 💻 GitHub Repository: github.com/mdalif027-tech/easy-calculator 💬 Looking for Feedback Since this is my first app, I would really appreciate any thoughts on: Mobile touch layout and responsiveness across screen sizes. UI/UX design or theme improvements. Recommendations for features to add in future releases. Thank you so much for checking it out!

Dirk Lemmerman has released FlexGanttFX as an open-source resource-scheduling framework under the AGPL license. This JavaFX library enables Gantt chart creation for various industries, optimizing performance with a Canvas rendering method. The framework includes features for task dependency modeling and direct editing, accommodating diverse project planning needs. By Erik Costlow

I'm a backend engineer mainly working on game servers, with Java as my primary language. Over the years, I've spent a lot of time building and debugging backend systems, and recently I've been digging deeper into concurrency, I/O, logging, and performance. Working on game servers has taught me that many problems look simple at first, but become surprisingly complicated once the system gets busy. I'll be sharing some of the things I've learned from real-world systems, including experiments, benchmarks, design decisions, and a few open-source projects I'm working on. Glad to be here. Looking forward to learning from everyone on DEV!

Sometimes software development reaches a point where the tools designed to make your job easier start becoming part of the job. I ran into that with browser debugging. I wanted something that should have been simple: Set a breakpoint. Press F5. Debug my JavaScript. Instead, I found myself spending too much time thinking about development servers, browser launch configuration, debugger connections, ports, profiles, and the debugging environment itself. That led to a simple question: What if browser debugging could go back to convention over configuration? So I built CloudIDEaaS JavaScript Debugger . ⚡ The Goal: Press F5 and Debug The philosophy behind CloudIDEaaS is straightforward: Spend your time debugging your application instead of debugging your debugging environment. For a straightforward JavaScript or HTML project, I wanted the workflow to look like this: Set a breakpoint. Press F5 . Start debugging. Behind those three steps, CloudIDEaaS can start the local web server, launch Chrome, establish the debugging connection, configure your breakpoints, and then load the application. The important part is that you don't have to think about most of that. 🔴 Real Debugging Inside VS Code This isn't intended to replace Chrome DevTools or compete feature-for-feature with every large JavaScript debugging platform. It's focused on providing the debugging features I use most often directly inside Visual Studio Code: 🔴 Source and conditional breakpoints 👣 Step over, step into, and step out ▶️ Continue and pause 🔍 Local variables and object inspection 📚 Scopes and call stacks 🧮 Expression evaluation ⚠️ Exception breakpoint configuration 🌐 A built-in local web server One feature that was particularly important to me was startup breakpoints . The debugger establishes the connection and configures your breakpoints before loading the application, making it possible to catch JavaScript that executes during startup. 🧠 What's Actually Happening Under the Hood? Building the debugger a

1. Fundamental Base: The Problem and the Theory 1.1 Introduction The Adapter Pattern (also widely known by its alias, Wrapper ) belongs to the Structural Design Patterns category. Structural patterns deal with object composition, establishing clean relationships and interfaces across disparate classes to form larger, flexible structures without introducing tight coupling. According to the canonical definition by the Gang of Four (GoF): "Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces." (Gamma et al., 1994). In enterprise Java ecosystems, the Adapter pattern serves as an indispensable architectural bridge whenever we need to integrate legacy components, proprietary third-party SDKs, or external services whose contracts diverge from our core domain model. 1.2 The Problem: Architectural Friction with Incompatible Interfaces In day-to-day software engineering, teams frequently encounter highly stable, battle-tested utilities, mainframe integrations, or third-party libraries whose public interfaces do not match the domain interface required by the consuming system. When this structural friction occurs, developers often face three problematic alternatives: Modifying the existing class/service ( Adaptee ): Often impossible when consuming compiled third-party JARs or closed-source code. Even if the source code is available, forcing low-level infrastructure or external utilities to adopt domain-specific contracts violates the Single Responsibility Principle (SRP). Polluting the client code: Littering domain services with primitive type conversions, legacy status parsing, and foreign dependencies introduces tight coupling and tech debt. Rewriting the component from scratch: Incurs massive engineering costs, delivery delays, and high regression risks in critical, already-validated business logic. The core problem the Adapter pattern solves is: how can we enable

If you've done LeetCode's Design HashMap , you've implemented put , get , and remove . What that exercise usually skips is the part that actually breaks in production: what happens when someone mutates the map while another piece of code is iterating over it. I ran into this directly while building MyHashMap , a from-scratch single-threaded HashMap (separate chaining, resize on load factor). Getting put / get / remove right was the easy 80%. Getting entrySet().iterator() to correctly detect concurrent mutation — including the case where a second, completely separate iterator is the one that should notice — took three wrong turns before landing on the pattern the JDK actually uses. The problem, concretely Iterator < Entry < K , V >> it = map . entrySet (). iterator (); it . next (); map . put ( someNewKey , someValue ); // structural change, mid-iteration it . next (); // ??? — undefined behavior if we don't guard against this Without a guard, next() might return a stale entry, skip entries entirely, or throw an unrelated exception depending on internal bucket-array state. Java's real collections handle this with ConcurrentModificationException (CME) — but the interesting part isn't the exception, it's the mechanism that detects when to throw it. First idea: a boolean "dirty" flag Obvious first attempt: a boolean modified field on the map, flipped to true on any put / remove , checked by the iterator. This works for exactly one iterator. It falls apart the moment two iterators are alive at once: Iterator A calls next() , sees modified == false , proceeds. Something else mutates the map. modified flips to true . Iterator B — created after that mutation — checks the same shared modified flag, sees true , and incorrectly throws, even though nothing has changed since B was created. A single shared boolean can't represent "changed since this specific iterator was created" for more than one iterator at a time. Resetting it on read doesn't help either — now the other iterat

1. Problem Statement I wanted to contribute to an open source project called WikiEduDashboard , a web application built by Wiki Education. It helps instructors and program leaders run Wikipedia-editing classes and campaigns: students join a course, make edits to Wikipedia, and the dashboard tracks their work. To contribute code to this project, I first need a working copy of it running on my own PC. This is called a "local development environment." Without it, I can't test any changes I make before sending them back to the project. The problem: this project was built with tools that work best on Mac or Linux, not on plain Windows. So the first challenge wasn't even the project itself, it was figuring out how to run a Linux-friendly project on a Windows PC. 2. The Solution (High Level) Instead of fighting Windows directly, we used a feature built into Windows called WSL (Windows Subsystem for Linux) . WSL lets a real Linux system (Ubuntu, in our case) run inside Windows, side by side with your normal Windows apps. It's not a separate computer or a virtual machine you have to babysit, it just works like an extra terminal environment on the same PC. Once inside Ubuntu, we could follow the project's official setup instructions exactly as written, since those instructions assume a Mac or Linux machine. The overall plan looked like this: Get a Linux environment running on Windows (WSL + Ubuntu) Get a personal copy of the project's code (fork it on GitHub, then clone it) Install the programming language the project is built with (Ruby) Run the project's automated setup script, which installs the rest of the required tools (database, background job system, etc.) Start the actual application and view it in a browser Build the frontend (the visual, interactive part of the site) Set up an editor (VS Code) that can actually see and edit the code living inside Ubuntu 3. Step by Step: What We Did and Why Step 1: Install WSL and Ubuntu What: WSL is a Windows feature that runs a re

GitHub热门项目 | Checkstyle is a development tool to help programmers write Java code that adheres to a coding standard. By default it supports the Google Java Style Guide and Sun Code Conventions, but is highly configurable. It can be invoked with an ANT task and a command line program. | Stars: 9,115 | 78 stars today | 语言: Java

You type "Hi" and the computer stores 01001000 01101001 . Text is just numbers wearing a costume. Here is exactly how a string turns into binary, why UTF-8 matters, and how to do the conversion both ways in a few lines of JavaScript. What "binary" actually means here Computers do not store letters. They store numbers, and every number is a run of ones and zeros. Each character maps to a code point, that number becomes a byte, and each byte is written as eight bits . The letter A has the ASCII code 65. In binary that is: 65 = 01000001 Lowercase a is 97, which is 01100001 . So the whole word "Hi" ( H = 72, i = 105) becomes: 01001000 01101001 Group the bits into bytes of 8 and you can read any binary string back into text. Text to binary in JavaScript The reliable way is TextEncoder . It hands you the raw UTF-8 bytes, so you do not have to worry about character codes above 127. function textToBinary ( text ) { const bytes = new TextEncoder (). encode ( text ); return Array . from ( bytes ) . map ( b => b . toString ( 2 ). padStart ( 8 , " 0 " )) . join ( " " ); } textToBinary ( " Hi " ); // "01001000 01101001" toString(2) gives the binary digits, and padStart(8, "0") keeps every byte a full 8 bits. Without the pad, H would come out as 1001000 (7 bits) and the string would be impossible to split back cleanly. Binary back to text Reverse the process: strip spaces, cut the string into 8-bit chunks, parse each chunk as a base-2 number, then decode the bytes with TextDecoder . function binaryToText ( bin ) { const bits = bin . replace ( / \s +/g , "" ); const bytes = new Uint8Array ( bits . length / 8 ); for ( let i = 0 ; i < bytes . length ; i ++ ) { bytes [ i ] = parseInt ( bits . slice ( i * 8 , i * 8 + 8 ), 2 ); } return new TextDecoder ( " utf-8 " ). decode ( bytes ); } binaryToText ( " 01001000 01101001 " ); // "Hi" Two checks worth adding in real code: reject anything that is not 0 or 1 , and reject a bit count that is not a multiple of 8. Those two guards catch almo

When applying for engineering roles, automated applicant tracking systems (ATS) often silently reject candidates due to parsing blockers like multi-column layouts, missing quantitative metrics, or non-standard font embeddings. To fix this latency bottleneck, I built MyRizzume ( https://myrizzume.me ) — designed to parse and score resumes end-to-end in under 1,000ms. What it checks: Layout Integrity: Validates that column and table layouts won't merge or scramble text during ATS ingestion. Action Verb Strength: Highlights passive phrases and suggests active, quantifiable replacements. Keyword Density: Compares section headers and skill blocks against common parser taxonomies. Try it out live at https://myrizzume.me and let me know how it handles your layout!

The Silent Killer of Next.js Performance: Component Poisoning In the modern React ecosystem, specifically within Next.js and the new paradigms introduced in React 19, the distinction between Server Components and Client Components is the most critical architectural concept to master. Yet, it is also the most frequently misunderstood. If you have ever imported a React Server Component directly into a Client Component, you have inadvertently "poisoned" your application. This silent performance killer is rampant in production codebases, leading to bloated bundles, broken security, and a complete breakdown of the server-side benefits you migrated to React Server Components (RSC) to achieve in the first place. What is Component Poisoning? Component poisoning occurs when a developer treats file boundaries as mere organizational choices rather than strict execution boundaries. When you write import MyServerComponent from './MyServerComponent' inside a file marked with 'use client' , you are telling the bundler to include that component in the client-side JavaScript bundle. The moment that import statement is parsed, the Server Component is stripped of its server-only capabilities—like direct database access or environment variable usage—and compiled into a Client Component. The result? Bundle Bloat: Code that was meant to stay on the server is now shipped to the browser. Broken Logic: Any code relying on Node.js-specific APIs or secret keys will throw errors at runtime because it is now executing in the browser's environment. Performance Degradation: The primary benefit of RSC—reducing the amount of JavaScript sent to the client—is completely negated. The Mental Model: Respecting the Serialization Boundary To avoid poisoning, you must shift your mental model. Client Components cannot "own" Server Components. They cannot import them, nor can they directly control their execution lifecycle. Instead, think of the Serialization Boundary . React Server Components render on the

I’ve been building a browser-first project called RelicBeam, and one feature I wanted was simple in theory: Open a folder on one device and temporarily browse it from another device without installing anything. That became Remote Files, part of RelicBeam’s Device Portal. The host selects a folder, another device joins with a QR/code, the host approves the connection, and the second device can browse, preview and download files. The folder itself is never uploaded to RelicBeam. File data travels over a WebRTC DataChannel. If a direct connection isn’t possible, my own TURN server relays the encrypted traffic. Device Portal traffic is end-to-end encrypted between the connected browsers. The interesting problems The file browser itself was actually the easy part. Android file pickers kept killing sessions When I added optional uploads, I noticed something odd during testing. The first upload worked, but after opening the Android file picker a few times, the Remote Files session could suddenly disconnect. It turned out Android can background or suspend the browser while the native file picker is open. That could temporarily drop the Socket.IO signaling connection, and my server was treating any disconnect as the viewer leaving permanently. The fix was a short reconnect grace period. Temporary disconnects now get time to recover, while explicit Leave and End session actions still terminate access immediately. Firefox and Safari can browse, but not host uploads Remote Files works read-only across browsers, but writable folder access is more limited. Chrome and Edge expose writable directory handles through the File System Access API, so a host can optionally allow remote uploads into the selected folder. Firefox and Safari don’t currently expose the same writable directory picker. So today: Chrome / Edge host Browse ✅ Preview ✅ Download ✅ Optional uploads ✅ Firefox / Safari host Browse ✅ Preview ✅ Download ✅ Host uploads ❌ Firefox and Safari can still be the remote device

It's the week before vizcrush goes public, and I have two files open side by side. On the left, the launch copy: the JS core beats the most popular npm downsampling package by 32×, "and WASM adds another 5-10x on top." On the right, the repo's own benchmark control run: wasm/js ≈ 1.00× . One million points, same algorithm, same machine. Parity. I go looking for the measurements behind the claim. Half of it holds up: the 32× JS comparison has a result file (1.72ms against 55.52ms, real). The claimed additional 5-10× from WASM has nothing behind it, and the repo's own control run contradicts it. That afternoon set the shape of the whole launch: before anything shipped, every performance claim would either get a measurement behind it or get deleted. Three beliefs didn't survive. Each one got a public retraction, written up as an ADR in the repo. vizcrush is a set of data primitives for browser visualization (downsampling, binning, spatial indexing, streaming sketches), written in Rust, compiled to WebAssembly, with a pure-JS core behind the same API as a fallback and explicitly selectable backend. It went open source this week: the repo and the book are public, and all 11 packages are live on npm. npm install @vizcrush/core @vizcrush/downsample This is a launch story about turning benchmark results into product policy: claims, documentation, and WebGPU policy follow the measurements, while WASM dispatch stays availability-based pending further investigation. One scope note before the data. Every result here is workload-specific: LTTB (Largest-Triangle-Three-Buckets, the downsampling algorithm that picks, per bucket, the point that best preserves the visual shape of the line) is downsampling, the stats kernel is a reduction, and bin2d is histogramming. Which backend wins is algorithm- and engine-dependent, so none of what follows is a library-wide WASM-versus-JS verdict. It is three specific workloads measured on specific engines, with the claims and documentation follo

Imagine a teacher wants to greet 5 students: Hello Arun Hello Kumar Hello Ravi Hello Priya Hello Divya Without a loop, we need to write the same code multiple times. console . log ( " Hello Arun " ); console . log ( " Hello Kumar " ); console . log ( " Hello Ravi " ); console . log ( " Hello Priya " ); console . log ( " Hello Divya " ); Instead of writing the same type of code again and again, JavaScript provides loops . 🔄 What is a Loop? A loop is used to execute a block of code repeatedly. It helps us avoid writing the same code again and again. A loop continues running based on a condition or a collection of values . In simple words: A loop means repeating a task multiple times using code. For example: For every student: Print the student's name This is the basic idea of a loop. 🤔 Why Do We Use Loops? Loops are useful when the same task needs to be performed multiple times. For example, without a loop: console . log ( " Hello " ); console . log ( " Hello " ); console . log ( " Hello " ); console . log ( " Hello " ); console . log ( " Hello " ); Using a loop: for ( let i = 1 ; i <= 5 ; i ++ ) { console . log ( " Hello " ); } Output: Hello Hello Hello Hello Hello If the task needs to be performed 100 or 1000 times, using a loop is much easier than writing the same code repeatedly. 📍 Where Are Loops Used? Loops can be used in many situations, such as: Displaying a list of products Processing a list of students Reading values from an array Printing numbers Calculating marks Processing multiple records Repeating a task until a condition becomes false For example: For every product: Display the product ⏰ When Should We Use a Loop? A loop can be used when: The same task needs to be performed multiple times. For example: For every student: Display the student's name or: While the password is incorrect: Ask for the password again Different situations require different types of loops. 🔢 Types of Loops in JavaScript JavaScript provides different types of loops: for loop whi