标签：#EV

I remember the day I hit my breaking point. I had spent the entire morning — five hours — wrestling with a React component that an AI assistant had generated for me in about four minutes. The code looked flawless at first glance. Proper hooks, clean JSX, even decent comments. But it didn't work. And worse, I couldn't figure out why. Everyone talks about how AI speeds up coding. And it's true — when it works, it's magical. I've personally seen my feature delivery time drop by maybe 40-50% on good days. But what nobody talks about — what I certainly never saw in the breathless LinkedIn posts — is the debugging nightmare that follows when the AI gets it wrong. That day, I realised I had spent ten times longer debugging AI-written code than I would have spent writing it myself from scratch. I started tracking it. Over three months, I logged every AI-assisted task. The numbers were sobering: on average, each AI-generated snippet took me 3.2 times longer to verify and fix than to write myself. And for complex tasks — anything involving state management, async flows, or edge cases — the ratio jumped to 8-12x. The AI was giving me confidence, not correctness. And confidence, as any seasoned developer knows, is the enemy of debugging. The Hallucination That Cost Me a Sprint One incident stands out. I was building a data pipeline in Python that needed to batch-process JSON files from an S3 bucket and push transformed records into a PostgreSQL database. I gave the AI a detailed prompt: "Write a function that reads all JSON files from a given prefix, validates each record against a schema, and inserts them in batches of 500. Use threading for I/O." The AI returned a beautiful 60-line function. It used concurrent.futures.ThreadPoolExecutor , had proper error handling, even logged progress. I was impressed. I dropped it into the codebase, ran the tests — they passed. Deployed to staging. Worked like a charm. Then production hit. Three hours later, the database had 30,000 duplicat

Hello. No idea if anyone's going to read this, but writing it feels like I've done something, so here we go. And maybe it helps someone. For the past few years, I've been building a piece of software in Unity. It has actual users, somehow. My role was everything: founder, product owner, and whatever else needed doing. Development, UI, the website, the content. That's startup life. I'm good at learning fast and shipping, so it worked.(of course not all of it... I'm not trying to take all the credit for others' work Im just saying what I did) But I never came into this as a leading developer, so updating the product became kinda frustrating. Moreover, graphics are central to this product, and even with HDRP, Unity wasn't getting me where I wanted. I know my way around C#. C++, not so much. With Unreal, I've learned the basic UI and not much else. BuT~ You study, you keep going, and things tend to work out. So wish me luck I'll reveal what the product is once the switch to Unreal succeeds I'll take some courses. I don't care if it's in Korean or English. I'll make it work. Time passes either way, we get older, we all die anyway. So let me just learn and build what I want to build. I'm writing this to leave a record of what I learn and what I try. Let's go 헬로 누가 이걸 보기나 할 지 모르지만 이런 글이라도 쓰면 성취감이 드니까 걍 씀 그리고 누군가에게는 도움이 될 수도 있으니까 킬킬 난 지난 몇년간 유니티로 소프트웨어를 하나 만들었음. 나름 유저도 있는 상황 ㅋㅋ 나의 역할은 대표이자 기획자이자 뭐 올라운더로 참여했음. 개발도 하고... 화면도 만들고 뭐 웹사이트도 만들고 콘텐츠도 만들고 뭐 다 그랬음. 스타트업이 다 그런 거지 뭐. 뭐든 빨리 배우고 결과물을 만들어내는 걸 잘하는 편이라 나름 잘 했음 다만 내가 개발자로 참여한 건 아니라서 이 프로덕트를 업데이트하는 과정이 좀 아쉽기도 하고 그래픽이 중요한 프로덕트인데 unity는 hdrp라 하더라도 아쉬웠음 c#에 대한 이해도는 있는 편인데 c++은 잘 모름 unreal도 기본적인 ui 익힌 거 빼고는 모름 공부해서 하다보면 뭐든 되지 않겠음? 위시 미 럭 프로덕트가 뭔지는 unreal로 업그레이드 하는데 성공하면 공개하겠음. 한국어 강의나 영어 강의 닥치는대로 다 볼 거고 뭐 어떻게든 해 보겠음 어차피 시간은 흐르고 나이는 들고 죽을텐데 이렇게 하고싶은 거 어떻게든 해보면서 뭐라도 만드는 게 남는 거인듯 내가 공부하고 실행해본 걸 흔적으로 남기려고 이 포스트 쓰는 걸 시작해본다 아자뵤

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing What I Built The leaf is the page. For my CSS Art entry, I drew my mother's Sunday meal: sixteen dishes on a banana leaf, each one placed where Telugu tradition puts it. For Perfect Landing, that artwork became the navigation. Tap any dish on the leaf and the page takes you to that dish's course. Scroll instead, and you move through the meal in eating order: ghee first, then the curries, the pulusu, rasam, the rice varieties, the crunch, the sweet, and finally perugu. The scroll is the serving order. The structure of the page is the structure of the meal. It is deliberately not a restaurant. No menu cards, no reservation form, no gallery. One family, one Sunday, eight courses, and the rules my mother enforces at each one. The part I cared most about: a screen reader is served this meal the same way my mother serves it. The heading order, the tab order, and the reading order all follow the eating order. Tap targets on the leaf move focus to the course they open, so keyboard and screen reader users travel with everyone else. Telugu headings carry lang="te" so they are pronounced as Telugu, not mangled as English. The course nav marks where you are. And with reduced motion on, the smooth scrolling and the ghee-pour animation both settle down together. Demo Things to try: tap the rice mound (or the ghee spoon) on the leaf and see where it takes you. Press Tab from the top of the page and watch the skip link appear before anything else. Scroll and watch the Telugu nav track your course. Turn on reduced motion and take the calm version of the same journey. Every visual on the page is CSS. No images, no SVG, no canvas. Journey The concept came from the eating itself. On a banana leaf, order is information: neyyi before anything, perugu always last. Most landing pages invent an information architecture. This meal already had one, and it is thirty years older than CSS grid. My whole job was n

