标签：#dev

I and I imagine a lot of other folks, don't believe the future of work should be a smaller group of executives commanding a larger system of people and machines. We have seen what AI can do not just to software product quality without guardrails, but to the junior and midlevel team members who are laid off or never hired at all in exchange for better profit rates with AI tokens vs human salaries. That is just the old hierarchy with better software. The history of work has always had this tension. You can go back to the start of US history and look at the military, commissioned officers were trained and trusted to command while enlisted service members carried out the work and risk. In the corporate and business world, executives and managers became the people who planned, measured, and optimized, while workers became the people being measured. Those structures were not only about class, but race and in America they were built inside a society already shaped by racism, classism, unequal education, unequal access to capital, and unequal access to leadership. AI now forces us to confront that history again. If we are not careful, AI will not flatten organizations. It will make the hierarchy invisible. Instead of a manager with a clipboard, we will have an algorithm. Instead of a foreman with a stopwatch, we will have dashboards, productivity scores, automated performance reviews, and AI systems that decide who gets opportunity and who gets replaced. That is not progress. The goal should not be to replace people with AI. The goal should be to replace bureaucracy, repetitive work, bad process, and unnecessary gatekeeping. What I am trying to do at Buildly is simple: AI should remove drudgery, not dignity. Automation should increase agency, not surveillance. Productivity gains should be shared, not extracted. Hierarchy should be functional, temporary, and accountable — not a measure of human worth. This is why we talk about AI-native product development differently. An AI

An interactive visualization of how data moves across the Internet: • DNS lookup • TCP handshake • TLS encryption • HTTP requests • Routers and packets Built to make networking concepts easier to understand visually. submitted by /u/nulless [link] [留言]

On the side after work I've been experimenting a bit with aws cloud launching my own apps and website (its mostly for hobby/for fun not really expecting income but maybe one day) anyways, one of my website a couple months ago was hit by a bot attack which made my netlify monthly bill go from $20 to $140 in one day Which spooked me im not going to lie. And my knowledge of devops thing is so limited that I had to resort to asking ai to help debug this. We found that there was 8 million botted requests sent to my frontend website and on my .netify.app link netlify does not give you ddos protection unless you pay extra. My actual domain was protected by cloudfare rate limit I didnt even know I had this secondary domain for that website. Anyways that was useful discovery now I feel safer about netlify at least. I don't really want to give up this hobby. Is there anyway to get predictable billing I don't even mind if they shutdown my app if it exceeds usage. I read that fly.io is based on credit usage. Is that good for backend? submitted by /u/Ok_Indication_3656 [link] [留言]

Most AI short-form video demos skip the boring part. They show a finished TikTok, Reel, or YouTube Short. Maybe they show the prompt. Maybe they show the generated script or the final render. But the hard part is not making one video. The hard part is making the fifteenth video without the whole system turning into a pile of one-off scripts, half-remembered FFmpeg commands, broken captions, inconsistent hooks, and manual upload steps. That is where I think the conversation around AI video automation gets more interesting. Not: Can an AI generate a Short? But: What workflow does an AI agent need to generate Shorts repeatedly? I was looking at a Terminal Skills use case for building an AI short video generator, and the useful part is not the fantasy of "push one button, print infinite content." The useful part is the stack. The real job is a pipeline A short-form video generator sounds like one tool. In practice, it is a pipeline: topic research -> script -> voiceover -> footage or visual generation -> subtitles -> assembly -> platform formatting -> upload -> analytics Each step has different failure modes. Topic research can produce generic ideas. Scripts can be too long. Voice can drift from the brand. Footage can mismatch the narration. Subtitles can land under platform UI. FFmpeg can export a technically valid file that a platform still hates. Uploads can succeed in the API but fail the actual publishing workflow. If you try to solve all of that with one giant prompt, the agent has to keep too much operational knowledge in its head. That is fragile. The better pattern is to split the workflow into skills. What a skill gives the agent A skill is not just a code snippet. For this kind of workflow, a useful skill tells the agent: when to use this capability what inputs are expected what output should exist afterward what validation is required when to stop instead of pretending success That last point matters. For media automation, "the command ran" is not enough. Th

