AI 资讯
Caninography
This is a submission for Weekend Challenge: Dog Days Edition I built Caninography, a small digital archive for exploring dog breeds from around the world. I wanted it to feel more like a digital museum than a normal dog website. You can explore breeds, their origins, history, countries, characteristics and connections between them. The whole design is dark, clean and visual. I also kept it silent, so there is no distracting audio or player UI. Live Demo: canonigraphy.vercel.app GitHub: https://github.com/maisamabbas0323/canonigraphy.git How I Built It I built it with React, Vite and TypeScript. For the visual side, I focused a lot on typography, photography, smooth transitions and responsive layouts. I also added an interactive world atlas and a constellation-style view to explore breed relationships. For the content, I used Google Gemini to help create short and interesting breed information. I didn't wanted to make another chatbot. Instead, Gemini stays behind the experience and helps make the archive content more rich while people simply explore it. Prize Categories Best Use of Google AI Caninography is submitted for Best Use of Google AI. I used Google Gemini to generate concise, breed-specific information based on the archive data. The idea was to use AI in the background, not put a chatbot in front of the user. Built With React Vite TypeScript Google Gemini CSS SVG Canvas A Little About The Idea I always felt dog breed information is mostly shown as simple lists. So I thought: What if a dog archive felt like a museum? That small idea became Caninography. A place to explore their stories, origins and history — one breed at a time.
AI 资讯
I verified 51 sets of US tax rules by hand and turned them into a static site
Run the same salary through three different paycheck calculators and you'll get three different answers. None of them explain why. That bothered me enough to spend three weeks building an alternative. The result is payculate.org — a paycheck calculator for all 50 US states and DC where every deduction line opens up and shows its own arithmetic . The interesting problem wasn't the code The tax math itself is straightforward: progressive brackets are a loop, FICA is two multiplications with a cap. I had a working federal calculator in an afternoon. The hard part was that every state is a special case , and a generic model breaks on most of them: Wisconsin has a standard deduction that shrinks as you earn more — it starts at $13,230 and falls by 12 cents per dollar above a threshold, reaching zero around $126,000. Alabama lets you deduct your entire federal income tax before calculating state tax. The more federal tax you pay, the less Alabama income you have. Utah looks flat at 4.5%, but gives a taxpayer credit that phases out with income — so the effective rate climbs while the headline rate never moves. Ohio taxes nothing on the first $26,050, then a flat 2.75%. South Carolina rewrote its entire income tax in March 2026: six brackets became two (1.99% / 5.21%), and the federal standard deduction was replaced by a state-specific deduction that phases out above $40,000 of AGI. That last one I only caught during a routine data check last week. Most calculators I checked are still showing the old six-bracket system. The lines nobody counts The bigger discovery was what national calculators leave out entirely: employee-paid state payroll premiums . Washington charges no income tax at all. But Paid Family & Medical Leave (0.807%) and WA Cares (0.58%, uncapped) still take about $1,040 a year from a $75,000 salary . Most tools show $0 on that line. California's SDI lost its wage cap in 2024 and now takes 1.3% of every dollar — on a $200,000 salary that's $2,600 that appears
AI 资讯
I run a surf forecast for 20 breaks in Morocco on EUR 0/month. Here's the stack.
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'
AI 资讯
😸Catbot Integration, AI Office, Cat Mode (AI Avatar v17: VS Code and Chrome Extension)
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
AI 资讯
Banx Walk Safe: same sidewalk, two heat loads
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.
产品设计
PawMatch: Finding the Dog That Matches Your Personality 🐾
This is a submission for Weekend Challenge: Dog Days Edition What I Built Dogs have...
AI 资讯
Designing a referral system that can't be gamed by throwaway accounts
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.
AI 资讯
I Tested DeepSeek vs Qwen vs Kimi vs GLM — Here's the Winner
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
AI 资讯
Balan Coffee & Roastery — A Slow-Drip Vietnamese Coffee Landing Page
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
AI 资讯
var in JavaScript
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.
AI 资讯
I measured 7,032 WordPress plugins to find out how anyone gets their first install
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
AI 资讯
The World Clock Time-Zone Landscape: what 162 places reveal about time zones
Time zones look like a tidy grid of whole hours. They aren't. I read the standard UTC offset of all 162 cities, countries and regions on our World Clock straight from the IANA database (via Intl ) — and the real shape is lumpy, with quarter-hour outliers and a near-even split over whether clocks move at all. The quirk, in one line: Kathmandu keeps its clocks 5 hours 45 minutes ahead of UTC — the only :45 offset on the board, and one of 11 places out of 162 that don't sit on a whole hour. Nearly half the rest never move their clocks at all. The clocks that don't sit on the hour Most of the world rounds to a whole hour from UTC. A handful don't: Offset Places UTC+3:30 Tehran (Iran) UTC+4:30 Kabul (Afghanistan) UTC+5:30 India — New Delhi, Mumbai, Kolkata, Bengaluru, Hyderabad UTC+5:45 Kathmandu (Nepal) UTC+9:30 Adelaide, Darwin (Australia) Half-hour and quarter-hour offsets are a reminder that a time zone is a political decision, not an astronomical one — which is exactly why date code should read the IANA database rather than dividing longitude by 15. Nearly half never change their clocks Daylight saving feels universal if you live in North America or Europe, but it isn't. Of the 162 places tracked, 87 (54%) shift their clocks and 75 (46%) never do . The whole of East Asia, the Gulf, most of Africa, India and much of South America keep one fixed offset year-round — Tokyo, Singapore, Dubai, Nairobi and New Delhi never spring forward. Where the clocks crowd together Offsets aren't evenly populated. Four of them carry nearly half the board: Offset Places Who's there UTC−5 25 US Eastern — New York, Toronto, Miami, Boston UTC+1 21 Central Europe — Paris, Berlin, Rome, Madrid UTC−6 14 US Central — Chicago, Dallas, Mexico City UTC+2 12 Eastern Europe & Africa — Athens, Cairo, Johannesburg The full set spans 22 hours , from Honolulu at UTC−10 to New Zealand and Fiji at UTC+12. Reproduce it Every number here is printed by one dependency-free Node script that reads each place's
AI 资讯
WordPress Block Themes vs Classic Themes: Should You Switch in 2026?
If you've been developing WordPress websites for several years, there's a good chance you've spent a lot of time working with files like: header.php footer.php single.php page.php archive.php functions.php That's certainly where most of my WordPress development experience has been. But WordPress has been changing. With the Block Editor, Site Editor, block themes, patterns, and theme.json , WordPress now offers a very different approach to theme development. So I decided to take a closer look at the question: If you're already comfortable building classic WordPress themes, is it worth moving toward block themes in 2026? This isn't an article written from the perspective of someone who has spent years exclusively building block themes. Most of my own WordPress work has traditionally involved classic themes . Instead, I'm looking at block themes from the perspective of an experienced WordPress developer who is exploring how the platform is evolving—and where the newer approach fits alongside the architecture I've used extensively. Classic Themes vs Block Themes WordPress currently identifies two primary theme types: Classic themes Block themes According to the official WordPress Theme Developer Handbook, classic themes primarily use PHP, JavaScript, and CSS and can make extensive use of WordPress functions, hooks, and filters. Block themes, on the other hand, are built around block markup and HTML-based templates and allow users to edit more areas of the website through the Site Editor. A simplified comparison looks like this: Classic Theme Block Theme PHP templates HTML block templates single.php templates/single.html header.php parts/header.html footer.php parts/footer.html Template hierarchy Block-based templates Custom PHP logic Blocks + APIs + plugins Customizer / theme options Site Editor / Styles theme.json optional theme.json commonly used This doesn't mean classic themes are obsolete. They aren't. WordPress continues to maintain documentation for classic theme
AI 资讯
GoFullPage got pulled. Here is how to take a full-page screenshot without any extension.
On 11 August the GoFullPage extension disappeared from the Chrome Web Store and got disabled in Chromium browsers. Eleven million users, one Tuesday. It was not a hack. The developers say it was a copyright dispute over a design element, that it was "definitively not a security issue", and that they are working with Google on getting it back. Chrome shows the same "might be unsafe" string for every kind of Web Store policy breach, so the warning read far worse than the cause. Two things came out of it. A short list of fixes, and a longer thought about where our tools live. Get working again in a minute Re-enable it. Open chrome://extensions . If Chrome disabled the extension rather than deleting it, the toggle is still there. Use Edge. GoFullPage was never removed from the Edge add-ons store. Install the beta. The team published a separate build at ID kehafhfdnkhdgbnpeofmhmbibmpnjaof , and it can sit alongside the original. That is the practical answer. The more interesting one is that most of us never needed the extension. Five ways to capture a full page with no extension at all 1. Chrome DevTools, no code Open DevTools, press Cmd/Ctrl + Shift + P , type screenshot , choose Capture full size screenshot . This has been in Chrome for years and most people have never found it. It handles scroll-height pages properly and drops a PNG in your downloads. 2. Firefox, even shorter In the Firefox console: :screenshot --fullpage Add --dpr 2 for a retina-density capture, or --clipboard to skip the file. 3. Chrome DevTools Protocol, if you want it scripted The thing the extension was wrapping is one CDP call: await client . send ( ' Page.captureScreenshot ' , { format : ' png ' , captureBeyondViewport : true , }); captureBeyondViewport is the flag that does the work. Everything else in a full-page screenshot tool is UI around it. 4. Playwright import { chromium } from ' playwright ' ; const browser = await chromium . launch (); const page = await browser . newPage ({ viewport
AI 资讯
We scanned our own production site and found 8 vulnerabilities. Here’s the list.
Building software in 2026 feels surreal. With LLMs handling boilerplate, we ship features in hours that used to take weeks. But fast shipping has a nasty side effect: it breeds overconfidence. A few days ago, we ran an automated check against our own live marketing site ( vergate.dev ). We build security and diagnostic tools for a living, so we expected a clean bill of health. We were wrong. Our scanner flagged 8 real issues in production—including missing security headers that left us exposed to basic cross-site attacks. Dogfooding your own tool isn't a marketing gimmick. Sometimes, it's just plain embarrassing. But it taught us a crucial lesson: you can’t fix what you don't automatically measure. What our scan actually found Here is the exact breakdown of what slipped past us into production (and what probably exists in your current deployment right now): 1. Zero Security Headers Enabled Our hosting provider’s default CDN edge rules didn't set baseline headers. We were shipping without: Content-Security-Policy (CSP): Left us open to inline script injection. Strict-Transport-Security (HSTS): Didn't force browsers to enforce HTTPS strictly. X-Content-Type-Options : Allowed MIME-type sniffing on static assets. X-Frame-Options : Rendered our pages vulnerable to clickjacking IFrames. Why this happens: Framework defaults (like Next.js, Nuxt, or Astro) often expect your proxy or CDN edge (Vercel, Cloudflare, Nginx) to handle headers. If you forget to configure the edge, your app runs bare. 2. Sensitive Meta & Server Leakage Our response headers explicitly broadcast our server stack and proxy details. Attackers use automated scanners like Shodan or Censys to query these specific signatures and exploit target-specific CVEs in seconds. 3. Cookie Missing SameSite & Secure Flags A tracking cookie set on a subroute wasn't explicitly flagged as SameSite=Lax or HttpOnly , leaving a window open for CSRF-style cross-domain requests. How we fixed it (in under 10 minutes) Fixing the
AI 资讯
Your Website Can Be Technically Perfect and Still Fail at SEO
I've seen this happen a lot. A developer builds a fast website, gets the Core Web Vitals into a good range, adds proper metadata, creates a sitemap, fixes broken links, and makes everything responsive. Then they wait for Google traffic. And... almost nothing happens. The problem is that technical SEO is only one part of SEO. A technically clean website can still struggle if Google doesn't clearly understand what the site is about, which searches it should appear for, or why its content deserves to rank. Start With Search Intent One of the easiest mistakes is creating a page around a keyword instead of a user's actual problem. For example, imagine someone searches: "how to reduce JavaScript bundle size" They probably don't want a 2,000-word definition of JavaScript bundles. They want practical answers: What is making the bundle large? How do I find the problem? What can I remove? Which tools should I use? What does a good result look like? That's search intent. Before creating a page, ask: "If I were searching this, what would I actually want to accomplish?" Then build the page around that. Don't Ignore What Your Competitors Are Doing When a page isn't ranking, don't immediately add more keywords. Look at the pages already ranking. Not just their word count. Look at: Questions they answer Topics they cover Examples they provide Tools they recommend Content structure Missing information on your own page Sometimes the biggest opportunity isn't "write more." It's cover something useful that the current results don't cover well. Developers Have a Huge SEO Advantage Developers can do something many content teams struggle with: show the actual thing. Instead of writing: "Improve your website performance." You can show a Lighthouse result, explain what caused the problem, provide the code change, and show the result afterward. That's much more useful. The same idea works for SEO. If you explain an SEO problem , include the actual query, page, code, Search Console data, expe
AI 资讯
How We Got an LLM to Draw Charts Without Ever Touching a Pixel
Let's get something out of the way first. Having data is good. Having a database full of reviews, commits, and org activity sitting there quietly, untouched, unread, never once glanced at by a human being with a coffee and an opinion? That's not "having data." That's a very expensive data graveyard. At LiveReview , we build what we call a Blast-Radius Aware AI Code Review for Business-Critical Systems . Which is a fancy way of saying: we review your code, we figure out how bad it would be if a change goes wrong, and we don't shut up about it until someone fixes it. Along the way we accumulate a review data: who reviewed, how much, how fast, how often, which repos are on fire. And for a while, that pile just sat there. Engineering leaders would ask "is adoption increasing?" and get back a vibe, not an answer. So we built Livi , a chat bot that answers real questions about that data with real charts, not paragraphs of hedging. This post technically about how Livi draws those charts. Specifically: why we never let the LLM touch a pixel, how the same chart definition ends up as both a live interactive graph in your browser and a flat PNG in a Slack thread, and why teaching a language model to pick the right chart shape is a surprisingly deep rabbit hole. The core decision: don't ask the LLM to draw, ask it to describe The tempting, wrong idea is: "let's have the LLM generate an image." Please don't. Image-generating models are a different beast entirely, and even if you got one to draw a bar chart, you'd have no way to verify the numbers on it are real. You'd be trusting a model that hallucinates plausible-sounding review counts to also render them faithfully into pixels. That's not a chart, that's chart-shaped fan fiction. The actually good idea, and the one every serious LLM-charting integration eventually converges on, is: the LLM writes Vega-Lite , a JSON grammar for describing charts declaratively. You don't say "draw a blue bar going up." You say: { "mark" : "bar"
AI 资讯
Null Is Not Zero: Building a JavaScript SEO Audit That Admits Its Limits
We moved a server-side SEO engine into a Chrome extension. Measuring the page was the easy half. Saying what we could not measure was the hard half. We had been running an on-page analysis engine on our own servers for years. You give it a URL, it fetches the page, it reports. Ordinary. Then we moved that engine into the browser, because a server cannot reach localhost , a staging box, an intranet, or anything behind a login. The browser can. Porting the analysis was mechanical work. What took the real time was a category of problem that barely exists on the server: in a live tab, half the things you want to measure are sometimes unavailable, and the honest answer is not a number. This post is about the decisions that came out of that, with the code that implements them. The One Rule: Null Is Not Zero Every derivation in the engine returns number | null , and the two mean different things. 0 means we measured it and it is zero. A page with no layout shift really does score zero. null means we could not measure it. No interaction happened yet, the browser does not support that entry type, or the document came from another origin and the size fields were zeroed out. A zero printed where a null belongs is a made-up number. It is worse than an empty cell, because the reader has no way to tell it apart from a real measurement. So the two never collapse: the derivation keeps them separate and the UI renders them differently. That sounds obvious written down. It is surprisingly easy to violate, and the next section is the most common way. PerformanceObserver Fails Silently, So Ask It First Here is the trap. Calling observe() with an entry type the browser does not support does not throw . It does not warn. It quietly does nothing, and your handler is simply never called. Which means an unsupported metric produces exactly the same result as a measured zero. The one thing the rule above forbids. The fix is to ask before you observe, and to record the refusal: js const SUPPOR
科技前沿
Astronomers Discover the Existence of a Black Hole Star
An object observed by the James Webb Space Telescope lends credence to a strange explanation for the mysterious red spots in the early universe.
开发者
GOOD DOG: you are the dog, and the dog is real
This is a submission for Weekend Challenge: Dog Days Edition What I Built A game where...