A few months ago I moved a batch of WordPress sites off a shared LAMP host and onto Cloudflare Pages as static exports. The pitch is obvious: no PHP process to keep patched, no MySQL to babysit, effectively free hosting, and a CDN in front of everything by default. What the pitch doesn't tell you is how many small, boring things break on the way there. This post is a rundown of what actually went wrong migrating a set of ten WordPress sites — one of them is burningtribe.tokyo , which I'll use as the concrete example — and how I fixed each issue. The approach The migration itself is conceptually simple: crawl the live WordPress site, save every URL as a static HTML file plus its assets, and serve that tree from Cloudflare Pages. I used a combination of wget --mirror and a custom crawler for a couple of sites where wget choked on query-string-based pagination. The static output then gets pushed with wrangler pages deploy . No build step, no framework, just files. That simplicity is exactly why it seemed low-risk. It was not. Problem 1: relative canonical tags pointed everything at the homepage The first thing I noticed after deploying was that Google Search Console started reporting most inner pages as "duplicate, Google chose different canonical" — and the canonical it picked was the homepage. The cause was almost funny once I found it: the WordPress theme emitted <link rel="canonical" href="/"> as a relative path in a few cached page fragments, instead of an absolute URL like https://burningtribe.tokyo/some-post/ . On the original WordPress install this didn't matter because the page itself resolved the relative reference correctly at the point of caching. Once the HTML was frozen and served statically from a different origin structure (Pages serves everything from the apex), that relative canonical collapsed to the site root for every single page that had it. The fix was a straightforward but tedious pass: grep every exported HTML file for rel="canonical" , and rew

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry. ...

Two minutes and thirty seconds into the title track of Rachika Nayar's Heaven Come Crashing, an absolutely massive drum and bass beat drops. As a fan of Nayar's debut record Our Hands Against The Dusk, it caught me off guard. That album has no percussion on it at all. Heaven Comes Crashing is almost entirely […]

This was first published on the Vibsync blog . Reposting for the DEV community. The short version: AI reliably makes each developer faster. Whether it makes the team faster is a separate question — and the gap between the two is where a lot of quiet cost hides. Below: the five coordination costs that eat the difference, a ten-question diagnostic, and five operating principles. Picture three developers, three AI coding agents, and one repository. Each developer can now produce candidate code, tests, and refactors faster than before. Yet releases move at the same pace, review queues grow, and the same facts keep getting rediscovered. That's not a paradox, and it isn't a reason to slow anyone down. It's a reminder that individual speed and team speed are different quantities , and AI coding agents scale the first far more easily than the second. Give everyone a faster typewriter and you get more pages — not necessarily a better book, written faster, by a group. Individual output is not team throughput It's worth separating two things we tend to blur: Individual output — how much finished work one developer (plus their agent) produces. Team throughput — how much shippable, coherent work the group produces together, after review, rework, waiting, and reconciling everyone's changes. AI agents lift individual output directly. Team throughput is what's left after the coordination overhead is paid, and that overhead doesn't shrink just because each person got faster. A useful way to hold it in your head — not as a formula to compute, just as a shape: team throughput ≈ the sum of local speed-ups − rework − waiting − reconciliation When you add agents, the first term grows. If nothing else changes, the last three grow too — because there's now more work in flight, produced faster, by people who can't all see what the others are doing. The interesting question for a team lead isn't "how do I make everyone faster?" It's "which of those subtraction terms is my real ceiling?" Ther

