标签：#Web

Some time ago, I embarked on the journey to radically simplify building realtime apps. I wanted: No backend/socket.io setup, and no logins A simpler client to handle race conditions Ultimately I came up with: A public/free relay server that anyone can use A thin WebSocket client that talks directly to that service (or any other WS server) The Dilemma: I always assumed it should be angled at the rapid prototyping crowd, since it's literally a service you can use in a single line from your browser DevTools, but the client itself is pretty f*cking amazing... for ~466 bytes, you can do things like this: connect('wss://socket.massive.com/crypto') .on('*', e => console.log(e['0'])) // listen .send({ action: 'auth', params: 'MY-API-KEY' }) // login .send({ action: "subscribe", params: "XQ.*" }) // subscribe If you notice, that's usually a race-condition nightmare that involves callbacks/promises, etc. The tiny client sorts all that out under the hood (and much more). While of course I use the underlying service to power apps, I find myself using the client itself just to check any existing WS service, because it's 100x easier to use than native WS code. The Question In the NPM library specifically, which should I focus on? The hosted integration, or strictly as a more user-friendly WebSocket client (with an aside mention of the integrated service)? It's all 100% free, so it's not like this is a product question - it's more of a "am I sleeping on something that could help more of the community?" question. submitted by /u/kevin_whitley [link] [留言]

The more I code, the worse my relationship with builder projects gets. It's just reality. I migrate a lot of sites to VPS these days. Cuts hosting costs significantly for clients, and honestly I've gotten pretty good at it. If anyone does the same, curious if you've run into this too. The thing is, most of these projects come with builders already in place. Elementor mostly, some Bricks, some older stuff that's a complete disaster. And the core problem is always the same: these tools design in the database. Not in code. So on a live ecommerce site you've got payments, emails, transactional stuff, chat integrations. All of that gets disabled on dev. Fine. But then when you need to push something back to main, especially if the builder is involved, it becomes a mess. The database on staging and the database on production have diverged, and there's no clean way to merge them. My current approach: stop fighting the chaos, join it with a method. Every DB action I take on staging gets documented as a WP-CLI command. Those commands live in a migration script. When it's time to push, I run the script on production after a backup. It's not magic, but it works, it's readable, and it lives in git. Not sure if this is the right way though. Meanwhile, when design lives in code (custom theme, Gutenberg blocks, PHP templates) the whole problem disappears. Git handles it. Deploy is clean. How do you all handle this in practice? Do you steer clients away from builders? Have you found a builder that plays nicely with proper deploys? Or do you just accept that builder sites need a different, more careful workflow? submitted by /u/Substantial_Word4652 [link] [留言]

Imagine you're responsible for a company's website. Everything seems healthy. Pages load quickly. Users can log in. Content editors publish articles every day. Customers aren't reporting problems. From the outside, everything looks perfect. But then one day you discover something surprising: Attackers don't care whether your website looks healthy. They care whether the software behind it is vulnerable. That's exactly what happened with Drupalgeddon2. One of the most significant CMS vulnerabilities in recent years. And one that still teaches valuable lessons for developers, DevOps engineers, and security professionals today. The Building Manager Analogy Imagine a large office building. The company hires a building manager. The manager handles: Visitors Deliveries Maintenance Schedules Room Access The employees don't worry about these details. They trust the manager. A Content Management System (CMS) works similarly. Instead of manually managing every page and article, organizations rely on a CMS. Website ↓ CMS ↓ Content The CMS becomes the central control system. And that's why it becomes such an attractive target. What Is Drupal? Drupal is an open-source Content Management System. Organizations use it to manage: Corporate websites Government portals Universities Media platforms Enterprise applications A simplified architecture looks like: Visitor ↓ Drupal ↓ Database ↓ Content Every request passes through Drupal. Which means Drupal becomes part of the application's attack surface. Why Attackers Love CMS Platforms Suppose an attacker discovers a vulnerability in: Custom Internal Tool Maybe a few organizations are affected. Now suppose they discover a vulnerability in: Popular CMS Thousands of organizations may be affected. Potentially millions of users. One vulnerability. Many targets. That's why CMS platforms receive so much attention. Understanding Drupalgeddon2 Drupalgeddon2 refers to: CVE-2018-7600 A Remote Code Execution vulnerability affecting Drupal. The import