A post titled "Learn SQL Once, Use It for 30 Years" hit the front page of r/programming this week (307 points, 48 comments). The claim sounds like the kind of thing a database vendor would put on a billboard, so I went looking for the part that holds up. It turns out the longevity is not marketing. It is a property of how the language was designed, and it is the reason SQL is one of the few skills on a developer's resume that does not quietly expire. I run a site that compares developer tools, which means I spend a lot of time watching technologies rise, peak, and get replaced. Most of what you learn in this field has a half-life measured in single-digit years. The framework you mastered in 2019 is legacy by 2024. SQL is the strange exception, and the reasons are worth understanding before you decide where to spend your next month of learning. Where the staying power comes from SQL did not start as a language. It started as a math paper. In 1970, Edgar Codd published "A Relational Model of Data for Large Shared Data Banks," which proposed organizing data into tables of rows and columns with formal rules for combining them. IBM built a query language on top of that model in the mid-1970s, called it SEQUEL, and later renamed it SQL after a trademark conflict. The important detail is the order: the model came first, the language second. SQL is a surface over a mathematical foundation that has not needed to change. That foundation is why the skill compounds instead of decaying. When you learn SQL, you are not memorizing one vendor's API. You are learning the relational model, and the model is the same whether the data sits in Postgres, MySQL, SQLite, Oracle, or SQL Server. A join is a join everywhere. Move from one database to another and the syntax shifts at the edges, but the way you think about the problem carries over intact. Compare that to a frontend framework, where moving stacks means relearning how to think, not just how to type. Declarative is the whole trick

Hi everyone, I've been working on building my own website for my upcoming small business in the pest control. My set up is cloudflare for domain, Hostinger for hosting, and WordPress for CMS. I have a fair amount of coding and tech knowledge (Code simple things in a different languages and understand enough abouting coding to understand most non robust code; have also built a couple simple websites in wordpress) and really want to do things right. My question is what tools, choices, or practices are there that someone trying to research the space wouldn't be able to easily find that provide high value? Things deeper in scope than just building pages with custom blocks, using plug ins, and tweaking settings. Essentially, of the millions of tools and implementations existing in this space, where should a person looking to move from amateur to advanced but not career web dev look? And what is the value in those tools or choices? Additionally. outside of page speed insights, what audits are actually worth running to ensure everything is secure and running as smooth as possible without costing an arm and leg cumulatively? If you were a single person looking to build as professional of a website as possible, in a reasonable timeline (a month or two), what things would you really be focused on? My overall goal is to build everything as close to professional as a single person realistically could, so if you guys could help, I'd really appreciate it! Thanks in advance submitted by /u/ChestnetR [link] [留言]

Hello everyone, PHP comes up here from time to time, and I've noticed the discussion is usually based on what the language looked like 5+ years ago. Since I work with it every day and have genuinely come to enjoy it, I wrote a short article recapping where it actually stands today. It covers modern deployment (FrankenPHP, Docker), software architecture (modular monoliths, the Symfony kernel, agents), the type system and its tooling (PHPStan, PHP CS Fixer), and the state of concurrency (ReactPHP, Swoole, the True Async RFC). Full article: https://morice.live/posts/your-next-project-will-run-on-php/ Let me know if I missed anything, or if you'd like me to go deeper on a specific topic! submitted by /u/andre_ange_marcel [link] [留言]

The Uncomfortable Truth Here's a test: when your deployment fails in production, what happens to your main branch? If the answer is "the broken code is already merged" — congratulations, you're doing CI/CD with a Git trigger. That's not GitOps. It's a pipeline that happens to watch a branch. I've spent years building platform engineering systems at enterprise scale — identity management frameworks, infrastructure-as-code pipelines, AI agent platforms that manage operational code. And I keep seeing the same mistake: teams adopt "GitOps" by adding a deployment step after merge, then wonder why they get drift. True GitOps has one non-negotiable rule: main always equals production. If a deployment fails, main doesn't change. Period. This isn't just my opinion — it's the logical extension of OpenGitOps principles : declarative desired state, versioned in Git, automatically reconciled. The enforcement mechanism I'm describing is how you make those principles real rather than aspirational. The Anti-Pattern Everyone Runs The most common "GitOps" setup I see in enterprise teams looks like this: Developer opens PR CI runs tests Reviewer approves PR merges to main Deployment triggers from main ❌ Deployment fails main now contains code that isn't in production This is merge-then-deploy . It's standard CI/CD with extra steps. The moment you merge before confirming a successful deployment, you've broken the core GitOps contract: Git as the single source of truth for what's actually running. The result? Drift. Stale state in main . A branch that lies about what's deployed. Every subsequent PR is now based on a broken foundation. The Enforcement Pattern: Deploy Before Merge The fix isn't philosophical — it's mechanical. GitHub's Merge Queue gives you exactly the right primitive: Developer opens PR CI runs tests (standard checks) Reviewer approves → PR enters the merge queue Merge queue trigger runs a dry-run deployment against the target environment If dry-run passes → queue trigge