Also Published On trever.cloud Medium LinkedIn Most of us who get into self-hosting start the same way: start with linux, throw a few apps into Docker, get them running and connectable outside the home network, and call it good for months, maybe even years. Nothing wrong with that approach. A compose file and a spare mini PC gets you further than you think, and if it works and you don't have to think about it, that's a perfectly fine place to stop. Then there's the rest of us. The people who get that first setup running, feel the little spark of "wait, I built this", and immediately start wondering what else is possible. More services. Less babysitting. A real answer to "what happens if this box dies at 2am". If any of that sounds familiar, this one's for you. If you keep going, you'll eventually run into the question every self-hosted setup faces sooner or later, whether you notice it happening or not, "how much should live together, and how much should be kept apart?". Put everything on one box and you quickly feel the fragility when one bad update takes everything down with it. Or when nightly backups put services on hold longer and longer. Split everything into its own isolated piece and you've gained resiliency but now manage a lot of moving parts. Most of the actual learning in running infrastructure happens in the space between those two answers. Where you draw that line is where most of the real infrastructure lessons live. Over the years, I've lived through a few different answers to that question in my own homelab, and each one taught me something the previous one couldn't. It started with a large VM, Docker installed, and every service I wanted to self-host running as a container inside. It was the fastest path to "it's actually working", and at the time that was the whole goal. I didn't know yet what I'd eventually want out of this thing, so keeping the infrastructure simple while I figured that out made sense. That setup carried me a long way, and I don

It happened during a medical appointment. I was sitting in the quiet waiting room, my thoughts occupied by the upcoming consultation, when my phone erupted with a loud, aggressive ringtone. The entire room turned to look at me, and I fumbled to silence it, accidentally hitting the volume up button instead of the mute toggle in my panic. I felt that specific, burning embarrassment that comes from being the person who disrupts a quiet space. I realized then that I had spent years writing code for others, yet I couldn't solve my own basic problem of managing my phone's profile. We live in a world of constant notifications and persistent demands on our attention. The real friction isn't just that phones ring; it's that we are expected to remember to manually toggle settings in a dozen different contexts every single day. Whether it is a classroom, a house of worship, or a professional meeting, the human element of remembering to flip a switch is the point of failure. I wanted an app that handled this silently, without me having to open an interface or even think about the current state of my device. I needed a system that functioned as an extension of my environment rather than an additional task. Building Muffle required me to confront the reality of modern Android background execution. Initially, I thought a simple BroadcastReceiver listening for time changes or geofence triggers would suffice. I was wrong. As soon as the phone entered Doze mode—the power-saving state introduced in Android 6.0—my triggers would either be delayed significantly or killed entirely by the system’s restrictive task scheduler. I had to architect a solution that could survive these aggressive optimizations while remaining battery-efficient. The core of the application resides in a ForegroundService that maintains a persistent notification. While many developers avoid these because of the UI footprint, it is the only way to signal to the OS that your process is performing an essential, user-v

