Coder Legion - Recent posts tagged regression

Mathematical Intuition of Linear Regression

Mon, 06 Jul 2026 18:58:15 +0000

Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star git-lrc on GitHub to help more developers discover the project. Do give it a try and share your feedback for improving the product.

Linear Regression Line

The line is drawn between two axes, X and Y.

We can draw infinite lines with different points. But only one will be best fit for the given points.

For a set of 2D points (x_i,y_i), the simplest linear regression model is:

y = mx + b

Where:

(m) = slope
(b) = intercept

To compute them from your points:

Slope:

m = (n∑xy−(∑x)(∑y)) / (n∑x^2−(∑x)^2)

Intercept:

b = (∑y−m∑x) / n

Then your best-fit line is:

y = mx + b

Calculation of Slope

For example points:

x	y
1	2
2	3
3	5
4	4

Result:
m = 0.8
b = 1.5

Best-fit line:
y = 0.8x + 1.5

Finally we get the result:

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.

⭐ Star git-lrc on GitHub

AI-driven architectural regression

Mon, 20 Apr 2026 15:02:43 +0000

AI Code: It Passes Review, but the System Dies Anyway

Ever had that sinking feeling? The CI is glowing green, linters are silent, and the code looks like a work of art. This phenomenon, often leading to AI-driven architectural regression, starts when variable names are meaningful and logic seems modular, but the foundation is rotting. You hit Merge, go to bed, and at 3 AM on a Tuesday, the system starts bleeding out. No explosions, no dramatic crashes — just a slow, agonizing erosion of stability. This isn’t a logic bug. It’s Architectural Drift.

We’ve entered an era where LLMs optimize for the context window, not for your system's survival. The AI solved the ticket? Yes. Was it correct? In isolation, absolutely. But it just drilled a hole through a load-bearing wall in your architecture, and nobody noticed because the "drywall" looks perfect.

The Illusion of Correctness

The core issue is that AI doesn't understand invariants — the invisible, unwritten rules that have kept your project alive since 2021. This isn’t "code debt" you can refactor away during a Friday cleanup. This is Architectural Debt. You don't "fix" it; you amputate it along with the affected modules — if you’re lucky enough to find it before it metastasizes.

Why Your "Clean" Code is a Time Bomb

Thread Safety? The LLM will drop a dict.update() where atomicity is a hard requirement. It looks fine in a unit test, but under real load, you’ve got a corrupted state.
Idempotency? It’ll write a beautiful retry loop that ends up double-charging your customer because of a 50ms network hiccup.
Event Loop Blocking? To an LLM, numpy.dot() is just a function. In production, at 5,000 req/s, it’s a silent killer that hangs your entire asyncio loop for 40ms.

The Halo Effect: How Seniors Become Rubber Stamps

The most dangerous link in this chain isn't the bot — it’s the exhausted Senior Engineer. AI-generated code is deceptively tidy. The styling is consistent, the comments are there. The reviewer’s brain falls for the Halo Effect: the first 10 lines are elegant, so the pattern-recognition system marks the whole thing as "high quality."

A > that should’ve been a >= on line 47, or an assert that gets stripped in production with the -O flag, slips through without a second thought because the surrounding code looks professional.

Survival Protocols for 2026

If you think your project is safe because you have 90% test coverage, congratulations — you’re the primary target. We need to move beyond simple unit tests and start enforcing architecture at the CI level.

In the full breakdown, we dissect:

Invariant Drift: How local logic violates the global state of your system.
Silent Memory Pressure: Where descriptor leaks hide in "convenient" AI patterns.
The Thundering Herd: How removing one "redundant" timeout cascades into a multi-service blackout.
Practical Mitigations: From custom Ruff rules to contract-based thinking that prevents AI from burning your house down.

Stop guessing and start auditing. Check out the deep dive on AI-driven architectural regression and learn how to stop the bleeding before it's too late.

Weather Service Project (Part 3): Predicting the Future with AI and OpenWeatherMap

Thu, 22 Jan 2026 06:49:58 +0000

In the first part of this series, we set up the backbone of our global weather service, collecting raw data using Python and GitHub Actions. Then, in Part 2, we transformed that raw data into a beautiful, interactive dashboard, leveraging GitHub Pages/Netlify, JavaScript, PapaParse.js, and Chart.js.

