标签：#RAM

Shpper is a cross-border personal-shopping marketplace. A buyer wants something they cannot get where they live. A traveller is already flying that route with unused luggage space. The platform introduces them, holds the money until the item arrives, and turns an empty few kilos in someone's suitcase into a delivery network. I am the CTO. I own the platform end to end — the Flutter apps for both sides, the backend, payments and escrow, identity verification, and the release pipeline. We are on version 14.2.0, rated 4.64 on the App Store from 72 ratings. Fourteen major versions is enough distance to say something useful about what this kind of product actually demands. Almost none of the hard parts were the ones I expected. You are not building one app The first structural fact about a two-sided marketplace is that "the app" is two products with opposed interests, and you ship both. The buyer wants their item cheaply, quickly, and with certainty it will arrive. The traveller wants to be paid well, carry as little risk as possible, and not be blamed for customs. Those are not complementary desires. Every feature has to be designed twice, from two points of view, and any change to the shared middle — the request, the offer, the trip — reaches into both. This has a consequence people underestimate: your release cadence is bounded by the slower side. A change to how offers work is not shipped when the buyer app ships. It is shipped when both apps are live, on both platforms, and enough of both populations have updated. Mobile app review is not a build step you can optimise away; it is a scheduling constraint that shapes how you design changes, which is why so much of the logic has to be able to change without a release. The hard problem is trust, and it is not a feature A marketplace's actual product is trust between strangers. Everything else is plumbing. Consider what the platform is asking. A buyer sends money for an item that does not exist yet, to be bought by someo

submitted by /u/sousapereira [link] [留言]

Excitement I wanted to share my excitement of forcing myself to build without using AI. I...

AI can write code now. That part is no longer surprising. You can describe a feature to Copilot, Claude Code, Cursor, Codex, or another coding agent and get a working implementation in minutes. Sometimes it is genuinely impressive. But there is a bigger question: Can you actually trust the code enough to ship it? According to the Stack Overflow 2025 Developer Survey, 84% of developers use or plan to use AI tools . At the same time, trust in AI-generated output is still limited. One of the biggest frustrations developers report is getting an answer that is almost right, but not quite . Source: https://survey.stackoverflow.co/2025/ai And that “almost right” part is exactly where developers still matter. AI may write more code. But humans still need to decide whether that code is correct, secure, maintainable, and actually worth merging. So here is a simple review workflow I think every developer should practice. 1. Start With the Requirement, Not the Diff Imagine you tell an AI agent: Add password reset support. A few minutes later, it generates the full feature. The code may compile. The UI may work. The tests may even pass. But before reading the implementation, ask: How long should reset tokens remain valid? Can the same token be used twice? What happens if the email does not exist? Should existing sessions be logged out? Are we exposing whether a user account exists? This matters because AI can build the wrong thing very cleanly. So before asking: Does this code work? Ask: Does this solve the correct problem? That one question can save a lot of time. 2. Check the Architecture Before the Syntax AI is usually good at writing a function. It is not always good at understanding where that function belongs inside your system. For example, an agent might create something like: components/ ├── PaymentForm.tsx ├── PaymentAPI.ts ├── StripeService.ts └── Database.ts Everything may technically work. But should database access really live beside your UI components? Probably no

I've been quietly building Antigravity Tools — a collection of 59 free, browser-based developer utilities — and today I'm sharing everything I built and learned. Why vanilla JS? No React, no build step. The main constraint I set for myself: zero dependencies, zero server, zero telemetry . When you paste your JWT token into jwt.io, it goes to their server. When you use an online regex tester, your test strings are logged. I built Antigravity Tools so every operation runs inside your browser, using native APIs. No Node.js backend No npm packages No webpack/vite/parcel No Google Analytics No cookies Everything runs on Web Crypto API , Canvas API , Web Audio API , and IndexedDB — all native to modern browsers. The 8 tool categories 🔐 Security & Auth Tools JWT Inspector — decode JWT header, payload, and check expiry locally RSA & ECC Key Generator — generate 2048-bit key pairs via SubtleCrypto Hash & Password Generator — SHA-256/SHA-512 via Web Crypto PII Masker — strip emails, credit cards, SSNs, IPs from text Universal Encoder/Decoder — Base64, URL, Hex, HTML entities, Unicode 🤖 AI & Prompting Tools AI Token Counter — estimate cost across GPT-4o, Claude 3.5, Gemini 2.0, DeepSeek R1 System Prompt Builder — structure agent instructions with XML tags and tool definitions AI Text Humanizer — rephrase robotic AI output into natural writing Prompt Cost Trimmer — compress prompts by 30–50% to reduce API costs ⚡ Dev & Code Tools JSON Workbench — beautify, validate, convert to TypeScript, Python, Go types cURL Converter — cURL → JS fetch, Python requests, Go, PHP Regex Tester — real-time match highlighting with capture group display Cron Builder — visual cron expression editor with plain-English output Git Command Helper — build undo/squash/cherry-pick commands visually Try it 👉 https://antigravitytools.app

