标签：#war

When I became an AWS Community Builder, one of the things I was most excited about was getting the opportunity to experiment with AWS. Let me Introduce .... eventinary.com A Completly free event management software Like most developers, I had a long list of things I wanted to build. AI applications, serverless projects, agents, APIs — there was no shortage of ideas. The AWS credits made it easier to experiment without constantly thinking about the cost of every service I turned on. But after a while, I started asking myself a different question. What if I used those credits to build something that could actually give back to the community? That question eventually led me to Eventinary . I've always enjoyed technical meetups and community events. A meetup may only have a few dozen people in a room, but something interesting happens there. Someone learns about a technology for the first time. Someone meets another developer. Someone gets inspired to build something. Someone gives their first technical talk. The event may last only a few hours, but the impact can last much longer. Then I started looking at what happens behind the scenes. Organizers have to create the event, manage registrations and RSVPs, keep track of attendees, coordinate speakers, prepare schedules, communicate updates, and somehow keep everything organized. For larger events, the number of tools and spreadsheets can grow quickly. I thought, why not build a platform that makes this easier? That became Eventinary. At first, it was just another idea. Then I started building it. As the platform grew, I realized I didn't want to build another simple invitation or RSVP website. I wanted to create a proper digital event platform that could support the entire event experience. Today, Eventinary can help organizers with things like: Event creation and digital event pages RSVP and attendee registration Speaker and session management Event schedules and itineraries Guest and attendee management Event informat

Over the past year, I've watched a lot of engineering teams go through the same adoption pattern with AI tools. They start using GitHub Copilot or Claude. Productivity goes up. And then someone in a meeting asks the question: "Do we still need as many junior developers?" I think that question reveals exactly the wrong mental model. The teams getting the most value from AI tools aren't the ones who figured out what AI can automate. They're the ones who figured out what AI should automate, and then designed their workflows around that distinction. That sounds like a small difference. It isn't. Most of the debate around AI and junior developers focuses on the wrong question: can AI do what juniors do? In a previous article, I explored why that question leads teams in the wrong direction. In another, I looked at what happens when organizations quietly remove the work juniors need to grow. This article is about what the best teams actually do instead. They don't pick AI over junior developers. They redesign how work flows. The AI and Junior Developers Debate Is Asking the Wrong Question The argument goes like this: AI can generate code, write tests, and produce documentation. Junior developers also generate code, write tests, and produce documentation. Therefore, AI can replace junior developers. This looks logical at the task level. But it misses something important. Junior developers aren't primarily valuable for their output. They're valuable for what they become while producing that output. Every bug they debug, every test they write, every pull request they review is quietly building something that doesn't appear in any sprint metric. You can automate a task. You can't automate the learning that comes from doing it. That's where the replacement narrative breaks down. What AI Is Actually Good At After using AI coding tools seriously for a while, certain patterns become clear. AI is fast and reliable for repetitive, well-defined work: boilerplate, standard implementat

Git is a version control system. Version control, also known as source control, is the practice of tracking and managing changes to software code. Version control systems are software tools that help software teams manage changes to source code over time. Git is used for: Tracking code changes Tracking who made changes Coding collaboration Setting up a new Repository A Git repository is a folder that Git tracks for changes. The repository stores all your project's history and versions. Add files to the folder. The following describes how to set up a new repository: Git Init Initializes git user@localhost $ git init This creates a hidden folder called .git inside your project. This is where Git stores all the information it needs to track your files and history. To see which files are in your project folder, use the ls command: user@localhost $ ls To Check if Git is tracking your new files: user@localhost $ git status The files here could either be tracked or untracked:- Untracked Files Files you've created or copied into the folder, but haven't told Git to watch. Tracked Files Files that Git is watching for changes. To make a file tracked, you need to add it to the staging area. Git Staging Tells Git exactly which files you want to include in your next commit. user@localhost $ git add . Common Commands git add . Stages all new, modified, and deleted files in the current directory and its subdirectories. git add <file> Stages a specific file. git add -A (or --all) Stages all changes across the entire repository, regardless of your current folder location. git add -u Stages modifications and deletions of already-tracked files, ignoring completely new (untracked) files. git add *.txt Stages all files matching a specific pattern (e.g., all text files). Git Commit A commit is like a save point in your project. It records a snapshot of your files at a certain time, with a message describing what changed. user@localhost $ git commit -m " Describe your changes" Pushing Chan

