标签：#Java

It started with one simple question: Why am I still doing this manually? I was working on a spreadsheet, checking information row by row, sending emails, and updating statuses. The process was not difficult, but it was repetitive. One small mistake could mean sending incorrect information, overlooking a request, or forgetting to update a row. I knew there had to be an easier way. I wanted the spreadsheet to detect when a status changed to Sent , find the email address in the same row, send the correct message, and add a timestamp after the email was sent. The idea sounded simple in my head. The problem was that I did not know how to build it. I was still learning how to code, so I asked AI for help. My first prompt was something like: Create a script that sends an email from Google Sheets. AI immediately generated a script. It looked impressive, but it did not work the way I expected. The script checked the wrong column, used information from the wrong cells, and failed when some required details were missing. That was when I realized the problem was not only the code. My instructions were too vague. I tried again, but this time I described the entire process: When the status in Column G changes to "Sent," get the email address from Column E and send a confirmation email. After the email is sent successfully, add a timestamp to Column H. Do not send the email if any required information is missing. The result was much closer to what I needed. When I changed the status to Sent and received the email automatically, I felt genuinely excited. It was only a small automation, but it removed several manual steps from the process. After building that first workflow, I started noticing repetitive tasks everywhere. A form submission could automatically send a confirmation email. A spreadsheet could detect missing information before processing a request. A completed action could record the date and time. Reports could be organized without manually copying every row. Tasks that

The bug reports all sounded the same. "It disconnected again." No error, no warning, nothing on screen to explain it. Someone would open a GitHub issue, start a planning-poker vote, then stop to actually read the thing they were estimating. Thirty seconds later they'd look back and the room had quietly gone still. Other people's votes weren't showing up, and their own weren't reaching the room. It had simply stopped, without a word. If you've ever built anything real on Chrome's Manifest V3, you can probably guess where this is going. The socket didn't drop because the network hiccupped. It dropped because Chrome reached over and killed the process it was living in. This is the story of that bug, and what it actually takes to keep a WebSocket alive inside a Manifest V3 extension. TL;DR: Manifest V3 runs your background code in a service worker that Chrome terminates after ~30s idle. If your WebSocket lives there, it dies with it, silently. The fix is three parts: a heartbeat so extension activity keeps the worker awake, auto-reconnect that pulls a fresh snapshot so drops are invisible, and a try/catch around every port message because the worker can die between your null-check and the call. Why the socket doesn't live where you'd expect First, some context on how the extension is wired, because it explains why this bug was even possible. It puts a button on GitHub issues and boards. Click it, and a live planning-poker room opens right there in the page. Votes flow over a WebSocket to a Cloudflare Durable Object that owns the room's state. Standard real-time stuff. The obvious place to open that socket is the content script, the code injected into the GitHub page. That's where the UI lives, so why not open the socket right next to it? Firefox is why not. A content script runs in the page's world, which means it inherits the page's Content Security Policy. GitHub ships a strict connect-src , and Firefox enforces it against content scripts. Try to open wss://… from the

Meet unzstd - a pure Java Zstandard (zstd) decoder for Android and the JVM. What looked like a simple dependency turned into a surprisingly difficult problem. I needed to decompress zstd-compressed datasets in an Android app. Existing options all had major trade-offs: aircompressor 2.x depends on "sun.misc.Unsafe", which crashes on Android ART. aircompressor 3.x moved to "java.lang.foreign", which Android doesn't support. zstd-jni works well, but requires native ".so" files, ABI-specific packaging, and brings additional complexity with newer Android memory page requirements. I had to build a pure Java alternative so I ported aircompressor's decoder The result: ✅ No native code ✅ No "Unsafe" ✅ No "java.lang.foreign" ✅ Android API 26+ ✅ JVM 9+ ✅ Zero "Unsafe" references in the compiled bytecode (verified) To make sure it was actually correct, I differentially tested it against libzstd across compression levels 1-22, covering one-shot decompression, streaming, fuzzing, and corruption-boundary tests. It's decode-only, Apache 2.0 licensed, and completely open source. If you're building Android or Java applications that consume zstd-compressed data, I hope this saves you a few days of debugging. implementation("com.qyntrax:unzstd:0.1.0") GitHub: https://github.com/mbobiosio/unzstd Feedback, bug reports, and contributions are always welcome. Android #Java #Kotlin #OpenSource #JVM #Zstd #Compression

Nuxt vs SvelteKit. Which one is better? That is is what I've been testing out this week. I built the...