This week, the first offline-first PWA went live on WebsitePublisher.ai . A travel blog that works without internet. Write posts on a plane, attach photos, and everything syncs the moment you reconnect. Service Worker, IndexedDB, sync queue — the full stack. The twist: it was built entirely through conversation with an AI assistant. No IDE, no terminal, no deploy pipeline. How that works WebsitePublisher.ai exposes 92 integrations as building blocks via MCP (Model Context Protocol). Any AI assistant — ChatGPT, Claude, Cursor, Windsurf, Copilot, Gemini, Grok, Mistral — connects to the same runtime and assembles these blocks into working applications. The offline-first PWA is one of those blocks. The AI doesn't generate a Service Worker from scratch. It activates a proven, tested building block and configures it for the use case. We call this wave coding — one deliberate wave of proven pieces, instead of 15 fragile vibe-coding attempts. What shipped recently Offline-first PWA building block — push/pull sync, conflict handling, IndexedDB storage, works on iOS 92 integrations (up from 78) — 45 built-in, 47 bring-your-own-key Integration stacks — pre-composed combinations: e-commerce (13 integrations), lead generation, B2B prospecting, booking, content/blog 9 AI platforms supported — all via MCP, no vendor lock-in 416 API endpoints across the platform ## The architecture in short AI assistant (any) → MCP → WebsitePublisher runtime ├── PAPI (pages + assets) ├── MAPI (structured data) ├── SAPI (forms + auth + sessions) ├── IAPI (integration proxy) ├── VAPI (encrypted vault) └── AAPI (scheduled AI agents) Credentials never touch the AI. They're stored AES-256-GCM encrypted in the vault and injected server-side during execution. The positioning We're not competing with Lovable or Bolt on the chat interface. We're the Supabase + Vercel + n8n underneath — reachable via whichever AI you already use. The platform your AI builds on. websitepublisher.ai

I have almost 8 YOE experience working in B2B SaaS doing full stack. I broke into the industry in early 2018 without a degree and being completely self taught. Note, I have no degree at all. I did go to college and almost completed my AA, but found work that paid pretty well at the time (not tech related) and off I went. I have been on the market for ~2 months now, and I have noticed I am getting zero traction, unlike before 2022. My last role lasted 4 years and moved to a Senior position. I had been removed from the market this whole time, woefully unaware of what has been going on. Have sent ~150 targeted applications and always an auto reject. Granted it's only been 2 months, but to have a 0/150 interview rate from cold apps is unlike anything I have experienced in the past. I am not spraying and praying, I apply to positions that match my experience. I have also had a technical resume writer rewrite my resume entirely. Right now, I am solely relying on LinkedIn recruiters at this point. I have exhausted my personal network; the few people I can hit up have all said their companies unfortunately are not hiring. Targeting remote, AND in person / hybrid. I am seeing more and more listings asking for CS or equivalent degree. They do mention, "or relevant experience," but the thing is, when a job has 300 applicants, the first filter likely is the degree. I have spoken to many recruiters via LinkedIn and they have all gone nowhere. I get past the initial phone screen no problem, and the recruiter will submit me to the hiring manager of the job, and I hear nothing back after. I was wondering what was happening, and finally a recruiter called me to tell me that a job she submitted me for told her that they are prioritizing candidates with a degree. I have also interviewed about 5 times, passed first rounds and also second round technicals, to only be ghosted. I am currently getting my B.S. as we speak, and should be done in ~7 months. Luckily I was already working on it

For me AI has been a saviour when it comes to coding as it help me learn at the start. However, AI is still relatively young and stilll in development especially a pain when you working big projects. Now the question is: What is the number 1 most constant thing that you dealt with AI in coding (aside from a colleague using it and make a mess of your code)? submitted by /u/Haunting-Bother7723 [link] [留言]