Apple has admitted that some roles are being impacted as it shifts its focus away from certain initiatives.

The $225 Pebble Time 2 pairs quirky watch faces and apps with physical buttons, an e-paper display, weeks of battery life, and a playful hacker spirit.

The lawsuit alleges that Oura rings are unable to measure any of the physiological signals needed to assess sleep quality or determine sleep stages.

I recently built WordScrambler, a free tool for unscrambling letters and solving anagrams, mostly out of frustration with existing tools being cluttered with ads or requiring sign-up just to see a result. Here's a quick look at the core technique behind how it works. The problem Given a jumbled set of letters (say, ucim), find every valid dictionary word that can be formed from some or all of those letters. The naive approach, generating every permutation and checking each against a dictionary, gets slow fast. A 7-letter input has 5,040 permutations; a 12-letter input has nearly 480 million. That's not viable for instant results. The signature trick The key insight: two words are anagrams of each other if and only if their letters, sorted alphabetically, produce the same string. For example: "listen" -> sorted -> "eilnst" "silent" -> sorted -> "eilnst" Both hash to the same signature. So instead of generating permutations, you can: Precompute a signature for every word in your dictionary and group words by signature. For a given input, generate the signature of the input (and its relevant sub-combinations, for partial-length matches). Look up matching signatures in a hash map, an O(1) lookup instead of a brute-force search. This turns "find every valid word from these letters" into a fast lookup problem rather than a combinatorial one, which is what makes results feel instant even against a large dictionary (WordScrambler checks against roughly 246,000 words). Handling partial-length matches Most real unscrambling needs go beyond "use every letter", people want every valid word of any length using a subset of the given letters. That means generating signatures for all relevant letter subsets (not full permutations, just subsets, which is a much smaller set) and checking each against the dictionary map. Try it You can play with the live version here: wordscrambler.online — it also shows word definitions and Scrabble/Words With Friends point values alongside each resu

Cloudflare has recently detailed how it is using AI to transform internal engineering standards from passive documentation into an actively enforced control system across the software development lifecycle. By Craig Risi

Originally published on hexisteme notes . I run pre-registered checks against a live system, read the verdict, and move on — that's the whole point of pre-registering them, so I don't get to argue with the result after the fact. Most of the time the discipline pays for itself. This time it passed, and the pass was wrong, and the reason it was wrong is more interesting than the failure itself: the check could not have returned anything else, whatever had actually happened to the file under test. The question I was probing something narrow: does a hand-made audio crossfade survive a round trip through DaVinci Resolve? Build a timeline with a crossfade sitting on a cut, export it to FCPXML 1.10, re-import it, and see whether the crossfade is still there. Third-party documentation says transitions are invisible to and unmodifiable by the scripting API. Believing that, I pre-registered a judgment method that never looks at timeline structure at all: render audio around the splice and classify it by waveform shape. The judge, exactly as pre-registered: render two seconds either side of the cut, downsample to 8 kHz mono, compute a 20 ms sliding-window RMS envelope — 202 windows across the render — and take the largest normalized step between adjacent windows. Above 0.5, call it a hard cut: the fade is gone. Below 0.5, call it a gradual ramp: the fade survived. The probe came back pass — gradual ramp, max step 0.4761, under the 0.5 threshold. Exit 0, all green. The crossfade had actually been lost at the export step. The pass was a false confirm, and I only found that out by going back in with a second, read-only inspection after the fact. Why the check could not fail The prep instructions for this probe — which I also wrote — said the easiest way to get two adjacent audio items with enough handle to build a crossfade is to take one continuous clip and blade-split it in the middle. That's a completely reasonable instruction on its own. A crossfade needs overlap media on bot

Linkdaze's smart digital calendar stands out for not putting its features behind a paywall, including an AI meal planner tool.

