标签：#programming

For a long time, I hesitated to share my work. I kept telling myself: "If I post a simple hero section, a basic Bootstrap grid, or a landing page clone, people will judge me. They’ll think I’m not a 'real' developer yet." But today, I saw a video of a developer who built a complete Netflix clone using only HTML & CSS in just 4 hours https://x.com/Aditwariii/status/1681403710457643009?s=20 . It made me stop and think. It’s easy to get so obsessed with complex frameworks, cloud architectures, and database optimizations that we begin to look down on the fundamentals. But here is the psychology of software engineering that we often ignore: Every master was once a beginner: The engineers managing complex distributed systems today started exactly where we are—struggling to center a div and fighting with CSS media queries. Shipping beats hiding: Building a clean, responsive interface in 4 hours shows speed, focus, and attention to detail. Those are core professional hygiene habits. Code is for humans, not just machines: Before we write APIs or database queries, we must master how a human being actually interacts with our interface. I’m letting go of the fear of being judged for "simple" things. From now on, I am building in public. Whether it’s a massive full-stack application or just a beautifully aligned hero section, it is proof of active practice and continuous momentum. Massive respect to [ https://x.com/Aditwariii?s=20 Check out Aditya Tiwari on X. POLYMATH 🧑‍💻 sde @IEX_INDIA_ ] for the inspiration and the reminder to keep shipping! 👇 What is a "small" project or layout you built recently that taught you a major lesson? Let's connect in the comments.

Java 26 was officially released in March 2026, and after spending the past three months exploring its new features, experimenting with preview APIs, and using it in personal projects, I think it's a good time to share my impressions. Unlike launch-day articles that simply list every new feature, this is a practical look at what actually stood out to me after having some time to work with Java 26. Some improvements are immediately useful, while others feel like building blocks for the future of the language. Java continues its predictable six-month release cycle, and Java 26 is another example of gradual, thoughtful evolution rather than dramatic change. In this article, I'll cover the features I found most interesting, what I like, what I probably won't use right away, and whether I think Java 26 is worth upgrading to. Why Upgrade to Java 26? Every Java release makes the platform: Faster More secure Easier to write Better for cloud applications Even if you don't immediately use every new feature, upgrading allows you to benefit from JVM optimizations and improved tooling. 1. Better Performance Java 26 continues improving the JVM with optimizations for: Faster startup Better garbage collection Reduced memory usage Improved JIT compilation Most applications will benefit automatically without changing a single line of code. 2. Improved Pattern Matching Pattern matching keeps becoming more powerful. Instead of writing: if ( obj instanceof String ) { String text = ( String ) obj ; System . out . println ( text . length ()); } You can simply write: if ( obj instanceof String text ) { System . out . println ( text . length ()); } Cleaner code with less casting. 3. Record Improvements Records remain one of Java's best additions for immutable data. public record User ( Long id , String name , String email ) {} Instead of writing dozens of lines containing: constructor getters equals() hashCode() toString() Java generates them automatically. 4. Better String Templates (Previe

[ Removed by Reddit on account of violating the content policy . ] submitted by /u/AnearlyApp [link] [留言]

Many AI projects today are presented as multi-agent systems. One agent investigates. Another agent analyzes risk. A third agent checks compliance. A fourth agent gives a recommendation. It sounds advanced. But in a bank, adding more agents does not automatically make a workflow safe. A bank cannot freeze a customer account, block a payment, file a regulatory report, or label a transaction as fraud simply because an AI system produced a confident answer. The real question is not: How many AI agents are involved? The real question is: Can the system show evidence, challenge its own conclusion, apply deterministic rules, and stop for human approval when the decision is high impact? That is the difference between an interesting multi-agent demo and an enterprise-ready AI workflow. A banking example: suspicious wire transfer Imagine a bank detects a wire transfer for $250,000. The payment is unusual because: The customer has never sent a transfer of this size. The destination account is in a new country. The transaction happens outside the customer’s normal business hours. The beneficiary was added only a few minutes before the transfer. The customer recently changed their phone number and email address. A simple AI chatbot might say: “This transaction looks suspicious. Consider blocking it.” That is not enough. A bank needs to know: Which transaction patterns triggered the concern? Is the customer actually violating a known risk threshold? Is there a sanctions or AML issue? Could this be a legitimate business payment? What policy applies? Should the payment be blocked, held, or released? Who is allowed to make that decision? Can the bank explain the decision later to auditors, compliance teams, and the customer? This is where structured multi-agent design matters. A better design: a banking fraud decision room Instead of letting one model make a decision, the bank can create a controlled workflow with specialized agents. Transaction Alert ↓ Fraud Detection Agent ↓ Custo

