标签：#programming

I wanted to understand how template engines and markdown parsers work internally. The project explores: compiling templates into Python functions using exec() block + inline markdown parsing simple AST construction stack-based inline parsing for nested formatting rendering the AST into HTML submitted by /u/mukulx99 [link] [留言]

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

I once spent nearly a week trying to fix a web scraper that, on paper, had absolutely no reason to fail. The target website wasn't using aggressive, visible defense walls. My script spaced out requests naturally, rotated common user agents, and used browser automation configured to mimic human interactions down to mouse movements. Yet, the results were an absolute nightmare. Some batches of requests would go through cleanly, while others immediately triggered CAPTCHAs or returned 403 Forbidden errors. Every single time I thought I had patched the logic, the failure rate climbed right back up. Like most developers, my default instinct was to assume the application layer was broken. I went down a rabbit hole optimization sprint checking request headers, browser fingerprints, cookies, and session persistence. Nothing explained the wild inconsistency until I noticed a strange clue: some proxy pools performed beautifully, while others crashed on the exact same codebase. The code wasn’t the issue. The culprit was a fundamental misunderstanding of proxy network architecture. Looking Beyond the IP Address: Enter the ASN For a long time, I treated proxies as interchangeable commodities. An IP address was just an IP address, and if one got blocked, you simply rotated to the next. Modern anti-bot solutions like Cloudflare, Akamai, and PerimeterX don't look at IPs in a vacuum. They analyze network layer characteristics, specifically the ASN (Autonomous System Number). An ASN is a unique identifier assigned to a network operator that defines who owns and routes an IP range. When your scraper hits a website, the target's security system looks up your ASN to check your network identity. If your traffic originates from a commercial hosting provider or data center ASN, it carries an automatic penalty score for sensitive endpoints. To build reliable systems, you have to move past basic rotation and understand the two core proxy frameworks that mask this identity: ISP Proxies and Resi

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

I wrote a short article about why Pandas is worth learning from a general programming perspective, not just a data science one. A lot of everyday programming work involves tabular data - CSV files, reports, logs, exports, billing data, sales data, inventory data, operational spreadsheets, analytics extracts, etc. You can process that kind of data with loops and dictionaries, SQL, shell tools, or spreadsheets. But Pandas gives Python a very compact and expressive way to do filtering, grouping, aggregation, joins, and reshaping in code. The article uses a small sales/purchases CSV example and compares the Pandas approach with plain Python and spreadsheet-style thinking. I’m curious how other programmers think about this: is Pandas one of the libraries that makes Python worth learning, even for people whose main work is not data science? Or would you usually reach for SQL, spreadsheets, shell tools, or something else? submitted by /u/Horror-Willingness74 [link] [留言]

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

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

Prompts rot. Captured failures compound. Most of the AI skills you are building are mostly prompt, which is why most of them will not survive the year. Not because the prompts are bad. A skill's value is maybe twenty percent instruction and eighty percent scar tissue, and only that second part lasts. The instruction rots the moment the thing it describes moves. Encode how your team deploys and it works until the pipeline changes. Then you are debugging a prompt at 2am, with less to go on than if you had written the script yourself. So before you build another one, stop asking whether the prompt is good. Ask what the skill is holding onto, and whether that thing sits still. A skill rots at the speed of what it touches A skill rots in proportion to how tightly it is coupled to things that move. Generic scaffolding leans on stable ground like a language or a convention, so it ages slowly. Domain logic wired to a codebase that gets refactored every quarter ages fast, no matter how good the prompt is. The difference is the dependency count. "Write a unit test in this style" depends on a language and a convention. Both barely move. It keeps working for years because nothing under it shifts. Real company-specific procedure is the opposite. File layouts. Service contracts. The one edge case in the billing flow. Each detail you pack in is a thread tied to something that gets refactored. Pack in enough of them and the skill is not a tool anymore. It is a liability with good intentions, and it fails silently, because a stale prompt does not throw. It quietly does the wrong thing. That is what the skill-library pitch gets backwards. Volume is not value. A hundred skills wired to a moving codebase is a hundred things to maintain. The only part that compounds is the scar One part of a skill does not rot. The captured failure. The five-line check you added after a model confidently reported a 41 percent dividend yield. The retry that refuses to fire twice so a flaky webhook cannot