Yash K Saini — Engineer, building in public — AI/ML, low-level (Rust/C/C++), and open source. GitHub...

The choice is usually made by whoever draws the first diagram, and then everybody lives with it for years. It is worth five minutes of thought, and the deciding question is not which tool is best but who will edit this thing next. Short answer. A visual editor such as draw.io for diagrams that non-engineers maintain. Mermaid or PlantUML when the diagram belongs with the code and should be reviewed like code. An attached SVG when the picture comes from a design tool and you need it to look exactly right. A screenshot when the diagram will genuinely never change again. The four options A diagramming app inside Confluence draw.io is the common choice, and it is free for small teams. The diagram is created and edited inside the page, links on shapes work, and anyone who can use a mouse can maintain it. This is the default answer for architecture maps, process flows and floor plans that live in the documentation and get corrected by whoever notices the mistake. The cost is lock-in of a mild kind: the diagram lives in the app's format, and moving to something else later means exporting and redrawing. Mermaid or PlantUML: diagrams as text Here the diagram is source code — a few lines describing nodes and arrows, rendered into a picture. The appeal is real: text goes into version control, diffs are readable, and a diagram can be generated by a script from the system it describes. Two things to know before choosing this. Confluence Cloud does not render Mermaid natively, so you need an app for it, and several of them exist including free ones. And the editing audience narrows sharply: a technical writer will not touch a diagram that has to be edited as syntax, so the diagram becomes the property of the engineers, whether you intended that or not. An SVG made somewhere else The diagram comes from Figma, Illustrator, Inkscape, Visio or an architecture tool, and lands on the page as an attachment. It looks exactly as designed, which is why people do it. The catch is documented