Now, it's time for the grand finale: adding predictive power to our Weather Service. We'll explore how to augment our historical data visualization with actual forecasts. This installment focuses on a dual approach: integrating an official, reliable forecast from a professional service (OpenWeatherMap) and, more excitingly, building and training our very own simple AI model (Linear Regression) to predict tomorrow's weather based on the historical data we've meticulously collected. Finally, we'll visualize both forecasts on our dashboard, allowing for a direct comparison and a real-world test of our AI's accuracy.

Let's turn our data into a crystal ball!

The Predictive Core: OpenWeatherMap and Our Custom AI

The goal for this predictive functionality was twofold:

Official Forecast: Obtain a reliable, multi-day forecast from a professional weather service (OpenWeatherMap - OWM).
Custom AI Prediction: Create our own simple AI model (Linear Regression) trained on the historical data we've collected, to predict the next day's weather.
Visualization & Comparison: Display and compare both forecasts to gauge the accuracy and performance of our custom AI model.

1. ⚙️ Backend Logic: `read_weather.py` Gets Smarter

Our read_weather.py script, previously responsible for data collection, now expands its role to gather data from both OWM and our historical archives, consolidating everything into a single predicciones.json file.

Step 1: Fetching OpenWeatherMap's 5-Day Forecast

We decided that in addition to our 1-day AI prediction, a 5-day forecast from OWM would provide valuable context.

API Endpoint: We opted for the free data/2.5/forecast API (since OneCall 3.0 required a payment method).
Data Processing: This API returns data in 3-hour blocks. We had to add Python logic to:
- Iterate over the list of ~40 forecasts.
- Group them by day (ignoring the current day).
- For each of the next 5 days, calculate the maximum, minimum, and average temperature from all 3-hour blocks within that day.
Result: A list of 5 objects (one per day) containing OWM's max, min, and average temperature predictions.

Step 2: Implementing Our AI Model (1-Day Prediction)

This is the core of our "homemade AI." For each city:

Data Loading: We used pandas to read the city's historical CSV file (e.g., datos/Madrid.csv).
Feature Engineering: Since we had multiple readings per day, the most crucial step was transforming this data:
- Resampling: We used df.resample('D') from pandas to group data by day, calculating the actual daily aggregates (e.g., temp_max, temp_min, avg_temp, avg_humidity).
- Feature Creation (X): We created new "shifted" columns (.shift(1)) so that each row (representing a day) contained the previous day's data (e.g., temp_max_lag1, avg_humidity_lag1). We also added day_of_year to capture seasonality.
- Target Creation (y): We defined what we wanted to predict (e.g., the actual temp_max of the current day).

Training 3 Models: Instead of one, we trained three independent Linear Regression models (scikit-learn):
- model_max: Trained with y = df_clean['temp_max'].
- model_min: Trained with y = df_clean['temp_min'].
- model_avg: Trained with y = df_clean['avg_temp'].
Prediction:
- We took the last row of aggregated data (representing "today's" data).
- Fed this data to the 3 models to predict "tomorrow's" values.
- We included a safeguard (MIN_RECORDS_FOR_IA = 10) so the model only attempts to predict if it has sufficient historical data (e.g., 10 clean days).

Step 3: Consolidate and Save

The script combines the results from Steps 1 and 2 into a JSON structure and saves it to predicciones.json:

{
  "Madrid": {
    "pred_owm_5day": [ 
      { "date": "...", "max": 15.0, "min": 10.0, "avg": 12.5 }, 
      ... (5 days) ...
    ],
    "pred_ia": {
      "max": 14.8,
      "min": 7.5,
      "avg": 11.2,
      "records": 120
    }
  },
  "A Coruña": {
      ...
      "pred_ia": { "max": null, "min": null, "avg": null, "records": 9 } // Example of insufficient data
  }
}

2. Frontend Logic: `index.html` Visualizes the Future

The frontend is responsible for loading this predicciones.json file and presenting it in a visually appealing and informative way.

Step 1: Data Loading

loadPredictions(): We created a new async function that runs once during initialization (before updateDashboard).
allPredictionsCache: This function loads predicciones.json and saves it into this new global variable so that all visualization functions have access to it.

Step 2: Visualization in the "Super-Cards" (KPIs)

We wanted a direct and clear comparison.