So far we've been working with Swift's built-in types — String, Int, Bool, Array. But what if you...

the insight that started this project hit me while i was finishing a bytecode-compiled language i'd written in C i'd spent months building a hand-written lexer, a single-pass Pratt compiler, a stack VM with 35 opcodes, and a mark-and-sweep garbage collector. and right near the end i had this realization: an LLM inference engine is the same problem. it's a graph-compile plus memory-plan plus kernel-schedule problem. i'd just built one so i decided to find out if that was actually true the project the result is ignis, a from-scratch LLM inference engine in Rust. i used it specifically to see how far the compiler analogy held up. the dependency count ended up at 2: memmap2 (to mmap the weight blob off disk) and fancy-regex (for one look-ahead in the BPE tokenizer). everything else is hand-written, because the whole point was to understand what's actually happening the compiler analogy holds up better than i expected the interesting part of any inference engine isn't loading the weights or doing matrix math. it's what happens between "here's a compute graph" and "here's an efficient execution plan." that's a compiler problem ignis builds an SSA (static single assignment) IR of the entire Qwen2 forward pass. every operation in the transformer (the RMSNorm layers, the SwiGLU activations, the attention projections, all of it) becomes a node in the graph with explicit data dependencies then fusion passes run over the graph. the intuition is simple: if operation B always and only reads the output of operation A, you can merge them into one op and eliminate the intermediate buffer. in practice this fused 49 RMSNorm ops and 24 SwiGLU ops, bringing the total from 435 operations down to 362 that part felt expected. the liveness analysis surprised me the liveness analysis after fusion, the graph still needs activation buffers: scratch memory to hold intermediate results as the plan executes. the naive approach allocates one buffer per node. the smarter approach asks: which buffer

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

If you ever find yourself with time to kill and crave a fun challenge, you can write a program that prints out its own source code, called a quine ). Go on, give it a try, it's good fun! Once that's done, what's to stop you from modifying the source code instead of printing it verbatim, slowly shifting forms as you iterate on each successive output? Naturally, you'll want to make a game that's played in its own source code (click for an animation): #include<stdio.h> #define z else #define y return #define x int #define w if( #define v putchar( #define B v 10); #define A v 92); /* IOCCC29, w = up, e = down */ x a= 32 ; x b= 6 ; x c= -1 ; x d= 1 ; x e= 5 ; x f= 10 ; x g= 62 ; x h= 5 ; x i[6]={ 1,3,1,4,1,0} ; char*j[]={ "\ \ #include<stdio.h>'#define$z$else'#define$y$return'#define$x$int'#defin\ e$w$if('#define$v$putchar('#define$B$v$10);'#define$A$v$92);''/*$IOCCC\ 29,$w$=$up,$e$=$down$*/''x$a=","32",";x$b=","6",";x$c=","-1",";x$d=","\ 1",";x$e=","5",";x$f=","10",";x$g=","62",";x$h=","5",";x$i[6]={1,3,1,4\ ,1,0};char*j[]={","","};x$k=0;x$l=1;x$m(){l++;w$l==1)y!v$44);w$l==2)y!\ v$34) ;char$o=j[k][l-3];w!o){l=0;k++;y!v$34);}w$o==34){A$y$v $34);\ }w$o= =92){A$y$A}w$o!=32&&o!=1 0)y!v$o);y$m();}void$n(x$o, x$p){\ aspri ntf(j+o,\"%i\",p);}x$mai n(x$o,char**p){char*q;w$c<2 )a+=c\ ;b+=d ;x$r=b+2>f/2&&b<f/2+5;x$s=a+2==g&&b+2>h&&b<h+5;w$c<2){ w$a==\ e+2&& r||s){a-=c;b-=d;c=-c;}w$a<0||a>67){w$a<0){c=2;d=0;}a=3 4;b=6\ ;}w$b<0||b>13){b-=d;d=-d;}w$f/2>10)f-=2;w$h>10)h--;w$o>1){w*p[1]==119&\ &h>0)h--;w*p[1]==101&&h<10)h++;}s=f/2-b+1;w$s<0)f++;w$s>0)f--;}z{b++;w\ $d<0)d++;w$b>=13){w$o>1&&*p[1]==119)d=-4;b=13;}w$f/2<15-i[c-2])f+=2;z$\ e--;w$h<15-i[c-1])h++;z$g--;w$e+3<=0){c++;w$c<7){e=g;f=h*2;g=70;h=15-i\ [c-1];}z{e=5;g=62;c=1;d=1;}}w$a+2==e&&r||s){c=2;e=5;f=28;g=62;h=12;}}n\ \ (1,a);n(3,b);n(5,c);n(7,d);n(9,e);n(11,f);n(13,g);n(15,h);for(s=0;s<","29",";s++){w$s)v$32);q=j[s];r=1;for(char*t=q;*t;t++)w*t==","36",")v$32);z$w*t==","39",")B$z$w*t!=32&&*t!=10){r=0;v*t);w*t==123||*t==125||*t

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