pg_anon found 1 of the 8 personal-data columns in my PostgreSQL database. The one it caught was email , and only because "email" is spelled the same in Spanish and English. The other seven — nombre , apellido , telefono , direccion , fecha_nac , tarjeta_ult4 and rut — walked straight through, unmasked. pg_anon is the open TantorLabs tool that masks personal data in PostgreSQL: it scans the database, flags the sensitive columns, and dumps a masked copy. Like pg_dump , but covering the sensitive parts on the way out. Exactly what you want before handing a colleague a copy of production. So I fed it a Chilean database and watched it miss almost everything — no error, no warning. It finished successfully and handed me a dump with names and national IDs still in cleartext. What the scan actually does Two filters, in order. First it reads each column's name against a set of regexes ( ^email$ , ^phone$ , ^ssn$ …). To the columns left over, it opens the data and tries patterns on the value (an email's @ , a card's 16 digits). Whatever no filter catches passes through. The rules in the demo meta-dict it ships with are written for English schemas. Mine aren't. 1 of 8 Column Holds Stock rules email email ✅ nombre first name ❌ apellido surname ❌ telefono phone ❌ direccion address ❌ fecha_nac birth date ❌ tarjeta_ult4 card digits ❌ rut national ID ❌ email got caught by name (it's an English word) and confirmed by its @ . Everything else has a Spanish name no stock rule looks for. The rut is the clearest miss. A RUT looks like 7917183-2 : seven or eight digits, a dash, and a mod-11 check digit that can be the letter K . The only national-ID rule pg_anon ships with is ssn . It has no idea what a RUT is — and it won't know a cpf (Brazil), dni (Spain, Argentina), curp (Mexico), nif (Portugal) or aadhaar (India) either. If your schema isn't American, the defaults miss your most sensitive column. The fix: a few lines of Spanish You teach it. Column names in your language, plus a conte

A short essay on naming submitted by /u/foobear777 [link] [留言]

Level 300 Some time ago we created a blog showing the capabilities of AI DLC and SDD to create quick and efficient prototypes as a MVP, the results were amazing, however, we omitted something: DevSecOps best practices and CICD for the workload. The prototype was built with a serverless framework and modern cloud-native application patterns. However, moving from a working MVP to a production-ready solution requires stronger alignment with DevSecOps, CI/CD, and operational excellence. That transition leaves several important questions open: Security posture • What security vulnerabilities exist in the solution? • Is the platform ready to withstand common web attacks? Code quality and production readiness • What is the overall quality of the code? • Is this truly an example of an enterprise-ready solution? Cloud compliance and misconfiguration risk • Which cloud security compliance gaps still need to be addressed? • Are there misconfigurations that could create operational or security risk? The other side of this challenge is organizational readiness. Many companies are enabling development teams with assistants such as Kiro, Claude, Cursor, and similar tools. However, without a mature process to review, scan, govern, and manage code at scale, these tools can introduce high costs, expand security risks, and growing technical debt. For the Agentic AI era, DevSecOps maturity is no longer optional. A secure software development lifecycle, policy-driven development, and zero-trust principles must become core operating requirements rather than afterthoughts. Open loop – Starter point a classical DevSecOps CICD system Suppose that the company already has a continuous integration and delivery framework and tools for that kind of workload with classical tools, in terms of maturity level and L3 Defined and Managed here we have Security gates integrated in CI/CD; SAST/SCA/secrets/IaC; centralized findings; quality gates. The maturity model we use We measure against a five-level

submitted by /u/manny2206 [link] [留言]

Building StudySift Without Third-Party Dependencies Introduction What if a useful study tool could be built without installing a single third-party package? For the Zero Dependency Hackathon, I built StudySift , a command-line tool that converts lecture transcripts into structured, revision-friendly study notes. The idea is simple: give StudySift a transcript and automatically extract useful information such as keywords, definitions, examples, and important points. The interesting part was the constraint. The project had to run using Python's standard library only , with no third-party runtime dependencies. The Problem Lecture transcripts can be long and difficult to revise. Important definitions, examples, keywords, and important statements can be spread throughout the transcript. Students often have to manually read the entire transcript, identify important sentences, and create their own notes. I wanted to reduce this manual work. StudySift takes a text transcript as input and processes it into organized notes. The basic workflow is: Lecture Transcript ↓ StudySift ↓ ┌─────────────────┐ │ Definitions │ │ Important Points│ │ Examples │ │ Keywords │ └─────────────────┘ **What I Built** StudySift is a Python command-line tool. The user provides a transcript file: python src/main.py examples/lecture.txt StudySift processes the transcript through several stages: 1. Read the input file 2. Split the text into sentences 3. Extract words 4. Remove common words 5. Count word frequencies 6. Detect definitions 7. Detect examples 8. Identify important sentences 9. Score sentences 10. Sort sentences by importance 11. Generate structured notes The goal is not to pretend that a collection of simple rules is a complete natural-language understanding system. Instead, StudySift is a lightweight and transparent approach to turning transcripts into useful revision material. **The Zero-Dependency Challenge** The biggest constraint was that StudySift could not depend on third-party runt

A cryptography library had a bottleneck no test could see : encrypting half a megabyte took fifty seconds. Every test passed. They had been passing for months. The cause is a trap that keeps recurring: a correct, well-documented optimisation that fixes the constant and not the order — and whose comment, precisely because it is well written, convinces the reader the problem is already solved. What the code did Quipu renders encrypted data as a sequence of symbols. To do that it converts the whole message into a single huge integer and repeatedly divides it to extract digits, the same way you would convert a base-10 number to base 2 by hand. The code did not divide one digit at a time. It carried a sensible optimisation: divide by the largest power of the base that fits in a machine word, extracting nine digits per pass instead of one. The comment explaining it opened by saying that doing it one at a time would be quadratic , and then described the improvement. All true. And the result was still quadratic: extracting nine digits per pass divides the work by nine; it does not change how the work grows. That sentence — "doing it this way would be quadratic" — reads in the past tense, as if it described the previous state. It described the current one. The measurement, which is the only thing that says so Size Time Factor per doubling 64 KiB 0.79 s — 128 KiB 3.16 s ×4.0 256 KiB 12.6 s ×4.0 512 KiB 50.7 s ×4.0 Exactly four, three times running. That is textbook quadratic: every time the input doubles, the time quadruples. Extrapolating, ten megabytes would have cost about five and a half hours . And here is the point: a correctness test sees none of this . A slow algorithm produces exactly the same bytes as a fast one. The suite stayed green, and would have stayed green forever. The fix is two hundred years old Nothing had to be invented. Divide-and-conquer radix conversion is a classical algorithm: instead of peeling digits off one end, you split the number in half — div

The problem I was trying to solve Candidates send hundreds of applications. Companies receive thousands of resumes. Most candidates never hear back. Both sides exhausted. Most of the effort wasted. The insight that changed my thinking: senior engineers don't apply to jobs. They get headhunted. A recruiter finds them, reaches out, and they evaluate the opportunity on their terms. Why is that only available to senior people? It shouldn't be. What I built Wrkmark Jobs — a hiring platform where candidates never apply. Here's how it works: Candidates create one profile Algorithm scores them against active roles Companies see their top 15 ranked matches Companies reach out. Candidates choose to respond. No applications. No cover letters. No ghosting. How the matching algorithm works This is the part I want to talk about technically. The algorithm scores each candidate against each job across four dimensions: Skills — 40% of score Simple exact match (case-insensitive) with a synonym map for common variations: const SKILL_SYNONYMS : Record < string , string [] > = { ' ruby on rails ' : [ ' rails ' , ' ror ' , ' ruby-on-rails ' ], ' kubernetes ' : [ ' k8s ' , ' kube ' ], ' postgresql ' : [ ' postgres ' , ' pg ' , ' psql ' ], ' javascript ' : [ ' js ' , ' es6 ' , ' ecmascript ' ], // 60+ mappings } A candidate with "RoR" on their profile matches a job requiring "Ruby on Rails". Simple but surprisingly effective at this scale. Salary — 25% of score All salaries converted to USD for comparison using live exchange rates (Frankfurter API). The logic: job_max_usd >= candidate_min_usd → score 100 job_max_usd < candidate_min_usd → score 0 If a company offers $80-120K and a candidate expects $30-50K — that's a great match. The company can easily meet the candidate's expectation. Score: 100. The common mistake is calculating range overlap. Overlap fails in the overqualified-offer case. Experience — 20% of score Years of experience vs role requirement. Meeting or exceeding → full score

My thoughts on hate trends against software developers. submitted by /u/ParserXML [link] [留言]

submitted by /u/SunnyKatt [link] [留言]

submitted by /u/der_gopher [link] [留言]

I run seven agents over the same domain. They have never once sent each other a message. That was not the plan. The plan was the thing everybody builds first: a coordinator that hands work between specialists, agents that call each other, a shared conversation they all append to. It worked in the demo and it fell apart the moment the work got real. What replaced it is boring and it has held up: every agent writes claims to one shared record, and nothing else. No agent reads another agent's reasoning. No agent can call another agent. The record is the only channel. Here is why, and what it cost. What breaks in the group-chat design Three things, roughly in the order they hurt. Context grows without bound. If agents converse, every agent needs everyone else's output in its window to participate. Six specialists means each one is reading five other monologues. Your token spend goes quadratic in the number of agents and the marginal agent makes the others measurably worse. Errors laminate. Agent B reads agent A's output as input. If A was confidently wrong, B does not treat it as a claim to be weighed — it treats it as context, which is to say, as true. By the time it reaches F you have a well-reasoned conclusion resting on a hallucinated premise, and nothing in the transcript flags where the floor gave way. You cannot answer "why." Six weeks later someone asks why the system concluded X. The honest answer is "there was a conversation." That is not an answer you can act on, and it is not an answer that survives an auditor. Agents as authors, not as callers The reframe that fixed it: an agent is not a function other agents invoke. An agent is an author with a domain of authority . Each of mine owns a slice of the problem and may only make claims inside it: Agent Domain Claims it may make Verification What is true about the thing today Observed facts, source records, reconciled geometry Design What it should become Plan gaps, code compliance, takeoffs Recovery What can be

I've built enough animated portfolio sites and agency landing pages at this point that I can usually tell within the first three seconds of scrolling whether a site was built by someone who actually understands scroll animation, or someone who just copied a GSAP tutorial and called it a day. And honestly, for a long time, I was the second guy. I remember the first time I tried to recreate one of those Awwwards style hero sections, the ones where text fades and slides as you scroll and everything feels buttery and expensive. I copied the GSAP code almost exactly from a tutorial. Same triggers, same easing, same everything. On my laptop, using my trackpad, it looked incredible. I was proud of it. Then I opened it on my client's Windows machine with a regular mouse, and it looked like it was having a seizure. Stuttering, jumping, completely different animation than what I built. That was the moment I realized the problem was never really the animation. The problem was what the animation was reading from. That thing is scroll. And native browser scroll is honestly kind of a mess. Why native scroll ruins your animations Here's the part nobody explains properly when they show you a GSAP demo. When you scroll a normal webpage, the browser doesn't give you a smooth continuous stream of scroll position. It gives you scroll position in little discrete jumps. How big those jumps are depends on the device, the input method, the browser, even the operating system. A trackpad on a Mac behaves differently than a mouse wheel on Windows, which behaves differently again on a touchscreen. Now think about what ScrollTrigger is actually doing under the hood. It's constantly reading your scroll position and mapping it to animation progress. If the scroll position itself is jumpy and inconsistent, then no matter how well you write your animation code, the output is going to inherit that same jumpiness. You could have the most perfectly tuned easing curve in the world and it still won't ma