标签：#dev

Originally published on hexisteme notes . I have a small pipeline that crossposts my notes to dev.to. It parses a Markdown file's front matter, builds a payload, and calls the dev.to API to publish. It has 19 gate tests, and every one of them was green the whole time it was shipping. It published nine articles. All nine went live with their titles broken — the front-matter quotes were sitting right there in the title, visible to anyone who looked, for nine days, and nothing in the pipeline noticed. I didn't notice either. A human had to open the dev.to profile page by accident before anyone found out. This is the postmortem, and the reason I'm writing it up as a general essay rather than just a fixed-bug log is that the root cause isn't specific to dev.to, or to Markdown front matter, or to Python. It's a category of mistake that any pipeline with an external endpoint on the other end can make: testing the payload you build, and never testing what the other system does with it. The pipeline that had "passed everything" The shape of it is ordinary. A draft file has YAML-style front matter — title: "Some Title" — because that's the convention. A parser reads the front matter and pulls out the title. A payload builder takes that title and a few other fields and assembles the JSON body for the dev.to API. The API gets called, dev.to accepts it, the article is live. Nineteen gate tests cover this path — the front-matter parsing and the payload/API contract of the pipeline's own code. All green, every publish. The gap is in what "parses the front matter" actually means. The parser isn't a real YAML parser. It's closer to line.partition(":") — split each line on the first colon, take the right-hand side as the value. That works fine for tags: testing, devops where there's nothing to unwrap. It does not work for title: "Some Title" , because the quote characters are part of the string on the right-hand side of the colon, and a partition-based parser has no concept of "this

Introduction As developers, we're often drawn to the fast-paced and ever-evolving world of technology. The thrill of learning new skills, the rush of solving complex problems, and the satisfaction of building something from scratch can be incredibly exhilarating. However, this enthusiasm can sometimes tip into an unhealthy obsession, leading to burnout. The Psychological Impact of Constant Learning The tech industry is notorious for its fast pace, with new technologies and frameworks emerging every month. This creates a sense of FOMO (fear of missing out) among developers, who feel pressure to stay updated and relevant. The constant learning curve can be mentally draining, leading to feelings of anxiety and stress. Example: Consider the popular saying 'You can't be good at everything.' This is a crucial fact to acknowledge in our ever-evolving tech world. Example of prioritizing learning paths learning_paths = [ ' AI ' , ' Cloud ' , ' Cybersecurity ' ] priority_path = input ( ' What path do you want to prioritize? ' ) if priority_path in learning_paths : print ( ' Great choice! ' ) else : print ( ' Consider your options carefully. ' ) Environmental Factors: Workplace Culture and Resources The workplace culture and availability of resources can significantly impact a developer's likelihood of burnout. A toxic work environment, lack of support, or inadequate resources can exacerbate burnout, while a supportive and inclusive culture, mentorship, and access to resources can help mitigate it. Recognizing Early Signs of Burnout and Implementing Self-Care Burnout can sneak up on us, but there are early warning signs to look out for. If you're consistently feeling exhausted, disconnected from work, or struggling to focus, it may be time to take a step back and reassess your priorities. Implementing self-care practices, such as exercise, meditation, or hobbies outside of work, can help maintain a healthy work-life balance. ## Conclusion As developers, we need to acknowledge

AxonASP is a high-performance Classic ASP engine written in Go — but here's the twist: it runs JavaScript (JScript) natively on the server side. You get a synchronous, predictable execution model, full ECMAScript 5/6+ support, and zero dependency on Node.js or any third-party JavaScript runtime. And yes — you can build an entire production website with it. Why AxonASP Changes the Game for Server-Side JS Most developers associate server-side JavaScript exclusively with Node.js. And Node.js is great — until you're drowning in async/await chains, package.json conflicts, and the 47th minor version bump of a dependency that broke your build. AxonASP takes a fundamentally different approach. Instead of wrapping everything in an event loop and forcing asynchronous patterns everywhere, AxonASP's JavaScript engine executes code synchronously by default . You write your server logic the same way you write your frontend logic — line by line, top to bottom. It compiles through a high-performance AST parser and runs directly on a custom Go-based virtual machine. The result? Cleaner code, simpler debugging, and a massive reduction in cognitive overhead. What You Get Out of the Box Full ES5 + ES6 support (classes, arrow functions, template literals, destructuring, proxies, for...of , Map , Set , Symbol , typed arrays — 37+ modern features documented) Synchronous execution — no callback pyramid, no promise chains for basic I/O ASP intrinsic objects — Request , Response , Session , Application , Server — all accessible directly from your JS code No npm install required — just write .asp or .js files and point the server at them CLI execution — run JavaScript files from the command line for automation, batch processing, or testing The Philosophy: Simplicity Over Complexity Here's a hard truth: most web applications don't need 2,000 npm modules. They need to read a database, render HTML, handle form submissions, and maybe serve a JSON API. That's it. The modern JavaScript ecosystem ha

