GitHub热门项目 | OpenKB: Open LLM Knowledge Base | Stars: 2,349 | 208 stars today | 语言: Python

GitHub热门项目 | Generate audiobooks from e-books | Stars: 7,750 | 151 stars today | 语言: Python

GitHub热门项目 | A collective list of free APIs | Stars: 442,738 | 408 stars today | 语言: Python

GitHub热门项目 | macOS video editor built for AI | Stars: 1,436 | 749 stars today | 语言: Swift

GitHub热门项目 | A one stop repository for generative AI research updates, interview resources, notebooks and much more! | Stars: 27,444 | 203 stars today | 语言: HTML

Toy Story 5 introduces a tablet as a villain, but it's also smart enough to realize tech isn't always bad. Parents just need to step up.

Where's the Trump phone? We're going to keep talking about it every week. We don't have the phones we preordered yet, but this week we received unexpected news from Trump Mobile's media relations manager. If you've been following my reporting on the Trump phone, you'll know that Trump Mobile doesn't exactly keep open lines of […]

Call it a startup with a sole founder and a very large seed round, but what's next is less clear.

Luca Guadagnino's Sam Altman biopic has to find a new studio after Amazon dropped it.

This is a submission for the June Solstice Game Jam . What I Built Bletchley's Longest Day is a browser-based cipher escape game set inside a fictional Bletchley Park night shift. The player has to stop a U-boat convoy attack before dawn by clearing five rooms. Each room contains three escalating locks, so the full escape requires 15 solved puzzles . The game combines Caesar shifts, A1Z26 number decoding, Morse, anagrams, fragment ordering, a visible countdown timer, mistake penalties, hint penalties, account-based score saving, and a best-score leaderboard. The solstice theme became the core dramatic clock: night is running out, first light is coming, and the player has to decode the final signal before dawn. Video Demo The demo shows the opening briefing, the three-lock room flow, the Gemini hint penalty, and the final victory state that only appears after all 15 locks are cleared. Live game: https://bletchleys-longest-day.onrender.com Code Repository: https://github.com/himanshu748/bletchleys-longest-day How I Built It The game is a lightweight Node-served browser app. The front end is a hand-built HTML/CSS/JavaScript game surface, while server.js serves static files and protects the Gemini API key behind a server-side /api/hint endpoint. The main design goal was to make the game feel like a tense intelligence desk rather than a generic puzzle page. Every room has atmosphere, evidence props, lock-specific copy, feedback states, and a timer that is always part of the pressure. The puzzle structure was tuned around three ideas: Three locks per room : each room has to be solved in stages, so the player earns the escape instead of clicking through one answer. Time as score pressure : wrong answers and hints cost time, while clean solving preserves the best leaderboard run. Guest mode vs signed-in mode : guests can play the full game, but Gemini-powered hints and saved leaderboard scores belong to authenticated players. Google Gemini is used as a server-side hint offi

As a solo developer I wanted a fast, mobile-friendly interactive map for Palworld that didn't bury me in ads. The result is Pindrop , and here are a few of the technical decisions behind it. Rendering 1000+ markers without jank The interactive map uses Leaflet with a custom marker-clustering layer. Markers are served as static JSON from the edge and hydrated client-side, so the first paint is server-rendered and the heavy marker work happens after. A breeding calculator as a pure function Palworld's breeding combos are deterministic, so the breeding calculator is just a lookup over a precomputed table rather than a backend call. That keeps it instant and fully cacheable. Stack Next.js (App Router) for SSR + static generation Leaflet for the map layer Supabase for the small amount of dynamic data Vercel for hosting and edge caching If you play Palworld, the guides section collects the breeding, location and boss notes I kept losing track of. Feedback from other devs welcome — especially on the clustering approach.

Failures are obvious. Retries are sneaky. When something fails, everyone notices. An alert goes off. A request errors out. Someone starts investigating. Retries are different. They look harmless. Most of the time, they save the system. But sometimes, retries create bigger problems than the original failure. Imagine an API call times out. No problem. The system retries. But what if the first request actually succeeded and only the response was lost? Now the retry creates: duplicate orders repeated emails inconsistent records workflows running twice The failure happened once. The retry multiplied it. Another thing I've seen: One slow dependency causes requests to pile up. Retries start firing. Those retries create even more traffic. Which slows things down further. Which triggers even more retries. Suddenly, the system is spending more effort retrying than doing useful work. Retries also hide problems. A temporary issue gets retried five times and eventually succeeds. Everything looks normal. Meanwhile: latency increases queues grow users experience delays Nothing technically failed. But the system is getting less healthy. What changed for me is that I stopped treating retries as free. Every retry has a cost. It consumes resources. It increases load. And if actions aren't designed carefully, retries can repeat side effects that should only happen once. Now when I build something, I don't ask: "What happens if this fails?" I ask: "What happens if this runs again?" Because in production, things almost always run again. And if the answer is "bad things happen," the retry mechanism isn't helping. It's making things worse. Failures are part of every system. Retries are too. The difference is that failures usually happen once. Retries can turn one problem into hundreds if you don't design for them. This is something we think about constantly at BrainPack when operating long-running workflows across multiple systems. AI and automation layers make retries even more common, wh

