标签：#dev

This is a submission for Weekend Challenge: Dog Days Edition What I Built PawSafe is an AI-powered web application that helps dog owners answer a simple but important question: "Can my dog eat this?" Users can enter the name of a food, upload a photo, or provide both. PawSafe then analyzes the information using Google's Gemini API and provides a simple safety assessment. The result is categorized into four levels: 🟢 Generally Safe 🟡 Use Caution 🔴 Not Safe ⚪ Unable to Determine Along with the result, PawSafe provides explanations, potential warnings, and safer alternatives when appropriate. My goal was to build something that was useful, simple to understand, and approachable for dog owners rather than making users search through multiple sources every time they encounter an unfamiliar food. Demo Live Demo Code GitHub Repository How I Built It PawSafe is a full-stack application built with: Frontend React Vite Tailwind CSS Lucide React Backend Node.js Express Multer CORS Google Gemini API Deployment Render GitHub The basic flow looks like this: User ↓ Food name / Image / Both ↓ React Frontend ↓ Express API ↓ Google Gemini ↓ Structured Analysis ↓ PawSafe Result Card One of the main technical decisions I made was to keep the Gemini API integration on the backend rather than exposing the API key in the frontend. The frontend sends the user's food information to the Express API. The backend then communicates with Gemini and returns the structured analysis to the frontend. I also wanted the application to support both text and images independently, while still allowing users to provide both when additional context is useful. Prize Categories Best Use of Google AI PawSafe is submitted for the Best Use of Google AI prize category. Google's Gemini API is the core intelligence behind the application. It is used to analyze both text-based and image-based food information and generate a structured safety assessment. The AI response is then presented through PawSafe's interface