Hello, I'm Shrijith Venkatramana. I'm building git-lrc, an AI code reviewer that runs on every commit. Star Us to help devs discover the project. Do give it a try and share your feedback for improving the product. An AI model writes a paragraph. It sounds fluent. It looks convincing. But how do you know whether it's actually good? This deceptively simple question has occupied researchers for more than two decades. Long before ChatGPT, machine translation researchers faced exactly the same problem. Human evaluation was expensive, inconsistent, and painfully slow. If every new model required thousands of humans to compare translations, research would crawl. That necessity gave rise to BLEU , one of the most influential evaluation metrics in AI history. Years later, as language models became better at paraphrasing and reasoning, BLEU started to show its age. Researchers responded with learned metrics like BLEURT and COMET , which use neural networks to judge language much more like humans do. Interestingly, this mirrors software engineering itself. We first wrote simple unit tests, then integration tests, and today we increasingly rely on sophisticated observability systems. Evaluation metrics for LLMs have undergone a similar evolution. Let's see why. Before BLEU: The Evaluation Bottleneck Imagine you're building Google Translate in 2001. Every time your team improves the model, someone has to read thousands of translated sentences and score them. Suppose a single sentence pair takes only 20 seconds to judge. Evaluating 50,000 sentences would require nearly 280 human-hours . Now imagine dozens of experiments every week. Evaluation—not training—quickly becomes the bottleneck. Researchers at IBM, led by Kishore Papineni , introduced BLEU (Bilingual Evaluation Understudy) in 2002 to automate this process. Their idea was surprisingly simple: If a machine translation resembles what professional translators write, it's probably good. This became one of the most cited papers

How I built an open-source Slack assistant with persistent semantic memory, powered by any LLM and Mem0's managed memory layer — no vector database required. The problem with Slack bots and memory Most AI Slack bots have the memory of a goldfish. Every conversation starts from scratch. You ask it about your sprint goals, it gives a great answer, then three days later you ask a follow-up and it has no idea what you're talking about. You end up re-explaining context constantly. The commercial solution to this is Claude Tag — a Slack integration that maintains genuine conversational continuity. But it's tied to one provider and not open-source. slacktag-oss is our attempt to replicate that experience: a Slack bot with real, semantic, persistent memory that works with any LLM — including ones running entirely on your laptop. What I built A Python Slack bot with: Socket Mode for local dev (no public URL needed), HTTP-ready for prod LangChain to abstract LLM calls across any OpenAI-compatible endpoint Mem0 managed cloud for semantic memory — no Qdrant, no Pinecone, no infra to run Three memory scopes: per-channel, per-thread, per-DM Built-in !clear and !memory commands A clean, extensible architecture you can fork and build on Architecture Before diving into code, here's the full request lifecycle: ┌─────────────────────────────────────────────────────────────┐ │ Slack │ │ @mention in channel ──┐ │ │ DM to bot ──┼──► Slack Events API │ │ Thread reply ──┘ │ │ └───────────────────────────────────│─────────────────────────┘ │ (Socket Mode / HTTP) ▼ ┌─────────────────────────────────────────────────────────────┐ │ slack-bolt (Python) │ │ bot.py ──► router.py ──► handler.py │ │ │ │ │ ┌───────────────┤ │ │ │ │ │ │ ▼ ▼ │ │ Mem0 Client LangChain │ │ (managed) ChatOpenAI │ └────────────────────────────────────────────────────────────-┘ │ ▼ ┌───────────────────────┐ │ Mem0 Managed Cloud │ │ Vector Embeddings │ │ Entity Extraction │ │ Deduplication │ └───────────────────────┘ The ke