In my previous article, I argued that AI is just the next abstraction layer — the same pattern we’ve seen a dozen times in software history. Each layer demands a new skill. So what does the AI layer demand? I think the answer is hiding in plain sight. And some very powerful people just demonstrated it. Something Interesting Happened Recently Mark Zuckerberg started coding again after a 20-year break. According to multiple reports, he moved his desk to Meta’s AI lab, spends 5 to 10 hours a week writing code, and is “coding all day long” alongside the Meta Superintelligence Labs team. The man who built Facebook in a dorm room and then spent two decades managing tens of thousands of people — is shipping diffs again. Garry Tan, CEO of Y Combinator, returned to coding after 15 years using AI tools like Claude Code. He described himself as “addicted” to it, sleeping four hours a night because he couldn’t stop building things. Sergey Brin, Google’s co-founder who stepped back from day-to-day operations years ago, came out of retirement to code on Gemini. He’s reportedly assembling an elite “coding strike team” and is directly involved in hands-on development. And there’s a quote from The New Stack that captures this perfectly: executives are building with AI because they were “tired of explaining it to somebody who was supposed to build it for me.” Why is this happening? These people haven’t written production code in over a decade. What changed? The Career Ladder Was Always About Communication Let’s take a step back. The most common career paths for a developer are either the strict technical way — from developer to tech lead, then architect — or the management way — team lead, then head of engineering, CTO. In both ways you start from doing things yourself and gradually move to teaching — or better to say, guiding — others how to do it. Or strictly overseeing the whole process. You stop writing code and start writing explanations. You stop implementing and start reviewin

MD5 Is Broken — Stop Using It for Passwords (Use SHA256 Instead) MD5 was invented in 1991. It's 2026, yet I still see developers using MD5 for password hashing in production systems. Let’s break down why this is dangerous and what you should use instead. What Is a Hash Function? A hash function takes any input and produces a fixed-length output called a digest or hash . It is a one-way function , meaning you cannot reverse it to get the original input. Example: ```text id="hash1" Input: "password123" MD5: 482c811da5d5b4bc6d497ffa98491e38 SHA256: ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94f Even a small input change completely changes the output. --- # Why MD5 Is Broken MD5 generates a **128-bit hash**, which was considered secure decades ago. Today, it's extremely weak. Modern GPUs can compute **billions of MD5 hashes per second**, making brute-force attacks trivial. --- ## The Rainbow Table Problem Attackers use precomputed databases called **rainbow tables**. These tables map common passwords → their hash values. So if you hash: ```text "password123" → MD5 → known value An attacker can instantly look it up. Collision Vulnerabilities Researchers have demonstrated that two different inputs can produce the same MD5 hash . This breaks the core security guarantee of hash functions. SHA256 — The Better Choice SHA256 produces a 256-bit hash and is part of the SHA-2 family. It is currently considered cryptographically secure. Example: ```text id="sha1" "hello" → 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 Even tiny changes completely change the output: ```text "hello" → 2cf24dba... "Hello" → 185f8db3... But Wait — Don’t Use SHA256 for Passwords Either This is where many developers make a mistake. SHA256 is not suitable for password hashing . Why? Because it is too fast . Fast hashing allows attackers to brute-force passwords quickly using GPUs. What You Should Use Instead For password storage, use: bcrypt scrypt Argon2 (recommended

A visual, beginner-friendly Java 25 experiment that explains virtual threads, blocking work, carrier threads, and the production rules that matter.

NewsScope is a real-time news search engine: search a topic, filter by language, category and country, get live results from the NewsData.io API. No React, no bundler, no npm dependencies — just HTML, CSS and vanilla ES2020+. This post is about a few specific decisions in the architecture that I think are worth sharing. The module structure The JS is 9 files, each with a single responsibility, loaded in dependency order directly in index.html : config.js → i18n.js → data.js ↓ ↓ ↓ helpers.js → geo.js → ui.js ↓ ↓ ↓ render.js → api.js → main.js Every module only uses things defined in modules loaded before it. main.js registers all event listeners and calls init() — it's the only file that touches everything. config.js is the smallest file in the project, since it only defines the state object and two constants. All app state lives in a single flat object in config.js , accessed as a global: const S = { apiKey : '' , query : '' , activeQuery : '' , language : ' es ' , category : '' , country : '' , results : [], nextPage : null , loading : false , hasSearched : false , error : null , }; No state management library. When something changes, the relevant render function gets called explicitly. Simple, and easy to trace. Translating search intent, not just the UI Most i18n stops at labels and button text. NewsScope has 10 predefined topic shortcuts (AI, Climate, Economy, Cybersecurity…) that trigger a search. If a user picks "Cybersecurity" while the app is set to Japanese, the keyword sent to the API should be in Japanese — not a transliteration of the English word. The solution is a TOPIC_KEYWORDS map in data.js : const TOPIC_KEYWORDS = { ai : { es : ' inteligencia artificial ' , en : ' artificial intelligence ' , ja : ' 人工知能 ' , ar : ' الذكاء الاصطناعي ' , /* 7 more */ }, cyber : { es : ' ciberseguridad ' , en : ' cybersecurity ' , ja : ' サイバーセキュリティ ' , /* 8 more */ }, // 8 more topics }; One string per language, per topic. Switching the UI language and then selecting a

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

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