In today's world where websites and web applications play a very important role in businesses, choosing the right tool for developing a project is of great importance. Developers usually use frameworks to build websites faster, more securely, and more professionally. One of the most powerful and popular web development frameworks is Django . Django is a powerful and open-source web framework built with the Python programming language that allows developers to create complex and professional websites and web applications in a short amount of time. From simple websites to large systems, online stores, social networks, admin panels, and professional APIs — all can be developed with Django . In this article, we will thoroughly examine what Django is, why it has become popular, what its use cases are, and why many developers and large companies use it. What is a Framework? Before we get to know Django , it's better to understand the concept of a framework. A framework is a collection of pre-built tools, libraries, and rules that help developers build software faster and with better structure. In the past, developers had to create many features from scratch; for example: User login system Database connection Request management Application security Page structure File management But by using a framework, many of these capabilities are already prepared, and the developer can focus on the core logic of the project. Simply put, a framework is like a ready-made skeleton for building software that increases the speed and quality of development. What is Django? Django is a server-side (backend) web development framework written in Python . This framework is designed for building web applications and provides developers with many features by default. The main goal of Django is to make web development faster, more secure, more organized, and more scalable. Django's official slogan: The web framework for perfectionists with deadlines This slogan indicates that Django was built for

Introdução O nome do princípio vem do próprio nome do projeto de pesquisa (que remete a Deméter, deusa grega da agricultura — a metáfora era "cultivar" software que cresce de forma incremental e adaptável, não do princípio de acoplamento em si). O projeto Demeter investigava como reduzir o custo de manutenção de sistemas orientados a objetos observando que boa parte das mudanças de software quebrava código muito distante do ponto onde a mudança real acontecia — um efeito cascata causado por classes que conheciam profundamente a estrutura interna de outras classes. Essa observação foi confirmada empiricamente alguns anos depois: em 1994, Chidamber & Kemerer publicaram as famosas métricas CK ( A Metrics Suite for Object Oriented Design ), nas quais o CBO (Coupling Between Objects) — quão acoplada uma classe é a outras — se tornou um dos preditores mais fortes de defeitos e esforço de manutenção em estudos empíricos posteriores de engenharia de software. Ou seja: a intuição por trás da Law of Demeter (menos acoplamento = menos bugs ao mudar código) tem respaldo em dados de décadas de pesquisa empírica em qualidade de software. Definição Também chamada de "Principle of Least Knowledge" , a formulação clássica é: Um método M de um objeto O só deve chamar métodos de: O próprio O Os parâmetros recebidos por M Qualquer objeto que M crie/instancie internamente Os componentes diretos de O (seus atributos/campos) Variáveis globais acessíveis a O Resumo popular: "use apenas um ponto" — evite código como: pedido . getCliente (). getEndereco (). getCidade (). getNome () Isso é conhecido como "train wreck" (trem de vagões) — cada . é um vagão acoplado ao anterior. Se a estrutura interna de Cliente ou Endereco mudar, todo código que fez essa travessia quebra, mesmo estando em um módulo completamente não relacionado. Porque isso importa na prática? Quando o método M faz objeto.getX().getY().metodo() , ele passa a depender da estrutura interna de X e Y , não só da interface pública d

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry . Copilot started whispering random letters into my ear, like it was leaking secret tokens from the underworld! Cute, but also, a bug! This sounds like a classic data serialization or sanitization failure in the text-to-speech (TTS) pipeline. What is happening here is a classic disconnect between the UI layer (what you see on screen) and the data payload sent to the background engine. When you read a response on screen, the Android app renders clean Markdown or HTML. However, when you tap "Read Aloud," the app has to strip away all background formatting, structural code, and system metadata, converting the response into a raw, clean string of text before handing it off to the mobile TTS engine. In this case, the background script running the relay is failing to sanitize that data stream. It is accidentally passing raw control characters, escape sequences, or hidden system tracking tokens (like structural delimiters or character-encoding artifacts) directly into the text pipeline. Because the mobile TTS engine doesn't understand that these symbols are meant to be ignored structural code, it tries to do exactly what it’s programmed to do: it reads them literally. When the voice engine encounters unexpected symbols, raw strings of characters, or broken text boundaries in the middle of a sentence, it completely disrupts the engine's predictive text processing: ● Pitch and Speed Fluctuations: Mobile TTS engines use deep learning models to predict natural tone, cadence, and inflection based on context. Injecting random, non-linguistic characters completely derails the engine's context window, causing it to panic-adjust its pitch, speed, and emphasis mid-sentence. ● Mispronunciations: The hidden characters slice words in half semantically, forcing the engine to mispronounce standard words because it's trying to blend them with the rogue data trailing right behind them. Here is a direct, high-s

