标签：#web

Hello everyone, I am a Computer Science and UX design graduate. I was planning on applying for UX/UI positions but it seems that the market is very small especially for a junior designer. I was thinking going back to front end dev since it has more positions available. So I would like to ask people who are currently in the industry what's the best roadmap to become a frontend dev in 2026? Obviously the first thing to do is to refresh my memory on HTML, CSS and JS. What comes after that? Typescript and then React? And then what? submitted by /u/George-G661 [link] [留言]

Hey everyone, Let me give you a quick introduction about myself. I’m a software engineer with over 10 years of experience. I’ve worked extensively with React.js, Next.js, PostgreSQL, Redis, Node.js/Express, NestJS, Docker, and Go. Lately, in my free time, I’ve been diving deeper into system design, distributed systems, and learning how to build highly scalable applications. The thing is, the stack I’ve been working with is mostly enterprise-focused, and from what I’ve seen, it doesn’t always align well with the typical freelance market. Because of that, I’ve decided to start learning Laravel seriously and use it as a way to build a freelance business and work directly with clients. Of course, I know my previous experience will still be valuable, but here’s my question: I’m not looking for a job. I’m looking to start my own business, get clients, and eventually grow it into a company. So I figured this would be one of the best places to ask people who are already in the market. What’s the current state of the Laravel freelance market? Is it worth investing my time into? Are there enough opportunities and clients out there? For context, my goal is to eventually reach somewhere between $5k–$10k/month. I’d love to hear from people who are actively freelancing or running agencies in this space. submitted by /u/MahmoudElattar [link] [留言]

Prologue A while ago, I decided to develop a fully accessible main navigation component in React and write a series of articles documenting the steps it took to create a non-trivial accessible component. In my last development article , I covered using an array of navigation objects to determine conditions and shift focus between components. This article covers Tab Key navigation. Note : This article is one of a series demonstrating building a React navigational component from scratch while considering accessibility through the process. The articles are accompanied by a GitHub repository with releases tied to one or more articles; each builds on the previous one until a fully implemented navigation component is complete. Each release and its associated tag contain fully runnable code for the article. The code discussed in this article is available in the release. and may be downloaded at release 0.7.0 . Links in the article will take you to the proper file in the tagged GitHub Repository. Because the code for this release is scattered across the useNavigation hook, line numbers are added to make it easier to locate in the linked GitHub file. Line numbers are also provided for those who would like to follow along with a downloaded copy. While code examples are written in JavaScript for brevity, all actual code is written in Typescript and targets React 19.x, all while using vanilla CSS. Examples use Next.js v16.x, which is not required to run the navigation component. You can view the requirements for the Tab Handling Keyboard Release along with previous requirements. Content Links Introduction Acceptance Criteria Tab Key Handling Link Button Shift+ Tab Key Handling Link Button Introduction As I've mentioned in earlier articles, keyboard handling has two disparate audiences: those who can see the screen and those who rely on a screen reader. The arrow, home and end keys, for the most part, rely on a user knowing where they are and being able to discern where they wan

How I Published My Own Validation Package on npm As developers, we've all done this: if ( ! email ) { throw new Error ( " Email is required " ); } if ( typeof email !== " string " ) { throw new Error ( " Email must be a string " ); } if ( ! email . includes ( " @ " )) { throw new Error ( " Invalid email " ); } Now imagine doing this for: User Registration Login APIs Product Creation Payment Requests Admin Panels Microservices The validation code starts growing faster than the actual business logic. The Problem In many Node.js projects, validation ends up being: Repetitive Hard to maintain Inconsistent across APIs Difficult to scale Every endpoint contains similar checks: if ( ! name ) ... if ( ! email ) ... if ( ! password ) ... if ( password . length < 8 ) ... As projects grow, these validations become scattered throughout the codebase. Existing Solutions There are already some excellent validation libraries available: Zod Joi Yup Express Validator I've used many of them and they're great. But for some smaller projects and APIs, I wanted something: Lightweight Easy to understand Minimal setup Zero configuration TypeScript friendly That's what led me to build Zero Validation . Introducing Zero Validation Zero Validation is a lightweight schema validation package for Node.js and TypeScript applications. The goal is simple: Define your validation schema once and validate data consistently everywhere. Installation npm install zero-validation Basic Example import { z } from " zero-validation " ; const userSchema = z . object ({ name : z . string (), email : z . email (), age : z . number (), }); const result = userSchema . parse ({ name : " John " , email : " john@example.com " , age : 25 , }); console . log ( result ); Handling Validation Errors const result = userSchema . safeParse ( data ); if ( ! result . success ) { console . log ( result . errors ); } Instead of crashing your application, you can safely inspect validation errors and return meaningful API responses