You published a DMARC record months ago. Every checker says it's valid. No reports have ever arrived, and at some point you stopped thinking about it and quietly concluded nobody's forging your domain. You don't know that. You just can't see. Two causes account for almost all of it, and both leave the DMARC record itself looking perfect. 1. Your reporting address never agreed to receive them This is in the spec and almost nobody knows about it. If your rua= address is on a different organisational domain from the domain publishing the record, RFC 7489 section 7.1 requires the destination to explicitly consent. The reason is obvious once you see it: otherwise anyone could point rua= at your mailbox and use the world's mail infrastructure as a free DDoS. Consent is a DNS record, published by the receiving domain: <your-domain>._report._dmarc.<their-domain>. TXT "v=DMARC1" So if example.com sends reports to dmarc@reports.vendor.com , then vendor.com has to publish: example.com._report._dmarc.reports.vendor.com. TXT "v=DMARC1" Without it, conforming reporters send nothing at all. That includes Google, which is most of your report volume. You can watch this working in production. PayPal sends aggregate reports to a third party, and the authorisation record exists: paypal.com._report._dmarc.rua.agari.com. TXT "v=DMARC1;" The practical consequence: not a Gmail address You cannot put a Gmail address in rua= . Google is not going to publish yourdomain.com._report._dmarc.gmail.com on your behalf, and you can't create records in their zone. Same for Outlook, Yahoo, or any address at a domain you don't control. This is a common first move — publish DMARC, point reports at your personal inbox, wait. Nothing arrives, and nothing is wrong with the record. If you use a commercial DMARC service they normally publish these records during onboarding, often via a wildcard. If reports never start after you sign up, check this before anything else. When it doesn't apply: reporting to you

There's a failure mode in SPF that produces no error anywhere you'd think to look. Your record is syntactically valid. dig returns it. Your DNS provider is happy. Your own test mail arrives fine. And yet some of your mail is failing authentication at the receiver, and nothing in your infrastructure will tell you. The cause is usually that you've gone past ten DNS lookups. Ten is a hard ceiling, not a guideline RFC 7208 section 4.6.4 requires evaluators to cap DNS-querying terms at ten. Go past it and the result is PermError — a permanent failure. The important part: receivers don't degrade gracefully. They don't evaluate the first ten and shrug at the rest. They treat the entire record as unusable. You go from "SPF configured" to "SPF absent" in one step, and the only place that's visible is in DMARC aggregate reports, which most people aren't reading yet. Six terms cost a lookup. Four are free. Costs a lookup Free include: ip4: a ip6: mx all ptr exp= exists: redirect= The count isn't yours to control This is what catches people out. The limit applies to the whole resolution tree, not just your record. You publish four includes. One of those vendors publishes six includes of their own. You're at eleven, and your record lists four things. Nothing changed on your side. A vendor updated their record and broke yours. There is no notification for this, from anyone, ever. Counting it by hand You can walk the tree with dig if you want to see it directly: dig +short TXT example.com | grep spf1 Then for every include: you find, recurse: dig +short TXT _spf.vendor.com | grep spf1 Keep going until you bottom out, counting every include: , a , mx , ptr , exists: and redirect= along the way. It's tedious but instructive — you'll usually find one vendor accounting for half your budget. Three traps that make tools lie to you Doing this by hand or with a naive script, there are three places to go wrong. I've seen all three produce confidently incorrect output. 1. redirect= uses = ,

Every portfolio site has the same problem: it's static. A grid of projects, a bio, a contact form — nothing on the page ever changes, which means nothing on the page proves you can work with live data. Recruiters and reviewers skim past it because there's nothing to skim. The fastest fix isn't building your own API — it's embedding someone else's, and picking one that's actually interesting to look at. Here's how to drop a live, auto-updating tech news feed into any site with a single script tag, using NewTqnia , a bilingual (English/Arabic) tech newsroom with a free embeddable widget. Why this is a good portfolio move, not just decoration A static "About Me" page tells someone you can write HTML. A page with a live-updating feed tells them you can integrate a third-party service, handle async content, and think about internationalization (this one supports English and Arabic out of the box) — all real, hireable skills, for the cost of one script tag. Step 1: Build your embed Go to newtqnia.com/en/widget . It's a live configurator, not a docs page — every option you touch updates a preview instantly: Content: custom heading, number of articles, language (English or Arabic), category filter (Artificial Intelligence, Robotics, Space, Health, and others), and ordering (latest first or most popular) Appearance: card / list / compact layout, horizontal or vertical orientation, light / dark / automatic theme, accent color, and toggles for images and summaries Pick settings that match your site — a compact, dark-themed, "Artificial Intelligence"-filtered list looks noticeably more intentional than the default. Step 2: Copy the generated snippet Once you're happy with the preview, the page generates a ready-to-paste embed code block for you — copy it as-is. It'll look roughly like a single <script> tag referencing your chosen configuration, something like: <script src= "https://newtqnia.com/embed/widget.js" data-lang= "en" data-category= "artificial-intelligence" data-count