Just wanted to share my journey after 3.5 years of building a live web analytics tool from scratch, and without AI: WireBoard.io As a web publisher for the last 15 years, I used UA (before GA4) and then Chartbeat. I always loved real-time. At the beginning of the internet I spent my time on IRC, which was great and a huge change from newsgroups and forums. A few years later, Chartbeat was changing its customer base and focusing on big news publishers, and my workflow was about to change with it. I loved being able to watch my traffic live and spot anything unusual, day by day, compared to the same day the previous week. So I decided to replace it with my own product, but with the things their tool was missing. I spent about 8 months thinking it through and sketching different architectures to handle the load and the logic of the data processing pipeline. Then I learned to code in Go (which was surprisingly easy) and built an MVP. After some iterations, I worked on the frontend (Laravel + React) and kept improving the product based on user feedback. The features I couldn't find anywhere else: Truly real-time data via streaming instead of polling. Merging data from different websites into one chart, so I can see at a glance whether traffic is unusual "today" compared to last week. A flexible dashboard, arranged like widgets on a phone. I mostly worked on this quietly and didn't talk about it much on social media or anywhere else, since I'm a dev and not a marketer. This is my biggest project, and I've enjoyed the long journey. All of this happened before the AI era, which turned out to be good timing: I can work on the codebase knowing exactly what does what and where. Over the last 6 months I've experimented with using Claude on some parts of the project (only the frontend), but in limited areas: Performance improvements (useMemo, etc.) Security reviews (not strictly needed, but reassuring when it confirms what I expected) CMS (blog section) The tech stack: Data proc

The dangerous part of web extraction is not the error. The dangerous part is a clean JSON response that looks correct and is not. If an AI agent uses that output, the mistake does not stay inside a scraper. It moves into a report, a lead list, a price alert, a CRM update, or an automated decision. So before you trust any web extraction API in an agent workflow, test whether it fails honestly. Here is the checklist I use. 1. Test a real page, not a demo page Demo pages are usually polite little museum exhibits. Use pages that behave like the actual internet: a JavaScript-heavy product page a search results page a page with missing fields a login-gated page a blocked or rate-limited page a thin page that has layout but little useful content If the tool only looks good on clean static pages, you have not learned much. 2. Check whether the API separates fetch success from extraction success A page can return HTTP 200 and still be useless. Common examples: the final page is a login screen the visible content is a bot challenge the useful data loads after hydration and never appeared in the fetch the page contains a generic country selector instead of the product the source has navigation text but no actual item data The extractor should not treat these as success just because the request completed. A better response says something like: { "status" : "failed" , "failure_type" : "login_required" , "extracted" : null , "next_step" : "Use a public URL, authorised access, or sample content." } That is boring. Boring is good here. Boring means the agent can stop safely. 3. Ask for fields that are not on the page This is the easiest lie detector. Ask the extractor for something impossible: Extract the product name, price, stock status, warranty length, CEO name, office address, and refund policy. If the page only contains product name and price, the API should say the other fields are missing or low confidence. It should not politely invent them because the schema asked nicely.

With ideas and project specs scattered across platforms like Notion while actual tasks live in GitHub, keeping them in sync is constant manual overhead—how do you bridge this gap without your PM tools and repos becoming a mess? submitted by /u/asifdotpy [link] [留言]

You can't imagine how bad my experience with Next.js has been recently. I have two projects running on the same Ubuntu laptop: One Next.js app One TanStack app The Next.js dev server was literally the biggest process on my entire machine, sitting at almost 4GB of RAM and absolutely murdering my old Lenovo. Even Brave and VScode consume less memory. Meanwhile, the TanStack app was using around 800MB. Still not amazing, but nowhere near as insane. Out of frustration, I asked an AI to help optimize the Next.js setup. It ended up changing some config to force Webpack instead of the default Turbopack setup and also added limits to how large the cache could grow. Believe it or not, memory usage dropped from nearly 4GB down to around 1–2GB. That's still a ridiculous amount of RAM for a dev server, but at least it no longer tries to consume every available resource on my laptop. Maybe Vercel is thinking that everybody has a fancy Macbook M4 with 64GB ram?! P.S. both codebases are small, max 50k lines in each. submitted by /u/hanzo2349 [link] [留言]