OWM 5-Day Forecast:
- We created a helper function buildForecastHTML().
- This function takes the pred_owm_5day list and generates an HTML block with a list of the 5 days and their max/min temperatures (e.g., "Sat, Nov 9: 15.1°C / 10.0°C").
AI 1-Day Forecast (Comparison):
- We created a second helper function buildIAForecastHTML().
- This function takes the pred_ia object and the first day of the OWM forecast (pred_owm_5day[0]).
- Comparison Logic: For max, min, and average temperatures, it displays the AI's value and then, next to it, the difference from OWM.
- Visual Impact: The difference is colored red (if our AI predicts warmer) or blue (if it predicts cooler), giving us an immediate visual cue of our model's deviation.
- It also handles the "Insufficient Data" case (${ia_preds.records}/${MIN_RECORDS_FOR_IA}).
updateKPIs(): The card template was modified to call these two new functions, displaying both forecast blocks.

Step 3: Visualization in the Charts

We wanted the forecasts to be integrated directly into the existing charts.

Evolution Chart (Dotted Line):
- In updateChart(), we added a new dataset for each city.
- This dataset uses the average of the OWM prediction (pred_owm_5day).
- We applied the style borderDash: [5, 5] to draw it as a dotted line.
- We "stitched" the beginning of this line to the last real data point to make it appear as a seamless continuation.
Variation Chart (Striped Bars):
- In updateVariationChart(), we added another dataset for each city.
- The y data for this set is day.max - day.min (the variation) from the OWM forecast.
- For styling, we created a helper function createStripedPattern() that draws a striped pattern on a canvas.
- We used this pattern as the backgroundColor for the forecast bars, differentiating them from the solid bars of real data.

Conclusion (Part 3)

With this final installment, our Weather Service project is complete! We've successfully integrated both professional 5-day forecasts from OpenWeatherMap and a custom 1-day AI prediction model, all powered by our collected historical data. The frontend now provides a rich, interactive experience that not only visualizes past weather but also offers a glimpse into the future, complete with a comparative analysis of our AI's performance.

This journey has covered everything from backend data collection, automation with GitHub Actions, static site hosting with Netlify, to dynamic frontend development with vanilla JavaScript, advanced data parsing with PapaParse.js, interactive charting with Chart.js, and finally, dipping our toes into Machine Learning for predictive analytics.

We've built a robust, serverless, and insightful application entirely on free services. The possibilities for expansion (e.g., more complex ML models, different data sources, user accounts) are endless, but for now, we have a fully functional weather oracle!

References and Links of Interest:

Complete Web Service: You can see the final project in action here: https://datalaria.com/apps/weather/
Project GitHub Repository: Explore the source code and project structure in my repository: https://github.com/Dalaez/app_weather
OpenWeatherMap API: https://openweathermap.org/api
Pandas: Python Data Analysis Library: https://pandas.pydata.org/
Scikit-learn: Machine Learning in Python: https://scikit-learn.org/
PapaParse.js: Fast in-browser CSV parser for JavaScript: https://www.papaparse.com/

Tester's Six Eye Technique: Visual Regression Testing

Fri, 02 May 2025 10:27:37 +0000

Visual UI Regression Testing is a critical practice in web development that ensures the visual consistency of a user interface (UI) across updates, browser versions, or devices. This guide explains what it is, why it matters, and how tools like Playwright (and AI-powered solutions like Applitools) simplify the process.

What Is Visual UI Regression Testing?

Visual UI Regression Testing involves comparing screenshots of a web application’s UI before and after changes to detect unintended visual differences. Unlike functional testing, which verifies logic and workflows, visual testing focuses on pixel-perfect rendering of elements like layout, colors, fonts, and images.

Why Does It Matter?

Prevents UI Bugs: Catches visual regressions caused by code changes, such as misaligned buttons or broken styles.
Enhances User Trust: Ensures a consistent experience, especially for apps with frequent updates (e.g., ecommerce platforms).
Saves Time: Automates repetitive manual checks during sanity testing.

Which Applications Need It?

Ecommerce Platforms: Visual consistency directly impacts user trust and conversion rates. A misplaced "Buy Now" button or a broken product image can lead to lost sales.
Dynamic Content Apps: Apps with frequent A/B tests, CMS-driven content, or third-party integrations benefit from automated visual checks.

How It Simplifies Sanity Testing

Sanity testing ensures critical functionalities work after minor updates. Visual regression testing automates this by:

Reducing Manual Effort: No need to manually inspect every UI element.
Enabling Rapid Deployment: Catch visual issues early in CI/CD pipelines.
Supporting Cross-Browser/Device Validation: Ensure consistency across browsers without manual testing.

Combining Visual Testing with Accessibility Testing

While visual testing focuses on appearance, accessibility testing ensures usability for all users, including those with disabilities. They complement each other:

Run Both in Parallel: Use tools like Playwright for visual checks and Axe for accessibility audits.
Shared Workflows: Trigger both tests during CI/CD to catch visual and usability issues.