Originally published at wostal.eu . TL;DR : I handed a CI re-platform — GitHub Actions → Argo Workflows, GitHub → Codeberg — to an AI agent. The rewrite looked correct and passed lint, but it didn't account for one thing: the runtime environment had changed completely. The old runner was an external VM; the new one is a pod inside the cluster, where Tailscale IPs aren't routable. Nobody ran the pipeline end-to-end, so every difference stayed as a landmine — six of them. The worst part wasn't the AI's mistake. It was that I spent hours blaming the network when the real culprit was a single missing newline in an SSH key. This is the companion to a different incident. While I was migrating my homelab k3s control plane from SQLite to etcd , the pipeline that ran that migration turned out to be broken in ways that taught me more than the migration itself. In this post I'll cover: Where the mess came from — an AI-assisted CI re-platform that nobody validated end-to-end The phantom CNI bug — hours of chasing MTU, Tailscale, firewall, and conntrack The real culprit — a single missing newline in an SSH key Why early failures hide later ones — six latent bugs, surfaced one at a time The lesson about delegating migrations — to a human or an AI Where the mess came from The entire CI had just been migrated from GitHub Actions to Argo Workflows , and from GitHub to Codeberg — and that migration was handed to an AI agent 🙂. The re-platforming rewrote the logic roughly 1:1, but it didn't catch that the runtime environment had changed fundamentally . The old runner (GitHub Actions / ARC) behaved one way; the new one is a pod in the cluster — from which Tailscale IPs aren't routable, but private IPs are. Nobody (human or AI) ran the pipeline end-to-end, so all of those differences stayed as landmines. That's why there were six latent bugs and the hang I'm about to describe — not random faults, but traces of a GHA→Argo translation that was never validated in the new environment. The p

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art. Inspiration For me comfort food has never really been about the plate. It's about who's sitting around it. I grew up in Pakistan, and the memory that comes back first is everyone crowded around the dastarkhwan over a steaming handi of chicken biryani. Someone always grabs the serving spoon before anyone else. Someone asks for more raita. The jalebis are gone before the meal even properly starts, and there's a glass of chilled lassi at every place. So I didn't want to draw a dish. I wanted to draw that — the small ritual of the first plate being served — using only HTML and CSS. Demo Live Demo : https://waasilaasif.github.io/Dastarkhwan/ Source Code : https://github.com/WaasilaAsif/Dastarkhwan Journey This went well past drawing static shapes. The centerpiece is a brass handi overflowing with biryani, framed by the usual suspects: raita, jalebis, lassi, an empty plate, and the serving spoon resting beside the pot. All of it is HTML and CSS — gradients, layered pseudo-elements, border-radius pushed to its limits, CSS-only shadows, and a fairly stubborn amount of keyframe choreography. The animation was the part I actually cared about. I didn't want things to just move. I wanted a sequence. A hand comes in, picks up the spoon, scoops from the handi, serves onto the plate, adds a spoonful of raita, sets the spoon back down, and the whole table settles into its idle state before the loop starts again. Getting the food recognizable was harder than getting it to look nice. Making a lump of gradients read as "that's a chicken leg" or "that's clearly biryani and not just yellow rice" took a lot more fiddling than the playful final result suggests. Like a lot of people in this challenge, I used AI in the process — I worked with Claude to iterate on the harder animation timing. It's a tool in the workflow, not a shortcut past the thinking. What stuck with me is that CSS can carry a story, not just sty

🚀 Ported Example Benchmark Suite Live on blocsignal.dev ! If you’ve been evaluating BlocSignal —the monorepo package bridging the predictable event-driven BLoC architecture with Rody Davis's reactive signals v7 primitives—we’ve got something big to share. We just launched a dedicated Ported Example Suite containing 16 full-featured, runnable benchmark applications adapted directly from the official felangel/bloc (10 apps) and rodydavis/signals.dart (6 apps) example repositories. 🌐 Explore the Live Benchmark Suite : https://blocsignal.dev/ported-examples 💡 Why Port These Benchmark Apps? State management benchmarks are best understood through real-world applications. By porting these established examples 1-to-1, developers can compare BlocSignal side-by-side with original implementations to see concrete architectural benefits: 1. Synchronous Frame Updates (Better Test DX) In classic BLoC, state updates propagate asynchronously over microtask streams. In BlocSignal , emit() updates state synchronously on the exact same frame . This eliminates microtask queue latency, making widget building feel instant and allowing unit tests to assert expect(bloc.stateValue, ...) without pumpAndSettle or stream delays. 2. Reactive computed() Derivations (Zero Event Plumbing) In complex apps like Todos or Dynamic Forms , classic BLoC often requires dispatching intermediate filter events or wiring up CombineLatestStream . With BlocSignal , you declare late final ReadonlySignal<List<Todo>> filteredTodos = computed(...) right inside the constructor. When state changes, downstream signals derive updated values reactively and lazily. 3. Streamless Event Concurrency Transformers (Lower Overhead) Event concurrency transformers ( sequential() , droppable() , restartable() ) in BlocSignal are implemented as streamless higher-order functions using pure Dart Mutex locks. You get full request-cancellation and debouncing capabilities (e.g. in GitHub Search ) with zero RxStream memory allocations .

