标签：#EV

I want to create a website in a couple of days. It's main purpose is to offer a free digital download. I want to capture email in the process, to provide follow-up guidance to using the product. There's no e-commerce involved and few pages (4-5). Analytics and domain registration would be a bonus. I want it to look nice - I'd like to have flexible visual design options or be able to adapt a template. I'm comfortable with the likes of WordPress, Wix, Squarespace, Shopify, Canva but not so much using code. In this situation, what would people recommend? 🙏 submitted by /u/jahwinnie [link] [留言]

I'm not sure if I'm in the right place to ask this, but I need to create a web application, and am looking forwhat stack might be best suited.. So far, SurveyJS seems to tick all the boxes, but I have zero experience with the stack. Another one is Flask/Waitress and JS. Ultimately, this will all have to run off a docker host.. I need it save form data, ideally in something like MariaDB, so the user can pick a form the previously filled out and edit it. Multiple users will be using it, authentication is being handled elsewhere, but everyone should be able to see/edit everyone elses' data.. This is a "nice to have", but is there a functionality to export the form data to XML? The app we're looking at building needs to be able to as a question like "How many cars have you driven", and then from that answer create a section or a sub-form for each car that would ask other questions about the cars. I don't mind throwing a bit of money at this, looking at all-in-one options like FluentForm if that ticks all the boxes Thanks so much! submitted by /u/the_zipadillo_people [link] [留言]

OpenSparrow v2.6 is out. This one's a big step forward — RAG (Retrieval-Augmented Generation) integration, bulk grid operations, and a whole new UX layer. RAG & AI integration You can now upload documents and let users ask questions against them. The system retrieves relevant sections and generates answers using an LLM (supports Ollama locally or any OpenAI-compatible API). What's new: RAG Statistics tab in admin — tracks query tokens, response times, document matches, and recent queries Multilingual auto-response — user questions are answered in their own UI language, no schema changes needed 20-language support — "Ask AI" panel fully translated, plus language dropdown in the test interface Good for things like: knowledge base Q&A, customer support automation, or letting internal teams ask questions about their own data. Grid & bulk operations Mass Edit module — select rows via checkboxes, bulk edit fields, change owners, duplicate, or delete with one click Keyboard shortcuts — arrow keys to navigate, Tab, Ctrl+C to copy, Ctrl+F to search, Ctrl-hold for help modal — works across all 20 languages Quick Data Cleanup toolbar — find & replace with live preview, case sensitivity, accent-ignore. Editor-gated with audit trail. Admin improvements Renamed "RAG Knowledge Base" to "Centrum AI" (heading is translatable) Migration Manager — tracks pending cleanup tasks after version upgrades, with automatic backups and audit trail FK columns render as dropdowns in forms by default Security & Quality All bulk operations (mass edit, cleanup, delete) are editor-role gated CSRF protection on every operation Full audit trail — every change is logged 20 languages fully supported across all new modules Fixed regressions in RAG API and CSV import Following this series? OpenSparrow v2.3 – visual admin panel, zero dependencies, now with ERD and M2M support OpenSparrow – open-source admin panel builder, zero dependencies, v2.1 just dropped Websites opensparrow.org github.com/wrobeltomasz/

Analytics is often treated as a reporting feature: a dashboard added after the product already exists. That is usually too late. For software operators, analytics is closer to infrastructure. It is the layer that makes the state of the product visible. Without it, a team cannot evaluate the situation, understand whether the product creates value, or know whether a workflow is improving. That is the reason WebmasterID is built around privacy-first analytics. The goal is not to collect more data than necessary. The goal is to preserve enough signal to make practical decisions without turning measurement into surveillance. Analytics answers operational questions Good analytics starts with plain questions. What happened? Which workflow changed? Which part of the product is used? Where do people leave? Which system events matter? What evidence supports the conclusion? Those questions sound simple, but they are the foundation of product judgment. If the data model cannot answer them, the team is forced to reason from anecdotes, support messages, and internal opinion. Those inputs still matter, but they are not enough on their own. Analytics gives operators a way to compare the current state with the previous state. It makes change visible. It also makes uncertainty visible when the evidence is incomplete. Product value needs evidence A product can look polished and still fail to create value. It can also look unfinished while solving a real operational problem. The difference is usually visible in behavior. Do users return? Do they complete the workflow? Do they avoid a manual step? Does the product reduce confusion? Does it make a business process easier to operate? Privacy-first analytics should help answer those questions without building a profile of every person. In many cases, first-party events, coarse context, workflow state, and careful retention rules are enough. The system does not need to know everything about a user to show whether a product path is working.