One thing I've noticed after using AI for development over the past year is this: The code it generates is usually correct. The architecture slowly isn't. That doesn't happen because AI writes bad code. It happens because architecture rarely erodes all at once. Imagine a modular application with clear boundaries. The billing module talks to the orders module through its public interface. Authentication is isolated. Notifications are independent. Everything is predictable. Now imagine hundreds of AI-assisted commits over the next few months. One suggestion imports an internal class because it already exists. Another bypasses a service layer because it's shorter. A helper gets copied into another module. A database query is duplicated instead of reused. None of those changes are catastrophic. In fact, every pull request probably gets approved. The application still builds. The tests still pass. Customers never notice. Until one day, making a simple change requires touching five different modules because everything has quietly become connected. That's architecture debt. And unlike a failing test, it doesn't show up immediately. One thing I've realized is that our current tooling doesn't really watch for this. Unit tests verify behavior. Integration tests verify interactions. Linters enforce style. Static analysis finds bugs. All of those are important. But none of them are asking questions like: Should this module depend on that one? Did someone bypass a defined boundary? Are we introducing new architectural coupling? Is the overall architecture getting healthier or worse over time? Those questions usually get answered during code review. Or worse, during a production incident. The interesting part is that AI isn't really the problem. If anything, it's doing exactly what we ask it to do. It optimizes for solving the problem in front of it. Architecture, on the other hand, is about protecting the system as a whole. Those are different goals. As AI makes us write code fa

DISCLAIMER : NO AI OR LLMS WERE USED IN WRITING THIS ARTICLE . EVERY SINGLE WORD WAS TYPED MANUALLY USING A KEYBOARD I HAVE A COMPLETE UNEDITED VIDEO OF ME WRITING THE ARTICLE HERE: https://www.youtube.com/watch?v=6j1dbN64LyI submitted by /u/Inevitable_Back3319 [link] [留言]

Optimizing code starts with measuring it, and a measurement is only useful if it is repeatable: a 2% improvement is invisible under 5% of noise. Yet on an untuned machine the same binary can easily run several percent faster or slower between runs. In this post we take a tiny benchmark and tune the machine step by step, re-measuring after every change, until runs become deterministic. Continue reading— Tuning a Server for Benchmarking submitted by /u/david-alvarez-rosa [link] [留言]

Hey everyone 👋 Is anyone here playing RF Online Next? I recently built a fan guide website for it: 👉 https://rf-online-next.net RF Online Next Guide — Starter Finder & Beginner Tips New to RF Online Next? Answer 3 questions to get your starter Biosuit, faction lean, and first-day checklist — personalized for your playstyle. rfonlinenextguide.com The idea is pretty simple. When a new MMO launches, information is usually all over the place — Discord messages, random posts, outdated guides, fake code pages, and long videos when you only need one quick answer. So I wanted to make a cleaner guide hub for players who just want to know: how to download and play which faction to pick what Biosuits/classes are good whether there are any real codes how to fix server full/login issues how Mining War / Chip War works what Sacred Weapons do The site focuses a lot on Mining War, the big 450-player faction war between Bellato, Cora, and Accretia. I also tried to keep the content honest. For example, the codes page doesn’t list fake “working codes” just for clicks. If there are no confirmed codes, it says that clearly. From the dev side, I structured the site around search intent instead of a normal blog feed. So the homepage points players directly to the guide they probably need. It also has multilingual sections for different regions, since RF Online Next has players from many countries. Would love to hear feedback from other devs, especially on: site structure SEO approach guide layout content clarity anything that feels confusing If you’re into MMOs, gaming websites, or niche SEO projects, feel free to check it out: 👉 https://rf-online-next.net RF Online Next Guide — Starter Finder & Beginner Tips New to RF Online Next? Answer 3 questions to get your starter Biosuit, faction lean, and first-day checklist — personalized for your playstyle. rfonlinenextguide.com

