标签：#dev

I'm 15 and Built an AI Energy Dashboard with Next.js 15 + Groq Hey Dev.to! 👋 I'm a 15-year-old student developer from South Korea. I just finished my first real production project — FuelScope AI. What is it? An energy market intelligence dashboard that uses Groq's Llama 3.3 70B to summarize real energy news in real time. 🔗 Live Demo: https://fuelscope-ai.vercel.app What it does ⛽ Regional gas price cards 📈 Energy stock tickers (XOM, CVX, SHEL) 🤖 AI-summarized energy news (Llama 3.3 70B via Groq) 🗺️ Interactive Mapbox station map 📍 GPS nearest station finder 🎨 Apple-inspired clean design Tech Stack Next.js 15 + TypeScript Tailwind CSS Groq API (Llama 3.3 70B) — FREE tier GNews API — FREE tier Mapbox GL JS Vercel deployment What I learned This was my first time building something with: Real API integrations AI summarization pipeline Production deployment on Vercel Apple design system principles Honestly learned more in 4 days building this than months of tutorials. Honest disclosure Gas prices and stock data are mock values — the README includes guides for swapping in real APIs (EIA, Alpha Vantage, etc.). The AI news summaries are 100% live though. Template I'm selling the template for $19 on Gumroad if anyone wants to build on top of it: 👉 https://LZF01.gumroad.com/l/djzoaj Would love any feedback from the community! 🙏 Built with Next.js 15, Groq, GNews, Mapbox

Hello developers, A common issue in team workflows is configuration drift. Staging crashes because of a missing env variable, or a teammate spends hours debugging because they did not get the updated configuration. The typical workaround is sharing env files over chat apps to compare them, which is a major security risk. To solve this, I built envlint. It is an open-source tool written in pure Node.js with zero npm dependencies. How it works: - It creates a schema file (.env.schema) with key names, expected types (string, number, boolean, url, port), and defaults. - The schema contains no secrets and is committed to Git. - Developers run validation locally or in CI/CD. - It includes a diff command to compare keys across environments (e.g. .env and .env.staging). It prints key presence but suppresses all values so that terminal logs remain secure. Technical Details: - Language: JavaScript (Node.js standard library) - Dependencies: Zero - Size: Under 50KB What I learned building this: I spent a lot of time writing a custom parser in JavaScript instead of using regex or third-party parsers like dotenv. Writing a custom parser allowed me to handle edge cases like comments, multiline values, and inline types much more reliably. The project is fully open source under the MIT license: https://github.com/7xmohamed/envlint I would love to hear how you currently manage environment verification in your teams. submitted by /u/7xmohamedd [link] [留言]

Disclosure up front: I maintain one of the five libraries tested (SignalTree), and it's the one that scored worst in the cold run — so this isn't a "look how good my thing is" post. The cross-library pattern and the fix were interesting enough that I wanted to put the numbers in front of people who use Copilot/Cursor/Claude Code every day. The whole harness is reproducible (one command, link at the bottom); I'd rather it get torn apart than taken on faith. Setup Libraries : NgRx (classic), NgRx SignalStore, Akita, Elf, SignalTree. Agents : Claude Sonnet 4.6, GPT-5.4, Gemini 3.1 Pro, Perplexity Sonar Pro, Claude Haiku 4.5, GPT-5.4-mini. 8 prompts : counter, paginated users, debounced search, derived totals, login form, undo/redo, deep nested state, multi-marker editor. 5 libs × 6 agents × 3 priming modes = 720 cells . Temperature 0. Identical prompt text per library (only the library name swapped). Scored on three orthogonal checks: idiomatic-pattern match, import resolution (does every import resolve to a real package), and method validity (do the called methods actually exist on the API). What this measures: one-shot generation. The agent gets the prompt, returns a file, we score it. Real interactive use — Cursor/Copilot with chat back-and-forth, where the model sees its own errors and gets a second try — is a different setting, and the lift could be larger or smaller there. This is the cold-shot case. Finding 1: cold accuracy basically tracks how much the library is in the training data No context provided, just "write this in library X": Library Cold score Akita 94% Elf 94% NgRx (classic) 91% NgRx SignalStore 86% SignalTree 49% The libraries that have been around for years, with thousands of blog posts and Stack Overflow answers, score in the 90s. The youngest/smallest library in the set scores ~49%. That gap isn't really a quality signal — it's a corpus signal. The models have simply seen orders of magnitude more Akita than SignalTree. Worth keeping in mind any