Rspack, developed by ByteDance, has released version 2.0, featuring enhanced performance, reduced dependencies, and a focus on modern ECMAScript modules. Key updates include a pure ESM core, improved static analysis, and support for RSC. Performance benchmarks show big improvements in build times. The project has experienced substantial growth, with npm downloads exceeding 5 million weekly. By Daniel Curtis

GitHub热门项目 | Skill that audits and rewrites content to remove AI writing patterns. Use it with your favorite agents including Claude Code, OpenClaw, and Hermes. | Stars: 2,511 | 165 stars this week | 语言: JavaScript

GitHub热门项目 | Expert-level WordPress knowledge for AI coding assistants - blocks, themes, plugins, and best practices | Stars: 1,901 | 7 stars today | 语言: JavaScript

GitHub热门项目 | A collection of AI agent skills for working with Expo projects and Expo Application Services | Stars: 2,286 | 55 stars today | 语言: JavaScript

It is time to bring opposites together, to stir up these stagnant waters, and to restore an industry that is dynamic from within, with multiple connections that were previously impossible or unimaginable. In the previous parts of this series, we explored how PureScript acts as a quiet rewrite of the Web , offering a territory of mathematical precision above JavaScript, and how its universal polymorphism allows it to target wildly different runtimes like Node.js, Erlang's BEAM, Chez Scheme, etc. But hey, what about the elephant in the room? Yes, what is running the majority of the web, today, in the shadow? You know. The eternal one, the big one, the one whose death everyone talks about, but who never truly dies. PHP. While the modern JavaScript ecosystem (among others) races toward edge computing and containerized microservices, around 70% of the web is still powered by PHP . From legacy WordPress sites to affordable shared hosting (cPanel, OVH, GoDaddy, basic LAMP stacks), a massive portion of the internet lives in environments where escaping the PHP runtime is either financially unviable, technically impossible, or simply unnecessary. And yet... For a long time, the PHP ecosystem has been left without a true, strictly typed functional and safe alternative, like TypeScript for Javascript. Even though recent PHP versions introduced fantastic features (short closures, match expressions, Fibers), the frustration that comes with its historical limitations and dynamic typing remains very real for some of its users. Very well! This is why I built phpurs : a brand new compiler backend that transpiles PureScript directly to modern PHP 8.4+ syntax. It is no longer a proof of concept. It is passing the official PureScript test suite , and it is ready for production. Here is how we bring the elegance of purely functional programming to the big web, while keeping deployment as simple as a legacy FTP upload, or anything alike. The easy deployment paradox In modern DevOps, deplo

A request starts at 10:00:00.900 and finishes 200 ms later. Your latency log says -800 ms . That sounds impossible until the machine corrects its clock between the two reads. Then ordinary code turns an adjustable wall clock into a broken stopwatch. The subtraction that works—until it does not This is probably hiding in one of your metrics helpers: async function timed ( operation ) { const startedAt = Date . now (); const result = await operation (); return { result , durationMs : Date . now () - startedAt , }; } Most of the time, this reports a sensible number. That is what makes it dangerous. Date.now() answers a calendar question: how many milliseconds have passed since the Unix epoch according to this machine? The answer must remain comparable with logs, users, and other computers, so synchronization software is allowed to correct it. A correction can change its rate, jump it forward, or move it backward. If either correction lands between the two calls, the subtraction measures the clock adjustment as if it were work. A timestamp is a coordinate. A duration is a distance. They need different instruments. Your computer already has two kinds of clock Operating systems expose several clocks, but two mental buckets cover most application code: Question Clock JavaScript example “When did this happen?” Wall clock Date.now() , new Date() “How long did this take?” Monotonic clock performance.now() A wall clock follows civil time. It has an epoch and can be serialized as an ISO timestamp. A monotonic clock starts at an arbitrary origin and promises that later readings will not be lower than earlier readings. wall: 1000 ── 1001 ── 0998 ── 0999 clock correction monotonic: 40 ───── 41 ───── 42 ───── 43 On Linux, CLOCK_REALTIME is settable wall time . CLOCK_MONOTONIC cannot be set and does not make discontinuous jumps backward, although gradual frequency adjustment can affect its rate. Linux even has CLOCK_BOOTTIME for a monotonic counter that includes suspended time. Thre

