标签：#Java

I built PunFiction: 1-Star Travel Reviews , a free daily web puzzle where you guess world landmarks by deciphering unhinged travel reviews from confused travelers. Tech Stack: Vanilla JS, CSS, HTML, GitHub Pages, MongoDB Atlas The Concept The internet can feel like it's literally overflowing with consumer complaints. I decided to take that negative energy and turn it into a 2-minute daily browser game for your morning coffee break. The Game Loop: Read an absurd 1-star review of a famous world landmark. Decipher the rhyming pun clues to guess the destination. Solving the puzzle unlocks an illustrated cartoon postcard and a sassy reply from the landmark 'manager'. The Tech Stack I wanted PunFiction to feel lightweight and lightning fast. Vanilla JavaScript: No React, Vue, or Svelte. Pure DOM manipulation and client-side logic. Zero Dependencies: No npm install spiral, no build-step headaches, and zero third-party scripts. No Accounts: Daily state, win streaks, and game progress live in localStorage. MongoDB Atlas: Light backend for aggregate puzzle stats (success rates, guess counts, no PII stored). Hosted on GitHub Pages: Static asset delivery via CDN. Give It a Spin If you like wordplay, geography, or just laughing at terrible tourist complaints, give today's daily puzzle a shot: 👉 Play PunFiction: 1-Star Travel Reviews I’d love to hear your thoughts on the UX, the game feel, or your take on building lightweight web games. Drop your feedback (or your worst pun) in the comments!

Most agent projects do not fail because the first model call is difficult. They become difficult when the prototype needs memory, tools, evaluation, a user interface, documentation that coding agents can navigate, and a repeatable review process. That is the problem the open-source AgentsKit ecosystem is trying to solve for JavaScript teams. It is a set of independent projects with shared contracts, rather than one application that must own the whole stack. The six public pieces 1. AgentsKit: the composable foundation AgentsKit provides focused JavaScript and TypeScript packages for runtimes, adapters, tools, skills, memory, RAG, evaluation, observability, sandboxing, and UI bindings. Its core has zero runtime dependencies and a CI-enforced 10 KB gzipped budget. Six formal contracts keep adapters, tools, memory, retrievers, skills, and runtimes substitutable. You can run a first local agent without an API key: npm install @agentskit/core @agentskit/runtime tsx Then connect OpenAI, Anthropic, Gemini, Ollama, or another adapter without changing the rest of the runtime composition. 2. AgentsKit Chat: one interaction model, seven renderers AgentsKit Chat defines an interactive agent experience once and renders it through React, React Native, Ink, Vue, Svelte, Solid, or Angular. It also supports deterministic local answers before an optional backend call. That matters for documentation and support interfaces where exact project facts should not require an LLM. pnpm dlx @agentskit/chat-cli@0.4.0 init my-chat --renderer react --yes 3. Registry: reusable source, not another dependency The AgentsKit Registry distributes ready-to-use agents in a shadcn-style model: the CLI copies the source into your project, so you can inspect and modify it. npx agentskit add research npx agentskit add code-review The public catalog currently includes research, code-review, and knowledge-promotion agents, and is open to contributions. 4. Agents Playbook: engineering rules that can execute Ag

Most "AI agent" libraries fall into one of two buckets. Either they're a big framework you spend an afternoon configuring, or they're a tiny toy that drops the one feature you actually need in production: the ability to stop and ask a human before the agent does something you can't undo. I wanted the middle. So I wrote yieldagent : a small agent loop you can read end to end, with human-in-the-loop pause/resume built in, and no runtime dependencies. This post walks through how it works and why it's built the way it is. What an agent loop actually is Strip away the branding and an "agent" is a loop: Send the conversation to the model, along with the tools it's allowed to call. If the model asks to call a tool, run it and append the result. Repeat until the model answers without asking for a tool. That's it. The model decides the control flow at runtime; your job is to run the tools and feed the results back. Here's the core, lightly trimmed: for ( let step = 0 ; step < maxSteps ; step ++ ) { const reply = await call ( messages , toolSpecs ); messages . push ( reply ); if ( ! reply . tool_calls ?. length ) { yield { type : " final " , text : reply . content , messages }; return ; } for ( const tc of reply . tool_calls ) { const args = JSON . parse ( tc . function . arguments ); const result = await tools [ tc . function . name ]. run ( args ); messages . push ({ role : " tool " , tool_call_id : tc . id , content : JSON . stringify ( result ) }); } } Everything else in the library is in service of making this loop observable, testable, and safe to run against the real world. Why an async generator Notice the yield . The loop is an async generator, so the caller drives it: for await ( const step of agent ({ call , tools , messages })) { if ( step . type === " tool-start " ) console . log ( " -> " , step . tool , step . args ); if ( step . type === " final " ) console . log ( step . text ); } Every step (each tool call, each result, and the final answer) is handed back to

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! 🚀