标签：#webdev

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

I own an unblocked games website that I started roughly 2 years ago at https://boredom arcade.xyz and it's reached over 75000 daily active users. I run ads with Google adsense, but since the website has so many mirror domains I struggle to make the money that I should. I have looked into other advertising networks that allow for mirror domains such as adsterra but they offer low quality ads which isn't what I want. Does anyone know how I could make more money from my website? It currently only pulls in about 250 ish a month from the few domains I have monetized on adsense. submitted by /u/Recent-Background-61 [link] [留言]

🎬 This article is a companion to my YouTube video. Watch it here: Introduction In this video we are going to talk about Redis — what it is, what it does, and why it is an important part of my back-end stack. What is Redis? Redis is a free, open-source, in-memory data store. Unlike PostgreSQL which stores data on disk, Redis stores data entirely in memory — in RAM. This makes it extremely fast. Redis can handle millions of operations per second with sub-millisecond response times. Redis is most commonly used as a cache, a session store, a message broker, and a real-time data store. What is Caching? When your application queries a database, that query takes time — it reads from disk, processes the query, and returns the result. If the same query is made thousands of times per second, you are hitting the database thousands of times unnecessarily. Caching solves this by storing the result of a query in memory. The first request hits the database and the result is stored in Redis. Every subsequent request gets the result from Redis — which is in memory and therefore much faster — instead of hitting the database again. Think of it like a shortcut. Instead of driving the long route to the database every time, you take the shortcut through Redis. What Does Redis Do? Caching Store frequently accessed data in memory for fast retrieval. Database query results, API responses, computed values — anything that is expensive to compute and accessed frequently is a good candidate for caching. Session Storage Store user session data in Redis instead of the database. Since sessions are read on every request, having them in memory is significantly faster than a database lookup. Rate Limiting Track how many requests a user or IP address has made in a given time window. Redis's atomic increment operations make it perfect for implementing rate limiting. Message Queues and Pub/Sub Redis supports publish/subscribe messaging and message queues. Applications can publish messages to a channel a

TLDR tsc is the TypeScript compiler. It turns your .ts files into .js files that Node.js and browsers can run. Install it with npm install -g typescript . Run tsc to compile your whole project. Run tsc --watch to auto-compile on every file save. Run tsc --noEmit to check for errors without creating any files. What is the TypeScript Compiler? The TypeScript compiler is a tool called tsc . It reads your TypeScript files and turns them into JavaScript files. Your browser and Node.js cannot run TypeScript directly. They only understand JavaScript. So tsc acts as the bridge between what you write and what actually runs. Think of tsc like a spell checker for your code. It finds problems before your code ever runs. Then it produces clean JavaScript output for you. How to Install the TypeScript Compiler You install tsc using npm. There are two ways to do this. Option 1: Global Install (runs anywhere on your computer) npm install -g typescript After install, check it works: tsc --version You will see something like Version 6.0.3 . Option 2: Local Install (recommended for teams) npm install --save-dev typescript Then run it using npx : npx tsc --version Which one should you use? Use a local install for project work. This makes sure everyone on your team uses the same TypeScript version. Use a global install only for quick personal experiments. How to Compile a Single TypeScript File The simplest way to use tsc is to pass it a single file. Create a file called hello.ts : const message : string = " Hello, TypeScript! " ; console . log ( message ); Now compile it: tsc hello.ts This creates a new file called hello.js in the same folder: var message = " Hello, TypeScript! " ; console . log ( message ); Notice that TypeScript removed the : string type annotation. The output is plain JavaScript that Node.js can run. Run the output file: node hello.js # Hello, TypeScript! Important: When you pass a file directly to tsc , it ignores your tsconfig.json . It uses its own default setting