I live on the Taghazout coast in Morocco - a strip of Atlantic between Agadir and Imsouane that's basically one long right-hand point break after another. Two years ago the only way to know if tomorrow was worth it was to check three different global forecast sites, none of which knew the difference between Anchor Point and the beach break 400m south of it. So I built taghazout.io . It now covers 20 named breaks, runs in 10 languages, and costs me nothing per month. Here's how it's actually put together - including the parts I'd do differently. The stack is deliberately boring Hand-rolled PHP. No framework, no build step, no node_modules. About 4,800 files, server-rendered, no hydration. That sounds like a confession, but it was the right call for one reason: my readers are on phones, on cafe Wi-Fi, often on 3G. A server-rendered page that ships HTML and a little CSS beats anything I could have built with a client-side framework in that environment. Time-to-content is the only metric that matters when someone is standing on the beach deciding whether to paddle out. The hosting is a cheap shared plan. The forecast data is free and open. The whole thing runs at EUR 0/month recurring , which was a hard constraint from day one. The interesting part: two ocean models that disagree The forecast blends two sources: Open-Meteo (CC BY 4.0) - the primary, with a marine endpoint that covers our coastal cells. NOAA WaveWatch III via PacIOOS - the second opinion. Here's the thing nobody tells you: they disagree, a lot. On the same hour at the same break I've seen WaveWatch read ~55% higher than Open-Meteo (1.36m vs 0.88m). Offshore models resolve coastal bathymetry badly, and our points are exactly the kind of close-in, shallow-reef setups where that bias shows up. The wrong fix is to pick one and pretend. What I did instead: Run both, cache both. Compute agreement over a 72-hour window - a Pearson correlation on the swell rhythm plus a circular difference on direction (you can'

Part of an ongoing series on model routing and trust tiering for agentic coding tools. This one's the boring, working half — no bug hunt, just a setup that's been running clean across two machines. The problem Claude Code does one thing well: careful, scoped edits with a real plan-then-execute loop behind them, backed by a subscription you're already paying for. Not every task needs that. Exploratory reads, "summarize this directory," draft-and-discard scratch work — most of that doesn't need the most capable model watching every token. The fix is a second, cheaper backend for that category of work. The catch: Claude Code only speaks Anthropic's Messages API. It has no built-in notion of "same tool, different model." So the question is how to point it somewhere else without giving up the interface. The stack Trusted agent: claude — real Anthropic subscription, default session Cheap agent: claude-cheap — same CLI, routed through a self-hosted proxy Proxy: LiteLLM, translating Anthropic-format requests to DeepSeek V4 (pro for Sonnet-tier calls, flash for Haiku-tier) served through an OpenRouter API Transport: a persistent SSH tunnel from a small VPS back to each machine The proxy itself wasn't new. It's the same LiteLLM instance already routing a separate content pipeline I run. The actual work here was wiring Claude Code to it: a shell function and a few environment variables. The core trick and it took me a few week to learn this is to point ANTHROPIC_BASE_URL at LiteLLM's /v1/messages endpoint, not the OpenAI-compatible path LiteLLM also exposes. Claude Code only understands the Anthropic shape, so the OpenAI-shaped endpoint fails in ways that look like a client bug and aren't. Once LiteLLM sits on the right endpoint and translates underneath, Claude Code has no idea it isn't talking to Anthropic. The one bug worth flagging Claude Code's Plan Mode attaches a context_management parameter to its requests. Anthropic's API handles it. Most other backends don't recogniz

Intro AI Avatar is a free app where your VRoid (VRM) avatar cheers you with all its might .🤗 It lives in your VS Code sidebar (reacts to Claude Code / GitHub Copilot) or browser side panel (reacts to ChatGPT / Claude). Animations and speech bubbles all run without AI too. This time I have three main topics. 🤝Catbot Integration 🏢AI Office 😺Cat Mode Let's see how they are! Catbot Integration I was asked to collaborate with my DEV Community friend @annavi11arrea1 Catbot . Catbot is A galactic robot cat you can talk to from any device — and a harness that lets you switch between (or combine) all of your AI models. https://github.com/AnnaVi11arrea1/catbot I was happy about this offer because I loved Anna's creativity and cool designs. I added the features below to AI Avatar to integrate Catbot. Launch Cat button: With this button, AI Avatar can run Catbot. Catbot with button: This makes Catbot stay beside AI Avatar. Cat Boss button: This changes the AI Office boss from a VRM avatar to Catbot. Cat Mode Many people feel that animals are healing and soothing. It is close to the AI Avatar concept of cheering people up. So I decided to add Cat Mode . I added the features below to make it look like a cat. Cat-like text, "Meow/Purrr" in English and "にゃ～" in Japanese Cat emojis Cat pose animations A new avatar with cat ears and cat whiskers. To tell the truth, the hardest part of making this mode was adding whiskers to the avatar using Blender . I can do basic things in Blender, but it is too difficult for me, even with the help of AI, just to add whiskers. It would be more fun if I added other animal modes too. AI Office AI Avatar displayed only one avatar. I thought it could do more things if it displayed several avatars at once. So I added AI Office mode. Two avatars are displayed and talk and move around when idle, and they also make a communication animation when using AI or clicking. I made one avatar a boss and one a worker. The hard part of making this mode was the timin

This is a submission for the DEV Weekend Challenge: Dog Days Edition . What I Built Same sidewalk. Two bodies. Two completely different heat loads. Banx is my French Bulldog. Born October 5, 2022. He weighs 35 pounds — seven above the 28-pound ceiling in the French Bull Dog Club of America conformation standard. I call him my XL. He is purebred and he has never had airway surgery. The face that makes him Banx is also the conformation that puts French Bulldogs at higher risk of obstructed breathing and heat-related illness. Dogs cool themselves mostly by panting. Flat-faced dogs can do it less efficiently, and how much varies a lot between individual dogs. So the same afternoon — same sun, same pavement, same humidity — is a walk for one dog and something else entirely for him. Nothing on the outside tells you that. Enter a location. It pulls temperature and humidity, computes a heat index, and shows the load on a flat-faced dog beside a longer-muzzle dog across the day. Then it helps me think through the question I actually have when he's standing at the door: how stressful do the conditions look right now, how does that change with activity, and when does the environment get more favorable? It does not medically answer that for him, and the section below says exactly why it can't. Demo Live: https://banx-walk-safe.vercel.app Geolocation or city search. Works if you deny location. No API key. Code Vanilla HTML / CSS / JS. No framework. Repo is the project folder on the machine that built it; the production artifact is the Vercel deploy above. Weather: Open-Meteo . Heat index: NOAA/NWS Rothfusz / Steadman family. Why I Built It When I first got him I didn't know how any of this worked. We started at Ledge Street Park in Nashua and took the trails toward Main Street. First ten minutes he's got everything — all over the place, into everything, full Banx. Then he changes. He stops being all over it and starts just observing. Walking straight forward, taking it in, calm.

This is a submission for Weekend Challenge: Dog Days Edition What I Built Dogs have...

What are you working on? I hear these words in my day-to-day. And sometimes, when I hear them, there’s this little brain freeze that happens because my brain is probably trying to put into words the amount of things that have wandered through my head in the last 24 hours. 😂 So I thought, okay, let me try something. I want to take some of those wandering thoughts, explorations, things I'm trying out and things I'm learning, and put them into writing. This is going to be a series where I come and talk about what I'm working on — software engineering, product, work, people, faith, relationships, rest, and whatever else happens to be taking up space in my head at the moment. So, what am I working on? I recently started writing backend code, and there’s a bit of a backstory to that. I built this frontend commerce store years ago where people can come and shop for furniture. At the time, I used a backend-as-a-service to handle the backend side of the application. Now, I’m coming back to that same system and writing the backend myself with NestJS. I wanted to go beyond just consuming a backend and actually understand what is happening behind the scenes. The learning process is a bit stretching at the moment because I’m getting familiar with a lot of new concepts. Tiring and frustrating? Yes. But the feeling when I finally understand the reason behind something is always refreshing. That has been really rewarding lately. I'm also in the middle of launching a mobile application at my workplace, going through system design classes, figuring out how to get the best out of my engineers (AI sub-agents, by the way 😅), and occasionally imagining that dream job where you get to build products that serve millions of people and work with really brilliant minds. Also, I discovered the productivity rush that comes with using large monitors. 😂 Then there's learning how to rest while also trying to close out all the open loops in my head. Building reading habits. Figuring out what to pri

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry. A quick note...

I just shipped a referral system for Adsyte , my free directory for indie projects, and the design decision behind it is worth sharing because it's a pattern that applies to any growth loop with a token reward attached. The obvious version, and why it's broken The naive implementation: give the recruiter tokens the moment someone signs up through their link. Simple, but it has an exploit built in. Signing up costs nothing, and OAuth makes throwaway accounts trivial. Anyone can self-refer through five Discord accounts and walk away with free reward tokens without bringing a single real user to the platform. What I did instead The payout only fires when the recruit publishes their first listing, not when they sign up. This one change closes the loop: A fake account costs nothing, but a real listing needs an actual project with a real URL The listing already has to pass duplicate-URL detection and hCaptcha, so faking one is meaningfully harder than faking a signup Every token paid out corresponds to a listing the directory actually gained, which is the metric that matters, not signups Implementation notes Referral code is an HMAC of the user's id, derived deterministically rather than stored as a random token, so there's nothing extra to generate or leak The code lives in a cookie set on landing ( ?ref=CODE ), read once at OAuth callback, and tied to the account via a Redis SETNX so it can only ever be set once, self-referral excluded outright Payout uses SETNX again on a per-recruit key so double-firing (retries, race conditions) can't double-pay A daily cap per recruiter stops a single compromised or bot-driven account from draining the reward pool in one sitting Nothing here is novel, it's the standard "pay for the outcome, not the action" principle, but I don't see it applied to referral systems as often as it should be. Most implementations I've seen reward signup because it's the easy event to hook into, and then bolt on fraud detection after the abuse shows up.

So here's what happened: i Tested DeepSeek vs Qwen vs Kimi vs GLM — Here's the Winner Okay, so I've been on this absolute rabbit hole for the past few weeks, and I have to share what I've found. You know how everyone's been talking about GPT-4o and Claude, but there's this whole other universe of Chinese AI models that are honestly punching way above their weight? Yeah, I went deep into it. Let me walk you through what I learned. If you've ever stared at a pricing page wondering which model to actually use for your side project, your startup's chatbot, or that one client who's been asking about cheaper alternatives — this is for you. I spent hours testing DeepSeek, Qwen, Kimi, and GLM through Global API's unified endpoint, and I'm going to break it all down for you. No fluff, no marketing speak, just what actually works. Why I Even Started Looking at Chinese Models Let me be honest with you — I was skeptical at first. My mental model was "Western models = good, Chinese models = questionable." Then a friend who runs a SaaS startup told me he cut his API bill by 80% by switching to DeepSeek for non-critical workloads. Eighty percent! I had to see for myself. The thing is, China's AI scene has exploded in the last couple of years. You've got four major players — DeepSeek from High-Flyer (幻方), Qwen from Alibaba (阿里), Kimi from Moonshot AI (月之暗面), and GLM from Zhipu AI (智谱) — and each one has its own personality, if you will. Some are great at coding, some are reasoning beasts, and some just refuse to break the bank. I figured the best way to compare them was to actually run the same prompts through all of them and see what happens. That's exactly what I did, and here's how it went. The TL;DR (For the Impatient Folks) I'll give you the punchline upfront because I know some of you are skimming: DeepSeek V4 Flash — absolute champion of price-to-performance at $0.25/M output Qwen — widest range of models, from $0.01/M all the way up to $3.20/M Kimi — the reasoning specialis

We run about 283 scheduled jobs across a handful of machines. Each one is a shell script that declares its own schedule in a header comment, ships its own --test , and gets wired into cron automatically once that test passes. It is a tidy arrangement and it has a hole in it that took us five separate incidents to see, because every one of those incidents looked healthy from every angle we had built. Every number, command and file listing below was re-measured on one 16-core Ubuntu 24.04 box while writing this, not quoted from the commit that fixed it. Two of the numbers came out different, and one of the mechanisms did not reproduce at all. Those are the interesting parts. The hole is that "green" is a conjunction pretending to be a single fact. For a scheduled job to be doing its work, at least four things have to be true at once: the test passes, the test asserts the thing the job does, the job is actually scheduled, it is scheduled where its consumer exists . We had instrumentation for (1). We had a habit — a good one — of insisting on (2). We had nothing whatsoever for (4), and it turns out (4) is the one that runs silently for weeks. 1. The edge detector that compared the state against itself The first one is almost embarrassing in the diff and was invisible for six weeks in production. We have a job that fuses four inputs into one node health label — HEALTHY , DEGRADED , CRITICAL — writes it to a state file, and with --edge prints a line only when the label changes . Cron runs it every five minutes; a separate log records the transitions. The --edge path did this: write_state " $label " # $STATE now holds the new label prev = $( cat " $STATE " ) # ...and prev is read from it [ " $prev " = " $label " ] && exit 0 prev is read after the write. It equals $label by construction. The equality test held on every single run, --edge exited 0 with empty output on every real transition, and the transition log could not append. What makes it worth writing about is not the

This is a submission for the DEV Weekend Challenge: Dog Days Edition . What I Built Every family with a dog eventually asks the same question: did anyone feed the dog? PawTwin turns that daily uncertainty into a shared game. It is a real-life Tamagotchi whose state is controlled by care performed for the family's physical dog—not a task manager with a mascot pasted on top. The family begins with a photo of the real dog. PawTwin creates a reusable pixel identity and places it inside an animated Phaser home. The environment communicates real needs: an empty bowl means food is due, a dry bowl means water is overdue, pacing at the door means a walk is waiting, and dirt particles mean hygiene has slipped. Completing and approving real care makes the twin playful again. A caregiver can claim feeding, water, walking, oral-care, ear-care or grooming work. Walks record time, approximate distance and a privacy-reduced route; other tasks can include private photo evidence. A guardian—not computer vision—reviews the proof and decides whether it counts. Approval can release a real Devnet SOL reward through a guardian-signed Solflare transaction. The V2 experience also gives the dog a life beyond reminders: Pet Memory learns explainable patterns such as who normally walks the dog and at what time, then creates personalized in-app reminders and a monthly family report. Find the Ball uses a future finalized Solana Devnet blockhash to choose one of four rooms, exposing the slot, blockhash, digest, salted commitment and nonce so anyone can reproduce the zero-stakes result. Life Album recreates the thick paper, metal rings, photo corners and protective cellophane of a family photo album, with private photos, stories, places and short recordings of the real pet's original sounds. Device Lab demonstrates a guarded Raspberry Pi ball-launcher contract while remaining clearly in simulator mode unless safe physical hardware is configured. The core loop is: Real need → visible game behavior

This is a submission for Frontend Challenge - Comfort Food Edition, Perfect Landing What I Built I created Balan Coffee & Roastery , a polished landing page for a fictional Vietnamese comfort café in Saigon. The concept is inspired by the quiet comfort of slow phin coffee, butter toast, and small sweet treats. Rather than treating coffee as a quick purchase, I wanted the site to feel like a calm daily ritual: slow, warm, familiar, and personal. Visitors can explore the menu, learn the café story, find visiting information, and interact with a small pixel-art coffee brewing experience. Highlights: Responsive editorial-style coffee shop landing page Vietnamese coffee-inspired menu, story, ritual, and visit sections Clear navigation and accessible interactive controls Consistent number and price typography throughout the site A lightweight interactive mini-game: Pixel Phin Brew Dose beans into the phin Grind the beans Bloom the coffee Let the phin drip Serve the finished cup Built without heavy UI, game, or animation libraries Demo Live demo: Balan Coffee & Roastery Source code: GitHub repository Journey I wanted to create something that felt more like a coffee ritual than a typical restaurant landing page. The visual direction uses warm cream tones, deep coffee browns, generous spacing, subtle texture, and an editorial layout inspired by a slow morning at a Saigon café. I paid attention to small details such as consistent tabular numerals for prices and opening hours, responsive layouts, visible interaction states, and reduced-motion support. The feature I enjoyed building most was Pixel Phin Brew . I wanted the interaction to be understandable instead of just decorative, so each button clearly explains the next brewing action. Every correct step updates the pixel scene, progress indicator, and feedback message until the final cup is served. The project was built with React, TypeScript, Vinext/Vite, and custom CSS. I kept the implementation lightweight and avoided add

Performance testing is essential for ensuring your applications can handle expected user loads without bottlenecks or failures. Apache JMeter remains one of the most popular open-source tools for load, stress, and performance testing. Here is a quick guide to getting your JMeter environment set up and executing your first load test. 1. Prerequisites JMeter requires Java to execute. Ensure you have JDK 11 or higher installed on your system. Verify your Java installation: java -version 2. Download and Installation Download the latest binary zip/tgz file from the Official Apache JMeter Site. Extract the archive into your preferred local directory. Launch JMeter from the bin directory: Windows: Double-click jmeter.bat macOS/Linux: Open terminal and run ./jmeter.sh 3. Install the Plugins Manager The Plugins Manager simplifies adding listeners, graph generators, and custom samplers. Download jmeter-plugins-manager.jar from JMeter Plugins. Move the file into your JMeter lib/ext directory. Restart JMeter. Access the Plugins Manager under Options > Plugins Manager. 4. Building Your First Test Plan Set up a basic HTTP test using the GUI interface: Thread Group: Right-click Test Plan > Add > Threads (Users) > Thread Group. Configure your target virtual users, ramp-up time, and loop count. HTTP Request Defaults: Right-click Thread Group > Add > Config Element > HTTP Request Defaults. Set your target server domain/IP and port. HTTP Sampler: Right-click Thread Group > Add > Sampler > HTTP Request. Define the API path and request method. Listeners: Right-click Thread Group > Add > Listener > View Results Tree or Summary Report (use these GUI listeners primarily for test script validation). 5. Running Tests in Non-GUI Mode Never run actual heavy load tests through the JMeter GUI as it consumes significant local system resources. Use CLI mode for accuracy: jmeter -n -t /path/to/testplan.jmx -l /path/to/results.jtl -e -o /path/to/html-report-folder -n: Non-GUI execution -t: Path to y

This is a submission for Weekend Challenge: Dog Days Edition Target categories: Best use of Snowflake + Best use of Solana. Ten days from now International Dog Day is August 26th. The date is not arbitrary and it is not a marketing pick. Colleen Paige founded it in 2004 and chose the 26th because that is the day her family brought her first dog home from a shelter , when she was ten years old. So the holiday is not really about dogs. It is about the gap between a dog sitting in a shelter and a dog sitting in a house, and about how many animals never cross it. That gap is the whole reason this project exists, and it is why the last tab of this dashboard is the quietest one. I did not start at the shelter. I started at a limp nobody saw. But every path I traced ran the same direction, and it always ended in the same room. This is a build post, so most of what follows is SQL. But I want to be honest about which end of the problem I was standing at when I wrote it. The problem, stated plainly Because a hackathon post should be able to say this in four rows before it earns the right to show you any SQL: The question In one line The issue A dog in pain is built to hide it, so the first human-readable sign of a chronic problem arrives months late - often at the point the relationship, not just the joint, has broken down. Why software has not fixed it Every consumer tracker compresses a day of movement into a scalar - steps, active minutes, a sleep score - and then thresholds it. The clinical signal is not in the magnitude. It is in the ordering , and averaging is precisely the operation that deletes ordering. What TELLTAIL tries Stop thresholding. Make the detector a regular expression over rows - MATCH_RECOGNIZE - so a differential diagnosis stays a sequence all the way down to the individual second that satisfied it. How you know it is not a demo Every finding is explainable to the second, the accuracy is printed in 44px type on the dashboard including the parts that are

Here is a step-by-step guide to configuring your Playwright/Cucumber test suite to run on LambdaTest Cloud via Azure DevOps pipelines, returning test results directly to Azure. 1. Prerequisites A GitHub repository containing your Playwright, Cucumber, and JavaScript automation code. An active Azure DevOps account with a project created. A LambdaTest account (you will need your username and access key). 2. Connect GitHub to Azure DevOps In Azure DevOps, navigate to Pipelines > New Pipeline. Select GitHub as the source and authenticate your account. Choose your repository and target branch (e.g., main). 3. Create LambdaTest Credentials Variable Group Go to Pipelines > Library in Azure DevOps. Click + Variable group and name it LambdaTest-Credentials. Add the following key-value pairs: LAMBDATEST_USERNAME = your_lambdatest_username LAMBDATEST_ACCESS_KEY = your_lambdatest_access_key (toggle "Keep this value secret") Save the group. 4. Add/Update Your azure-pipelines.yml Place this configuration file in your repository root directory: trigger : - main pool : vmImage : ' windows-latest' variables : - group : LambdaTest-Credentials - name : BASE_URL value : ' https://your-app-url.com' - name : LT_BROWSER value : ' chrome' - name : ENABLE_LAMBDATEST value : ' true' stages : - stage : Test jobs : - job : UITestsLambdaTest displayName : ' UI Tests (LambdaTest Cloud)' steps : - task : NodeTool@0 inputs : versionSpec : ' 20.x' displayName : ' Install Node.js 20.x' - script : npm ci displayName : ' Install Dependencies' - script : npm run test:ui:smoke displayName : ' Run UI Smoke Tests on LambdaTest' env : ENABLE_LAMBDATEST : ' true' LT_USERNAME : $(LAMBDATEST_USERNAME) LT_ACCESS_KEY : $(LAMBDATEST_ACCESS_KEY) LT_BROWSER : $(LT_BROWSER) BASE_URL : $(BASE_URL) - task : PublishTestResults@2 condition : always() inputs : testResultsFormat : ' JUnit' testResultsFiles : ' reports/junit-report.xml' testRunTitle : ' UI Tests - LambdaTest Cloud' 5. Update Your Test Code Ensure your tes

var is one of the ways to create a variable in JavaScript. A variable is a place to store a value, like a name or a number. var is mostly seen in old JavaScript code, written before 2015. Today most people use let and const instead, but it still helps to know var , especially when reading old code. Creating a Variable var name = " Abishek " ; var age = 22 ; console . log ( name ); console . log ( age ); Here, name stores "Abishek" and age stores 22 . We Can Change the Value var age = 22 ; age = 23 ; console . log ( age ); The output is 23 . The value inside age got updated. We Can Also Create it Again We can create the same variable a second time with var , and JavaScript does not give an error. var name = " Abishek " ; var name = " Abi " ; console . log ( name ); The output is Abi . It just overwrites the old value. It Works Across the Whole Function A block is a small part of code inside { } , like an if statement. var does not care about these small blocks, it only cares about the function. function test () { if ( true ) { var x = 10 ; } console . log ( x ); // works fine } test (); Even though x was created inside the if part, we can still use it outside the if , as long as we are inside the function. Hoisting console . log ( x ); var x = 10 ; You might expect an error here, but the output is undefined . This is because JavaScript moves the var declaration to the top before running the code. This is called hoisting. Why var Isn't Used Much Now Most people use let and const instead of var , because var can cause confusing bugs like accidental redeclaration and hoisting. let is used when the value can change, and const is used when it should not change. In Short var was the first way to create variables in JavaScript. It can be changed, redeclared, and it works across the whole function instead of one block. Once you understand var , let and const become easier to learn.

I shipped a plugin to the WordPress.org directory. It got zero installs. That is not a complaint, it is the normal outcome. Roughly 19% of all plugins in the directory never pass zero installs , which is more than 10,500 of them. But I wanted to know why , and whether the answer was "your plugin is bad" or something structural. So instead of reading marketing advice, I queried the directory API and counted. Everything below is reproducible. The API is free, needs no key, and every query I used is in the article. The short version Search is a two phase system, and phase one is a hard filter , not a ranking. If a single word of the user's query is missing from your listing, you are excluded from that search entirely. Phase two is where you lose, and it is ranked partly on active installs . That is the cold start trap. Of the plugins that broke out recently, 88% had distribution before they started . The two behaviours that actually correlate with breaking out from nothing are release cadence and resolving support threads , which are two of the five phase-two ranking inputs and the only two a plugin with no installs can move. WordPress.org gives plugin authors no analytics whatsoever . No listing views, no impressions, no click-through. Anyone who tells you confidently what makes people click install is guessing. How search actually works The best-documented account traces to WP Tavern's 2017 coverage of the directory relaunch, quoting Greg Brown, the Automattic data engineer who built it. It runs on Elasticsearch, and it has two phases. Phase one builds the candidate pool. It matches against title, excerpt, description, tags, slug, author name and contributor names. Critically: all search keywords must appear somewhere, or the plugin is excluded from the result set. Not ranked low. Excluded. Phase two sorts that pool by last update date, compatibility with the current core version, active installs, percent of support tickets resolved, and average rating. That split ma

A comprehensive, production-ready checklist for reviewing data validation, ETL testing, and automated reconciliation codebases. Code reviews for data engineering tools need more rigor than standard web apps. A subtle bug in a data validation framework can cause silent pipeline failures, false positive test passes, or accidental execution of unbounded SQL queries on production warehouses. Whether you are building a custom data framework or maintaining automated ETL tests, use this generalized checklist during code reviews to keep your test suites secure, performant, and reliable. 1. Test Case Configuration (YAML / JSON) TC ID Matching: Ensure the tc_id value matches the configuration filename exactly. Schema Validity: Verify that type (e.g., count, data, recon, file) and source/target drivers are valid and supported. Explicit Enablers: Confirm the enabled field is explicitly set (true or false) rather than omitted. Relative File Paths: For file-based validation, ensure paths are relative to defined source/target data directories. Non-Empty Queries: Confirm SQL sources and targets include non-empty query strings or valid template paths. Unique Case IDs: Ensure test case identifiers are unique across the test suite directory. Documented Rationale: If a test case has enabled: false or uses numeric tolerance thresholds (validation_tolerance), ensure a comment explains the business reason. Dependency Order: Verify that basic structural checks (COUNT) run prior to deep comparisons (DATA / RECON). 2. SQL & Query Logic Explicit Projections: No SELECT *. All columns must be explicitly listed to avoid schema drift breaks. Alignment: Source and target queries must return compatible data types and matching column ordering. Environment Isolation: Check that query strings contain zero hardcoded hostnames, schema names, or environment paths. Secret Hygiene: Ensure queries contain no hardcoded credentials or connection strings. Warehouse Pushdown: Confirm filtering and heavy aggrega

I recently had to do a deployment for a client demo. On local everything worked fine. All the tests were passing. All the data was where it was supposed to be. And then I pushed it to production. Suddenly, queries were failing. And I could not figure out why. So I fixed the first query. Re-built it, pushed again. It worked, but another thing broke. Rinse repeat and another thing broke. All the queries that were failing had something in common. An error because a function was receiving nil or an empty enumerable. They were built for when data to be queried existed. But in production, I had no data. I was working with an empty state. I had spent the past week designing for when the data is already there. Designing for when my database is already seeded. Designing for when queries were passing. But prod will get a blank slate. I was a bit angry and a bit embarrassed at myself for overlooking such a situation. It reminded me of old developer wisdom I had heard before. 80% of the time in software development is about discovering and covering the "unhappy" paths. source: https://x.com/sihui_io/status/914908896371777536? While I am not sure about that metric, the point stands. So now I have had to re-orient my process for writing new features. I have to define all possible states that the feature may be in and test all the states. That way I do not have to spend another 6 hours going through production wondering why that query is failing. It is good to assume failure and the unhappy path. Because then you can plan for it.