标签：#software

자동으로 돌아가게 만든 것과, 자동으로 끝까지 처리되는 것은 다른 문장이었습니다 이 시스템은 사람 승인 없이 스스로 판단하고 매매하는 걸 목표로 설계했습니다. 실계좌 주문 실행과 안전장치 (새 창)도 그 목표에 맞춰 만들었습니다. 그런데 최근 한 달 사이 실계좌에서 세 번, 사람이 직접 개입해야 하는 상황이 있었습니다. 세 사례 모두 "왜 자동 로직이 이 상황을 못 넘겼는지"의 구조가 서로 달랐습니다. 1. 배분 규칙이 특정 주문을 구조적으로 굶겼다 특정 종목 하나가 여러 날째 매도 계획이 서 있는데도 계속 팔리지 않는 걸 발견했습니다. 시스템은 매일 이 종목을 매도 후보로 올렸지만, 실제 주문까지는 못 갔습니다. 원인은 하루 매매 한도를 여러 라운드에 나눠 배분하는 규칙이었습니다. 이 종목의 주문 금액이 그날 남은 매도 한도보다 항상 컸습니다. 라운드 순서를 아무리 바꿔도 통과할 수 없는 구조였습니다. 한도 자체는 정상 작동하고 있었습니다. 문제는 "이번엔 못 나가도 다음 기회에 나간다"는 전제가 이 종목엔 애초에 성립하지 않았다는 점입니다. 잔여 한도가 매번 주문 금액보다 작으면, 기회는 계속 오지만 한 번도 충분하지 않습니다. 당장 못 나간 주문 1건은 사람이 직접 처리했습니다. 실계좌에서 이뤄진 되돌릴 수 없는 매도였습니다. 이후 배분 규칙 자체를 손봐서 같은 구조로 다시 굶는 일이 없도록 정리했습니다. 2. 안전장치가 스냅샷과 누적치를 혼동했다 다른 날엔 반대 방향의 사고가 있었습니다. 누적 손실을 감지하는 안전장치가 정상적인 매수 2건을 잘못 차단했습니다. 지수는 그날 거의 보합이었는데, 이 안전장치가 재는 손실률은 훨씬 크게 찍혀 있었습니다. 원인을 보니 이 장치는 "고점 대비 누적 하락"을 감지하는 용도였는데, 정작 비교하는 현재값은 장중 순간 스냅샷이었습니다. 장중 잠깐의 변동이 누적 지표를 밀어 올려서, 실제로는 발동하면 안 될 상황에서 발동한 겁니다. 누적을 재는 장치와 순간을 재는 장치가 뒤섞여 있었던 셈입니다. 막힌 매수 2건은 사람이 판단해서 직접 집행했습니다. 이후 이 안전장치가 장중 순간값이 아니라 "그날 마감 대 전날 마감" 기준으로만 반응하도록 구조를 바꿨습니다. 장중 급락에는 이제 다른 안전장치가 대신 반응하도록 역할을 나눴습니다. 3. 개입 경로 자체가 "새로 사는 경우"를 몰랐다 두 번째 사례를 수습하는 과정에서 사고가 하나 더 있었습니다. 수동으로 낸 주문을 원장에 반영하는 도구를 썼는데, 반영이 안 되고 조용히 빠졌습니다. 이 도구는 사람이 손으로 낸 거래를 세 가지 경우 중 하나로 분류합니다. 기존 보유 종목을 판 경우, 기존 보유 종목을 더 산 경우, 그리고 시스템과 무관한 거래인 경우입니다. 그런데 이번 매수는 원장에 없던 새 종목을 사람이 처음 사들인 경우였습니다. 세 분류 중 어디에도 안 맞았고, 도구는 이걸 "시스템과 무관한 거래"로 잘못 넘겼습니다. 그 결과 실제로는 산 자산이 잠깐 원장 밖에 있는 것처럼 표시됐습니다. 이 도구는 애초에 사람 개입을 위해 만든 경로였습니다. 그런데 그 경로를 설계할 때, "사람이 아예 새로운 자리에 처음 진입하는 경우"는 상정하지 않았습니다. 개입 경로 자체가 개입의 한 형태를 놓치고 있었던 셈입니다. 순서(먼저 다른 매도를 부기하고, 그다음 이 매수를 부기)를 지켜서 바로 수습했고, 검증 결과 원장과 실계좌 잔고는 정확히 일치했습니다. 분류 로직에 이 경우를 추가하는 건 아직 남은 과제입니다. 세 사례를 묶어보면 셋 다 "자동으로 처리되게 만들었다"와 "실제로 끝까지 처리된다"가 다른 문장이라는 걸 보여줬습니다. 첫 번째는 규칙이 있었지만 그 규칙이 특정 입력에서 절대 통과할 수 없는 구조였습니다. 두 번째는 장치가 있었지만 재는 대상(순간 대 누적)이 설계 의도와 어긋나 있었습니다. 세 번째는 사람 개입을 위한 경로가 있었지만 그 경로 자체가 특정 개입 형태를 몰랐습니다. 세 가지 모두 "자동화가 이 케이스를 놓칠 수 있다"는 걸 사전에 안 게 아니라, 실제로 놓친 뒤에야 알았습니다. 일반화하면 완전자동을 목표로 설계할수록,