This is a submission for the GitHub Finish-Up-A-Thon Challenge What I Built FlowDesk is a fully offline, production-quality productivity dashboard that combines three tools I always wanted in one place — a habit tracker, a Pomodoro focus timer, and a Kanban task board — all in a single beautiful React app with zero backend and zero accounts required. 🔗 Live Demo: https://flow-desk-lovat.vercel.app/ 💻 GitHub: https://github.com/red-coder-27/flow-desk Everything runs entirely in your browser via localStorage. Your data never leaves your device. Core Features 🎯 Habit Tracker GitHub-style 84-day contribution heatmap Streak tracking with fire badges 🔥 Emoji + color customization per habit Confetti celebration when you hit 100% for the day 🎉 Daily/Weekdays/Weekends frequency options ⏱️ Pomodoro Focus Timer Animated SVG countdown ring with glow effect Web Audio API chimes — no audio files needed Session history log with weekly focus stats Keyboard shortcuts: Space / R / S from any page Auto-switches between work and break sessions 📋 Kanban Task Board Full drag-and-drop via @dnd-kit (mouse + touch) Priority badges: 🔴 High / 🟡 Medium / 🟢 Low Live search + priority filter Three columns: To Do → In Progress → Done 📊 Unified Dashboard Real stats pulled from all three modules Weekly focus bar chart (Recharts) Daily motivational quote Quick-action buttons to jump into any module And more: Dark/Light/System theme, PWA installable, full keyboard shortcuts, data export/import, mobile bottom nav, glassmorphism UI. Demo 🚀 Try FlowDesk Live → Works best in Chrome. Install as a PWA for the full experience (look for the Install button in the top nav). Screenshots: Loom walkthrough video here: https://www.loom.com/share/f3c750d782694baf876229ab598695dc The Comeback Story Where It Started (The "Before") I originally started FlowDesk about 6 months ago during a weekend hackathon. The idea was simple: I was tired of switching between three different apps — one for habits, one for a Pomodoro

Google shipped Gemma 4 12B this week — a model that packs near-26B performance into something that runs on a consumer laptop with 16GB of RAM or unified memory. That alone would be notable. But the more significant move is the architecture: no multimodal encoders at all. Vision and audio go straight into the LLM backbone. "Gemma 4 12B packages powerful capabilities inside a reduced memory footprint. It is also our first mid-sized model to feature native audio inputs." — Google DeepMind What actually changed Encoder-free multimodal : Traditional multimodal models pipe images and audio through separate encoder networks before the LLM ever sees them. Gemma 4 12B removes those entirely. Vision gets a lightweight embedding module (a single matrix multiplication + positional embedding). Audio skips encoding altogether — the raw signal is projected directly into the same token space as text. Near-26B benchmark performance at half the footprint : On standard benchmarks it runs neck-and-neck with Gemma 4 26B, and actually surpasses it on DocVQA (document visual question answering). A new slot in the lineup : April's Gemma 4 release had E2B/E4B for mobile/IoT, and 26B/31B for heavier compute. The 12B fills the gap — more capable than edge models, runnable without a GPU server. Drafter-ready : Ships with Multi-Token Prediction (MTP) drafters to reduce inference latency. Apache 2.0 : Open weights, available now on Hugging Face, Kaggle, Ollama, and LM Studio. Why the architecture matters Encoder-free isn't just an efficiency hack — it's a different architectural bet. Separate encoders add latency, memory overhead, and a seam in the stack that limits how tightly vision and language reasoning can be integrated. Removing them means the LLM backbone handles the full chain from pixels and audio waveforms to text output, which allows for tighter cross-modal understanding rather than bolted-on modalities. Whether that bet pays off at scale is still an open question. But for local deplo

https://youtu.be/gd3QLL63bT0 submitted by /u/Prize_Concept_41 [link] [留言]