Last week I shipped something that would have sounded reckless two years ago: an MCP server that lets an AI agent write to a merchant's live Shopify store. Create discount codes. Build customer segments. Draft WhatsApp campaigns against real order data. Read-only agent integrations are everywhere now, and they're fine — but a read-only agent is just a chatbot wearing a dashboard. The useful version is the one that does the thing . The dangerous version is also the one that does the thing. A hallucinated SELECT is a wrong answer; a hallucinated discount code is free product going out the door. So before turning writes on, I sat down and listed every way an agent could hurt a store. Then I built one guardrail per failure mode. Here's the list — it's short, and I think it generalizes to any agent surface that touches business data. 1. Read-only by default. Writes are a per-token opt-in. The lazy design is one API key that can do everything the app can do. Instead, every agent token starts read-only — list customers, inspect segments, read campaign stats. Write capability is a separate flag the merchant flips per token: { "token" : "fav_mcp_…" , "scopes" : [ "read" ], // default "writeEnabled" : false // explicit opt-in , per token } This sounds obvious. It is obvious. It's also the single most-skipped step I see in agent integrations, because it's friction during development. Build the friction in anyway — "the agent could read everything but couldn't have sent that" is a sentence you really want available to you later. 2. Caps live in the tool schema, not the prompt. Early on I had a system prompt that said something like "never create discounts above 30%." You can guess how durable that is. Prompts are suggestions; schemas are physics. So the caps moved into the tool's input validation itself — the shape of it: // create_discount — validated server-side, not prompt-side { percentage : z . number (). min ( 1 ). max ( 100 ), // hard ceiling, enforced in the service exp

In times when people believe that "AI can code a website in 2 days" (see: how to leverage AI as a...

I got some time to kill and honestly I'm just itching to solve a problem nobody gives a shit about cause there is no real money in it. IE social impact rather than financial , maybe something that helps charity and non profits, or a hobby that wishes it had a tool to make life easier but wouldn't actually pay for, etc etc submitted by /u/AssistanceAshamed609 [link] [留言]

I’m building GoWDK , a Svelte-inspired web framework for Go. Honestly, I’m starting to wonder if I’m wasting my time. I like Go, but web development in Go still feels too verbose when you want modern component-based apps. Most options either feel too backend-only, too manual, or they push you back into JavaScript-heavy stacks. So I started building GoWDK to test a different path: Go components server-side rendering simple syntax minimal JS Go-native tooling compiler-driven DX The frustrating part is that building a framework is a lot of work, and I’m not sure if Go developers actually want this kind of thing So I’m asking honestly: Would a Svelte-like framework for Go be useful to you, or am I solving a problem most Go devs don’t care about? Repo: https://github.com/cssbruno/GoWDK submitted by /u/OkSeesaw7030 [link] [留言]

I am Brazilian and I have been working in tech for 12 years, but right now I feel like the dumbest person on earth. A guy named Damian Gutierrez from a company called Ritual ( https://www.linkedin.com/company/ritualnet/ ) reached out to me on LinkedIn about a Senior Backend Engineer position paying $180k USD. During the interview, I was so focused on performing well that I almost got scammed. They asked me to clone their repository onto my machine and run it with npm start . Yeah, I know. I already feel stupid enough, no need to remind me. At the time, something felt off, but the salary clouded my judgment. After I launched the application, they asked me to connect my crypto wallet (MetaMask) to it. That's when things started feeling really suspicious. Luckily, I didn't have MetaMask installed on the machine I was using for the interview. I worked with crypto back in 2022, and connecting a wallet is pretty common in DeFi applications, so I wasn't immediately alarmed. They told me, "No problem, let's continue on Monday when you're on a machine that has MetaMask installed." Afterward, I ran the repository through Claude, and it flagged the project as malware. Even after hunting through cron jobs, startup tasks, and everything else I could think of, I decided to wipe and reinstall my entire system. That thing was executing remote code on my machine. Honestly, I feel like an idiot. But more importantly, I want to warn others that this kind of scam exists in our industry. These people looked completely legitimate. Well-dressed Americans, interviewing from a fancy office, professional setup, polished communication. The whole thing looked real. It wasn't. I'll post in the comments what Claude found in the repository. The company is called Ritual, and as far as I can tell, all of their job openings are fake: https://docs.google.com/document/d/1Q3GyiZmgbBOQoGSP_N0SoDsl7e6fgFTdoxzxnreigvQ/edit?tab=t.0 The recruiter who contacted me: https://www.linkedin.com/in/damian-gutierre

Something changed in software engineering, and I do not think we have fully named it yet. For years, the job was mostly about writing code directly. Then autocomplete got better. Then chat-based coding assistants arrived. Now the workflow is shifting again: we describe goals, hand off chunks of work to agents, inspect their output, tighten the tests, and decide what gets merged. That is not the same job with a faster keyboard. It is a different shape of work. I would call it agentic engineering. The engineer is becoming a director Agentic engineering does not mean the engineer disappears. If anything, it makes the engineer's judgment more visible. A coding agent can read files, make changes, run commands, open pull requests, and iterate through errors. GitHub describes Copilot agent mode as a workflow where the agent can plan, edit, run terminal commands, and keep working until a task is complete. Google describes Jules as an asynchronous coding agent that can take a task, work in a virtual machine, and produce a pull request. Anthropic's Claude Code guidance talks openly about using multiple Claude sessions in parallel, giving agents clear context, and treating them like workers that need direction. That is the shift. The engineer is no longer only the person typing every line. The engineer is also the person deciding what should be built, what constraints matter, how to verify the result, and when the agent is wrong. Prompting is too small a word for this People often describe this work as prompting, but that undersells it. A prompt can be a single instruction. Agentic engineering is more like delegation. You define the task, provide the relevant context, set the boundaries, create checks, review the work, and decide the next move. If the agent goes in the wrong direction, the failure is not always the model's fault. Sometimes the task was too vague. Sometimes the repository had no tests. Sometimes the acceptance criteria lived only in someone's head. This is why

Would you treat a serious illness without seeing a doctor, relying only on whatever your favorite AI...

Have you ever stared at two different medicine boxes, squinting at the tiny font of the active ingredients, wondering: "Can I actually take these together?" Modern healthcare is complex, and drug-drug interactions (DDI) are a leading cause of avoidable ER visits. In this tutorial, we’re going to leverage GPT-4o Vision , React Native , and the FDA OpenData API to build a "Drug Conflict Scanner." We will utilize multimodal AI to transform messy pill-box photos into structured data and cross-reference them against official medical databases for safety. By the end of this guide, you'll master GPT-4o OCR structuring and automated knowledge graph verification for real-world health tech applications. 🚀 The Architecture 🏗️ The logic flow involves capturing images of multiple medicine labels, using GPT-4o's multimodal capabilities to extract chemical compounds, and then querying the FDA's database for potential interactions. graph TD A[React Native App] -->|Capture Multi-Photo| B[Node.js Backend] B -->|Image Buffer| C[GPT-4o Vision API] C -->|Structured JSON: Ingredients| B B -->|Search Interactions| D[FDA OpenData API] D -->|Drug Labels & Warnings| B B -->|Safety Report| A A -->|UI Alert| E{Safe or Warning?} Prerequisites 🛠️ To follow along, you'll need: GPT-4o API Key (via OpenAI) Node.js (for our backend relay) React Native (Expo is recommended for camera access) An account at open.fda.gov (though the public API works for limited requests) Step 1: Extracting Ingredients with GPT-4o Vision Traditional OCR struggles with curved medicine bottles and shiny packaging. GPT-4o excels here because it understands context. We don't just want text; we want the Generic Name of the drug. The Backend Logic (Node.js) // backend/scanner.js import OpenAI from " openai " ; const openai = new OpenAI ({ apiKey : process . env . OPENAI_API_KEY }); async function analyzeMedicineLabels ( imageUrls ) { const response = await openai . chat . completions . create ({ model : " gpt-4o " , messages :

I think it's fair to say that someone who has never done non-AI web development will always be vibe-coding. For, say, an experienced (20+ years) developer, would it still be vibe coding if they craft technically sound prompts (i.e. explicitly mention things to avoid/include, and define methodologies and algorithms as well as goals), and fully test (and have AI fix) the output, but never review the actual code? What if the prompts are loose, but they are fastidious about reviewing all code generated? submitted by /u/lindymad [link] [留言]

I've been with Omnis for years (they were awesome) and they were bought out by JetHost. The transfer took down a bunch of clients. Now I'm arguing with them and they don't offer an online guarantee or a refund. I have to deal with clients whose websites were down. I'm really upset just because I have never had to worry about this. Anybody have cheap reliable registrars? My fave never showed in google, so I figured I'd axe the community if anyone has a good secret one in your pocket submitted by /u/dash-dash-hyphen [link] [留言]

Hi! I'm in the process of teaching myself HTML and CSS for the very first time. I have a general idea of what I want this website to be and how to structure it. For actual secure access, I am making it on Neocities. For general browsing on the other hand, I want to essentially make a snapshot of whatever the current build of it is and put it on an http as well with the intent of being able to see and browse said website on old hardware like a Dreamcast or Win98 machine. Any help is appreciated! submitted by /u/souls_wandering [link] [留言]

A few months ago I was doing a final pre-release review on a client project before handing it...

I built a portfolio site that ended up turning into a collection of interactive experiments rather than a traditional resume. > Main Page > Drawing > Text based game > Capture the flag (CTF) It includes: - a live collaborative pixel canvas where visitors draw together - a hidden terminal with a virtual filesystem - small hidden challenges scattered throughout the site - an AI assistant you can talk to It started as a portfolio, but became more of an interactive playground. submitted by /u/Another_bot_beepboop [link] [留言]

If your goal is faster releases with fewer flaky failures, the tool choice matters less than the testing strategy behind it. Teams usually start by asking, “Should we use Playwright, Selenium, Cypress, or a cloud platform?” A better question is, “What do we need to prove, in which browsers, at what cost to maintainability and reliability?” That shift changes the conversation. Browser automation is not only about writing scripts that click through a happy path. It is about building a test system that survives UI changes, covers the browsers your users actually have, and fails for the right reasons. This playbook walks through a practical sequence you can use to compare tools and make those tradeoffs explicit. Start with the outcomes, not the framework Before comparing tools, define the job your browser tests need to do. Most teams have a mix of goals, even if they do not write them down: Catch broken critical flows before merge Verify rendering in real browsers, not just headless simulations Keep test code readable enough that the team can maintain it Reduce flaky failures that waste review time and erode trust Avoid spending more time on infrastructure than on product quality Once you name those goals, tool comparison becomes simpler. A fast local developer feedback loop may point you toward one choice, while broad cross-browser coverage and managed execution may point you toward another. If a tool is fast but makes maintenance painful, that is not a win. If it supports many browsers but creates unstable runs, that is also not a win. Map your browser reality first The second step is to compare your user base with your test environment. Teams often say they support “all major browsers,” but the actual risk is usually narrower. Check which browser and device combinations matter for your product, then decide what needs automated coverage versus manual spot checks. This is where real browser execution becomes important. A headless run can be useful, but it does not repl

Building a URL shortener with Cursor, ChatGPT, AWS Lambda, API Gateway, and Cloudflare taught me more about shipping software than writing code. Since last year, Cursor has been my go-to development assistant for daily tasks. But at the beginning of this year, just using it to generate snippets didn't feel like enough anymore. Having studied programming since 2011, I knew what modern AI tools could do, but I wanted to test their limits. I decided to build a full project—a URL shortener—without writing a single line of frontend or backend code myself. For the stack, I chose Node.js with TypeScript, React with Vite, and AWS Lambda to handle redirects. While I used ChatGPT to debate architectural trade-offs, Cursor generated the entire codebase. Watching a functional application take shape so quickly was the exact moment a line was crossed for me. It made me realize how fundamentally software development is shifting: our role is evolving from code writers to architectural decision-makers and problem-solvers. But truth be told, this project and this post represent a massive personal milestone. Like many developers, I have a graveyard of half-finished projects on my machine. This is one of the first times I've pushed a personal project all the way to production. Writing this and exposing my work to the community is a huge first step for me. This isn't just a story about code or AI—it's about the challenge of finally shipping something. The Stack Before asking Cursor to write a single line of code, I wanted to map out the architecture. I didn't need a massive enterprise system for a URL shortener, but I did want something flexible enough to support future features and experiments. To validate my ideas, I used ChatGPT to debate the pros and cons of different architectural approaches. We eventually settled on this stack: Backend: Node.js + TypeScript Frontend: React + Vite Database: MongoDB Atlas Redirects: AWS Lambda Entry Point: AWS API Gateway DNS / CDN: Cloudflare Secur

I’m building a website that will eventually become a collection of useful browser-based tools, similar to iLovePDF but covering many different categories. The goal is simple: No downloads No accounts Fast and mobile-friendly Free to use I’m researching what people actually need before building more tools. What’s a small utility, calculator, converter, formatter, generator, or productivity tool you use regularly but wish had a better version? Examples: Land measurement calculators PDF tools Text formatting tools Developer utilities SEO tools Study tools I’d love to hear your ideas and pain points. submitted by /u/Nikpa_2163 [link] [留言]