Making something run automatically and having it actually get handled to completion turned out to be two different sentences This is the English version of a post originally written in Korean for my algorithmic trading system devlog (new tab). I designed this system to judge and trade on its own, without needing human approval for each decision. The order execution and safety-guard layer (new tab) was built around that same goal. Over the past month, though, there were three separate moments where I had to step in and act directly on the live account. Each one failed for a structurally different reason. 1. An allocation rule structurally starved one order I noticed a particular ticker had a sell plan queued for several days running, yet it never actually went out. The system kept nominating it as a sell candidate every day, but the order never reached execution. The cause was the rule that splits the daily trading budget across multiple rounds. This position's order size was consistently larger than whatever sell budget remained that day. No matter how the rounds were reordered, it could never clear. The budget cap itself was working exactly as designed. The problem was that the underlying assumption — "if it doesn't clear this time, it'll clear next time" — never held for this position. New opportunities kept arriving, but none of them was ever big enough. I executed the one blocked order by hand. It was an irreversible sell on the live account. Afterward, I reworked the allocation rule itself so the same starvation pattern couldn't recur. 2. A safety guard confused a snapshot with a cumulative reading On a different day, the opposite kind of failure happened. A guard meant to detect cumulative drawdown wrongly blocked two legitimate buy orders. The index was nearly flat that day, but the loss figure this guard was tracking read much larger. Looking closer, the guard was designed to measure "decline from peak," but the current value it compared against was an intra

로그조차 안 쌓이니, 돌고 있는지 죽어 있는지 구분할 방법이 없었습니다 이 블로그의 개발일지는 매일 밤 자동으로 마무리됩니다. 그날 대화로 초안을 썼으면 변환해서 로그에 남기고, 없으면 스킵했다는 한 줄만 남깁니다. 최근 이 파이프라인을 들여다볼 일이 있었는데, 7월 24일 이후로 로그가 통째로 비어 있었습니다. 무슨 일이 있었나 자동화 로그( .automation.log ) 마지막 줄이 2026-07-24였습니다. 그 뒤로 8월 22일까지, 거의 한 달 가까이 스킵 기록조차 한 줄도 없었습니다. 자동화가 아예 안 돌았나 싶어서 실행 로그( cron_output.log )를 열어봤습니다. 그런데 거기엔 매일 밤 실행된 흔적이 빼곡했습니다. 날짜 확인하고, 초안 있으면 내용 정리하고, 크로스링크까지 챙긴 요약이 매일 밤 남아 있었습니다. 일은 하고 있었는데, 결과물만 하나도 남지 않고 있었던 겁니다. 왜 아무도 몰랐나 실행 로그를 읽어보니 원인은 매일 같았습니다. 파일 쓰기 권한 승인을 기다리다가 그대로 끝난 겁니다. "workspace has not been trusted"라는 경고가 매 실행마다 찍혀 있었습니다. 초안을 잘 정리해놓고도, 마지막 파일 쓰기 한 줄이 승인 대기에 막혀서 아무것도 저장되지 않은 채 세션이 끝나는 패턴이 한 달 가까이 반복됐습니다. 문제는 이게 하필 로그를 남기는 단계 자체가 막힌 상황 이었다는 겁니다. 스킵한 날엔 스킵했다는 한 줄도 못 남겼습니다. 그러니 로그만 보면 "자동화가 멈췄다"와 "쓸 게 없어서 조용했다"를 구분할 수가 없었습니다. 무인 자동화이니 매일 밤 누가 화면을 지켜보는 것도 아닙니다. 결과적으로 이 공백은 사람이 우연히 로그 파일을 열어보기 전까지는 발견될 방법이 없는 구조였습니다. 진짜 원인 원인은 신뢰(trust) 설정이었습니다. 이 헤드리스 자동화 세션은 프로젝트 폴더 단위로 파일 쓰기 권한을 신뢰받아야 동작하는데, 그 신뢰 설정 키가 이 블로그 폴더가 아니라 상위 디렉터리(프로젝트들이 모여 있는 루트) 단위로 걸려 있었습니다. 즉 이 블로그 폴더만 놓고 보면 "아직 한 번도 대화형으로 신뢰 승인을 받은 적 없는 새 작업공간" 취급을 받고 있었던 셈입니다. 설정 파일 안에 이미 허용 규칙 10개가 들어 있었는데도, 그 규칙들이 걸려 있는 범위 자체가 무시되고 있었습니다. 헤드리스로 도는 야간 자동화는 대화형 승인 프롬프트에 응답할 사람이 없습니다. 범위가 어긋난 신뢰 설정 하나가, 매일 밤 정확히 같은 지점에서 조용히 실행을 무력화하고 있었던 겁니다. 흥미로운 디테일 하나 — 유령 완료 기록 이 공백을 되짚어보다가 특이한 줄 하나를 발견했습니다. 8월 22일 낮 12시 41분에 "weekly: 완료"라는 로그 한 줄이 남아 있었는데, 그 시각에 대응하는 실제 산출물 파일은 없었습니다. 같은 날 오후 4시에 다시 수동으로 실행된 기록이 있었고, 이번엔 실제 파일까지 정상적으로 만들어졌습니다. 앞선 12시 41분 기록이 왜 실물 없이 "완료"라고만 남았는지는 원인을 특정하지 못했습니다. 권한 문제가 한창이던 구간이라 어떤 형태로든 쓰기 절차 일부만 성공하고 일부는 실패한 걸로 추정만 할 뿐입니다. 다만 이 한 줄은 별도로 눈에 띄는 교훈을 남겼습니다. "완료"라고 적힌 로그도 그 자체로 완전히 믿을 수는 없다 는 겁니다. 로그와 실제 산출물을 따로 대조하지 않았다면 이 유령 기록을 그냥 지나쳤을 겁니다. 어떻게 고쳤나 신뢰 설정을 이 블로그 폴더 기준으로 다시 걸어주니, 그날 밤부터 바로 정상화됐습니다. 별도의 복잡한 조치는 필요 없었습니다. 문제는 고치는 방법이 아니라, 한 달 가까이 그 문제를 놓치고 있었다는 사실 쪽이었습니다. 일반화된 교훈 이번 일로 다시 확인한 건, 무인 자동화에서 "로그가 없다"는 상태 자체가 하나의 신호라는 겁니다. 그런데 그 신호를 신호로 취급하려면, 애초에 "침묵"과 "성공적인 무동작"을 구분할 수 있게 설계돼 있어야 합니다. 이번 파이프라인은 스킵한 날에도 로그 한 줄을 남기게 되어 있었습니다. 그 설계 덕분에, "로그가 아예 안

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

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

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

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