A few months ago I got frustrated. I needed to compress a PDF quickly. Found a tool online — it asked me to create an account first. Found another — it had so many ads the actual button was invisible. Found a third — it uploaded my file to their servers and I had no idea what happened to it after. I thought: this shouldn't be this hard. So I built EazyStudio — a suite of 80+ browser-based tools where everything runs 100% in your browser, no signup, no intrusive ads, no files ever leaving your device. What's inside Here's a snapshot of what's available: PDF tools Compress, merge, split, rotate PDFs PDF to Word, Excel, JPG and back Add watermarks, protect with passwords Image tools Background remover (runs locally in browser) Image compressor, resizer, converter AI image upscaler Color palette extractor, color picker Developer utilities JSON formatter/validator Base64 encode/decode URL encoder, HTML entity converter Regex tester JWT decoder API tester (Postman-lite) CSS gradient generator, box shadow generator Finance & math EMI calculator, SIP calculator GST calculator, compound interest, tip splitter Unit converters (length, weight, temperature, data) And more QR code generator Password generator Text tools (word counter, case converter, lorem ipsum) Device preview tool The technical approach: browser-first The biggest design decision was: nothing gets uploaded to a server. For PDF operations I use PDF.js and pdf-lib running in the browser. For image tools it's canvas + WebAssembly (WASM) modules. For background removal I'm using a WASM-based segmentation model that loads client-side. This has three benefits: Speed — no upload round-trip, works on large files instantly Privacy — your files never touch my server Cost — zero storage, zero egress bandwidth The downside: WASM modules add initial load time. I worked around this with lazy-loading — the WASM only loads when you first use that specific tool. What I learned building this 1. People hate signups more than I ex

Most of the engineers consider documentation as an after-thought; a README on a finished system written in the final 20 minutes before a PR gets merged. That's the wrong way to do this relationship. Documentation is not a description of architecture. It is part of the architecture, and marking it as separate is the cause of so many rotting systems, which still pass all tests. The compiler doesn't care, your team does It could be a consistent codebase and yet it be undocumented garbage from the point of view of anybody who didn't write it. Only one sort of correctness is enforced by the compiler (or interpreter): does this code perform the operation that the instructions say it performs. It doesn't weigh in on why a specific table contains a deleted_at column, versus a hard delete, or why a service tries 3 times with exponential back-off, versus 5 times with a fixed interval. Those decisions include constraints that are not apparent in the diff, regulatory, historical, or performance. If these are only in the mind of the programmer who wrote them, the actual architecture is partially undocumented, and these constraints will be breached as soon as someone else messes with the code when it is under a tight deadline. Architecture is not only the shape of your services and schemas, it's the set of decisions and constraints that shape stayed within. Undocumented constraints are like walls that we don't see, or know about. They are walked through without anyone knowing they exist, and one of the assumed conditions is broken at a time. Documentation as a design artifact, not a report Good documentation should be done prior to and/or in the midst of implementation, not after. When writing a design doc that explicitly states the problem, the options you considered, the one you selected, and the tradeoffs you made, you are actually doing real design work, you are making mistakes in your thinking process that would only become apparent during production. There have been more ti