I got tired of watching coding agents spin up from scratch every single time I sent them a prompt. Cold starts, re-cloning massive monorepos, pasting the previous context into a synthetic prompt block — it worked, but it felt fundamentally wrong for agents that are supposed to think in conversations. So we shipped persistent sessions for the Critique Coding Agent API . Here's what changed, why the harness matters, and why you should never run a coding agent without a review skill. The Problem: Agents That Forget When we first released the Coding Agent API, follow-ups were honest but clunky: every follow-up was a brand-new job. The previous output was replayed as plain text into a fresh sandbox. It was the right MVP. It billed predictably. It never pretended a dead sandbox was alive. But it was the wrong long-term shape. If your internal bot fixes a migration, then wants a follow-up test, then wants a small doc tweak — you don't want three cold starts. You want: One repository checkout One OpenCode session A control plane that understands turns What Changed: Persistent Sessions After the first turn completes, the run now enters idle status. The E2B sandbox and OpenCode server stay up until sessionExpiresAt or until you explicitly POST endSession: true . The next prompt you send is delivered as a real message in that same session — not a synthetic "prior run output" block in a brand-new sandbox. Before (Chained MVP): Turn 1 completes → Sandbox killed → Turn 2 = new job + pasted prior summary Now (Persistent): Turn 1 completes → idle → Sandbox warm → Turn 2 = message into same OpenCode session Same run.id . Same checkout. Same context. Just the next turn. How It Works Under the Hood On the first turn, Critique: Creates an E2B sandbox from the OpenCode template Clones your repository at the requested ref Bootstraps tooling and starts opencode serve on localhost inside the VM Opens an OpenCode session Instead of killing that sandbox after completion, we now store session

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

Hey devs! 👋 I'm the creator of this project, and I'm looking for help with an open issue: https://github.com/PedroVitor-Dev/Ped-Os/issues/1 If you're interested in contributing, reviewing possible solutions, or simply sharing ideas, I'd love to hear your thoughts. Contributions of all sizes are welcome, especially from developers looking to get involved in open source. Thanks in advance! 🚀💚 submitted by /u/Opposite-Stranger- [link] [留言]

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

The hidden cost of AI isn't generating code. It's understanding your codebase. For a long time, I assumed AI coding tools became expensive because they generated a lot of code. These tools can produce components, tests, SQL queries, documentation, and sometimes entire features on demand. If costs were climbing, the output volume must be the reason. The more I used these tools, the more I realized I was measuring the wrong thing. The expensive part isn't writing code. The expensive part is understanding what code should be written — and that work is mostly invisible. That realization changed how I think about AI-assisted development entirely. Two Prompts, Two Very Different Problems Consider these two requests: "Create a utility function that formats dates" and "Review this feature and suggest improvements." At first glance, both look ordinary. Both might even produce short answers. But they require completely different levels of understanding. The first is narrow and well-defined. The AI needs very little information before it can produce a useful answer. The second is open-ended. Before suggesting a single improvement, the AI may need to read multiple files, understand dependencies, follow existing patterns, compare implementations, and build a mental model of why the feature exists at all. The output might still be small. The work required to reach it is not. Why Agent Workflows Feel Different From Autocomplete This became much clearer when I started using AI agents. Traditional autocomplete is predictive — you type, the AI guesses what comes next. It's fast, cheap, and deliberately context-light. Agents behave differently. When you ask one to improve a feature or review a workflow, it doesn't immediately start generating code. It starts reading. It follows imports, finds related files, and tries to understand the system before touching it. That is exactly what makes agent workflows feel slower and more resource-intensive than autocomplete: they are spending effor

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