You ask an LLM for JSON. You get this: json { "name": "test", "valid": True, "items": [1, 2, markdown Three problems in one response: markdown fences the LLM wasn't supposed to add, True instead of true (Python literal), and the response was cut off mid-array. JSON.parse() throws on all three. A linter tells you what's wrong. But you're left fixing it manually. I kept hitting this wall so often that I built a dedicated repair pipeline: AI JSONMedic . Why existing tools don't cut it JSONLint / JSONFormatter — great for valid-ish JSON with one missing comma. Not built for LLM failure modes: they flag errors but don't repair them. jsonrepair (npm) — solid library, handles many cases. AI JSONMedic actually uses it as a last-resort fallback. But it doesn't tell you what it changed, and doesn't handle all the LLM-specific cases we needed. The 14 failure modes we target Through building this, we catalogued how LLMs specifically break JSON: Markdown fences — ` json wrapping the output Trailing commas — [1, 2, 3,] (the model "runs out" of items but adds one more comma) Python literals — True , False , None instead of true , false , null Single quotes — {'key': 'value'} instead of double quotes Smart quotes — "key" (curly quotes from copy-paste) Unclosed brackets — truncated at max_tokens mid-array or mid-object Unclosed strings — "value without closing Concatenated objects — {"a":1}{"b":2} when streaming produces multiple chunks NDJSON — newline-delimited JSON that needs wrapping Python-style comments — # this is a comment inside JSON JavaScript-style comments — // inline or /* block */ Escaped backslashes — \\n instead of \n Duplicate keys — same key appearing twice (ambiguous — we warn, not silently pick) BOM / encoding issues — UTF-8 BOM at start of response What makes the repair pipeline different Each pass targets one failure mode. The order matters — strip fences first, then normalize quotes, then fix commas, then close truncated structures. Each change is tracked. The

So I built a Chrome extension that does one very stupid thing: it waits a random amount of time, then screams at you like a goat if you don't dismiss the notification fast enough. Simple idea. Should've been a simple build. It was not, because Manifest V3 said no. The plan was easy, in my head Here's what I thought I needed: chrome.alarms to fire at a random interval chrome.notifications to show a "you good?" popup If the user ignores it for 60 seconds, play a goat sound Step 3 is where things fell apart. Because in Manifest V3, your background script isn't a persistent background page anymore — it's a service worker. And service workers have the audio capabilities of a rock. No Audio() object. No Web Audio API. Nothing. You can't just do new Audio('goat.mp3').play() and call it a day, because there's no DOM for it to live in. I found this out the way everyone finds out things in MV3: by writing the obvious code, watching it silently fail, and then spending 20 minutes wondering if I'd misspelled "goat." Enter: the offscreen document Chrome's answer to "service workers can't do X" for a bunch of X's (audio playback included) is the offscreen document API . It's exactly what it sounds like — a hidden HTML page that exists purely so your extension has something with a DOM, so it can do DOM things. In my case, playing an mp3 of a goat losing its mind. The flow ends up looking like this: service worker (background.js) → creates an offscreen document if one doesn't exist → sends it a message: "play the sound" offscreen.html/offscreen.js → has an <audio> tag → actually plays the sound → closes itself when done It's a little bit like hiring a stunt double because the main actor (your service worker) isn't allowed near water. The offscreen document does the wet work, then goes home. Rough version of what that looks like in code: // background.js async function playGoatSound () { if ( ! ( await chrome . offscreen . hasDocument ())) { await chrome . offscreen . createDocument

Every time I needed to check whether my microphone actually worked before a call, or whether a key on a used keyboard was dead, I ended up on some sketchy "free online tester" that wanted an account, showed six ad banners, and — the worst part — happily streamed my webcam to a server I knew nothing about. So I built the thing I actually wanted: TestOnDevice — 118+ device tests that run 100% in the browser. No installs, no account, and nothing you record ever leaves your machine. Here's what I learned building it. The core constraint: the network is off-limits The single rule that shaped the whole project: no device data touches a server. No webcam frames, no audio buffers, no keystrokes, no sensor readings. That constraint turned out to be freeing rather than limiting, because modern browser APIs are genuinely powerful. Almost every "device test" is just a Web API plus a bit of rendering: What you're testing The API doing the work Microphone / speakers MediaDevices.getUserMedia , Web Audio ( AnalyserNode ) Webcam getUserMedia , <video> , MediaStreamTrack.getSettings() Keyboard keydown / keyup , KeyboardEvent.code Mouse / touch / stylus Pointer Events, PointerEvent.pressure Gamepads Gamepad API MIDI keyboards Web MIDI API Display ( dead pixels , refresh rate ) Fullscreen + requestAnimationFrame Motion / orientation DeviceOrientationEvent , DeviceMotionEvent A live mic meter, entirely local The microphone test is a good example of how little you need. Grab a stream, wire it into an AnalyserNode , and compute RMS on each frame for a level meter — no recording, no upload: const stream = await navigator . mediaDevices . getUserMedia ({ audio : true }); const ctx = new AudioContext (); const analyser = ctx . createAnalyser (); ctx . createMediaStreamSource ( stream ). connect ( analyser ); const data = new Uint8Array ( analyser . frequencyBinCount ); function tick () { analyser . getByteTimeDomainData ( data ); let sum = 0 ; for ( const v of data ) { const x = ( v - 128 )

The feature was supposed to be the easy one. NotebookLM generates flashcards. My extension reads them...

🚀 JavaScript Fundamentals (Week-03): Building a Strong Foundation "Before learning frameworks like React or backend technologies like Node.js, it's essential to build a strong understanding of JavaScript fundamentals. A solid foundation makes advanced concepts much easier to learn." Introduction During Week-03 of my Full Stack Development learning journey, I focused on understanding the fundamental concepts of JavaScript . Instead of only writing code, I wanted to understand how JavaScript works behind the scenes . In this week, I learned about variables, hoisting, different types of scope, execution context, call stack, closures, the this keyword, call() , apply() , bind() , module patterns, and clean coding principles like DRY and KISS . In this blog, I'll explain each concept in a simple and beginner-friendly way with examples. 📚 Topics Covered What is JavaScript? Variables ( var , let , const ) Hoisting Scope Global Scope Function Scope Block Scope Lexical Scope Scope Chain Execution Context Call Stack The this Keyword call() , apply() , and bind() Closures Module Pattern Common var vs let Bugs DRY Principle KISS Principle Conclusion 📌 What is JavaScript? JavaScript is a high-level, interpreted, single-threaded programming language used to build interactive and dynamic web applications. Initially, JavaScript was designed to run only in web browsers, but today it can also run on servers using Node.js . Some common uses of JavaScript include: Creating interactive web pages Form validation DOM manipulation API communication Web application development Backend development with Node.js Example console . log ( " Hello, JavaScript! " ); Output Hello , JavaScript ! 📦 Variables Variables are containers used to store data. JavaScript provides three ways to declare variables: var let const var Characteristics Function Scoped Can be redeclared Can be reassigned Hoisted var name = " Sai " ; var name = " Rahul " ; console . log ( name ); Output Rahul let Characteristics Block

Strings & Text Processing: Text Isn't as Simple as It Looks If someone asks you what's the simplest type of data in programming, there's a good chance you'll say strings . After all, they're just text. A person's name is a string. An email address is a string. A password is a string. Even the message you're reading right now is just a collection of strings. At first glance, there doesn't seem to be much to learn. You create a string, print it, compare it with another string, and move on. But after writing a few programs, things start getting... strange. You convert "hello" into uppercase, yet the original string somehow stays the same. An emoji that looks like a single character suddenly reports a length of 2 . Joining thousands of small strings together makes your program unexpectedly slower. And then someone introduces you to something called Regex , which looks less like code and more like an ancient spell. None of these are bugs. They're simply the result of how strings actually work behind the scenes. In this lesson, we'll uncover those hidden details one by one. Surprise #1: Why Didn't the String Change? Take a look at this code. const original = " hello " ; const shouted = original . toUpperCase (); console . log ( original ); console . log ( shouted ); What would you expect the output to be? Many beginners think the output will look like this: HELLO HELLO But that's not what happens. Instead, JavaScript prints: hello HELLO The original string remains exactly as it was. Why? Because strings are immutable . What Does "Immutable" Mean? The word immutable simply means: Once something is created, it cannot be changed. Think of a printed book. If you want every occurrence of the word hello to become HELLO , you don't magically change the ink that's already on the paper. Instead, you print a new copy with the updated text. Strings behave in a similar way. Whenever you use methods like: toUpperCase() toLowerCase() replace() concat() the original string stays untouch

Hey everyone! 👋 First of all, thank you so much for all the support, feedback, and feature suggestions since the Product Hunt launch. Every comment has been incredibly valuable, and I've already started implementing some of your ideas. Today I'm excited to share a new update to Rizzzler ! 🌙 ✨ What's New? 🎨 2 Brand-New Themes I've added two new themes , giving you even more ways to personalize your profile and match your own style. Whether you prefer something clean, vibrant, or expressive, there's now even more variety to choose from. 👀 Live Preview Panel One of the most requested improvements is finally here! You can now preview your showcase page while editing it . No more guessing how your profile will look after saving—see your changes in real time before publishing. 🎵 Audio Preview Choosing background music is now much easier. Instead of selecting tracks blindly, you can now preview audio directly before applying it to your profile. ✨ Profile Picture Decorations Want your profile to stand out even more? You can now add Profile Picture Decorations to give your avatar a unique look and make your showcase even more personal. More decoration styles will be added in future updates! ❤️ Thank You The feedback from the GitHub community and Product Hunt has been incredibly helpful. Many of these improvements came directly from community suggestions, and I'll continue building Rizzzler based on your ideas. If you have feature requests, bug reports, or suggestions, I'd love to hear them! 🔗 Try Rizzzler Website https://rizzzler.onrender.com Product Hunt https://www.producthunt.com/p/rizzzler-show-yourself-off GitHub https://github.com/DeveloperPuneet/Rizzzler-Stable Thank you for supporting Rizzzler! 🚀

Error handling has a quiet problem. You catch an error deep in a call stack, wrap it in something...

The openFDA enforcement API is free, keyless, and well documented on the surface. It is also full of failure modes that return HTTP 200 with quietly wrong data. Every number and error string below was measured against the live API on 2026-07-20; anything I could not reproduce has been cut. Pick the right endpoint first There are four recall-shaped endpoints and they are not interchangeable. Choosing wrong gives you a different universe of records with no warning. Endpoint Records What it is drug/enforcement.json 17,793 Recall Enterprise System (RES) drug recalls device/enforcement.json 39,519 RES device recalls food/enforcement.json 29,224 RES food recalls device/recall.json 58,756 CDRH device recall database, a different schema entirely The three enforcement endpoints share their schema. device/recall.json does not: its fields include cfres_id , product_res_number , k_numbers , root_cause_description , event_date_posted , event_date_terminated and recall_status , and it has no classification field at all ( count=classification.exact returns HTTP 404 "Nothing to count" ). If you are filtering for Class I, you want an enforcement endpoint. The two families also refresh on different clocks. On 2026-07-20 the three enforcement endpoints reported meta.last_updated of 2026-07-08, while device/recall.json reported 2026-07-17. The OR bug that silently returns the wrong answer This is the single most expensive trap, and it is undocumented. An unparenthesized OR discards every clause except the last one. All figures below are from food/enforcement.json . search=classification:"Class I" OR state:"CA" returns 4,003 - exactly the count for state:"CA" alone. Reverse the operands and you get 12,809 - exactly classification:"Class I" alone. Wrap it: search=(classification:"Class+I"+OR+state:"CA") returns 14,822 in both orders. That is the real union (12,809 + 4,003 - 1,990 overlap, and the AND of the two clauses does return 1,990). No error is raised in any case. The nastier varia

Every time you run a JavaScript program, a lot happens behind the scenes. Variables are allocated memory, execution contexts are created, functions are pushed onto the call stack, and the engine starts executing your code. But before we dive into all of that, let's first understand what JavaScript actually is and why it was created. An Introduction to JavaScript What is JavaScript? JavaScript is a programming language that was originally created in 1995 by Brendan Eich in just 10 days while he was working at Netscape. JavaScript is a high-level programming language primarily used to make web pages interactive. Today, it is also used to build servers, mobile applications, desktop software, and much more. Why was JavaScript created? JavaScript was created to make web pages alive . But what does "alive" mean? it means adding interactivity (e.g., animations, clickable buttons, popup menus, etc.) to the static web pages. Today, JavaScript isn't limited to browsers. With runtimes like Node.js, it can also be used to build backend applications and APIs, which allow you to add more functionality to a website. Did you know? When JavaScript was created, it initially had another name: “LiveScript”. Where can JavaScript be used? In your browser — every interactive website uses it (Facebook, YouTube, Gmail). On servers — through Node.js, you can build backend APIs. In mobile apps — using frameworks like React Native. In desktop apps — VS Code itself is built using JavaScript (Electron). In smart devices, games, robots, and much more. Now that we know what JavaScript is, another question comes to mind: How does JavaScript execute my code? Before answering that, let's first understand Who executes my code? . The answer is: The JavaScript Engine The JavaScript Engine We already know what JavaScript is, but what exactly is this engine ? The "Engine" A JavaScript engine is a piece of software responsible for executing JavaScript code. Every environment that runs JavaScript, whether i