The Problem We Were Actually Solving I still remember the day our treasure hunt engine started to show its weaknesses. We had been using a custom-built solution written in Java, and it had served us well until our user base grew exponentially. The engine, which relied heavily on recursive searches and dynamic memory allocation, began to cause performance issues and occasional crashes. Our team was under pressure to find a solution that would allow our server to scale without sacrificing the user experience. After some research, I became convinced that Rust was the answer to our problems. Its focus on memory safety and performance seemed like the perfect fit for our needs. What We Tried First (And Why It Failed) Our first attempt at solving the problem was to simply translate our Java code into Rust. We thought that the language's built-in features would automatically solve our performance and memory issues. However, we quickly realized that this approach was not going to work. The Rust compiler was complaining about lifetime issues and borrow checker errors, which we did not fully understand at the time. We spent weeks trying to fix these issues, but our code was still not stable. I recall one particularly frustrating error message from the Rust compiler: error: cannot borrow self.list as mutable because it is also borrowed as immutable. It was then that I realized we needed to take a step back and rethink our approach. The Architecture Decision We decided to start from scratch and redesign our treasure hunt engine with Rust's strengths in mind. We chose to use a graph-based data structure, which allowed us to take advantage of Rust's ownership model and avoid common pitfalls like null pointer dereferences. We also made use of the crossbeam crate for parallelism and the tokio crate for async I/O. This new design required us to think differently about our problem domain, but it ultimately led to a more efficient and scalable solution. I was impressed by the level of

Scarab Field Test: Repairing an AI-Generated App Without Guessing Its Intended Baseline I’ve been building Scarab Diagnostic Suite around a problem I keep seeing in AI-assisted development: the app may look close, the code may be mostly there, and some checks may even pass — but the repo still isn’t in a trustworthy state. So I tested Scarab against a public GitHub repo that was explicitly asking for help with an AI-generated web app. The app had been created through a generated/vibe-coded workflow and the owner was looking for help cleaning it up, fixing broken behavior, and making it more stable. The interesting part wasn’t just “can the code be fixed?” The interesting part was: what does fixed mean for this repo? Scarab’s repair pass surfaced that there were actually two valid repair postures: TypeScript intended — treat npm run typecheck as a real acceptance gate. Build/lint only — treat the app as a generated JavaScript React export, where build + lint are the intended acceptance boundary. That distinction matters because a diagnostic suite should not blindly impose a standard the repo never chose. Sometimes the repair is not just technical. Sometimes the repair is clarifying the repo’s actual operating baseline. Both repaired versions now: build successfully lint successfully run locally in the browser render the app correctly include saved runtime evidence/screenshots pass browser smoke checks across key routes One of the more useful findings was that static checks were not enough. A governance/static pass could look clean while the browser runtime still revealed real problems: stray generated stub text, React not mounting meaningful app content, and missing local Base44 helper behavior outside the hosted runtime. That is exactly the kind of failure I’m interested in. Not just “does the code pass a command?” But: does the app actually render? does the local runtime behave? did the repair preserve the app’s intent? did the repo become more coherent afterward?

How to approach hard problems — first principles thinking for engineers First principles thinking is a powerful engineering method for solving hard problems by stripping away assumptions, reducing a system to fundamental truths, and reasoning back up to a solution from those truths. In practice, it helps you avoid cargo-cult design, debug faster, and make architecture decisions based on invariants instead of habit. What it is First principles thinking means asking: what do we know for certain, what is merely assumed, and what must be true for this system to work? Instead of copying a known pattern because it worked somewhere else, you decompose the problem into constraints, facts, resources, and failure modes, then build the simplest solution that satisfies them. For engineers, this is especially useful when the problem is novel, the stakes are high, or the decision is hard to reverse. Core method Use this loop: Define the problem precisely. List facts and constraints. Separate assumptions from evidence. Reduce the system to fundamentals. Ask why repeatedly until you hit a root cause or invariant. Rebuild the solution from those fundamentals. Test the smallest thing that can prove or disprove your reasoning. A useful engineering question is: “What must be true for this to work?” because it forces you to identify invariants before picking tools or patterns. System design example Suppose you need to design a notification service. Start with fundamentals: What is the work? Deliver messages reliably. What are the entities? Users, notifications, delivery attempts. What changes over time? Notification status, retry count, recipient preferences. What must never break? A user should not receive duplicate critical alerts, and failed deliveries should be visible. What happens under load? Queueing, retries, and backpressure become essential. From there, the architecture follows the requirements rather than fashion. If the real constraint is reliable delivery under bursty traff

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