In 1994, Peter Deutsch published the Fallacies of Distributed Computing — eight assumptions that every developer building distributed systems makes, discovers are wrong, and pays for in production. The network is reliable. Latency is zero. Bandwidth is infinite. Each assumption sounds true. Each leads to system failures that could have been avoided. Thirty years later, we're making the same category of mistakes with generative AI. The trough of disillusionment for AI-assisted development has begun. Byron Cook, VP and Distinguished Scientist at Amazon, founder of AWS's Automated Reasoning Group (300+ scientists, 15+ teams), says it plainly: "Generative AI is sliding into the trough of disillusionment." The headlines are shifting. The "summer of vibe coding" is over. The disillusionment isn't caused by AI being useless. AI-assisted coding delivers real productivity gains. The disillusionment is caused by false assumptions about WHERE the gains come from and WHAT changes when generation gets fast. Teams expected 10x engineering. They got 10x code generation and 1x everything else. The gap between expectation and reality is the trough. This series names the eight assumptions, explains why each one fails, and presents the resolution — not from theory, but from domains that hit the same wall and climbed out. The Eight Fallacies 1. Faster code generation means faster engineering. You made one sub-system 10x faster. Seven others didn't change. The system doesn't get faster — it breaks at the interfaces. The CPU-memory wall tells you exactly what happens and what fixes it. 2. If the output looks correct, it is correct. AI-generated code is optimized for plausibility, not correctness. It compiles, passes tests, and reads well — while violating properties nobody tested. Plausible is not correct. The gap is where production failures live. 3. You can verify AI output with another AI. Guardrails, LLM-as-judge, AI code review — the verifier has the same failure modes as the thing

I use "what is my IP" sites maybe once a month. Every time I end up on something covered in ads, calling three different tracking APIs, and showing me results I don't fully understand. So I spent a weekend building whatsmy.fyi. The thing I didn't expect: you don't need an IP geolocation API at all if you're on Cloudflare Workers. Every request comes with a cf object that already has your city, country, ISP, TLS version, HTTP protocol, and RTT. Free. Zero latency. The part I enjoyed most was the WebRTC leak test. It checks whether your browser is exposing your real IP through RTCPeerConnection even when you're on a VPN. I ran it on my own setup. It was leaking. Zero logs. Zero storage. Just your data, shown to you. https://whatsmy.fyi

So im working on a saas and am wondering how most of you all handle ToS, liability, and where you get them from? Ill be storing customer data like addresses, emails, phone numbers in a db. Stripe for payment processing. I want to make sure i have a solid tos. To cover refunds, chargebacks, data stored in a db, etc… Should i just find a lawyer or are there resources online i can use? submitted by /u/spacedublin [link] [留言]