Pattern Recognition: The Secret Weapon Top Coders Actually Use Quick context (why you're writing this) I was knee‑deep in a legacy codebase last month, trying to fix a report that kept timing out. The function was supposed to flag any user who made three purchases from the same merchant within a five‑minute window, but the original author had written three nested loops that ran in O(n³). After staring at it for two hours I felt that familiar sinking feeling— there’s got to be a better way . Then I noticed the code kept doing the same thing over and over: looking for a recent occurrence of a value within a sliding window. That’s when it clicked: I wasn’t looking at a unique problem; I was seeing a pattern I’d solved a dozen times before, just dressed up in different variable names. The moment I recognized that pattern, the solution fell into place in minutes instead of hours. The Insight Top coders don’t rely on genius flashes; they rely on a mental library of patterns —recurring shapes of problems and their corresponding solutions. When faced with new code, they ask themselves: “What does this remind me of?” If they can map the current shape to a known pattern (like sliding window, two‑sum, divide‑and‑conquer, or observer), they instantly know which data structures and algorithms fit, and they can skip the trial‑and‑error phase. It’s not about memorizing answers; it’s about training your brain to spot the underlying structure so you can reuse proven solutions. The trade‑off is that you need to invest time upfront to build that library, but once you have it, you solve problems faster, write fewer bugs, and can explain your reasoning to teammates in a language they already understand. How (with code) Let’s walk through the exact problem I was tackling: detect users who made ≥ 3 purchases from the same merchant within any 5‑minute interval . The naïve attempt (what most of us write first) function flagFraudulent ( users ) { const flagged = new Set (); for ( let i = 0 ;

Static Application Security Testing (SAST) is a critical practice in modern DevSecOps. While tools like SonarQube, Snyk, and Veracode are popular, this article focuses on GitHub CodeQL – a semantic code analysis engine that treats code as a database. We will apply it to a vulnerable Java Spring Boot application to detect SQL Injection and Path Traversal. 🤔 Why CodeQL? Unlike pattern-based scanners, CodeQL builds a relational database of your code, including abstract syntax trees, control flow graphs, and data flow graphs. This allows it to track tainted data across functions, classes, and files, drastically reducing false positives. 🚨 Target Application (Vulnerable Java App) Let's look at a simple REST API with two vulnerable endpoints. File: UserController.java package com.demo.controller ; import com.demo.model.User ; import org.springframework.beans.factory.annotation.Autowired ; import org.springframework.jdbc.core.JdbcTemplate ; import org.springframework.web.bind.annotation.* ; import java.nio.file.Files ; import java.nio.file.Paths ; import java.util.List ; @RestController @RequestMapping ( "/api" ) public class UserController { @Autowired private JdbcTemplate jdbcTemplate ; // Vulnerability 1: SQL Injection @GetMapping ( "/users" ) public List < User > getUsers ( @RequestParam ( "id" ) String userId ) { String sql = "SELECT * FROM users WHERE id = " + userId ; // Dangerous concatenation return jdbcTemplate . query ( sql , ( rs , rowNum ) -> new User ( rs . getString ( "id" ), rs . getString ( "name" ))); } // Vulnerability 2: Path Traversal @GetMapping ( "/file" ) public String readFile ( @RequestParam ( "filename" ) String filename ) throws Exception { return new String ( Files . readAllBytes ( Paths . get ( "/var/data/" + filename ))); } } 🛠️ Installing and Configuring CodeQL CLI You can run CodeQL locally to analyze your code before pushing it to a repository. 1. Download CodeQL from GitHub releases: wget [ https://github.com/github/codeql-cli-binaries/re

A bit of context: I'm having fun building my app. I'm trying to built something truly great for monitoring. I run a pool of workers on a couple of VPSes and probes about 10k endpoints on a tight loop down to every 15 seconds. The part that was quietly bleeding money, was that every probe result got written to our document db and all dashboards subscribed to those documents with real-time listeners (onSnapshot). In Firestore that's the obvious way to build a live dashboard and it actually works great until you draw out the actual data flow: workers write on every cycle every write fans out to a read to every browser that is running the dashboard so cost just scales with amount of cycles and open dashboards The database quietly became a message bus with billing on every message. I guess this is how you learn about proper architecture the hard way. 😄 A good Friday evening, with a glass of whisky, I decided to make something cool. I wanted a true live experience for the users, directly on the website. Basically something that looked directly into the VPS. So I flipped it. The WebSocket is the source of truth for live fields The DB gets demoted to config + state transition "Still up" heartbeats get batched, instead of writing "200 OK" everything cycle, we switch to a transition model and flush the no-change on a interval Results: ~95% fewer DB writes Live status reads went to zero Time from probe to pixel went from 1-3 seconds to <300ms (p90) It feels a bit like cheating. Making the product insanely more cool and useful, while also cutting costs, and not only cutting immediate costs. This thing scales like crazy. Basically the only real thing needed is a good amount of memory. Memory is not cheap nowadays, but it's definitely cheaper than continuous real-time DB reads and writes. Some tradeoffs worth mentioning. I kept the DB listeners as fallback if socket drops. The UI degrades instead of breaking. Websockets are real ops work. Is has become a bit harder to maintain an

This is a submission for the GitHub Finish-Up-A-Thon Challenge Note: AI is currently a Hot Topic in...

I work as a Developer Advocate helping people ship web apps as native mobile apps, and I kept answering the same questions over and over. So I wrote a guide that summarizes everything I recommend, based on 13+ years working in mobile development. From what I've seen, every time someone in a web dev community asks "how do I publish my React/Vue/Angular app to the App Store?", the answers are either "just make a PWA" (which doesn't actually get you on the stores) or links to tutorials that assume you already know what a provisioning profile is and have Xcode configured on a Mac. This one starts from zero. It's structured as an index, not a wall of text. Each step links to specific posts, videos, tools, and automation resources so you can go as deep as you need, at your own pace. Some things I cover that I rarely see explained well: - Why PWAs won't get you into the App Store or Google Play (and what to use instead) - How to generate iOS certificates directly from your browser, without a Mac or Keychain Access - The Google Play closed testing requirement that blindsides most first-time publishers: personal accounts created after November 2023 need 12 testers actively opted in for at least 14 consecutive days before you can go public. - Why you should install the Live Update plugin in your very first release, even if you have nothing to update yet. Adding it later means another full native build and another review cycle, which is the last thing you want when you're trying to push a critical fix. - How to build for iOS without owning a Mac Honest feedback welcome: is there a step that's unclear, or something you think is missing? https://capawesome.io/blog/11-steps-to-get-your-web-app-on-the-app-store/ submitted by /u/DayanaJabif [link] [留言]