Hello everyone, I’m trying to host a React (Vite) app on GitHub Pages and keep running into the classic SPA routing problem. Repo: [Img2Num GitHub repo]( https://github.com/Ryan-Millard/Img2Num/ ) Live site: [Img2Num GitHub Pages]( https://ryan-millard.github.io/Img2Num/ ) The app is bascally a small landing page for the project that shows an example of how the library can be used, but it uses React Router (BrowserRouter). Everything works fine when navigating inside the app, but: - Refreshing any route other than / results in a 404 - Directly visiting a nested route also 404s - GitHub Pages clearly doesn’t handle SPA fallback routing Many people have suggested these: - Use HashRouter - Add a 404.html fallback hack - Switch to another host (e.g., Clouflare Pages) but I don't like those options because they are either not well-structured and SEO-friendly, not a complete solution, or make it harder to test global support (Cloudflare Pages allows special headers for things like pthreads that GitHub Pages and many other JS setups don't support). What I’m trying to do instead is something like static site generation (SSG) as it would likely be the cleanest fix - similar to how Docusaurus or Astro handles this: - Pre-render routes at build time - Serve static HTML for /, /docs, etc. - No client-side routing dependency for initial load - Better SEO and no refresh issues This saves use from needing to have a fancy backend. When I try setting up SSG with Vite & React, I end up failing I've tried things like `vite-plugin-ssg`, but run into strange behaviours and errors that I cannot seem to be able to fix (e.g., an incompatible dependency that, also breaks when downgraded). I don’t fully understand the correct architecture for multi-route SSG in a React SPA setup. --- What is the correct modern approach for this and is there a recommended way to keep React & Vite, deploy to GitHub Pages, get proper multi-route support without hash routing, and avoid SPA 404 refresh issues ent

Hi ! I would like to know, for all the freelancer, how do you find clients ? submitted by /u/Klutzy-Badger-2778 [link] [留言]

A new verification step submitted by /u/mikeplus10 [link] [留言]

While AI is helping coders produce code faster, it may not be producing better code, researchers warn. And that could cause problems down the road for them.

This is a submission for the Hermes Agent Challenge What I Built Onyx is an autonomous infrastructure operator running 24/7 on my droplet. He manages my entire stack: 6 Next.js deployments, 5 Docker containers, a Minecraft server, fail2ban, Nginx, and UFW. He also helps me write my undergraduate thesis. The difference from every other "AI agent" project I've seen: Onyx doesn't wait for commands. He surfaces problems, patches vulnerabilities, and pushes work forward on his own. When I wake up, there's a session log waiting for me, not a to-do list. The core idea: graduate an AI agent from assistant to operator . A chatbot with tools bolted on doesn't cut it. I wanted something that runs infrastructure while I'm eating dinner, asleep, or in class. Demo Onyx operates through Discord. A normal week: 🔴 3 AM — gateway process failure, no wake-up required A gateway process had a stale PID. Onyx detected it, diagnosed the root cause, restarted it cleanly, and wrote a session log. I found out in the morning. Zero human intervention, zero downtime. 🟡 Dinner — 9 CVEs found across Docker containers While I was eating, Onyx ran a routine audit, found 9 CVEs, rebuilt 3 container images from fresh base images, patched Python dependencies, hardened fail2ban (ban time: 600s to 24 hours), and verified every container came back healthy. 🟢 "Fix it" — two words, full tunneling deployment My friends in Indonesia couldn't connect to the Minecraft server because their ISPs use carrier-grade NAT. I sent Onyx "fix it." He researched solutions, selected playit.gg, installed the tunneling agent, configured a systemd service, and optimized TCP keepalive parameters. All autonomous. 🧠 Accountability loop Onyx noticed I kept asking for things but not acting on the output. He surfaced it: "You keep opening new loops and not closing them." He was right. Now when I open a loop, Onyx tracks it until it's closed or explicitly shelved. 📚 Thesis research partner I'm finishing my undergraduate thesis on e

Genera la tua prima fattura elettronica XML per lo SDI in TypeScript (in 10 minuti) Se hai mai dovuto integrare la fatturazione elettronica italiana in un progetto Node.js, sai già quanto è scomodo: specifiche FatturaPA di 200 pagine, regole cross-field non documentate, codici errore SDI criptici, e librerie npm o abbandonate o in PHP. Questo articolo mostra come generare un XML valido per il Sistema di Interscambio (SDI) usando fattura-elettronica-sdi-builder , una libreria TypeScript open-source che copre B2B (FPR12) e Pubblica Amministrazione (FPA12). Installazione npm install fattura-elettronica-sdi-builder Nessuna dipendenza pesante. La validazione è custom e tipizzata, zero runtime esterni. Il flusso in tre funzioni La libreria espone tre funzioni pubbliche che si usano sempre in sequenza: import { applyDefaults , validate , buildXml } from ' fattura-elettronica-sdi-builder ' ; Funzione Input Output applyDefaults(input) FatturaElettronicaInput (campi deducibili opzionali) FatturaElettronica completa validate(fattura) FatturaElettronica Result<void, ValidationError> buildXml(fattura, options?) FatturaElettronica Result<string, BuildError> Tutte le funzioni restituiscono un Result<T, E> — mai eccezioni non gestite: type Result < T , E > = | { ok : true ; value : T } | { ok : false ; error : E } Esempio completo: fattura B2B con IVA ordinaria Genera una fattura TD01 da una Srl italiana a un cliente italiano, IVA al 22%, pagamento con bonifico. import { applyDefaults , validate , buildXml } from ' fattura-elettronica-sdi-builder ' ; import type { FatturaElettronicaInput } from ' fattura-elettronica-sdi-builder ' ; import { writeFileSync } from ' fs ' ; const input : FatturaElettronicaInput = { FatturaElettronicaHeader : { DatiTrasmissione : { ProgressivoInvio : ' 00001 ' , CodiceDestinatario : ' ABC1234 ' , // 7 caratteri per FPR12 }, CedentePrestatore : { DatiAnagrafici : { IdFiscaleIVA : { IdPaese : ' IT ' , IdCodice : ' 01234567890 ' }, Anagrafica : { Denominaz

If you manage PostgreSQL databases across multiple environments, you've probably done this: SSH to the DB host (or connect via psql ) Run CREATE USER jsmith CONNECTION LIMIT 20 PASSWORD '...' Slack the password to the developer Forget to log it anywhere Repeat for every environment, every onboarding, every access request It's tedious, error-prone, and leaves zero audit trail. Here's a better way. What I Built pg-user-api is a lightweight Flask REST API that wraps PostgreSQL user provisioning in clean HTTP endpoints. You register your databases once in a SQLite inventory, then any tooling — CI pipelines, internal portals, Ansible playbooks, or a plain curl — can create and manage users across environments without ever touching psql . GitHub: pcraavi/PostgreSQL-user-creation-API The Problem It Solves In teams that span dev, QA, UAT, and prod, you end up with different patterns of users: App service accounts — named after the host/port combo ( web01_8080 ) Kubernetes workload accounts — named after env prefix + farm ( dv_gearservice ) Individual dev/QA accounts — low connection limits, scoped to non-prod Read-only analyst accounts — prod only, no DDL DBA accounts — CREATEDB CREATEROLE LOGIN , rarely provisioned Each type has different CONNECTION LIMIT values, privilege levels, and naming conventions. Encoding these patterns in an API means the rules are consistent, repeatable, and auditable. Architecture The project is intentionally small — five Python files and a requirements list: pg_user_api/ ├── app.py # Flask app — all endpoints ├── auth.py # HTTP Basic Auth (constant-time compare) ├── database.py # SQLite registry + audit log ├── notifications.py # Notification stubs (Webex / Slack / Email) ├── seed_db.py # One-time setup: creates DB + sample records └── requirements.txt Two credential pairs, clearly separated: PG_API_USER / PG_API_PASS — who can call this API (your team/tooling) PG_ADMIN_USER / PG_ADMIN_PASS — the PostgreSQL DBA role that executes DDL The DBA cr

This is a submission for the GitHub Finish-Up-A-Thon Challenge What I Built GlowStore — a full-stack MERN e-commerce store (React + Redux + Express + MongoDB). Back in 2023 I built this as my university Web Engineering final project. I ran out of time, handed in what I had, and never touched it again. When I reopened it for this challenge I found something funny: the backend was basically finished — JWT auth, products, orders, reviews, search — but the React frontend never actually talked to it. It was a good-looking shell with fake logic bolted on. So "finishing it" meant connecting the two halves and making it a real store you can actually shop in. Repo: https://github.com/hashaam-011/Web-Engineering Demo Before — the entire app was just a fake login screen. Typing anything (or nothing) and clicking "Log in" flipped a boolean and "logged you in": After — a working storefront with products from the database: A real product detail page (was literally <h1>DetailsPages</h1> before): You can run it yourself in two terminals (no database setup needed — it boots an in-memory MongoDB and seeds itself): cd backend && npm install && npm start # http://localhost:4000 npm install && npm start # http://localhost:3000 Demo login: user@example.com / 123456 — or register a new account. The Comeback Story Here's what the project looked like before , and what I changed: Before After Login dispatched a boolean and ignored your credentials Real login/register against the API with JWT + bcrypt Frontend never called the backend (no axios anywhere) Axios client with token injection; products load from MongoDB Product details page was <h1>DetailsPages</h1> and wasn't routed Full details page (image, price, stock, rating) routed by slug Cart was local-only; "checkout" button did nothing Persistent cart → checkout → real order placed and saved Backend had a reviews endpoint the UI never used Product reviews: read them and post your own with a star rating Only 3 routes; most of the app was

Daily Learning part twenty-two. I haven't been active in three days due to Eid Al‑Adha. On Tuesday I went to my family house, where we go once in a while. We call it the family house because that's where my grandmother, uncles, aunts, and cousins live. I didn't bring my laptop with me because I wanted to spend some time with my family, which I haven't done in months. I stayed there for the two days of Eid. Today I came back by bus. I was supposed to arrive at 17:00, but due to traffic I arrived at 18:40. When I arrived I ate a small sandwich and got back to work. I started the session at 19:30. The first thing I did was complete the HTML Tables section. It was difficult to learn (at least for me). It covered HTML Tables, Table Borders, Table Sizes, Table Headers, Padding & Spacing, Colspan & Rowspan, Table Styling, Table Colgroup, Exercises, and finally the Code Challenge. Then I did a quiz and the Unit 2 test in Khan Academy and also completed one lesson in Unit 3. Now I have started a Tic‑Tac‑Toe challenge in Python. I watched a video on the minimax algorithm, which the game uses. I have started coding, but I am far from finishing it. I am ending today's session at 23:40. Eid Al‑Adha Mubarak to all Muslims. "Speak good or remain silent." Prophet Muhammed (peace be upon him)

I'm a maxillofacial surgeon in Ouagadougou, Burkina Faso — and a self-taught builder who's been coding since medical school. Over evenings and weekends, I shipped Readium — a production AI reading app that lets you discuss books with Claude while you read them, in any language. Built AI-paired with Claude, reviewed and deployed by me. Most "I shipped an AI app" write-ups cover the happy path: clone a starter, glue an LLM, deploy to Vercel. The walls I hit weren't there. They were in the spaces between the libraries. Here are five of them — and what I'd tell myself a few weeks ago. Wall 1 — SSE streaming broke at the seam between the LLM and the browser I assumed streaming "just worked" once OpenRouter returned a stream. It does — until your server-side handler, your reverse proxy, or your browser code introduces a buffer somewhere along the path. The chain has at least three places where buffering can silently kill streaming: The LLM API (fine on its own) Your Node server-side handler (fine if you forward chunks instead of accumulating them) The reverse proxy / CDN (often buffers entire responses by default) The failure mode is always the same: the UI looks exactly like the LLM is slow. It isn't — somewhere between OpenRouter and the browser, bytes are being withheld until the connection closes, then dumped in one chunk. What I'd tell past-me: streaming isn't a feature of the LLM, it's a property of your entire request path. If you can't watch tokens land character-by-character in curl -N against your origin, you don't have streaming, you have a slow non-stream pretending. Set Cache-Control: no-transform and X-Accel-Buffering: no headers from your handler, disable response buffering on every layer in front of it, and verify with curl -N before you trust the UI. Wall 2 — fetch hangs forever on certain hosts (and the fix isn't where you think) I had a proxy route that fetched from an external API. Worked locally. Worked in staging. Deployed to production: the route wo

I have a PHP and MySQL website that I built myself and I want to make an app for my website. I am currently running an app with website2native app or hybrid if you know what that is. Do you recommend me learning a language like Dart to make apps or should I focus on PHP? submitted by /u/FarrisFahad [link] [留言]

Question from the title. For years and years I have a recognizable style of making UI and I have experienced that people think that those applications/sites were generated by AI even though this is not true, and some applications were made before gpt 3.5 and before the commercialization of LLM. I have always tried to make the design look modern and the fact is that LLMs were trained in such a style and that is why we come to such a problem. submitted by /u/Excellent-Article937 [link] [留言]

Hello, How can I implement a component overlay, like a dropdown or popover, so it escapes its parent container instead of being clipped, hidden, or expanding the parent layout? I managed to do it with getBoundingClientRect(), store the position in state and apply it as fixed positinioning. Even though it seems to work, wonder if there is a better solution. Thank you. submitted by /u/prois99 [link] [留言]