I added real-time activity logging and security scoring to my Claude Code dashboard The problem with just seeing costs Knowing how much you spent is useful. But it's not enough. The real question is: what is your AI actually doing? Which files did it read? Which commands did it run? Is your environment even safe to run it in? I couldn't answer any of those. So I built the answers in. What's new in v0.1.17 Activity Log — see every action in real-time Claude Code logs everything via hooks. Every file read. Every command executed. Every API call. Risk-labeled. Timestamped. Live. Set it up once in ~/.claude/settings.json : { "hooks" : { "PostToolUse" : [{ "matcher" : ".*" , "hooks" : [{ "type" : "command" , "command" : "curl -sf -X POST http://localhost:3000/api/actions -H 'Content-Type: application/json' --data-binary @- 2>/dev/null || true" }] }] } } Then open http://localhost:3000/activity . Watch your AI's actions stream in real-time. This is the audit layer AI agents have been missing. Security Score — how safe is your Claude Code environment? Scored out of 100. Checks 7 things: Is Bash(sudo *) in your allow list? (-20) Is ~/.ssh/** in your deny list? (-20) Is Bash(curl *) unrestricted? (-15) Are .env files protected? (-15) Is strictMode enabled? (-10) Is Bash(rm *) restricted? (-10) Are hooks configured? (-5) I scored 90/100. What's yours? The point isn't to shame anyone. It's to make the invisible visible — so you can make informed decisions about what your AI is allowed to do. Try it npm install -g @notenkidev/claude-token-dashboard claude-token-dashboard Open http://localhost:3000 GitHub: https://github.com/notenkitoclient-cpu/claude-token-dashboard This started as a simple token counter. It's becoming something bigger — an observability layer for AI agents. More coming.

Your security scanner just came back with 6 flagged items. All missing HTTP headers. You did what any reasonable developer does: Googled each one, copy-pasted the recommended config, and shipped a fix in 20 minutes. Job done. Security score green. PR merged. You also probably shipped at least two of them wrong. Here is the thing nobody tells you about HTTP security headers: knowing what to add is the easy part. Understanding why it matters, when it actually doesn't, and how a misconfigured one breaks your app in production — that's where most developers fall short. This isn't another "add these 7 headers to secure your app" post. This is the one that explains what's actually happening. First, The Contrarian Take Missing a security header is not automatically a vulnerability. If you do bug bounties, this will save you a rejection. If you're a dev, it'll save you from cargo-culting configs that don't apply to your app. Context is king. X-Frame-Options: DENY is a valid security header. YouTube doesn't use it. Because the entire point of YouTube is for people to embed its videos in iframes. Applying that header would break a core product feature. That's not a security oversight — it's a deliberate design decision. A missing Content-Security-Policy header is not a vulnerability in itself. It only becomes relevant if you already have an XSS problem to mitigate. CSP is defense-in-depth. Not a fix for a broken input sanitisation layer. This matters because a lot of developers (and worse, automated scanners) treat these headers like a binary checklist. Present = secure. Missing = vulnerable. Reality is messier than that. Now — with that said — let's talk about what each one actually does. #1. HTTP Strict Transport Security (HSTS) Most developers think HSTS is just "force HTTPS." It's more precise than that. When your app redirects http:// to https:// , that first request is still unencrypted. For a fraction of a second, on a public network, that window exists. An attacker on

I’m building a company monitoring app that reads Firebase data coming from multiple bus DMS devices and returns KPIs for a Svelte dashboard. Is FastAPI a good backend choice for this, especially for a secure, production-ready, scalable, and maintainable API? If not give me please alternatives . I also need a good FastAPI template or guide to start from, a secure way to connect it with Firebase, and the best way to package the app for both Windows and Android. What I need to use ? submitted by /u/Successful-Life8510 [link] [留言]

TypeORM 1.0 is the first major release of the open-source TypeScript and JavaScript ORM since its inception in 2016. This version modernizes platform requirements, removes deprecated APIs, and introduces numerous bug fixes and new features. TypeORM now supports ECMAScript 2023, dropping older Node.js versions and dependencies while enhancing security and migration processes. By Daniel Curtis

When building a small content site, the framework is usually not the hardest part. The harder part is deciding what each page should be responsible for. A lot of sites start as a simple article list. That works for a while, but it becomes messy when visitors arrive with different search intents. Some users want to learn what something means. Some want download or setup information. Others are trying to fix a specific issue. Those users should not all land on the same generic page. The structure I use For a small Next.js content hub, I like to separate routes by intent: Homepage: broad entry point Learn hub: basic explanations and guides Learn detail pages: specific guide topics Download page: download or install intent Fix hub: troubleshooting entry point Fix detail pages: specific issue pages English and Japanese routes: language-specific entry points This structure is simple, but it keeps the site easier to maintain. Page role comes first Before writing a page, I define its role. A learn page answers what something is, how it works, and what a beginner should understand first. A download page answers where a user should get something, what should be checked before installing, and which platform or device matters. A fix page answers what is not working, what should be checked first, and whether the problem is related to permissions, notifications, device settings, or installation. The page role decides the title, description, internal links, and body structure. Why this helps SEO This approach helps avoid pages competing with each other. For example, a download page should not try to rank for every tutorial query. A troubleshooting page should not read like a general homepage. Each page can link to related pages, but the primary intent stays clear. That makes the site cleaner for both users and search engines. Metadata and sitemap discipline In a Next.js App Router project, I also like to keep metadata and sitemap updates close to the route change. For example: If

Fallback rules are where an AI API gateway becomes operationally valuable. The goal is not to blindly retry every failed LLM call. The goal is to choose the right backup model, provider, or budget path based on the workflow, customer tier, latency target, and risk of a lower-quality answer. A practical fallback policy should define: which failures are retryable; which workflows may downgrade models; which customers or API keys are allowed to use premium fallback routes; how budget caps change routing behavior; what metadata gets logged so the team can debug cost and quality later. 1. Classify traffic before routing Do not write one global fallback rule for every request. Start by classifying traffic: Critical user-facing : support chat, checkout assistance, customer-facing agent answers. Non-critical user-facing : summaries, title generation, enrichment, recommendations. Internal automation : triage, labeling, data cleanup, back-office agents. Batch jobs : long-running summarization, extraction, report generation. Experiments : tests, staging, evaluation, prompt tuning. Each class should have a different fallback budget and quality floor. 2. Decide what counts as a retryable failure Good retry candidates: upstream timeout; 429 rate limit; temporary 5xx provider error; network interruption; overloaded model endpoint; streaming connection drop before useful output. Poor retry candidates: invalid API key; malformed request payload; unsupported tool-call schema; content policy rejection; user quota exhausted; deterministic validation failure. Retrying non-retryable failures usually burns tokens and hides product bugs. 3. Example fallback policy matrix Traffic class Primary route First fallback Second fallback Hard stop Critical user-facing frontier model same-class model on second provider cheaper model with explicit uncertainty after 2 provider failures Non-critical user-facing balanced model cheaper model cached/default response after budget cap Internal automation lo

Bitcoin can look simple from the outside: paste an address, choose an amount, send. Under that simple interface are several concepts that are useful for developers and technical beginners to understand. This post is not trading advice and does not discuss price. It is a practical mental model for what is happening when someone sends Bitcoin. 1. A wallet does not "hold coins" the way an app balance does Many beginners imagine a wallet as a container full of coins. That is close enough for casual conversation, but it can be misleading. A Bitcoin wallet manages keys and helps create transactions. The Bitcoin network tracks spendable outputs on the ledger. When you send BTC, the wallet constructs a transaction that spends previous outputs and creates new outputs. You do not need to master every detail on day one, but the high-level idea matters: control of keys controls the ability to spend. 2. An address is a destination, not an identity A Bitcoin address is where funds can be sent. It is not a username and it is not automatically tied to a person in the way a social profile is. Before sending, beginners should check the address carefully. A small copy-paste mistake can be permanent. Malware can also replace clipboard contents, so visually checking the beginning and ending characters is a useful habit. For larger transfers, a tiny test transaction can reduce risk. 3. Fees are about block space Bitcoin transactions compete for limited block space. A fee is not a tip to a company. It is part of the transaction economics that helps miners decide which transactions to include. When the network is busy, low-fee transactions may wait longer. When the network is quieter, confirmations may happen faster. The beginner lesson is simple: do not assume "sent" means "fully settled." Check confirmations and understand that fee choice can affect waiting time. 4. The mempool is a waiting area Before a transaction is confirmed in a block, it may sit in the mempool, which is a pool of u

I keep seeing shit all over about companies producing 95% of their code using AI. I see people saying they now write 100k lines of code a day. I am seeing this everywhere and as a CTO and solo eng, this has given me major fomo. For the past few months I have been working on everything I can to get to this level. I tried Ralph loop, goals, compound engineering, and my own mixture of things. No matter what I just keep finding that slop is coming out the other end and my time to review and fix (by prompting or by manually fixing) is 1. feeling like a pretty huge time sink and 2. sucks way worse than just using my brain to write to code. it is much less rewarding/ fun fixing retarded code than it is writing something elegant myself. I know AI is a huge productivity booster when I can use it for internal tools, scripts, prototypes, and boiler plate or highly defined work. other than that, it seems like it is kind of a time sink, especially for production and legacy apps. You guys experiencing this too? seriously, is the shit about crazy good ai output out there real and if so, how do I attain it? my tech advisor thinks it’s total BS and even said Google engineering is pulling back their AI use in coding some submitted by /u/l300TS [link] [留言]

My Previous Deployment Choices Since I mostly do web development using Ruby on Rails, these were my go-to options for deployment: PaaS like Heroku, Render, or Railway Serverless setups (Cloud Run + NeonDB) Honestly, I didn’t have any major complaints. PaaS costs a bit more, but in return, you get a clean UI and dead-simple workflows like GitHub integration. If the cost bothered me, I’d just go serverless. For my personal servers—where huge traffic isn't exactly a concern—going serverless meant the app would just sleep when inactive, allowing me to run services for around 50 yen a month. Compared to the headache of clicking through complex AWS or GCP dashboards to piece things together based on architecture diagrams, it was a walk in the park. I was perfectly content. Seriously. Kamal Became the Default in Rails 8 Everything changed when Rails 8 dropped. I heard they adopted Kamal as the official deployment tool. Kamal — Deploy web apps anywhere From bare metal to cloud VMs using Docker, deploy web apps anywhere with zero downtime. kamal-deploy.org Kamal? Is deploying really going to get any easier? I mean, I’m doing completely fine right now, though... That’s what I thought. But once I gave it a shot, it felt like being struck by lightning. This is an absolute game-changer. All you have to do is run rails new , throw your server's IP address into deploy.yml , and run kamal setup . That’s it—your app is deployed. For every release after that, it's just kamal deploy . I couldn't believe how simple the deployment workflow was. # deploy.yml service : my-app image : my-user/my-app servers : web : - 192.0.2.1 # Just swap in your VPS IP address here proxy : ssl : true host : app.example.com # Set up your domain here Sure, you have to bring your own server, but Kamal prides itself on being able to deploy absolutely anywhere. I rented a couple of VPS instances from Hetzner for about $10 a month each to host SuperRails and LazyCafe . From what I looked into, you can't really

Im a freshman college student, for a credit, I have to intern at an NGO and do community outreaches The one that I'm fixed to join asked me to revamp their website, understandable since I'm an engineering student, except i only have minimal knowledge. I'm interning for a month and would really like to learn this into a learning lesson but as of now, im extremely overwhelmed and have no idea where to start. All I've done is very basic HTML, CSS and JAVASCRIPT, nothing practical on an actual website. I would really really appreciate any help with how to approach this challenge. All help would be appreciated, thank you submitted by /u/Internal_Sector_1802 [link] [留言]