Check how on-premises AI solutions empower enterprises to safeguard sensitive code, ensure data residency, and maintain full compliance without compromising performance. Why privacy and security matter in AI-powered development? As enterprises increasingly adopt AI to automate code reviews, testing, and vulnerability scanning, ensuring data privacy becomes paramount. Cloud-based AI tools may expose sensitive source code, customer data, or intellectual property to external risks. By contrast, on-premise AI tools allow organizations to keep data within their controlled environments by aligning with data sovereignty and compliance requirements like GDPR and CCPA. According to Gartner, by 2026, 75% of organizations will demand AI solutions that guarantee strong data residency and compliance assurances. What are on-premise AI tools for software development On-premise AI tools are artificial intelligence solutions that are deployed and operated within an organization’s own infrastructure, rather than relying on external cloud services. In the context of software development, on-premise AI allows teams to leverage advanced AI capabilities such as code analysis, automated testing, and security scanning while keeping all data and processes within their own controlled environment. Core components of on-premise AI infrastructure include: Hardware: servers, GPUs, and storage devices physically located on-site or in a private data center. Software: AI models, orchestration tools, and management platforms installed and maintained by the organization. Security Measures: firewalls, access controls, and monitoring systems tailored to the organization’s specific needs. Examples of on-premise AI tools in software development: AI-powered code review platforms installed on internal servers automated vulnerability scanners running within the company’s network machine learning models for test automation, hosted locally. Primary connection to data privacy: on-premise AI ensures that sensit

This is just an opinion of what I experience and am witnessing, but looking at how LLMs scale feels like I've seen it before: with CPUs trying to outrun Moore's Law and break the rules of physics. Heat, power leakage, and diminishing returns made it increasingly expensive to squeeze out even small gains in clock speed. The GHz race shifted because it had to. For LLMs, more compute, more data, more parameters, and everything just keeps getting better? That curve seems to hit a ceiling and innovation needs to succeed the scaling race now. History does not repeat itself, but it rhymes. What learnings can we make from history to "predict" a potential future? History In the early 2000s, CPUs ran into a wall, a very physical one ^^ So makers adapted. Instead of crunching every single watt out of a single core, multi-cores became common. Athlon 64 x2, Pentium D, PS3 with its heavy Cell approach. From linear to parallel. From sequential to multi-threaded (and funny race conditions ;). Talks of distributed systems, SIMD/MIMD and new benchmarking spawned into what we have today. We still use CPUs, but differently. We still have Memory, but think about Cache, RAM, GPU or Unified. Same same, but different. Innovation because of limitation. Present I feel something similar is about to happen to gen AI. Yes, there are improvements in different areas, some in scaling, some optimisation, some performance, but the slope is becoming slippery. The last 12 months went from "Opus 4.5 is the pinnacle" to "What the hell is wrong with Claude?". The perfect (business) storm of scaling execution! But the low-hanging fruits have been eaten and the crops don't grow as fast anymore. Costs rise quickly, latency becomes a constraint, and even large context windows feel more like extensions than breakthroughs. What remains is more incremental, more expensive, and more complex. You could argue the whole venture of "agents" is the same multi-core experience repeating itself. A different kind of orch