Last Friday at 4:30 PM, my product manager walked over: "Hey, can you grab the titles from the Hacker News homepage and send me an Excel file?" I thought: That's it? Five minutes tops. Two hours later, I was still debugging CSS selectors. How Things Spiraled Out of Control Step 1: Initialize the Project mkdir hacker-news-scraper && cd hacker-news-scraper npm init -y npm install puppeteer Hit enter, waited three minutes. Puppeteer needs to download a full Chromium browser — over 200 MB. I stared at the progress bar and started questioning my life choices. Step 2: Write the Code "It's just a document.querySelectorAll , right?" That's what I thought. Then I opened my editor: const puppeteer = require ( ' puppeteer ' ); ( async () => { const browser = await puppeteer . launch ({ headless : true , args : [ ' --no-sandbox ' , ' --disable-setuid-sandbox ' ] }); const page = await browser . newPage (); try { await page . goto ( ' https://news.ycombinator.com ' , { waitUntil : ' networkidle2 ' , timeout : 30000 }); await page . waitForSelector ( ' .titleline > a ' , { timeout : 10000 }); const titles = await page . evaluate (() => { const items = document . querySelectorAll ( ' .titleline > a ' ); return Array . from ( items ). map ( el => ({ title : el . textContent , url : el . href })); }); console . log ( JSON . stringify ( titles , null , 2 )); } catch ( err ) { console . error ( ' Scraping failed: ' , err . message ); } finally { await browser . close (); } })(); I counted: 27 lines. And this is the minimal version — no User-Agent spoofing, no retry logic, no proxy support, no concurrency control. Add all of that and you're well past 50 lines. Step 3: Run It node index.js Error: Navigation timeout of 30000 ms exceeded . Switched to domcontentloaded , got past that. But then waitForSelector timed out — because .titleline was a relatively new class name. Hacker News had silently changed it from .storylink at some point, and nobody sent me the memo. Step 4: Debug Set head

The Bezos-backed EV startup has yet to announce final pricing for its vehicle, which is supposed to start shipping by the end of this year.

When Mozilla shut down Pocket in July 2025, I lost my favorite tool. Worse, none of the English alternatives (Instapaper, Readwise, Matter, Raindrop) had Japanese UI, and their article extraction was mediocre on Japanese pages. So I built one. It's called Readbox — Japanese-first, English-too, read-later as a PWA. Here's what I learned shipping it. The stack Next.js 15 App Router + TypeScript strict (no any ) Supabase (Postgres + Auth + RLS) Stripe (JPY + USD prices, locale-routed) Tailwind CSS Service Worker for PWA install + offline read Three things that bit me 1. Article extraction on Vercel serverless First attempt: Mozilla Readability + jsdom. Doesn't bundle on Vercel because of ESM compatibility issues and the 50MB serverless function size limit. I tried 6 approaches — Webpack externals, dynamic imports, edge runtime — none worked cleanly. Ended up using Jina Reader , which returns clean Markdown/HTML from any URL. Trade-off: third-party dependency, rate limits at scale. But it works today, and it's free. 2. Storing article body on-device I didn't want to host millions of articles' worth of HTML on Supabase (cost + privacy). Solution: extracted HTML lives in the browser's IndexedDB only (via Dexie); only metadata (URL, title, tags, read status) syncs to the server. Trade-off: cross-device sync of body content doesn't work seamlessly. Acceptable for a "read it later" workflow where you usually read on the device you saved on. 3. i18n routing — the silent sitemap killer For Japanese + English from one codebase: app/[locale]/ segment with /en prefix for English (default Japanese has no prefix, to preserve old URLs). Middleware detects cookie / Accept-Language and redirects accordingly. The gotcha (cost me a launch-day hour): middleware matcher excludes _next , api , image extensions — but if you forget .xml/.txt/.webmanifest , sitemap.xml and robots.txt get rewritten to /ja/sitemap.xml (which doesn't exist as a route → 404). Fix: export const config = { matcher

I got tired of explaining to people why their "simple weather widget" needed an API key, a signup form, and a credit card. So I built a weather API that doesn't need any of that. Here's how you can add live weather to your personal website, portfolio, or side project in about 60 seconds. The old way (painful) Most weather APIs make you: Create an account Verify your email Generate an API key Paste that key into your code Worry about rate limits Get an email when your "free tier" expires For a weather widget on a personal site? That's overkill. The Nimbus way (one fetch, done) I made a public API that doesn't need keys. Just call it. fetch ( ' https://nimbus-api-gxuc.onrender.com/api/v1/weather?city=Berlin ' ) . then ( response => response . json ()) . then ( data => { console . log ( data ); }); That's it. No headers. No tokens. No signup. Real example: Put it on your site Here's a working snippet you can drop into any HTML page right now: <div id= "weather-widget" > <p> Loading weather... </p> </div> <script> fetch ( ' https://nimbus-api-gxuc.onrender.com/api/v1/weather?city=Berlin ' ) . then ( res => res . json ()) . then ( data => { const weatherHtml = data . temp_celsius + ' °C • ' + data . description + ' <br>Wind: ' + data . wind_speed_kmh + ' km/h • Humidity: ' + data . humidity_percent + ' % ' ; document . getElementById ( ' weather-widget ' ). innerHTML = ' <strong> ' + data . location + ' </strong><br> ' + weatherHtml ; }) . catch ( function () { document . getElementById ( ' weather-widget ' ). innerHTML = ' <p>Weather not available right now</p> ' ; }); </script> Change Berlin to any city. It works. Why did I build this? Because I got tired of closed source APIs that change their pricing every 6 months. Nimbus is open source. The code is on GitHub. You can read it, fork it, or run your own version if you don't trust me. The API is free because hosting a weather endpoint costs me almost nothing, and I'd rather lose money than put up a paywall. Try it righ

The pale-blue Ojai vehicles will start picking up members of the public in California and Arizona today.

I recently started using NewsAPI for scraping news articles online but this only works in your localhost, can anyone recommend any free APIs that work in production too (especially when deploying with Vercel)🙏 submitted by /u/Expensive_Bank9080 [link] [留言]

At least two owners have lost control of their vehicles after a critical suspension component broke. In both cases, the vehicles had been previously serviced.

Hi, I was working on extension that has an end-to-end encrypted sync, and when user first time install the extension on a browser where it needs to download all the data (can be a few hundreds or thousands), then it was taking a huge amount of time in the first place then I spend some time researching and found that using workers with a worker pool is the best thing I can do to improve the performance, now it's significantly faster as compared to previous encryption/decryption approach where everything was inside the main thread and being done one by one. but, it's still not like the protonmail inbox where I never see any decryption progress when I login and open the inbox, so, how does that work and how can I make my tool work like that? and as I can't explicitly set that how many workers will actually work in parallel during runtime, as it's up-to the browser based on the available resource, so, is there any other way to get the most out of the workers to make the encryption decryption even faster? btw, I'm currently using the same salt per batch of 100 items, salt, iv, derived keys are generated once and passed to those workers for batches, so, workers are not doing same thing again for common tasks, decreased iteration from 600K to 400K for faster performance. so, if anyone can help me understanding how these works, and how can I make it even better, I'll really appreciate that :) submitted by /u/nhrtrix [link] [留言]