Originally published at tddbuddy.com . Related reading: Where the Review Point Moved is the direct predecessor; this post argues the industry's response to that shift is doubling down on the wrong surface at higher throughput. What "Senior" Means When Typing Is Free and The Test Pyramid Was an Economic Argument name where signal actually lives now. The review agent left fourteen comments on the pull request and none of them were the reason the PR should not have merged. That is the shape of the failure. The reviewer that shipped the review was a tool built to catch what a human reviewer no longer had time for. Three of the comments were genuine issues, unused imports, a typo in a log message, a dead branch. Eleven were style opinions, restatements of what the diff already made obvious, or false positives on patterns the codebase had chosen deliberately. The human on the PR spent more time filtering the review than reading the diff. The change that actually needed a second pair of eyes (a renamed field in a shared DTO that had already broken a downstream consumer twice this year) merged without a comment on it from either the human or the machine. The industry response to agent-generated pull-request volume has been to deploy more agents. The response is understandable. It is also empirically counterproductive. A 2026 study measured what happens when only a code-review agent reviews an agent-authored PR: 60.2% of closed pull requests sat in the 0 to 30 percent signal-ratio range, and twelve of the thirteen review agents evaluated averaged below a 60% signal ratio. Signal is what a human reviewer needs. The review agent produces less of it per unit of reviewer attention than the diff would have without a bot in the middle. The Volume Problem Is Real Four hundred thousand pull requests in two months from a single code-writing agent. One in five reviews on the largest hosting platform now involves an agent. Pickup time on agent-authored PRs is 5.3 times longer than on h

A parent class must be able to be substituted by its child classes without breaking the application. In practice, this helps to organize the idea of inheritance, as it prevents us from extending a parent class only to later remove an already implemented method or do a “throw new Error(‘Not implemented’)”. Making us much more careful during planning. THE BIGGEST SYMPTOM OF ERROR Unfortunately, it is a symptom that appears late, but it is exactly when we are going to make a new implementation. You realize you violated Liskov when you are going to build a class or subclass and need to purposely throw an error in the implementation of a method. Exactly because that method shouldn't be there, but it is. A BAD EXAMPLE For example, in a delivery system. In this case, the “Delivery” class should be the parent/base for the other implementations. But the ‘MotoboyDelivery’ class breaks this. Code Example: // BAD: The subclass breaks the parent class contract. class Delivery { public calculateShipping (): number { return 15.0 ; } public getTrackingCode (): string { return " TRK123456789 " ; } } class MotoboyDelivery extends Delivery { public calculateShipping (): number { return 8.0 ; } // ERROR! There is no tracking code. public getTrackingCode (): string { throw new Error ( " Motoboys do not have a tracking code. " ); } } THE SOLUTION For those who do not yet know the 'Liskov Substitution Principle', it might seem that fitting in a sequence of 'if's is the solution. But in reality, the ideal path is to rethink how this abstraction is built. A good guiding principle is to think that a child class must always be able to take the place of the parent, without breaking the application. A GOOD EXAMPLE Still in the delivery system. ‘Delivery’ now has ‘TrackableDelivery’ in the middle of the way. With this, each “leaf”/edge of the application inherits what makes the most sense and nothing is broken. Code Example: interface Delivery { calculateShipping (): number ; } interface Trackab

1. The question that started everything Three weeks into my internship, my supervisor sat down across from me and asked, very casually: "OK your NLP pipeline extracts intentions and rules from legacy Java. Nice. And then what? " I looked at him. I looked at my laptop. I looked back at him. The whole project — Pulsar Modernizer — was supposed to eventually turn legacy Java into modern Spring Boot code. My part was the "understand the old code" part. F1 = 0.857 on the annotated corpus, a shiny React UI, everything humming in Docker. But the "and then?" was doing a lot of work in that sentence. That evening I wrote in my notes: "Nobody has actually tried the generation part. Everyone assumes it'll be easy because LLMs. That is very obviously wrong." So I decided to try. 2. Why "just prompt an LLM to rewrite it" doesn't work The naive move — feed the old code and the extracted rules to an LLM and say "please modernize this" — has three problems and I hit all of them in the first hour: The model hallucinates. It happily invents helper classes that don't exist and calls methods with the wrong signature. You have no criterion for stopping. The model tells you "it's done ". OK. Is it? By what test? You have no criterion for equivalence. Even if it compiles, how do you know the new code actually does what the old one did? I needed something more constrained than "prompt it and pray". 3. The setup — a chain, not a monolith I ended up building three specialized agents in sequence: IntentCard + RuleCards │ ▼ [APIDesigner] ──► JSON contract (class, methods, DTOs, throws) │ ├───────────────┐ ▼ ▼ [CodeGenerator] [TestGenerator] │ │ ▼ ▼ .java *Test.java │ │ └────► verifier (mvn test) The key insight: each rule extracted from the legacy code should become a test that the generated code has to pass. This flips the whole thing. I don't trust the LLM. I trust javac and JUnit. I did all of this on a local model — Qwen 2.5 Coder 3B via Ollama. No cloud APIs, no data leaving my Mac. On a