I have a confession. Somewhere around day nine of this experiment, I almost quit and went back to my old setup. Not because ChatGPT was bad. Because I was bad at using it. I kept typing half-questions the way I'd type into Google, hitting enter, and getting answers that were technically correct and completely useless. It took me about a week to realize the problem wasn't the tool. It was twelve years of muscle memory. This post is the long version of what happened when I tried to go a full month without my usual stack of developer crutches — Google, Stack Overflow, Regex101, JSONLint, a SQL formatter site, a commit message generator, a pile of bookmarked Docker cheat sheets, and a few other tabs I didn't even realize I kept open until they were gone — and replaced all of it with a single ChatGPT window. I work as a backend-leaning full stack engineer at a small e-commerce company. Python and Django on the server, a chunk of Node for a couple of internal services, Postgres, Docker, and an AWS setup that I inherited rather than designed. Nothing exotic. Which is actually why I think this experiment is useful — most of you reading this aren't working on some bleeding-edge ML pipeline either. You're maintaining stuff, fixing stuff, shipping features under deadlines that someone in another department picked without asking you. So here's what happened. All of it. The good parts, the embarrassing parts, and the parts where I quietly reopened Stack Overflow in an incognito tab because I didn't want my browser history to judge me. TL;DR I tried to replace 12 daily developer tools with ChatGPT for 30 days straight, tracking what worked and what didn't. Google search volume dropped by roughly 70%, but it never hit zero — and I don't think it should. Stack Overflow was the hardest habit to break, and also the one I missed least once I'd broken it. The small utility sites (Regex101, JSONLint, SQL formatters) were the easiest wins. ChatGPT replaced almost all of them outright. Do

Making of Aantraa aantraa.site — AI audio & video translation, caption generator, and viral shorts cutter. Under the Hood I run a small YouTube channel. I'm not a full-time content creator, but YouTube is a solid platform to gain traffic for your online work, business, project, or idea. Aantraa is what I built in a week. The main concept is simple: Video translation into multiple languages Audio translation — including text-to-audio, with MP3 output for Premiere Pro Long-form to shorts — convert YouTube long-form video into short clips At that time, only three features were needed, so website development wasn't the heavy lift. The real work was building APIs, backend infrastructure to integrate AI into video, and dealing with heavy storage. Breaking the execution into steps: How I made Aantraa AI LLM layering and provider Aantraa is heavily dependent on AI APIs — we need reliable infrastructure for LLM providers. OpenRouter, Portkey, Vercel AI SDK labs, and individual APIs for Anthropic, Deepseek, and OpenAI are solid options. I prefer OpenRouter for Aantraa for one reason: multiple model support — it's easy to pick the cheapest capable model for each job. Easy to integrate, strong community support, free model access, and more. AI LLM APIs are needed at almost every stage in the backend: Understanding video context and creating a script Translating the script into target languages Recording the script into MP3 or WAV format Summarising the video Generating captions Cutting videos into shorts Building APIs and servers Each layer needs heavy AI context and prompt engineering. Loop engineering is the trend here — and it's required for aantraa. For example, video translation works in multiple connected steps: Video translation API breakdown AI understands the video, fed into the LLM via the ffmpeg module AI generates a script/caption from the video AI translates the script into the desired language AI generates audio (MP3 or WAV) of the new translation AI glues audio a

Most developers use AI like a smarter Stack Overflow . Type a question. Get an answer. Go do the work yourself . That's fine but it's the slow way 😩 There's a faster mode, and most people haven't switched to it yet. Diff: Asking & Delegating When you ask an AI : "How do I write tests for my auth module?" You get a nice explanation. Then you write the tests yourself. You're still doing the work 🥸 When you delegate to an AI agent: "Write tests for /src/auth.py . Cover login, logout, and invalid token cases. Run them. If any fail, fix the code until they pass. Tell me what you changed." The agent opens your files, writes the tests, runs them, reads the failures, fixes the code, and comes back to you with a working test suite. You review the result. You didn't do the work. That's the shift 🙂‍↔️ It sounds small. The time difference is huge . How to write a good delegation Every delegation that works has four parts . Think of it like giving a task to a new team member: Goal: what should it produce? Scope: which files or area of the codebase? Success condition: how do we know it's done correctly? Report back: tell me what you changed and why. Here's what that looks like in practice: Debugging: "Here's the error and the stack trace. Find the root cause, fix it, and explain what was broken." Why this works: You're not asking what the error means. You're handing over the whole problem, find it, fix it, explain it 😎 Refactoring: "Refactor this file. Max two levels of nesting. No single function longer than 30 lines. Update every call site in the codebase." Why this works: The constraints are clear and checkable . The agent knows exactly when it's done 🧐 Database migration: "Write a migration script for this schema change. Make it idempotent. Run it against a local test database and confirm it succeeds." Why this works: You gave it a way to verify its own work before coming back to you 🤔 PR review: "Read this PR diff. Find anything that could fail in production. Write the tests