This is only for freelancers who build websites in the EU/UK. What headless cms do you use, as some don’t allow you to choose server location? How do you store your clients websites? Do you self host using gitea? submitted by /u/Fine-Market9841 [link] [留言]

I'm working on a few client sites where translation costs are getting ridiculous. I started looking into whether we can do more on the client side and came across someone or a company? experimenting with Chromium's built-in translation neural net instead of calling external APIs. Has anyone here tried building around window.translation yet? How flaky is the model loading? What kind of fallback are you using when the browser hasn't downloaded the language pack? Mostly curious about the architecture, especially around handling the initial load and performance on lower end devices. (I apologize if links are not allowed, not use to posting much) submitted by /u/Old_Acanthisitta1396 [link] [留言]

Hey guys. We used to write our backend code primarily in python flask. And then we added nextjs/react for frontend. But the way it was done by previous devs was nextjs talks to flask internally on localhost and passes requests onto flask after handlingu the auth. As there's only one public subdomain. But often times it feels so ceremonial. Because flask has a route. Then nextjs has an equivalent route. And for basic stuff it almost looks equal size in the 2 places. There's endpoints just to pass a request on. And then someone suggested to do rewrites for certain stuff but that just splits the ability to where do you find code related to a certain thing like whitelabel. You go and first find it in nextjs routes, then u see if it's in any of the rewrites. And then you go and dig the flask equivalent. Since nextjs is totally really a real backend. And it anyways sits in the middle to interject every request due to auth etc. Makes me wonder if it's a bad idea to let it handle most of the crud stuff. Because rn it gets a request to say serve a logo. It gets a route handles headers etc and sends a request to flask hey can you grab that logo for me. And then ships it back. But it's gonna take just a few lines more for nextjs to end up doing the whole thing itself. Now the only issue is. That would sort of split the duties a bit. And the line might be slightly arbitrary. I personally prefer if we can keep all the business logic in python as that's what our team understands best. And also do certain data science stuff for which you anyways need python. But overall is it a bad idea to split duties between 'backends' like this. Especially the simpler crud stuff. Or how else would you suggest the backend handles the requests. Is route handlers the way or rewrites. Thanks. submitted by /u/Consistent_Tutor_597 [link] [留言]