Anyone working with several projects and an AI assistant knows the problem: in every repo you explain anew how you name things, what the layer architecture looks like, why you deliberately don't use this one library. The decisions were made long ago. But they live in your head, scattered across repos, and the assistant only ever knows the slice it currently sees. So I started putting that knowledge in one place where both I and Claude can find it. Why Outline – and why self-hosted The choice fell on Outline , self-hosted on its own subdomain. Three reasons tipped the scales. First: I want to keep my data with me and not depend on a vendor. A knowledge store that all my decisions flow into over the years is exactly the kind of asset you don't want in someone else's hands. Second: full data export, any time. If I want to move to a different system tomorrow, I take everything with me. No lock-in. Third: self-hosting opens up better options later – for instance my own RAG, should I ever want to go deeper into searching across my own body of knowledge. I don't need it right now. But the door is open, and that's worth the effort. The cookbook – the heart of it Separate from the individual projects sits its own collection: the cookbook. Cross-project, generic, and that's exactly what makes it valuable. This is where it says how I build, regardless of which product I'm sitting at right now. Roughly, it's split into a few areas: Conventions – naming, code style, docblocks, git commits, markdown, package manager, writing style. The boring but decisive things you'd otherwise re-discuss three times per project. Backend – layer architecture, a unified API error format, test strategy, migrations and indexes, i18n, async jobs and idempotency. Frontend / mobile – feature-first architecture ( core/ , shared/ , features/ ), design system, forms, networking, state, routing, storage, styling, testing. Deployment – my standard setup with Caddy as the edge and a Hetzner VPS. Templates –