Every AI-generated site we have inherited was missing the same eighteen things. None of them are visible in a screenshot. All of them are visible to Google. July 10, 2026 An AI-generated site looks done. It has a hero, sections, a color palette, and copy that reads well in a screenshot. Then we open the page source, and the production work is missing. Not some of it. The same eighteen things, every time. None of them change what a human sees in a browser. All of them change what a crawler, a link preview, or a cache does with the page. Here is the list we run before we call anything live. Crawlability and indexing This is where the gap is widest, because a client-rendered single-page app hands crawlers an empty div and expects them to run JavaScript to fill it. Many will not. We fix that with static work. Prerendered static HTML per route , so the first paint is real content and not a loading spinner. A sitemap.xml generated from a single route manifest , so it lists every page and no page twice. A robots.txt that points at that sitemap and does not accidentally disallow the whole site. A canonical URL on every page , because a screenshot cannot show you a missing canonical tag. A meta title and description written per page , not one template repeated across the whole site. Structured data as JSON-LD for the page types that support it. IndexNow submission on deploy , so search engines learn about changes without waiting for a crawl. An llms.txt file describing the site for the AI crawlers that now read it. Sharing and presentation A link is content too. When someone pastes the URL into Slack or iMessage, the site is representing itself, and the defaults are usually blank. Open Graph tags for the title, description, and image. Twitter card tags , which are close to Open Graph but not identical. A per-page share image at 1200x630 in PNG. WebP renders unreliably in LinkedIn and iMessage previews, so we ship PNG here even though we prefer WebP elsewhere. Descriptive alt

Every developer has a "starter project." Some keep a GitHub template. Some duplicate their previous SaaS project. Some run create-next-app and spend the next two hours installing the same dependencies, configuring the same tools, and recreating the same folder structure. I was in the second group. Every new project started the same way. bun create next-app Then came the checklist. Install Tailwind CSS. Configure Biome. Add shadcn/ui. Organize folders. Set up a UI library. Configure TypeScript. Add environment files. Set up a monorepo. Copy utility functions. Configure path aliases. Install development tools. None of these tasks were difficult. They were just repetitive. After starting enough projects, I realized something: I wasn't building products. I was rebuilding the same foundation over and over again. The Starter Kit Trap Like many developers, I created a "starter repository." Whenever I wanted to build something new, I'd clone it. It worked... until it didn't. Eventually I had multiple starter repositories. One for a monorepo. One for a standalone project. One with authentication. One without authentication. One for experiments. One that was already outdated. Keeping them synchronized became its own maintenance project. Fix a bug in one. Forget to fix it in another. Upgrade Next.js in one repository. Forget the rest. The more starters I created, the less useful they became. Why Existing Starters Didn't Quite Fit There are already fantastic starter kits in the ecosystem. Some focus on minimalism. Others include every feature imaginable. The problem wasn't that they were bad. The problem was that they optimized for someone else's workflow. Every project I build starts with almost the same stack. Next.js TypeScript Bun/pnpm Tailwind CSS v4 shadcn/ui Biome Production-ready project structure I didn't want to answer twenty configuration questions every time I scaffolded a project. I wanted one command. npx create-notils my-app …and be ready to start building. Opini