Uma classe mãe deve ser capaz de ser substituída pelas suas classes filhas sem que a aplicação quebre. Isso na prática ajuda a organizar a ideia de herança, já que nos faz evitar estender uma classe mãe, apenas para depois remover um método já implementado ou fazer um “throw new Error(‘Not implemented’)”. Fazendo com que tenhamos mais cuidado no planejamento. O MAIOR SINTOMA DE ERRO Infelizmente é um sintoma que aparece de forma tardia, mas é justamente quando vamos fazer uma nova implementação. Você percebe que feriu o Liskov quando você vai construir uma classe ou subclasse e precisa lançar um erro proposital na implementação de um método. Justamente porque aquele método não deveria estar ali, mas está. UM EXEMPLO RUIM Por exemplo em um sistema de entregas. Nesse caso a classe “Delivery” deveria ser a mãe/base para as demais implementações. Mas a classe ‘MotoboyDelivery’ quebra isso. Exemplo de Código: // RUIM: A subclasse quebra o contrato da classe mãe. class Delivery { public calculateShipping (): number { return 15.0 ; } public getTrackingCode (): string { return " TRK123456789 " ; } } class MotoboyDelivery extends Delivery { public calculateShipping (): number { return 8.0 ; } // ERRO! Não tem código de rastreio. public getTrackingCode (): string { throw new Error ( " Motoboys não possuem código. " ); } } A SOLUÇÃO Para quem ainda não conhece o 'Liskov Substitution Principle', pode parecer que encaixar uma sequência de ifs é a solução. Mas na verdade o caminho ideal é repensar como essa abstração é construída. Um bom norte é pensar que uma classe filha sempre deve ser capaz de substituir o lugar da mãe, sem quebrar a aplicação. UM EXEMPLO BOM Ainda no sistema de entregas. ‘Delivery’ agora tem no meio do caminho ‘TrackableDelivery’. Com isso, cada “folha”/ponta da aplicação herda quem faz mais sentido e nada é quebrado. Exemplo de Código: interface Delivery { calculateShipping (): number ; } interface TrackableDelivery extends Delivery { getTrackingCode (): st

One of the best moments when learning electronics is seeing your first LED blink. It's a simple experiment, but it represents the bridge between software and the physical world. With Java and Pi4J, that first step is already well documented. But what happens after the first LED? How do you experiment with different animations, colours, brightness levels, or GPIO configurations without repeatedly rewriting the same code? That question led to the creation of the Pi4J LED Playground . 👉 https://igfasouza.github.io/pi4j-led-playground/ Why another example? Pi4J already provides excellent examples and documentation for getting started with Raspberry Pi hardware. The project itself encourages community-driven examples and implementations, recognising that the ecosystem grows through shared contributions. The goal of the LED Playground is not to replace those examples. Instead, it provides an interactive environment where developers can quickly experiment with LED behaviours while learning how Pi4J works. Think of it as a sandbox where changing a few lines of code immediately produces visible results. Built by the community, for the community This project started as a personal experiment while exploring Pi4J. Very quickly it became clear that the playground could be useful for others who are starting their journey with Java on Raspberry Pi. Instead of keeping it as a private repository, it was published as an open community resource where anyone can: 1. learn from the source code; 2. suggest improvements; 3. report issues; 4. contribute new LED effects; 5. help improve the documentation; Open source projects become stronger when many people contribute different ideas, and Pi4J itself has grown thanks to this collaborative model. What can you do? The playground demonstrates common LED operations such as: turning LEDs on and off; blinking patterns; brightness control (where supported); experimenting with different GPIO configurations; creating reusable animations; Because th

You’ve got a product idea, a deadline creeping closer, and a blank canvas staring back at you, so...

Flux has introduced Flux Mirror, a CLI plugin that mirrors container images, Helm charts and OCI artifacts between registries from a declarative configuration. The plugin is part of the Flux v2.9 CLI plugin system and is presented as a way to keep Kubernetes clusters reconciling only from registries that teams operate themselves. By Matt Saunders