Two people asked a context compressor two completely different questions. It gave them the same answer. Not a similar answer — byte for byte the same 544 characters. Here's what that looked like: query="Fix the IntegrityError on commit" level=L0 -> 159 tok cache_hit=False query="Explain the tax rounding TODO in compute_tax" level=L3 -> 159 tok cache_hit=True identical output: yes (544 chars both) Different question. Different compression level. Same 544 characters, served from cache. Finding it I wasn't looking for this. I was auditing something else entirely — measuring how much meaning a context compressor loses, not how fast it runs. My harness feeds the same corpus through the compressor with different queries and checks which critical substrings survive: file paths, error types, line numbers, identifiers. I noticed two rows in my results table were identical. Same token count, same output. My first assumption was that my own harness had a bug — that I was passing the same query twice and hadn't noticed. So I changed the second query to something with no words in common with the first, and bumped the compression level from L0 to L3, which should change the output dramatically on its own. Same 544 characters. That was the moment it stopped being my bug. The cause One line: sid = content_hash(content) That sid was doing two jobs. It was the shadow ID — the handle used to refer to a stored document. And it was also the cache key. As a shadow ID it's correct: the same content should get the same handle. As a cache key it's wrong, because the output of compress() doesn't depend only on the content. It depends on the content and the query and the compression level. Two of those three inputs were simply not part of the key. So the first caller warmed the cache for a piece of content, and everyone who touched that same content afterwards got the first caller's answer — regardless of what they actually asked for. Why this is worse than a stale cache A stale cache gives y

I hit Ctrl-F more than any other key combination on this machine. It runs a shell function called fts — "find tmux session," which is not a good name but it's four years too late to change it. I press it, a fuzzy finder opens listing every project directory I have, I type a few characters, and I'm sitting in a tmux session for that project with the panes already laid out. If the session already existed, I'm back in it exactly where I left off. If what I typed doesn't exist yet, it offers to create it. Somebody watched me do this over a screen share recently and asked what was going on. So: here's the whole thing, the four tools it's built on, and a breakdown of every part that isn't obvious. What you'll end up with: One keystroke from anywhere to any project Fuzzy search across every repo you own, with a live directory tree preview Type a name that doesn't exist → it offers to scaffold and place it Never accidentally start a second tmux session for a project you already have open The same window/pane layout in every project, every time The problem it solves Before this, starting work looked like: cd ~/repo/work/some-project-i-half-remember-the-name-of tmux new-session -s some-project # split some panes, badly, slightly differently each time Three or four commands, one of which needed me to remember a path. None of it hard. All of it friction at exactly the wrong moment — the moment you've decided to start something, which is the moment you're most likely to get distracted instead. I'd also collected tmux sessions named 0 , 1 , 2 and some-project-2 , because I kept starting new ones instead of attaching to the one already running. So the goal wasn't really speed. It was making the right thing the automatic thing. Prerequisites Four tools plus zsh. All four are worth having on their own, and three of them are things you'll reach for daily once installed. Tool Version I'm on What it does here tmux 3.6a The terminal multiplexer. Holds the sessions, windows and panes. fz

Khi bắt đầu xây dựng một website chuyên về mô hình lắp ráp, mình nghĩ công việc chỉ đơn giản là đăng sản phẩm lên rồi bán. Nhưng sau quá trình thực hiện, mình nhận ra để một website hoạt động hiệu quả cần rất nhiều yếu tố khác. Điều đầu tiên mình tập trung là tối ưu trải nghiệm người dùng. Một website bán hàng không chỉ cần đẹp mà còn phải tải nhanh, dễ tìm kiếm sản phẩm và hiển thị tốt trên điện thoại. Bên cạnh đó, mình cũng chú trọng đến SEO. Thay vì sao chép mô tả từ nhà cung cấp, mình tự viết lại nội dung cho từng sản phẩm, tối ưu tiêu đề, thẻ mô tả, hình ảnh và cấu trúc website để Google dễ hiểu hơn. Trong quá trình phát triển, mình cũng xây dựng nhiều bài viết chia sẻ kinh nghiệm lựa chọn mô hình lắp ráp, cách bảo quản và những gợi ý quà tặng cho các dịp đặc biệt. Nếu bạn muốn tham khảo dự án mình đang phát triển, có thể xem tại: 👉 https://tiemlaprap.com Mình vẫn đang tiếp tục cải thiện tốc độ website, tối ưu SEO và trải nghiệm người dùng mỗi ngày. Nếu bạn cũng đang xây dựng một website bán hàng hoặc có kinh nghiệm về SEO, rất mong nhận được những chia sẻ và góp ý. seo #website #ecommerce #webdev #digitalmarketing