CSS has been around for about 30 years. It is the only styling language built specifically for the web platform, and it is one of the three core technologies that make the web what it is. Without it, every page would be a block of black text on a white background, laid out from top to bottom with no control whatsoever. That is not an exaggeration. That is what the web looks like without CSS. The original design goal of CSS has never changed. It is a declarative language that describes how documents should be presented. It does one thing and it does it in a standardized way that works across browsers. That restraint is not a weakness. It is the reason CSS has survived for two decades without being replaced. It never tried to be more than a styling language. Looking back at frontend development in the late 2000s, the frustration is hard to overstate. The gap between what CSS could do and what designs required was so wide that the platform itself felt like the obstacle. The vendor prefix era is the clearest example. You wrote -webkit- , -moz- , -ms- , -o- before every experimental property, often all four, because no browser could agree on when a feature was stable. Autoprefixer became a standard dependency not because developers were lazy, but because manual prefix management was genuinely unsustainable. It was not that CSS was badly designed. It was that the pace of the platform could not keep up with what developers were building. This created a pattern. Every time the platform fell short, the community built a workaround. Those workarounds became tools. Those tools became dependencies. And those dependencies reshaped how we thought about CSS entirely. Each new abstraction solved a real problem, but it also moved us further from writing actual CSS. Eventually, it became natural to assume that any serious project needed a layer on top of CSS to be viable. However, if CSS is so good at its job, why have we spent so long building alternative ecosystems on top of it? Pr

If you are like me, then you have also tried to change a specific thing in your workout plan that your app of choice didn't support. Well I'm trying to fix that issue with a workout app in which you'll be able to customize pretty much everything (WIP). Building the thing in Flutter to have mobile (starting with Android) and web. The web app is live! If you work out and have tried similar apps before, your feedback would be gold. But really any feedback is appreciated. I also found that finding the required 12 people with an Android phone for closed testing on Google Play Console was more difficult than anticipated. So if you'd be interested in that, hit me up at dev@notes.fitness ! Gym Notes — A Customizable Workout Logbook for Strength Training A free, customizable workout logbook that tracks exercises, sets, reps, and weights. Built-in training plans with automatic progression. gym.notes.fitness

This started as a comment @wrencalloway left on my last post. It was sharp enough that it deserved more than a reply — so here's the full version. You did the work. The page is server-rendered. The JSON-LD is in the raw response. curl returns the whole article, headline and all. A crawler that fetches your URL gets everything it needs. Except the crawler never fetches your URL. It asks the CDN, and the CDN says 403. Your content is perfect and unreachable. This is the layer underneath the one everyone talks about — and it's invisible in every tool you'd normally reach for. Two different kinds of "no" robots.txt is a note taped to the door. It says "please don't come in." A polite crawler reads it and turns around. A rude one ignores it and walks straight past. Either way, the note never touches your bytes — it's a request, enforced entirely by the visitor's own manners. A WAF or CDN rule is the door. It answers the request itself, at the edge, before anything reaches your origin: 403 Forbidden , 429 Too Many Requests , or a JavaScript challenge the bot can't solve. The HTML behind that door could be a masterpiece or a blank page. The bot sees neither. It sees the status code. People spend weeks perfecting the note and never check whether the door is locked. This isn't hypothetical — here's the data Cloudflare Radar publishes what actually happens to AI-crawler traffic across its network. From the AI Insights dashboard (7-day view, as of 18 July 2026): Of all HTTP responses served to AI bots and crawlers: 200 OK — 73.6% 403 Forbidden — 5.2% 429 Too Many Requests — 1.3% 503 — 1.1% AI-crawler response codes. Source: Cloudflare Radar, AI Insights, 7-day view, 18 Jul 2026. Read that again. More than one in fifteen requests from AI crawlers is being actively refused at the edge — 403 or 429 — before it ever touches the content. Not deprioritised. Refused. And most of that isn't a decision. It's a default — a managed WAF ruleset, a "block AI bots" toggle flipped in 2024, a