📈 Building the Future of Trading: An AI-Powered Platform for Smarter Investments The Introduction: Empowering Every Investor Hello, Builders and tech enthusiasts! I'm thrilled to share my journey as part of the "Meet The Builders" campaign, where innovators are leveraging Google AI to tackle real-world challenges. My project is an ambitious endeavor to democratize effective stock trading through an intuitive, AI-enabled platform. Inspired by industry leaders like Zerodha, I set out to create a comprehensive website that not only facilitates trading but also acts as a smart, AI-powered guide, helping users navigate the often-complex world of stock markets more effectively. This project is my story, a testament to how technology, especially AI, can empower individuals to make more informed investment decisions. The Deep Dive: Why Investors Need a Guiding Hand The stock market can be a daunting place. For many retail investors, it's a whirlwind of data, conflicting advice, and emotional decision-making that can lead to missed opportunities or significant losses. From understanding market trends and analyzing complex financial reports to knowing when to buy or sell, the sheer volume of information can be overwhelming. Many feel like they're trading blind, lacking the expertise and analytical tools available to professional institutions. I believe there's a significant gap here – a need for a personal, intelligent assistant that can cut through the noise, provide actionable insights, and guide users towards more strategic trading choices. This conviction fueled the inception of my project. The Solution: Stock Trading Platform – Intelligent Trading, Engineered for Success My project, Stock Trading Platform, is a robust web-based platform designed to simplify stock trading with the power of artificial intelligence. While currently in its final polishing stages on my local machine and version-controlled with Git and hosted on GitHub, the core functionality revolves around a

Designing Reliable APIs for Production Applications: Lessons From Building Real-World Digital Products APIs are often described as the “bridge” between different parts of an application, but building a production-ready API involves much more than sending data from a frontend to a backend. Through my experience building full-stack applications, I've learned that a good API needs to be designed around reliability, security, maintainability and the actual needs of its users. Here are some of the principles I now consider when designing APIs: Design around resources, not screens An API shouldn't simply mirror the frontend interface. It should expose meaningful resources and operations that can evolve independently from the UI. Validate everything at the API boundary Data coming from a client should never be trusted automatically. Request validation, type checking and clear error responses help prevent invalid data from propagating through the system. Authentication is only the beginning An authenticated user should not automatically have access to every resource. APIs need appropriate authorisation and access-control rules for sensitive operations. Design predictable errors A useful API doesn't just return “something went wrong.” Clients need consistent status codes and structured error responses so that applications can respond appropriately. Think about idempotency This becomes particularly important when an API handles operations such as payments, orders or other actions that shouldn't accidentally happen twice because of a network retry. Don't expose unnecessary data APIs should return what the client needs rather than exposing entire database records. This reduces unnecessary data transfer and can also reduce the risk of accidentally exposing sensitive information. Logging and observability matter An API can appear perfect during development and still fail in production. Good logging and monitoring make it possible to understand what happened when requests fail, la