What I Built I’ve always had a love-hate relationship with technology. In college, I majored in computer science and took classes ranging from electrical engineering to human-computer interaction. From soldering transistors on a physical circuit board to designing UI/UX experiences, I’ve touched many layers of the computing stack—and I’m constantly mind-blown by every new piece of the puzzle I learn. However, my experience as a user of technology before studying it was very different. In middle school and high school, my phone made me feel anxious, stressed, and cynical. I felt lonely on social apps and isolated when I deleted them. I remember some summer days in middle school spent alone in my bedroom watching YouTube, where I was recommended extreme dieting videos. Back when I had no idea what an algorithm was, I still knew I was being harmed by them. By my sophomore year of college, I had deleted Instagram and TikTok and turned off YouTube recommendations. While this protected me from harmful and extreme content, I also missed important life updates from my close friends and family. After taking a web development class and learning how to build a basic card layout, I decided to try building my own social app: Lumira. My goal was simple. I wanted to create a mobile, personal feed of photos just from my friends and family, curated by their genuine interests and sorted by time. Demo https://youtube.com/shorts/DwbVU_LFOc0?si=9H5zPovzIbbW8t-i https://apps.apple.com/us/app/lumira/id6737853449#information The Comeback Story Lumira was born out of 3:00 AM manic coding sessions in my college apartment. This was my first fully end-to-end deployed and distributed application—and it was rocky. My code was chaos. My files were unorganized, and I followed no real patterns, but the thing that motivated me to keep going was that it somehow kind of just worked. I remember the sense of accomplishment I felt the first time I connected to my Firebase backend and saw a photo successf

Threat-intel reports from recent years document campaigns in which attackers obtain AWS IAM credentials from developer workstations, use them to enumerate cloud accounts and access Kubernetes clusters. From there, attackers deploy poisoned container images to move laterally and harvest secrets. The MITRE ATT&CK chain maps to: T1552.001 ( Credentials in Files ) → T1078.004 ( Valid Accounts: Cloud Accounts ) → T1610 ( Deploy Container ) → T1496 ( Resource Hijacking ). This is not an isolated case. The Shai-Hulud supply chain attack harvested Kubernetes credentials from CI and developer workstations, feeding exactly this kind of attack chain. This research started with a short list of questions: What are Kubernetes secrets, exactly? What can an attacker do with them? How can defenders harden their clusters? So before we look at what we found in the wild, and how to harden clusters to mitigate impacts, let's define what Kubernetes secrets are. Three Surfaces, Three Secret Formats A simplified view of the cluster has three sides that matter for this post: A developer, or automation pipeline, talks to the Kubernetes API server with credentials. That is the canonical front door. On every node, the kubelet exposes its own HTTPS API. The same credentials can authenticate to it directly when it is reachable on the network. The cluster's nodes pull images from container registries (Docker Hub, GitHub Container Registry, ECR, Quay, GitLab, ACR…) using a second set of credentials. Kubernetes Architecture These are the attack surfaces where leaked secrets have the most impact, and three secret formats unlock them: TLS client certificates are used by humans through a kubeconfig file with the kubectl command to connect to a Kubernetes cluster. JSON Web Tokens, or Service Accounts, are non-human identities (NHI) used to automate cluster operations from CI/CD jobs, controllers, and integrations. By default, JWTs have no expiration date — which is why a JWT leaked years ago can still