I Built a Crew of AI Agents That Review Code Like a Real Team — Then Watched Them Argue With SigNoz My submission for the Agents of SigNoz Hackathon (Track: AI & Agent Observability) The idea Most "AI code review" demos are one LLM call with a clever prompt. That's fine, but it doesn't reflect how review actually works on a real team — different people care about different things. Someone obsesses over edge cases. Someone else nitpicks naming. Someone else only cares if it's going to be slow in production. And then someone has to actually make the call on whether the PR merges. So I built that as a crew: a Logic Reviewer , a Style Reviewer , and a Performance Reviewer — three independent agents, each with a narrow system prompt that tells them to only look at their lane — followed by a Moderator agent that reads all three opinions and produces one final verdict, calling out disagreement when it happens. The interesting engineering problem wasn't the prompting. It was: once you have four chained LLM calls, how do you actually know what's happening inside your own system? Why observability, not just another agent demo Once I had the crew working, I had zero visibility into it. Four sequential API calls, each with its own latency and token cost, and all I had was print() statements. If the moderator gave a weird verdict, I had no fast way to tell whether the logic reviewer hallucinated an issue, or the moderator just summarized badly. If a run felt slow, I couldn't tell which of the four agents was the bottleneck. This is exactly the gap SigNoz is built for, so I instrumented every agent call with OpenTelemetry: Each specialist agent and the moderator run inside their own span ( agent.logic_reviewer , agent.style_reviewer , agent.performance_reviewer , agent.moderator ) All four are nested under one parent span, code_review_session , so a single review run shows up as one trace with four child spans Every span carries the attributes that actually matter for debugging a

Most A/B testing happens in the browser: a script swaps a headline or button color after the page loads. That works for surface-level UI changes, but it cannot test the logic that runs before a page is ever rendered — a pricing algorithm, a search ranking model, a checkout flow, or a backend API response. Server-side A/B testing moves the experiment decision into your application code, where you control the full request lifecycle. This guide explains when to test server-side, how it differs from client-side testing, and how to implement it with Optimizely Feature Experimentation, including working SDK code for Node.js and Python. What Server-Side A/B Testing Is In a server-side A/B test, your application server decides which variation a user sees and renders the response accordingly. Instead of shipping the control experience and patching it in the browser, the server already knows the assignment by the time it builds the HTML, the JSON payload, or the rendered component. The decision is deterministic: a given user ID is consistently bucketed into the same variation, so the experience stays stable across requests and devices. Your code branches on that assignment, serves the corresponding experience, and reports a conversion event when the user does something that matters — a purchase, a signup, a search that returns a click. This is the model Optimizely calls Feature Experimentation . If you have used Optimizely before, you may know this product by its former name, Full Stack — the SDKs, datafile, and decision model are the same lineage, now under the Feature Experimentation name. Searchers still look for "Optimizely full stack," but the current product and documentation use Feature Experimentation. When to Test Server-Side Server-side testing is the right tool when the thing you are changing is not a cosmetic, post-render tweak. Reach for it in these situations: Backend logic and algorithms. Recommendation engines, search ranking, fraud scoring, feed ordering, and

Every team doc tool promises "search everything." Ours did too — and it still didn't answer the question new hires actually ask: not "where is this doc," but "why does this decision look the way it does, and what else does it touch?" We spent the last few months trying to solve that by treating team docs less like a filing cabinet and more like a graph. Here's what we tried, what broke, and what we'd do differently.