I feel like this might start becoming a lot more common, due to all the hype and marketing surrounding AI. Seems a lot of ppl believe anyone can build an app in one-shot and we don’t need experienced engineers anymore. When they ask a question like “why can’t we just one-shot the app”, it puts you on the hot seat to explain the entire development process to them, and all the steps it takes to get to a production quality app. AI can be used to assist and augment that process but you need a human in the loop to know and understand what they are doing. Rather than just telling them “go ahead and try it yourself”, how would you respond to this? How would you explain why AI can’t just make the entire app? How would you breakdown the step by step process of building an entire application? Thanks submitted by /u/throwaway0134hdj [link] [留言]

I'm working on a personal one-man project. It's very simple : it's a static website generated from some data stored in a JSON file. I have a prototype written in TypeScript/TSX, consisting of fewer than ten files (views), each containing an average of less than fifty lines of code. Only two of the pages retrieve data from JSON; the rest are simple TSX files that describe the project (pages like "About" or the "Privacy" page). Given how simple it is, I thought I'd go the extra mile and focus heavily on ensuring the entire code, from the build process to the distribution, is 1000% correct, stuff like: crazy type safety 0% chance of logical and consistency errors validation of JSON against a schema HTML (and attributes) that conforms to the specifications (no mains inside spans, no booleans inside hrefs...) I started exploring the various programming languages that allowed me to do all these things at once, and I found OCaml . It: is statically typed has yojson to parse JSON and into a nested OCaml tree data structures has tyxml to build valid HTML. If I understood correctly, it has the distinctive feature of performing strict checks on (HTML) element's attributes while libraries in other languages simply accept any string To be honest, I also looked into Elm , which seems to be even more lenient when it comes to error handling; however, its HTML generation library doesn't seem to have strict controls over attributes, not nearly as strict as tyxml. Is there something even more powerful that allows me to achieve what I want (code safety and error free) or is OCaml already the best? If so, what has been your experience with it? Any advice? I'll say it again: the project is so simple that you could rewrite it in any programming language in an hour, it's no problem for me. It's a chance to learn something new. Thanks in advance. submitted by /u/Wise_Stick9613 [link] [留言]

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] [留言]