标签：#web

Stanford Just Published Rules for AI Coding Agents — What Devs Should Know Stanford dropped a document last week that every developer using AI coding tools should read. It's called CLAUDE.md , it's part of CS336 (Language Modeling from Scratch), and it's a brutally honest set of rules for how AI agents should — and shouldn't — help students write code. The document hit #1 on Hacker News for good reason. It doesn't just apply to students. If you use Claude Code, Cursor, Copilot, or any AI coding assistant, these rules expose the uncomfortable gap between what these tools can do and what they should do. GitHub just rolled out token-based billing for Copilot, and developers are furious. The tension is the same: when does AI assistance stop helping and start hurting? The Core Principle: Teaching Assistant, Not Solution Generator Stanford's position is unambiguous: "AI agents should function as teaching aids that help students learn through explanation, guidance, and feedback — not by completing assignments for them." This isn't academic hand-wringing. It's a design constraint that maps directly to professional development. The same agent that writes your PR in 30 seconds is also the one that leaves you unable to debug it when it breaks at 2 AM. The AI agent role framework from Stanford's CS336 guidelines: teaching assistant vs solution generator The document draws a hard line: What agents SHOULD do: Explain concepts by guiding toward understanding Review your code and point out areas for improvement Ask guiding questions instead of giving fixes Reference documentation, lectures, and debugging tools Suggest sanity checks, assertions, and profiler investigations What agents SHOULD NOT do: Write any Python or pseudocode Complete TODO sections in assignments Give solutions to problems Edit code in the student repo Convert requirements directly into working code Point to third-party implementations If you're a professional developer, the "SHOULD NOT" list probably looks extr