WordPress affiche une page blanche, un 403, ou la boucle de connexion infinie sur /wp-admin : voici le protocole de diagnostic que nous utilisons, dans l'ordre, avec les commandes exactes. 1. Identifier le type de blocage Trois familles de symptômes, trois causes différentes : 403 Forbidden : règle serveur ( .htaccess , WAF, IP bannie) ou cookies corrompus Boucle de redirection login : problème de cookies/HTTPS mal déclaré ( WP_HOME / WP_SITEURL ) Page blanche (WSOD) : erreur PHP fatale, souvent une extension ou le thème 2. Le fix express des cookies (cause n°1 du 403) Avant de toucher au serveur, videz les cookies du domaine et testez en navigation privée. Si ça passe en privé, c'est un cookie corrompu — pas le serveur. Le détail complet du mécanisme est dans notre guide WordPress erreur 403 et cookies bloqués . 3. Désactiver les extensions sans wp-admin # Via WP-CLI (le plus propre) wp plugin deactivate --all # Sans WP-CLI : renommer le dossier mv wp-content/plugins wp-content/plugins.off Si wp-admin revient, réactivez une par une pour isoler la coupable. 4. Vérifier .htaccess et les règles serveur Un .htaccess corrompu ou une règle de sécurité trop stricte bloque l'accès admin. Régénérez un fichier propre (Réglages → Permaliens, ou à la main). Pour générer des règles saines — protection wp-login, anti-hotlink, cache navigateur — sans risquer la syntaxe, nous maintenons un générateur de .htaccess WordPress gratuit . 5. Purger tous les caches (souvent oublié) Un cache de page qui sert une vieille version de wp-login provoque des boucles incompréhensibles. Purgez dans l'ordre : cache navigateur, cache de page (extension), cache serveur (LiteSpeed/Varnish), OPcache. La méthode complète par type de cache : comment vider le cache WordPress . 6. Le guide complet Chaque étape ci-dessus est développée (avec les cas 404 wp-admin, erreur critique, mot de passe perdu via WP-CLI et phpMyAdmin) dans notre guide de référence : accéder à wp-admin : connexion et administration Wo

A few months ago, I was searching for a backend engineering job. Every day looked the same: Open LinkedIn Open Naukri Search for Python jobs Open dozens of tabs Read every job description Apply Repeat The frustrating part wasn't finding jobs. It was finding the right jobs . I kept getting recommendations for roles that technically matched my resume because they contained words like Python , Backend , or API , but after reading the description I'd realize they wanted a completely different skill set. I started wondering: Why are job boards still matching keywords instead of understanding what a developer actually knows? That question eventually turned into a side project called Jobspiq . The Problem Imagine these two jobs: Job A Python FastAPI PostgreSQL Redis Job B Java Spring Boot Oracle Kafka Both are "Backend Engineer" roles. A keyword-based system often treats them as similar. As developers, we know they're not. What I Built Instead of matching keywords, I built a system that compares a developer's profile with a job description to understand how well they actually fit. The platform: Collects jobs from multiple sources. Removes duplicate postings. Scores every job based on how closely it matches your profile. Sends alerts only for high-quality matches. Helps track applications in one place. The goal isn't to show more jobs. It's to show fewer, better ones. What I Learned Building the product taught me something interesting. Writing the software was the easier part. Helping people discover it is much harder. That's why I'm starting to build in public and share what I'm learning along the way. If you've ever built search systems, recommendation engines, or developer tools, I'd love to hear your thoughts. You can check out the project here: https://jobspiq.in Feedback is always welcome.

Every team I've worked with has a version of the same Slack message. Someone posts a PR link, adds a...

I run a scheduled agent that writes and publishes DEV.to articles twice a day. Step 5 of its instructions has always said the same thing: write the log entry, commit the drafts, push. I've read that line a dozen times without questioning it. This morning I actually checked what "commit the drafts" had been doing for the last month, across more than thirty published articles. The answer: nothing. Not once. the check that should have happened on day one The task instructions reference source files like drafts/scheduled-agent-shared-quota-no-memory.md and drafts/one-env-key-two-usernames.md in every log entry — real filenames, written by the agent, presumably sitting in the repo as a record of what was drafted before it got published. I went looking for one of them: $ git log --all -- drafts/ $ # (nothing) Empty. Not "one commit, then deleted later" — completely absent from git history since the very first commit in this repo. Every single run that logged "committed drafts + the log" had, in fact, only ever committed the log. why git let this happen silently .gitignore in this repo has listed drafts/ since the initial commit: . env __ pycache__ / *. pyc codes / drafts / . omc / . claude / CLAUDE . md That line predates the scheduled publishing task entirely — it was almost certainly written back when drafts were just scratch files someone edited by hand before a publish script existed. Nobody revisited it when the publishing task's instructions later started saying "commit the drafts." The instruction and the ignore rule have been quietly contradicting each other since before either was written by the same person in the same sitting. Here's what actually happens when a script (or an agent) runs git add drafts/whatever.md in this repo: $ git add drafts/gitignore-ate-my-drafts-folder.md The following paths are ignored by one of your .gitignore files: drafts hint: Use -f if you really want to add them. hint: Turn this message off by running hint: "git config advice.addIgn