Why It’s Not Accessibility Testing:

Visual testing ignores screen reader compatibility, keyboard navigation, or ARIA labels.

Accessibility testing doesn’t verify pixel-level design consistency.

Performing Visual Testing with Playwright

Playwright, a modern testing framework, simplifies visual regression testing with built-in screenshot comparison. Below is an example test:

import { test, expect } from '@playwright/test';

test('Visual Regression Test for My Website', async ({ page }) => {
  // Navigate to the website
  await page.goto('https://yusufasik.com'); // Replace with your website URL

  // Scroll through the page to trigger lazy loading
  await page.evaluate(() => {
    return new Promise<void>((resolve) => {
      let totalHeight = 0;
      const distance = 100;
      const timer = setInterval(() => {
        const scrollHeight = document.body.scrollHeight;
        window.scrollBy(0, distance);
        totalHeight += distance;

        if (totalHeight >= scrollHeight) {
          clearInterval(timer);
          resolve();
        }
      }, 300);// Adjust the interval as needed, scroll every 300ms
    });
  });

// After initial page load and full-page scrolling:

// Handle all lazy-loaded images
const hoverElements = await page.getByRole('link', { name: 'mail' }).all();
for (const img of images) {
  await img.scrollIntoViewIfNeeded(); // Makes each image visible
  await img.waitFor({ state: 'visible' }); // Waits for load completion
}

// Handle hover-activated elements if any
const hoverElements = await page.getByRole('link', { name: 'mail' }).all();
for (const el of hoverElements) {
  await el.hover();
  await page.waitForTimeout(500); // Adjust based on your animations
}

// Additional safety measures
await page.waitForLoadState('networkidle'); // Waits for network inactivity
await page.waitForTimeout(500); // Small buffer for final rendering

    // Take a full page screenshot and mask out dynamic elements
    await expect(page).toHaveScreenshot({
      fullPage: true,
      animations: 'disabled',
      mask: [
        page.locator('[data-test="titles"]:nth-of-type(1)'), // Replace with the selector of the dynamic element
      ],
      maxDiffPixelRatio: 0.01,
    });
});
});

Example Playwright Report on Fail

Pro Tips

Customize selectors - Use attributes specific to your hover mechanism like [data-hover] or .hover-load
Adjust timings - Some hover effects have delays (CSS transitions/JS timeouts)
Combine approaches - Some elements might need both scrolling AND hovering

This combination ensures you capture all dynamic content in your visual tests, whether triggered by scroll, hover, or other interactions.

.toMatchSnapshot() vs .toHaveScreenshot()

.toMatchSnapshot() comes from Jest or generic test runner while.toHaveScreenshot() built-in Playwright runner.
You can give snapshot name manually .toMatchSnapshot() but not Pw runner.
Tolerance is none if you use .toMatchSnapshot(), so best practice would be put it on critical aspects like purchase now, login/logout.

Important Attributes

animations: "disabled": Disables animations to prevent flaky comparisons.
mask: If there is dynamic elements constantly changing.
maxDiffPixelRatio: Allows minor differences (e.g., anti-aliasing) to reduce false positives.

CI/CD Integration

Use tracing.start() and tracing.stop() to capture traces (screenshots, DOM snapshots) in CI environments.
Update baselines with npx playwright test --update-snapshots after intentional UI changes.

AI-Powered Visual Testing with Applitools

Tools like Applitools enhance traditional pixel comparison with AI:

Ultra-fast Grid: Test across 100+ browser/device combinations in parallel.
Smart Baseline Management: AI auto-approves insignificant changes (e.g., text rendering).
Test Result Monitoring: Cloud dashboards highlight visual diffs and track trends.

Why It’s Better

Reduces False Positives: AI ignores trivial differences (e.g., font rendering).
Scales Effortlessly: Test complex UIs (e.g., ecommerce dashboards) without infrastructure setup.

Example: Applitools with Playwright

Below is a sample setup using Applitools Eyes with Playwright. This code enables testing across both classic and Ultrafast Grid runners.

import { test } from '@playwright/test';
import {
  BatchInfo,
  Configuration,
  EyesRunner,
  ClassicRunner,
  VisualGridRunner,
  BrowserType,
  DeviceName,
  ScreenOrientation,
  Eyes,
  Target
} from '@applitools/eyes-playwright';
require('dotenv').config();