Pre: What is BlockSocial? BlockSocial is the ultimate social network for developers, bringing the energy of short-form video to the world of open source. Think of it as Facebook meets Instagram—a place to showcase your code, find inspiration, and build your developer brand through "Reels" and interactive dashboards. Github link: https://github.com/Hfs2024/BlockSocial 1. User Scenario & Workflow (The Fork System) The Setup User A : Publishes a post saying: "I love drinking Pepsi every day." User B : Is shy, but wants to tell their friend this is an unhealthy habit. User C : Is a malicious user who gossips. The Fork Mechanism User B creates a fork to discuss this post with User C via the POST /api/share endpoint. Data Copying : It copies the entire post contents except comments, likes, reports, and downloads. Chain Prevention : You can fork a forked post, but the system will fork the original source root, not the fork itself. Scope : It shares with only one user at a time to prevent unexpected group creation. Database Payload for Forks The following fields are appended to the document structure: { "share" : true , "shareId" : "post._id" , // The original post ID "sharedBy" : "req.currentUser.username" , // The user who shared or forked "shareTo" : "shareTo" , // The friend receiving the share "shareComment" : "comment || ''" // A quick comment on the post } Moderation & Enforcement Workflow If User C breaks trust and leaks the conversation, User B can report them via the POST /report/user endpoint. Verification : Administrators review interaction history to verify the violation. Account Termination : Bad users receive a permanent lifetime account ban. Data Scrubbing : All associated messages from the malicious user are removed. Blacklisting : The account is fully banned. The Blindspot : Face-to-face interactions remain outside system moderation boundaries 😅 2. Technical Implementation Details Dynamic Comment Identity Logic When a user submits a comment via POST /api/c

For years I treated burnout as a personal failing. If I was tired, I needed more sleep. If I was anxious on Sunday night, I needed to meditate. If I dreaded standup, I needed a better attitude. None of it worked, because I was treating an organizational problem as a character problem. Senior engineer burnout rarely looks like simple exhaustion. It looks like your pull request reviews getting slower. It looks like tech debt you keep meaning to document and never do. It looks like every "quick question" landing in your DMs, because you are the person who knows where everything is. The load is structural. You cannot meditate your way out of an org chart. Here is the framework that finally helped me, and that I now keep as a runbook. First, diagnose: acute or systemic A rough sprint is not burnout. A hard quarter is not burnout. Those are acute, and they resolve when the spike passes. Systemic burnout is different. The recovery never comes, because the structure that caused it never changes. You finish the death-march launch and the next one is already scheduled. You clear the queue and it refills by lunch. The mistake is applying acute fixes (a long weekend, a vacation) to a systemic problem. You come back rested, the structure grinds you down again in two weeks, and now you also feel like the rest "did not work," which makes it worse. A quick self-check. In the last month: Do you feel recovered after a weekend, or does Sunday-evening dread start by Saturday night? Is your reduced capacity tied to one specific deadline, or is it just how things are now? If your single worst recurring task vanished tomorrow, would you feel fine, or would something else immediately take its place? If your answers point to "it is just how things are now," you are dealing with systemic burnout, and the fixes are structural, not personal. Reclaim deep work with routing, not willpower Deep work does not survive on discipline. It survives on routing. The senior engineer's calendar is a public