📺 Prefer to watch? 90-second YouTube Short · 💬 Telegram Originally published on software-engineer-blog.com . You fixed the CSS. You deployed. You opened the site and checked it yourself — perfect. Then a customer sends a screenshot of last week's layout. Nothing is broken. No deploy failed, no CDN is lying to you, no file is corrupt. The browser is doing exactly what you told it to do, several days ago, in a header you probably never wrote by hand. This is the part of web performance that gets skipped, because caching looks like a setting rather than a contract. It is a contract. And like any contract, the interesting part is not what it gives you — it is what you can no longer do once you have signed it. Throughout this post I will use one running example: PlantPal , a small plant shop. One stylesheet ( app.css ), one logo ( logo.png ), one API endpoint ( /api/products ). The floor: a page load is not one thing Before caching means anything, you have to see what it is acting on. Loading PlantPal's homepage is not a request. It is roughly 40 separate requests — the HTML, the stylesheet, a few fonts, the logo, a dozen product images, the JavaScript bundle, the product API. Each one is a full round trip: DNS is probably warm, but you still pay connection setup, the request, the server's think time, and the bytes coming back. The numbers for a first visit: ~40 requests 1.2 MB transferred 2.1 s to a usable page Which gives us the only sentence in this post that you actually need to remember: The fastest request is the one the browser never sends. Not a faster server. Not a closer edge node. Not a smaller file. No request at all. Everything below is a way of getting closer to that. max-age: buying silence The blunt instrument is Cache-Control : HTTP / 1.1 200 OK Content-Type : text/css Cache-Control : max-age=31536000 31536000 is one year in seconds. You are telling every browser that receives this response: keep this copy and use it for a year without asking me again. O

Many beginner developers believe software engineering is all about mastering programming languages, framework syntaxes, and clearing error logs. In reality, writing code is only a fraction of the actual job. The true core of software engineering lies in analyzing complex domain problems, evaluating deep trade-offs, and designing robust systems that stand the test of time. Let's explore what it genuinely takes to transition from a coder to a modern software engineer with the right engineering mindset. 1. Writing Code vs. Solving Problems Anyone with a healthy brain can learn syntax and write functional scripts after a few tutorials. However, the real engineering challenge begins long before you touch your IDE. Understanding the Domain: Breaking down business logic and user requirements. Evaluating Alternatives: Assessing whether a feature needs a complex custom hook or a simple native state. Long-term Value: Building solutions that won't break when requirements shift tomorrow. 2. The Importance of Maintainability Code is read much more often than it is written. When you are working on large-scale applications, you are never coding alone—even if you are solo for now, your future self is essentially a stranger six months down the line. Crafting clean, self-documenting code with meaningful, intention-revealing names. Enforcing single-responsibility functions to keep modules decoupled. Using predictable patterns so teammates can navigate and scale the application without getting buried in technical debt. 3. Pragmatic System Design and Trade-offs There is no silver bullet in software engineering. Every architectural decision—whether choosing a database, state management library, or caching strategy—comes with heavy trade-offs. Performance vs. Development Speed: Knowing when to optimize early and when to ship MVP code. Scalability vs. Complexity: Avoiding over-engineering simple features just because a shiny new tool exists. Balancing Constraints: A great engineer evaluate

A tool that handles crash recovery, hang detection, and a full status page sounds like it should cost something. Here's why it doesn't, and won't. "What's the Catch?" — Why StayPresent Is Actually Free It's a reasonable question. A tool that handles crash recovery, hang detection, and generates a real status page — the kind of thing you'd expect to see behind a pricing page with a "Pro" tier — is, in fact, entirely free. Not a free tier that nudges you toward upgrading. Not a trial. Just free. Here's the honest answer to "what's the catch," because the skepticism is fair. The MIT license, plainly stated StayPresent is released under the MIT License — one of the most permissive open-source licenses that exists. In practice, that means: use it in a personal project, use it in something you're charging money for, modify it, redistribute it, all without paying anything or asking permission. There's no feature gate waiting behind a paywall, and no functionality quietly disabled unless you upgrade. No account required, no data leaving your deployment There's no account to create, no API key issued by a third party, no external service your bot phones home to. Everything — the web server, the crash recovery, the status page, the hang detection — runs directly inside your own deployment, on infrastructure you already control. There's genuinely nothing to charge for on the vendor side, because there's no ongoing service being provided from outside your own process. Why "free forever" is actually plausible here A lot of "free" developer tools eventually aren't, because they're subsidizing a hosted service somewhere — servers, bandwidth, support staff — and the free tier exists to fund a business built around eventually charging some of its users. StayPresent doesn't have that shape. It's a library, not a hosted service. There's no infrastructure cost scaling with your usage that would ever create pressure to start charging. What you're actually trading The honest trade isn't