export const USE_ULTRAFAST_GRID: boolean = true;
export let Batch: BatchInfo;
export let Config: Configuration;
export let Runner: EyesRunner;
let eyes: Eyes;
let URL = 'https://demo.applitools.com';

test.beforeAll(async() => {
  if (USE_ULTRAFAST_GRID) {
    Runner = new VisualGridRunner({ testConcurrency: 5 });
  } else {
    Runner = new ClassicRunner();
  }

  const runnerName = (USE_ULTRAFAST_GRID) ? 'Ultrafast Grid' : 'Classic runner';
  Batch = new BatchInfo({ name: `ACME Project - ${runnerName}` });

  Config = new Configuration();
  Config.setBatch(Batch);

  if (USE_ULTRAFAST_GRID) {
    Config.addBrowser(800, 600, BrowserType.CHROME);
    Config.addBrowser(1600, 1200, BrowserType.FIREFOX);
    Config.addBrowser(1024, 768, BrowserType.SAFARI);
    Config.addDeviceEmulation(DeviceName.iPhone_11, ScreenOrientation.PORTRAIT);
    Config.addDeviceEmulation(DeviceName.Nexus_10, ScreenOrientation.LANDSCAPE);
  }
});

test.beforeEach(async ({ page }) => {
  eyes = new Eyes(Runner, Config);
  await eyes.open(
    page,
    'Example Page',
    test.info().title,
    { width: 1024, height: 768 }
  );
});

test.afterEach(async () => {
  await eyes.close();
});

test.afterAll(async () => {
  const results = await Runner.getAllTestResults();
  console.log('Visual test results', results);
});

test.describe('Example Test', () => {
  //Test code here...
});

Important Attributes

USE_ULTRAFAST_GRID: Flag to switch between Applitools' Ultrafast Grid and Classic Runner.
BatchInfo: Groups related test results for better organization in the Applitools dashboard.
Configuration: Holds test settings like browser types, devices, screen sizes, and the batch reference.
VisualGridRunner / ClassicRunner: Determines how tests are executed—either in parallel across devices (Ultrafast Grid) or locally (Classic).
addBrowser() / addDeviceEmulation(): Specifies the environments (browsers or devices) to run visual checks against.
eyes.open(): Initializes a visual testing session, associating it with the current page.
eyes.close(): Ends the session and submits the results for comparison.
getAllTestResults(): Retrieves a report of all visual check results after the test suite completes.

This setup makes it easy to scale visual testing across a matrix of
devices and browsers while maintaining consistency and clarity in
reporting.

Domain Expansion:

Visual UI Regression Testing is essential for maintaining brand integrity and user satisfaction, especially in fast-paced environments like ecommerce. Playwright offers a robust open-source solution, while AI-powered tools like Applitools provide enterprise-grade scalability. By combining visual and accessibility testing, teams can deliver polished, inclusive experiences with confidence.

Coder Legion - Recent posts tagged regression

Mathematical Intuition of Linear Regression

Linear Regression Line

Calculation of Slope

AI-driven architectural regression

AI Code: It Passes Review, but the System Dies Anyway

The Illusion of Correctness

Why Your "Clean" Code is a Time Bomb

The Halo Effect: How Seniors Become Rubber Stamps

Survival Protocols for 2026

Weather Service Project (Part 3): Predicting the Future with AI and OpenWeatherMap

The Predictive Core: OpenWeatherMap and Our Custom AI

1. ⚙️ Backend Logic: read_weather.py Gets Smarter

Step 1: Fetching OpenWeatherMap's 5-Day Forecast

Step 2: Implementing Our AI Model (1-Day Prediction)

Step 3: Consolidate and Save

2. Frontend Logic: index.html Visualizes the Future

Step 1: Data Loading

Step 2: Visualization in the "Super-Cards" (KPIs)

Step 3: Visualization in the Charts

Conclusion (Part 3)

References and Links of Interest:

Tester's Six Eye Technique: Visual Regression Testing

What Is Visual UI Regression Testing?

Why Does It Matter?

Which Applications Need It?

How It Simplifies Sanity Testing

Combining Visual Testing with Accessibility Testing

Performing Visual Testing with Playwright

Example Playwright Report on Fail

Pro Tips

.toMatchSnapshot() vs .toHaveScreenshot()

Important Attributes

CI/CD Integration

AI-Powered Visual Testing with Applitools

Why It’s Better

Example: Applitools with Playwright

Important Attributes

Domain Expansion:

1. ⚙️ Backend Logic: `read_weather.py` Gets Smarter

2. Frontend Logic: `index.html` Visualizes the Future