Stuck on Meta App Review and hoping someone here has cracked it. Setup: Instagram API with Instagram Login (graph.instagram.com, v25.0), Instagram User token (IGAA...), BUSINESS account. Trying to get Advanced Access for instagram_business_manage_comments. The blocker: the "make 1 successful API call" requirement stays at "0 of 1 API call(s)" for days (past Meta's 2-day logging window), so the Request Advanced Access button stays grayed out. What I've confirmed: - The token DOES hold the scope (granted permissions list includes it). - GET /{media-id}/comments?fields=id,username,timestamp returns HTTP 200. - Rate-limit usage increases per call, so the calls are landing. - It's not the endpoint: I also tried creating a comment + replying (POST /{media-id}/comments, POST /{comment-id}/replies) — all 200, none registered. On the SAME token/path, instagram_business_manage_messages registered fine (its requirement is complete) even though ITS call (GET /me/conversations) also returns an empty array (200, "data":[]). So an empty 200 counted for manage_messages but the comments call never counts for manage_comments — looks like a tracking bug specific to the manage_comments counter. Question: has anyone gotten instagram_business_manage_comments to flip 0 -> 1 on the Instagram-Login path? What exact call/step did it, or did Meta credit it via a Platform Bug Report? Anything that worked would save me. submitted by /u/Traditional-Lake3525 [link] [留言]

Frontend automation has been getting pretty wild lately. 🫠 A few months ago, this comparison would...

I've been building out embedded reporting for b2b clients (i use next.js), and as our user base grows, the P95 latency is becoming a nightmare. Every time a user changes a date filter, it triggers a fresh compute spin-up on the warehouse. I’m currently refactoring the stack to put a universal semantic layer (in my case, cube core) between the frontend and the database. and the goal is to move all the logic, like multi-tenant row-level security (RLS) and complex joins, out of the React code itself and into a declarative modeling layer since I started, the biggest win (so far) is using pre-aggregations. now, instead of hitting raw tables, the API hits a warmed caching tier which is in the 'cubestore'. it feels more like querying a structured API than a database for those of you here who do high-concurrency analytics in SaaS, a question! are you just throwing more money at warehouse compute, are you moving toward this kind of decoupled architecture, what other best practices do you have? now trying to figure out if I should stick with this or just move everything to a huge ClickHouse instance and hope for the best submitted by /u/sivyh [link] [留言]

Inspiration Build a simple and modular technical documentation and blog. Build the website without using node/npm or any external frameworks(CSS, JS, icon, font). Only GoHugo normal binary + pageFind binary needed. Features [x] Responsive and adaptive layouts. [x] Support for light and dark modes. [x] Support for multiple documentation sets. [x] Support for a blog. [x] Implement a menu via Hugo configs. [x] Customizable sidebars using Hugo data templates. [x] Plug-and-play/ repeatable home page blocks using separate partials/ css/ data templates. [x] Integrate a search via Pagefind. [x] Inline SVG icons based on Google's Material Symbols GitHub Repo: https://github.com/dumindu/E25DX Example Docs: https://github.com/dumindu/E25DX/tree/gh-pages/example Example Live: https://dumindu.github.io/E25DX/ submitted by /u/dumindunuwan [link] [留言]

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

Security is not a feature you bolt on after launch. It is not the CISO's problem alone. It is not a checklist you run through before a compliance audit. It is a shared responsibility across every engineer, every team, every layer of the stack. This guide walks through the three layers where most web vulnerabilities live — Frontend , In Transit , and Backend — using a threat modeling lens: thinking like an attacker so you can build like a defender. What Is Threat Modeling? Before writing a single line of defensive code, you need to think systematically about your system's attack surface. Threat modeling is the process of: Identifying entry points — Where does untrusted data enter your system? Form inputs, URL parameters, uploaded files, third-party APIs? Assessing potential impact — If this entry point is exploited, what can an attacker access or do? Designing defenses proactively — Before the exploit occurs, not after. It shifts your mindset from "let's hope nothing breaks" to "let's assume something will be tried." Part 1 — Frontend Security: Stopping XSS What Is XSS? Cross-Site Scripting (XSS) happens when untrusted data is rendered as executable code in a browser. An attacker injects a script; your application runs it on behalf of your users. The consequences are severe: session hijacking, credential theft, defacement, redirects to malicious sites. There are three flavours: ┌─────────────────────────────────────────────────────────────────┐ │ XSS TYPES │ ├──────────────────┬──────────────────────────────────────────────┤ │ Stored XSS │ Malicious script saved in your DB, │ │ │ served to every user who loads that data. │ │ │ Most dangerous — persistent and broad. │ ├──────────────────┼──────────────────────────────────────────────┤ │ Reflected XSS │ Script lives in a URL parameter. │ │ │ Requires tricking the user into clicking │ │ │ a crafted link. Temporary, per-request. │ ├──────────────────┼──────────────────────────────────────────────┤ │ DOM-Based XSS │ Entir

Google has released a new CLI for Google Workspace, offering a unified interface for various services like Drive, Gmail, and Calendar. Built in Rust, the tool dynamically adjusts to API changes and features over 100 bundled skills. It requires Node.js and a Google Cloud project for setup. Initial community feedback is mixed, highlighting both its dynamic capabilities and setup challenges. By Daniel Curtis

“Did We Already Watch This?” — Building KindaSeen with FastAPI and Next.js A few months ago, my friends and I kept running into the same question whenever we talked about movies, dramas, anime, or variety shows: “Did we already watch this before?” Sometimes we remembered the title but forgot whether we had finished it. Other times, we completely forgot we had already seen it at all. That simple problem inspired me to build KindaSeen, a full-stack personal media repository designed to help users track and organize the media they’ve consumed in one centralized platform. The goal of the project was not only to create a useful application, but also to gain hands-on experience building a real-world full-stack system with modern web technologies. What KindaSeen Currently Supports User authentication with Supabase CRUD operations for personal media records TMDB-powered search functionality Watchlist system Favorites system Persistent PostgreSQL storage Dockerized backend deployment Separate frontend/backend deployment workflow Tech Stack Frontend Next.js React Tailwind CSS Shadcn/ui Vercel deployment Backend FastAPI PostgreSQL Docker Render deployment External Services Supabase Authentication TMDB API integration One of the main goals of this project was to simulate a more realistic production workflow by using a decoupled frontend/backend architecture instead of building everything inside a single monolithic application. In this article, I’ll share: Why I chose this architecture How I integrated TMDB into the application Challenges I faced during deployment What I Learned From Building KindaSeen Why I Chose This Architecture Instead of building a monolith using Next.js API routes, I decided to decouple the application into a Next.js frontend and a FastAPI backend. This decision was driven by three main factors: AI Compatibility & Future Proofing : While researching the job market, I noticed that most companies building AI products heavily rely on Python. By choosing FastA

We talk about pagination as if it's purely a backend concern – the database does the heavy lifting, the API returns pages, and the frontend just renders them. But in 2026, that mental model is outdated. The frontend now owns more of the data-fetching lifecycle than ever: server components prefetch, client caches hydrate, optimistic updates mutate, and streaming responses trickle in chunk by chunk. The choice between cursor pagination and offset pagination has real consequences for how you write your React components, how your cache behaves, how scroll feels on the phone, and what happens when a user navigates back. This post is about those tradeoffs – from the frontend seat. The Landscape Has Changed A few things are different in 2026 that make this conversation more nuanced than it was three or four years ago: React Server Components are mainstream. Data fetching happens on the server in many apps, which shifts where pagination state lives and how navigation works. TanStack Query is the de-facto standard for client-side async state, with first-class infinite query support baked in. The "infinite scroll vs pagination" debate is mostly settled — infinite scroll wins for feeds and content-heavy apps; numbered pages win for dense data tables. Your pagination strategy should serve that decision, not fight it. LLM-powered search and filtering are becoming common, and those use cases have their own quirks around pagination stability. Edge caching and CDN-level pagination mean that certain offset-paginated responses can be cached by URL – a genuine advantage offset still holds. What Frontend Engineers Actually Care About When you strip away the SQL theory, here's what the pagination choice actually affects on the frontend: 1. Cache Key Design With offset pagination, the cache key is simple and predictable: posts?page=3&limit=20 . Every page is independently cacheable by URL — your CDN loves this. TanStack Query, SWR, and Apollo all handle this naturally. // Offset — clean,

You know that, right? The mobile web is completely unusable. Its garbage and it is garbage because you can't say "no" to stupid advertisers and keep putting more and more stupid popovers and sneaky links, and animations, and content obscuring crap, often not bothering to put the close box within the bounds of the screen. If you work on a mobile version of a website - shame on you. It doesn't work. I'm not kidding. I probably visited, and immediately noped out via the back button because it is just more trouble than the crappy click bait title implies it might be worth. RIP mobile web. submitted by /u/Small_Dog_8699 [link] [留言]

Ever received a WebSocket tick stream for US stocks and wondered why your indicators behave oddly outside regular hours? The raw data doesn’t tell you which session a trade belongs to, but identifying the session is crucial for signal quality. Here’s a clean, no-dependency-heavy way to do it in Python. Quick Session Reference Session US Eastern Time Data Characteristics Pre-market 04:00-09:30 Sparse trades, choppy moves Regular hours 09:30-16:00 Dense liquidity, smooth price action After-hours 16:00-20:00 Volatility often triggered by news Method 1: Timestamp Conversion Almost every API sends a UTC timestamp. Convert it to US/Eastern and classify. from datetime import datetime import pytz # US Eastern timezone et = pytz . timezone ( ' US/Eastern ' ) def get_session ( ts ): t = datetime . fromtimestamp ( ts , et ) # Check pre-market window if t . hour < 9 or ( t . hour == 9 and t . minute < 30 ): return " pre " # Regular session if t . hour < 16 : return " regular " # After-hours return " after " Method 2: Use a Session Status Field If your provider sends a field like sessionType , you can skip the timezone math. Just make sure to test edge cases at session boundaries. Live Integration Example Using a WebSocket feed (like AllTick’s market data stream) that includes a timestamp, I label ticks on the fly. import websocket import json from datetime import datetime import pytz # US Eastern timezone et = pytz . timezone ( ' US/Eastern ' ) def session ( ts ): t = datetime . fromtimestamp ( ts , et ) if t . hour < 9 or ( t . hour == 9 and t . minute < 30 ): return " pre " elif t . hour < 16 : return " regular " else : return " after " def on_message ( ws , message ): data = json . loads ( message ) s = session ( data [ " timestamp " ]) print ( f " { data [ ' symbol ' ] } | { s } | { data [ ' price ' ] } | { data [ ' volume ' ] } " ) # Open WebSocket connection ws = websocket . WebSocketApp ( " wss://ws.alltick.co/stock " , on_message = on_message ) ws . run_forever () Effic

Back in February, a friend asked me to join his hackathon team. My first reaction wasn't excitement. It was: "Can I even contribute anything?" I remember repeatedly telling him not to add dead weight to the team and to find someone better. He kept insisting that it didn't matter and that I should just join. The funny thing is, I still don't think I've done anything extraordinary since then. No big startup. No crazy achievement. No overnight success story. Mostly just hundreds of hours of learning, building random things, breaking them, fixing them, and realizing how much I still don't know. But today I caught myself doing something weird. I'm the one thinking about who to bring into a team. And for the first time, I don't immediately feel like I'd be dead weight. Not because I know everything now. Just because I've reached the point where I can look at a problem and genuinely believe that, given enough time, I'll figure out how to contribute. It's a small shift, but it feels important. A few months ago I was wondering if I belonged on a team at all. Today I'm wondering who should be on mine. 👀

I read a lot of PDFs at night, especially on my phone. And honestly, PDFs are not great for that. Most of them still feel like digital paper: white background, fixed layout, and tiny text. Dark mode helps a bit, but many tools only change the page color. The bigger problem for me was mobile reading. When the text is too small, I have to pinch zoom, move the page left and right, zoom out again, then repeat the same thing on the next paragraph. After doing that too many times, I thought: Why can’t I just read the PDF text like an article? So I built a small free tool: PDF Dark Mode It has two reading modes. Page color mode This keeps the original PDF layout, but makes the page darker and easier to read at night. I use this for scanned PDFs, tables, image-heavy documents, or files where the original layout matters. Text reading mode For selectable PDFs, the tool can extract the text and show it in a cleaner reading view. You can adjust the font size, line height, font family, and theme. This is the part I personally wanted most, because it makes mobile reading much more comfortable. Instead of constantly pinch-zooming a fixed PDF page, the PDF starts to feel more like a normal article. Privacy The tool runs locally in the browser. Your PDF is not uploaded to a server, and refreshing the page clears the current session. Try it You can try it here: PDF Dark Mode I built it for my own night reading, but I’d love to hear feedback from anyone who reads PDFs on mobile. Also, if you ever need to convert a dark PDF back to a light version, I made a related tool for that too: PDF Light Mode

I am considering switching from Contentful to a different headless CMS platform and I have noticed that a lot of them are self hosted. It seems like Sanity, Prismic, and Strapi all require you to create a project locally, then (at least in the case of Sanity) deploy the project for editors to use. Is this something people want? Maybe I haven't used it enough, but I don't really see the point of doing it this way. I have created a Sanity project locally and it seems I can't even edit the Studio dashboard, I can just define my types there and deploy. Why would the CMS provider not just host the UI (that they built anyway) themselves? submitted by /u/darkshadowtrail [link] [留言]

I need to share my misery with someone. Hope you get a laugh out of this. About a year ago, I built a web app for a client. Let's call her Karen. She loved the UI; she loved the functionality - every meeting was a joy. She was shit-kickin happy. I have 10 months of emails from her saying stuff like "it's like you're in my head! You get it exactly!" She even paid me extra for new functionality that she came up with halfway through. Then, after I had delivered everything she asked for (and signed off on), I demonstrated the finished app to her and her staff, and I thought it went well. I kept asking her when she wanted to launch it - crickets. Then she called me two weeks later, saying that one of her employees was still using her old system and asking Karen why. Apparently, the employee said that what we built didn't meet her needs... no details. So then Karen lays into me and says that what I built her is worthless and we need to start over. This is just out of the blue; absolutely no complaints until then. She was literally screaming on the phone. My wife heard this because I put her on speakerphone. I told Karen, " Hey, I'm sorry, but you have never said you weren't happy or that anything was wrong. I can't start over. I have to pay my staff to start over. If we did something wrong, I would cover the cost - but I built what you asked for, and I have many emails and Zoom calls recorded where you were happy." Then I don't hear from her for about four months, and she sent me this nasty-ass email saying that I screwed her over, used templates off the web (not true), and she wanted $45k in compensation (more than she paid) - or - make up for it by redesigning her Claude designs for her other stuff. "I did it on the weekend in 2 hours, I don't know why you developers charge so much!" She would never win a lawsuit. I forwarded everything to my attorney - and he laughed. He said, "No way she can build a case. But try to settle with her and do what she asks; it's not worth

I recently built Letras Diferentes , a free Unicode text-styling tool for people who want creative copy-paste fonts for bios, nicknames, social posts and gaming profiles. The idea is simple: Type normal text Preview different Unicode styles Copy the result in one click Use it on Instagram, WhatsApp, TikTok, Free Fire, Discord or social posts The project is especially focused on Portuguese-speaking users, but the tool works with general Latin text too. Main project: One thing I’m learning while building it is that Unicode text tools are not just about “fonts”. They are about UX, compatibility, mobile performance, copy buttons, favorites, categories and making the result easy to use on real platforms. I’m still improving the interface, categories and mobile experience. Feedback is welcome.

I've been doing frontend development for a little over a year. Mostly personal projects, a few freelance jobs for friends, nothing huge. Recently someone reached out through a mutual contact and asked if I could build a website for their business. At first I assumed it would be a simple brochure site, but after our call it sounds like they want something a bit more custom. The site itself doesn't sound overly complicated, but they have a bunch of specific requirements that don't really fit into an off-the-shelf template. The deadline is around two weeks. Part of me thinks this is exactly the kind of project I need if I want to improve and start taking on more freelance work. The other part of me is looking at the timeline and thinking there's a good chance I'm being way too optimistic. For those of you who freelance or run your own projects, how do you figure out whether a client request is genuinely manageable or whether you're setting yourself up for a stressful couple of weeks? Trying to work out if I'm overthinking this or if my instincts are trying to warn me about something. submitted by /u/avz008 [link] [留言]

I'm a Full Stack dev. At my current job, until recently, I've being stuck doing only front end work. This is due to coworkers (referred to as C:A & C:B) hording all the back end work. They have stated that they don't know the front end. Yet they use A.I. to generate front end code they don't understand. Tech Lead doesn't care as long as it works. To be clear, this is not an anti-A.I. post. I see it as a tool and use it myself. Whatever it generates, I go through and understand how it works and if it is the best way to do it. When I say "Done Dirty", I mean A.I. is being used by people to do front end work that they wouldn't be capable of otherwise. Examples of what I have experienced. I was working on an assignment with Coworker C:A. I was on the front end work and they on the back. C:A branched off my Git branch, used A.I. to finish my part and theirs. They presented it to the boss (a non-technical director) as their work alone. I was working on an assignment with both C:A and C:B and we got down the wire on it. It was the day before delivery and I was trying to wire up the U.I. for both their back ends. I was running behind. C:B decided to use A.I. to wire theirs up and told everyone they got it done. The next day I was looking over everything and realized it wasn't wired up. It was displaying the embedded data I put in for testing. I had to inform the Tech Lead and it did not go well for C:B. My question is are front end devs getting the "short end of the stick" because A.I. can generate U.I. elements and do interface work for people who don't understand anything about it. Is anyone else experiencing something similar? Not looking for anti-A.I talk. I really want to know if people who specialize in this work are being directly undercut by A.I. usage. TLDR: Are devs using A.I. to generate front end code they don't understand undercutting those that specialize in it? submitted by /u/wtfbigman24x7 [link] [留言]

Web Security Basics Every Developer Must Know (2026) Security isn't just for security teams. Every developer needs these fundamentals to protect their applications and users. The Threat Landscape in 2026 Most common attacks targeting web apps: 1. SQL Injection — Still #1, still devastating 2. XSS (Cross-Site Scripting) — Steals sessions, defaces sites 3. CSRF (Cross-Site Request Forgery) — Actions on behalf of users 4. Authentication bypass — Weak passwords, session fixation 5. Sensitive data exposure — API keys in code, unencrypted data 6. IDOR (Broken Access Control) — Accessing others' data 7. SSRF (Server-Side Request Forgery) — Internal network probing 8. Dependency vulnerabilities — Compromised npm/pip packages Key principle: Defense in depth → Don't rely on one security layer → Multiple independent controls → If one fails, others catch it #1 SQL Injection Prevention // ❌ VULNERABLE: String concatenation const query = `SELECT * FROM users WHERE email = ' ${ email } '` ; // Attacker inputs: ' OR '1'='1' -- // Result: Returns ALL users! // ✅ Parameterized queries (always!) const user = db . prepare ( ' SELECT * FROM users WHERE email = ? ' ). get ( email ); // The database treats the input as DATA, not code. // With ORM (Sequelize/TypeORM/Prisma): User . findOne ({ where : { email } }); // Safe by default // Even with parameterized queries, validate input first: function isValidEmail ( email ) { return /^ [^\s @ ] +@ [^\s @ ] + \.[^\s @ ] +$/ . test ( email ); } if ( ! isValidEmail ( email )) return res . status ( 400 ). json ({ error : ' Invalid email ' }); // ⚠️ Dangerous: Dynamic table/column names can't be parameterized! const allowedTables = [ ' users ' , ' products ' , ' orders ' ]; if ( ! allowedTables . includes ( table )) throw new Error ( ' Invalid table ' ); #2 XSS (Cross-Site Scripting) Defense // Types of XSS: // 1. Stored XSS: Malicious script saved in DB, shown to all viewers // → Comment sections, profiles, product reviews // 2. Reflected XSS: Sc