This is a submission for DEV's Summer Bug Smash: Clear the Lineup . Project Overview Formbricks is an open-source survey and experience-management platform. Its packages/surveys package ships the client-side survey runner, and inside it, packages/surveys/src/lib/logic.ts is the module that decides, for every question and every "skip logic" / branching rule a survey author configures, whether a given condition ( equals , doesNotEqual , contains , isEmpty , and friends) is true for a respondent's answer. This is pure, unglamorous logic — but it's load-bearing: it's what routes respondents through the correct sequence of questions. I picked up issue #8527 for the "Clear the Lineup" track, which reports that doesNotEqual conditions weren't behaving correctly for single-choice questions. Bug Fix or Performance Improvement The doesNotEqual operator is supposed to be the exact logical negation of equals . For most answer shapes it was. But for MultipleChoiceSingle answers, the survey runtime sometimes represents the selected value as a single-element array rather than a bare string (this happens via getLeftOperandValue , e.g. when a choice answer is merged with an "other" option path). To handle that shape, both equals and doesNotEqual had a special-case clause that unwraps a one-element array and compares its only entry to the right-hand value. equals 's fallback: return ( ( Array . isArray ( leftValue ) && leftValue . length === 1 && typeof rightValue === " string " && leftValue . includes ( rightValue )) || leftValue === rightValue ); doesNotEqual 's fallback (before the fix): return ( ( Array . isArray ( leftValue ) && leftValue . length === 1 && typeof rightValue === " string " && ! leftValue . includes ( rightValue )) || leftValue !== rightValue ); At a glance this looks like a faithful "negate every sub-expression" mirror of equals . It isn't. The array-includes clause was correctly inverted ( !leftValue.includes(rightValue) ), but the second disjunct, leftValue !==

This is a submission for DEV's Summer Bug Smash: Clear the Lineup . Project Overview Typst is the Rust-based markup typesetting system that's been quietly eating LaTeX's lunch for the last couple of years — you write plain-text markup, Typst compiles it to PDF (or HTML) with a real incremental compiler underneath instead of a multi-pass macro soup. Part of what makes it pleasant is that it exposes its own evaluator to itself: a document can call #eval("some typst code") and get back whatever that code produces, at runtime, inside the document being compiled. It's a small feature, but it opens up a surprisingly deep rabbit hole, which is exactly where this bug was hiding. Bug Fix or Performance Improvement The problem: typst/typst#8632 reports that Typst crashes instead of erroring when #eval is used to recursively re-import the file it's running in. The repro is one line. Save this as overflow.typ : #eval("import \"overflow.typ\"") Then: $ ./target/debug/typst compile overflow.typ overflow.pdf thread 'main' (750833) has overflowed its stack fatal runtime error: stack overflow, aborting No PDF, no diagnostic, no exit code you can act on — just a native stack overflow and a SIGABRT. Typst has had cyclic-import detection since forever; a normal top-level import "overflow.typ" inside itself gets caught cleanly with an error: cyclic import message. Something about routing the import through #eval specifically was bypassing that check. The hunt I'll be upfront about how this investigation actually went: I worked through it with Claude (Anthropic's coding agent) rather than solo. The triage pass it did before I sat down with the code had already narrowed the search to one function — eval_string in crates/typst-eval/src/lib.rs — and named the suspect line. That's a big head start, but a named suspect isn't a confirmed root cause, so the actual work was reading that function next to its sibling, the file-level eval() a few lines above it, and checking the claim against the s