Focus: Unit Tests ONLY — no integration, no E2E Stacks: Node.js (NestJS/Express) · React.js · Python · Angular · Laravel Goal: AI generates unit tests consistently, deterministically, without hallucination IDE: Cursor (Primary) + Claude (Secondary) Part 1 — Best Single Library Per Stack (Final Decision) Do not mix libraries. Pick one per stack, configure it fully, never deviate. | Stack | Library | Why This One | |---|---|---| | Node.js / NestJS / Express | Jest | Native DI mocking, @nestjs/testing built around it, widest ecosystem | | React.js | Vitest + @testing-library/react | Native Vite/ESM support, Jest-compatible API, 3–10x faster | | Python | pytest | De facto standard, fixture system eliminates boilerplate, best plugin ecosystem | | Angular | Jest (replace Karma) | Karma is deprecated in Angular 17+; Jest is the official migration target | | Laravel | Pest | Modern syntax, built on PHPUnit, higher signal-to-noise ratio | Rule: If someone suggests a second library for the same stack, reject it. One library per stack, configured once, followed always. Part 2 — IDE: Cursor (Only Choice for This Goal) Why Cursor and Not VS Code / WebStorm | Capability | Cursor | VS Code + Copilot | WebStorm | |---|---|---|---| | Project-level AI rules | ✅ .cursor/rules/ | ❌ | ❌ | | Codebase-aware context | ✅ @codebase | Partial | Partial | | Run terminal + read output | ✅ Composer | ❌ | ❌ | | Multi-file generation | ✅ Agent mode | Limited | ❌ | | Custom instructions per filetype | ✅ | ❌ | ❌ | | MCP server integration | ✅ | ❌ | ❌ | Cursor's .cursor/rules/ system is the only IDE-native mechanism that injects persistent, project-scoped instructions into every AI interaction — this is what prevents hallucination at the source. Cursor Setup for This Project project-root/ ├── .cursor/ │ └── rules/ │ ├── unit-test-global.mdc ← applies to all files │ ├── unit-test-nestjs.mdc ← applies to *.service.ts, *.guard.ts │ ├── unit-test-react.mdc ← applies to *.tsx, *.component.tsx │ ├── unit-t

Your retriever returned the right documents. The similarity scores look fine. The answer is still wrong. If you've shipped RAG, you've seen this — and it's the failure that survives every retrieval upgrade. What everyone tries Reranker. Higher top-k. Hybrid search. A better embedding model. All of these chase the same goal: documents more similar to the query. They help when the right document wasn't being retrieved. They do nothing when the right document was retrieved and the answer is still wrong. Why it doesn't work Similarity answers "is this chunk about the same topic?" It does not answer "does this chunk contain the facts needed to support the answer?" Those come apart constantly. A chunk can be highly similar — same vocabulary, same subject — and contain nothing that actually grounds the answer. Hand the model a pile of on-topic text and it will produce a fluent, plausible, even cited-looking answer. The grounding is cosmetic: the text was nearby, not load-bearing. High similarity with a wrong answer isn't a contradiction. You asked retrieval to find related text. It did. Nobody asked whether the text was enough. The one shift Stop treating retrieval output as evidence. Treat it as candidate material that has to pass an explicit evidence check before it can support an answer. Put a step between retrieval and generation: does the retrieved set actually contain the facts this answer requires? If not, abstain. When the documents don't contain the facts, the system should return nothing rather than a confident guess. Relevant context in, only sufficient evidence allowed through. That's the line between a RAG demo and a RAG system you can trust in production. I write about the three boundaries where production RAG dies — query, evidence, output — from the angle of shipping under security and model constraints. Read the full version on my blog , where this connects to the practical RAG Failure Diagnosis Kit for teams debugging production RAG.

Static sites are great: fast, cheap to host, almost nothing to attack. Then you add a contact form and hit the same wall everyone hits — a static site can't process a submission. You need a backend. The usual answers are a third-party service (Formspree, Netlify Forms, Basin) or a small server you now have to babysit. Both add a dependency you don't control, a recurring bill, and — the part that bugs me most — your submission data lives on someone else's infrastructure. There's a third option I've been running for a while: one WordPress install, zero public pages, used purely as a form endpoint. Every form from every static site I own hits it. I own all the data. And because it serves no public HTML, its attack surface is close to nothing. The architecture Three pieces, each doing one job: WordPress — the backend. Locked down so hard it doesn't behave like a normal WP site anymore. A form plugin — handles building, validation, storage, email, file uploads. (I use CraftForms because it exposes a clean craftforms/v1 REST namespace and can also serve the form HTML to an external page — more on that below.) Your static frontend — Cloudflare Pages / Netlify / wherever. It either fetch es the REST endpoint on submit, or drops in an embed snippet. WordPress never serves a public request. It only processes submissions. The part that matters: locking it down The biggest WordPress attack vector isn't your host — it's outdated plugins . So the first move is brutal minimalism: one plugin, no theme, no page builder, no public frontend. A WP install with one plugin and a blocked frontend has almost no CVE surface, because none of the usual stuff is installed. The rest is one must-use plugin. Drop this in wp-content/mu-plugins/ (no activation needed) and you've blocked the four standard entry points: <?php if ( ! defined ( 'ABSPATH' ) ) exit ; // 1. Restrict the REST API to your form namespace only. // Kills user enumeration (/wp/v2/users), route discovery, the usual REST exploits