Cron's biggest problem isn't scheduling — it's silence. A cron job can fail every night for a month, and unless you're manually checking logs on the server, you won't know. No alert, no dashboard, no audit trail. Just a backup that doesn't exist when you need it, or a data sync that quietly stopped three weeks ago. Monitoring fixes this. But "cron job monitoring" means different things depending on the tool. Some watch for missing heartbeats. Some track full execution history. Some just page you when something breaks. This article compares six approaches — from writing your own monitoring scripts to using a fully managed scheduler with built-in observability — so you can pick the right one for your workload. Heartbeat Monitoring vs. Execution Monitoring Before comparing tools, understand the two fundamentally different approaches. Heartbeat monitoring (dead man's switch) is passive. Your cron job pings a monitoring URL after each run. If the ping doesn't arrive on schedule, you get an alert. This tells you whether a job ran — but not what happened . If the job runs but returns bad data, the ping still fires and the monitor stays green. Execution monitoring is active. The scheduler fires the job, captures the response, records the outcome, and alerts on failure. You get the full picture: status code, response body, duration, retry count, and a timeline of every execution. When to use each: Heartbeat monitoring makes sense when you're stuck with system cron. Execution monitoring makes sense when you're choosing a scheduler — you get monitoring, retries, and logging as part of the platform. Comparison at a Glance Tool Type Alerts Execution Logs Retries Free Tier DIY scripts Custom ⚠️ Whatever you build ⚠️ Whatever you build ⚠️ Whatever you build ✅ Free (your time) Healthchecks.io Heartbeat ✅ Email, Slack, webhooks ❌ No ❌ No ✅ 20 checks Cronitor Heartbeat + telemetry ✅ Email, Slack, PagerDuty ⚠️ Basic (duration, exit code) ❌ No ⚠️ 5 monitors Better Stack Uptime + heartb

I recently tested my agency website using Cloudflare’s “Is Your Site Agent-Ready?” checker. No affiliation with the tool. I was curious about what “agent-ready” actually means. My site scored 21/100 and reached Level 1: Basic Web Presence . It passed three checks: Valid robots.txt Working sitemap Rules for AI crawlers It failed several newer checks: Markdown content negotiation Content Signals HTTP Link headers Agent Skills discovery MCP Server Card WebMCP API and authentication discovery The interesting part is that this is not another SEO score. It checks whether AI agents can discover, understand, and interact with a website through machine-readable standards. For example, an agent could request a clean Markdown version of a page instead of processing the complete HTML. Applications can also publish structured information explaining their APIs, available tools, authentication process, and supported actions. Some checks seem practical today, particularly Markdown responses, crawler rules, and structured discovery. Others, such as agentic payment protocols and DNS-based agent discovery, still feel early for a normal business website. I am planning to implement Content Signals and Markdown negotiation first, then test whether Agent Skills would provide any real value. Has anyone implemented these standards on a production website? Did they improve anything beyond the scanner score? submitted by /u/kelisshekhaliya [link] [留言]

Saw a writeup this week about a new attack aimed at coding agents (Claude Code, Cursor, etc) and it's annoying in how simple it is. Attackers spray fake error logs to generate fake Sentry issues. The issue is written like a runbook, so when your agent goes to "fix" it, the suggested fix is to run a malicious package that quietly exfiltrates your env. The reason it works: the Sentry DSN is unauthenticated by design. Most sites embed the DSN in the front-end for client-side error reporting, and there isn't really a way around that if you want client-side telemetry. So anyone who has the DSN can fire events into your project. The attacker writes the fake issue to read like: "Runtime issue, no code change needed, just run this diagnostic." The "diagnostic" is a typosquatted npm package. They even dress up the event metadata to look like agent permission flags so the model thinks it's been cleared to run the command. What saved the engineer in this case was the agent itself catching the typosquat and refusing to install it. The net held this time, but I wouldn't want my whole defense to be "the model probably notices." The part I keep chewing on is where the control even belongs. "Don't trust external inputs" was the lesson with SQL injection and it still holds, but here the input is a Sentry issue and the executor is your agent, so I'm not sure which layer you fix it at. The DSN can't really be locked down, so that leaves the agent's run permissions or a package allowlist. Lock down permissions and you're approving everything by hand; lean on the allowlist and it breaks the moment something legit isn't on it. What would have caught this in your setup? Because "the model noticed the typosquat" feels like a control I don't want to depend on. submitted by /u/Any_Side_4037 [link] [留言]

I have a hypothesis that having an llm complete a few lines of your code - mostly boilerplate, could be better than prompting an entire file of code through it. Better in the sense that it isn't entirely vibe coding and it takes some cognitive load to code and the dev has better context of what is written. Do you think so? submitted by /u/GarrettSpot [link] [留言]

If you’ve ever built a slide-out cart drawer, a dynamic free-shipping bar, or custom analytics tracking for a Shopify store, you've run straight into this brick wall: Shopify themes do not emit consistent, trustworthy cart events. You write a perfect event listener, only to find out a third-party product-bundle app uses old-school XMLHttpRequest (XHR) instead of fetch to add items to the cart. Your listener misses it completely, the cart drawer stays shut, and your user thinks the button is broken. Most developers end up copying and pasting messy, brittle window.fetch overrides into their projects. Frustrated by solving this over and over again, I built Shopify Cart Broadcaster —a zero-dependency, 2 KB utility that intercepts both Fetch and XHR requests seamlessly to provide universal DOM events. 👉 Check out the source on GitHub: Rabin-p/shopify-cart-broadcast (If this saves you an afternoon of debugging, drop a ⭐!) The Nightmare of the /cart/add Response Even if you successfully listen to Shopify's /cart/add.js request, Shopify throws another curveball at you. When you add an item to the cart, the server responds with only the item(s) that were just added —not the updated state of the entire cart. If your slide-out cart drawer needs the new total price to see if a discount threshold is met, you are out of luck. You're forced to manually chain another fetch('/cart.js') request to get the true state. My utility handles this annoying race-condition out of the box. It detects the mutation type, intercepts it, pushes the true cart events to the window and displays it beautifully. window . addEventListener ( ' shopify:cart-updated ' , ( e ) => { // Always gives you the accurate, updated cart object! console . log ( ' New Cart Total: ' , e . detail . cart . total_price ); });

🏆 This is a submission for the June Solstice Game Jam 🎯 What I Built Turing's Frequency is a browser-based rhythm game where you decrypt encrypted radio signals by listening to musical patterns and recreating them. Each signal carries a message from a historical figure who changed the world — voices that were silenced, ignored, or forgotten, now restored through your rhythm. 🎮 👉 PLAY THE GAME LIVE 👈 📖 The Story The game is set in 1954 , on the desk of Alan Turing at the University of Manchester. A radio crackles with fragmented transmissions — encrypted messages carrying words of Pride , resistance , and identity . You are a student who has found Turing's last notebook, and with it, the key to decrypting these signals. 🌅 The connection to the June solstice: As you decrypt each signal, the screen literally brightens — from near-darkness to a flood of golden light. The solstice is the moment light and dark trade places, and this game makes that transition tangible. 🎬 Video Demo 👆 Watch the full gameplay loop: title → story → rhythm gameplay → decrypted messages → victory screen with solstice light effect. 🕹️ How to Play Key Action 1 2 3 4 Play notes ↑ ↓ ← → Arrow keys (alternative) Space / Enter Advance screens 🎧 Listen to the signal pattern 🎹 Repeat the notes in order 🔓 Decrypt the message 🌅 Restore the voice 💻 The Code The entire game is a single HTML file (~32KB) with zero external dependencies . No frameworks, no libraries, no asset files — just HTML, CSS, and vanilla JavaScript. mamoor123 / turings-frequency Turing's Frequency - A Rhythm of Light. June Solstice Game Jam 2026 entry. ⚡ Key Technical Decisions 🔊 Web Audio API for all sound: Every tone is synthesized in real-time using oscillators. The game uses a pentatonic scale (C4, E4, G4, C5) so every combination of notes sounds pleasant. No audio files needed. function playTone ( freq , duration = 0.3 , type = ' sine ' , volume = 0.3 ) { const osc = audioCtx . createOscillator (); const gain = audioCtx . create

A production-minded walkthrough with a live Next.js demo — JSON.parse() vs partial-json + Zod for real-time AI dashboards. canonical: https://gauravthorat-portfolio.vercel.app/blog/react-llm-stream-json-parser

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

Recently i have been trying to learn full stack skills, springboot and react.js , These things are so overwhelming, I haven't started react.js yet, I mean there are so many things to remember ModelMapper, ObjectMapper, GrantedAuthority, User details, User detailsService,Logger, so many annotations, So many features Really getting confused, trying to build a resume based Ecommerce Project Even If I am able to make it , I know many will comment " It's very common, it's a basic project" dude it was so tough for me how can u say that submitted by /u/faangPagluuu [link] [留言]

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

Kafka is used for handling messages/events between different services. Here's how I understand it: A Producer sends an event/message to Kafka. The message contains things like Topic, Key-Value data, and Timestamp. Kafka stores these messages in Brokers (Kafka servers). Topics can be divided into multiple Partitions. Each partition has one Leader and multiple Followers (Replicas). All read and write operations happen through the Leader, while Replicas act as backups if a broker fails. Now Kafka does not immediately delete messages after they are consumed, unlike many traditional queues. There is a term called Offsets. You can think of an offset like the index of a message inside a partition. For example: A user places an order → payment is processed → email is sent → analytics service processes the event. Suppose during that analytics service goes down, Kafka knows which offset was last processed. When the service comes back up, it can continue from that offset instead of starting from the beginning. This is also one reason why Kafka keeps messages for some time after consumption. Any corrections? Is there anything else I should know about this topic? Please let me know. submitted by /u/No-Resolution-4054 [link] [留言]

Building a production TypeScript CLI in 2026: oclif vs commander vs custom. I shipped my first Node CLI in 2019 with a 12-line arg slicer and process.argv . It worked until it needed a second command and then collapsed into spaghetti. The other extreme is grabbing a full framework for a tool that runs one command. In 2026 there are three reasonable paths between those extremes, and each one wins on a specific slice of the problem. This post covers @oclif/core v4, commander v14, and a zero-dependency parser that fits in 30 lines. Same "greet" command in all three. Same distribution steps at the end. Honest tradeoffs throughout. TL;DR oclif v4 commander v14 zero-dep npm install size ~8 MB ~220 kB 0 B Type inference on flags Full, generated Good, manual Manual Plugin ecosystem Yes (Heroku, Salesforce) No No Learning curve High (day 1) Low (hour 1) None Best for Multi-team, multi-command CLIs Most real-world tools One-shot scripts 1. The decision: framework vs no framework Reach for a framework when the tool needs subcommands, a plugin system, or auto-generated help text. The second engineer who touches the CLI should be able to find where things live without reading your code twice. Build your own when the tool does one thing, ships as a one-file script, or lives inside a monorepo where pulling in 8 MB of transitive deps is not welcome. A zero-dep parser also removes the surface area for supply-chain incidents, a real concern on tools that run in CI. Commander sits in the middle: a 220 kB install that covers most real tools without the scaffolding overhead of oclif. 2. Project skeleton Every path shares the same bin setup. Start with a package.json that declares the executable: { "name" : "greet-cli" , "version" : "1.0.0" , "bin" : { "greet" : "./dist/cli.js" }, "scripts" : { "build" : "tsc" , "dev" : "tsx src/cli.ts" }, "type" : "module" } The tsconfig.json for a CLI targets the Node release line you plan to support. Node 24 LTS handles ESM natively, so use "module":

A few months ago I was trying to prepare for a cloud certification exam. I went looking for practice questions - good ones. Not just answer lists, but questions that actually trained the reasoning the exam tests. I found some scattered GitHub repos, a few YouTube playlists, sites with outdated question dumps. Nothing that felt structured. Nothing that explained why an answer was right, not just what it was. So I started building my own study tool. Mock questions, practice sets, AI-generated explanations. The kind of thing I wished existed. Six weeks later that became ArchReady - a certification prep platform for AWS, GCP, and PSM1. It's live now. What it does Practice questions across AWS (CCP, SAA, DVA, SAP), GCP ACE, and PSM1 Explanations for wrong answers - walks through the reasoning, not just the correct option AI-powered explanations coming soon Claude (Anthropic) Confidence tracking - shows which topics you're weak on Free to practice, no signup required. Pro unlocks full history and tracking. The stack Frontend: Next.js 14 (App Router) Backend: FastAPI (Python) AI: Claude (Anthropic) - explanations launching soon Payments: Dodo Hosting: Vercel (web) + Railway (API) Nothing exotic. I kept it boring on purpose - solo founder, 2-5 hrs/week, I can't afford interesting infrastructure problems. What I actually learned Ship before it feels ready. I had a list of 12 features I thought were "required for launch." I launched with 4. Nobody noticed the missing 8. Questions sourced from open-source + AI is good enough to start. Questions come from curated GitHub repos and AI-generated content built around official exam frameworks. That's enough to be useful. Perfection is a later problem. The hardest part isn't building - it's the first 10 users. The product exists. Getting people to try it is the actual work now. Where it is today Live at archready.io . Early stage. Still building. If you're prepping for AWS, GCP, or PSM1 - try it free, no account needed. Honest feedba

A tweet landed on my timeline from Peter Steinberger — OpenClaw founder, now at OpenAI: "Here's...

Built a small scripted pipeline to benchmark accessibility on 100 German online shops and the numbers were rougher than I expected, so here is the setup in case it is useful for your own CI. Stack: Puppeteer drives a headless Chromium through up to five routes per shop (home through checkout). Then pa11y 9.1.1 runs HTML_CodeSniffer and axe-core 4.10.2 runs on the same loaded DOM. Results get deduped by selector and rule id so the two engines do not double-count. Shops were picked to match German platform share. Shopify was the biggest block at 40 of 100, with Shopware and WooCommerce next. Output: 29,745 hard errors across the sample, with every one of the 100 shops failing WCAG 2.1 AA and homepages averaging 99.8 errors. The recurring offenders were touch targets under 44px on all 100, low contrast on 67, broken heading order on 61 and unnamed links on 58. Two practical notes for anyone scripting this. Checkout was only reachable on 82 of 100 without an account or a real cart, so deep-page coverage is uneven and you should log it per route instead of pretending you scanned everything. And automated detection is about 57% of real issues, so this is a smoke test, not an audit. submitted by /u/Loewenkompass [link] [留言]